Concise planning
Skill karim-bhalwani/agent-skills-collection/skills/concise-planning
AI agents are smart but unreliable without procedure. "Agent Skills" are executable checklists that package expertise.
npx -y skills add karim-bhalwani/agent-skills-collection --skill concise-planningAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 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
Generate clear, actionable, and atomic checklists for coding tasks with minimal interaction and reasonable assumptions. Use when creating implementation plans, breaking down tasks into steps, generating task checklists, or planning project workflows.
SKILL.md
3.3 KB, as published. Nobody here has run it
Concise Planning
Goal
Turn a user request into a single, actionable plan with atomic steps.
Workflow
1. Scan Context
- Read
README.md, docs, and relevant code files. - Identify constraints (language, frameworks, tests).
2. Minimal Interaction
- Ask at most 1–2 questions and only if truly blocking.
- Make reasonable assumptions for non-blocking unknowns.
3. Generate Plan
Use the following structure:
- Approach: 1-3 sentences on what and why.
- Scope: Bullet points for "In" and "Out".
- Action Items: A list of 6-10 atomic, ordered tasks (Verb-first).
- Validation: At least one item for testing.
Plan Template
# Plan
<High-level approach>
## Scope
- In:
- Out:
## Action Items
[ ] <Step 1: Discovery>
[ ] <Step 2: Implementation>
[ ] <Step 3: Implementation>
[ ] <Step 4: Validation/Testing>
[ ] <Step 5: Rollout/Commit>
## Open Questions
- <Question 1 (max 3)>
Checklist Guidelines
- Atomic: Each step should be a single logical unit of work.
- Verb-first: "Add...", "Refactor...", "Verify...".
- Concrete: Name specific files or modules when possible.
Outputs & Deliverables
- Primary Output: A single
plan.mdfollowing the Plan Template - Secondary Output: Open questions and assumptions list
- Success Criteria: Plan has atomic action items and at most 3 blocking questions
- Quality Gate: Plan reviewed and approved by requester or
implementer
Constraints
- Technical Constraints: Do not implement code in this step; produce a plan only.
- Scope Constraints: Plans should be limited to the requested scope; avoid speculative features.
- Governance Constraints: Align plan with
project-context.mdandspec.mdif present.
Common Pitfalls
- Over-Planning: Creating 30+ atomic steps when 6-10 suffice. Keep it concise; details emerge during execution.
- Vague Action Items: "Implement feature" isn't actionable. "Add payment processing to checkout flow" is specific.
- Missing Validation Steps: A plan without testing/verification sets up for rework. Always include a validation checkpoint.
- Ignoring Dependencies: Listing steps in random order instead of respecting precedence. Steps must be executable in sequence.
- Scope Creep: Including "nice-to-haves" in the main plan. Use "Out of Scope" section to acknowledge but exclude them.
- Assuming All Context: Not reading existing code/docs leads to redundant or conflicting plans. Always scan context first.
Integration Points
| Phase | Input From | Output To | Context |
|---|---|---|---|
| Input | User request + context | Plan generation | Scan code, README, and constraints |
| Design Specs | architect specifications | Implementation steps | Use spec.md to guide atomic tasks |
| Execution | Approved plan | implementer | Hand off actionable checklist |
| Monitoring | Progress updates | Status tracking | Adjust if blockers emerge |