Plannotator logo

Plannotator

CommunityPopular
backnotprop
plannotator

Reference for using the Plannotator CLI: plan review, code review, annotating files, URLs, folders, and running local apps, annotating the last assistant message, browsing archived plan decisions, and exporting or sharing Guided Reviews. Invoke when asked to use Plannotator for anything not covered by a more specific plannotator-* skill.

Overview

Publisherbacknotprop
Repositoryplannotator
Skill nameplannotator
Stars
8.8K
Forks
658
Bundled files
1
LicenseApache-2.0
Links
  • 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.

  • 1 bundled files

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

  • Open source

    Published by backnotprop on GitHub. Read the source before you install it.

Installation

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

1

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.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

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/backnotprop/plannotator.git /tmp/plannotator
mkdir -p .claude/skills
cp -r /tmp/plannotator/apps/skills/core/plannotator .claude/skills/plannotator
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Plannotator 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 Plannotator 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 Plannotator 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.

Plannotator CLI Reference

Plannotator is a local, browser-based review layer for agent workflows: it opens plans, diffs, and documents in an annotation UI, the human marks them up, and the structured feedback comes back to you on stdout. It installs as a single plannotator binary plus per-host hooks, so plan review fires automatically when you exit plan mode; every other surface is launched explicitly from the CLI. A session runs on a random localhost port (fixed port 19432 in remote mode) and blocks until the reviewer submits feedback, approves, or closes the tab.

This skill is the knowledge layer. The plannotator-review, plannotator-annotate, and plannotator-last skills are thin launchers for the three most common actions; use this reference when you need to pick the right command or flags yourself.

Choose the command

The user wantsRun
Review a plan you producedNothing. Plan review opens automatically on plan exit via hooks. Never run bare plannotator yourself.
Review and explicitly approve a plan/spec saved as a fileplannotator annotate <file> --gate --json
Review current code changesplannotator review
Review a GitHub PR or GitLab MRplannotator review <PR_URL>
Annotate a markdown, text, config, or HTML fileplannotator annotate <file>
Annotate a web pageplannotator annotate <https-url>
Annotate a running local app (dev server)plannotator annotate <http://localhost:PORT/>
Pick a file to annotate from a folderplannotator annotate <folder/>
Annotate your latest assistant messageplannotator last
Browse past plan decisionsplannotator archive
Export or share a Guided Reviewplannotator guide export / plannotator guide share
Reopen or list live sessionsplannotator sessions

Session model

Every review or annotate command starts a local web server, opens the browser, and blocks until the human decides. That can take minutes. Launch it with a long (or no) command timeout, or in the background, then read stdout when the process exits. Do not kill the process to "finish" a review; a session that ends without a decision reads as no feedback.

Stdout is the interface, but its contract is command-specific. For annotate and its last-message variants:

  • Plaintext (default): empty output on close, The user approved. on approve, otherwise the feedback text. Address returned feedback in the same conversation.
  • --json: one JSON record with decision (approved, dismissed, or annotated) and optional raw feedback. An approval may still carry notes in feedback; treat those as guidance, not a change request.
  • --hook: hook-native output for real PostToolUse/Stop hook contexts only. Approve/close emits nothing (hook passes); annotations emit {"decision":"block","reason":"..."}. --hook implies the gate UI. Never use it for a normal interactive invocation.

plannotator <command> --help prints usage without launching anything. Bare plannotator is the hook entry point and expects hook JSON on stdin.

plannotator review

bash
plannotator review [--git | --gitbutler] [--base <ref>] [--diff-type <type>] [--local | --no-local] [--patch-file <path | ->] [--tailscale] [--json] [PR_URL]

Reviews local VCS changes, or a pull request when a URL is given. Default stdout stays plaintext: the existing close message, approval prompt, or feedback.

With --json, direct review emits one record: { decision: 'approved' | 'annotated' | 'dismissed', message: string }. message is the CLI-rendered text exactly as default plaintext would print it, without the final console newline. It includes customized prompts and non-blocking approval-with-notes framing; a denial suffix is included only when annotations.length > 0, including in PR mode, not for zero-annotation platform status.

