Use this skill when wiring two completed modules together to satisfy a parent contract, especially in a compartmentalised setting. Trigger this whenever the user has two implemented modules (each with its manifest) and a parent contract that says how they should compose, when the user asks to "compose these modules", "wire these together", "integrate A and B", or "build the parent module from these two children". This skill is deliberately mechanical — it favours faithful contract-to-contract wiring over creative integration, and it re-raises any genuine mismatch back up the composition tree rather than papering over it. Suitable for cheaper / smaller models because the work is structurally constrained.
Use this skill after a design document exists and before any module is implemented. It takes a design doc and derives per-module contracts (manifests) that are complete enough for an implementor working in isolation to build each module correctly without seeing the rest of the system. Trigger this whenever the user has a design doc and is about to start implementation, when the user asks to "derive contracts", "produce manifests", "split this design", or "prepare modules for implementation". Also trigger when an existing system needs its modules' contracts reverse-engineered before further compartmentalised work. This skill is the bridge between system-level design and isolated implementation.
Use this skill before writing any non-trivial code, especially when starting a new feature, service, or codebase. It produces a structural design document that commits to module boundaries, contracts, and data shapes BEFORE implementation begins. Trigger this whenever the user describes building something new, asks to "build", "create", or "implement" a system or feature larger than a single function, or whenever the conversation is about to move from discussion into code. Also trigger if the user mentions architecture, system design, planning, or wanting to "think through" a build before coding. Especially important for AI-generated codebases where unconstrained generation tends to sprawl into accidental complexity.
Use this skill when running a Taniwha build from the main Claude Code session. The skill turns the main session into a thin, mechanical executor that follows instructions from ephemeral orchestrator subagents. Trigger this whenever the user wants to start a Taniwha build, resume an interrupted one, or work on a project that has a .taniwha/ directory. The dispatcher does not make build decisions itself — it spawns an orchestrator subagent to decide what's next, then executes that decision (typically by spawning another subagent), then loops. Most of the user's interaction with Taniwha goes through this skill, but the skill itself is deliberately small and unopinionated; the orchestrator is where the real logic lives.
Use this skill when implementing a single module against a contract manifest, especially in a compartmentalised setting where the implementor should NOT see the rest of the system. Trigger this whenever a manifest exists and the user wants to implement that module, asks to "implement this module", "build against this contract", or hands over a manifest with a request to write the code. Also trigger this whenever code is being written against a defined interface and the user wants disciplined, contract-faithful implementation rather than free-form generation. The skill enforces strict adherence to the contract, refuses scope expansion, and surfaces ambiguity as a re-raise instead of guessing.
Use this skill when running as an ephemeral orchestrator subagent for a Taniwha project. The skill instructs the agent to read project state from disk, decide the single next action the dispatcher should take, write that decision back to disk, and exit. Trigger this whenever the dispatcher has invoked an orchestrator subagent — i.e., when the agent is being asked "what should happen next in this Taniwha build?" The skill assumes filesystem state at .taniwha/ following the Taniwha state layout, and assumes the agent will not run again with the same context (every invocation is fresh). This skill is what makes the build progress; without it, no decisions get made.
Use this skill when verifying that a completed Taniwha implementation or composition satisfies its contract's acceptance criteria. The verifier reads the contract, the implementation's source files, and the project context, then writes its own tests against the contract's acceptance criteria, runs them, and reports pass/fail per criterion. Trigger this whenever an implementation or composition has been produced and the orchestrator is about to mark it current. The verifier is a separate role from the implementor specifically so that contract satisfaction is checked by an agent that did not write the code — implementor self-reports are not verification.