plan

Name: plan
Author: Rune-kit

80stars21forks

How to install plan?

rune-kit/rune/plan

$npx -y skills add Rune-kit/rune --skill plan

Installs into the current project.

Summary

Create structured implementation plans from requirements. Produces master plan + phase files for enterprise-scale project management. Master plan = overview (<80 lines). Phase files = execution detail (<200 lines each). Each session handles 1 phase. Uses opus for deep reasoning.

Files · 1

View on GitHub

SKILL.md

1	# plan
2
3	## Purpose
4
5	Strategic planning engine for the Rune ecosystem. Produces a master plan + phase files architecture — NOT a single monolithic plan. The master plan is a concise overview (<80 lines) that references separate phase files, each containing enough detail (<200 lines) that ANY model can execute with high accuracy.
6
7	Design principle: Plan for the weakest coder. Phase files are designed so that even an Amateur-level model (Haiku) can execute them with minimal errors. When the plan satisfies the Amateur's needs, every model benefits — Junior (Sonnet) executes near-perfectly, Senior (Opus) executes flawlessly.
8
9	This is enterprise-grade project management: BA produces WHAT → Plan produces HOW (structured into phases) → ANY coder executes each phase with full context.
10
11	> Goal-first — leverage native goal/outcome commands (advisory, 2026). Current
12	> agent models (Opus 4.8, Sonnet 5, Fable 5) perform best when handed
13	> the full goal + constraints up front, then left to execute at high effort. Some
14	> platforms now expose this natively: Claude Code `/goal` sets a run's north-star;
15	> Managed Agents Outcomes (`user.define_outcome` + rubric) grade-and-iterate to a
16	> target. The master plan IS that goal contract in durable form — when a native
17	> goal/outcome command is present, seed it from the master plan's Overview +
18	> acceptance criteria instead of re-stating the goal loosely. Advisory only: the
19	> master plan + phase files stay the source of truth on every platform (goal/Outcome
20	> are single-session; the plan survives across sessions and platforms).
21
22	<HARD-GATE>
23	NEVER produce a single monolithic plan file for non-trivial tasks.
24	Non-trivial = 3+ phases OR 5+ files OR estimated > 100 LOC total change.
25	For non-trivial tasks: MUST produce master plan + separate phase files.
26	For trivial tasks (1-2 phases, < 5 files): inline plan is acceptable.
27	</HARD-GATE>
28
29	## Architecture: Master Plan + Phase Files
30
31	```
32	.rune/
33	plan-<feature>.md ← Master plan: phases overview, goals, status tracker (<80 lines)
34	plan-<feature>-phase1.md ← Phase 1 detail: tasks, acceptance criteria, files to touch (<200 lines)
35	plan-<feature>-phase2.md ← Phase 2 detail
36	...
37	```
38
39	### Why This Architecture
40
41	- Big context = even Opus misses details and makes mistakes
42	- Small context = Sonnet handles correctly, Opus has zero mistakes
43	- Phase isolation prevents cross-contamination of concerns
44	- Each session starts clean with only the relevant phase loaded
45	- Coder (Sonnet/Haiku) can execute a phase file without needing the full plan
46
47	### Size Constraints
48
49	\| File \| Max Lines \| Content \|
50	\|------\|-----------\|---------\|
51	\| Master plan \| 80 lines \| Overview, phase table, key decisions, status \|
52	\| Phase file \| 200 lines \| Amateur-proof template: data flow, contracts, tasks, failures, NFRs, rejections, cross-phase \|
53	\| Total phases \| Max 8 \| If > 8 phases, split into sub-projects \|
54
55	## Modes
56
57	### Implementation Mode (default)
58	Standard implementation planning — decompose task into phased steps with code details.
59
60	### Feature Spec Mode
61	Product-oriented planning — write a feature specification before implementation.
62	Triggers: user says "spec", "feature spec", "write spec", "PRD" — or `/rune plan spec <feature>`
63
64	### Roadmap Mode
65	High-level multi-feature planning — organize features into milestones.
66	Triggers: user says "roadmap", "milestone", "release plan", "what to build next" — or `/rune plan roadmap`
67
68	## Triggers
69
70	- Called by `cook` when task scope > 1 file (Implementation Mode)
71	- Called by `team` for high-level task decomposition
72	- `/rune plan <task>` — manual planning
73	- `/rune plan spec <feature>` — feature specification
74	- `/rune plan roadmap` — roadmap planning
75	- Auto-trigger: when user says "implement", "build", "create" with complex scope
76
77	## Calls (outbound)
78
79	- `scout` (L2): scan codebase for existing patterns, conventions, and structure
80	- `brainstorm` (L2): when multiple valid approaches exist
81	- `adversary` (L2): optional red-team gate on critical plan output (features touching auth, payments, or data integrity)
82	- `research` (L3): external knowledge lookup
83	- `sequential-thinking` (L3): complex architecture with many trade-offs
84	- L4 extension packs: domain-specific architecture patterns
85	- `neural-memory` \| Before architecture decisions \| Recall past decisions on similar problems
86
87	## Called By (inbound)
88
89	- `cook` (L1): Phase 2 PLAN
90	- `team` (L1): task decomposition into parallel workst

