tapania

Bootstrap .grimoire/ from an existing codebase — reverse-engineer vision, schools, taxonomy, and glossary from code

Expand a single branch of the specification tree with child capabilities

Analyze a third-party library or service and map its capabilities, constraints, and conflicts onto the specification tree

Enforce sealed wards and structural gates — the sole blocking authority in the Grimoire pipeline

Define governance schools with sealed/advisory wards and scoring criteria for evaluating suggestions

Compute critical paths, bottleneck nodes, and effort ranges for reaching a target node in the specification tree

Analyze the specification tree for structural problems and propose merges, splits, reparents, and prunes

Compare estimated vs actual effort after a slice ships — surface bias patterns and propose tree calibration updates

Execute implementation tasks with quality and awareness. Use when: (1) After TASKS phase in 5D-SDD workflow, (2) Tasks are defined and sequenced, (3) User is ready to write code, (4) User asks to 'implement,' 'build,' or 'code' a task. This phase produces working code while maintaining connection to spec intent.

Analyze the gap between current state and specification to identify all required changes. Use when: (1) After SPEC phase in 5D-SDD workflow, (2) Spec exists and implementation is about to begin, (3) User asks 'what needs to change' or 'what's the delta,' (4) Assessing scope of work. This phase prevents surprise discoveries during implementation.

Pre-development orientation and assumption mapping for spec-driven development. Use when: (1) Starting a new feature or project, (2) User says 'let's build X' without prior analysis, (3) Beginning any 5D-SDD workflow, (4) User wants to 'think through' an idea before planning. This phase prevents wasted effort by surfacing hidden assumptions and identifying all relevant domains before committing to a direction.

Convert expanded thinking into a concrete, multi-perspective plan. Use when: (1) After SPAR phase in 5D-SDD workflow, (2) User is ready to define what will be built, (3) User asks to 'write up the plan' or 'document what we're building,' (4) Transitioning from exploration to commitment. This phase creates the authoritative description of intent before technical specification.

Stress-test the plan through adversarial review and edge case analysis. Use when: (1) After PLAN phase in 5D-SDD workflow, (2) User wants to 'validate,' 'review,' or 'check' a plan, (3) Before committing significant resources to implementation, (4) Plan exists but hasn't been challenged. This phase catches plan-level errors before they become code-level errors.

Extract learning from completed work to improve future cycles. Use when: (1) After VERIFY phase shows feature complete, (2) End of development iteration, (3) User asks for 'retrospective,' 'lessons learned,' or 'what went well/wrong,' (4) Before starting next major feature. This phase prevents repeating mistakes and compounds learning.

5D Spec-Driven Development - A complete methodology for building software through structured phases. Use when: (1) User wants to build something non-trivial, (2) User mentions '5D' or 'spec-driven development,' (3) Starting a new project or feature that needs careful planning, (4) User wants a structured approach to development. This skill orchestrates the full workflow across 10 phases from orientation to reflection.

Structured sparring to challenge and expand thinking before planning. Use when: (1) User has an idea but hasn't stress-tested it, (2) After ORIENT phase in 5D-SDD workflow, (3) User asks to 'think through,' 'challenge,' or 'poke holes' in an idea, (4) User seems certain too early—needs perspective expansion. This phase prevents building the wrong thing by forcing multi-perspective examination.

Break predictable writing patterns through systematic generation of multiple alternatives. Forces exploration beyond typical responses into genuine creative territory. Auto-triggers when user requests you to be creative.