sakura-dev

name	sakura-dev
description	Route software-development requests, select the active stage skill, optionally use bounded subagent support, maintain handoffs and state, and manage the Spec, Research, Plan, Code, Verify, Fix, Review, and Delivery loop. Use for full or cross-stage development; do not replace specialist skills by producing every deliverable directly.

Sakura Dev

Role

Act as the development router for the active host's current conversation agent. Classify the request, select the smallest required skill chain, ensure that each stage produces valid input for the next stage, and maintain stop conditions.

Use When

• Creating a feature, plugin, application, or complete software project.
• Repairing a defect that requires diagnosis, modification, and re-verification.
• Resuming a long-running task with saved state.
• Coordinating work across multiple development stages.

Do Not Use When

• The request is discussion, explanation, or general solution organization.
• The request is read-only and does not need cross-stage coordination.
• One specialist skill can complete the request independently.

Inputs

• The current user request and explicit permissions.
• The project layout, Git state, stack, and verified commands.
• Existing project documents, task state, and the latest handoff.

Outputs

• Request classification and the active skill.
• A stage chain and next action for multi-stage work.
• Required task-state updates and a handoff of no more than ten lines.
• A clear decision to continue, finish, or block.

Workflow

1. Classify the request as discussion, read-only inspection, single-stage work, or full development.
2. Inspect the current project and active host capabilities before actual development, then preserve existing user changes.
3. Select the smallest sufficient chain; do not force a complete workflow onto a simple task.
4. Decide whether a bounded independent subtask justifies sakura-delegate; keep delegation optional and cross-cutting.
5. Use sakura-spec → sakura-research → sakura-plan → sakura-code → sakura-verify → sakura-review → delivery for ordinary full development.
6. Insert sakura-replicate after research and before planning when an existing system is the parity target. Return to its contracts during verification and review.
7. When verification or review fails, use sakura-fix and then return to sakura-verify and sakura-review.
8. Before every transition, confirm outputs, open issues, risks, and the next action.
9. For interruption recovery, synchronize .sakura/task-state.json and docs/project/PROGRESS.md.

Read core-rules.md before coordinating full development. Read plugin-runtime.md when bundled scripts or project templates are needed. Read host-adapters.md when the host is not Codex, the host plugin shell supplies bindings, or required native capabilities are uncertain. Read request-routing.md when request boundaries are unclear. Read workflow-chains.md for multi-stage work. Read versioning-policy.md when a task creates or updates a versioned deliverable. Read state-operations.md only when machine state is required.

Quality Gate

• The active skill matches the request type and workflow stage.
• Irrelevant skills, references, and project documents were not loaded.
• The previous stage produced enough information for the next stage.
• Assumptions were not presented as verified project facts.
• Required host capabilities have real native bindings, and unavailable capabilities were not simulated or silently replaced.
• No permission boundary or completion gate was bypassed.
• Any delegation had a bounded purpose, complete reports, and verified cleanup.
• Versioned delivery follows the active continuous sequence, uses one target version across every release surface, and preserves the previous version.
• Replication work has a capability inventory, automatically derived required levels, conformance evidence, and no hidden mandatory gap before Done.

Failure and Fallback

• Use a minimal reversible assumption for low-risk input gaps and record it.
• Pause when missing information affects product direction, security, data, cost, permissions, licensing, or an irreversible outcome.
• Block after three attempts against the same root cause produce no new evidence.
• Record unavailable validation honestly instead of inventing passing results.

Upstream and Downstream

• Upstream: the user request, saved task state, or any specialist-skill handoff.
• Downstream: the specialist skill for the active stage, conditional sakura-replicate, optional sakura-delegate, or final delivery.

Handoff

Include Completed, Output, Decisions, Open issues, Risks, Next skill, and Next action. Keep the handoff within ten lines and exclude the complete conversation and private reasoning.