simple-plan

Name: simple-plan
Author: Codagent-AI

28stars1forks

How to install simple-plan?

codagent-ai/agent-skills/simple-plan

$npx -y skills add Codagent-AI/agent-skills --skill simple-plan

Installs into the current project.

Summary

Lightweight planning for small, quick changes. Combines propose, spec, and (optionally) design into one conversational pass, then writes tasks.md so the change is ready for implementation. Activates when users ask for "simple plan", "quick plan", "plan this", or "planning mode" f

Files · 1

View on GitHub

SKILL.md

1	# Simple Plan
2
3	## Overview
4
5	Rapid, lightweight planning for small changes. One conversation produces a `proposal.md`, one or more spec files, an optional `design.md`, and a `tasks.md` placeholder so the change is ready for implementation.
6
7	> Key principle — write for a different agent. The artifacts you produce will be handed to a separate implementing agent that has zero shared context from this conversation. Every decision, rationale, constraint, file path, naming convention, and behavioral detail must be captured in the written artifacts. If you discussed it but didn't write it down, the implementer won't know about it.
8
9	## Flow
10
11	1. Understand — Ask the user what the change is about (problem, desired behavior, scope) when not already explicit.
12	2. Orient quickly — Before asking questions, do a light survey so your questions are grounded:
13	- Related existing specs — scan spec files in neighboring or overlapping capabilities for conflicts, dependencies, and naming conventions. For modified capabilities, locate the existing spec now.
14	- Code, when appropriate — if the change touches existing code, skim the relevant files/modules to understand current behavior. Skip this for greenfield work, pure doc changes, or anything where reading code wouldn't change what you ask.
15	Keep it light — this is a quick orientation, not the deep research pass from `propose` or `design`.
16	3. Clarify — Follow the `codagent:ask-questions` skill to gather information. Keep the conversation tight — a handful of questions total, not a full interview. Focus on:
17	- Behaviors, boundaries, and error/edge cases (for the specs — this is the load-bearing part)
18	- Scope boundaries (what's in, what's out)
19	- Any architectural question that would actually change the specs — otherwise skip it
20	Ask these as concrete discovery questions before presenting the plan or writing artifacts. Include recommendations when options have trade-offs. A final "thumbs-up" confirmation is not a substitute for clarifying the behavior.
21	4. Decide if a design doc is needed — Default: no. Write `design.md` when:
22	- There's a real architectural choice whose rationale needs to survive (e.g., a non-obvious trade-off future contributors would re-litigate), or
23	- There are specific implementation details (algorithms, data-structure choices, integration points, migration steps, error-handling strategies, etc.) that came up in conversation but don't belong in behavioral specs. Because a different agent will implement the change, these details must be written down somewhere — `design.md` is that somewhere.
24
25	A small code change, a config tweak, a straightforward CRUD addition, or anything where "the code is the design" does not need one. When in doubt, ask whether the implementer would have enough information without it.
26	5. Confirm the plan — Briefly restate: capabilities to spec, whether a design doc will be written, and output location. Before confirming, do a quick self-check: did you ask only questions that mattered, avoid discoverable facts, and choose obvious implementation defaults yourself? End with a compact "Low-level decisions I made" list for any defaults you chose from context.
27	6. Write all the docs in one pass — `proposal.md`, one `specs/<capability>/spec.md` per capability, optionally `design.md`, and `tasks.md`.
28
29	## Output location
30
31	Follow the project's convention if one exists (e.g., AGENTS.md, a project config, or similar conventions). Otherwise default to `changes/<kebab-slug>/` and confirm with the user before writing.
32
33	## Specs — the load-bearing artifact
34
35	Specs outlive everything else in this skill — they become the living source of truth for the change. Get them right:
36
37	- Every requirement MUST have at least one scenario.
38	- Scenarios use `#### Scenario:` (exactly four hashtags) with WHEN/THEN.
39	- Use SHALL/MUST for normative language.
40	- Describe observable behavior — not file contents or internal structure.
41	- If a behavior genuinely depends on an architectural choice you haven't made, mark it `<!-- deferred-to-design: <reason> -->` — but for a simple plan, you should usually just decide and move on.
42
43	The proposal and (optional) design exist to scaffold the specs. The specs are what matter.
44
45	## tasks.md
46
47	Write a placeholder `tasks.md` — no actual task breakdown. This skill produces one-shot, self-contained plans; a different agent reads the files directly to implement the change.
48
49	Because the implementer has no context beyond these artifacts, the task entry must link to every

