plan-mode

Name: plan-mode
Author: vercel-labs

159installs750forks

How to install plan-mode?

vercel-labs/open-agents/plan-mode

$npx -y skills add vercel-labs/open-agents --skill plan-mode

Installs into the current project.

Summary

plan-mode is an agent skill published from vercel-labs/open-agents, installable through the skills CLI.

Files · 1

View on GitHub

SKILL.md

1	For non-trivial implementation tasks, plan before you code. Treat every change as a system change, not an isolated patch. Your job is not just to find a working implementation; it is to find the smallest implementation that remains coherent with the architecture, lifecycle, and future evolution of the system.
2
3	## Planning Doctrine
4
5	- Think broadly, implement narrowly. Analyze the surrounding system before deciding where the change belongs.
6	- Every change has system implications. Consider how the request affects data flow, ownership of state, interfaces, lifecycle, failure modes, observability, and future extension.
7	- Prefer authoritative, derivable designs. If UI state or control flow can be derived from backend events, persisted state, shared protocols, or existing abstractions, prefer that over inventing transient client-only state.
8	- Choose the smallest coherent solution. Do not default to the smallest local patch if it distorts the architecture or adds hidden follow-on complexity.
9	- Expand scope only when it simplifies the system. Widen the implementation only when a local fix would create duplicated state, fragile coupling, lifecycle mismatches, or recurring complexity.
10	- Do not gold-plate. Make bounded architectural improvements that materially improve coherence for the task at hand.
11
12	## Plan File
13
14	Write your plan to a `PLAN.md` file in the project root. Build this file incrementally as you progress through the steps below -- do not wait until the end to write it all at once. If a plan file already exists, read it first and decide whether the current request is a new task (overwrite) or a continuation (revise).
15
16	## Step 1: Explore
17
18	Thoroughly explore the codebase to understand the request before designing anything.
19
20	- Read the relevant files and understand existing patterns, architecture, and conventions.
21	- Trace the end-to-end flow, not just the local implementation point.
22	- Identify the current source of truth, state ownership, boundaries between subsystems, and any existing invariants.
23	- Identify the full lifecycle of the behavior: trigger, processing, intermediate states, completion, side effects, failure, retry, and cleanup.
24	- Search for similar features and prior art in the codebase.
25	- Launch parallel explorations when the scope is uncertain or multiple areas of the codebase are involved. Give each exploration a specific, distinct search focus (e.g., one searches for existing implementations of similar features, another explores related components, a third investigates testing patterns). Use a single agent when the task is isolated to known files or the user provided specific file paths.
26	- Do not start implementing yet.
27
28	## Step 2: Clarify
29
30	Ask the user questions to resolve ambiguities before committing to an approach. This may cover technical implementation, desired system behavior, UI/UX, performance, edge cases, ownership of state, failure handling, or tradeoffs. You may ask multiple rounds, reading more code in between. Do not make large assumptions about user intent.
31
32	## Step 3: Design
33
34	Based on exploration and user input, design a concrete implementation approach:
35
36	- Provide comprehensive background context including filenames, code path traces, and the surrounding system behavior discovered in Step 1.
37	- Treat the request as a system modification, not just a local diff.
38	- Explicitly consider both:
39	- The most direct implementation
40	- The most system-coherent implementation
41	- Choose the direct implementation only if it does not introduce architectural distortion, duplicated state, fragile coupling, lifecycle mismatches, or hidden follow-on complexity.
42	- Prefer the smallest holistic solution: think broadly about implications, then keep the implementation as narrow as possible while preserving coherence.
43	- For complex tasks, consider multiple perspectives to arrive at the best approach:
44	- New feature: simplicity vs performance vs maintainability
45	- Bug fix: root cause fix vs workaround vs prevention
46	- Refactoring: minimal change vs clean architecture
47	- For tasks that touch multiple parts of the codebase, involve large refactors, or have many edge cases, explore different approaches in parallel before converging on a recommendation.
48
49	Before finalizing the design, explicitly answer these questions:
50
51	1. What part of the system is actually changing?
52	2. What is the source of truth before and after this change?
53	3. What new state, transitions, or invariants does this introduce?
54	4. What other components, flows, or interfaces now depend on this decision?
55	5. Does this create duplicated logic or state anywhere?
56	6. Is there a

People who liked this also viewed

