external-resource-context
The external-resource-context skill captures and stores access methods for resources that exist outside the repository such as design systems, API schemas, IaC sources, and secret stores in a deterministic two-tier structure (project-level and feature-level documentation). Use this skill when downstream work depends on external resources or when users mention design sources, design systems, API schemas, IaC sources, secret stores, or canonical sources that the codebase needs to reference.
git clone --depth 1 https://github.com/shinpr/claude-code-workflows /tmp/external-resource-context && cp -r /tmp/external-resource-context/dev-workflows-fullstack/skills/external-resource-context ~/.claude/skills/external-resource-contextSKILL.md
# 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: 1. Read `docs/project-context/external-resources.md` (if present) to learn what is available and how to access it. 2. Read the target UI Spec or Design Doc's `## External Resources Used` section for feature-specific identifiers. 3. 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 Capturing a record requires an interactive hearing. The workflow using this skill owns the interaction mechanism and routing. Follow [references/hearing.md](references/hearing.md) for the hearing conditions, domain routing, two-phase hearing, storage protocol, and quality checklist. ## Output Format The project-tier file follows the structure in [references/template.md](references/template.md). The project-tier file's heading levels and section names are fixed so downstream agents can locate sections deterministically. 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](references/hearing.md) — Hearing conditions, domain routing, storage protocol, quality checklist - [references/frontend.md](references/frontend.md) — Frontend domain axes - [references/backend.md](references/backend.md) — Backend domain axes - [references/api.md](references/api.md) — API contract domain axes - [references/infra.md](references/infra.md) — Infrastructure domain axes - [references/template.md](references/template.md) — Project-tier and feature-tier structure templates
Generates integration/E2E test skeletons from Design Doc ACs using ROI-based selection and journey-based E2E reservation. Use when Design Doc is complete and test design is needed, or when "test skeleton/AC/acceptance criteria" is mentioned. Behavior-first approach for minimal tests with maximum coverage.
Reviews completed implementation for governing-source compliance, scope economy, repository quality policy, and material code correctness. Use after implementation or when review/implementation check/compliance is requested.
Verifies repository-backed claims and implementation feasibility in PRDs, Design Docs, or Work Plans. Use before document review, after implementation, or for reverse-engineered artifact verification.
Collects compact repository evidence for scope confirmation, technical option selection, complete design, and verification. Use before Design Doc creation when repository facts can change scope, reuse, contracts, cost, or proof.
Detects conflicts across multiple Design Docs and provides structured reports. Use when multiple Design Docs exist, or when "consistency/conflict/sync/between documents" is mentioned. Focuses on detection and reporting only, no modifications.
Reviews one document or one ADR batch against governing requirements, repository evidence, and the needs of its next consumer. Use before user approval or when document consistency and completeness need verification.
Reviews changed integration and E2E tests against skeletons, proof obligations, or explicit prompt claims. Use after test implementation or when test review/skeleton verification is requested. Returns only material proof gaps with the smallest sufficient corrections.
Comprehensively collects problem-related information and creates evidence matrix. Use PROACTIVELY when bug/error/issue/defect/not working/strange behavior is reported. Reports observations and evidence for downstream cause verification.