Software Development Workflow

Goal

Make coding agents behave like careful software engineers: define what is being changed, understand the existing system, make focused edits, debug from evidence, handle security risk explicitly, and only claim completion after verification.

Core Principle

Use the smallest workflow that can safely finish the task, but do not confuse the smallest workflow with the cheapest patch. For non-trivial or durable work, choose the best-fit solution for the task's risk, lifetime, and project architecture.

Do not load every reference by default. Load only the references/ files whose routing conditions match the current task.

This skill coordinates one software change from intent to evidence. It does not replace project knowledge, external research, skill authoring, or handoff skills; it calls or yields to them when their trigger is stronger.

Use When

• The user asks to build, fix, refactor, test, review, or prepare code changes.
• The task changes behavior, touches multiple files, or depends on project conventions.
• A bug, failing test, broken build, runtime error, or unexpected behavior appears.
• The work has security, privacy, compatibility, migration, public API, or release risk.
• The agent is about to say a coding task is done.

Do Not Use When

• The task is external/current research only; use research-to-knowledge.
• The task is durable repository knowledge work only; use project-knowledge.
• The task is creating, splitting, securing, or evaluating skills; use write-agent-skill.
• The task is only a temporary handoff; use write-agent-handoff.
• The task is a tiny local edit with obvious scope, no behavior change, and no need for workflow judgment.

Existing Skill Order

This skill does not replace the core starter skills.

1. If the request changes skills, use write-agent-skill instead of this skill.
2. If project conventions, architecture, workflows, decisions, domain terms, or known gotchas may matter, use project-knowledge before coding.
3. If current external documentation, technology choice, dependency choice, or source-backed comparison may materially affect the implementation, use research-to-knowledge before coding.
4. If the request needs transfer state, use write-agent-handoff after or instead of this skill.

Reference Router

Load references from references/ only under these conditions:

If several references apply, read them in workflow order: task contract, context plan, implementation loop or debugging loop, security gate when relevant, then done gate.

Workflow

1. Classify the request.

• Tiny: obvious one-file mechanical edit, no behavior/risk. Make the edit and run the narrowest sensible check.
• Standard: behavior or multi-file change. Use the task contract, context plan, implementation loop, and done gate.
• Debug: failure or bug. Use the debugging loop first; return to implementation only after the root cause is understood.
• High risk: auth, privacy, migrations, public APIs, release, destructive actions, or irreversible data. Use the security gate and ask only when a decision is genuinely blocking.
• Current-sensitive or systemic: framework/library/API/dependency/security/build/release choices, shared invariants, or project-wide patterns. Use research-to-knowledge or context-plan.md before committing to a local implementation.

1. Pick the initial route. For non-trivial work, choose at least one of task contract, context plan, debugging loop, or security gate before editing; always use done gate before completion claims.
2. State the active route briefly when it helps the user understand why you are reading or verifying something.
3. Keep context tight. Prefer rg, targeted file reads, existing docs, and exact commands over broad repository scans.
4. Keep changes scoped to the contract, not artificially local. If the correct owner is shared or the new pattern must stay consistent across sibling flows, update the in-scope affected places or name the scope expansion before widening.
5. Verify after meaningful changes and before completion claims.
6. If durable knowledge changed, route the update through project-knowledge.

Outputs

For normal coding tasks, finish with:

• What changed.
• What verification ran and what it proved.
• Anything not verified, with the reason.
• Follow-up risks only when they are real and related to the task.

Failure Modes