一键导入
writing-plans
Use to expand bd tasks with detailed implementation steps - adds exact file paths, complete code, verification commands assuming zero context
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use to expand bd tasks with detailed implementation steps - adds exact file paths, complete code, verification commands assuming zero context
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use to audit test quality with Google Fellow SRE scrutiny - identifies tautological tests, coverage gaming, weak assertions, missing corner cases. Creates bd epic with tasks for improvements, then runs SRE task refinement on each.
Use when creating or developing anything, before writing code - refines rough ideas into bd epics with immutable requirements
Use when creating Claude Code hooks - covers hook patterns, composition, testing, progressive enhancement from simple to advanced
Use when encountering bugs or test failures - systematic debugging using debuggers, internet research, and agents to find root cause before fixing
Use when facing 3+ independent failures that can be investigated without shared state or dependencies - dispatches multiple agents to investigate and fix independent problems concurrently
Execute entire bd epic autonomously via subagent-per-task dispatch loop. Setup, dispatch subagent per task, end-of-epic review, branch completion.
| name | writing-plans |
| description | Use to expand bd tasks with detailed implementation steps - adds exact file paths, complete code, verification commands assuming zero context |
<kimi_compat> This skill was ported to Kimi Code CLI. In Kimi:
/skill:name or let the model invoke them automatically.SetTodoList tool.Agent tool.Agent calls with run_in_background=true.<rigidity_level> MEDIUM FREEDOM - Follow task-by-task validation pattern, use codebase-investigator for verification.
Adapt implementation details to actual codebase state. Never use placeholders or meta-references. </rigidity_level>
<quick_reference>
| Step | Action | Critical Rule |
|---|---|---|
| Identify Scope | Single task, range, or full epic | No artificial limits |
| Verify Codebase | Use codebase-investigator agent | NEVER verify yourself, report discrepancies |
| Draft Steps | Write bite-sized (2-5 min) actions | Follow TDD cycle for new features |
| Present to User | Show COMPLETE expansion FIRST | Then ask for approval |
| Update bd | tm update bd-N --design "..." | Only after user approves |
| Continue | Move to next task automatically | NO asking permission between tasks |
FORBIDDEN: Placeholders like [Full implementation steps as detailed above]
REQUIRED: Actual content - complete code, exact paths, real commands
</quick_reference>
<when_to_use> Use after /skill:sre-task-refinement or anytime tasks need more detail.
Symptoms:
</when_to_use>
<the_process>
User specifies scope:
If epic:
tm dep tree bd-1 # View complete dependency tree
# Note all child task IDs
Create SetTodoList tracker:
- [ ] bd-2: [Task Title]
- [ ] bd-3: [Task Title]
...
# Mark in SetTodoList: in_progress
tm show bd-3 # Read current task design
CRITICAL: Use codebase-investigator agent, NEVER verify yourself.
Provide agent with bd assumptions:
Assumptions from bd-3:
- Auth service should be in src/services/auth.ts with login() and logout()
- User model in src/models/user.ts with email and password fields
- Test file at tests/services/auth.test.ts
- Uses bcrypt dependency for password hashing
Verify these assumptions and report:
1. What exists vs what bd-3 expects
2. Structural differences (different paths, functions, exports)
3. Missing or additional components
4. Current dependency versions
Based on investigator report:
NEVER write conditional steps:
❌ "Update index.js if exists"
❌ "Modify config.py (if present)"
ALWAYS write definitive steps:
✅ "Create src/auth.ts" (investigator confirmed doesn't exist)
✅ "Modify src/index.ts:45-67" (investigator confirmed exists)
Bite-sized granularity (2-5 minutes per step):
For new features (follow test-driven-development):
Include in each step:
CRITICAL: Show the full expansion BEFORE asking for approval.
Format:
**bd-[N]: [Task Title]**
**From bd issue:**
- Goal: [From tm show]
- Effort estimate: [From bd issue]
- Success criteria: [From bd issue]
**Codebase verification findings:**
- ✓ Confirmed: [what matched]
- ✗ Incorrect: [what issue said] - ACTUALLY: [reality]
- + Found: [unexpected discoveries]
**Implementation steps based on actual codebase state:**
### Step Group 1: [Component Name]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`
**Step 1: Write the failing test**
```python
# tests/auth/test_login.py
def test_login_with_valid_credentials():
user = create_test_user(email="test@example.com", password="secure123")
result = login(email="test@example.com", password="secure123")
assert result.success is True
assert result.user_id == user.id
Step 2: Run test to verify it fails
pytest tests/auth/test_login.py::test_login_with_valid_credentials
# Expected: ModuleNotFoundError: No module named 'auth.login'
[... continue for all steps ...]
**THEN ask for approval using AskUserQuestion:**
- Question: "Is this expansion approved for bd-[N]?"
- Options:
- "Approved - continue to next task"
- "Needs revision"
- "Other"
### 2e. If Approved: Update bd and Continue
```bash
tm update bd-3 --design "[paste complete expansion]"
# Mark completed in SetTodoList
# IMMEDIATELY continue to next task (NO asking permission)
All bd issues now contain detailed implementation steps.
Epic ready for execution.
Offer execution choice: "Ready to execute? I can use /skill:executing-plans to implement iteratively."
</the_process>
Developer writes placeholder text instead of actual implementation steps
tm update bd-3 --design "## Goal
Implement user authentication
Implementation
[Full implementation steps as detailed above - includes all 6 step groups with complete code examples]
Tests
[Complete code examples will be added here]"
<why_it_fails> Placeholders defeat the purpose:
Common placeholder patterns (ALL FORBIDDEN):
[Full implementation steps as detailed above][See above for detailed steps][As specified in success criteria][Complete code examples will be added here]
</why_it_fails>tm update bd-3 --design "## Goal
Implement user authentication
## Implementation
### Step 1: Write failing login test
```python
# tests/auth/test_login.py
import pytest
from auth.service import login
def test_login_with_valid_credentials():
result = login(email='test@example.com', password='pass123')
assert result.success is True
pytest tests/auth/test_login.py::test_login_with_valid_credentials
# Expected: ModuleNotFoundError: No module named 'auth.service'
# src/auth/service.py
from dataclasses import dataclass
@dataclass
class LoginResult:
success: bool
user_id: int | None = None
def login(email: str, password: str) -> LoginResult:
# Minimal implementation
return LoginResult(success=True, user_id=1)
[... continue for all steps with complete code ...]
All test code included in implementation steps above following TDD cycle."
**Result:** Engineer can execute without any context.
</correction>
</example>
<example>
<scenario>Developer verifies codebase state themselves instead of using codebase-investigator agent</scenario>
<code>
Developer reads files manually:
- Reads src/services/auth.ts directly
- Checks package.json manually
- Assumes file structure based on quick look
Writes expansion based on quick check:
"Modify src/services/auth.ts (if exists)"
</code>
<why_it_fails>
**Manual verification problems:**
- Misses nuances (existing functions, imports, structure)
- Creates conditional steps ("if exists")
- Doesn't catch version mismatches
- Doesn't report discrepancies from bd assumptions
**Result:** Implementation plan may not match actual codebase state.
</why_it_fails>
<correction>
**Use codebase-investigator agent:**
Dispatch agent with bd-3 assumptions: "bd-3 expects auth service in src/services/auth.ts with login() and logout() functions. Verify:
**Agent reports:**
✓ src/services/auth.ts exists ✗ ONLY has login() function - NO logout() yet
**Write definitive steps based on findings:**
Step 1: Add logout() function to EXISTING src/services/auth.ts:45-67 (no "if exists" - investigator confirmed location)
Step 2: Use argon2 (already installed 0.31.2) not bcrypt (no assumption - investigator confirmed actual dependency)
**Result:** Plan matches actual codebase state.
</correction>
</example>
<example>
<scenario>Developer asks permission between each task validation instead of continuing automatically</scenario>
<code>
After user approves bd-3 expansion:
Developer: "bd-3 expansion approved and updated in bd.
Should I continue to bd-4 now? What's your preference?"
[Waits for user response]
</code>
<why_it_fails>
**Breaks workflow momentum:**
- Unnecessary interruption
- User has to respond multiple times
- Slows down batch processing
- SetTodoList list IS the plan
**Why it happens:** Over-asking for permission instead of executing the plan.
</why_it_fails>
<correction>
**After user approves bd-3:**
```bash
tm update bd-3 --design "[expansion]" # Update bd
# Mark completed in SetTodoList
IMMEDIATELY continue to bd-4:
tm show bd-4 # Read next task
# Dispatch codebase-investigator with bd-4 assumptions
# Draft expansion
# Present bd-4 expansion to user
NO asking: "Should I continue?" or "What's your preference?"
ONLY ask user:
Between validations: JUST CONTINUE.
Result: Efficient batch processing of all tasks.
<critical_rules>
No placeholders or meta-references → Write actual content
[Full implementation steps as detailed above]Use codebase-investigator agent → Never verify yourself
Present COMPLETE expansion before asking → User must SEE before approving
Continue automatically between validations → Don't ask permission
Write definitive steps → Never conditional
index.js if exists"src/auth.ts" (investigator confirmed)All of these mean: Stop, write actual content:
</critical_rules>
<verification_checklist>
Before marking each task complete in SetTodoList:
Before finishing all tasks:
</verification_checklist>
This skill calls:
This skill is called by:
Agents used:
Detailed guidance:
When stuck: