code-review
Use when a major project step has been completed and needs review against the plan and coding standards. Also use when someone says 'review this', 'check my…
Use before ANY creative work — creating features, building components, adding functionality, modifying behavior, or starting a new project. Also use when someone says 'build', 'create', 'add', 'implement', 'let's make', or describes something they want built. Do NOT write code
$ npx -y skills add burhankhatri/e2e-testing --skill brainstorming-and-planning --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/brainstorming-and-planningContext preview
The summary Claude sees to decide when to auto-load this skill.
Use before ANY creative work — creating features, building components, adding functionality, modifying behavior, or starting a new project. Also use when someone says 'build', 'create', 'add', 'implement', 'let's make', or describes something they want built. Do NOT write code
name: brainstorm-and-plan description: "Use before ANY creative work — creating features, building components, adding functionality, modifying behavior, or starting a new project. Also use when someone says 'build', 'create', 'add', 'implement', 'let's make', or describes something they want built. Do NOT write code until a design is approved and a plan is written."
<HARD-GATE> Do NOT write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity. </HARD-GATE>
Every project goes through this process. A todo list, a single utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short, but you MUST present it and get approval.
1. **Explore project context** — check files, docs, recent commits 2. **Ask clarifying questions** — one at a time, prefer multiple choice when possible 3. **Propose 2-3 approaches** — with trade-offs and your recommendation. Lead with recommended option and explain why. 4. **Present design** — in sections scaled to complexity, get user approval after each section. Cover: architecture, components, data flow, error handling, testing. 5. **Write design doc** — save to `docs/specs/YYYY-MM-DD-<topic>-design.md` and commit 6. **Spec self-review:**
7. **User reviews written spec** — wait for approval before proceeding 8. **Transition to Part 2** — write implementation plan
---
Write plans assuming the engineer executing has zero codebase context and questionable taste. Document everything: files to touch, code, testing, how to verify. DRY. YAGNI. TDD. Frequent commits.
# [Feature Name] Implementation Plan **Goal:** [One sentence] **Architecture:** [2-3 sentences] **Tech Stack:** [Key technologies] ---
### Task N: [Component Name] **Files:** - Create: `exact/path/to/file.ts` - Modify: `exact/path/to/existing.ts` - Test: `tests/exact/path/to/test.ts` - [ ] **Step 1: Write the failing test** [actual test code] - [ ] **Step 2: Run test to verify it fails** Run: `npm test path/to/test.ts` Expected: FAIL with "[specific message]" - [ ] **Step 3: Write minimal implementation** [actual implementation code] - [ ] **Step 4: Run test to verify it passes** Run: `npm test path/to/test.ts` Expected: PASS - [ ] **Step 5: Commit** `git add ... && git commit -m "feat: add specific feature"`
These are plan failures — never write them:
1. **Spec coverage:** Skim each requirement. Can you point to a task? List gaps. 2. **Placeholder scan:** Search for red flags. Fix them. 3. **Type consistency:** Do names match across tasks? (`clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.)
Save plans to: `docs/plans/YYYY-MM-DD-<feature-name>.md`
After saving the plan, execute tasks sequentially:
For feature work, create an isolated worktree:
# Check for existing .worktrees/ directory, create if needed # Verify .worktrees/ is in .gitignore (add + commit if not) git worktree add .worktrees/<branch-name> -b <branch-name> cd .worktrees/<branch-name> npm install # or appropriate setup npm test # verify clean baseline
When done: verify tests → merge/PR/keep/discard → clean up worktree.
A set of 8 global skills for Claude Code that enforce disciplined, test-driven agentic development. Install once, use in any project.
Repo: burhankhatri/e2e-testing
Use when a major project step has been completed and needs review against the plan and coding standards. Also use when someone says 'review this', 'check my…
Battle-tested Playwright E2E testing patterns for Next.js/React apps. Use when writing, running, debugging, or fixing Playwright tests. Also triggers on 'e2e',…
Master orchestrator skill that kicks off the full development pipeline. Routes tasks through the correct skill chain (brainstorm, debug, tdd, e2e, verify)…
Use when encountering ANY bug, test failure, unexpected behavior, or error — before proposing fixes. Also use when someone says 'fix this', 'it's broken', 'not…
Enforces strict test-driven development. Use when implementing ANY feature, bugfix, or refactor — before writing implementation code. Also use when someone…
Use when you need to autonomously iterate through test-fix cycles without human intervention. Use when someone says 'make it work', 'run tests and fix',…