@fableplan/fableplan 1.0.1 → 2.0.0

package/.claude-plugin/marketplace.json

@@ -1,6 +1,6 @@
 {
   "name": "fableplan",
-  "description": "Marketplace for the fableplan Claude Code plugin: Fable 5-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 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.0.0",
-  "description": "Delegates implementation planning to a Fable 5 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** 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) 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 Plan subagent**, confirm it made no edits, and save the plan verbatim to a scratch file.
-3. **Sanity-check the plan** against the actual codebase (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.
+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). 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
 
@@ -64,7 +62,7 @@ This installs into `.claude/skills/` (and any other agents it detects). It's a t
 A Claude Code skill is just a directory containing a `SKILL.md`, so you can also install it with one command — no clone needed:
 
 ```sh
-mkdir -p ~/.claude/skills/fableplan && curl -fsSL https://raw.githubusercontent.com/richkuo/fableplan/master/skills/fableplan/SKILL.md -o ~/.claude/skills/fableplan/SKILL.md
+mkdir -p ~/.claude/skills/fableplan && curl -fsSL https://raw.githubusercontent.com/richkuo/fableplan/main/skills/fableplan/SKILL.md -o ~/.claude/skills/fableplan/SKILL.md
 ```
 
 This puts it in your personal skills directory (`~/.claude/skills/`), available in every project. To scope it to a single project instead, put the file at `<repo>/.claude/skills/fableplan/SKILL.md`.
@@ -81,12 +79,12 @@ 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
 
-- The planning subagent always runs on Fable 5 regardless of your main session's model.
-- The skill adapts to the target repo's conventions (e.g. its `CLAUDE.md`); behavior isn't hardcoded to any one project.
+- The planning subagent always runs on Fable 5.1 regardless of your main session's model.
+- The skill adapts to the target repo's conventions (e.g. its `CLAUDE.md` or `AGENTS.md`); behavior isn't hardcoded to any one project.
 
 ## License
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fableplan/fableplan",
-  "version": "1.0.1",
-  "description": "Installer for the fableplan Claude Code skill: plan with Fable 5, 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 planning subagent before building it. Spins up a Plan subagent running on Fable 5 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** 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
 
@@ -30,16 +30,20 @@ If the command fails (wrong number, no auth, no repo), stop and tell the user
 
 Record the issue number and URL — you'll need them in step 4. If no issue is referenced, skip this and step 4's posting.
 
-### 2. Dispatch the Fable 5 Plan subagent
+### 2. Dispatch the Fable 5.1 Plan subagent
 
 Do not re-plan the task yourself first — the subagent owns the plan. Snapshot `git status --porcelain` before dispatching (the tree may already be dirty), then call the Agent tool with:
 
 - `subagent_type`: `Plan`
-- `model`: `fable` (this is the whole point of the skill — the plan must come from Fable 5)
+- `model`: `fable` (this is the whole point of the skill — the plan must come from Fable 5.1)
 - `run_in_background`: `false` — every later step depends on the plan, so wait for it synchronously instead of doing other work first
 - `description`: `Plan <short task name>`
 - `prompt`: Hand the subagent everything it needs to plan independently — the full task description, the issue title/body if one was fetched, the working directory, and any constraints the user stated. Tell it explicitly:
   - Produce a concrete, ordered implementation plan (files to create/modify, the approach, build sequence, risks/edge cases, and how to verify).
+  - Before planning, read the repo's CLAUDE.md and AGENTS.md files (root and any in directories the plan touches) and follow their conventions. Name any convention the plan relies on.
+  - Cite every load-bearing claim about the existing code with a `file:line` reference (files to modify, functions or symbols it calls, behavior it depends on), so each claim can be checked against the code. Never cite a location it has not read.
+  - Include an `Open questions and assumptions` section. List every assumption it made where the task, issue, or code was unclear, and every decision the user must make. Write "None" if there are none. Never resolve an ambiguity silently.
+  - Include an `Acceptance criteria` section of observable, checkable outcomes, and a `Verification` section with the exact commands to run (build, lint, type check, integration tests) and the result each must produce.
   - Plan the absolute-best solution the task calls for, evaluated as if cost, effort, time, token spend, and code volume were unlimited — they are not factors and must never narrow the option space. The only constraints that override "best" are correctness and safety.
   - Return the plan as its final message in clean Markdown suitable to (a) act on directly and (b) post verbatim as a GitHub issue comment.
   - It is planning only — it must NOT make code edits, including via Bash (no writing/modifying files, no commits). The subagent lacks Edit/Write, but still has Bash, so this must be stated explicitly.
@@ -50,48 +54,37 @@ 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
 
-Before posting or presenting it, verify the plan's load-bearing claims against the actual codebase: the files it says to modify exist, the functions/symbols it references are real, and it doesn't contradict repo conventions (CLAUDE.md). Fix small inaccuracies yourself and note them; if the plan is structurally wrong (built on a file or mechanism that doesn't exist), do NOT automatically re-dispatch the Plan subagent — stop and tell the user what's failing, and let them decide whether to re-plan with Fable 5, adjust the task, or proceed anyway. If you fixed small inaccuracies, update the scratchpad file from step 2 so it reflects the corrected plan before step 4 posts it.
+Before posting or presenting it, verify the plan's load-bearing claims against the actual codebase: open each `file:line` citation and confirm it says what the plan claims, the files it says to modify exist, the functions/symbols it references are real, and it doesn't contradict repo conventions (CLAUDE.md, AGENTS.md). Treat a load-bearing claim with no citation as unverified until you check it. Fix small inaccuracies yourself and note them; if the plan is structurally wrong (built on a file or mechanism that doesn't exist), do NOT automatically re-dispatch the Plan subagent — stop and tell the user what's failing, and let them decide whether to re-plan with Fable 5.1, adjust the task, or proceed anyway. If you fixed small inaccuracies, update the scratchpad file from step 2 so it reflects the corrected plan before step 4 posts it.
 
 ### 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)` 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 | 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 reveals ambiguity or a decision the user must make; otherwise proceed.
+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 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.
+- 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 present the plan.