| semantic-links |
|
|---|
Define a lightweight, machine-readable convention to couple Agent Skills and repository artifacts.
This convention is intentionally minimal. It is designed to prevent skill drift without introducing a heavy ontology framework.
The repository keeps a small catalog of marker definitions.
Current markers:
| Marker | Value | Meaning |
|---|---|---|
skill-link |
<skill-name> |
This artifact affects the linked skill and should trigger a skill review when changed. |
Add new markers only when there is a concrete recurring maintenance problem that the current marker set cannot represent.
Use this marker in comments or documentation text close to behavior-defining lines:
skill-link: <skill-name>
Rules:
skill-namemust match the skill frontmatternamevalue.- Use lowercase letters, numbers, and hyphens.
- Add only high-signal links: artifacts that can make a skill stale when they change.
For new or updated issue and EPIC specification documents, YAML frontmatter is the canonical metadata source. Existing specs may be migrated incrementally as they are touched.
Use frontmatter to keep machine-readable metadata and semantic links queryable and consistent.
For other Markdown artifacts, frontmatter remains optional but recommended.
Required metadata fields for issue specs:
doc-type: issue
issue-type: <task|bug|feature|enhancement>
status: <draft|planned|in-progress|blocked|in-review|done>
priority: <p0|p1|p2|p3>
github-issue: <number|null>
spec-path: <repo-relative-path>
branch: <branch-name>
related-pr: <number|null>
last-updated-utc: YYYY-MM-DD HH:MMRequired metadata fields for EPIC specs:
doc-type: epic
status: <draft|planned|in-progress|blocked|in-review|done>
github-issue: <number|null>
spec-path: <repo-relative-path>
epic-owner: <owner|null>
last-updated-utc: YYYY-MM-DD HH:MMWhen frontmatter metadata is present, do not duplicate it in a body section like ## Metadata.
Recommended shape:
---
semantic-links:
skill-links:
- <skill-name>
related-artifacts:
- <repo-relative-path>
---Guidance:
- For Markdown files with frontmatter
semantic-links.skill-links, the frontmatter is the canonical source; inline<!-- skill-link: ... -->top-of-file markers are redundant and need not be added. - For non-Markdown artifacts and Markdown files without frontmatter, inline markers remain the primary convention.
- Use frontmatter to express richer relations (for example bidirectional links).
- Keep paths repository-relative and stable.
- Keep links high-signal; avoid noisy or speculative links.
- For issue and EPIC specs, include both metadata and
semantic-linksin frontmatter.
Use language-appropriate syntax:
- Rust:
// skill-link: <skill-name> - TOML:
# skill-link: <skill-name> - Markdown:
<!-- skill-link: <skill-name> -->
For Markdown files with frontmatter semantic-links.skill-links, top-of-file inline markers are
redundant and need not be added. Inline markers placed near specific workflow-defining sections
within the body remain useful for navigation but are not required when frontmatter links are present.
Place the marker near:
- constants that encode default behavior,
- configuration blocks consumed by the workflow,
- documentation sections that define the operational procedure.
- Add or update
skill-linkmarkers in touched artifacts. - Update the skill instructions if semantics changed.
- Validate links and markers.
This repository currently uses these minimal categories:
- Skill: instruction protocol with stable
name - Artifact: code, config, or documentation file
- Relation:
skill-linkfrom artifact to skill - Validator: script that verifies relation integrity