# Plan

> Shape or refine the existing bead or caller

- Skill: `thedixitjain/plan-5` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds add thedixitjain/plan-5`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thedixitjain/plan-5/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: thedixitjain (https://skillmd.com/u/thedixitjain)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/thedixitjain/plan-5

---


# Plan

Turn the caller's intent into one bounded, testable behavior in the place that
already owns the work. Prefer the caller's tracker, if any. When no tracker is
available, use the caller's conversation or supplied issue text; the runtime
snapshots the resolved intent bytes automatically so later contexts can read
and hash the same source. Do not make the model restate those facts in a packet.

## Workflow

1. Resolve the intent source and choose one active behavior. When that source
   is not already durable, have the runtime pass its exact bytes to
   `python3 skills/validate/scripts/validate.py snapshot-intent --source -` and
   use the returned `intent_ref` for later phases.
2. Route the work by type (see **Ground-truth routing**) and name its ground
   truth first. Then inspect only enough real context to make paths, interfaces,
   and evidence concrete. Existing research and specialist skills are advisory
   inputs.
3. Ensure the source contains acceptance examples, important non-goals, and the
   allowed write scope. Use lightweight prose or Given/When/Then only where it
   removes ambiguity; do not require both normal and edge ceremony for every
   change.
4. Name the first useful acceptance check.
5. If authorized and the source is writable, update that bead or issue in
   place. Otherwise return a concise proposed amendment to the caller.

Planning produces no AgentOps packet. The runtime stores and hashes the resolved
source bytes to detect later acceptance drift. That content-addressed snapshot
is derived automatically and is not another model-authored planning artifact.

Bound the work around the caller-visible outcome, not individual files, gates,
or reviewer comments. Decomposition is useful only when it reduces reasoning
cost; it must not multiply invocations or proof artifacts.

## Scope admission

In a repository with generated projections, write scope names generator-owned
outputs as a class — the hand-edited sources plus all outputs of the owning
regen commands — never as a hand-enumerated path list. Hand enumeration is
falsified the first time a regen command rewrites a companion the author did
not list: the 2026-07-15 heal-skill fold burned two implement lanes and three
intent revisions (`.agents/ao/intents/sha256/d1db59d4...2b81` superseded by
`f5fd7c3c...af75` superseded by `26a4f2be...eb48`) before scope was restated
as a class.

Before freezing acceptance, run a complexity admission: enumerate the
generated companions, parity twins (for example a `skills-codex/` mirror), and
test files that assert on the paths being changed. Anything this pass finds
that the scope does not admit will surface later as an out-of-scope diff or a
broken gate.

## Ground-truth routing

Every plan needs a ground truth outside the planner's own reasoning. Before
freezing acceptance, classify the work and name its ground truth, its control
experiment, and its deviation ledger from the row below.

| Work type | Ground truth | Control experiment | Deviation ledger |
|---|---|---|---|
| Integrate an external substrate, runtime, tracker, or service | the vendor's own docs plus stock behavior | run their vanilla quickstart on pinned versions with zero local code, before designing | each deviation from the documented flow, each justified; and every component you write that has a native counterpart in the substrate |
| Extend this project | the repo's existing patterns and behavior spec | the simplest version that satisfies acceptance, and why it is insufficient | each novelty introduced — new abstraction, dependency, or pattern |
| Greenfield | reference experience and domain prior art | a walking skeleton | each deviation from the boring default, ~one novelty per change |

The Extend row is already the repo's default discipline: behavior-first
acceptance, RED -> GREEN, the smallest real change. The Integrate row is the one
that is cheap to skip and expensive to have skipped — run the stock control
experiment *before* you design, or you will re-plumb what the substrate already
documents and inherit bugs you built yourself.

Trigger: the Integrate-row mechanics — the stock-quickstart control run and the
deviation ledger from the documented flow — apply only to integration-class work
(adopting or wiring in an external substrate, runtime, tracker, or service).
Routine feature work on this project uses the Extend row and does not incur them.

A plan is done only when it passes the fresh-context test: a cold context,
given the intent source alone, could execute it without the author's
conversation. If execution needs facts that live only in the planning
conversation, move them into the source before freezing.

---

**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/boshu2/agentops/skills-codex/plan/SKILL.md`

