implement-plan

A process for implementing approved GitHub plan issues and landing the work through pull requests. It coordinates multiple work areas, reviews changes, resolves documentation conflicts, and merges them in order.

In plain words
What is it for?
Use it to select open plan issues, determine their order, delegate implementation, review results, create or merge pull requests when authorized, and update related documentation.
Why use it?
It gives larger changes a controlled path from planned issue to tested, merged code. It also defines safeguards for protected branches, worktree isolation, and publishing changes.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/beppetemp/cartographer/implement-plan
Any agent
npx skills add BeppeTemp/cartographer --skill implement-plan
Clone the repo
git clone --depth 1 https://github.com/BeppeTemp/cartographer

Made for: Claude Code, Codex.

Per session 107 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,500 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00107 $0.01500
Opus 5 $0.00053 $0.00750
Sonnet 5 $0.00021 $0.00300
Haiku 4.5 $0.00011 $0.00150

Measured 2d ago against content hash 499beb1c9f17, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

implement-plan scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.agents/skills/implement-plan/SKILL.md · 96 lines

How it starts

The opening of the file, as written. The whole thing — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.

implement-plan — plan issues → merged PRs

Source of truth is CONTRIBUTING.md §Plan issues + §Pull requests, CLAUDE.md (workflow and delegation rules), and docs/index.md §Maintenance rules. The plan skill covers writing/consuming a single plan. This skill adds only the multi-plan orchestration and the PR/merge cycle — read those first; do not duplicate them here.

Preconditions

  • Never push in working hours (Mon–Fri 09–18): no git push/gh pr create/gh pr merge toward github.com/BeppeTemp/cartographer in that window — implement locally, ship outside it. Check date first.
  • main is protected: every plan lands via its own PR, squash-merge, CI test green. No direct pushes.
  • Merging a self-authored PR and git push --force-with-lease require explicit user authorization or a standing approval. Never work around the approval gate — surface it and let the user choose.

1 — Wave planning (coordinator)

  1. Collect the target issues: gh issue list --label plan (or the subset the user named). Each title already carries its reserved D<n>.
  2. gh issue view <n> each; extract the execution order line (plans state it explicitly) and the file-set each touches.
  3. Build the graph, two edge types:
    • Hard code dependency — a plan uses code a sibling introduces (e.g. a new client method, a new helper). These form strictly sequential chains: never start a plan before its predecessor is on main.
    • Shared file — plans touching the same code, current-state page or decision topic can conflict at merge. A D entry only touches its owning docs/decisions/<topic>.md; unrelated topics are not a shared file.
  4. Emit waves: independent roots with disjoint code file-sets run in parallel; dependency chains run internally sequential but in parallel with each other when their file-sets are disjoint. One plan = one PR.
  5. State the wave plan to the user before spawning (spawning N dev agents + opening N public PRs is outward-facing).

Read the full file on GitHub · 96 lines

Files

What ships with it

1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 96 lines · 107 tokens per session scan A 499beb1c9f17

Subscribe to this mod's changes

implement-plan is a skill published in the GitHub repository BeppeTemp/cartographer (16 stars, last pushed 3d ago), licensed Apache-2.0. It adds 107 tokens to every session and 1,500 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

loop-implement

The single implementation loop. It plans via wiki-plan (step 2, required) into an ordered, wiki-navigated task list, then executes those tasks in order, each loading only its named wiki pages, writing tests first, getting an independent test-quality audit, and judging against done; on failure it reflects and retries…

choiyounggi/dev-loop · 94 tokens

knowledge-flush

Drain queued ★ Insight candidates (harvested from your sessions) into the wiki as a reviewed PR. For each candidate it researches and verifies the best-practice against real sources, checks existing wiki layers for duplicates and links, decides the target layer/category (or justifies a new one), runs wiki-ingest, then…

choiyounggi/dev-loop · 117 tokens

wiki-plan

The fixed planning methodology for a capable model. Make every design decision grounded in a bundled wiki page (recording a decision-to-page map), then decompose the work into ordered, self-contained tasks, each naming the exact wiki pages that govern it. Runs as loop-implement step 2.

choiyounggi/dev-loop · 62 tokens

configure

Set up dev-loop's capability-role tool profile — map knowledge (your domain wiki / MCP), verify (your project's test/build/QA command), explore (code search), tacit (past incidents), and design (Figma/visual spec) to the actual tools this environment has, then write /.claude/dev-loop/tools.json (global) or…

choiyounggi/dev-loop · 124 tokens

fkf-use

Use an fkf base safely: inspect status, retrieve bounded context, resolve URIs, traverse declared relations, collect sources, or serve read-only MCP. Invoke for any read or collection workflow in a base.

fmind/fkf · 46 tokens

Cursor rules for Go development with backend scalability

Skill "Cursor rules for Go development with backend scalability" from AmariahAK/atlarix-skills, covering cursor rules for go development with backend scalability, when to use this skill and source.

AmariahAK/atlarix-skills · 8 tokens