planner-spec-expand

Name: planner-spec-expand
Author: Archive228

712stars129forks

How to install planner-spec-expand?

archive228/loopkit/planner-spec-expand

$npx -y skills add Archive228/loopkit --skill planner-spec-expand

Installs into the current project.

Summary

Expand a 1-4 sentence product brief into a full spec with a design language, acceptance surface, and an ordered feature list.

Files · 1

View on GitHub

SKILL.md

1	# Planner Spec Expand
2
3	A one-line brief ("build a claude.ai clone", "a habit tracker with streaks") is not enough surface for a coding agent to make good decisions from. It has no design language, no acceptance criteria, no ordering. The generator ends up inventing scope mid-session and shipping incoherent slices.
4
5	The planner's job is to expand the brief into a spec dense enough that every downstream decision — what feature to pick, what "done" looks like, what the button should say — has an answer already written down. See Prithvi's post on planner/generator/evaluator separation for the underlying architecture: https://www.prithvirajrk.com/blog/three-agent-harness.
6
7	## When to apply
8
9	- The user handed you a brief under ~200 words and expects a real product.
10	- You're about to seed [[feature-list-json]] and the brief has no orderable features yet.
11	- Scope drifted mid-project and the original spec no longer describes the target — rewrite, don't patch.
12
13	## Procedure — expand in this order
14
15	Do the sections in order. Later sections depend on earlier ones being locked.
16
17	1. Restate the brief in one paragraph. In your own words, what is being built and for whom. If you can't write this cleanly, ask the user before continuing — the brief is under-specified.
18	2. Pick a design language. One sentence each on: visual tone (minimal / dense / playful), typography stance (one sans / serif+sans / mono accents), color posture (monochrome + one accent / two-color / full palette), density (airy / compact). This locks a thousand later micro-decisions.
19	3. Enumerate the acceptance surface. For each user-observable capability, write one sentence of user-observable behavior AND the concrete steps a human would take to verify it. This is the shape [[feature-list-json]] wants — write it in that shape now.
20	4. Order the features. Sort by dependency: nothing appears before what it depends on. Ties broken by "what does the user see first when they open the app." The top of the list must be runnable-alone.
21	5. Name the out-of-scope. One short list of things the brief could imply but you are explicitly not building. Prevents the generator from wandering.
22	6. Write the smoke path. The single user journey that proves the product exists — 3-6 steps end-to-end. This becomes the initializer's smoke test.
23
24	## Checklist before you hand off
25
26	- Every feature has `description` + `steps` in the shape [[feature-list-json]] expects.
27	- The first 3 features can be built in order with no forward dependency.
28	- Design language fits on one screen — if it's a page, you over-specified.
29	- Out-of-scope list is non-empty. If everything is in scope, you didn't plan, you transcribed.
30	- Smoke path touches the core value prop, not auth or settings.
31
32	## Anti-patterns
33
34	- Padding the feature list to look thorough. 40 real features beats 200 fake ones. The generator will build all of them.
35	- Designing the schema. That's the generator's job. You describe user-observable behavior; the generator picks the data model.
36	- Writing prose where you should write steps. "User can manage conversations" is not a feature. "Clicking the trash icon on a sidebar item deletes that conversation and removes it from the sidebar" is.
37	- Leaving priority implicit. If two features tie, break the tie now. The generator will not.
38
39	## When NOT to apply
40
41	Skip this for briefs already specified to acceptance-criteria depth, or for single-feature edits to an existing project — use [[shift-notes]] and pick from the existing [[feature-list-json]] instead.
42
43	Related: [[feature-list-json]], [[shift-notes]], [[broken-window-check]].

People who liked this also viewed

6 picks

Type

planner-spec-expand

712stars129forks

View on GitHub

How to install planner-spec-expand?

archive228/loopkit/planner-spec-expand

$npx -y skills add Archive228/loopkit --skill planner-spec-expand

Installs into the current project.

Summary

Expand a 1-4 sentence product brief into a full spec with a design language, acceptance surface, and an ordered feature list.

Files · 1

View on GitHub

SKILL.md

1	# Planner Spec Expand
2
3	A one-line brief ("build a claude.ai clone", "a habit tracker with streaks") is not enough surface for a coding agent to make good decisions from. It has no design language, no acceptance criteria, no ordering. The generator ends up inventing scope mid-session and shipping incoherent slices.
4
5	The planner's job is to expand the brief into a spec dense enough that every downstream decision — what feature to pick, what "done" looks like, what the button should say — has an answer already written down. See Prithvi's post on planner/generator/evaluator separation for the underlying architecture: https://www.prithvirajrk.com/blog/three-agent-harness.
6
7	## When to apply
8
9	- The user handed you a brief under ~200 words and expects a real product.
10	- You're about to seed [[feature-list-json]] and the brief has no orderable features yet.
11	- Scope drifted mid-project and the original spec no longer describes the target — rewrite, don't patch.
12
13	## Procedure — expand in this order
14
15	Do the sections in order. Later sections depend on earlier ones being locked.
16
17	1. Restate the brief in one paragraph. In your own words, what is being built and for whom. If you can't write this cleanly, ask the user before continuing — the brief is under-specified.
18	2. Pick a design language. One sentence each on: visual tone (minimal / dense / playful), typography stance (one sans / serif+sans / mono accents), color posture (monochrome + one accent / two-color / full palette), density (airy / compact). This locks a thousand later micro-decisions.
19	3. Enumerate the acceptance surface. For each user-observable capability, write one sentence of user-observable behavior AND the concrete steps a human would take to verify it. This is the shape [[feature-list-json]] wants — write it in that shape now.
20	4. Order the features. Sort by dependency: nothing appears before what it depends on. Ties broken by "what does the user see first when they open the app." The top of the list must be runnable-alone.
21	5. Name the out-of-scope. One short list of things the brief could imply but you are explicitly not building. Prevents the generator from wandering.
22	6. Write the smoke path. The single user journey that proves the product exists — 3-6 steps end-to-end. This becomes the initializer's smoke test.
23
24	## Checklist before you hand off
25
26	- Every feature has `description` + `steps` in the shape [[feature-list-json]] expects.
27	- The first 3 features can be built in order with no forward dependency.
28	- Design language fits on one screen — if it's a page, you over-specified.
29	- Out-of-scope list is non-empty. If everything is in scope, you didn't plan, you transcribed.
30	- Smoke path touches the core value prop, not auth or settings.
31
32	## Anti-patterns
33
34	- Padding the feature list to look thorough. 40 real features beats 200 fake ones. The generator will build all of them.
35	- Designing the schema. That's the generator's job. You describe user-observable behavior; the generator picks the data model.
36	- Writing prose where you should write steps. "User can manage conversations" is not a feature. "Clicking the trash icon on a sidebar item deletes that conversation and removes it from the sidebar" is.
37	- Leaving priority implicit. If two features tie, break the tie now. The generator will not.
38
39	## When NOT to apply
40
41	Skip this for briefs already specified to acceptance-criteria depth, or for single-feature edits to an existing project — use [[shift-notes]] and pick from the existing [[feature-list-json]] instead.
42
43	Related: [[feature-list-json]], [[shift-notes]], [[broken-window-check]].

People who liked this also viewed

6 picks

Type