external-resource-context
Skill712 starsChanged 8 months agoMITView on GitHub
Records where resources outside the repository live (design source, design system, API schema, IaC source, secret store) and how design, implementation, and verification reach them. Use when work depends on an external resource, or when the user mentions design source, design system, API schema, IaC source, secret store, or canonical source.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- shinpr/codex-workflowstheir own version, first seen Nov 3, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- shinpr/codex-workflows★ 39same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository27 other files it gives its agents.
- ai-development-guideSkill
- coding-principlesSkill
- documentation-criteriaSkill
- implementation-approachSkill
- integration-e2e-testingSkill
- llm-friendly-contextSkill
- recipe-add-integration-testsSkill
- recipe-buildSkill
- recipe-designSkill
- recipe-diagnoseSkill
- recipe-front-adjustSkill
- recipe-front-buildSkill
- recipe-front-designSkill
- recipe-front-planSkill
- recipe-front-reviewSkill
- recipe-fullstack-buildSkill
- recipe-fullstack-implementSkill
- recipe-implementSkill
- recipe-planSkill
- recipe-quality-profileSkill
- recipe-reverse-engineerSkill
- recipe-reviewSkill
- recipe-update-docSkill
- requirement-convergenceSkill
- subagents-orchestration-guideSkill
- testing-principlesSkill
- typescript-rulesSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 29
Before investigating the repository for an external fact, check whether it is already recorded:
- Very specific: line 31
Read docs/project-context/external-resources.md (if present) to learn what is available and how to access it.
- Very specific: line 32
Read the target UI Spec or Design Doc's ## External Resources Used section for feature-specific identifiers.
- Distinctive: line 33
Use the access method declared in the project tier (e.g., the named MCP, the URL, the file path) to fetch the actual resource content.
- Distinctive: line 35
When the file is absent or the resource is unreachable, continue from governing and repository evidence.
- Distinctive: line 43
Use references/template.md for a compact project record.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
External Resource Context
Purpose
Repository evidence does not contain every external resource surrounding a system. This skill captures, in a deterministic location, the access methods to resources outside the repository so downstream work (design, planning, implementation, review) can reach them without repeatedly rediscovering access details.
Resources covered: design origin (where the canonical visual specification lives), design system (component library and tokens), guidelines (usage docs, accessibility rules), visual verification environment (how to confirm rendering), database schema source, migration history, secret store location, API schema source (OpenAPI / proto / GraphQL SDL), mock environment, IaC source, environment configuration.
Storage Locations (Two-Tier)
| Tier | Location | Holds | Update Frequency |
| Project | docs/project-context/external-resources.md | Environment-stable facts: which resources exist for this project and how to access them (URL, MCP name, file path, command) | Rare — only when the project's environment changes |
| Feature | ## External Resources Used section inside the relevant UI Spec or Design Doc | The subset of project-tier resources actually used by this feature, plus feature-specific identifiers (e.g., a specific node id within the design tool, a specific endpoint path) | Per feature |
Single Source of Truth Rule
The project tier owns environment facts. Feature-tier sections list only feature-specific identifiers (node id within the design source, specific endpoint path within the API, specific IaC module name) and reference project-tier entries by label; URLs, MCP names, and access commands remain in the project-tier file. When the environment changes, only the project-tier file is updated.
Example feature-tier entry uses the table format defined in references/template.md: a row with the project-tier label in the first column and the feature-specific identifier in the second column.
Reference Protocol (For Downstream Consumers)
Before investigating the repository for an external fact, check whether it is already recorded:
- Read
docs/project-context/external-resources.md(if present) to learn what is available and how to access it. - Read the target UI Spec or Design Doc's
## External Resources Usedsection for feature-specific identifiers. - Use the access method declared in the project tier (e.g., the named MCP, the URL, the file path) to fetch the actual resource content.
When the file is absent or the resource is unreachable, continue from governing and repository evidence. Each consumer records the limitation in its applicable output.
Capturing and Updating Records
Capture only resources needed by the current decision. Reuse supplied access details and repository records, verify them within current authority, and ask only for missing information that prevents that decision. Follow references/hearing.md for evidence, questions and storage.
Output Format
Use references/template.md for a compact project record. Preserve existing labels referenced by consumers; include only relevant entries with their access details and source evidence.
For feature-tier sections inside UI Spec or Design Doc, the heading text "External Resources Used" is fixed; the heading level matches the parent document's natural structure (h2 in UI Spec where it is a sibling of other top-level sections, h3 in Design Doc where it sits under Background and Context).
References
- references/hearing.md — Decision-specific capture and storage
- references/frontend.md — Frontend domain axes
- references/backend.md — Backend domain axes
- references/api.md — API contract domain axes
- references/infra.md — Infrastructure domain axes
- references/template.md — Project-tier and feature-tier structure templates
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.