Menú
Recognize bulk-edit missions and apply occurrence classification guardrails before modifying many matching instances.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | spk-doctrine-bulk-edit |
| description | Recognize bulk-edit missions and apply occurrence classification guardrails before modifying many matching instances. |
Use this skill when the user asks for a broad rename, replace, migration, classification, or other multi-occurrence edit.
For detailed DIRECTIVE_035 handling, use
spec-kitty-bulk-edit-classification when available.
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).
Discover the Spec Kitty 3.2.0 spk skill hierarchy, naming convention, legacy aliases, and the correct skill for a user intent.
