give-plan

Name: give-plan
Author: avibebuilder

109stars17forks

How to install give-plan?

avibebuilder/claude-prime/give-plan

$npx -y skills add avibebuilder/claude-prime --skill give-plan

Installs into the current project.

Summary

Use when the user wants a written, reviewable plan or spec produced before coding starts. Triggers on: mapping out changes without implementing, thinking through risks of upgrades or migrations, evaluating approaches before committing to one, writing specs for team review, phasin

Files · 1

View on GitHub

SKILL.md

1	ultrathink
2
3	## Core contract
4
5	Figure out the right approach, write a plan the user can inspect, and stop. Planning is not approval to implement — wait for explicit go-ahead before writing any code.
6
7	- Clarify only what would materially change the plan.
8	- Read the codebase before making claims. Distinguish confirmed facts, inferences, and unknowns — never hide uncertainty.
9	- Optimize for reviewability over momentum.
10
11	If already in native plan mode, this skill shapes how to plan; plan mode provides the workflow structure and must follow this skill guidelines.
12
13	## Process
14
15	Check conversation context and skip completed steps.
16
17	### 1. Clarify the planning goal
18	What kind of plan? Scoped implementation, phased feature, migration/rollout, architecture decision, or spec artifact. Ask only the questions that matter.
19
20	### 2. Ground in evidence
21	Read relevant files and search the codebase before proposing changes. Be explicit about what's confirmed from code vs. inferred vs. unknown.
22
23	### 3. Choose the right altitude
24	- Small change → concise plan with touchpoints and validation
25	- Multi-file feature → phased plan with dependencies
26	- Architecture choice → options, tradeoffs, recommendation
27	- Migration / rollout → sequencing, rollback, validation checkpoints
28
29	Don't force every request into the same template.
30
31	### 4. Write the plan (right-size the artifact)
32	Match artifact to plan size — don't force `plans/*.md` on small scoped changes.
33
34	- Inline prose — small single-file tweaks, quick scoped edits, brief decisions. Present the plan in the response and stop.
35	- `plans/YYYYMMDDHHMMSS-{plan-name}.md` — multi-file features, migrations, architecture decisions, anything that benefits from review or history.
36	- `plans/YYYYMMDDHHMMSS-{plan-name}/plan.md` + phase files — large multi-phase work where each phase warrants independent reading/editing.
37
38	Use `date +%Y%m%d%H%M%S` for timestamps.
39
40	A strong plan covers: problem summary, recommended approach, phases/workstreams, affected files/modules/systems, dependencies and sequencing, validation strategy, risks and mitigations, assumptions and open questions, non-goals when useful.
41
42	### 5. Present and stop
43	Summarize the recommendation, call out risks/assumptions/unknowns, clarify what needs user confirmation, then wait. Do not drift into coding.
44
45	## Boundaries
46
47	- Prose, not code — describe what changes in prose (name the file, the concept); never include executable syntax (function bodies, JSX, SQL, migration scripts, shell commands). "Illustrative" snippets are still implementation code.
48	- Right-sized artifacts — don't force heavyweight structure onto small work; don't leave plans so abstract they name no touchpoints or validation path.
49	- Every plan needs a validation path — how will you know the implementation succeeded?
50	- Name concrete files, interfaces, and systems where possible. Surface tradeoffs instead of hiding them.
51
52	## Request
53
54	<request>$ARGUMENTS</request>

People who liked this also viewed

6 picks

Type

give-plan

109stars17forks

View on GitHub

How to install give-plan?

avibebuilder/claude-prime/give-plan

$npx -y skills add avibebuilder/claude-prime --skill give-plan

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	ultrathink
2
3	## Core contract
4
5	Figure out the right approach, write a plan the user can inspect, and stop. Planning is not approval to implement — wait for explicit go-ahead before writing any code.
6
7	- Clarify only what would materially change the plan.
8	- Read the codebase before making claims. Distinguish confirmed facts, inferences, and unknowns — never hide uncertainty.
9	- Optimize for reviewability over momentum.
10
11	If already in native plan mode, this skill shapes how to plan; plan mode provides the workflow structure and must follow this skill guidelines.
12
13	## Process
14
15	Check conversation context and skip completed steps.
16
17	### 1. Clarify the planning goal
18	What kind of plan? Scoped implementation, phased feature, migration/rollout, architecture decision, or spec artifact. Ask only the questions that matter.
19
20	### 2. Ground in evidence
21	Read relevant files and search the codebase before proposing changes. Be explicit about what's confirmed from code vs. inferred vs. unknown.
22
23	### 3. Choose the right altitude
24	- Small change → concise plan with touchpoints and validation
25	- Multi-file feature → phased plan with dependencies
26	- Architecture choice → options, tradeoffs, recommendation
27	- Migration / rollout → sequencing, rollback, validation checkpoints
28
29	Don't force every request into the same template.
30
31	### 4. Write the plan (right-size the artifact)
32	Match artifact to plan size — don't force `plans/*.md` on small scoped changes.
33
34	- Inline prose — small single-file tweaks, quick scoped edits, brief decisions. Present the plan in the response and stop.
35	- `plans/YYYYMMDDHHMMSS-{plan-name}.md` — multi-file features, migrations, architecture decisions, anything that benefits from review or history.
36	- `plans/YYYYMMDDHHMMSS-{plan-name}/plan.md` + phase files — large multi-phase work where each phase warrants independent reading/editing.
37
38	Use `date +%Y%m%d%H%M%S` for timestamps.
39
40	A strong plan covers: problem summary, recommended approach, phases/workstreams, affected files/modules/systems, dependencies and sequencing, validation strategy, risks and mitigations, assumptions and open questions, non-goals when useful.
41
42	### 5. Present and stop
43	Summarize the recommendation, call out risks/assumptions/unknowns, clarify what needs user confirmation, then wait. Do not drift into coding.
44
45	## Boundaries
46
47	- Prose, not code — describe what changes in prose (name the file, the concept); never include executable syntax (function bodies, JSX, SQL, migration scripts, shell commands). "Illustrative" snippets are still implementation code.
48	- Right-sized artifacts — don't force heavyweight structure onto small work; don't leave plans so abstract they name no touchpoints or validation path.
49	- Every plan needs a validation path — how will you know the implementation succeeded?
50	- Name concrete files, interfaces, and systems where possible. Surface tradeoffs instead of hiding them.
51
52	## Request
53
54	<request>$ARGUMENTS</request>

People who liked this also viewed

6 picks

Type