External Resource Context

Purpose

This skill resolves a concrete external evidence dependency for a current design or verification decision, records its stable access method, and lets later consumers reuse that evidence.

Potential resources include design origin, design system, API or database schema sources, IaC, and verification environments. A workflow selects only the resource axis needed by its current decision.

Scope Boundaries

In scope: resolving a named external evidence need, storage location, single-source ownership, and lookup of a known resource.

Freshness handling: record access methods and feature identifiers here. The consuming workflow checks current resource content at use time.

Storage Locations

Single Source Rule

The project tier owns environment facts such as URLs, MCP server names, file paths, commands, and secret-store locations. Feature-tier sections list feature-specific identifiers such as design node ids, API paths, schema names, or IaC module names, then reference the project-tier label.

Hearing Protocol

When to Hear

State which decision or verification result the requested resource controls. Leave unrelated axes unrecorded. Use N/A only for a selected or inspected axis confirmed to be outside the project.

Domain Routing

Load the domain reference matching the current task:

Each domain reference defines candidate axes and question templates. Record only the axes selected for the current decision.

Focused Hearing

Ask for the selected axis, its stable access method, and the feature identifier when known. Accept MCP server name, URL, file path, command, repository-owned source, or existing implementation. One answer completes the hearing when it makes the named decision inspectable.

When the resource remains unavailable, return the missing evidence and the exact decision it leaves unsupported to the caller. The caller owns response selection within its outcome and authority, including omitting an unnecessary mechanism; this lookup does not create a requirement to preserve the current design or invent a fallback.

Storage Protocol

After hearing completes:

1. Merge the selected axis into the project-tier content using references/template.md; preserve unrelated existing entries.
2. Write docs/project-context/external-resources.md, creating docs/project-context/ as needed.
3. When a target UI Spec or Design Doc exists, update its External Resources Used section with project-tier labels plus feature-specific identifiers.
4. If a write fails, return the error with the intended path and leave completion status unresolved.
5. Report touched file paths to the calling workflow.

Lookup Protocol

Consumers resolve external context in this order:

1. Read the matching label from docs/project-context/external-resources.md.
2. Read the matching feature identifier from the target UI Spec or Design Doc when present.
3. Fetch or inspect only the resource needed by the current decision.

Output Format

The project-tier file follows references/template.md. Feature-tier sections use the fixed heading External Resources Used; heading level follows the parent document structure.

Quality Checklist

• Every requested axis names the decision or verification result it controls
• Each requested axis has a usable access method or records the exact unsupported decision for its consuming workflow
• Project-tier file contains environment facts
• Feature-tier sections contain feature identifiers and project-tier labels
• Unrelated project-tier entries are preserved

References

• references/frontend.md
• references/backend.md
• references/api.md
• references/infra.md
• references/template.md