plan-implement
Implement Plan
Implement the requirements in $ARGUMENTS.
If no argument provided, search for plan files in the plans/ directory and present them to the user for selection.
Critical: you must create an agent team to implement the plan. Do not try to skip this!
Step 1: Parse Plan
- Read the plan file specified in
$ARGUMENTS - Extract all tasks with their dependencies, descriptions, verification requirements, and metadata
- Parse task metadata -- extract the JSON metadata code fence from each task (see @.claude/rules/plan.md Metadata section for the required schema)
- Build a dependency graph to determine which tasks can run in parallel
Task Metadata Rules
Each task in the plan file contains a JSON metadata code fence (schema defined in @.claude/rules/plan.md Metadata section).
- Every TaskCreate call MUST include the full
metadataobject from the plan's JSON code fence - If a task is missing
skillsorverification, flag it as an error and ask the user before proceeding - Run
verification.commandbefore marking any task complete
Step 2: Setup
- Read
@.claude/rules/plan-governance.mdfor governance rules (branch/PR, git workflow, required tasks) - Read
@.claude/rules/plan.mdfor task document format - Verify branch exists -- create if needed following branch/PR rules from plan-governance.md
- Verify draft PR exists -- create with
gh pr create --draftif needed. No implementation before the draft PR exists - Determine implementer count based on the task dependency graph:
- 1-2 independent tasks → 1 implementer
- 3-5 independent tasks → 2 implementers
- 6+ independent tasks → 3 implementers (cap)
Step 3: Create Agent Team
Spawn an Agent Team with:
- Implementers (named
implementer-1,implementer-2, etc.) -- agent type:implementer, mode:bypassPermissions - Create all tasks via TaskCreate with proper
blockedByrelationships matching the plan's dependency graph - Assign the first batch of independent tasks to implementers
Use the specialized agents per @.claude/rules/plan-governance.md (Implementation Team Guidance):
| Agent | Use For | Phase |
|---|---|---|
implementer |
Code implementation with TDD (red-green-refactor) | Phase 2 |
tech-reviewer |
Technical review (correctness, security, performance) | Phase 3 |
product-reviewer |
Product/UX review (validates from non-technical perspective) | Phase 3 |
test-coverage-agent |
Writing comprehensive tests | Phase 4 |
code-simplifier |
Code simplification and refinement | Phase 4 |
coderabbit |
Automated AI code review | Phase 3 |
learner |
Post-implementation learning | Phase 5 |
The team lead handles git operations (commits, pushes, PR management) -- teammates focus on their specialized work.
Compaction Resilience
Context compaction can cause the team lead to lose in-memory state (task assignments, owner fields). Follow these rules:
- Dual owner storage -- on every TaskUpdate that sets
owner, also store it inmetadata.owner:TaskUpdate({ taskId: "1", owner: "implementer-1", metadata: { owner: "implementer-1" } }) - Re-read after compaction -- immediately call TaskList to reload all task state
- Restore missing owners -- if any task has
metadata.ownerbut noownerfield, restore it via TaskUpdate - Never rely on memory -- always call TaskList before assigning new work
Step 4: Phase 2 - Implementation
- Implementers work on assigned tasks following TDD (red-green-refactor cycle)
- Team lead monitors completion via messages from implementers
- After each task completes: team lead runs
git add <specific files>+git commitwith conventional commit message - Team lead assigns next tasks as dependencies resolve
- Continue until all implementation tasks are complete
Step 5: Phase 3 - Reviews (parallel)
Spawn review agents simultaneously:
- tech-reviewer -- agent type:
tech-reviewer, mode:bypassPermissions - product-reviewer -- agent type:
product-reviewer, mode:bypassPermissions - Invoke
/plan-local-code-reviewskill (team lead runs directly) - coderabbit -- agent type:
coderabbit:code-reviewer, mode:bypassPermissions
Wait for all reviews to complete.
Step 6: Phase 4 - Post-Review (sequential)
- Fix review findings -- re-spawn an implementer to address valid review suggestions
- Simplify code -- spawn
code-simplifieragent (agent type:code-simplifier:code-simplifier, mode:bypassPermissions) - Update tests -- spawn
test-coverage-agentto update tests for post-review changes - Verify all tasks -- team lead runs ALL proof commands from all tasks to confirm everything still works
Step 7: Phase 5 - Learning & Archive
- Collect learnings -- spawn
learneragent (agent type:learner, mode:bypassPermissions) to process task learnings - Archive the plan -- follow the Archive Procedure in @.claude/rules/plan-governance.md
- Finalize PR:
git add . && git commit -m "chore: archive <plan-name> plan" GIT_SSH_COMMAND="ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5" git push gh pr ready gh pr merge --auto --merge
Step 8: Shutdown Team
Send shutdown_request to all teammates and clean up the team.
More from codyswanngt/lisa
claude-code-action
Knowledge base for creating and configuring Claude Code Action GitHub workflows
43lisa-review-project
This skill should be used when comparing Lisa's source templates against a target project's implementation to identify drift. It validates the Lisa directory, detects project types, scans template directories, compares files, categorizes changes, and offers to adopt improvements back into Lisa. This is the inverse of lisa:review-implementation.
39lisa-integration-test
This skill should be used when integration testing Lisa against a downstream project. It applies Lisa templates, verifies the project still builds, and if anything breaks, fixes the templates upstream in Lisa and retries until the project passes all checks.
37lisa-learn
This skill should be used when analyzing a downstream project's git diff after Lisa was applied to identify improvements that should be upstreamed back to Lisa templates. It validates the environment, captures the diff, correlates changes with Lisa template directories, categorizes each change, and offers to upstream improvements.
35jsdoc-best-practices
Enforces JSDoc documentation standards for this TypeScript project. This skill should be used when writing or reviewing TypeScript code to ensure proper documentation with file preambles, function docs, interface docs, and the critical distinction between documenting "what" vs "why". Use this skill to understand the project's JSDoc ESLint rules and established patterns.
34plan-lower-code-complexity
This skill should be used when reducing the cognitive complexity threshold of the codebase. It lowers the threshold by 2, identifies functions that exceed the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to fix all violations.
23