Phased Delivery Workflow

This skill is rigid. Follow the phases in order. Do not skip ahead unless the user explicitly approves an exception.

Goal

Turn a coding request into a gated delivery flow:

1. requirement understanding and restatement
2. technical approach confirmation
3. implementation plan confirmation
4. minimal-scope implementation
5. review and risk-fix loop
6. safe testing
7. documentation update
8. scoped commit

For long-running work, keep the user informed at each phase boundary.

Phase 0: Load Local Rules First

Before Phase 1:

• read repository or workspace rules such as AGENTS.md, CLAUDE.md, GEMINI.md, or local runbooks if they exist
• map stricter local rules into the workflow before you restate the requirement
• if local rules conflict with this skill, follow the stricter rule or the user's explicit instruction

Do not assume the same repository conventions across projects.

Phase Transition Rules

• If requirement understanding is incomplete, stay in Phase 1.
• If the technical approach reveals a requirement gap, return to Phase 1 and restate the newly discovered gap.
• If implementation reveals the approved plan is no longer valid, pause and go back to Phase 3 with a revised plan.
• If review reveals an approach-level flaw rather than a coding bug, return to Phase 2 instead of patching locally.
• If testing reveals behavior outside the approved requirement, stop and ask whether to treat it as scope expansion.

Output Modes

Default mode is strict.

Strict mode

Use for medium or large work, business-rule changes, data consistency logic, state transitions, integrations, risky fixes, refactors, and anything likely to need more than one file or one verification step.

Compact mode

Use only when all of the following are true:

• the task is tiny and low risk
• the expected change set is very small, such as one file or one tightly scoped change area
• there is no schema change, no data migration, no environment or configuration risk, no external integration risk, and no destructive operation
• the user has explicitly agreed that a compact response format is acceptable

Do not skip phases. Compress them.

Compact mode still requires:

• requirement restatement
• technical approach confirmation
• plan confirmation
• implementation
• review
• testing
• documentation update

Use short output blocks, not full writeups.

Phase 1: Requirement Restatement

Before discussing solutions or code:

• restate the requirement back in numbered points
• separate current behavior, expected behavior, boundaries, affected modules, data touchpoints, and out-of-scope items
• call out every ambiguity, contradiction, or missing prerequisite
• ask targeted clarification questions only for unresolved points

Do not propose technical solutions yet.

Business-rule tasks

If the task involves business rules, time ranges, states, snapshots, main-table vs record-table behavior, cache consistency, historical replay, or merge/split logic:

• convert the requirement into scenario-style bullets or a draft scenario matrix
• distinguish current-effective, future-effective, expired, disabled, and exceptional states when relevant
• state which data artifacts are expected to change and which must remain untouched

Output shape

Use this structure in the user's current language:

1. your understanding of the requirement
2. current behavior
3. expected behavior
4. boundaries and impact scope
5. points still needing confirmation

Only move on after the user confirms the understanding is correct.

Phase 2: Technical Approach

After the requirement is confirmed:

• propose a technical approach
• include touched modules, files, interfaces, and data paths
• describe handling for main tables, record tables, cache, external systems, rollback concerns, and environment boundaries when relevant
• identify the main risks and validation strategy

Do not produce a coding plan yet.

Output shape

Use this structure in the user's current language:

1. technical approach
2. change scope
3. data and cache handling
4. risks
5. validation approach
6. ask for confirmation of the approach

Only move on after the user confirms the approach.

Phase 3: Implementation Plan

After the approach is confirmed:

• break the work into concrete steps
• list expected file touch points
• include validation steps and documentation updates
• keep the plan minimal and execution-oriented

Output shape

Use this structure in the user's current language:

1. implementation plan
2. expected files to touch
3. validation steps
4. documentation updates
5. ask for confirmation of the plan

Only move on after the user confirms the plan.

Phase 4: Implementation

When coding:

• enforce minimal-scope changes
• do not make unrelated cleanups without user approval
• do not revert others' work
• keep configuration changes out unless explicitly required and approved
• make the smallest change set that satisfies the confirmed plan

Before editing files, briefly state what you are about to change.

If you discover additional issues:

• stop
• classify them as blocker, adjacent issue, or future follow-up
• ask before expanding scope

Phase 5: Review and Risk-Fix Loop

After implementation:

• review against the confirmed requirement, approach, and plan
• list findings first, ordered by severity
• focus on behavior gaps, regression risks, missing validation, cache/data consistency, safety issues, and missing docs/tests
• ask the user which findings must be fixed now

After fixes, review again. Repeat until the user confirms there are no more required risk fixes.

Findings buckets

When possible, group findings into:

• 必须修复
• 需要你确认
• 可接受残留

Output shape

1. Findings
2. Open questions or assumptions
3. Short change summary

If there are no findings, state that explicitly and mention residual testing gaps.

Phase 6: Safe Testing

After the review loop:

• create or update repeatable test scripts or automated tests when feasible
• run the highest-value validation ladder that is available

Preferred validation ladder

1. static checks or smoke checks
2. compile or build verification
3. targeted automated tests
4. integration or script-based verification
5. SIT queries, simulated data, or non-destructive end-to-end checks
6. browser validation for frontend work

Safety rules

• use SIT only when environment-based validation is needed
• you may query SIT data and use mock or simulated data
• do not touch production data
• never perform destructive operations such as dropping databases, dropping tables, truncating shared data, or mass destructive updates

Always state:

• what you tested
• what passed
• what you could not test
• what still depends on manual or downstream validation

Phase 7: Documentation Update

Every change needs documentation updates, even small fixes.

Update the smallest relevant documentation set:

• business rule docs
• API docs
• workflow or runbook docs
• validation script docs

If no doc was updated, explain why that would violate the workflow and correct it.

Phase 8: Scoped Commit

Commit only after:

• requirement is confirmed
• approach is confirmed
• plan is confirmed
• review loop is closed
• testing is done
• docs are updated

Before commit:

• show or inspect the staged file set
• remove unrelated files from the commit scope
• exclude local config changes, logs, temp files, build artifacts, and unrelated workspace changes unless explicitly approved

Commit only files related to the task.

Operating Rules

• Prefer concise checkpoints between phases.
• If blocked, stop and ask rather than guessing.
• If the user provides a spec link or document, read it before restating the requirement.
• If the task is large, keep a checklist or plan updated as you progress.
• If the repository already has stricter local rules, follow those stricter rules.

Companion Resources

• Read references/checklists.md when you need a concrete per-phase checklist.
• For structured request intake, use a local request template if the repository has one.
• For repeatable validation, prefer repository scripts over ad hoc command sequences.