SuperAPI AI Directory

curate-skills

General & other

View repository

Updated 10-16 01:35

About this skill

Skill: Planning skill

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):

  1. ✅ Each skill's SKILL.md has been scanned and annotated has_output_contract: true|false
  2. ✅ Each skill's agent.yaml contains the acceptance_criteria field (array, empty allowed)
  3. ✅ status is derived according to the rules and written back to agent.yaml
  4. ✅ Overlaps are filled into owner/repo:skill-name in the form overlaps_with
  5. ✅ Repository-level skills/SKILL_INVENTORY.md is 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 contract or ## 附录:输出合约/合同/契约)
  • 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.md generation

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

  1. Scan: List all skill directories under skills_directory All skill directories under
  2. Detect output contract: grep each skill's SKILL.md; matching any of the following is considered has_output_contract: true:
    • ## Appendix: Output contract
    • ## 附录:输出合约
    • ## 附录:输出合同
    • ## 附录:输出契约
  3. Read/initialize acceptance_criteria: Read from agent.yaml; if it does not exist, initialize to an empty array
  4. Derive status:
    • validated ← has_output_contract == true AND len(acceptance_criteria) >= 1
    • experimental ← otherwise
    • archive_candidate ← only manually set by the maintainer; this skill does not actively transition it
  5. Overlaps and positioning: Assign overlaps_with(owner/repo:skill-name form) and market_position(differentiated / commodity / experimental)
  6. Write back: Update each skill's agent.yaml (status, has_output_contract, acceptance_criteria, overlaps_with, market_position); normalize README.md
  7. 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-name list, this repository's format matches other repositories; leave empty if none []
  • market_position:
    • differentiated: clearly differentiated, minimal overlap, unique value in the inventory
    • commodity: general-purpose capability, overlaps with multiple skills
    • experimental: 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.md or 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_gates was 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-design or 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-name format
  • 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_gates fields 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.md including 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) >= 1
  • experimental ← otherwise
  • archive_candidate ← maintainer manual setting only

Prohibited fields(removed by ADR 008):scores、asqm_quality、validation_gates、cognitive_mode。