6 picks

Type

plan-mode

159installs750forks

View on GitHub

How to install plan-mode?

vercel-labs/open-agents/plan-mode

$npx -y skills add vercel-labs/open-agents --skill plan-mode

Installs into the current project.

Summary

plan-mode is an agent skill published from vercel-labs/open-agents, installable through the skills CLI.

Files · 1

View on GitHub

SKILL.md

1	For non-trivial implementation tasks, plan before you code. Treat every change as a system change, not an isolated patch. Your job is not just to find a working implementation; it is to find the smallest implementation that remains coherent with the architecture, lifecycle, and future evolution of the system.
2
3	## Planning Doctrine
4
5	- Think broadly, implement narrowly. Analyze the surrounding system before deciding where the change belongs.
6	- Every change has system implications. Consider how the request affects data flow, ownership of state, interfaces, lifecycle, failure modes, observability, and future extension.
7	- Prefer authoritative, derivable designs. If UI state or control flow can be derived from backend events, persisted state, shared protocols, or existing abstractions, prefer that over inventing transient client-only state.
8	- Choose the smallest coherent solution. Do not default to the smallest local patch if it distorts the architecture or adds hidden follow-on complexity.
9	- Expand scope only when it simplifies the system. Widen the implementation only when a local fix would create duplicated state, fragile coupling, lifecycle mismatches, or recurring complexity.
10	- Do not gold-plate. Make bounded architectural improvements that materially improve coherence for the task at hand.
11
12	## Plan File
13
14	Write your plan to a `PLAN.md` file in the project root. Build this file incrementally as you progress through the steps below -- do not wait until the end to write it all at once. If a plan file already exists, read it first and decide whether the current request is a new task (overwrite) or a continuation (revise).
15
16	## Step 1: Explore
17
18	Thoroughly explore the codebase to understand the request before designing anything.
19
20	- Read the relevant files and understand existing patterns, architecture, and conventions.
21	- Trace the end-to-end flow, not just the local implementation point.
22	- Identify the current source of truth, state ownership, boundaries between subsystems, and any existing invariants.
23	- Identify the full lifecycle of the behavior: trigger, processing, intermediate states, completion, side effects, failure, retry, and cleanup.
24	- Search for similar features and prior art in the codebase.
25	- Launch parallel explorations when the scope is uncertain or multiple areas of the codebase are involved. Give each exploration a specific, distinct search focus (e.g., one searches for existing implementations of similar features, another explores related components, a third investigates testing patterns). Use a single agent when the task is isolated to known files or the user provided specific file paths.
26	- Do not start implementing yet.
27
28	## Step 2: Clarify
29
30	Ask the user questions to resolve ambiguities before committing to an approach. This may cover technical implementation, desired system behavior, UI/UX, performance, edge cases, ownership of state, failure handling, or tradeoffs. You may ask multiple rounds, reading more code in between. Do not make large assumptions about user intent.
31
32	## Step 3: Design
33
34	Based on exploration and user input, design a concrete implementation approach:
35
36	- Provide comprehensive background context including filenames, code path traces, and the surrounding system behavior discovered in Step 1.
37	- Treat the request as a system modification, not just a local diff.
38	- Explicitly consider both:
39	- The most direct implementation
40	- The most system-coherent implementation
41	- Choose the direct implementation only if it does not introduce architectural distortion, duplicated state, fragile coupling, lifecycle mismatches, or hidden follow-on complexity.
42	- Prefer the smallest holistic solution: think broadly about implications, then keep the implementation as narrow as possible while preserving coherence.
43	- For complex tasks, consider multiple perspectives to arrive at the best approach:
44	- New feature: simplicity vs performance vs maintainability
45	- Bug fix: root cause fix vs workaround vs prevention
46	- Refactoring: minimal change vs clean architecture
47	- For tasks that touch multiple parts of the codebase, involve large refactors, or have many edge cases, explore different approaches in parallel before converging on a recommendation.
48
49	Before finalizing the design, explicitly answer these questions:
50
51	1. What part of the system is actually changing?
52	2. What is the source of truth before and after this change?
53	3. What new state, transitions, or invariants does this introduce?
54	4. What other components, flows, or interfaces now depend on this decision?
55	5. Does this create duplicated logic or state anywhere?
56	6. Is there a

People who liked this also viewed

6 picks

Type