Classify the outcome only by decision, never by message text. Notes on an approved review are guidance, not a blocking change request. This rendered message contract is separate from the raw feedback JSON used by annotate and the unchanged opencode-review integration. --hook is annotate-only.

  • VCS is auto-detected (JJ, GitButler, Git, and P4 where supported). --git forces plain Git; --gitbutler forces GitButler (requires the but CLI 0.21.0+). Running from a non-VCS parent folder that contains nested repos produces a combined workspace diff.
  • The default diff is "everything a PR would show now": merge-base of the trunk vs the working tree plus untracked files. --base <ref> opens the session against a different compare target (branch, origin/<branch>, tag, or commit) and --diff-type <type> opens it in a different mode (since-base, merge-base, branch, uncommitted, staged, unstaged, last-commit, local-vs-remote, all). Both are session-only: the reviewer can change either in the UI, and neither writes the user's saved defaults.
  • Reviewing one layer of a stacked branch? Pass --base <the branch below yours>plannotator review --base feature/part-1 shows only what this layer adds, instead of everything since main.
  • Both flags are git-only: they error on jj, GitButler, Perforce, multi-repo workspace reviews, and PR URLs (a PR's base comes from the pull request). A --base ref that does not resolve is a startup error naming near-match branches, never a silently wrong diff.
  • --patch-file <path> reviews a static caller-supplied unified diff with no repository at all (use - to read it from stdin): the session serves the patch as-is with no file-system affordances that need a worktree. It cannot be combined with a PR/MR URL, --base, --diff-type, --git/--gitbutler, or --local/--no-local. Every working-tree affordance is off in that session (staging, hunk-context expansion, open-in-editor, code navigation, diff-type/base switching), and the endpoints behind them answer 400.
  • PR review (plannotator review https://github.com/owner/repo/pull/123, GitLab MR URLs too) needs an authenticated gh or glab CLI. --local (the default) builds a local checkout of the PR head in the background for full file access; --no-local skips it and reviews the platform diff only.
  • --tailscale publishes the loopback session over the user's tailnet via tailscale serve (HTTPS, never public) and prints the URL with a QR code. A publish failure exits nonzero instead of leaving the server hanging.

plannotator annotate

bash
plannotator annotate <target> [--markdown] [--no-jina] [--app | --static] [--render-html] [--tailscale] [--gate] [--json] [--hook]

Opens one document, page, or app in the annotation UI and returns the human's annotations on stdout.

Plain annotate is feedback-only: it shows Close but no Approve button. When the user asks to review, approve, accept, or gate a generated plan/spec/document saved as a file, always add --gate --json. Do not tell the user they can approve a plain annotate session. If the plan is being handed off through the host agent's native plan flow, do not launch annotate; let the plan-exit hook open the approval UI automatically.

Targets:

  • Markdown and text files: .md, .mdx, .txt.
  • Plain-text config and data files, rendered as text: .yaml, .yml, .json, .jsonc, .json5, .toml, .ini, .cfg, .conf, .properties, .csv, .tsv, .log, .xml, .env.example. .env itself is deliberately refused (it commonly holds secrets, and annotate history copies file contents). Source-code files belong to plannotator review, not annotate.
  • HTML files (.html, .htm): rendered as the raw page by default; --markdown converts to markdown instead. --render-html is accepted for compatibility; raw rendering is already the default.
  • URLs (https://...): fetched and converted via Jina Reader by default; --no-jina uses plain fetch plus Turndown instead.
  • Running local apps: a loopback http://localhost:PORT/ URL whose probe returns HTML opens in live-app mode (annotate the real running page). --app forces live mode and fails loudly when it cannot apply; --static forces the classic conversion pipeline. Non-loopback URLs always use the conversion pipeline.
  • Folders: plannotator annotate docs/ opens a file browser over the folder's supported files.

Single files are capped at 2MB. Files are read from disk at stable project paths; keep the reviewed source where it lives.

Argument tolerance: extra words are fine (plannotator annotate look at notes.md please opens notes.md), but two resolvable targets is an error naming both, and an unrecognized dashed token disables the tolerance so flag typos fail loudly. When nothing resolves in a plain multi-word invocation, the CLI prints an agent-addressed handoff on stdout and exits 0: read it, work out the concrete target, and re-run with that exact path or URL.

Strict gates and exit codes

For a machine-checkable approval gate, add --gate --json plus one or both strict flags:

bash
plannotator annotate report.md --gate --json --require-approval --result-file /tmp/decision.json
  • --require-approval: exit code reports the human outcome.
  • --result-file <path>: the stdout decision JSON is also published atomically to <path>. The parent directory must exist and the file must not; results resolve from the invocation cwd.

Exit codes under a strict flag (grep convention):

ExitMeaning
0Approved. The only success.
1The reviewer did not approve (annotated or dismissed); the decision record was still published.
2The gate itself failed: bad flag combination, startup failure (missing file, unreachable URL, oversized file), or the result file could not be published. Never treat as a reviewer outcome.
128+nKilled by signal n.

Without strict flags, startup failures exit 1 and the exit code carries no decision; parse the output instead. Both strict flags require --gate --json and reject --hook.

plannotator annotate-last

bash
plannotator annotate-last [--stdin] [--tailscale] [--gate] [--json] [--hook]
plannotator last

Opens the latest rendered assistant message from the current agent session in the annotation UI (last is an alias). The session log is discovered per host automatically; --stdin reads the content from stdin instead.

Do not print a commentary or status message immediately before running it: the command targets the latest rendered assistant message, so a preamble becomes the thing being annotated.

plannotator copilot-last

bash
plannotator copilot-last [--gate] [--json] [--hook]

The annotate-last variant for live GitHub Copilot CLI sessions (reads Copilot's session-state events). Normally invoked by the Copilot plugin's /plannotator-last command; use it only inside a Copilot CLI session.

plannotator archive

bash
plannotator archive

Opens a read-only browser over saved plan decisions (approved/denied badges) from the Plannotator data directory. No feedback comes back; the session ends when the user clicks Done.

plannotator guide

bash
plannotator guide list
plannotator guide export --id <savedGuideId> [--out <file.html>]
plannotator guide export --guide <guide.json> --patch <diff.patch> [--out <file.html>]
plannotator guide export --snapshot <snapshot.json> [--out <file.html>]
plannotator guide share --id <savedGuideId> [--public] [--ttl <7d|24h|30m|3600>] [--json]
plannotator guide unshare <id> --token <deleteToken>

Guided Reviews are AI-generated walkthroughs of a diff, produced inside the code review UI. The CLI works with saved ones:

  • list shows guides Plannotator has persisted for the current repo.
  • export writes one portable, self-contained HTML file (the viewer loads from guides.show). --guide + --patch exports a guide you authored yourself against a unified diff (--patch - reads stdin; validation is strict and names any file the guide references that the patch lacks). --out - writes to stdout. --viewer-url overrides the pinned viewer base.
  • share uploads the guide and prints a link. Encrypted by default: the key lives only in the URL fragment and the host stores ciphertext. --public stores it unencrypted so chat apps can unfurl a preview. --ttl sets an expiry; otherwise the link stays until unshare. A saved guide records its link, and a second share --id refuses rather than orphaning the first link's delete token.
  • unshare <id> --token <t> removes a link using the delete token printed at share time.

plannotator sessions

bash
plannotator sessions [--open [N]] [--clean]

Lists active Plannotator server sessions. --open reopens session N (default 1) in the browser, useful when a tab was closed mid-review. --clean drops stale entries.

Other subcommands

bash
plannotator setup-goal <interview|facts> <bundle.json | -> [--json]
plannotator uninstall [--purge] [--yes] [--dry-run]
plannotator improve-context
  • setup-goal opens the interview or facts-acceptance UI for /goal workflows; it is driven by the plannotator-setup-goal skill and takes a bundle JSON (- reads stdin). Do not hand-build bundles.
  • uninstall removes Plannotator-installed components (--purge also deletes local data; --yes is required without a TTY; --dry-run previews).
  • improve-context and install-runtime are internal integration commands (hook plumbing and managed runtime install). Never run improve-context directly; plannotator install-runtime agent-terminal exists for reinstalling the optional annotate-terminal runtime and is normally run by the installer.
  • Additional host-internal subcommands (the opencode-* and copilot-plan family) are invoked by their plugins, not by you.

Environment variables that change behavior

VariableUse
PLANNOTATOR_REMOTE=1Force remote mode (fixed port 19432, wide bind) for SSH/devcontainer sessions; 0 forces local. Unset means SSH auto-detection.
PLANNOTATOR_PORTFix the port instead of a random one.
PLANNOTATOR_ORIGINOverride agent-origin detection (claude-code, codex, opencode, pi, oh-my-pi, amp, droid, copilot-cli, gemini-cli, kiro-cli). Set it when launching Plannotator from a wrapper the detection cannot see through.
PLANNOTATOR_AI=disabledDisable Ask AI and agent-launched review surfaces in the UI.
PLANNOTATOR_SHARE=disabledDisable URL sharing, including guide share links.
PLANNOTATOR_DATA_DIRMove the data directory (default ~/.plannotator): plans, history, drafts, config.
PLANNOTATOR_BROWSEROpen sessions in a specific browser.

Posting annotations into a live session

A running plan-review session exposes a small HTTP API on its base URL for external annotations: POST /api/external-annotations adds inline annotations the reviewer sees immediately, with PATCH/DELETE for updates and an SSE stream at /api/external-annotations/stream. The UI's "copy agent instructions" action puts the full API contract for the current session, with the correct base URL, on the clipboard for handing to an agent or script. If the user pastes such instructions, follow them; do not invent endpoints beyond that contract.

Do not

  • Do not parse or scrape the browser UI's HTML; the CLI's stdout (and the documented HTTP API above) is the whole contract.
  • Do not use --hook outside a real hook context; use --json when you need structured output.
  • Do not run bare plannotator interactively; it is the hook entry point.
  • Do not guess flags. Run plannotator <command> --help when unsure; unknown dashed tokens make annotate fail on purpose.
  • Do not point plannotator annotate at source-code files or .env files; code goes through plannotator review, and .env is refused.
  • Do not start a strict gate (--require-approval) unless a human is actually there to review; the session blocks until they act.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Plannotator AI skill do?

Reference for using the Plannotator CLI: plan review, code review, annotating files, URLs, folders, and running local apps, annotating the last assistant message, browsing archived plan decisions, and exporting or sharing Guided Reviews. Invoke when asked to use Plannotator for anything not covered by a more specific plannotator-* skill.

Why use Plannotator on TypingMind?

Because you install it once and use it with any model. Plannotator 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 Plannotator in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/backnotprop/plannotator/tree/main/apps/skills/core/plannotator. 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 Plannotator?

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 Plannotator?

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

Is the Plannotator AI skill free?

Yes. It is published on GitHub by backnotprop under the Apache-2.0 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.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