dsh-codex-workflow

Implement a confirmed software feature, repair, or refactor within its current scope and architecture. Use when the expected result and verification method are clear enough to change code; do not use for read-only diagnosis or review.

Keep software-development context reliable by frequently offloading bounded exploration, research, test analysis, diagnosis, review, and isolated implementation to native subagents or separate Codex tasks, then closing or archiving them after verified handoff. Use throughout non-trivial projects, before raw evidence fills the main task, and whenever a repeated problem needs a clean context.

Run software development from the user's natural-language goals, generating and maintaining the working PRD, acceptance criteria, and development plan. Use to start or resume a project, coordinate workstreams and supporting tasks, decide what happens next, and carry an accepted milestone through implementation, verification, repair, review, and release.

Diagnose and repair a reproducible software failure without repeating the same unsuccessful patch. Use after a test, build, runtime, integration, package, or review failure has produced concrete evidence.

Convert an accepted software outcome and current project facts into the smallest executable development plan. Use when work spans multiple meaningful changes, dependencies, integration points, or recovery checkpoints; do not use merely to restate a simple edit.

Prepare and verify a user-ready software release from a known source state. Use when the user asks for a clean version, distributable archive, installer, release candidate, deployment, publication, or clarification of development versus released versions.

Verify external technical facts that materially affect an active software decision, including official platform behavior, framework compatibility, APIs, standards, open-source reference projects, and relevant implementation patterns. Use when the current project and available evidence cannot support a reliable decision or when external code may affect provenance and licensing.

Review a software change against the accepted outcome, current code, and actual verification evidence, then recommend or record whether it passes, needs repair, or is blocked according to the current context role. Use before closing a workstream or when the user requests a code or completion review.

Convert the user's natural-language software goal, feature request, complaint, screenshot, or defect report into a maintained working PRD, bounded user-visible outcome, and executable acceptance criteria. Use throughout Sakura development so Codex owns this translation by default while accepting user edits.

Verify software changes through current executable evidence, including targeted tests, type checks, builds, browser behavior, APIs, CLIs, integration, and package checks. Use after implementation, after repair, or when a reported failure must be reproduced.