Plan Harder
Turn a vague bug, feature, or task into sprint-sized, committable implementation plans after the user explicitly asks to “plan harder.”
Overview
Plan Harder is an agent skill most often used in Build (also Validate scope) that researches the repo, clarifies requirements, and writes phased sprint plans with atomic, testable tasks—when the user explicitly says “pla
Install
npx skills add https://github.com/am-will/codex-skills --skill plan-harderWhat is this skill?
- Three-phase flow: codebase research, up to 10 clarification questions, then structured plan authoring
- Sprints must each ship a demoable, runnable, testable increment with a verification checklist
- Tasks must be atomic, committable, file-path-specific, independently testable, with explicit dependencies for parallel w
- Clarification pass covers scope boundaries, constraints, priorities, edge cases, and success criteria
- Triggered only when the user specifically says “plan harder”—not a default planning mode
- 3 planning phases: research, clarify, create plan
- Up to 10 targeted clarification questions in the requirements phase
Adoption & trust: 1.2k installs on skills.sh; 941 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know what to build but your agent keeps producing vague milestones instead of sprint-sized, committable tasks grounded in your actual codebase.
Who is it for?
Solo builders shipping non-trivial features or fixes who want demoable sprint increments and explicit task boundaries before coding.
Skip if: Quick one-liner fixes, tasks where requirements are already frozen and a spec exists, or sessions where you did not ask to “plan harder.”
When should I use this skill?
User specifically says “plan harder” and needs a detailed phased plan with sprints and atomic tasks.
What do I get? / Deliverables
You get an overview plus ordered sprints and atomic tasks with verification steps—ready for an implementation agent to execute sprint by sprint without re-deriving architecture.
- Phased implementation plan with overview, sprints, and atomic tasks
- Per-sprint demo and verification checklists
- Clarification answers captured after ambiguities are resolved
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build → PM because the skill’s output is phased sprints and atomic dev tasks tied to the codebase. Subphase pm matches implementation planning, task breakdown, and parallelizable work—not ideation-only brainstorming.
Where it fits
Slice a new integration into sprint-sized releases with clear in/out of scope before you commit build time.
Produce atomic tasks with file paths and tests after researching how similar features are implemented in your repo.
Plan a multi-step API change with security and performance considerations captured in sprint verification checklists.
Align review expectations with what each sprint must demo so PRs map to planned increments.
How it compares
Use instead of ad-hoc “write me a plan” chat when you need enforced sprint/demo rules and atomic committable tasks.
Common Questions / FAQ
Who is plan-harder for?
Solo and indie developers using Codex, Claude Code, or Cursor who need disciplined, codebase-aware implementation plans with sprints—not a single paragraph todo list.
When should I use plan-harder?
Use it in Validate when scoping a feature into releasable slices, and in Build PM when breaking work into sprints; also before large Ship reviews when you need testable increments. Only invoke when you explicitly want the “plan harder” workflow.
Is plan-harder safe to install?
Treat it as procedural planning guidance that may read your repo context through the agent; review the Security Audits panel on this page and limit secrets in prompts before codebase investigation.
SKILL.md
READMESKILL.md - Plan Harder
# Planner Agent Create detailed, phased implementation plans for bugs, features, or tasks. You make phased implementation plans with sprints and atomic tasks. ## Process ### Phase 0: Research 1. **Investigate the codebase:** - Architecture and patterns - Similar existing implementations - Dependencies and frameworks - Related components 2. **Analyze the request:** - Core requirements - Challenges and edge cases - Security/performance/UX considerations ### Phase 1: Clarify Requirements Use request_user_input to resolve ambiguities. Ask up to 10 targeted questions: - Scope boundaries (in/out of scope) - Technology/architectural constraints - Priorities (critical vs nice-to-have) - Edge case handling - Success criteria ### Phase 2: Create Plan #### Structure - **Overview**: Brief summary and approach - **Sprints**: Logical phases that build on each other - **Tasks**: Specific, actionable items within sprints #### Sprint Requirements Each sprint must: - Result in **demoable, runnable, testable** increment - Build on prior sprint work - Include demo/verification checklist #### Task Requirements Each task must be: - **Atomic and committable** (small, independent) - Specific with clear inputs/outputs - Independently testable - Include file paths when relevant - Include dependencies for parallel execution - Include tests or validation method **Bad:** "Implement Google OAuth" **Good:** - "Add Google OAuth config to env variables" - "Install passport-google-oauth20 package" - "Create OAuth callback route in src/routes/auth.ts" - "Add Google sign-in button to login UI" ### Phase 3: Save Save the file Generate filename from request: 1. Extract key words 2. Convert to kebab-case 3. Add `-plan.md` suffix Examples: - "fix xyz bug" → `xyz-bug-plan.md` - "implement google auth" → `google-auth-plan.md` ### Phase 4: Gotchas AFTER it is saved. Identify potential issues and edge cases in the plan. Address them proactively. Where could something go wrong? What about the plan is ambiguous? Is there a missing step, dependency, or pitfall? Use the request_user_input tool again now that you have a plan to read, if any issues are identified. Update the plan if you have improvements. ### Phase 5: Review Provide the plan file location to a subagent for review, and ask it to provide feedback. Provide it useful context so it can make sound decisions. Explicitly tell it not to ask any questions. If it provides useful feedback, Incorporate useful suggestions to plan. ## Plan Template ```markdown # Plan: [Task Name] **Generated**: [Date] **Estimated Complexity**: [Low/Medium/High] ## Overview [Summary of task and approach] ## Prerequisites - [Dependencies or requirements] - [Tools, libraries, access needed] ## Sprint 1: [Name] **Goal**: [What this accomplishes] **Demo/Validation**: - [How to run/demo] - [What to verify] ### Task 1.1: [Name] - **Location**: [File paths] - **Description**: [What to do] - **Complexity**: [1-10] - **Dependencies**: [Previous tasks] - **Acceptance Criteria**: - [Specific criteria] - **Validation**: - [Tests or verification] ### Task 1.2: [Name] [...] ## Sprint 2: [Name] [...] ## Testing Strategy - [How to test] - [What to verify per sprint] ## Potential Risks & Gotchas - [What could go wrong] - [Mitigation strategies] ## Rollback Plan - [How to undo if needed] ``` ## Important - Think about full lifecycle: implementation, testing, deployment - Consider non-functional requirements - Show user summary and file path when done - Do NOT implement - only create the plan