Plan

Break an approved spec or design into a precise, executable implementation plan. Use after the what/why and the shape are agreed, and before writing implementation code for any multi-step task.From its SKILL.md

Install

npx -y skills add vasu-devs/Forge --skill plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
runs commandsInstructs the agent to run 3 commands, including `forge:tdd` and 2 more.

SKILL.md

3.3 KB, 729 tokens by cl100k_base, as published. Nobody here has run it

██████╗ ██╗      █████╗ ███╗   ██╗
██╔══██╗██║     ██╔══██╗████╗  ██║
██████╔╝██║     ███████║██╔██╗ ██║
██╔═══╝ ██║     ██╔══██║██║╚██╗██║
██║     ███████╗██║  ██║██║ ╚████║
╚═╝     ╚══════╝╚═╝  ╚═╝╚═╝  ╚═══╝

Plan in vertical, executable slices

A plan good enough that a context-free executor with questionable taste could follow it without guessing. Vague plans get vague work.

Slices are vertical tracer bullets

Each task cuts end-to-end through whatever layers the artifact actually has and leaves the program working. For a web feature that may be schema → API → logic → UI → tests; for a CLI it's flag → handler → output; for a library it's public function → behavior → test. The rule is end-to-end-to-an-observable-result — not a fixed layer list. Never slice horizontally (all of one layer, then all of the next) — horizontal slices can't be verified until the end and hide integration problems until they're expensive.

Among valid first slices, pick the one that retires the most risk — the integration most likely to be wrong (the unproven third-party call, the gnarly migration), not merely the easiest. De-risk first; polish later.

Each task is bite-sized and test-shaped

Size each task to one RED→GREEN→commit cycle — the minimum change that makes exactly one new test pass. If a task needs two assertions about two different behaviors, split it. (The loop itself lives in forge:tdd — don't restate it; plan just chooses the slices.)

Write each task so a context-free executor can run it. Give every task these fields:

id (T1, T2…) + a one-line intent
target — the file(s) and the function/signature it adds or changes
test — the assertion that should fail first, then pass (the success criterion — a concrete check, never "make it work")
blocked-by — real task IDs, or "none"

(This is forge:principles #4 made concrete.)

No placeholders

The executor may read tasks out of order and has no context beyond the plan. Therefore:

No "TBD", no "add appropriate error handling", no "handle edge cases."
No "similar to Task 3" — restate the actual intent/code, because Task 3 may not have been read.
If a value, path, or signature matters, write it down.

Order and parallelism

Order by dependency. Reference blockers by real task IDs ("blocked by T2"), added only once T2 exists.
Mark which tasks are independent and safe to parallelize — hand those to forge:orchestrate to run concurrently with fresh agents.
Keep the plan in a file, not just the conversation — it's a durable artifact that survives compaction.

Exit

Execute with forge:tdd (one slice at a time), request forge:review after meaningful chunks, and forge:verify before claiming done.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 1 of the 12 instructions most plan spec skills give in 729 tokens

Counted across 1,360 of the 2,617 authors here whose files we hold, read 2026-09-06

Ask one question at a timein 73 of 1360
Write the spec using the templatein 22 of 1360
Ask clarifying questions if neededin 19 of 1360, across 18 files
Wait for user confirmation before proceedingin 19 of 1360
Save plans to the plans directoryin 17 of 1360, across 13 files
Check for product marketing context firstin 16 of 1360, across 5 files
Read the plan file completelyin 16 of 1360
Order tasks by dependencyhere, and in 16 of 1360
Gather context from the conversationin 15 of 1360, across 9 files
Explore the codebase instead of askingin 15 of 1360, across 13 files
Wait for explicit user approvalin 14 of 1360, across 13 files
Quiz the user on the breakdownin 13 of 1360, across 7 files

Said here and by no other author read

Pick the first slice that retires the most risk
Size each task to one test cycle
Include id, target, test, and blocked-by fields
Exclude placeholders and vague instructions
Execute using test-driven development
Request review after meaningful chunks

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.