メニュー
Discover the Spec Kitty 3.2.0 spk skill hierarchy, naming convention, legacy aliases, and the correct skill for a user intent.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | spk-meta-skill-map |
| description | Discover the Spec Kitty 3.2.0 spk skill hierarchy, naming convention, legacy aliases, and the correct skill for a user intent. |
Use this skill when the user asks what skills exist, how spk-* names are
organized, or which skill applies.
Use spk-<family>-<action-or-topic>.
Legacy family means the pre-3.2.0 spec-kitty-* compatibility skills that
remain alongside the newer spk-* hierarchy.
Families:
spk-start-*: onboarding and orientation.spk-mission-*: authoring mission artifacts before runtime execution.spk-run-*: runtime advancement, program orchestration, implementation,
review, and blockers.spk-gate-*: accept, merge, mission review, and retrospectives.spk-admin-*: setup, configuration, upgrades, dashboard/status.spk-team-*: auth, sync, tracker, connectors.spk-doctrine-*: charter, glossary, SPDD, profiles, bulk-edit policy.spk-integrate-*: APIs, CI, external automation.spk-meta-*: skill discovery and authoring.Use the reference map for the complete inventory:
references/spk-skill-map.md.
Choose the narrowest matching skill. If multiple skills match, start at the earliest lifecycle family: start, mission, run, gate, admin/team, doctrine, integrate, meta.
Recognize when a mission is a bulk edit and drive the occurrence-classification guardrail on the user's behalf. Triggers: user says any variant of "rename X to Y", "change the terminology", "migrate all occurrences", "replace across the codebase", "the X feature is now the Y feature", "sed everywhere", or any request that touches the same identifier/path/key in many files. Also triggers on gate errors mentioning "change_mode", "occurrence_map.yaml", "Bulk Edit Gate: BLOCKED", or "Bulk Edit Review: Diff Compliance". Does NOT handle: line-level semantic refactors inside one file, adding a new feature that creates new identifiers without changing existing ones, or reviewing finished missions for fidelity.
Review a fully merged Spec Kitty mission post-merge (all WPs done/approved) to verify spec→code fidelity, FR coverage, drift, risks, and security. Triggers: "review the merged mission", "post-merge mission review", "verify the completed mission", "audit the mission implementation", "mission-level acceptance review", "is this mission releasable", "final review before tagging", "cross-WP coverage audit". Does NOT handle: per-WP review during implementation (use spec-kitty-runtime-review), implement-review loop orchestration (use spec-kitty-implement-review), setup or repair (use spec-kitty-setup-doctor), or glossary maintenance (use spec-kitty-glossary-context).
Drive the canonical spec-kitty next --mission <handle> control loop for mission advancement. Load agent profiles at init, apply action-scoped doctrine context at each step boundary, and pull specific tactics/directives on demand. Triggers: "run the next step", "what should runtime do next", "advance the mission", "what is the next task", "continue the workflow", "what step comes next". Does NOT handle: setup or repair requests, purely editorial glossary or doctrine maintenance, or direct code review.
Point a local Spec Kitty CLI at Spec Kitty SaaS on Upsun (main or preview): set sync vars via use-upsun-env.sh, authenticate against Upsun Teamspace, check readiness, or drain local events.
Understand how Spec Kitty missions work: the 4 built-in mission types, how they define workflows via step contracts and action indices, how missions and work packages relate, how templates are resolved through the 5-tier chain, and how doctrine artifacts (procedures, tactics, directives) compose mission behavior. Triggers: "what missions are available", "how do missions work", "which mission should I use", "explain the mission system", "what is a mission", "change the mission", "mission templates", "step contracts", "action index", "mission procedures". Does NOT handle: runtime loop advancement (use runtime-next), setup or repair (use setup-doctor), governance (use charter-doctrine), or glossary curation (use glossary-context).
Deploy a bounded, profile-loaded adversarial review squad at an SDD point-cut (post-spec, post-plan, post-tasks, pre-merge, or an ad-hoc decision) so independent doctrine lenses converge on findings one reviewer would miss. Triggers: "deploy a squad", "adversarial squad", "post-tasks anti-laziness pass", "pre-spec investigation squad", "brownfield check", "second opinion on this design", "review squad", "run a multi-lens review". Does NOT handle: the implement-review loop (use spec-kitty-implement-review), spec/plan/tasks generation, or direct code editing by the orchestrator. It is an optional, charter/memory-activated enrichment — it never gates a mission.