القائمة
Use when a new feature request, bug report, or work request needs requirements defined before implementation
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/Trevoke/org-gtd.el --skill defineيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Use EVERY TIME you need to run tests, verify tests pass, or check for regressions. ALWAYS use this instead of running eldev directly.
Use when code quality needs improvement after implementation, without changing behavior
Use when implementation is complete and you want to verify quality through adversarial testing that writes code and provides evidence
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | define |
| description | Use when a new feature request, bug report, or work request needs requirements defined before implementation |
Define requirements by interviewing the user. The interview IS the value — a requirements doc produced without conversation is just guessing.
Core principle: Ask, don't assume. Every assumption is a question you didn't ask.
Use AskUserQuestion with multiple-choice options where possible.
You MUST ask questions. You MUST NOT produce requirements without interviewing.
Cover these areas, one question per turn:
| Area | What to Ask |
|---|---|
| Scope | What should this do? What should it NOT do? |
| Personas | Who uses this? What's their context/skill level? |
| Success | How will we know it works? What does "done" look like? |
| Edge cases | What happens with empty/invalid/unexpected input? |
| Constraints | Backward compat? Performance? Dependencies? |
After each area, summarize what you heard (200-300 words) and ask the user to confirm before moving on.
Use INVEST format. Each story must be:
Template:
### Story N: [Title]
**As a** [persona from interview],
**I want** [functionality],
**So that** [benefit].
#### Acceptance Criteria
```gherkin
Given [context]
When [action]
Then [expected result]
Given [edge case context]
When [action]
Then [expected handling]
Present stories to user for validation before finalizing.
### 4. Save and Commit
Ask user for a short name, or derive from the topic.
docs/plans/YYYY-MM-DD--requirements.md
Commit: `docs: add <name> requirements`
### 5. Next Step
> Requirements saved. When ready, use `/architect` to design the solution.
## Common Mistakes
| Mistake | Fix |
|---------|-----|
| Producing requirements without interviewing | STOP. Ask questions first. Always. |
| Asking multiple questions at once | One question per `AskUserQuestion` call |
| Including implementation/architecture details | Stay in problem space. Code design is `/architect`'s job. |
| Listing "open questions" without asking them | If it's a question, ASK the user |
| Using FR-1/AC-1.1 format instead of user stories | Use "As a [persona]..." with Gherkin criteria |
| Assuming scope instead of scoping with user | Every assumption is a question you skipped |
| Massive document from a one-line request | Interview to right-size. Small request may mean small scope. |