| name | sakura-code |
| description | Implement the smallest safe and verifiable code change from a confirmed task package while following the current architecture and coding conventions. Use for feature, repair, and refactoring implementation; do not use for requirement definition, evidence-free repair, or final completion decisions. |
Sakura Code
Role
Implement the active milestone within its approved scope and hand a verifiable change to the verification stage.
Use When
- The specification, acceptance contract, and current task package are clear.
- The plan defines the allowed-change scope and validation method.
- A verified root cause requires a code correction.
Do Not Use When
- The user requested only inspection, explanation, diagnosis, or review.
- Requirements, technical constraints, or the allowed scope remain materially unclear.
- The active stage is only test execution or completion judgment.
Inputs
- The current milestone, allowed-change scope, and related acceptance items.
- The existing architecture, coding conventions, dependencies, and user changes.
- Confirmed technical constraints or a verified repair root cause.
Outputs
- Minimal, local, reviewable code and test changes.
- A summary of changed behavior and affected files.
- Verification commands and expected results for
sakura-verify.
Workflow
- Read the actual code, dependencies, and call paths involved in the task.
- Identify and preserve unrelated existing user changes.
- Implement the smallest working vertical slice or repair.
- Follow existing project patterns for input, state, errors, and security boundaries.
- Add or update the most relevant tests for changed behavior.
- Run the nearest fast check.
- Review the final diff and remove debug residue and unrelated changes.
When external projects informed the feature, implement from the independent behavior specification and current project constraints. Do not copy or closely translate external source code, tests, documentation, assets, branding, distinctive text, or unique visual expression.
When replication applies, implement the active capability contract at its required level. Do not replace a required protocol or runtime mechanism with a visual simulation, static registry, mock integration, or stubbed lifecycle while reporting the capability as complete.
When running as a delegated isolated writer, modify only the declared worktree and write scope. Return a structured report to the parent; do not update task state, project progress, durable decisions, final review, or completion.
Read coding-style.md before coding and apply only the sections relevant to the current stack and task.
Quality Gate
- Every change belongs to the current task package.
- Public interfaces and supported behavior did not change unintentionally.
- No unnecessary dependency, abstraction, configuration layer, or bulk formatting was added.
- Error paths, edge inputs, and sensitive data receive appropriate handling.
- The implementation does not create false success by weakening or bypassing validation.
- External functionality was implemented independently, or every reused protected artifact has an approved compatibility decision and required conditions.
- A replication implementation does not lower the required level or hide an approximation.
- A delegated implementation remains isolated and identifies its exact baseline and changed files.
Failure and Fallback
- If actual code invalidates the plan, stop expanding the change and return to
sakura-plan.
- If a critical API or platform fact is missing, return to
sakura-research.
- If a failure exists but the root cause is unclear, hand it to
sakura-verify for a failure record.
- Pause when the next step requires an unauthorized external or destructive operation.
Upstream and Downstream
- Upstream:
sakura-plan, or sakura-fix after a confirmed root cause.
- Downstream:
sakura-verify.
Handoff
Include the completed task, changed files, behavior change, unfinished items, risks, the most relevant verification commands, and the next skill. Do not claim the complete task is done.