Say where a plan file belongs, in the skill that writes one - #109
Merged
Conversation
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #68.
The gap
The
rhei-plan-writerskill 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 initthen 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: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 Extensionbecomes## 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 choosepanta/. 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 forindex.panta.mdor runrhei listbefore writing, prefersrhei newover 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 inititself, which contradicts the skill's own line underrhei new— "Do not create a project or run an orchestrator.rhei initis the human's call" — sincerhei initwrites.gitignoreandAGENTS.mdin 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 topanta/<id>.rhei.mdmeanwhile, which a laterrhei initadopts.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 --hereis 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 ingit 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-, withbasinreserved.## Planning Workflowgains 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-workerpresentsrhei new --under basinunconditionally, but the basin exists only inside a Panta project. A different bug, and the CLI's own error is good.rhei-template-writernever states where an instantiated workspace lands.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-workerneeds no location guidance — it takes the plan path as a required argument and is explicitly forbidden from inferring one.rhei-template-writeralready has a## File Placementsection covering where templates live.Verification
grund checkoutput byte-identical tomain.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