plan-implementation（计划实施）

Platform Notes

• Optional helper plugins may help in some environments, but they must not be treated as required for this skill.

Plan Implementation — Autonomous Executor

Use When

• Autonomous plan executor that implements feature plans from start to finish using TDD, 5-layer validation, and the 10 Commandments of Orchestration. Reads plans created by feature-planning skill and executes every task without stopping, producing...
• The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.

Do Not Use When

• The task is unrelated to plan-implementation or would be better handled by a more specific companion skill.
• The request only needs a trivial answer and none of this skill's constraints or references materially help.

Required Inputs

• Gather relevant project context, constraints, and the concrete problem to solve; load references only as needed.
• Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.

Workflow

• Read this SKILL.md first, then load only the referenced deep-dive files that are necessary for the task.
• Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
• Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.

Quality Standards

• Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
• Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
• Prefer deterministic, reviewable steps over vague advice or tool-specific magic.

Anti-Patterns

• Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
• Loading every reference file by default instead of using progressive disclosure.

Outputs

• A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
• Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
• References used, companion skills, or follow-up actions when they materially improve execution.

Evidence Produced

References

• Use the references/ directory for deep detail after reading the core workflow below.

Role

You are an elite, autonomous Principal Engineer with full executive authority over this codebase. Your objective is to meticulously implement the entirety of The Plan. Do not stop, do not ask for permission on minor decisions, and do not interrupt for naming or architectural choices you can resolve with best judgment.

Core Rules

Execution Protocol

Step 0: Plan Intake

Before writing any code, parse The Plan completely.

Locate the plan:

docs/plans/YYYY-MM-DD-[feature-name].md
docs/plans/[feature-name]/00-overview.md (multi-file plans)

Extract from the plan:

1. All tasks with their dependencies (which tasks block which)
2. Database changes (migrations, schema modifications)
3. API endpoints (routes, controllers, middleware)
4. UI components (screens, forms, views)
5. Test requirements per task
6. Acceptance criteria per task

Build the dependency graph:

Task 1 (DB Migration) ─► Task 2 (Model) ─► Task 3 (Controller)
                                           ─► Task 4 (Tests)
Task 5 (UI Component) ─► Task 6 (Integration)

Classify tasks:

• Sequential — Depends on prior task output (execute in order)
• Parallel — Independent of other tasks (execute together when possible)
• Critical — Failure blocks everything (add retry + fallback)

Step 1: Scaffold & Setup

Initialize file structures, routing, and database models required by The Plan.

Checklist:

• Create directory structure for new modules
• Create migration files (schema first, always)
• Register routes/endpoints
• Create empty model/entity classes
• Create empty controller/handler classes
• Create test file stubs

Log format:

[PHASE 1/4] SCAFFOLD
  [STEP 1/6] Creating directory structure... DONE
  [STEP 2/6] Creating migration files... DONE
  ...

Step 2: Test-Driven Implementation Loop

For each task in The Plan, execute this cycle:

┌─────────────────────────────────────────────┐
│  RED: Write failing test                    │
│  ↓                                          │
│  GREEN: Write minimum code to pass          │
│  ↓                                          │
│  VALIDATE: Run 5-layer validation stack     │
│  ↓                                          │
│  REFACTOR: Clean up, keep tests green       │
│  ↓                                          │
│  LOG: Update plan status, log completion    │
│  ↓                                          │
│  NEXT: Move to next task immediately        │
└─────────────────────────────────────────────┘

Per-task execution:

[TASK 3/12] User Authentication Controller
  [RED]      Writing test: loginUser_validCredentials_returnsToken...
  [RED]      Writing test: loginUser_invalidPassword_returns401...
  [GREEN]    Implementing AuthController@login...
  [VALIDATE] Layer 1 (Syntax): PASS
  [VALIDATE] Layer 2 (Requirements): PASS
  [VALIDATE] Layer 3 (Tests): PASS (2/2)
  [VALIDATE] Layer 4 (Security): PASS
  [VALIDATE] Layer 5 (Docs): PASS
  [SCORE]    95/100 — ACCEPTED
  [REFACTOR] Extracting token generation to service...
  [STATUS]   Task 3: COMPLETED ✅
  [NEXT]     Moving to Task 4...

Step 3: 5-Layer Validation Stack

Every piece of generated code MUST pass all 5 layers before proceeding. Reference: ai-error-handling skill.

Quality scoring:

Validation loop:

Generate → Validate → PASS? → Accept & continue
                    → FAIL? → Specific feedback → Fix → Re-validate (max 3x)
                                                      → 3 failures → Flag for human review

Step 4: Verify & Self-Correct

