一键导入
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when you have a spec or requirements for a multi-step task, before touching code
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Bulletproof CSS and frontend design principles from "Handcrafted CSS" by Dan Cederholm. Apply when writing CSS, HTML, Blade templates, or reviewing frontend code. CSS is king — refactor Tailwind when encountered.
Batch process GitHub issues via batch-orchestrator.sh with rate limit handling and session resumption
Use when given a GitHub issue number and base branch to implement end-to-end
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Process PR based on code review - if approved, create follow-up issues, merge, close; if changes requested, re-run implement-issue
Use when adapting the generic .claude pipeline folder to a specific codebase - adjusting skills, agents, hooks, scripts, prompts, and settings for the target project's tech stack and workflows
| name | writing-plans |
| description | Use when you have a spec or requirements for a multi-step task, before touching code |
Write comprehensive plans assuming the engineer has zero codebase context. Document: files to touch, code snippets, test commands, expected outputs. Bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume skilled developer, unfamiliar with our toolset/domain, weak on test design.
Announce: "I'm using the writing-plans skill to create the implementation plan."
Save to: docs/plans/YYYY-MM-DD-<feature-name>.md
Each step is one action (2-5 minutes):
Every plan MUST start with this header:
# [Feature Name] Implementation Plan
> **For Claude:** REQUIRED SUB-SKILL: Use executing-plans to implement this plan task-by-task.
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
**Feature Branch:** `issue-XXX-feature-name` ← **CRITICAL: Include this. Subagents need it.**
---
Why the branch is required: Subagents have no memory of which branch they're on. When you dispatch an implementer, you must tell them the branch name explicitly. Having it in the plan header ensures it's always available.
### Task N: [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
def test_specific_behavior():
result = function(input)
assert result == expected
Step 2: Run test to verify it fails
Run: pytest tests/path/test.py::test_name -v
Expected: FAIL with "function not defined"
Step 3: Write minimal implementation
def function(input):
return expected
Step 4: Run test to verify it passes
Run: pytest tests/path/test.py::test_name -v
Expected: PASS
Step 5: Verify branch and commit
# Verify on correct branch first
git branch --show-current # Should show feature branch, NOT main/test/aw-next
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
## Remember
- Exact file paths, complete code snippets (not "add validation"), exact commands with expected output
- Reference relevant skills with @ syntax
- DRY, YAGNI, TDD, frequent commits
## Execution Handoff
**"Plan complete and saved to `docs/plans/<filename>.md`. Proceeding with subagent-driven implementation."**
**REQUIRED:** Use subagent-driven-development (fresh subagent per task, code review between tasks).
**Alternative:** If user requests, guide to executing-plans skill for parallel session with checkpoints.