People who liked this also viewed

6 picks

Type

simple-plan

28stars1forks

View on GitHub

How to install simple-plan?

codagent-ai/agent-skills/simple-plan

$npx -y skills add Codagent-AI/agent-skills --skill simple-plan

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Simple Plan
2
3	## Overview
4
5	Rapid, lightweight planning for small changes. One conversation produces a `proposal.md`, one or more spec files, an optional `design.md`, and a `tasks.md` placeholder so the change is ready for implementation.
6
7	> Key principle — write for a different agent. The artifacts you produce will be handed to a separate implementing agent that has zero shared context from this conversation. Every decision, rationale, constraint, file path, naming convention, and behavioral detail must be captured in the written artifacts. If you discussed it but didn't write it down, the implementer won't know about it.
8
9	## Flow
10
11	1. Understand — Ask the user what the change is about (problem, desired behavior, scope) when not already explicit.
12	2. Orient quickly — Before asking questions, do a light survey so your questions are grounded:
13	- Related existing specs — scan spec files in neighboring or overlapping capabilities for conflicts, dependencies, and naming conventions. For modified capabilities, locate the existing spec now.
14	- Code, when appropriate — if the change touches existing code, skim the relevant files/modules to understand current behavior. Skip this for greenfield work, pure doc changes, or anything where reading code wouldn't change what you ask.
15	Keep it light — this is a quick orientation, not the deep research pass from `propose` or `design`.
16	3. Clarify — Follow the `codagent:ask-questions` skill to gather information. Keep the conversation tight — a handful of questions total, not a full interview. Focus on:
17	- Behaviors, boundaries, and error/edge cases (for the specs — this is the load-bearing part)
18	- Scope boundaries (what's in, what's out)
19	- Any architectural question that would actually change the specs — otherwise skip it
20	Ask these as concrete discovery questions before presenting the plan or writing artifacts. Include recommendations when options have trade-offs. A final "thumbs-up" confirmation is not a substitute for clarifying the behavior.
21	4. Decide if a design doc is needed — Default: no. Write `design.md` when:
22	- There's a real architectural choice whose rationale needs to survive (e.g., a non-obvious trade-off future contributors would re-litigate), or
23	- There are specific implementation details (algorithms, data-structure choices, integration points, migration steps, error-handling strategies, etc.) that came up in conversation but don't belong in behavioral specs. Because a different agent will implement the change, these details must be written down somewhere — `design.md` is that somewhere.
24
25	A small code change, a config tweak, a straightforward CRUD addition, or anything where "the code is the design" does not need one. When in doubt, ask whether the implementer would have enough information without it.
26	5. Confirm the plan — Briefly restate: capabilities to spec, whether a design doc will be written, and output location. Before confirming, do a quick self-check: did you ask only questions that mattered, avoid discoverable facts, and choose obvious implementation defaults yourself? End with a compact "Low-level decisions I made" list for any defaults you chose from context.
27	6. Write all the docs in one pass — `proposal.md`, one `specs/<capability>/spec.md` per capability, optionally `design.md`, and `tasks.md`.
28
29	## Output location
30
31	Follow the project's convention if one exists (e.g., AGENTS.md, a project config, or similar conventions). Otherwise default to `changes/<kebab-slug>/` and confirm with the user before writing.
32
33	## Specs — the load-bearing artifact
34
35	Specs outlive everything else in this skill — they become the living source of truth for the change. Get them right:
36
37	- Every requirement MUST have at least one scenario.
38	- Scenarios use `#### Scenario:` (exactly four hashtags) with WHEN/THEN.
39	- Use SHALL/MUST for normative language.
40	- Describe observable behavior — not file contents or internal structure.
41	- If a behavior genuinely depends on an architectural choice you haven't made, mark it `<!-- deferred-to-design: <reason> -->` — but for a simple plan, you should usually just decide and move on.
42
43	The proposal and (optional) design exist to scaffold the specs. The specs are what matter.
44
45	## tasks.md
46
47	Write a placeholder `tasks.md` — no actual task breakdown. This skill produces one-shot, self-contained plans; a different agent reads the files directly to implement the change.
48
49	Because the implementer has no context beyond these artifacts, the task entry must link to every

People who liked this also viewed

6 picks

Type