plan

A workflow for turning confirmed requirements into an ordered implementation task list. Each task has a scope, an assigned skill, and a testable condition for completion.

In plain words
What is it for?
Use it before multi-step implementation work when you need to decide what to build first, how tasks depend on one another, and how to verify each result.
Why use it?
It reduces integration problems caused by doing dependent work in the wrong order or starting before requirements are clear.

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/hellotern/sextant/plan
Any agent
npx skills add hellotern/Sextant --skill plan
Clone the repo
git clone --depth 1 https://github.com/hellotern/Sextant

Made for: Claude Code, Codex.

Per session 161 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,020 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.00161 $0.02020
Opus 5 $0.00081 $0.01010
Sonnet 5 $0.00032 $0.00404
Haiku 4.5 $0.00016 $0.00202

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

Security

Grade A, and why

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.

skills/plan/SKILL.md · 200 lines

How it starts

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

!../principles/SKILL_BODY.md

!../tool-gitnexus/SKILL_BODY.md


Sprint Planning Workflow

Core Principle

A plan is only as good as its dependency order. Tasks executed out of order produce integration failures that look like bugs but are actually sequencing errors. The goal is a dependency-ordered task list where each task has a clear skill assignment, a bounded scope, and a single testable acceptance condition.

Upstream skill: sextant:refine-requirements answers "what to build" and produces a requirements confirmation document. This skill answers "how to build it and in what order." If requirements are still unclear or unconfirmed, use sextant:refine-requirements first.


Complete Execution Workflow

Session Resume Check

Before Step 1, check whether .sextant/state.json exists in the project root.

If the file exists: display the current sprint summary (requirement name, task statuses) and ask:

"An existing sprint plan was found. Resume it, or start a new plan?"

  • Resume: present the task list with current statuses; skip to the Execution Handoff section. Continue from the first pending or in_progress task.
  • New plan: proceed with Steps 1–4 normally. Confirm with the user before overwriting the existing state.

If the file does not exist: proceed with Step 1 normally.

Step 1: Parse Inputs

Accept either a requirements confirmation document (output of sextant:refine-requirements) or a clearly stated, unambiguous requirement. Extract:

  • Modules involved: which existing modules will be modified or extended?
  • Entry points: where does the new behavior surface (API endpoint, CLI command, UI trigger, event producer)?
  • Integration points: where does the new code connect to existing code (interfaces, events, shared data structures, registries)?
  • Paradigm: which architecture paradigm applies (per §6.0)? — determines the default layer ordering in Step 2.

🔗 When GitNexus is available, use context / query MCP tools to extract module relationships automatically.

Read the full file on GitHub · 200 lines

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 · 200 lines · 161 tokens per session scan A bcb849128b71

Subscribe to this mod's changes

plan is a skill published in the GitHub repository hellotern/Sextant (15 stars, last pushed 4mo ago), licensed MIT. It adds 161 tokens to every session and 2,020 once invoked, about $0.0008 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.