القائمة
Draft an implementation plan for a feature in .agents/plans. Does not execute the plan. Use when the user asks to plan, design, or scope a feature without building it.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create a GitHub release and publish to NPM.
Commit staged work, push the branch, and open a PR. Use when wrapping up changes that need to ship.
Execute an implementation plan. Implements every task, runs validation, commits, and opens a PR. Use when the user asks to execute, implement, or run a plan file.
Triage and fix dependency vulnerabilities in an npm project. Use when the user asks to fix, address, or patch dependency/dependabot/npm audit vulnerabilities.
Prepare a release PR by bumping package versions (patch, minor, or major).
Analyze past Claude Code session(s) for mistakes and propose targeted improvements. Use when the user asks for a retrospective, post-mortem, or session review. Outputs concise findings plus suggested edits to CLAUDE.md (general lessons) or new/updated skills (specific workflows).
| name | create-plan |
| description | Draft an implementation plan for a feature in .agents/plans. Does not execute the plan. Use when the user asks to plan, design, or scope a feature without building it. |
| argument-hint | feature description |
Write a plan to .agents/plans/. Do not implement.
Ask questions in batches until the feature is unambiguous. Read the code instead of asking whenever the answer is in the repo. Stop at nitpicks.
Present 2–4 high-level approaches. For each: shape, main upside, main cost. Ask which to take. Wait.
Save to .agents/plans/YYYY-MM-DD-<slug>.md (create the dir if missing). Use this template:
The plan can cover a feature, bug fix, refactor, or technical task. Adapt the user story and acceptance criteria accordingly (e.g., for a refactor, "user" may be a developer; for a bug fix, frame the story around the broken behavior).
# <Title>
## User story
As a <user>, I want <goal> so that <benefit>.
## Description
A few paragraphs explaining what this is, the motivation, the current state, and the desired state. Include enough context that a reader unfamiliar with the work can understand it without external references.
## Acceptance criteria
User-perspective only. No technical terms, file names, or APIs.
- [ ] ...
## Out of scope
- ...
## Implementation details
Architecture, key types, dependencies, relevant patterns, trade-offs.
## Testing strategy
What to cover and how: unit, integration, e2e (Playwright). Note any new fixtures, mocks, or manual verification steps.
## Tasks
- [ ] ...
- [ ] Run the `validate` skill (must be the last task)
## Open questions
- ...
Tell the user the file path.
Apply requested edits, repeat until approved. Do not implement.