with one click
implement
Execute implementation plan step-by-step
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
Execute implementation plan step-by-step
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Argus — all-in-one information gathering & reconnaissance toolkit. 135 modules covering network infrastructure, web app analysis, and security/threat intelligence. Use for domain recon, subdomain enum, SSL analysis, tech stack detection, vulnerability scanning, and OSINT.
Manage secrets via Bitwarden CLI (bw). Use when pulling secrets into a shell session, creating/updating Secure Notes from .env files, listing vault items, or setting up Bitwarden on a new machine. Secrets live in Bitwarden, get loaded into memory on demand, and die with the shell session — no files on disk.
Develop a thorough, step-by-step specification for a given idea
Set up a recurring build tracker cron job for any GitHub repo. Runs a zero-LLM shell script to detect stale PRs, stale assigned issues, and phase progress, then posts to a Discord channel only when there's something actionable. Use when asked to "track this build every N hours", "prod agents on a project", "set up a build monitor", "watch this repo for stale work", or similar. The tracker is cheap to run — script does all the work, the agent only speaks when findings exist.
Run long-running coding tasks in cloud environments (Claude Code or Codex), with session teleporting and automatic PR creation.
Delegate coding tasks to subagents or run Claude Code/Codex in tmux sessions. Use the Task tool for focused multi-step coding work. Use tmux for long-running interactive sessions, parallel worktree-based fixes, and PR reviews. NOT for simple single-file edits — do those directly.
| name | implement |
| description | Execute implementation plan step-by-step |
| user-invocable | true |
You are tasked with implementing an approved technical plan from plans/. These plans contain phases with specific changes and success criteria.
When given a plan path:
After reading the plan, check for wave metadata:
## Phase sections for <!-- wave: commentsExecute phases grouped by wave number:
Single-phase wave: Execute inline (same as sequential -- avoids spawn overhead).
Multi-phase wave: Spawn parallel Task agents:
For each phase in this wave, spawn:
Task(
prompt: "Implement Phase {N}: {title}
Plan: {plan_path}
Phase: {N} only
Read the plan and implement ONLY Phase {N}.
Follow Changes Required exactly.
Run Success Criteria checks.
Update plan checkboxes when done.
Files you own (ONLY modify these): {files from wave comment}
Report: what was implemented, tests passing, any deviations.",
subagent_type: "general-purpose"
)
Wait for ALL agents in the wave before starting next wave.
On failure: Stop and report:
Wave {N} execution:
Succeeded: Phase {X}, Phase {Y}
Failed: Phase {Z} -- {reason}
Options:
1. Retry failed phase only
2. Continue to next wave (skip failed)
3. Fall back to sequential for remaining phases
After each wave: Verify no file ownership conflicts via git diff --name-only.
If no plan path provided, ask for one.
Plans are carefully designed, but reality can be messy. Your job is to:
When things don't match the plan exactly, think about why and communicate clearly. The plan is your guide, but your judgment matters too.
If you encounter a mismatch:
Issue in Phase [N]:
Expected: [what the plan says]
Found: [actual situation]
Why this matters: [explanation]
How should I proceed?
For each phase in the plan:
Understand the Phase:
Implement Changes:
Verify as You Go:
Update Progress:
Update project state (if .planning/ exists):
.planning/STATE.md with progress.planning/phases/{phase}/SUMMARY.md if it exists.planning/REQUIREMENTS.mdAfter implementing a phase:
Don't let verification interrupt your flow - batch it at natural stopping points.
When you encounter a checkpoint marker in the plan:
[CHECKPOINT:human-verify]:
[CHECKPOINT:decision]:
[CHECKPOINT:human-action]:
Automation-first rule: Before creating any checkpoint, verify Claude cannot perform the action itself via CLI, API, or file operations. Checkpoints verify after automation, never replace it.
Follow the plan's testing strategy:
First, verify your understanding:
Debug systematically:
If stuck, document and ask:
If the codebase has evolved since the plan was written:
If the plan has existing checkmarks:
Maintain Forward Momentum:
Communicate Progress:
Quality Over Speed:
Document Deviations:
Before considering implementation complete:
Remember: You're implementing a solution, not just checking boxes. Keep the end goal in mind and maintain forward momentum.