implementation-process

Executing Plans

For capy knowledge base conventions, see capy-knowledge-protocol.md.

Overview

Load plan, review critically, execute tasks in batches, report for review between batches.

Core principle: Batch execution with checkpoints for architect review.

Review Mode

By default, review checkpoints use standard mode. The user can request isolated review mode for the entire session:

• When invoking the skill: "use isolated review" or "isolated mode"
• In tasks.md metadata: a review-mode: isolated field in the header

When set, all review checkpoints automatically use isolated variants (kk:solid-code-review:isolated, kk:implementation-review:isolated) without per-checkpoint prompting. The user can override at any checkpoint ("use standard review for this one").

The Process

Step 1: Load and Review Plan

1. Read the feature's tasks.md file to get the task list and current progress
2. Read the linked design.md and implementation.md for full context
3. Identify the next pending task (one whose dependencies are all done)
4. Capy search: Search kk:arch-decisions, kk:project-conventions, kk:lang-idioms, and kk:review-findings for context relevant to the identified task
5. Review critically — identify any questions or concerns about the plan
6. If concerns: Raise them with your human partner before starting

Step 2: Execute Sub-Task

1. Update tasks.md: set the task's status to in-progress
2. Follow the plan exactly
3. Check off subtasks (- [x]) in tasks.md as you complete them
4. Run verifications as specified; use testing-process skill

Step 3: Report

• Show what was implemented
• Show verification output
• If session-level isolated review is set: automatically use kk:solid-code-review:isolated — this handles both sub-agent and pal codereview internally with independent reviewers. Do NOT run a separate pal codereview call, as it is already included in the isolated workflow. The user can say "use standard review for this one" to override.
• Otherwise: prompt user for code-review (mention isolated mode as an option); if user responds 'yes':
  • Standard review (default): Use kk:solid-code-review skill, then run pal mcp code-review, consolidate findings
  • Isolated review (if user requests): Use kk:solid-code-review:isolated — same as above
• Based on user and code-review feedback: apply changes if needed and finalize the sub-task
• Capy index: If a non-obvious pattern or convention was established during implementation, index it as kk:project-conventions
• When completed, update tasks.md: set the task's status to done

Step 4: Continue

• Move to the next pending task in tasks.md
• Repeat until all tasks are completed

Step 5: Complete Development

After all tasks complete and verified:

• Use testing-process skill to verify and validate functionality
• Use documentation-process skill to create or update any relevant docs
• Update the feature status in tasks.md header to done

When to Stop and Ask for Help

STOP executing immediately when:

• Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
• Plan has critical gaps preventing starting
• You don't understand an instruction
• Verification fails repeatedly

IMPORTANT! Always ask for clarification rather than guessing.

When to Revisit Earlier Steps

Return to Review (Step 1) when:

• Partner updates the plan based on your feedback
• Fundamental approach needs rethinking

IMPORTANT! Don't force through blockers - stop and ask.

Remember

• Review plan critically first
• Follow plan steps exactly
• Don't skip verifications
• Use skills when the plan says to do so
• Between batches: just report and wait
• Stop when blocked, don't guess