القائمة
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 ويثبّتها لك.
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.
استنادا إلى تصنيف SOC المهني
| 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.