@fableplan/fableplan 1.1.0 → 2.0.0

package/.claude-plugin/marketplace.json

@@ -1,6 +1,6 @@
 {
   "name": "fableplan",
-  "description": "Marketplace for the fableplan Claude Code plugin: Fable 5.1-driven implementation planning before building.",
+  "description": "Marketplace for the fableplan Claude Code plugin: Fable 5.1-driven implementation planning.",
   "owner": {
     "name": "Richard Kuo"
   },
@@ -8,7 +8,7 @@
     {
       "name": "fableplan",
       "source": "./",
-      "description": "Delegates implementation planning to a Fable 5.1 planning subagent, then builds from the vetted plan — posting it to a referenced GitHub issue along the way."
+      "description": "Delegates implementation planning to a Fable 5.1 planning subagent, checks the plan, and posts it to a referenced GitHub issue. It never builds."
     }
   ]
 }

package/.claude-plugin/plugin.json

@@ -1,8 +1,8 @@
 {
   "name": "fableplan",
   "displayName": "fableplan",
-  "version": "1.1.0",
-  "description": "Delegates implementation planning to a Fable 5.1 planning subagent, then builds from the vetted plan — posting it to a referenced GitHub issue along the way.",
+  "version": "2.0.0",
+  "description": "Delegates implementation planning to a Fable 5.1 planning subagent, checks the plan, and posts it to a referenced GitHub issue. It never builds.",
   "author": {
     "name": "Richard Kuo"
   },

package/README.md

@@ -1,22 +1,20 @@
 # fableplan
 
-A [Claude Code](https://claude.com/claude-code) skill that delegates implementation planning to a **Fable 5.1** planning subagent, then builds from that plan in your main session — and, when a GitHub issue is referenced, posts the vetted plan to the issue as a comment.
+A [Claude Code](https://claude.com/claude-code) skill that delegates implementation planning to a **Fable 5.1** planning subagent, checks the plan in your main session, and, when a GitHub issue is referenced, posts the vetted plan to the issue as a comment. Then it stops.
 
-The idea: let a dedicated planning model (Fable 5.1) produce a concrete, ordered implementation plan before any code is written, review it against the real codebase, preserve it on the tracker, and only then build — in an isolated git worktree so your working tree is never touched.
+The idea: let a dedicated planning model (Fable 5.1) produce a concrete, ordered implementation plan before any code is written, review it against the real codebase, and preserve it on the tracker. The skill never builds; you build from the plan when you choose to.
 
 ## What it does
 
 Trigger it with `/fableplan`, "fableplan this", or "plan this with fable", plus a task description and optionally a GitHub issue (`#N`, a full URL, or `owner/repo#N`).
 
-The skill then runs a 7-step flow:
+The skill then runs a 5-step flow:
 
 1. **Resolve the GitHub issue** (only if one is referenced) so the planner works from the real requirements, not a paraphrase.
 2. **Dispatch the Fable 5.1 Plan subagent**, confirm it made no edits, and save the plan verbatim to a scratch file. The plan follows the repo's `CLAUDE.md`/`AGENTS.md` conventions, cites `file:line` for its claims about the code, lists open questions and assumptions, and gives acceptance criteria and exact verification commands.
 3. **Sanity-check the plan** against the actual codebase (each `file:line` citation, files, symbols, conventions). It stops and asks you if the plan is structurally wrong rather than silently re-planning.
-4. **Post the vetted plan** to the GitHub issue as a comment (only if one was referenced).
-5. **Present the plan** to you.
-6. **Set up an isolated git worktree** so the build never touches your current workspace.
-7. **Build** the task from the plan, inside that worktree, then run the plan's verification commands before reporting done.
+4. **Post the vetted plan** to the GitHub issue as a comment (only if one was referenced). The heading and footer name the model and effort that actually produced the plan.
+5. **Present the plan** to you, then stop. The skill never builds.
 
 ## Install
 
@@ -81,7 +79,7 @@ Start a new Claude Code session (or restart the current one), then run:
 
 - Claude Code with access to the `fable` model for the planning subagent.
 - `gh` (GitHub CLI), authenticated, if you want the issue-comment step.
-- A git repository for the build step (the skill stops and asks if the working directory isn't one).
+- A local clone of the repository when you plan against a GitHub issue.
 
 ## Notes
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fableplan/fableplan",
-  "version": "1.1.0",
-  "description": "Installer for the fableplan Claude Code skill: plan with Fable 5.1, build with your main-session model.",
+  "version": "2.0.0",
+  "description": "Installer for the fableplan Claude Code skill: plan with Fable 5.1, check the plan, and post it to the issue.",
   "type": "module",
   "bin": {
     "fableplan": "bin/install.mjs"

package/skills/fableplan/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: fableplan
-description: Use when the user wants a task planned by a Fable 5.1 planning subagent before building it. Spins up a Plan subagent running on Fable 5.1 to produce an implementation plan, relays the plan back to the main agent to build, and — if a GitHub issue is referenced — posts the plan as a comment on that issue. Trigger on "/fableplan", "fableplan this", or "plan this with fable".
+description: Use when the user wants a task planned by a Fable 5.1 planning subagent. Spins up a Plan subagent running on Fable 5.1 to produce an implementation plan, checks it against the code, relays it to the main agent, and — if a GitHub issue is referenced — posts the plan as a comment on that issue, then stops. It never builds. Trigger on "/fableplan", "fableplan this", or "plan this with fable".
 ---
 
 # fableplan
 
-Delegate planning to a **Fable 5.1** Plan subagent, then build from its plan in the main agent. The main agent does the building — the subagent only plans.
+Delegate planning to a **Fable 5.1** Plan subagent. The main agent checks the plan, posts it, presents it, and stops. Neither one builds: no worktree, no code edits, no pull request.
 
 ## Input
 
@@ -54,7 +54,8 @@ If the call returns null or errors (user skip, terminal API failure), retry once
 
 When the result arrives:
 - Run `git status --porcelain` and compare against the pre-dispatch snapshot to confirm the subagent made no file changes despite the no-edit instruction. If it did, tell the user and ask whether to revert before continuing.
-- Save the plan verbatim to a scratchpad file immediately, so it survives context summarization during a long build and step 4 can post it exactly as produced.
+- Save the plan verbatim to a scratchpad file immediately, so it survives context summarization and step 4 can post it exactly as produced.
+- Record the model that actually served the plan and the effort it ran at. If the harness substituted another model for Fable 5.1, record that model; if it does not report the effort, record the tier you requested (`high` when you requested none). Step 4 uses these values.
 
 ### 3. Sanity-check the plan against the code
 
@@ -62,40 +63,28 @@ Before posting or presenting it, verify the plan's load-bearing claims against t
 
 ### 4. Post the plan to the GitHub issue (only if one was resolved in step 1)
 
-Now that the plan has passed the sanity-check, save it to the issue as a comment before building, so the vetted plan is preserved on the issue regardless of how the build goes. This comment is not updated after the build.
+Now that the plan has passed the sanity-check, save it to the issue as a comment, so the vetted plan is preserved on the issue for whoever builds it. This comment is not updated after the build.
 
 ```
 gh issue comment <N> --body-file <tmpfile>
 ```
 
-Add `-R owner/repo` when the issue lives in another repo (as in step 1). Use the scratchpad file from step 2 (with any step-3 corrections) as the body-file base — it avoids shell-escaping problems with Markdown. Prefix the comment so its origin is clear with a heading line `## Implementation plan (Fable 5.1)` above the plan body, and end the body with the standard metadata footer:
+Add `-R owner/repo` when the issue lives in another repo (as in step 1). Use the scratchpad file from step 2 (with any step-3 corrections) as the body-file base — it avoids shell-escaping problems with Markdown. Prefix the comment so its origin is clear with a heading line `## Implementation plan (<model that actually ran>)` above the plan body (`Fable 5.1` when Fable served), and end the body with the metadata footer:
 
 ```
 ---
-Created with: Fable 5.1 | high | Claude Code | fableplan
+Created with LLM: <model that actually ran> | <effort that actually ran> | Harness: <harness> | fableplan
 ```
 
+Fill the model and effort from step 2's record, never a constant. `<harness>` is the agent harness that ran the skill (for example `Claude Code`, `Cursor`, or `Codex`).
+
 After posting, give the user the comment URL `gh` returns. Follow the repo's CLAUDE.md conventions for comment formatting if any apply (e.g. avoid `#N` auto-links in list items). If no issue is referenced, skip this step.
 
 ### 5. Relay the plan to the user
 
-Present the vetted plan to the user (the main agent). This is the plan you will build from.
-
-### 6. Set up an isolated git worktree
-
-Before making any code changes, move the build into its own git worktree so it never touches the user's current workspace. If the directory isn't a git repository, tell the user and ask how to proceed rather than building in place. Otherwise create a fresh branch and worktree for the task:
-
-```
-git worktree add ../<repo>-fableplan-<short-task-name> -b fableplan/<short-task-name>
-```
-
-Do all of step 7's building inside that worktree. When the build is done, follow the repo's usual conventions for merging or opening a PR from the branch, and remove the worktree once it's no longer needed (`git worktree remove <path>`).
-
-### 7. Build
-
-In the worktree from step 6, the main agent builds the task per the plan. Confirm with the user first only if the plan's `Open questions and assumptions` section, or the build itself, reveals ambiguity or a decision the user must make; otherwise proceed. Before you report the build as done, run every command in the plan's `Verification` section and confirm each acceptance criterion.
+Present the vetted plan to the user (the main agent). Say in one line if step 2 recorded a model other than Fable 5.1. Then stop. Keep the scratchpad file. Never ask whether to build, create a worktree, or edit code; the user builds from the plan when they choose to.
 
 ## Notes
 
 - The Plan subagent runs on Fable 5.1 regardless of the main agent's model — `model: fable` on the Agent call forces it.
-- If the user did not reference an issue, never invent one or post anywhere — just plan and build.
+- If the user did not reference an issue, never invent one or post anywhere — just plan and present the plan.