一键导入
implement
Execute implementation plan step-by-step
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Execute implementation plan step-by-step
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.