People who liked this also viewed

6 picks

Type

plan

80stars21forks

View on GitHub

How to install plan?

rune-kit/rune/plan

$npx -y skills add Rune-kit/rune --skill plan

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# plan
2
3	## Purpose
4
5	Strategic planning engine for the Rune ecosystem. Produces a master plan + phase files architecture — NOT a single monolithic plan. The master plan is a concise overview (<80 lines) that references separate phase files, each containing enough detail (<200 lines) that ANY model can execute with high accuracy.
6
7	Design principle: Plan for the weakest coder. Phase files are designed so that even an Amateur-level model (Haiku) can execute them with minimal errors. When the plan satisfies the Amateur's needs, every model benefits — Junior (Sonnet) executes near-perfectly, Senior (Opus) executes flawlessly.
8
9	This is enterprise-grade project management: BA produces WHAT → Plan produces HOW (structured into phases) → ANY coder executes each phase with full context.
10
11	> Goal-first — leverage native goal/outcome commands (advisory, 2026). Current
12	> agent models (Opus 4.8, Sonnet 5, Fable 5) perform best when handed
13	> the full goal + constraints up front, then left to execute at high effort. Some
14	> platforms now expose this natively: Claude Code `/goal` sets a run's north-star;
15	> Managed Agents Outcomes (`user.define_outcome` + rubric) grade-and-iterate to a
16	> target. The master plan IS that goal contract in durable form — when a native
17	> goal/outcome command is present, seed it from the master plan's Overview +
18	> acceptance criteria instead of re-stating the goal loosely. Advisory only: the
19	> master plan + phase files stay the source of truth on every platform (goal/Outcome
20	> are single-session; the plan survives across sessions and platforms).
21
22	<HARD-GATE>
23	NEVER produce a single monolithic plan file for non-trivial tasks.
24	Non-trivial = 3+ phases OR 5+ files OR estimated > 100 LOC total change.
25	For non-trivial tasks: MUST produce master plan + separate phase files.
26	For trivial tasks (1-2 phases, < 5 files): inline plan is acceptable.
27	</HARD-GATE>
28
29	## Architecture: Master Plan + Phase Files
30
31	```
32	.rune/
33	plan-<feature>.md ← Master plan: phases overview, goals, status tracker (<80 lines)
34	plan-<feature>-phase1.md ← Phase 1 detail: tasks, acceptance criteria, files to touch (<200 lines)
35	plan-<feature>-phase2.md ← Phase 2 detail
36	...
37	```
38
39	### Why This Architecture
40
41	- Big context = even Opus misses details and makes mistakes
42	- Small context = Sonnet handles correctly, Opus has zero mistakes
43	- Phase isolation prevents cross-contamination of concerns
44	- Each session starts clean with only the relevant phase loaded
45	- Coder (Sonnet/Haiku) can execute a phase file without needing the full plan
46
47	### Size Constraints
48
49	\| File \| Max Lines \| Content \|
50	\|------\|-----------\|---------\|
51	\| Master plan \| 80 lines \| Overview, phase table, key decisions, status \|
52	\| Phase file \| 200 lines \| Amateur-proof template: data flow, contracts, tasks, failures, NFRs, rejections, cross-phase \|
53	\| Total phases \| Max 8 \| If > 8 phases, split into sub-projects \|
54
55	## Modes
56
57	### Implementation Mode (default)
58	Standard implementation planning — decompose task into phased steps with code details.
59
60	### Feature Spec Mode
61	Product-oriented planning — write a feature specification before implementation.
62	Triggers: user says "spec", "feature spec", "write spec", "PRD" — or `/rune plan spec <feature>`
63
64	### Roadmap Mode
65	High-level multi-feature planning — organize features into milestones.
66	Triggers: user says "roadmap", "milestone", "release plan", "what to build next" — or `/rune plan roadmap`
67
68	## Triggers
69
70	- Called by `cook` when task scope > 1 file (Implementation Mode)
71	- Called by `team` for high-level task decomposition
72	- `/rune plan <task>` — manual planning
73	- `/rune plan spec <feature>` — feature specification
74	- `/rune plan roadmap` — roadmap planning
75	- Auto-trigger: when user says "implement", "build", "create" with complex scope
76
77	## Calls (outbound)
78
79	- `scout` (L2): scan codebase for existing patterns, conventions, and structure
80	- `brainstorm` (L2): when multiple valid approaches exist
81	- `adversary` (L2): optional red-team gate on critical plan output (features touching auth, payments, or data integrity)
82	- `research` (L3): external knowledge lookup
83	- `sequential-thinking` (L3): complex architecture with many trade-offs
84	- L4 extension packs: domain-specific architecture patterns
85	- `neural-memory` \| Before architecture decisions \| Recall past decisions on similar problems
86
87	## Called By (inbound)
88
89	- `cook` (L1): Phase 2 PLAN
90	- `team` (L1): task decomposition into parallel workst

People who liked this also viewed

6 picks

Type