// @bun
var w=Object.defineProperty;var u=(q)=>q;function E(q,J){this[q]=u.bind(null,J)}var A=(q,J)=>{for(var z in J)w(q,z,{get:J[z],enumerable:!0,configurable:!0,set:E.bind(J,z)})};var I=(q,J)=>()=>(q&&(J=q(q=0)),J);var F={};A(F,{removeRepoAssets:()=>h,installRefreshSkill:()=>W,installPlanSkill:()=>O,installInitSkill:()=>f,installCodexRepoSkills:()=>j,ensureWorkflowDoc:()=>_,ensureMcp:()=>g,auditRepo:()=>L,REFRESH_SKILL:()=>k,PLAN_SKILL:()=>b,INIT_SKILL:()=>v});import{existsSync as H,mkdirSync as D,readFileSync as X,rmSync as B,writeFileSync as G}from"fs";import{join as Q}from"path";function f(q){let J=Q(q,".claude","skills","beacon-init");D(J,{recursive:!0});let z=Q(J,"SKILL.md");return G(z,v),z}function W(q){let J=Q(q,".claude","skills","beacon-refresh");D(J,{recursive:!0});let z=Q(J,"SKILL.md");return G(z,k),z}function O(q){let J=Q(q,".claude","skills","beacon-plan");D(J,{recursive:!0});let z=Q(J,"SKILL.md");return G(z,b),z}function j(q){let J=[];for(let z of K){let Y=Q(q,".agents","skills",z.name);D(Y,{recursive:!0});let $=Q(Y,"SKILL.md");G($,z.body()),J.push($)}return J}function _(q){let J=Q(q,"AGENTS.md"),z="";try{z=X(J,"utf8")}catch{}let Y=new RegExp(`${U}[\\s\\S]*?${M}`);z=Y.test(z)?z.replace(Y,T):`${z.trim()}

${T}
`.trimStart(),G(J,z.endsWith(`
`)?z:`${z}
`);let $=Q(q,"CLAUDE.md"),C="";try{C=X($,"utf8")}catch{}if(!/@AGENTS\.md/.test(C))G($,`${C?`${C.trim()}

`:""}@AGENTS.md
`)}function g(q){let J=Q(q,".mcp.json"),z={};try{z=JSON.parse(X(J,"utf8"))}catch{}if(z.mcpServers=z.mcpServers??{},z.mcpServers.beacon)return{path:J,added:!1};return z.mcpServers.beacon={command:"beacon",args:["mcp"]},G(J,JSON.stringify(z,null,2)+`
`),{path:J,added:!0}}function L(q){let J=Q(q,".mcp.json"),z=!1;try{z=!!JSON.parse(X(J,"utf8")).mcpServers?.beacon}catch{}let Y=!1;try{Y=X(Q(q,"AGENTS.md"),"utf8").includes(U)}catch{}let $=!1;try{$=/@AGENTS\.md/.test(X(Q(q,"CLAUDE.md"),"utf8"))}catch{}return{repo:q,mcpRegistered:z,agentsMdBlock:Y,claudeMdImport:$,skills:{"beacon-init":H(Q(q,".claude","skills","beacon-init","SKILL.md")),"beacon-refresh":H(Q(q,".claude","skills","beacon-refresh","SKILL.md"))},codexSkills:{"beacon-init":H(Q(q,".agents","skills","beacon-init","SKILL.md")),"beacon-refresh":H(Q(q,".agents","skills","beacon-refresh","SKILL.md"))}}}function h(q){let J=[];for(let V of["beacon-init","beacon-refresh","beacon-db-design"]){let Z=Q(q,".claude","skills",V);if(H(Z))B(Z,{recursive:!0,force:!0}),J.push(V)}for(let V of["beacon-init","beacon-refresh"]){let Z=Q(q,".agents","skills",V);if(H(Z))B(Z,{recursive:!0,force:!0}),J.push(`codex:${V}`)}let z=!1,Y=Q(q,".mcp.json");try{let V=JSON.parse(X(Y,"utf8"));if(V.mcpServers?.beacon){if(delete V.mcpServers.beacon,z=!0,V.mcpServers&&Object.keys(V.mcpServers).length===0)delete V.mcpServers;if(Object.keys(V).length===0)B(Y,{force:!0});else G(Y,JSON.stringify(V,null,2)+`
`)}}catch{}let $=!1,C=Q(q,"AGENTS.md");try{let V=X(C,"utf8"),Z=new RegExp(`\\n?${U}[\\s\\S]*?${M}\\n?`);if(Z.test(V)){let N=V.replace(Z,`
`).replace(/\n{3,}/g,`

`).trimStart();G(C,N.endsWith(`
`)?N:`${N}
`),$=!0}}catch{}let P=!1,x=Q(q,"CLAUDE.md");try{let V=X(x,"utf8"),Z=V.replace(/^[ \t]*@AGENTS\.md[ \t]*\n?/m,"");if(Z!==V){if(!Z.trim())B(x,{force:!0});else G(x,Z);P=!0}}catch{}return{skillsRemoved:J,mcpUnregistered:z,agentsBlockRemoved:$,claudeImportRemoved:P}}var v=`---
name: beacon-init
description: Read this repository and map its architecture, schema, and roadmap into Beacon (the local visual planning panel). Use when the user runs /beacon-init, asks to "set up Beacon for this repo", or asks to initialize/bootstrap Beacon's map of this codebase.
---

# Map this repo into Beacon (/beacon-init)

The user already has Beacon running. You're going to map this repository's architecture into it \u2014 what used to be \`beacon init\`. **You** do the analysis (your session already has the codebase context); Beacon just persists what you send.

## What you produce

A single \`beacon_init_persist\` MCP tool call with:

- **components**: 8\u201325 main building blocks of this codebase. NOT every file. Group them by \`domain\` (short UPPERCASE: AUTH, API, DATA, UI, JOBS, INFRA, BILLING, SEARCH, \u2026). For each: a one-line technical \`role\`, a one-sentence plain-language \`plain\`, the few \`files\` that implement it (repo-relative), and \`depends\` listing other component titles it relies on. Use the dependency graph you can see in the source \u2014 files that import each other heavily usually belong together. If you spot a bug or something worth investigating while reading a component's code, add \`bugs: [{ note }]\` to that component \u2014 it renders as a bug flag on the node (attributed to the agent). Only flag what you actually saw in the code; don't speculate.
- **roadmap**: 3\u20136 BROAD strategic directions. Big-picture themes only \u2014 "Harden auth & security", "Add observability", "Scale the data layer", "Pay down test-coverage debt". NOT detailed tasks. NOT file-level. Each gets a short title and one-line \`why\`. If one of them is a concrete BUG to fix (something broken you saw in the code), add \`kind: "BUG"\` so it renders as a typed bug card.
- **overview**: one paragraph describing what this project is and its stack. This lands in AGENTS.md as the project intro.
- **conventions**: 3\u20138 concrete rules a contributor MUST follow \u2014 build/test commands, where code goes, patterns, things easy to get wrong. Infer from actual files, not assumptions.
- **snapshot** (optional but encouraged): \`{ tables, relations, endpoints }\` for the existing database. If the project uses Prisma, read \`prisma/schema.prisma\`. If SQLAlchemy, read the model files. If Django, read \`models.py\`. If you find no obvious schema source, skip the snapshot \u2014 don't fabricate.

## How to do it

1. **Survey**. Use \`LS\` / \`Glob\` to see the top-level structure. Read \`README.md\` and the manifest (\`package.json\` / \`pyproject.toml\` / \`go.mod\` / \`Cargo.toml\` / \`pom.xml\`).
2. **Sample the source.** Read 15\u201330 representative files \u2014 one per cluster you can identify. Don't read everything; pick by name (route files, model files, main entrypoints, key services). The goal is to identify boundaries, not memorize every line.
3. **Identify the schema** if any. \`prisma/schema.prisma\` \u2192 translate each model into a \`tables\` entry. \`alembic\`/SQLAlchemy \u2192 read the latest models. Django \u2192 read \`models.py\`. Skip the snapshot if the source-of-truth isn't obvious.
4. **Identify endpoints** if any. Look for routes \u2014 Next.js \`app/api/*\` files, FastAPI \`@router.*\` / \`@app.*\`, Express \`app.get\`/etc. For each endpoint try to fill \`uses: [{ table, access }]\` so the canvas can draw which endpoint touches which table.
5. **Call \`beacon_init_persist\`** ONCE with the whole analysis. It replaces any prior init-derived map (idempotent) and regenerates \`AGENTS.md\`.

## What you should NOT do

- Don't propose detailed tasks in \`roadmap\` \u2014 that's what \`beacon_propose_plan\` is for. Init roadmap is strategic only.
- Don't list every file as a \`component\`. Aim for ~15. If you have 40, you're listing files, not components.
- Don't fabricate tables/endpoints. If you can't find the schema source, omit \`snapshot\`.
- Don't ask the user to confirm before persisting. The user invoked /beacon-init \u2014 that's the confirmation.

If \`beacon_init_persist\` isn't available, the Beacon panel isn't running in this repo. Tell the user to run \`beacon\` here first, then re-invoke /beacon-init.

After the tool returns, tell the user the counts (components / roadmap / tables / endpoints) and point them at the running Beacon panel.
`,k=`---
name: beacon-refresh
description: Re-survey the repo and update Beacon's architecture / schema / endpoints map after /beacon-init was already run \u2014 picks up new components, removed ones, schema changes, and new routes. Use when the user runs /beacon-refresh or asks to "refresh", "update", "re-sync", or "bring Beacon up to date" with the current code.
---

# Refresh Beacon's map (/beacon-refresh)

Beacon was already initialized in this repo (\`/beacon-init\` ran at some point). The codebase has moved since then \u2014 new modules, removed ones, schema changes, new routes. Your job is to re-survey the current code, show the user what changed, then persist the refreshed map.

## How it differs from /beacon-init

- **Init is a cold start** \u2014 no prior map, you survey everything fresh.
- **Refresh is incremental** \u2014 the map already exists. Read what's there first, then diff against the source so you can tell the user what actually changed. The user gets to see "+ 3 new components, \u2212 1 removed, ~ 2 changed roles" instead of an opaque re-run.

## What gets preserved vs replaced

The \`beacon_init_persist\` tool **replaces only init-derived nodes** (\`source=INIT\`). Anything the user added manually on the canvas \u2014 manually-created components, hand-edited tables, custom positions, notes, draft feature plans \u2014 survives the refresh untouched. So you can re-run this freely; nothing the user curated by hand is at risk.

The one caveat: if the user manually edited an INIT-source node on the canvas (e.g., renamed it, rewrote its role), that edit IS overwritten when you re-persist. If the user mentions hand-curated INIT nodes, ask whether they want those carried into the new analysis verbatim.

## How to do it

1. **Read the current map.** Call \`beacon_entities\` with \`{ kind: "architecture" }\`, \`{ kind: "roadmap" }\`, \`{ kind: "tables" }\`, \`{ kind: "endpoints" }\`. This is what Beacon has now.
2. **Survey the source like init.** Same approach as \`/beacon-init\`: \`LS\` / \`Glob\` for top-level structure, read \`README.md\` and the manifest, sample 15\u201330 representative files. Focus on areas likely to have changed \u2014 diff your memory against what \`beacon_entities\` returned.
3. **Build the diff in your head.** For each entity kind:
   - **components**: which titles in the current map no longer match any cluster you'd produce? Which clusters you'd produce don't appear in the current map?
   - **tables**: any added / removed since? Any model files you can see that aren't in the snapshot?
   - **endpoints**: walk the route directories \u2014 any new routes, any deleted ones?
   - **roadmap**: usually stable, but a strategic theme can finish or new ones can emerge.
4. **Surface the diff to the user, briefly, BEFORE persisting.** Something like:
   - **+ added**: NEW_COMPONENT_1, NEW_COMPONENT_2 (with one-line reason each)
   - **\u2212 removed**: STALE_COMPONENT (file no longer exists)
   - **~ changed**: COMPONENT_X (role expanded to cover Y)
   - **schema**: + 2 new tables (TableA, TableB); + 3 new endpoints; \u2212 1 deprecated endpoint
   No need to wait for confirmation \u2014 just show the diff so the user sees what's about to land.
5. **Call \`beacon_init_persist\`** ONCE with the refreshed full analysis (same shape as init: \`components\`, \`roadmap\`, \`overview\`, \`conventions\`, \`snapshot\`). It replaces all init-source nodes and regenerates \`AGENTS.md\`. Bug flags already on a component survive the refresh (they're carried over by title); add \`bugs: [{ note }]\` for anything NEW you found worth investigating \u2014 identical open flags are not duplicated.

## What you should NOT do

- Don't ask "should I refresh?" \u2014 the user invoked /beacon-refresh, that's the answer.
- Don't preserve stale components for sentimental reasons. If the underlying files are gone or merged into another component, drop it from the new \`components\` list.
- Don't pad with file-level granularity. Refresh maintains the same ~15-component altitude as init.
- Don't fabricate changes. If the codebase hasn't materially moved since the last init, say so and persist the current state anyway (re-runs are cheap; it's fine).

If \`beacon_entities\` or \`beacon_init_persist\` isn't available, the Beacon panel isn't running in this repo. Tell the user to run \`beacon\` here first, then re-invoke /beacon-refresh.

After the tool returns, report the final counts plus a one-line summary of the diff you surfaced.
`,b=`---
name: beacon-plan
description: Present your current plan or approach to the user on Beacon's /plan canvas for review \u2014 instead of asking for approval in prose. Use when the user says "present the plan", "show me the plan", "let me see it / the plan", or whenever you are about to end a turn asking whether to proceed with a plan, design, or approach.
---

# Present a plan on Beacon (/beacon-plan)

Beacon reviews plans on a canvas at /plan \u2014 never as a wall of text in the terminal. So do NOT
end a turn with "here's my plan\u2026 should I proceed?" in prose. Present it through Beacon and let the
tool BLOCK until the user decides.

## How to present

Call the **\`beacon_present_plan\`** MCP tool with your plan as markdown:

- \`description\`: a one-line summary shown in the review header.
- \`markdown\`: the full plan as markdown (headings, lists, code).
- If the plan proposes DB tables / relations / endpoints or roadmap features, embed ONE fenced
  \`\`\`beacon JSON block in the markdown \u2014 the same shapes \`beacon_propose_plan\` accepts:

\`\`\`beacon
{ "tables": [...], "relations": [...], "endpoints": [...], "features": [...] }
\`\`\`

Beacon extracts that block deterministically, strips it from the prose, and renders an editable
board on /plan. The board is built ONLY from the block \u2014 prose is never parsed \u2014 so mirror EVERY
table/endpoint/feature you mention in the prose into the block, or that board will be empty.

\`beacon_present_plan\` opens /plan and BLOCKS until the user clicks Approve / Discard / submits
feedback, then returns their verdict. Implement code or migrations ONLY after it returns approval.
If it returns feedback, revise and call it again.

## Which tool

- **Pure schema/feature plan** (tables + endpoints + roadmap features, little prose) \u2192 you may use
  \`beacon_propose_plan\` with the structured fields instead; it's the same review loop.
- **Anything else** (a code-change plan, a mixed plan, a "how should I approach X") \u2192 use
  \`beacon_present_plan\` with markdown so the full reasoning shows on /plan.

If \`beacon_present_plan\` isn't available, the panel isn't wired here \u2014 fall back to ExitPlanMode
with the same \`\`\`beacon block (Claude Code only; Codex has no ExitPlanMode), or tell the user to
run \`beacon\` in this repo once.
`,K,U="<!-- beacon:workflow:start -->",M="<!-- beacon:workflow:end -->",T;var R=I(()=>{K=[{name:"beacon-init",body:()=>v},{name:"beacon-refresh",body:()=>k}];T=`${U}
## Beacon \u2014 feature workflow

This project uses Beacon (a local planning/visualization panel; run \`beacon\` to open it). When you start work on a FEATURE \u2014 whether referenced via an \`@beacon:feature://\u2026\` mention, an \`@beacon:note://\u2026\` note the user wrote in the Notes panel (treat its checkbox \`- [ ]\` todos as subtasks and order features by their dependencies), or just described in chat \u2014 follow these steps in order:

### 1. Load context FIRST \u2014 do NOT Glob/Grep the codebase blind

Call \`beacon_context_for_feature({ id | title | query })\` BEFORE reading files. It returns, in one round-trip:
- the files the feature is attached to,
- what those files import + what imports them (live code-graph blast radius),
- endpoints in the feature's domain + the tables each touches + those tables' FK relations,
- sibling architecture components and the project's conventions.

That bundle replaces the discovery phase. Read only the files it returns plus whatever those imports lead you to. If the feature has no files attached yet, the bundle still gives you the domain map \u2014 Glob is a last resort.

Mid-feature, when deciding whether a change is safe, call \`beacon_blast_radius({ path })\` for the file you're about to edit \u2014 same code-graph data, file-centric.

### 2. Design the data BEFORE writing code

Determine the database tables the feature needs. If any don't exist yet, design the schema and call \`beacon_propose_plan\` (tables + relations + endpoints). This renders an **editable draft on the /plan page** for the user to review. The tool BLOCKS until the user clicks Approve / Discard / submits feedback. Implement migrations + code ONLY after it returns approval.

When listing endpoints, give each \`uses: [{ table, access }]\` so the endpoint\u2192table links draw on /db.

EVERY feature MUST carry \`category\` (e.g. AUTH | SEARCH | DATA | INTEL | BILLING | \u2026; \`cluster\` is accepted as an alias) and \`priority\` (0 = P0 critical, 1 = P1 high, 2 = P2 medium, 3 = P3 low). Beacon REJECTS a plan whose features omit either \u2014 \`beacon_propose_plan\` returns the list of what's missing, and an ExitPlanMode \`\`\`beacon block is denied \u2014 so set both on every feature instead of relying on defaults.

REUSE before you create. Call \`beacon_map\` to see the features + categories that already exist. Beacon HARD-BLOCKS a feature that duplicates an existing one (it returns the existing feature to use instead) and one created without a category \u2014 so don't re-create work that's already on the board, and reuse an existing category rather than a near-synonym. \`category\` is the ONLY domain field. \`front\` (in \`beacon_start_feature\`) nests a feature UNDER an existing parent feature \u2014 it is NOT a domain tag; a \`front\` that matches no real feature is rejected.

When listing features, give each \`dependsOn: ["Other feature title", \u2026]\` for any feature that must ship after another in the same plan. Beacon draws these as "depends on" links so the roadmap shows the dependency chain instead of loose, disconnected cards.

A roadmap item that is a BUG to fix (not a feature to build) should carry \`kind: "BUG"\` \u2014 it renders as a typed bug card. This works everywhere roadmap cards are created: \`beacon_propose_plan\` features, the \`\`\`beacon block, \`beacon_start_feature\` (when the user says they're starting on a bug), \`beacon_add_subtasks\` items (a bug discovered mid-work), and \`beacon_init_persist\` roadmap items. Default is FEATURE.

### 2b. Presenting a plan in plan mode (ExitPlanMode)

In Codex (which has no ExitPlanMode), always present plans via \`beacon_present_plan\` / \`beacon_propose_plan\` instead \u2014 this section applies to Claude Code's plan mode only.

When you present a plan via ExitPlanMode (not \`beacon_propose_plan\`) and it proposes DB tables/relations/endpoints or roadmap features, embed ONE fenced \`\`\`beacon code block of JSON in the plan \u2014 the same shapes \`beacon_propose_plan\` accepts:

\`\`\`beacon
{ "tables": [...], "relations": [...], "endpoints": [...], "features": [...] }
\`\`\`

Beacon extracts it deterministically and **strips the block from the prose** (it's never shown in the annotation panel), then renders the tables + features as an **editable board** on /plan so the user can edit them and have those edits flow back as feedback. Omit the block for pure code-change plans.

**The board is built ONLY from the block \u2014 prose is NOT parsed.** If your plan describes ANY database models/tables/columns in the prose (e.g. "Model \`legal_precedent.py\` \u2014 natural key (court, \u2026)"), you MUST also put them in the block's \`tables\` array (with \`columns\`), or the /db tab will be empty for that plan. Same for endpoints (\`endpoints\` with \`uses:[{table,access}]\`) and features (\`features\`). A plan that lists five tables in prose but ships a block with only \`features\` renders an empty database board \u2014 exactly the "I described models but the DB tab is empty" failure. Mirror every DB entity you mention into the block.

### 3. At the end, register the work \u2014 in ONE call

Call \`beacon_describe_feature\` **ONCE** with a \`features\` array \u2014 one entry per feature the plan created \u2014 each with the files you touched and a short markdown description. This flips each one to **Done** \u2014 including its sub-tasks (the cascade completes every PENDING/IN_PROGRESS child; a sub-task you did NOT finish must be set BLOCKED or CANCELLED before registering, so it survives visibly) \u2014 and keeps \`beacon_context_for_feature\` accurate for the next session.

Key each entry by its node \`id\`: the ids are handed back to you when the plan is approved (in the approval message / additionalContext), so you don't fuzzy-match titles or pay a disambiguation round-trip. If you don't have an id, \`title\` still works.

Register them all in that single batched call. If a plan added five features, that's ONE \`beacon_describe_feature\` call with five entries \u2014 NOT five calls, and NOT just an umbrella ("Harden auth"), which leaves the individual features stuck on **Pending**.

If the feature added or materially changed a REAL architectural component (a subsystem \u2014 NOT a file), also pass \`architecture: [{ title, domain, role, \u2026 }]\` so the Architecture map stays accurate. It upserts curated components by title; never list files as components. If you found a bug or something worth investigating in a component's code, add \`bugs: [{ note }]\` to its architecture entry \u2014 it renders as a bug flag on the node (attributed to the agent); identical open flags are not duplicated. Only flag what you actually saw in the code.

Pull raw planning data anytime with \`beacon_entities\` (features / architecture / tables / endpoints).
${M}`});R();export{h as removeRepoAssets,W as installRefreshSkill,O as installPlanSkill,f as installInitSkill,j as installCodexRepoSkills,_ as ensureWorkflowDoc,g as ensureMcp,L as auditRepo,k as REFRESH_SKILL,b as PLAN_SKILL,v as INIT_SKILL};
