Skip to content

A planning command that writes the setting of the plans folder itself, never asking the developer to - #122

Merged
PierreMardon merged 1 commit into
mainfrom
fix/plans-dir-written-by-the-planning-command
Oct 14, 2026
Merged

PierreMardon merged 1 commit into
mainfrom
fix/plans-dir-written-by-the-planning-command

Conversation

@PierreMardon

Copy link
Copy Markdown
Contributor

/surface-plan writes only in the plan folder, and took docs/plans whenever .claude/surface.json was missing. In a host whose agent instructions and earlier plan keep plans in another folder, the command saw the mismatch, read its own rule as a ban on writing the setting, and asked the developer to create the file themselves.

What changes

  • The opening of the skill names the one exception to "You write only in the plan folder": the setting step 3 writes in .claude/surface.json.
  • Step 3 finds the plans folder when the setting is missing, the first that answers: the folder the conventions read at step 1 name for plans; otherwise the folder of the plan folders the repository already keeps, those holding a journal.jsonl; otherwise docs/plans.
  • The command writes the setting. A folder other than docs/plans is written as plans_dir before the plan folder is created, the file created when missing and its other keys kept, since the state script finds the plans only through that setting. The developer is told in one line, never asked to write it.
  • The file is committed with the first commit of the plan, unless git ignores it, so the setting outlives the session.
  • A prompt test holds the order of the search, the write and the commit; the test of the opening holds the exception.
  • The guide tells the developer that /surface-plan writes plans_dir itself when their conventions place plans elsewhere.

ADR 0019 stays as it is: it bounds the installer, which still creates no settings file.

The critical zone

ARCHITECTURE.md, under "Settings and language", gains one paragraph, for the developer to read:

/surface-plan writes plans_dir itself, and commits it with the plan, when the host's conventions, or the plans it already keeps, put its plans outside docs/plans: the script finds the plans through that setting alone, and the developer would otherwise write it before planning.

It stands apart from the paragraph on the settings, which would have reached 619 bytes with it, over the bound of 600.

Checked

  • scripts/gate.sh, green locally.

Not measured: no end to end scenario nor evaluation plays a host that keeps its plans outside docs/plans.

…, never asking the developer to

/surface-plan writes only in the plan folder, and took `docs/plans` whenever
`.claude/surface.json` was missing. In a host whose agent instructions and earlier plan
keep plans in another folder, the command saw the mismatch, read its own rule as a ban
on writing the setting, and asked the developer to create the file.

- The opening of the skill names the one exception: the setting step 3 writes in
  `.claude/surface.json`.
- Step 3 finds the plans folder when the setting is missing, the first that answers: the
  folder the conventions read at step 1 name for plans, the folder of the plan folders
  the repository already keeps, then `docs/plans`. A folder other than `docs/plans` is
  written as `plans_dir` before the plan folder is created, the file created when
  missing and its other keys kept, and the developer is told in one line, never asked
  to write it.
- The file goes in the first commit of the plan, unless git ignores it, so the setting
  outlives the session.
- A prompt test holds the order, the write and the commit.
- ARCHITECTURE.md, under "Settings and language", says in a paragraph of its own that
  the command writes this one setting, and the guide tells the developer.

ADR 0019 stays as it is: the installer still creates no settings file.
@PierreMardon
PierreMardon merged commit 306563b into main Oct 14, 2026
3 checks passed
@PierreMardon
PierreMardon deleted the fix/plans-dir-written-by-the-planning-command branch October 14, 2026 08:55
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.

1 participant