菜单
Plan before executing. Use when task touches 3+ files, requires new folder structure, involves DB or API changes, or has step dependencies. Waits for approval before writing code.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Structured debugging workflow — diagnose before proposing fixes. Use when user says /debug, reports a bug, an error, or unexpected behavior. Forms hypotheses before touching code.
Compact the current conversation into a handoff document for a fresh agent to continue the work.
Manage persistent memory across sessions. Subcommands: save [topic] captures session learnings, recall [question] retrieves relevant context before acting, clean removes stale entries.
Review code with real engineering criteria — logic bugs, security vulnerabilities, and technical debt. Use when user says /review @file or /review to review current PR changes.
Audit AI-generated apps for security, performance, and maintainability issues. Use when user says /vibe-audit or "I generated this with AI and want to know how bad it is".
Generate a semantic commit message by reading the real staged diff. Use when the user says /commit, "make a commit", or "commit the changes". Never invents — reads the actual diff.
| name | ak:plan |
| description | Plan before executing. Use when task touches 3+ files, requires new folder structure, involves DB or API changes, or has step dependencies. Waits for approval before writing code. |
| disable-model-invocation | true |
| argument-hint | <task description> |
Plan before executing. For complex tasks that touch multiple files or require architecture decisions.
$ARGUMENTS
Understand the goal: Read the user's task. If ambiguous, ask ONE clarifying question before continuing. Done when: the goal fits in one sentence.
Explore the relevant codebase:
Propose a structured plan:
## Plan: [task name]
### Goal
[One line describing what will be achieved]
### Files to be touched
- `path/file.ts` — [what change]
- `path/other.ts` — [what change]
- [new] `path/new.ts` — [what it does]
### Steps in order
1. [First concrete step]
2. [Second step]
3. [...]
### Risks / decisions
- [Risk or trade-off the user should know about]
- [Alternative considered and why it wasn't chosen]
### Not included in this plan
- [What's out of scope and why]
Wait for approval before executing any changes. Done when: user explicitly approves ("go ahead", "looks good", etc.).
Mark the ticket InProgress: if the task is linked to an issue or ticket, mark it as in_progress now — before writing any code.
Execute the plan exactly as approved. If you discover something that changes the plan, stop and report.
After implementation: run /ak:review on the changed files before considering the task complete.