Plan

SkillMedia

Use after design approval for milestone plans with executable acceptance.

Use Plan in Claude, ChatGPT or Ahel Desktop

Free. Sign in, add Plan and connect your AI. About a minute.

Also: Claude Code · Cursor · Codex

Then ask your AI: use the Plan skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.

What this skill tells your AI

The instructions your AI receives, as published by hashgraph-online/awesome-codex-plugins in plugins/ouonet/praxis/skills/plan/SKILL.md and read by ahel’s review.

docs/staging/plans/YYYY-MM-DD-<topic>.md. Reference the spec; don't restate it.

If unresolved spec notes affect implementation or task order, return to design.

Multi-module plan

If topology=multi-module (triage announcement or coordinator spec/plan declaration), read ../references/multi-module.md. Open the workspace plan with the declaration block (topology: multi-module, change-set, coordinator, repos, module plan paths, integration task) - it is the on-disk mode marker downstream skills rely on.

  • Write the workspace plan in the coordinator repository and a module plan in every affected module's owning repository.
  • The workspace plan lists the change-set ID, coordinator, repositories, module plan paths, and the integration task.
  • Every task names exactly one repository: and one module:. Cross-module verification is an integration task owned by the coordinator.
  • Order contract tasks before consumers, local acceptance before integration, and integration before linked commits.
  • Mark tasks parallel only when they have independent write scopes and acceptance.
  • Adding a repository after implementation starts: update the declaration block and confirm with the user. Return to design only if the addition changes a shared contract.

Rolling wave

Spec references a milestone (milestone: MN)? Check docs/ROADMAP.md — expand only that milestone. Leave the rest as stubs.

After ship: open docs/ROADMAP.md, confirm which milestone is next, then expand it. Return to design only if the milestone's goal materially changed.

Milestone tasks (30-60 min each)

Every task is - [ ] T<n>: <name> - always a checkbox, never a heading. tdd/subagents flip it to - [x] on completion; ship refuses to run while any - [ ] remains.

goal:       <one sentence>
files:      <paths>
acceptance: <test or cmd>
spec:       <docs/staging/specs/...#anchor>

No exact code. No step-by-step. Acceptance is verifiable: a test, command, or scripted check — or, when none is possible, an explicit manual check (steps + expected result). Each task leaves the repo green.

Mark independent tasks: [parallel] T3, T4, T5.

Only mark [parallel] when shared contracts, state, errors, and acceptance are closed.

Atomic expansion is deferred until dispatch time - subagents expands a milestone into 2-5 min steps at dispatch time, not here.

for New project: derive an initialization task — scaffold code, tests, CI, and always include: README.md, CHANGELOG.md, .gitignore, and a Makefile (or equivalent task runner config).

Don't put in the plan

background, architecture, rationale (spec), CI commands, copy-pasted acceptance.

Hand off

<gate> The plan must exist on disk before handing off to tdd/subagents. For multi-module work, this means the coordinator workspace plan and every affected module plan in its owning repository. </gate>

Confirm plan with the user.

mostly [parallel] → subagents. Otherwise → tdd.

Signals

GitHub stars
1k
Forks
316
Last commit
Oct 2026
Advanced
Item type
skill
Key
plan-hashgraph-online
Source
github.com/hashgraph-online/awesome-codex-plugins