Purpose
Assign status by performing two verifiable checks for each skill (output contract existence + number of acceptance criteria), and normalize agent.yaml and README. The agent is prioritized; agent.yaml is the machine-consumable source of truth.
Core Objective
Primary Objective: Produce verifiable status, normalized documentation, and a repository-level inventory for all skills in the repository.
Success Criteria(all must be met):
- ✅ Each skill's SKILL.md has been scanned and annotated
has_output_contract: true|false - ✅ Each skill's agent.yaml contains the
acceptance_criteriafield (array, empty allowed) - ✅ status is derived according to the rules and written back to agent.yaml
- ✅ Overlaps are filled into
owner/repo:skill-namein the formoverlaps_with - ✅ Repository-level
skills/SKILL_INVENTORY.mdis written or refreshed, containing status distribution, contract coverage, missing list, and final recommendations
Acceptance Test: Can an AI agent understand each skill's status and relationships solely through the agent.yaml file, without reading SKILL.md or README?
Scope Boundaries
This skill is responsible for:
- Output contract detection (grep
## Appendix: Output contractor## 附录:输出合约/合同/契约) - Acceptance criteria field maintenance
- status assignment (validated / experimental / archive_candidate)
- Overlap detection and market_position annotation
- agent.yaml and README.md normalization
- Repository-level
skills/SKILL_INVENTORY.mdgeneration
This skill is not responsible for:
- Skill design refinement (→ refine-skill-design)
- SKILL.md content modification (→ refine-skill-design)
- Output contract appendix writing (→ refine-skill-design or manual)
- Registry synchronization (INDEX.md / manifest.json separate process)
- Generating README from scratch (→ generate-standard-readme)
Handoff Point: When SKILL_INVENTORY.md is written with final recommendations, hand off to the user for review or to refine-skill-design to handle the identified issues.
Use Cases
- After adding or changing a skill: Recheck and update status and documentation
- Audit: Review lifecycle distribution and overlaps
- Repository summary: Generate or refresh SKILL_INVENTORY.md
- Self-assessment: Manage the repository, including this meta-skill itself
Behavior
- Scan: List all skill directories under
skills_directoryAll skill directories under - Detect output contract: grep each skill's SKILL.md; matching any of the following is considered
has_output_contract: true:## Appendix: Output contract## 附录:输出合约## 附录:输出合同## 附录:输出契约
- Read/initialize acceptance_criteria: Read from agent.yaml; if it does not exist, initialize to an empty array
- Derive status:
validated←has_output_contract == true AND len(acceptance_criteria) >= 1experimental← otherwisearchive_candidate← only manually set by the maintainer; this skill does not actively transition it
- Overlaps and positioning: Assign
overlaps_with(owner/repo:skill-nameform) andmarket_position(differentiated / commodity / experimental) - Write back: Update each skill's agent.yaml (status, has_output_contract, acceptance_criteria, overlaps_with, market_position); normalize README.md
- Summary: write to
skills/SKILL_INVENTORY.md, must include a final recommendations section
status determination rules
validated = has_output_contract AND len(acceptance_criteria) >= 1
experimental = otherwise
archive_candidate = manual only
No scoring system. No cognitive mode derivation. No gating thresholds. Two boolean conditions determine status.
Ecosystem position (per skill)
- overlaps_with:
owner/repo:skill-namelist, this repository's format matches other repositories; leave empty if none[] - market_position:
differentiated: clearly differentiated, minimal overlap, unique value in the inventorycommodity: general-purpose capability, overlaps with multiple skillsexperimental: early-stage, niche, or unclear positioning
Interaction: before bulk-overwriting skill files or writing SKILL_INVENTORY.md, confirm with the user; unless the user explicitly requests a full run (e.g., "curate all skills").
Inputs and Outputs
Input
skills_directory: root path containing skill subdirectories (e.g.,skills/)
Output
- Per skill: update agent.yaml (status, has_output_contract, acceptance_criteria, overlaps_with, market_position); normalize README.md
- Repository-level:
skills/SKILL_INVENTORY.mdor a structured chat summary - Overlap and positioning report
Restrictions
Hard boundaries
- Do not modify specs/skill.md or manifest.json
- Do not overwrite SKILL.md (design refinement is handled by refine-skill-design)
- Do not write output contract appendix content (only detect existence)
- Do not proactively set
archive_candidate(maintainer manual only) - Do not output any scoring fields (
scores、asqm_quality、validation_gateswas removed by ADR 008; writing it is a violation)
Skill boundaries (avoid overlap)
- Skill design refinement →
refine-skill-design - Skill spec changes →
refine-skill-design - Output contract writing →
refine-skill-designor manual - Registry sync → separate process
- Standalone README generation →
generate-standard-readme
When to stop and hand off:
- User asks "How can I improve this skill's design?" →
refine-skill-design - SKILL_INVENTORY.md shows a skill is missing an output contract → recommend in the final recommendations section
refine-skill-design - User asks "Can you update INDEX.md?" → explain that registry sync is separate, provide manual steps
Self-Check
Core success criteria
- All skills' SKILL.md scanned and has_output_contract marked
- All skills' agent.yaml contains the acceptance_criteria field
- status derived and written back per the rules
- overlaps_with filled in as
owner/repo:skill-nameformat - SKILL_INVENTORY.md contains status distribution, coverage statistics, missing list, final recommendations
Process quality check
- Does the scan cover all skill directories?
- Does has_output_contract detection match both Chinese and English appendix titles?
- When acceptance_criteria is empty, is status correctly downgraded to experimental?
- Were no
scores/asqm_quality/validation_gatesfields output? - Is the user confirmed before bulk overwrite (unless a full run is explicitly requested)?
Acceptance tests
Can an AI agent understand each skill's status and relationships solely through the agent.yaml file, without reading SKILL.md or README?
- No: detection or documentation is incomplete, return to the corresponding step
- Yes: management complete, handoff or awaiting user comments
Example
Example 1: Full management run
- Input:
skills_directory: skills/; User: "curate all skills in this repo" - Expected: Scan all subdirectories; for each skill grep SKILL.md to detect the output contract; read or initialize acceptance_criteria; derive status according to the rules; write back agent.yaml; normalize README; write
skills/SKILL_INVENTORY.mdincluding final recommendations
Example 2: Single-skill recheck
- Input: User: "recheck refine-skill-design"
- Expected: Scan only that skill's SKILL.md; update that agent.yaml's has_output_contract and status; do not write SKILL_INVENTORY.md (unless requested)
Edge case: New skill has only SKILL.md
- Input: New directory contains only SKILL.md, no agent.yaml, no README
- Expected: grep SKILL.md to detect the output contract; initialize agent.yaml with has_output_contract, acceptance_criteria (empty array), overlaps_with, market_position; derive status as experimental (acceptance_criteria is empty); generate a minimal normalized README from SKILL.md; summarize and report that the skill is new
Appendix: Output contract (per skill agent.yaml)
When this skill writes or updates each skill's agent.yaml, use this structure:
name: [kebab-case skill name]
status: validated | experimental | archive_candidate
primary_use: [one-line purpose]
inputs:
- [list of input names]
outputs:
- [list of output artifacts]
has_output_contract: true | false # SKILL.md 是否含输出合约附录
acceptance_criteria: # 可观测的输入→输出断言;空数组合法但 status 降为 experimental
- [criterion 1]
- [criterion 2]
overlaps_with: # Git-repo form: owner/repo:skill-name
- [owner/repo:skill-name]
market_position: differentiated | commodity | experimental
status derivation rules:
validated←has_output_contract AND len(acceptance_criteria) >= 1experimental← otherwisearchive_candidate← maintainer manual setting only
Prohibited fields(removed by ADR 008):scores、asqm_quality、validation_gates、cognitive_mode。