Forward Plan by escoffier-labs — AI Skill for Any LLM

Overview

Publisher	escoffier-labs
Repository	`brigade`
Skill name	`forward-plan`
Stars	82
Forks	9
Bundled files	3
License	MIT
Links	Skill source Repository Homepage

Markdown instructions

A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

Works with any LLM

AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

3 bundled files

Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

Open source

Published by escoffier-labs on GitHub. Read the source before you install it.

Installation

Install the Forward Plan AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

Open the app and go to Plugins → Skills.
Choose "Install from GitHub".
Paste the skill folder URL below and confirm.
https://github.com/escoffier-labs/brigade/tree/main/src/brigade/templates/skills/forward-plan
Enable the skill in any chat where you want it available.

Store

Installed

Skills

Add skills

Import one or more skills from a public GitHub folder or a local .skill or .zip archive, or SKILL.md file.

From GitHub URLFrom .skill, .zip, or SKILL.md

GitHub repo or folder

https://github.com/escoffier-labs/brigade/tree/main/src/brigade/templates/skills/forward-plan

Points to a single skill folder, or any folder that contains multiple skills. Public repos only.

CancelContinue

Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills

git clone --depth 1 https://github.com/escoffier-labs/brigade.git /tmp/brigade
mkdir -p .claude/skills
cp -r /tmp/brigade/src/brigade/templates/skills/forward-plan .claude/skills/forward-plan

Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Forward Plan in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Forward Plan on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Forward Plan is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

Loaded only when it is needed

The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

Switch models mid-chat

Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

forward-plan

Turn the native ready set, outcome ranking, and the repo ROADMAP into one dependency-filed plan artifact. Brigade stays invoke-only. This skill is the allowlist-bound agent recipe. It is a registry skill, never a CLI subcommand - the planning sequence stays inspectable.

When this applies

You need a forward plan that joins what is ready now with roadmap direction.
An operator schedules a headless harness against this skill for planning.
The workspace has (or can create) .brigade/work/ and may or may not have GraphTrail installed.

Allowlist

Work only through this allowlist:

brigade work ready --json (add --explain when blocked items matter)
brigade outcome rank --json (optional --by-capability / --recency)
Read of repo-root ROADMAP.md under the parse contract below
brigade code … for GraphTrail footprint / impact / doctor checks
brigade work task edge … / brigade work task add --graph … only after an operator confirms derived edges (never auto-apply. See Safety gates)
brigade work plans to list existing plan artifacts
Write only under .brigade/work/plans/ (the plan JSON + plan.md pair)
Read/Grep of on-disk task ledgers, existing plans, and code paths named by GraphTrail output

Bash is scoped to those brigade … commands only. Do not expand into arbitrary shell, remote APIs, or writes outside .brigade/work/plans/. Stay inside the target workspace. Do not follow .. or symlinks out of it.

Safety gates

Plan draft is not graph-ingest input. A forward-plan draft under .brigade/work/plans/ (the .json / .plan.md pair) is not valid input to brigade work task add --graph. That command expects a graph-ingest file shaped for task creation with edges. Feeding it a plan draft can create task nodes while applying zero proposed edges from proposed_edges.

Confirmation is procedural, not enforced by the allowlist. Derived-edge confirmation is an operator-in-the-loop gate. The broad Bash(brigade work task:*) allowed-tool pattern does not enforce it, so this recipe must not run any mutating brigade work task … or brigade work task edge … command before the operator gives explicit confirmation.

Inputs

Native ready set - brigade work ready --json (from the work ledger dependency edges / ready resolver). Prefer --explain when the ready set is empty so blocked paths are visible. Ready items may carry optional seat_class (mechanical | judgment | review) and spend_by (ISO-8601 deadline) annotations for quota-driven dispatch routing. Pass those through when proposing or filing work; never invent a model id. When creating or annotating tasks after confirmation, emit them with brigade work task add … --seat-class … --spend-by … or brigade work task annotate <id> …, or as metadata.seat_class / metadata.spend_by on --graph nodes. Absent annotations change nothing.
Outcome rank - brigade outcome rank --json. Use ranking only as a soft priority signal for ordering proposed work, never as a substitute for readiness.
ROADMAP.md - repo-root roadmap, parsed with the contract below.

ROADMAP.md parse contract

Read only the repo-root file ROADMAP.md (or the path the operator names as that roadmap). Heading shapes:

Heading shape	Action
`# …` (document title)	Ignore for item extraction. Context only.
`## Now…` / `## Current…`	Read. Collect `-` / `*` bullets as active candidates.
`## Next…`	Read. Collect bullets as near-term candidates (below Now).
`## Later…`	Read. Collect bullets as deferred candidates (lowest priority).
`## Vocabulary` / `## How items move` / archive / process sections	Ignore.
`## Where things stand` / status snapshot sections	Ignore for new plan nodes (background only).
Any other `##` / `###`	Ignore unless the operator explicitly names it in scope.

Bullet rules:

Only lines starting with - or * under an included section become candidates. Nested prose paragraphs, tables, and fenced code are ignored.
Bold lead-ins (- **Title.** rest) keep the title as the candidate label. The rest is supporting detail.
Links, archive pointers, and "Status: implemented" closure notes do not create new plan nodes on their own.
Do not invent roadmap items that are not on-disk bullets under an included heading.

Output: dependency-filed plan artifact

Write a paired artifact under .brigade/work/plans/:

