goalbuddy 0.2.21 → 0.3.0

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

@@ -0,0 +1,24 @@
+{
+  "name": "goalbuddy",
+  "version": "0.3.0",
+  "description": "Turn broad Claude Code work into verified GoalBuddy boards with Scout, Judge, Worker, visual boards, and receipts.",
+  "author": {
+    "name": "tolibear",
+    "email": "support@tolibear.com",
+    "url": "https://github.com/tolibear"
+  },
+  "homepage": "https://goalbuddy.dev",
+  "repository": "https://github.com/tolibear/goalbuddy",
+  "license": "MIT",
+  "keywords": [
+    "claude-code",
+    "claude-code-plugin",
+    "claude-code-skill",
+    "goalbuddy",
+    "goal",
+    "task-board",
+    "receipts",
+    "workflow",
+    "extensions"
+  ]
+}

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

@@ -1,7 +1,7 @@
 {
   "name": "goalbuddy",
-  "version": "0.2.21",
-  "description": "Turn broad Codex work into verified GoalBuddy boards with Scout, Judge, Worker, receipts, and optional extensions.",
+  "version": "0.3.0",
+  "description": "Turn broad Codex and Claude Code work into verified GoalBuddy boards with Scout, Judge, Worker, visual boards, and receipts.",
   "author": {
     "name": "tolibear",
     "email": "support@tolibear.com",
@@ -13,6 +13,7 @@
   "keywords": [
     "goalbuddy",
     "codex",
+    "claude-code",
     "skills",
     "goal",
     "task-board",
@@ -23,8 +24,8 @@
   "skills": "./skills/",
   "interface": {
     "displayName": "GoalBuddy",
-    "shortDescription": "Turn broad Codex work into verified Scout/Judge/Worker boards",
-    "longDescription": "GoalBuddy packages a structured Codex goal workflow for broad, long-running, or ambiguous engineering work. It creates durable goal charters, task boards, receipts, verification gates, extension handoffs, and compatibility guidance for teams moving from goal-maker.",
+    "shortDescription": "Turn broad Codex or Claude Code work into verified Scout/Judge/Worker boards",
+    "longDescription": "GoalBuddy packages a structured goal workflow for broad, long-running, or ambiguous engineering work in Codex or Claude Code. It creates durable goal charters, task boards, visual board surfaces, receipts, verification gates, extension handoffs, and compatibility guidance for teams moving from goal-maker.",
     "developerName": "tolibear",
     "category": "Coding",
     "capabilities": [

package/plugins/goalbuddy/README.md

@@ -1,11 +1,14 @@
-# GoalBuddy Codex Plugin
+# GoalBuddy Plugin (Codex + Claude Code)
 
-GoalBuddy packages the canonical `$goal-prep` skill as a Codex plugin so teams can install the reusable workflow as a plugin while keeping the npm CLI for local setup, doctor checks, and extension management.
+GoalBuddy packages the canonical `goal-prep` skill as a plugin so teams can install the reusable workflow in **Codex** and **Claude Code**, while keeping the npm CLI for local setup, doctor checks, and extension management.
 
 ## What It Contains
 
-- `.codex-plugin/plugin.json`: plugin metadata and Codex UI copy.
-- `skills/goalbuddy/`: the installable GoalBuddy skill payload.
+- `.codex-plugin/plugin.json`: Codex plugin manifest and Codex UI copy.
+- `.claude-plugin/plugin.json`: Claude Code plugin manifest.
+- `skills/goalbuddy/`: the installable GoalBuddy skill payload (shared by both platforms).
+- `agents/`: Claude Code subagent definitions (`goal-scout.md`, `goal-judge.md`, `goal-worker.md`).
+- `commands/goal-prep.md`: Claude Code slash command entry point.
 - `assets/goalbuddy-icon.svg`: lightweight plugin icon.
 
 ## Local Testing
@@ -18,29 +21,36 @@ npx goalbuddy doctor
 npx goalbuddy check-update
 ```
 
-## Native Codex Install
-
-Install and enable GoalBuddy:
+## Install Both Targets
 
 ```bash
 npx goalbuddy
 ```
 
-Restart Codex, then use `$goal-prep`. Optional extensions can be installed with:
+This installs and enables the native Codex plugin in `~/.codex/`, then installs the GoalBuddy skill, Scout/Judge/Worker subagents, and `/goal-prep` slash command into `~/.claude/`.
+
+## Install One Target
 
 ```bash
-npx goalbuddy extend install --all
+npx goalbuddy --target codex
+npx goalbuddy --target claude
+```
+
+This installs the GoalBuddy skill, the three Scout/Judge/Worker subagents, and the `/goal-prep` slash command into `~/.claude/`. Restart Claude Code, then run:
+
+```text
+/goal-prep
 ```
 
 Or install the npm package globally:
 
 ```bash
 npm i -g goalbuddy
-goalbuddy
+goalbuddy                  # installs for Codex and Claude Code
+goalbuddy --target codex   # installs for Codex only
+goalbuddy --target claude  # installs for Claude Code only
 ```
 
-The marketplace manifest is included for Codex discovery, but current Codex CLI builds only register the marketplace with `codex plugin marketplace add`; the npm CLI also caches and enables the plugin.
-
 For local CLI testing before npm publish:
 
 ```bash
@@ -50,4 +60,4 @@ node internal/cli/goal-maker.mjs doctor
 
 ## Release Notes
 
-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.
+The plugin is prepared for the `tolibear/goalbuddy` repo and `goalbuddy` npm package. Keep `.codex-plugin/plugin.json` and `.claude-plugin/plugin.json` aligned with `package.json` before publishing a new package release.

package/plugins/goalbuddy/agents/goal-judge.md

@@ -0,0 +1,27 @@
+---
+name: goal-judge
+description: GoalBuddy Judge. High-thinking strategic reviewer for GoalBuddy escalation: ambiguity, risky scope, source/product conflicts, safety/API/live decisions, and tranche completion. Returns a compact Judge receipt for the PM to paste into state.yaml.
+tools: Read, Grep, Glob, Bash
+---
+
+You are Judge for GoalBuddy.
+
+Thinking level: high.
+Mode: strategic reviewer and escalation authority.
+
+Think as a skeptical staff engineer and project-management systems designer. You decide and constrain; you do not broadly implement.
+
+Use when source, tests, product behavior, API/live strategy, dirty scope, giant-file risk, safety/auth/money/persistence semantics, task priority, or completion readiness is ambiguous.
+
+Do not approve based on lots of docs or lots of tests. Require coherent receipts and current verification.
+
+Return a compact Judge receipt for the PM to paste into state.yaml:
+- result
+- decision
+- evidence
+- next_allowed_task when work may continue
+- blocked_tasks when work should not proceed
+- completion decision when auditing a tranche
+- required board updates
+
+Do not broadly implement, select the active task, or mark the goal complete yourself.

package/plugins/goalbuddy/agents/goal-scout.md

@@ -0,0 +1,24 @@
+---
+name: goal-scout
+description: GoalBuddy Scout. Read-only evidence mapper for one GoalBuddy task. Finds repo/source/spec evidence, verification commands, ambiguities, and candidate next tasks. Returns a compact Scout receipt for the PM to paste into state.yaml.
+tools: Read, Grep, Glob, Bash
+---
+
+You are Scout for GoalBuddy.
+
+Thinking level: medium.
+Mode: read-only evidence mapping.
+
+You are read-only. Do not edit files, stage files, run destructive commands, or claim implementation is complete.
+
+Given one active Scout task, map repo/source/spec evidence, verification commands, health signals, improvement candidates, target files, tests, and unresolved ambiguity.
+
+Return a compact Scout receipt for the PM to paste into state.yaml:
+- result
+- summary
+- evidence paths
+- note path if findings are too large for the task card
+- spawned_tasks when useful
+- ambiguity requiring Judge
+
+Do not select the active task or mark the goal complete.

package/plugins/goalbuddy/agents/goal-worker.md

@@ -0,0 +1,26 @@
+---
+name: goal-worker
+description: GoalBuddy Worker. Low-thinking bounded implementer for exactly one GoalBuddy Worker task with allowed files, verification commands, and stop conditions. Returns a compact Worker receipt for the PM to paste into state.yaml.
+tools: Read, Edit, Write, Grep, Glob, Bash
+---
+
+You are Worker for GoalBuddy.
+
+Thinking level: low.
+Mode: one bounded writer.
+
+Execute exactly one active Worker task. Do not broaden scope.
+
+You may edit only the task's allowed_files. You may update only explicitly named control files if the PM included them in scope. Do not decide product behavior, retained/excluded scope, API/live/deployment strategy, architecture direction, parity, or completion readiness.
+
+Stop immediately if required evidence is missing, files outside scope are needed, source/tests/product conflict, verification fails twice, or the diff exceeds the task budget.
+
+Return a compact Worker receipt for the PM to paste into state.yaml:
+- result
+- changed_files
+- commands run with pass/fail
+- summary
+- remaining_blockers
+- needs_judge when strategy or ambiguity remains
+
+Do not select the next active task or mark the goal complete.

package/plugins/goalbuddy/commands/goal-prep.md

@@ -0,0 +1,12 @@
+---
+description: Prepare a GoalBuddy board for a broad, long-running, or ambiguous goal. Compiles intake, writes goal.md/state.yaml, and prints the /goal command to run next. Does not start /goal automatically.
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+Invoke the GoalBuddy `goal-prep` skill to prepare a board for the user's goal.
+
+Follow the canonical GoalBuddy invocation boundary: prepare intake, create or repair `docs/goals/<slug>/goal.md`, `state.yaml`, and `notes/`, optionally open a visual board, then print exactly `/goal Follow docs/goals/<slug>/goal.md.` and stop.
+
+Do not perform the requested work during this turn, even if it looks read-only or obviously useful. Put implementation, research, asset generation, and named-skill loading into Scout, Judge, or Worker tasks for the later `/goal` run.
+
+User goal: $ARGUMENTS

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

@@ -1,13 +1,13 @@
 ---
 name: goal-prep
-description: Goal Prep for GoalBuddy. Use for broad, long-running, stalled, vague, detailed, planned, or unhealthy Codex work that needs a structured /goal intake, autonomous task discovery, role-tagged Scout/Judge/Worker delegation, one active task, durable receipts, and a PM-owned rolling board that maximizes the chance of a successful goal run.
+description: Goal Prep for GoalBuddy. Use for broad, long-running, stalled, vague, detailed, planned, or unhealthy Codex or Claude Code work that needs a structured /goal intake, autonomous task discovery, role-tagged Scout/Judge/Worker delegation, one active task, durable receipts, and a PM-owned rolling board that maximizes the chance of a successful goal run.
 ---
 
 # Goal Prep
 
-`$goal-prep` prepares a GoalBuddy board. It does not start `/goal` automatically, but the board and starter `/goal` command must be shaped so the next run continues into safe execution by default.
+`$goal-prep` (Codex) or `/goal-prep` (Claude Code) prepares a GoalBuddy board. It does not start `/goal` automatically, but the board and starter `/goal` command must be shaped so the next run continues into safe execution by default.
 
-GoalBuddy is for autonomous, long-running Codex work where the PM thread may need to discover the work, define tasks, sequence them, delegate them, execute them, verify them, and keep going without the human decomposing every step.
+GoalBuddy is for autonomous, long-running Codex or Claude Code work where the PM thread may need to discover the work, define tasks, sequence them, delegate them, execute them, verify them, and keep going without the human decomposing every step.
 
 The loop is:
 
@@ -24,15 +24,16 @@ There are two different modes:
 
 This boundary is strict. `$goal-prep` is not a lightweight `/goal`; it is a board compiler.
 
-During a `$goal-prep` 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.
+During a `$goal-prep` 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, or edit product files. Put those actions into Scout, Judge, Worker, or PM tasks for the later `/goal` run.
 
 Allowed `$goal-prep` actions:
 
 - run the bundled GoalBuddy update checker and mention a newer version if one is available;
 - 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/`;
+- create or repair only `docs/goals/<slug>/goal.md`, `docs/goals/<slug>/state.yaml`, `docs/goals/<slug>/notes/`, and the generated `.goalbuddy-board/` visual board artifact;
+- create and open the selected visual board surface for the goal;
 - 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;
+- verify GoalBuddy agent availability, if this can be done without touching implementation work, and record `installed`, `bundled_not_installed`, `missing`, or `unknown` truthfully;
 - print exactly `/goal Follow docs/goals/<slug>/goal.md.`;
 - ask whether to start `/goal`, refine the board, or stop.
 
@@ -72,6 +73,22 @@ Extract:
 - blind spots: important risks, choices, or success dimensions the user may not have named yet;
 - existing plan facts: user-provided steps, files, constraints, or sequencing that must be preserved but still validated.
 
+Ask the visual-board question early, before detailed task shaping:
+
+```text
+Do you want to set up a visual board for this?
+```
+
+Recommended options:
+
+1. Local live board (Recommended) - starts immediately, requires no credentials, and lets the user watch tasks populate inside Codex or Claude Code.
+2. GitHub Projects - best when stakeholders need a shared external board and the user can approve GitHub credentials/project details.
+3. No visual board - best for quick or private goals where the file board is enough.
+
+If the user chooses the local live board, create the goal directory, `notes/`, and an initial minimal `state.yaml` as soon as the slug is known, then run `npx goalbuddy board docs/goals/<slug>` and open the printed local URL in the AI coding agent's in-app browser (the Codex in-app Browser, the Claude Code preview, or the user's regular browser). In short: start the local board before filling the task list so the board pops up right away and cards populate live as `state.yaml` changes. Keep the printed URL in the final prep response as a fallback, but do not make the URL the primary experience.
+
+If the user chooses GitHub Projects, ask for approval and the required project target before any live write. Create or sync the GitHub Project at the same early point as the local board: after the goal root and skeleton `state.yaml` exist, before the detailed task list is finished, then sync again as tasks populate. Run a dry-run sync first when possible. Missing GitHub credentials or project details should not block local board creation or goal prep; record the missing requirement in `visual_board.github_projects` and seed a PM setup task.
+
 Ask before board creation when the request is vague, strategic, improvement-oriented, or open-ended and the user has not explicitly said to use defaults. Ask one guided question at a time with 2-3 options and a recommended default, then wait. Continue the diagnostic intake until the user's answers are sufficient to choose the board shape. Do not create or repair `docs/goals/<slug>/` until the diagnostic intake is complete or the user explicitly accepts defaults.
 
 For vague or strategic goals, one answer is rarely enough. After each answer, reflect what it implies, name one likely blind spot, and ask the next material question. The goal is to help the user discover what they mean, not merely collect a form value.
@@ -117,14 +134,15 @@ Stop after each question. Do not create files, repair an existing board, run che
 
 Minimum diagnostic ladder for vague, strategic, or improvement-oriented goals:
 
-1. Intent target: what kind of improvement or outcome matters most?
-2. Success proof: what evidence would convince the user this worked?
-3. Scope and non-goals: what should remain untouched or explicitly out of scope?
-4. Board handling: reuse an existing board, create a fresh board, or inspect first?
+1. Visual board: ask "Do you want to set up a visual board for this?"
+2. Intent target: what kind of improvement or outcome matters most?
+3. Success proof: what evidence would convince the user this worked?
+4. Scope and non-goals: what should remain untouched or explicitly out of scope?
+5. Goal handling: reuse an existing goal, create a fresh goal, or inspect first?
 
 Ask these one at a time. Skip a step only when the user's words already answer it clearly. After the user answers one step, do not assume the remaining steps; ask the next unresolved material question.
 
-For "make GoalBuddy better", a good first question is which improvement target matters most: intake clarity, board/execution reliability, completion proof/eval coverage, or user experience during long-running goals. A good second question asks what proof would convince the user it improved. A good third question asks whether to reuse an existing board, create a fresh board, or inspect first.
+For "make GoalBuddy better", a good first question is which improvement target matters most: intake clarity, board/execution reliability, completion proof/eval coverage, or user experience during long-running goals. A good second question asks what proof would convince the user it improved. A good third question asks whether to reuse an existing goal, create a fresh goal, or inspect first.
 
 ## Direct `/goal` Entry
 
@@ -155,9 +173,10 @@ Do:
 - classify the goal as `specific`, `open_ended`, `existing_plan`, `recovery`, or `audit`;
 - create or repair `docs/goals/<slug>/`;
 - create `goal.md`, `state.yaml`, and `notes/`;
+- if requested, start the local visual board immediately and open it in the AI coding agent's in-app browser (Codex in-app Browser, Claude Code preview, or the user's regular browser) before filling the task list;
 - seed a role-tagged task board that matches the input shape;
 - make the first active task safe;
-- verify Scout, Worker, and Judge agents are installed or explain what is missing;
+- verify Scout, Worker, and Judge agent availability or record an explicit truthful state;
 - print the exact command `/goal Follow docs/goals/<slug>/goal.md.`;
 - ask whether to start now, refine `goal.md`, or stop.
 
@@ -221,7 +240,7 @@ docs/goals/<slug>/
   notes/
 ```
 
-The goal root may contain only `goal.md`, `state.yaml`, and `notes/`.
+The goal root may contain only `goal.md`, `state.yaml`, `notes/`, and generated `.goalbuddy-board/` files when the local visual board is enabled.
 
 Most results live inline as task receipts in `state.yaml`. Only create `notes/<task-id>-<slug>.md` when Scout, Judge, or PM output is too large to fit on the task card.
 
@@ -472,7 +491,18 @@ If the checker and your judgment disagree, choose the more conservative state.
 
 ## Agents
 
-Scout, Worker, and Judge are default-installed roles.
+Scout, Worker, and Judge templates are bundled with GoalBuddy. They may also be installed as user or project agent configs, but a board must not claim `installed` unless the preparer verified the matching agent files.
+
+Use these `state.yaml` values:
+
+| State | Meaning | Next action |
+|---|---|---|
+| `installed` | Matching Scout/Worker/Judge agent configs were found in the expected user or project agent location. | Continue. |
+| `bundled_not_installed` | The bundled `goal_*.toml` template exists with the skill, but no matching installed agent config was verified. | `/goal` can proceed through PM fallback. If dedicated agents are required before `/goal`, run `npx goalbuddy agents`. |
+| `missing` | Neither an installed config nor the bundled template was verified. | `/goal` can proceed through PM fallback. If dedicated agents are required before `/goal`, run `npx goalbuddy install`. |
+| `unknown` | Agent availability could not be checked. | `/goal` can proceed through PM fallback. To check before `/goal`, run `npx goalbuddy doctor`. |
+
+Non-`installed` states are warnings, not false failures, because the main `/goal` PM can perform Scout/Judge/Worker-shaped tasks directly when dedicated agents are unavailable.
 
 | Agent | Thinking level | Write access | Use for |
 |---|---:|---:|---|

package/plugins/goalbuddy/skills/goalbuddy/agents/README.md

@@ -1,17 +1,22 @@
 # GoalBuddy Agents
 
-This directory contains both skill metadata and bundled agent definitions.
+This directory contains skill metadata and bundled agent definitions for Codex and Claude Code.
+
+## Files
 
 - `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.
+- `goal_scout.toml`, `goal_judge.toml`, `goal_worker.toml` — Codex agent configs. Copy into `.codex/agents/` for project-scoped agents or `~/.codex/agents/` for personal agents.
+- Claude Code agent markdown lives in `plugins/goalbuddy/agents/` (installed to `~/.claude/agents/` by `npx goalbuddy --target claude`).
+
+## Agent Matrix
 
-| 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 |
+| Agent | Codex file | Claude Code file | Reasoning effort | Write scope |
+|---|---|---|---:|---|
+| Scout | `goal_scout.toml` | `goal-scout.md` | medium | read-only |
+| Worker | `goal_worker.toml` | `goal-worker.md` | low | workspace-write |
+| Judge | `goal_judge.toml` | `goal-judge.md` | high | read-only |
 
-Recommended config:
+## Recommended Codex Config
 
 ```toml
 [agents]
@@ -20,4 +25,6 @@ max_depth = 1
 job_max_runtime_seconds = 1800
 ```
 
+## Authority Boundary
+
 Only the main `/goal` PM loop may select the active task, mark tasks done, update board truth, or mark the goal complete.

package/plugins/goalbuddy/skills/goalbuddy/extend/github-projects/README.md

@@ -0,0 +1,105 @@
+# GitHub Projects
+
+Mirror a GoalBuddy `state.yaml` board into GitHub Projects without making GitHub the source of truth.
+
+This extension ports the GitHub Projects work from PR #1 into the catalog-based extension system. It keeps the package core dependency-free and optional, while giving teams a practical way to publish a GoalBuddy board into a familiar project surface.
+
+## Use When
+
+- A long-running GoalBuddy board needs stakeholder visibility in GitHub Projects.
+- A team wants one-way sync from `state.yaml` into ProjectV2 draft issues.
+- The PM needs a dry-run plan before using GitHub credentials.
+- Existing GoalBuddy receipts, verification commands, allowed files, owners, and dependencies should be visible in a board layout.
+
+## What It Creates
+
+The live sync ensures a GitHub Project has:
+
+- Draft issues keyed by `Task ID`, so reruns update existing cards instead of duplicating them.
+- Status mapping: `queued -> Todo`, `active -> In Progress`, `blocked -> Blocked`, `done -> Done`.
+- Single-select fields for `Status`, `Priority`, `Work Type`, and `Agent Lane`.
+- Text fields for `Task ID`, `Owner`, `Goal Role`, `Agent Responsible`, `Credential Gate`, `Parent ID`, `Depends On`, `Receipt Summary`, `Verify`, `Allowed Files`, and `Goal Updated`.
+- A `Goal Board` board-layout view for PM flow.
+
+The extension must use the bundled sync script for live writes. Do not use Computer Use, browser automation, or the GitHub web UI to create or repair the board view. Do not replace the script with `gh project` commands; `gh project` does not expose the complete ProjectV2 view creation path this extension needs. The script uses GitHub GraphQL for projects, fields, items, and draft issues, plus the GitHub REST Project views endpoint for the `Goal Board` view.
+
+The sync only creates or reuses `Goal Board`. It does not create a default Table view, an `Agent Workboard`, or extra role-specific views. GitHub may still show views that already existed on the Project.
+
+The extension does not promise custom board grouping or sort order. GitHub's public Project views REST API currently accepts `name`, `layout`, `filter`, and `visible_fields` when creating a view, and GraphQL exposes grouping/sort fields for reading but not a public mutation for saving them. Because that display state cannot be written reliably through the public API, the sync only creates supported fields, cards, and the single `Goal Board` view.
+
+## Inputs
+
+- `docs/goals/<slug>/state.yaml`
+- Optional `GITHUB_PROJECT_ID`
+- Optional `GITHUB_PROJECT_OWNER` and `GITHUB_PROJECT_NUMBER`
+- `GITHUB_TOKEN` or `GH_TOKEN` for live sync
+
+## Dry Run
+
+Dry-run mode does not call GitHub:
+
+```bash
+node extend/github-projects/scripts/sync-github-project.mjs \
+  --state docs/goals/<slug>/state.yaml \
+  --dry-run
+```
+
+For structured output:
+
+```bash
+node extend/github-projects/scripts/sync-github-project.mjs \
+  --state docs/goals/<slug>/state.yaml \
+  --dry-run \
+  --json
+```
+
+## Live Sync
+
+Always run the bundled script for live sync. It creates or reuses the `Goal Board` view as part of the same run that syncs fields and draft issues.
+
+Use a ProjectV2 node ID:
+
+```bash
+GITHUB_TOKEN=... node extend/github-projects/scripts/sync-github-project.mjs \
+  --state docs/goals/<slug>/state.yaml \
+  --project-id <project-node-id>
+```
+
+Or use an owner and project number:
+
+```bash
+GITHUB_TOKEN=... node extend/github-projects/scripts/sync-github-project.mjs \
+  --state docs/goals/<slug>/state.yaml \
+  --owner <user-or-org> \
+  --project-number <number>
+```
+
+Environment alternatives:
+
+- `GITHUB_PROJECT_ID`
+- `GITHUB_PROJECT_OWNER`
+- `GITHUB_PROJECT_NUMBER`
+- `GITHUB_TOKEN` or `GH_TOKEN`
+
+## Verification
+
+```bash
+node --test extend/github-projects/test/*.test.mjs
+node extend/github-projects/scripts/sync-github-project.mjs \
+  --state extend/github-projects/examples/goal-board-sync/state.yaml \
+  --dry-run
+node extend/github-projects/scripts/sync-github-project.mjs \
+  --state extend/github-projects/examples/goal-board-sync/state.yaml \
+  --dry-run \
+  --json
+```
+
+## Boundaries
+
+- `state.yaml` remains authoritative.
+- The sync is one-way from GoalBuddy to GitHub Projects.
+- Missing GitHub credentials block only live sync, not local dry-run validation.
+- Live sync creates or updates GitHub Project draft issues, fields, and the `Goal Board` view through the bundled script.
+- Agents must not fall back to Computer Use, browser automation, or the GitHub web UI for Project setup.
+- Agents must not claim ProjectV2 board views are UI-only; GitHub's REST Project views API supports creating board-layout views.
+- Native GitHub issue hierarchy and dependencies are represented as fields because ProjectV2 draft issues do not provide full issue relationship semantics.

package/plugins/goalbuddy/skills/goalbuddy/extend/github-projects/examples/goal-board-sync/state.yaml

@@ -0,0 +1,63 @@
+version: 2
+
+goal:
+  title: "Goal board sync MVP"
+  slug: "goal-board-sync-mvp"
+  kind: specific
+  tranche: "Mirror a GoalBuddy board into an external Kanban surface."
+  status: active
+
+rules:
+  pm_owns_state: true
+  one_active_task: true
+  max_write_workers: 1
+  no_implementation_without_worker_or_pm_task: true
+  no_completion_without_judge_or_pm_audit: true
+
+active_task: T002
+
+tasks:
+  - id: T001
+    type: scout
+    assignee: Scout
+    status: done
+    priority: P3
+    objective: "Map external board API requirements."
+    inputs:
+      - "Board API docs"
+    constraints:
+      - "Read-only."
+    expected_output:
+      - "Required scopes"
+      - "Field mapping"
+    receipt:
+      result: done
+      summary: "The board sync can read GoalBuddy state.yaml and mirror tasks into an external board."
+  - id: T002
+    type: worker
+    assignee: Worker
+    status: active
+    priority: P1
+    objective: "Implement one-way external board sync."
+    parent: T001
+    depends_on:
+      - T001
+    allowed_files:
+      - "extend/github-projects/scripts/**"
+      - "README.md"
+    verify:
+      - "node --test extend/github-projects/test/*.test.mjs"
+      - "node extend/github-projects/scripts/sync-github-project.mjs --state extend/github-projects/examples/goal-board-sync/state.yaml --dry-run"
+    stop_if:
+      - "Board API credentials are unavailable."
+    receipt: null
+  - id: T003
+    type: judge
+    assignee: Judge
+    status: queued
+    priority: P2
+    objective: "Audit whether the board sync MVP is ready to document."
+    parent: T002
+    depends_on:
+      - T002
+    receipt: null

package/plugins/goalbuddy/skills/goalbuddy/extend/github-projects/extension.yaml

@@ -0,0 +1,43 @@
+id: github-projects
+name: GitHub Projects
+kind: integration
+version: 0.1.1
+source_of_truth: local
+description: Mirror GoalBuddy state.yaml tasks into GitHub Projects with dry-run planning, ProjectV2 fields, draft issue upserts, and one Goal Board view.
+local_use_prompt: Run the bundled GitHub Projects sync script for docs/goals/<slug>/state.yaml. Use --dry-run first unless the user has approved live GitHub writes, then run the same script with GITHUB_TOKEN or GH_TOKEN and --project-id or --owner plus --project-number. Do not use Computer Use, browser automation, the GitHub web UI, or gh project as a fallback.
+use_when:
+  - A long-running GoalBuddy board needs stakeholder visibility in GitHub Projects.
+  - The team wants one-way sync from state.yaml into ProjectV2 draft issues.
+  - The PM needs a safe dry-run plan before using GitHub credentials.
+  - GoalBuddy receipts, verification commands, allowed files, owners, role/agent fields, credential gates, and dependencies should appear in a GitHub board.
+activation: publish_handoff
+outputs:
+  - GitHub Projects dry-run plan
+  - GitHub ProjectV2 draft issue sync
+  - Goal Board ProjectV2 view
+requires_approval: true
+safe_by_default: false
+reads:
+  - docs/goals/<slug>/state.yaml
+  - GITHUB_PROJECT_ID
+  - GITHUB_PROJECT_OWNER
+  - GITHUB_PROJECT_NUMBER
+writes:
+  - GitHub ProjectV2 draft issues
+  - GitHub ProjectV2 fields
+  - GitHub ProjectV2 Goal Board view
+side_effects:
+  - Live sync creates or updates GitHub Project draft issues, fields, and views.
+agent_instructions:
+  - Use the bundled sync script for all live GitHub Projects writes.
+  - Do not use Computer Use, browser automation, or the GitHub web UI to create or repair Project views.
+  - Do not replace the bundled script with gh project commands; the script uses GraphQL plus the REST Project views endpoint.
+  - Do not claim ProjectV2 board views are UI-only; the GitHub REST Project views API supports creating board-layout views.
+auth:
+  env:
+    - GITHUB_TOKEN
+supports:
+  dry_run: true
+  live_github_projects: true
+  credentials_required: true
+  one_way_sync: true