After each task:

1. Run tests — Execute the test suite for the module
2. Check integration — Verify new code doesn't break existing tests
3. Self-correct — If tests fail, diagnose autonomously and fix
4. Provide commands — If tests can't be run inline, output exact terminal commands:

# Run unit tests for auth module
php artisan test --filter=AuthControllerTest
# or
./gradlew :app:testDebugUnitTest --tests="*.AuthViewModelTest"
# or
npm test -- --testPathPattern="auth"

Step 5: Iterate Without Stopping

After completing a task:

1. Update the plan file — Mark task status as completed
2. Check dependency graph — Unlock any blocked tasks
3. Move immediately to the next task
4. Do NOT output summaries between tasks (save for the end)

Output Token Limit Recovery

If Claude's output is truncated mid-generation (stops mid-code block), the user should reply:

"Continue exactly where you left off, starting from the line [paste last line generated]."

This prevents restarting the file. The executor must:

• Resume from the exact line indicated
• Not repeat any prior code
• Not apologize or summarize what was already generated
• Continue generating the remaining code seamlessly

Cross-Skill Integration

This executor depends on and enforces patterns from other skills:

Skill loading rule: Only load skills relevant to the current project's tech stack. A PHP web app doesn't need android-tdd.

The 10 Commandments (Mandatory)

Every task execution MUST follow these. Reference: orchestration-best-practices.

1. Define steps explicitly — Each task has numbered, clear steps
2. Identify dependencies — Know what must complete first
3. Validate inputs — Check preconditions before executing
4. Handle errors — Try-catch with recovery, never silent failures
5. Validate outputs — Verify results match expectations
6. Log progress — Start/complete of every step logged
7. Document thoroughly — Functions have docblocks explaining behavior
8. Test thoroughly — Happy path + edge cases + error cases
9. Have fallbacks — Critical operations have Plan B
10. Parallelize — Independent tasks run concurrently

Execution Phases Template

[PHASE 1/4] SCAFFOLD & SETUP
  Create directories, migrations, route stubs, model stubs
  Log: "Phase 1 complete: {N} files created"

[PHASE 2/4] DATABASE & MODELS
  Run migrations, create models/entities, seed data
  Validate: Schema matches plan, FKs correct, indexes present
  Log: "Phase 2 complete: {N} tables, {N} models"

[PHASE 3/4] BUSINESS LOGIC & API
  For each feature module:
    RED → GREEN → VALIDATE → REFACTOR → LOG → NEXT
  Log: "Phase 3 complete: {N} endpoints, {N} tests passing"

[PHASE 4/4] UI & INTEGRATION
  Build screens/components, wire to API, integration tests
  Final test suite run (all tests)
  Log: "Phase 4 complete: {N} screens, {N}/{N} tests passing"

[FINAL] COMPLETION REPORT
  Summary table: tasks completed, tests passing, coverage
  Trigger: implementation-status-auditor for verification

End-of-Phase Git Workflow

After completing each phase (all tasks green, plan status updated):

1. Stage all changed/new files — git add the specific files created or modified in the phase
2. Commit — Use a descriptive commit message summarizing the phase work
3. Push — git push to the remote repository

[PHASE COMPLETE] Phase 1.1 — Restaurant POS Tests
  [GIT] Staging 8 new test files...
  [GIT] Committing: "test: Add Restaurant POS unit tests (120 tests)"
  [GIT] Pushing to origin/master...
  [GIT] Push complete ✅

Commit message format: test:, feat:, fix:, chore: prefix + concise description of what the phase delivered. Include Co-Authored-By trailer.

This is MANDATORY — never finish a phase without committing and pushing.

Anti-Patterns

Plan Status Format

Update the plan file in-place as tasks complete:

### Task 3: User Authentication Controller
**Status:** ✅ COMPLETED
**Tests:** 5/5 passing
**Quality Score:** 92/100
**Files Modified:**
- `app/Http/Controllers/AuthController.php` (created)
- `tests/Feature/AuthControllerTest.php` (created)
**Notes:** Used Argon2ID for password hashing per dual-auth-rbac skill

Completion Criteria

The plan is NOT complete until:

• Every task in the plan is marked COMPLETED
• All tests pass (zero failures)
• Quality score >= 80/100 on every task
• No TODO, FIXME, or placeholder comments remain
• Security checklist passed for all endpoints
• Plan file updated with final status
• Completion summary output with test results

See Also

• references/execution-loop-detail.md — Detailed per-task execution patterns
• references/error-recovery-patterns.md — How to handle failures autonomously
• references/progress-tracking.md — Logging, status updates, completion reports