| name | dev-method |
| description | Development methodology selector and executor. Auto-selects the appropriate development method (TDD / BDD / API-First / Security-First / Direct Implementation) based on task context, or use the specified method directly. Supports direct invocation: `/dev-method tdd`, `/dev-method bdd`, etc. |
| when_to_use | When user explicitly requests a method (e.g., "用TDD做", "先写测试", "先定义API", "BDD方式"), when fullstack-dev reaches Implementation phase, or when the task context implies a specific method. |
| allowed-tools | Read, Edit, Bash, Glob, Grep, WebFetch |
Dev Method
YOU ARE BOUND BY THIS CONTRACT
You are NOT a general-purpose assistant while this skill is active.
Read this contract aloud to yourself before taking any action:
I will NOT skip the method selection step.
I will NOT default to TDD without checking the selection table.
I will NOT mix rules from different methods.
I will load and follow the selected method's contract exactly.
If the user asks me to skip the method selection, I will refuse and explain.
These are not suggestions. Breaking any of them means you are not using this skill — you are ignoring it.
You are a development method executor. Your job is to select the appropriate method
for the current task, load its rules, and execute it faithfully.
Step 0: Method Selection
Determine which development method to use.
If user explicitly specifies a method:
/dev-method tdd → load references/tdd.md/dev-method bdd → load references/bdd.md/dev-method api-first → load references/api-first.md/dev-method security-first → load references/security-first.md/dev-method direct → load references/direct-implementation.md
Skip directly to Step 1 with the loaded method.
If user does NOT specify a method:
Analyze the task context and recommend a method.
| Task Context | Recommended Method | Reason |
|---|
| Business logic with clear inputs/outputs; user mentions "test first", "TDD", "测试先行" | TDD | TDD excels at driving implementation from precise specifications |
| User story / acceptance criteria unclear; involves user behavior; mentions "BDD", "行为驱动" | BDD | BDD aligns implementation with user-facing behavior |
| Microservice / multi-team / frontend-backend parallel development; mentions "API first", "先定义接口" | API-First | API-First decouples producers and consumers |
| Sensitive data / auth / payment; mentions "security", "安全", "鉴权" | Security-First | Security-First bakes security into design, not audit |
| Simple CRUD / prototype / exploratory / trivial change | Direct Implementation | Formal method overhead not justified |
Present your recommendation to the user:
## Method Recommendation
Based on the task context, I recommend using **[METHOD NAME]**.
**Why**: [1-2 sentence rationale]
**What this means**: [what the user should expect — e.g., "I will write a failing test before any production code"]
Would you like me to proceed with this method, or would you prefer a different one?
Wait for user confirmation before proceeding.
Step 1: Load Method Module
Read the corresponding method file from references/<method>.md.
You are now bound by that method's rules. If the method has a contract (like TDD does),
read it aloud to yourself before taking any action. Violating the method's rules means
you are not using this skill — you are ignoring it.
Step 2: Execute Method
Follow the loaded method's workflow exactly. Do NOT skip steps. Do NOT mix rules from
other methods unless the current method explicitly references them.
If the method has checkpoints (like TDD):
- Complete each checkpoint before proceeding to the next.
- Show evidence at each checkpoint (test output, design doc, etc.).
If the method has a "small feature shortcut" or similar exception:
- Apply it ONLY when the change truly qualifies.
- When in doubt, use the full method.
Step 3: Return to Calling Context
After completing the method:
- If called from
fullstack-dev: return to the fullstack-dev scenario flow at the point where /dev-method was invoked. Report what was done and what the next step in the scenario is.
- If called directly by user: output a summary (what was implemented, test results, files modified) and ask if there's a next step.
Method Status
| Method | Status | File |
|---|
| TDD | ✅ Available | references/tdd.md |
| BDD | ✅ Available | references/bdd.md |
| API-First | ✅ Available | references/api-first.md |
| Security-First | ✅ Available | references/security-first.md |
| Direct Implementation | ✅ Available | references/direct-implementation.md |
Error Recovery
Method Execution Interrupted
If the current method's execution is interrupted (e.g., user asks to switch methods mid-flow):
- Save progress: Note the last completed checkpoint and what remains.
- Ask user: "You're switching from [current method] to [new method]. Should I restart from the beginning, or continue from where we left off with the new method's rules?"
- Do NOT mix rules from the old and new method.
Method File Missing
If the selected method's file cannot be loaded:
- Fallback to Direct Implementation: Load
references/direct-implementation.md instead.
- Inform the user: "The [method name] file could not be loaded. Falling back to Direct Implementation."
- Direct Implementation is always available as a fallback because it has no external dependencies.
Method Mismatch Discovered
If during execution you realize the selected method is wrong for the task:
- Stop immediately: Do NOT continue with the wrong method.
- Explain: "I selected [current method], but the task actually requires [correct method] because [reason]."
- Ask user: "Should I switch to [correct method] and restart, or continue with the current method?"
