ea057feeec
* feat(skills): add oh-my-issues for root-cause issue clustering Codifies the consolidation method that turned ~100 open issues into 6 plan-master issues during the v13.0.1 cycle. Three modes: cluster pass (initial reduction), triage (route a new bug into an existing master), bundle (ship a PR that closes the cluster atomically). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(skills): correct oh-my-issues cluster-pass instructions - Cluster pass step 1: drop the misleading single-call pattern; point to a paginated list + per-issue comment fetch since `gh issue list --json comments` returns only counts and `--limit` silently truncates large backlogs. - GitHub CLI primitives: replace the buggy snippet with a total-count check, paginated listing, per-issue comment loop, and REST API fallback for repos with >1000 open issues. - make-plan: add See Also section linking oh-my-issues so the planning skill knows about its issue-side sibling. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(skills): use search API for issue counts and tag fenced block - repos/{owner}/{repo}.open_issues_count includes PRs. Switch to the search/issues API which differentiates issues from PRs so the cluster-pass count is accurate. - Add `text` language tag to the standardized redirect comment fenced block (MD040). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
68 lines
3.1 KiB
Markdown
68 lines
3.1 KiB
Markdown
---
|
|
name: make-plan
|
|
description: Create a detailed, phased implementation plan with documentation discovery. Use when asked to plan a feature, task, or multi-step implementation — especially before executing with do.
|
|
---
|
|
|
|
# Make Plan
|
|
|
|
You are an ORCHESTRATOR. Create an LLM-friendly plan in phases that can be executed consecutively in new chat contexts.
|
|
|
|
## Delegation Model
|
|
|
|
Use subagents for *fact gathering and extraction* (docs, examples, signatures, grep results). Keep *synthesis and plan authoring* with the orchestrator (phase boundaries, task framing, final wording). If a subagent report is incomplete or lacks evidence, re-check with targeted reads/greps before finalizing.
|
|
|
|
### Subagent Reporting Contract (MANDATORY)
|
|
|
|
Each subagent response must include:
|
|
1. Sources consulted (files/URLs) and what was read
|
|
2. Concrete findings (exact API names/signatures; exact file paths/locations)
|
|
3. Copy-ready snippet locations (example files/sections to copy)
|
|
4. "Confidence" note + known gaps (what might still be missing)
|
|
|
|
Reject and redeploy the subagent if it reports conclusions without sources.
|
|
|
|
## Plan Structure
|
|
|
|
### Phase 0: Documentation Discovery (ALWAYS FIRST)
|
|
|
|
Before planning implementation, deploy "Documentation Discovery" subagents to:
|
|
1. Search for and read relevant documentation, examples, and existing patterns
|
|
2. Identify the actual APIs, methods, and signatures available (not assumed)
|
|
3. Create a brief "Allowed APIs" list citing specific documentation sources
|
|
4. Note any anti-patterns to avoid (methods that DON'T exist, deprecated parameters)
|
|
|
|
The orchestrator consolidates findings into a single Phase 0 output.
|
|
|
|
### Each Implementation Phase Must Include
|
|
|
|
1. **What to implement** — Frame tasks to COPY from docs, not transform existing code
|
|
- Good: "Copy the V2 session pattern from docs/examples.ts:45-60"
|
|
- Bad: "Migrate the existing code to V2"
|
|
2. **Documentation references** — Cite specific files/lines for patterns to follow
|
|
3. **Verification checklist** — How to prove this phase worked (tests, grep checks)
|
|
4. **Anti-pattern guards** — What NOT to do (invented APIs, undocumented params)
|
|
|
|
### Final Phase: Verification
|
|
|
|
1. Verify all implementations match documentation
|
|
2. Check for anti-patterns (grep for known bad patterns)
|
|
3. Run tests to confirm functionality
|
|
|
|
## Key Principles
|
|
|
|
- Documentation Availability ≠ Usage: Explicitly require reading docs
|
|
- Task Framing Matters: Direct agents to docs, not just outcomes
|
|
- Verify > Assume: Require proof, not assumptions about APIs
|
|
- Session Boundaries: Each phase should be self-contained with its own doc references
|
|
|
|
## Anti-Patterns to Prevent
|
|
|
|
- Inventing API methods that "should" exist
|
|
- Adding parameters not in documentation
|
|
- Skipping verification steps
|
|
- Assuming structure without checking examples
|
|
|
|
## See Also
|
|
|
|
- `oh-my-issues` — the issue-side sibling. When the plan you're being asked to make is rooted in a bug or feature backlog rather than a fresh idea, route through `oh-my-issues` first to cluster issues by root cause into plan masters and `plans/0X-*.md` design docs. `make-plan` then operates on the design doc for one plan slice.
|