goalbuddy 0.2.11 → 0.2.13

package/.agents/plugins/marketplace.json

@@ -0,0 +1,20 @@
+{
+  "name": "goalbuddy",
+  "interface": {
+    "displayName": "GoalBuddy"
+  },
+  "plugins": [
+    {
+      "name": "goalbuddy",
+      "source": {
+        "source": "local",
+        "path": "./plugins/goalbuddy"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Coding"
+    }
+  ]
+}

package/CONTRIBUTING.md

@@ -12,8 +12,6 @@ cd goalbuddy
 npm run check
 ```
 
-Until the GitHub repository rename is complete, use the current local clone or the existing `tolibear/goal-maker` remote.
-
 ## Local Install Test
 
 Use a temporary Codex home so local testing does not overwrite your real install:
@@ -33,7 +31,7 @@ Before opening a PR, verify the npm package contents:
 npm pack --dry-run
 ```
 
-The package should include `README.md`, `internal/assets/`, `package.json`, `internal/cli/`, the canonical `goalbuddy/` skill directory, the temporary `goal-maker/` compatibility skill directory, and `plugins/goalbuddy/`.
+The package should include `README.md`, `internal/assets/`, `package.json`, `internal/cli/`, the canonical `goalbuddy/` skill directory, and `plugins/goalbuddy/`. The temporary `$goal-maker` compatibility skill is generated by the installer; do not add a second tracked skill payload.
 
 ## Releases
 
@@ -43,7 +41,7 @@ GoalBuddy publishes from GitHub Actions with npm trusted publishing. See [RELEAS
 
 - Keep the runtime dependency-free unless there is a strong reason.
 - Keep `goalbuddy/` installable as the canonical Codex skill directory.
-- Keep `goal-maker/` working as a temporary compatibility skill directory until the migration window ends.
+- Keep `$goal-maker` working as a generated compatibility alias until the migration window ends.
 - Prefer small, reviewable changes.
 - Update README or templates when behavior changes.
 - Run `npm run check` before submitting changes.

package/README.md

@@ -1,81 +1,127 @@
 # GoalBuddy
 
-Turn open-ended Codex work into a living Scout/Judge/Worker board with receipts, verification, and optional extensions.
+<p align="center">
+  <a href="https://goalbuddy.dev">
+    <img src="internal/assets/goalbuddy-readme-hero.png" alt="GoalBuddy turns vague Codex goals into structured progress with Scout, Judge, Worker, receipts, and verification." width="100%">
+  </a>
+</p>
+
+<p align="center">
+  <strong>Turn open-ended Codex work into one reviewable goal board.</strong>
+</p>
+
+<p align="center">
+  <a href="https://www.npmjs.com/package/goalbuddy"><img alt="npm" src="https://img.shields.io/npm/v/goalbuddy?style=flat-square&color=684cff"></a>
+  <a href="LICENSE"><img alt="MIT License" src="https://img.shields.io/badge/license-MIT-071236?style=flat-square"></a>
+  <a href="https://goalbuddy.dev"><img alt="goalbuddy.dev" src="https://img.shields.io/badge/site-goalbuddy.dev-684cff?style=flat-square"></a>
+</p>
+
+GoalBuddy is a local Codex companion for work that is too broad to trust to a single prompt. It turns a vague request into a `goal.md` charter, a machine-readable `state.yaml` board, role-tagged Scout/Judge/Worker tasks, compact receipts, and verification before completion.
 
 ```bash
 npx goalbuddy
 ```
 
-Then invoke the skill inside Codex:
+Then invoke the installed skill inside Codex:
 
 ```text
 $goalbuddy
 ```
 
-`$goalbuddy` creates a local goal charter and task board, then prints the `/goal` command to run next. It does not start `/goal` automatically.
+`$goalbuddy` prepares the board and prints the `/goal` command to run next. It does not start `/goal` automatically.
 
-Native Codex `/goal` is still an under-development Codex feature. Before relying on the printed command, confirm your local Codex runtime is logged in and has goals enabled:
+## Why GoalBuddy Exists
 
-```bash
-codex login status
-codex features enable goals
-npx goalbuddy doctor --goal-ready
-```
+Long Codex goals drift. A request like "improve this project" can turn into unbounded edits, stale verification, and premature completion claims.
 
-![A simple hand-drawn diagram showing a vague goal becoming a GoalBuddy board with Scout, Judge, Worker, and a receipt.](internal/assets/goal-maker-flow.png)
+GoalBuddy gives Codex a durable loop:
 
-## Why It Exists
+```text
+vague goal -> Scout -> Judge -> Worker -> receipt -> verify -> repeat
+```
 
-Long Codex goals drift. A broad request like “improve this project” can turn into unbounded edits, stale verification, and premature completion claims.
+The main `/goal` thread acts as PM. It owns the board, keeps exactly one active task, delegates when useful, records receipts, and only completes after a Judge or PM audit proves the original outcome is done.
 
-GoalBuddy gives Codex an operating loop for that kind of work:
+## What You Get Locally
 
 ```text
-vague goal -> discovery -> task board -> one active task -> receipt -> board update -> repeat
+docs/goals/<slug>/
+  goal.md
+  state.yaml
+  notes/
 ```
 
-The main Codex thread is the PM. It owns the board, chooses the active task, delegates when useful, records receipts, and only completes after a Judge or PM audit.
+- `goal.md` is the editable charter: objective, constraints, tranche, and stop rule.
+- `state.yaml` is the board truth: task status, active task, receipts, and verification.
+- `notes/` holds longer Scout, Judge, or PM findings when a task receipt would be too large.
+
+## The Operating Model
 
-## Core Features
+GoalBuddy uses four primitives:
 
-- **Local board truth**: `goal.md` is the editable charter; `state.yaml` is the machine-readable board; `notes/` holds long receipts.
-- **Default role agents**: Scout discovers evidence, Judge resolves risk and completion claims, Worker performs one bounded implementation task.
-- **One active task**: keeps autonomous work sequenced and reviewable instead of turning a vague goal into a pile of parallel edits.
-- **Task receipts**: every completed, blocked, or escalated task records what changed, what was learned, and what verification ran.
-- **Board checker**: validates v2 goal folders and rejects old `gate`, `units`, `artifacts`, and `evidence.jsonl` layouts.
-- **Extensions**: optional add-ons are discovered from `extend/catalog.json` without requiring npm updates for every integration.
+- **Charter**: states what this goal is trying to accomplish and what must stay true.
+- **Board**: tracks tasks, status, receipts, and verification freshness.
+- **Task**: exactly one active Scout, Judge, Worker, or PM task.
+- **Receipt**: compact proof for every completed, blocked, or escalated task.
 
-## The Model
+The default agents are installed with the skill:
 
-GoalBuddy uses four primitives:
+- **Scout** maps repo evidence, workflows, constraints, risks, and candidate next tasks.
+- **Judge** resolves ambiguity, scope, risk, task selection, and completion claims.
+- **Worker** performs one bounded implementation or recovery slice with explicit files and checks.
 
-- **Charter**: `goal.md` states the objective, constraints, current tranche, and stop rule.
-- **Board**: `state.yaml` is machine truth for tasks, status, receipts, and verification freshness.
-- **Task**: exactly one active task is worked at a time.
-- **Receipt**: every completed, blocked, or escalated task leaves compact proof of what happened.
+## Install And Check Readiness
 
-Scout, Judge, and Worker are installed by default:
+Install or refresh the Codex skill and bundled agents:
 
-- **Scout** maps repo/source/spec evidence and candidate tasks.
-- **Judge** resolves ambiguity, scope, risk, and completion claims.
-- **Worker** performs one bounded implementation or recovery task.
+```bash
+npx goalbuddy
+npx goalbuddy update
+```
 
-The main `/goal` thread is the PM. Use medium thinking for specific bounded goals, high for open-ended/recovery/audit goals, and reserve xhigh for exceptional high-risk or multi-day final audits.
+Native Codex `/goal` is still an under-development Codex feature. Before relying on the printed command, confirm your local Codex runtime is logged in and has goals enabled:
 
-## Goal Folder
+```bash
+codex login status
+codex features enable goals
+npx goalbuddy doctor --goal-ready
+```
 
-For each goal, `$goalbuddy` prepares:
+Repair only the bundled agent definitions:
+
+```bash
+npx goalbuddy agents
+```
+
+Check the local install:
+
+```bash
+npx goalbuddy doctor
+```
+
+Use a non-default Codex home:
+
+```bash
+npx goalbuddy install --codex-home /path/to/.codex
+```
+
+`install`, `update`, and `doctor` also support `--json` when an agent or script needs structured output.
+
+## Run A Goal
+
+After `$goalbuddy` creates or repairs the board, start the run with the printed command:
 
 ```text
-docs/goals/<slug>/
-  goal.md
-  state.yaml
-  notes/
+/goal Follow docs/goals/<slug>/goal.md.
 ```
 
-Most task results live inline as receipts in `state.yaml`. Use `notes/<task-id>-<slug>.md` only when a Scout, Judge, or PM result is too large for the task card.
+Check board health at any time:
+
+```bash
+node ~/.codex/skills/goalbuddy/scripts/check-goal-state.mjs docs/goals/<slug>/state.yaml
+```
 
-For a broad prompt like “Improve my project,” the first task should usually be Scout, not Worker:
+For a broad prompt like "Improve my project," the first active task should usually be Scout, not Worker:
 
 ```yaml
 tasks:
@@ -104,50 +150,9 @@ tasks:
     receipt: null
 ```
 
-## Commands
-
-Install or update the Codex skill and bundled agents:
-
-```bash
-npx goalbuddy
-npx goalbuddy update
-```
-
-`install` and `update` print a compact summary of the skill, agent files, preserved installed extensions, and extension catalog recommendations. Use `--json` when an agent or script needs structured output.
-
-### Compatibility Window
-
-GoalBuddy was previously published as `goal-maker`. During the migration window, `npx goal-maker` remains available as a compatibility alias and prints the new command:
-
-```bash
-npx goalbuddy
-```
-
-Machine-readable commands such as `npx goal-maker install --json` keep JSON output clean so existing automation can migrate safely.
-
-Release automation for future npm publishes is documented in [RELEASE.md](RELEASE.md).
-
-Repair only the agent definitions:
-
-```bash
-npx goalbuddy agents
-```
-
-Check what is installed:
-
-```bash
-npx goalbuddy doctor
-```
-
-Strictly check whether the native Codex `/goal` runtime is ready too:
-
-```bash
-npx goalbuddy doctor --goal-ready
-```
-
-`doctor` reports missing or stale bundled agents, Codex login status, and whether the `goals` feature is enabled. `update` refreshes the installed skill and bundled agents.
+## Extensions
 
-Discover optional extensions from the GitHub-hosted catalog:
+The npm package is the stable core. Optional extensions live under `extend/` and are discovered from the GitHub-hosted `extend/catalog.json`, so users do not need a new npm release for every integration.
 
 ```bash
 npx goalbuddy extend
@@ -156,51 +161,44 @@ npx goalbuddy extend install github-pr-workflow --dry-run
 npx goalbuddy extend install --all --dry-run
 ```
 
-Use a non-default Codex home:
-
-```bash
-npx goalbuddy install --codex-home /path/to/.codex
-```
-
-## Extensions
+`goalbuddy extend` shows available extensions plus local install state, activation state, credential requirements, safe-by-default status, and missing environment variables.
 
-The npm package is the stable core. Extensions live under `extend/` and move through the GitHub-hosted `extend/catalog.json`, so users do not need a new npm release for every optional integration.
+Current catalog examples include:
 
-`goalbuddy extend` reads the catalog and shows available extensions plus operational state such as activation, install/configuration status, approval requirements, safe-by-default status, and missing environment variables. `goalbuddy extend <id>` shows what an extension reads, writes, requires, supports, and a local-use prompt. `goalbuddy extend install <id>` copies a pinned, checksum-verified extension into the local GoalBuddy install. `goalbuddy extend install --all` installs every cataloged extension.
+- `github-pr-workflow`: prepares receipt-aligned commit and PR handoff text.
+- `github-projects`: mirrors GoalBuddy boards into GitHub Projects.
+- `ai-diff-risk-review`: summarizes risk in the current diff.
+- `ci-failure-triage`: maps failing CI back to likely causes and next tasks.
+- `docs-drift-audit`: checks whether docs still match implementation.
+- `codebase-onboarding-map`: creates a concise repo map from files and conventions.
+- `release-readiness`: checks whether a goal is ready to publish.
 
-Extensions are not board truth. They may publish, report, intake, or add role guidance, but `state.yaml` remains authoritative.
+Extensions can publish, report, intake, or add role guidance. They are not board truth. `state.yaml` remains authoritative.
 
-The first cataloged extension, `github-pr-workflow`, prepares receipt-aligned commit boundaries and GitHub PR handoff text from goal receipts without requiring GitHub credentials or making GitHub authoritative. The catalog also includes GitHub Projects sync plus local-first review, recovery, planning, documentation, audit, and credential-gated handoff extensions such as `github-projects`, `ai-diff-risk-review`, `ci-failure-triage`, `docs-drift-audit`, `test-gap-planner`, `release-readiness`, `dependency-upgrade-planner`, `security-review-brief`, `codebase-onboarding-map`, `slack-standup-digest`, and `linear-ticket-handoff`.
+## Compatibility Window
 
-## Running A Goal
-
-After `$goalbuddy` creates or repairs the board, start `/goal` with the printed command:
+GoalBuddy was previously published as `goal-maker`. During the migration window, `npx goal-maker` remains available as a compatibility alias and prints the new command:
 
-```text
-/goal Follow docs/goals/<slug>/goal.md.
+```bash
+npx goalbuddy
 ```
 
-The detailed run instructions live in that goal's `goal.md`, so the kickoff prompt can stay short while the board carries the full stop rule, intake, and PM loop.
-
-By default, GoalBuddy treats broad goals as requests for continuous work, not plan-only or one-slice exercises. Missing credentials or owner input are blockers for specific tasks, not reasons to stop the goal. A queued or active Worker task blocks `goal.status: done`; finish it, block it with a receipt, or replace it with a smaller safe Worker task before final audit. For continuous execution boards, a final audit must prove the full original outcome is complete, not merely that the latest slice passed.
-
-Check board health:
+Machine-readable commands such as `npx goal-maker install --json` keep JSON output clean so existing automation can migrate safely.
 
-```bash
-node ~/.codex/skills/goalbuddy/scripts/check-goal-state.mjs docs/goals/<slug>/state.yaml
-```
+Release automation for future npm publishes is documented in [RELEASE.md](RELEASE.md).
 
-## Example
+## Examples
 
-See `examples/improve-goal-maker/` for a small completed reliability run, `examples/extend-catalog-workflow/` for a larger run that moves from product framing through implementation and repo cleanup, and `examples/github-pr-workflow-extension/pr-handoff.md` for an extension-generated PR handoff artifact.
+- `examples/improve-goal-maker/`: a small completed reliability run.
+- `examples/extend-catalog-workflow/`: a larger run from product framing through implementation and cleanup.
+- `examples/github-pr-workflow-extension/pr-handoff.md`: an extension-generated PR handoff artifact.
 
-## Repo Contents
+## Repo Map
 
-- `goalbuddy/SKILL.md`: the canonical Codex skill
+- `goalbuddy/SKILL.md`: canonical Codex skill
 - `goalbuddy/agents/`: Scout, Judge, and Worker definitions
 - `goalbuddy/templates/`: `goal.md`, `state.yaml`, and `note.md`
 - `goalbuddy/scripts/check-goal-state.mjs`: v2 board checker
-- `goal-maker/`: temporary compatibility skill payload for existing users
 - `internal/cli/goal-maker.mjs`: npm installer CLI
 - `plugins/goalbuddy/`: repo-local Codex plugin package scaffold
 - `extend/` and `extend/catalog.json`: GitHub-hosted extension surface
@@ -208,9 +206,9 @@ See `examples/improve-goal-maker/` for a small completed reliability run, `examp
 
 ## Status
 
-`0.2.x` is the v2 board/receipt model. It intentionally rejects old v1 `gate`, `units`, `artifacts`, and `evidence.jsonl` goal folders instead of auto-migrating them.
+`0.2.x` is the v2 board and receipt model. It intentionally rejects old v1 `gate`, `units`, `artifacts`, and `evidence.jsonl` goal folders instead of auto-migrating them.
 
-Use this to structure autonomous Codex work. Keep relying on repo-specific `AGENTS.md`, tests, and CI for repo facts.
+Use GoalBuddy to structure autonomous Codex work. Keep relying on repo-specific `AGENTS.md`, tests, and CI for repo facts.
 
 ## License
 

package/goalbuddy/SKILL.md

@@ -15,6 +15,28 @@ The loop is:
 raw user intent -> intake compiler -> discovery/plan validation/execution board -> one active task -> receipt -> board update -> repeat
 ```
 
+## Invocation Boundary
+
+There are two different modes:
+
+- `$goalbuddy`: prepare intake, `goal.md`, `state.yaml`, and the starter `/goal` command, then stop.
+- `/goal Follow docs/goals/<slug>/goal.md.`: execute the board, including Scout/Judge/Worker work.
+
+This boundary is strict. `$goalbuddy` is not a lightweight `/goal`; it is a board compiler.
+
+During a `$goalbuddy` turn, do not perform the user's requested work, even if the work looks read-only, preparatory, or obviously useful. Do not refresh or load named skills, inspect implementation files, browse reference repos, research design inspiration, generate design plans, generate images/assets, run app-specific checks, start servers, or edit product files. Put those actions into Scout, Judge, Worker, or PM tasks for the later `/goal` run.
+
+Allowed `$goalbuddy` actions:
+
+- ask diagnostic intake questions and wait when required;
+- create or repair only `docs/goals/<slug>/goal.md`, `docs/goals/<slug>/state.yaml`, and `docs/goals/<slug>/notes/`;
+- optionally run the GoalBuddy board checker against that `state.yaml`;
+- verify that the GoalBuddy agents are installed, if this can be done without touching implementation work;
+- print exactly `/goal Follow docs/goals/<slug>/goal.md.`;
+- ask whether to start `/goal`, refine the board, or stop.
+
+If the prompt names another skill or tool, such as "use the taste skill", "refresh the taste skill", "look at this repo", "use browser", or "generate assets", record that requirement in the charter and seed tasks. Do not load that skill, browse that repo, or generate those assets during `$goalbuddy`.
+
 ## Intake Compiler
 
 Before creating, repairing, or running a board, privately translate the user's input into a Goal Intake. The input may be vague, specific, or detailed with an existing plan. Do not dump the intake to the user unless they ask for it.
@@ -124,6 +146,8 @@ Do:
 Do not:
 
 - start `/goal` automatically;
+- use, refresh, inspect, or load named skills requested by the goal; schedule that as `/goal` work instead;
+- browse links, inspect reference repos, read implementation files, generate design plans, generate images, or create assets for the requested outcome;
 - create or repair a board from vague/open-ended input before diagnostic intake is complete;
 - create `evidence.jsonl`, `units/`, or `artifacts/` for new v2 goals;
 - edit implementation files before the board exists;
@@ -131,9 +155,11 @@ Do not:
 - discard a user-provided plan; preserve it as facts and validate it before execution;
 - treat `goal.md` as board truth when it conflicts with `state.yaml`.
 
-## Default Bias: Users Want Work Done
+## `/goal` Default Bias: Users Want Work Done
+
+This section applies after the user starts `/goal Follow docs/goals/<slug>/goal.md.` It does not apply to the initial `$goalbuddy` board-preparation turn.
 
-Unless the user explicitly asks for planning only, treat a GoalBuddy request as a request for work to happen.
+Unless the user explicitly asks for planning only, treat a `/goal` run as a request for work to happen.
 
 Planning, Scout findings, Judge decisions, and a queued Worker task are not terminal outcomes when the user's original ask is for a working capability, automation, fix, cleanup, or backend/frontend behavior. They are setup for execution.
 

package/internal/assets/goalbuddy-logo.svg

@@ -0,0 +1,21 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 760 190" role="img" aria-labelledby="title desc">
+  <title id="title">GoalBuddy logo</title>
+  <desc id="desc">GoalBuddy wordmark with lavender cloud mark.</desc>
+  <defs>
+    <radialGradient id="logoMarkGrad" cx="34%" cy="18%" r="92%">
+      <stop offset="0" stop-color="#f8f2ff"/>
+      <stop offset="0.46" stop-color="#b6a9ff"/>
+      <stop offset="1" stop-color="#5361ff"/>
+    </radialGradient>
+    <filter id="logoShadow" x="-20%" y="-25%" width="140%" height="160%">
+      <feDropShadow dx="0" dy="12" stdDeviation="10" flood-color="#4d48b8" flood-opacity=".24"/>
+    </filter>
+  </defs>
+  <g filter="url(#logoShadow)">
+    <path d="M72 141c-30 0-54-24-54-54 0-26 18-48 43-53C65 15 82 0 103 0c18 0 34 10 42 24 12-8 27-13 43-13 36 0 66 26 72 61 22 11 37 33 37 59 0 36-30 66-66 66H93c-8 0-15-2-21-6z" transform="translate(0 4) scale(.82)" fill="url(#logoMarkGrad)"/>
+    <ellipse cx="82" cy="81" rx="8" ry="12" fill="#061238"/>
+    <ellipse cx="132" cy="81" rx="8" ry="12" fill="#061238"/>
+    <path d="M99 101c8 9 18 9 27 0" fill="none" stroke="#061238" stroke-width="7" stroke-linecap="round"/>
+  </g>
+  <text x="230" y="116" fill="#071236" font-family="Geist, Avenir Next, Arial, sans-serif" font-size="82" font-weight="800" letter-spacing="-1">GoalBuddy</text>
+</svg>

package/internal/cli/goal-maker.mjs

@@ -188,9 +188,8 @@ function installSkill({ force = true, quiet = false } = {}) {
 
   mkdirSync(dirname(legacyTarget), { recursive: true });
   rmSync(legacyTarget, { recursive: true, force: true });
-  cpSync(skillSource, legacyTarget, {
-    recursive: true,
-  });
+  mkdirSync(legacyTarget, { recursive: true });
+  writeFileSync(join(legacyTarget, "SKILL.md"), compatibilitySkillBody());
   restoreInstalledExtensions(legacyTarget, extensionTempPath);
   writeInstallMetadata(legacyTarget, previousMetadata);
   cleanupPreservedExtensions([extensionTempPath]);
@@ -211,6 +210,28 @@ function installSkill({ force = true, quiet = false } = {}) {
   };
 }
 
+function compatibilitySkillBody() {
+  return `---
+name: ${legacySkillName}
+description: Compatibility alias for GoalBuddy. Use $${canonicalSkillName} as the canonical skill.
+---
+
+# GoalBuddy Compatibility Alias
+
+$${legacySkillName} is the previous name for $${canonicalSkillName}.
+
+Use $${canonicalSkillName} for new work. This compatibility skill exists so older prompts and local installs do not fail after the rebrand.
+
+When invoked through $${legacySkillName}:
+
+1. Tell the user Goal Maker has been rebranded to GoalBuddy.
+2. Show the canonical command: $${canonicalSkillName}.
+3. If the user wants to continue immediately, follow the same workflow as $${canonicalSkillName}: run diagnostic intake, create or repair \`docs/goals/<slug>/goal.md\` and \`state.yaml\`, preserve one active task, and print \`/goal Follow docs/goals/<slug>/goal.md.\` without starting \`/goal\` automatically.
+
+This alias has the same invocation boundary as \`$${canonicalSkillName}\`: prepare the board only. Do not use or refresh named skills, inspect implementation files, browse references, research, generate assets, or perform the requested work until the user starts the printed \`/goal\` command.
+`;
+}
+
 function installAgents({ quiet = false } = {}) {
   const source = join(skillSource, "agents");
   const target = join(codexHome(), "agents");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "goalbuddy",
-  "version": "0.2.11",
+  "version": "0.2.13",
   "description": "Turn open-ended Codex goals into a GoalBuddy Scout/Judge/Worker board with receipts, verification, and optional extensions.",
   "type": "module",
   "bin": {
@@ -8,6 +8,7 @@
     "goal-maker": "internal/cli/goal-maker.mjs"
   },
   "files": [
+    ".agents/plugins/marketplace.json",
     "README.md",
     "CONTRIBUTING.md",
     "examples",
@@ -17,14 +18,10 @@
     "goalbuddy/SKILL.md",
     "goalbuddy/agents",
     "goalbuddy/scripts",
-    "goalbuddy/templates",
-    "goal-maker/SKILL.md",
-    "goal-maker/agents",
-    "goal-maker/scripts",
-    "goal-maker/templates"
+    "goalbuddy/templates"
   ],
   "scripts": {
-    "check": "node --check internal/cli/goal-maker.mjs goal-maker/scripts/*.mjs goalbuddy/scripts/*.mjs && node --test internal/test/*.test.mjs",
+    "check": "node --check internal/cli/goal-maker.mjs goalbuddy/scripts/*.mjs && node --test internal/test/*.test.mjs",
     "test": "node --test internal/test/*.test.mjs",
     "pack:dry-run": "npm pack --dry-run",
     "publish:check": "node internal/cli/check-publish-version.mjs && npm run pack:dry-run",

package/plugins/goalbuddy/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "goalbuddy",
-  "version": "0.2.10",
+  "version": "0.2.13",
   "description": "Turn broad Codex work into verified GoalBuddy boards with Scout, Judge, Worker, receipts, and optional extensions.",
   "author": {
     "name": "tolibear",

package/plugins/goalbuddy/README.md

@@ -17,6 +17,16 @@ npm run check
 npx goalbuddy doctor
 ```
 
+## Native Codex Install
+
+Add the repository as a Codex plugin marketplace:
+
+```bash
+codex plugin marketplace add tolibear/goalbuddy
+```
+
+Then enable the `goalbuddy` plugin from that marketplace in Codex. The npm CLI remains useful for `doctor`, project-local agent setup, and optional GoalBuddy extension management.
+
 For local CLI testing before npm publish:
 
 ```bash
@@ -26,4 +36,4 @@ node internal/cli/goal-maker.mjs doctor
 
 ## Release Notes
 
-The plugin is prepared for the `tolibear/goalbuddy` repo and `goalbuddy` npm package. Do not publish this plugin until the owner completes the GitHub and npm handoff steps in `docs/goals/goalbuddy-rebrand-plugin/state.yaml`.
+The plugin is prepared for the `tolibear/goalbuddy` repo and `goalbuddy` npm package. Keep `.codex-plugin/plugin.json` aligned with `package.json` before publishing a new package release.

package/plugins/goalbuddy/skills/goalbuddy/SKILL.md

@@ -15,6 +15,28 @@ The loop is:
 raw user intent -> intake compiler -> discovery/plan validation/execution board -> one active task -> receipt -> board update -> repeat
 ```
 
+## Invocation Boundary
+
+There are two different modes:
+
+- `$goalbuddy`: prepare intake, `goal.md`, `state.yaml`, and the starter `/goal` command, then stop.
+- `/goal Follow docs/goals/<slug>/goal.md.`: execute the board, including Scout/Judge/Worker work.
+
+This boundary is strict. `$goalbuddy` is not a lightweight `/goal`; it is a board compiler.
+
+During a `$goalbuddy` turn, do not perform the user's requested work, even if the work looks read-only, preparatory, or obviously useful. Do not refresh or load named skills, inspect implementation files, browse reference repos, research design inspiration, generate design plans, generate images/assets, run app-specific checks, start servers, or edit product files. Put those actions into Scout, Judge, Worker, or PM tasks for the later `/goal` run.
+
+Allowed `$goalbuddy` actions:
+
+- ask diagnostic intake questions and wait when required;
+- create or repair only `docs/goals/<slug>/goal.md`, `docs/goals/<slug>/state.yaml`, and `docs/goals/<slug>/notes/`;
+- optionally run the GoalBuddy board checker against that `state.yaml`;
+- verify that the GoalBuddy agents are installed, if this can be done without touching implementation work;
+- print exactly `/goal Follow docs/goals/<slug>/goal.md.`;
+- ask whether to start `/goal`, refine the board, or stop.
+
+If the prompt names another skill or tool, such as "use the taste skill", "refresh the taste skill", "look at this repo", "use browser", or "generate assets", record that requirement in the charter and seed tasks. Do not load that skill, browse that repo, or generate those assets during `$goalbuddy`.
+
 ## Intake Compiler
 
 Before creating, repairing, or running a board, privately translate the user's input into a Goal Intake. The input may be vague, specific, or detailed with an existing plan. Do not dump the intake to the user unless they ask for it.
@@ -124,6 +146,8 @@ Do:
 Do not:
 
 - start `/goal` automatically;
+- use, refresh, inspect, or load named skills requested by the goal; schedule that as `/goal` work instead;
+- browse links, inspect reference repos, read implementation files, generate design plans, generate images, or create assets for the requested outcome;
 - create or repair a board from vague/open-ended input before diagnostic intake is complete;
 - create `evidence.jsonl`, `units/`, or `artifacts/` for new v2 goals;
 - edit implementation files before the board exists;
@@ -131,9 +155,11 @@ Do not:
 - discard a user-provided plan; preserve it as facts and validate it before execution;
 - treat `goal.md` as board truth when it conflicts with `state.yaml`.
 
-## Default Bias: Users Want Work Done
+## `/goal` Default Bias: Users Want Work Done
+
+This section applies after the user starts `/goal Follow docs/goals/<slug>/goal.md.` It does not apply to the initial `$goalbuddy` board-preparation turn.
 
-Unless the user explicitly asks for planning only, treat a GoalBuddy request as a request for work to happen.
+Unless the user explicitly asks for planning only, treat a `/goal` run as a request for work to happen.
 
 Planning, Scout findings, Judge decisions, and a queued Worker task are not terminal outcomes when the user's original ask is for a working capability, automation, fix, cleanup, or backend/frontend behavior. They are setup for execution.
 

package/goal-maker/SKILL.md

@@ -1,18 +0,0 @@
----
-name: goal-maker
-description: Compatibility alias for GoalBuddy during the rebrand migration window. Use $goalbuddy as the canonical skill.
----
-
-# GoalBuddy Compatibility Alias
-
-`$goal-maker` is the previous name for `$goalbuddy`.
-
-Use `$goalbuddy` for new work. This compatibility skill exists so older prompts and local installs do not fail during the 60-90 day migration window.
-
-When invoked through `$goal-maker`:
-
-1. Tell the user Goal Maker has been rebranded to GoalBuddy.
-2. Show the canonical command: `$goalbuddy`.
-3. If the user wants to continue immediately, follow the same workflow as `$goalbuddy`: run diagnostic intake, create or repair `docs/goals/<slug>/goal.md` and `state.yaml`, preserve one active task, and print `/goal Follow docs/goals/<slug>/goal.md.` without starting `/goal` automatically.
-
-Do not remove support for existing Goal Maker boards. GoalBuddy remains compatible with v2 `state.yaml` boards, existing `goal_*` agent role files, and installed extensions.

package/goal-maker/agents/README.md

@@ -1,23 +0,0 @@
-# Goal Maker Agents
-
-This directory contains both skill metadata and bundled agent definitions.
-
-- `openai.yaml` stays with the skill as metadata.
-- `goal_*.toml` files can be copied into `.codex/agents/` for project-scoped agents or `~/.codex/agents/` for personal agents.
-
-| Agent | File | Reasoning effort | Sandbox |
-|---|---|---:|---|
-| Scout | `goal_scout.toml` | medium | read-only |
-| Worker | `goal_worker.toml` | low | workspace-write |
-| Judge | `goal_judge.toml` | high | read-only |
-
-Recommended config:
-
-```toml
-[agents]
-max_threads = 4
-max_depth = 1
-job_max_runtime_seconds = 1800
-```
-
-Only the main `/goal` PM loop may select the active task, mark tasks done, update board truth, or mark the goal complete.