Plan feature
Skill az9713/youtube-transcript-to-skills/.claude/skills/plan-feature
Extract Claude Code skills from AI workflow YouTube transcripts. 10 ready-to-use skills + a meta-skill that automates the extraction process. Built from John Kim's 50 Claude Code tips.
npx -y skills add az9713/youtube-transcript-to-skills --skill plan-featureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Plan a new feature before writing code. Explores the codebase, creates a structured plan with verification criteria, and only implements after approval.
SKILL.md
3.0 KB, 649 tokens by cl100k_base, as published. Nobody here has run it
Plan Feature
Create a structured implementation plan before writing any code. Based on the principle that planning before coding prevents wasted work and produces better results.
Usage
/plan-feature <description of the feature>
Procedure
Step 1: Understand the Request
Parse $ARGUMENTS to understand what feature the user wants. If the description is ambiguous, ask clarifying questions:
- What is the expected behavior?
- Are there any constraints (performance, compatibility, etc.)?
- Should this follow an existing pattern in the codebase?
Step 2: Explore the Codebase
Before planning, understand the existing architecture. Use the Explore agent or read files directly:
- Find related code: Search for files related to the feature (e.g., if adding auth, search for existing auth/user code)
- Understand patterns: How does the codebase structure similar features? (routing, services, models, tests)
- Identify dependencies: What existing modules will this feature interact with?
- Check for conventions: Read CLAUDE.md for project-specific conventions
Step 3: Create the Plan
Write a structured plan with these sections:
# Feature Plan: [Feature Name]
## Scope
What this feature does and does NOT do. Explicit boundaries.
## Affected Files
- `path/to/file1.ts` — What changes and why
- `path/to/file2.ts` — What changes and why
- `path/to/new-file.ts` — NEW: What this file does
## Approach
Step-by-step implementation order:
1. First, ... (because this establishes the foundation)
2. Then, ... (because this depends on step 1)
3. Finally, ... (integration and wiring)
## Risks & Edge Cases
- Risk: [description] → Mitigation: [approach]
- Edge case: [description] → Handling: [approach]
## Verification Criteria
How to confirm the feature works:
- [ ] Unit tests pass: `[specific test command]`
- [ ] Integration test: [describe manual or automated check]
- [ ] Edge case covered: [specific scenario]
- [ ] No regressions: `[full test suite command]`
Step 4: Save the Plan
Save the plan to a local file:
- Path:
.claude/plans/<feature-slug>.md - Create the
.claude/plans/directory if it doesn't exist
Step 5: Present for Approval
Show the plan to the user and ask for approval:
"Here's the implementation plan. Should I proceed, or would you like to adjust anything?"
Do NOT write any implementation code until the user approves the plan.
Step 6: Execute (After Approval)
Once approved:
- Follow the plan step-by-step
- After each step, verify it works before moving to the next
- Run the verification criteria at the end
- Report completion with a summary of what was done
If you discover the plan needs adjustment during implementation, stop and consult the user before deviating.
Gives 0 of the 12 instructions most plan spec skills give in 649 tokens
Counted across 1,100 of the 1,860 authors here whose files we hold, read 2026-08-06
- ask one question at a timein 46 of 1100, across 38 files
- Break plans into vertical slicesin 28 of 1100, across 10 files
- Publish issues in dependency orderin 27 of 1100, across 9 files
- Iterate until user approves the breakdownin 24 of 1100, across 6 files
- Explore the repository to understand the codebase statein 24 of 1100, across 7 files
- Use domain glossary vocabularyin 23 of 1100, across 5 files
- Apply correct triage labels to published issuesin 23 of 1100, across 5 files
- Write failing tests before implementation codein 23 of 1100, across 18 files
- Prefer AFK slices over HITLin 22 of 1100, across 7 files
- ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
- Respect existing architecture decision recordsin 20 of 1100, across 5 files
- write a specification before writing any codein 20 of 1100, across 12 files
Said here and by no other author read
- search for files related to the feature
- do not write implementation code before approval
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.