Skip to content

Say where a plan file belongs, in the skill that writes one - #109

Merged
vjovanov merged 2 commits into
mainfrom
fix/issue-68-plan-location
Aug 29, 2026
Merged

Say where a plan file belongs, in the skill that writes one#109
vjovanov merged 2 commits into
mainfrom
fix/issue-68-plan-location

Conversation

@vjovanov

Copy link
Copy Markdown
Owner

Fixes #68.

The gap

The rhei-plan-writer skill specified the plan format, states, ids, and validation, and never said where the file goes. An agent following it to the letter saved a plan at a host repository's root; rhei init then refused to adopt the directory until the file moved.

That refusal is the good case. Inside a project that already exists there is no refusal at all — discovery reads the project directory's immediate children and nothing else, so a plan at the repository root or under panta/plans/ is simply not a rhei:

$ rhei list
Task real.1: A real ticket [pending]        # stray.rhei.md and panta/plans/deep.rhei.md: absent

$ rhei validate
Validation succeeded

Two plans on disk, no ticket, no warning, no error. That silence is the strongest argument for the section, and the issue undersells it.

The change

## File Extension becomes ## File Location and Name. Naming a plan and placing it are one decision taken at one moment, and the old heading advertised only half of it, so an agent that read the section still had no reason to choose panta/. Nothing outside the skill referenced the old heading.

The section now gives the default for both plan shapes (panta/<id>.rhei.md, panta/<name>/index.rhei.md), says to look for index.panta.md or run rhei list before writing, prefers rhei new over hand-writing a path, and describes what the silence above looks like.

Creating the project stays the human's call. The issue's suggested wording had the agent run rhei init itself, which contradicts the skill's own line under rhei new — "Do not create a project or run an orchestrator. rhei init is the human's call" — since rhei init writes .gitignore and AGENTS.md in the user's repository. Shipping the issue's text verbatim would have put a self-contradiction into the skill. The guidance instead is to ask for it and write to panta/<id>.rhei.md meanwhile, which a later rhei init adopts.

It also closes the question the issue leaves open. Saying "panta/ is gitignored, leave it unless the user asks to version the plan" raises a question without answering it; rhei init --here is the supported answer (§FS-rhei-init calls it the adoption mode for plans meant to be versioned), and the agent is told to say the plan will not appear in git status.

The naming rule grew the two constraints that fail loudly and were unwritten: a Directory Workspace takes its id from the directory name, and an id must start with a letter and contain only letters, digits, _ or -, with basin reserved.

## Planning Workflow gains a save step. The section only helps an agent that reaches it, and the numbered list went from "set initial states" straight to "run the validation checklist" — an agent working the list never learned where the file goes. Steps renumbered and the one cross-reference at line 46 updated with it.

Deliberately not in this PR

The proposal review surfaced three adjacent items, all real, none part of this issue:

  • rhei-plan-worker presents rhei new --under basin unconditionally, but the basin exists only inside a Panta project. A different bug, and the CLI's own error is good.
  • rhei-template-writer never states where an instantiated workspace lands.
  • The skill's line 56 says the state-machine fallback is "typically docs/states.yaml", which is not a path rhei ever resolves — the real order is project root, rhei root, then beside the plan. The same stale claim sits in two other files, so it wants one fix across all three rather than a partial one here.

Checked and unchanged: rhei-plan-worker needs no location guidance — it takes the plan path as a required argument and is explicitly forbidden from inferring one. rhei-template-writer already has a ## File Placement section covering where templates live.

Verification

grund check output byte-identical to main. install_skills_tests (14 tests) pass — no test asserts on a shipped skill's body. Skill grows 184 → 189 lines. No § citations introduced; this skill carries none.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ANPWuKoibZ6NS84tJxeDC8

The `rhei-plan-writer` skill specified the plan format, states, ids, and
validation, and never said where the file goes. An agent following it saved a
plan at a host repository's root; `rhei init` then refused to adopt the
directory until the file moved.

The refusal is the good case. Inside a project that already exists there is no
refusal at all: discovery reads the project directory's immediate children, so
a plan at the repository root or under `panta/plans/` is not a rhei, `rhei
list` never shows its tickets, and `rhei validate` prints "Validation
succeeded" over both. The plan is simply not there, and nothing says so.

`## File Extension` becomes `## File Location and Name`, because naming and
placing a plan are one decision taken at one moment and the old heading
advertised half of it. It gives the default location for both plan shapes,
says to look for `index.panta.md` or run `rhei list` before writing, and names
what silence looks like when the guess is wrong.

Creating the project stays the human's call. `rhei init` writes `.gitignore`
and `AGENTS.md` in someone's repository, and the skill already says so under
`rhei new`; the guidance is to ask for it and write to `panta/<id>.rhei.md`
meanwhile, which a later `rhei init` adopts. It also says that init gitignores
`panta/`, so the plan will not appear in `git status` — and that the versioned
route is `rhei init --here`, rather than leaving the question hanging.

The naming rule grew the two constraints that fail loudly and were unwritten:
a Directory Workspace takes its id from the directory name, and an id must
start with a letter and hold only letters, digits, `_` or `-`, with `basin`
reserved for the project's unfiled inbox.

Planning Workflow gains a save step. The section is only read by an agent that
reaches it, and an agent working the numbered list went from "set initial
states" to "run the validation checklist" without ever being told where the
file goes.

Fixes #68
@vjovanov
vjovanov merged commit c56a0ea into main Aug 29, 2026
4 checks passed
@vjovanov
vjovanov deleted the fix/issue-68-plan-location branch August 29, 2026 20:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

rhei-plan-writer skill never says where plans go (./panta)

1 participant