# SKILL_CATALOG

## Objective
Map role capabilities to reproducible, portable skills and verification checks.

## Portable Skill Contract

A skill is production-ready only if:

1. `SKILL.md` is the canonical portable source of truth.
2. Frontmatter description says what the skill does and when to use it.
3. `SKILL.md` includes:
   - canonical use cases
   - Inputs
   - Workflow/Steps
   - Outputs/Artifacts
   - Failure Policy/Troubleshooting
4. The skill exposes a validation surface:
   - trigger canaries
   - at least one functional path with expected evidence
5. Long or reference-heavy skills use `references/` for progressive disclosure.
6. Any files under `agents/` are optional client overlays only.
7. Client overlays must mirror the portable contract, not redefine it.

## Building Blocks

| Skill | Primary Role(s) | Entry Criteria | Output Contract |
|---|---|---|---|
| `problem-triage` | research, spec, ops | before creating or patching a skill | `PROBLEM_TRIAGE.md` route decision |
| `skill-auditor` | skeptic, research, ops | before remediation or release of skill changes | `SKILL_AUDIT_REPORT.md` |
| `state-auditor` | skeptic, ops | before/after each cycle | state coherence report |
| `schema-forge` | spec, research | new/changed interface | semver schema + changelog |
| `handoff-lint` | ops, qa | before handoff commit | pass/fail lint report |
| `memory-curator` | memory | snapshot age > 24h or high drift | reconciled memory artifact |
| `risk-quant` | skeptic, security | any new risk | probability-impact table + mitigation state |
| `eval-harness` | eval, qa | release candidate or major changes | eval run output + regression diff |
| `incident-commander` | observability, ops | SLO breach or gate storm | incident timeline + owner map |
| `landing-review-watcher` | release, ops, qa | active review / CI / merge loop | `LANDING_REVIEW_WATCH.md` |
| `release-sentry` | release | promotion request | release decision payload |

## Audit Questions

1. Does the skill still make sense with no `agents/*` overlay present?
2. If overlays exist, are they clearly optional and parity-only?
3. Does the description contain trigger language rather than generic capability labels?
4. Are use cases concrete enough to distinguish this skill from adjacent ones?
5. Does the skill expose validation evidence rather than pure prose?
6. Should the skill be split into `references/` to stay lean?