.brigade/work/plans/<plan-id>.json
.brigade/work/plans/<plan-id>.plan.md

Choose <plan-id> as forward-plan-<UTC-YYYYMMDDTHHMMSSZ> (filesystem-safe). Use the shipped plan.template.json shape in this skill directory as the JSON contract. Required fields:

kind: "forward-plan"
status: "draft" until an operator accepts. Never auto-accept
inputs: records of ready-set, outcome-rank, and roadmap sources used
nodes: proposed or existing work items (ready tasks first, then Now/Next roadmap candidates not already covered)
proposed_edges: dependency proposals (see below)
graphtrail: availability, snapshot identity when known, and degradation note
next_command: a safe next step (default review the draft. Never a mutating apply)

The .plan.md mirrors the JSON: summary, nodes, proposed edges (calling out derived + unconfirmed), GraphTrail status, and next safe command.

Derived dependency edges (GraphTrail impact intersection)

When GraphTrail is available (brigade code doctor / impact / neighbors work):

Build a footprint per candidate node (files + symbol ids) from GraphTrail context/impact, stamped with the graph snapshot you queried.
Pairwise impact intersection over open / proposed nodes:
- def/use ordering → directed blocks (definer/source blocks consumer/target)
- write overlap (same files written) → unordered conflicts-with
Every such edge is derived: set derived: true, record rule (def-use or write-overlap), and a snapshot_hash (or graph identity). Set confirmed: false.
Derived edges require confirmation before they become real ledger edges. Do not call work task edge add or --graph apply for derived edges until an operator confirms them.
Only derived edges may be auto-retracted by a later reconcile recipe (see scheduled-care / outcome reconcile docs). Authored (human-confirmed) edges are never auto-deleted by this skill. If GraphTrail later contradicts them, flag the contradiction in the plan, do not silently remove them.

conflicts-with is proposal-only in the plan artifact today (the native ledger edge types are blocks, parent-child, discovered-from). On confirmation, file native blocks edges that the operator accepts. Keep confirmed conflicts-with in the plan as parallel-safety advisories unless a native type exists.

GraphTrail unavailable (degrade cleanly)

If GraphTrail is missing, the DB is absent, or brigade code … fails:

Propose no derived edges (proposed_edges: []).
Set graphtrail.available to false and state plainly in both JSON and plan.md: "GraphTrail unavailable. No derived dependency edges proposed."
Still write the plan from the ready set, outcome rank, and ROADMAP parse.
Do not invent edges from prose guesswork.

Process

Run brigade work ready --json (and --explain if ready is empty).
Run brigade outcome rank --json.
Read ROADMAP.md under the parse contract. Collect Now / Next / Later bullets.
Probe GraphTrail (brigade code doctor or a cheap brigade code stats). If unavailable, skip to step 6 with empty proposed edges and say so.
Otherwise compute footprints and propose derived edges from impact intersection. Mark each derived + unconfirmed.
Soft-order nodes: ready set first, then outcome-rank hints, then Now, Next, Later roadmap candidates.
Write .brigade/work/plans/<plan-id>.json and .plan.md from the template contract. Leave status: draft.
Stop. Present the artifact paths and wait for confirmation before filing any ledger edges. Capture outcomes against forward-plan when verification is part of the run.

Failure paths

Missing .brigade/ / work ledger / target: stop. Report the missing path. Do not invent a ledger or run against the operator home.
Empty ready set and no includable ROADMAP bullets: exit cleanly with "nothing to plan". Write no artifact (or write a draft that says so and lists zero nodes - prefer no artifact when both inputs are empty).
Missing ROADMAP.md: continue with ready set + outcome rank only. Note the missing roadmap in inputs and do not invent roadmap nodes.
Malformed ready / rank JSON or unreadable ROADMAP: skip the bad input, say so, continue with what remains. Never rewrite ledger or roadmap files to "fix" parse errors.
GraphTrail errors mid-probe: degrade as above (no derived edges, say so).

Out of scope

New CLI subcommands or changing the work ledger schema
Auto-applying derived edges without confirmation
Scheduler or model-dispatch integration
Auto-retracting authored edges

Frequently asked questions

What does the Forward Plan AI skill do?

Use when turning Brigade's native ready set, outcome rank, and ROADMAP.md into a dependency-filed plan artifact under .brigade/work/plans/ - propose GraphTrail-derived edges (blocks from def/use, conflicts-with from write overlap) marked derived and requiring confirmation. Degrade cleanly when GraphTrail is unavailable. Never a subcommand.

Why use Forward Plan on TypingMind?

Because you install it once and use it with any model. Forward Plan is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Forward Plan in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/escoffier-labs/brigade/tree/main/src/brigade/templates/skills/forward-plan. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Forward Plan?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Forward Plan?

As many as you like. As long as a model supports skills, you can use Forward Plan with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Forward Plan AI skill free?

Yes. It is published on GitHub by escoffier-labs under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

Overview

Installation

Install in TypingMind

Install in another agent

Use it in TypingMind

Works with any AI model

Skill instructions

forward-plan

When this applies

Allowlist

Safety gates

Inputs

ROADMAP.md parse contract

Output: dependency-filed plan artifact

Derived dependency edges (GraphTrail impact intersection)

GraphTrail unavailable (degrade cleanly)

Process

Failure paths

Out of scope

Bundled files

Frequently asked questions

Related AI Skills

Set up your own AI workspace now