@esneiderbravo/speclaw 0.3.4 → 0.3.7

package/dist/modules/lawbook/assets/skills/build/steps/06-discipline-reports.md

@@ -0,0 +1,44 @@
+# Write the discipline reports (mandatory)
+
+Record the evidence of testing under `lawbook/changes/<name>/reports/`, one file
+per discipline the change touched, named for that discipline. The set is **open,
+not a fixed list** — `backend.md`, `frontend.md`, and `api.md` are the common
+ones, but write `database.md`, `infra.md`, `security.md`, `performance.md`,
+`e2e.md`, etc. when the change exercises those concerns, and coin a clear
+`<discipline>.md` for anything none of them fit. Omit disciplines the change did
+not touch; the archive is blocked until at least one discipline report exists.
+
+**`api.md` is mandatory whenever the change touches an API surface** — a new or
+modified endpoint, its request/response contract, its status codes, or its
+auth/permission or ordering guarantees. A `backend.md` unit report does not
+substitute for it: the contract is a distinct concern. In `api.md` document the
+method and path, the auth/permissions, the response shape and every status code
+the change governs (e.g. `200`/`401`/`403`/`404`), any ordering guarantee, and
+how the contract was exercised (test client and/or `curl`) — kept isolated from
+any live data store per the manual-verification step.
+
+Each report MUST follow this structure, in order — the fixed shape is what makes
+the evidence trustworthy and reproducible, rather than left to improvisation:
+
+1. **Title + header** — `# <Discipline> checks — <change> (<date>)`, then a line
+   `Date · Branch · Environment/cwd` naming where the commands ran.
+2. **Gates & results** — a `| Check | Command | Result |` table: each gate, the
+   exact command, and its real result with pass/fail counts (e.g. "62 files, 434
+   passed") and ✅/⚠️/❌. Quote real output — never paraphrase a green you did
+   not see.
+3. **Tests added / updated** — each new or changed test and what it asserts; note
+   TDD evidence ("failed before the fix, passes after") where it applies.
+4. **Spec-scenario coverage** — a table mapping each `#### Scenario` in this
+   change's delta specs to how it was verified (a test id, a gate, or a manual
+   step). Every scenario must appear.
+5. **Pre-existing / unrelated failures** — any failing check not caused by this
+   change, with proof it is pre-existing (e.g. it reproduces with the change
+   stashed) — or state "none".
+6. **Pending manual steps** — anything not automated, stated plainly — or "none".
+7. **Verdict** — one line.
+
+If a test kind does not yet apply (e.g. no unit runner), the report says so in
+place of that evidence and records the gates and manual verification that stood
+in.
+
+Next: read `steps/07-hand-off.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/build/steps/07-hand-off.md

@@ -0,0 +1,9 @@
+# Hand off
+
+When every task is checked and gates are green, tell the user the change is
+ready to `sync` and `archive`. Keep the delta specs current as you build, but
+know that `sync` formally reconciles the delta specs against what was actually
+built — so behavior that drifted past the original spec is caught there, not
+left to chance.
+
+No further steps remain — build workflow complete.

package/dist/modules/lawbook/assets/skills/draft/SKILL.md

@@ -9,84 +9,7 @@ Turn a request into a complete, reviewable change under `lawbook/changes/<name>/
 before any implementation. This is speclaw's own spec-driven workflow — no
 external CLI; the mechanical steps are speclaw MCP tools.
 
-## Step 0 — Ensure the workspace exists
+Use when the user wants to start, plan, or propose a new feature, fix, or
+refactor.
 
-If `lawbook/` is missing, run the `lawbook_init` tool once to create it.
-
-## Step 1 — Understand the request and the code
-
-- **Refresh the index first.** Run `compass_index` before reasoning about the
-  code — it is incremental (unchanged files are skipped by hash), so this is
-  cheap and guarantees your decisions rest on the current graph, not a stale one.
-- Clarify what the user wants (feature / fix / refactor) and confirm scope.
-- Use `compass_explore` and `compass_recall` (speclaw's code index) BEFORE
-  grep/read to locate the real code the change touches and its blast radius.
-- Read the governing standards in `docs/standards/` (architecture, backend,
-  frontend, testing) so the change complies with the project's law.
-
-## Step 2 — Pick a change name and its capabilities
-
-- **Change name:** kebab-case, action-oriented (e.g. `add-login`,
-  `fix-shift-overlap`). This is the folder under `lawbook/changes/`, and it is
-  per-feature — always distinct.
-- **Capabilities:** run `lawbook_list` to see the canonical capabilities. A
-  capability is the living contract for an area of behavior — it is *not* the
-  change. When your change modifies behavior an existing capability already
-  governs, reuse that capability's **exact** name so `sync` updates its spec.
-  Introduce a new capability only as a deliberate choice for a genuinely distinct
-  area of behavior — never as a near-duplicate (`transfer` next to an existing
-  `transfers`) of one that already exists.
-
-## Step 3 — Write the artifacts
-
-Create under `lawbook/changes/<name>/`:
-
-- **proposal.md** — the why, the what, non-goals, and whether migrations are
-  needed. Reference the team's tracker ticket if there is one.
-- **specs/<capability>/spec.md** — the delta spec for each affected capability.
-  `sync` promotes this by overwriting the whole canonical file, so the delta must
-  carry the capability's **full** intended spec. When you are updating an existing
-  capability, **start from the current `lawbook/specs/<capability>/spec.md`** and
-  edit on top of it, so its existing requirements are carried forward — do not
-  author it from scratch, or promotion will silently drop them. Use normative
-  language and testable scenarios:
-  ```markdown
-  # <Capability>
-
-  ### Requirement: <name>
-  The system SHALL <requirement>.
-
-  #### Scenario: <name>
-  - Given <context>
-  - When <action>
-  - Then <observable outcome>
-  ```
-- **design.md** — always: approach, alternatives weighed, and the trade-offs
-  behind the decision. For a small change, keep it short — but write it.
-- **tasks.md** — ordered, checkable steps. MUST include the mandatory steps
-  from `lawbook/config.yaml` (feature branch first; tests reviewed and run;
-  manual verification executed by the agent; discipline reports produced; docs
-  updated; archive within the PR).
-- **reports/** — create the folder with a short `reports/README.md` naming the
-  discipline reports the change will need — one per discipline it touches, from an
-  open set (`backend.md`, `frontend.md`, `api.md`, `database.md`, `infra.md`,
-  `security.md`, … — and `api.md` is required when the change touches any API
-  surface) that `build` will fill, following the required report structure
-  (header · gates table ·
-  tests added · spec-scenario coverage · pre-existing failures · pending manual ·
-  verdict — see the `build` skill, Step 5). Every change ships this folder;
-  archive is blocked until it holds at least one discipline report.
-
-## Step 4 — Validate
-
-Run the `lawbook_validate` tool for the change and fix every issue it reports
-(missing artifacts, non-normative specs, missing scenarios) before handing off
-to implementation. Read its advisory **warnings** too: a near-duplicate
-capability name usually means you should reuse the existing capability's exact
-name, and a dropped-requirement warning means the delta should start from the
-canonical. Warnings do not block, but resolve them unless the divergence is
-intentional.
-
-## Step 5 — Hand off
-
-Summarize the change and tell the user it's ready to `build`.
+Read `steps/01-ensure-workspace.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/draft/steps/01-ensure-workspace.md

@@ -0,0 +1,5 @@
+# Ensure the workspace exists
+
+If `lawbook/` is missing, run the `lawbook_init` tool once to create it.
+
+Next: read `steps/02-understand.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/draft/steps/02-understand.md

@@ -0,0 +1,12 @@
+# Understand the request and the code
+
+- **Refresh the index first.** Run `compass_index` before reasoning about the
+  code — it is incremental (unchanged files are skipped by hash), so this is
+  cheap and guarantees your decisions rest on the current graph, not a stale one.
+- Clarify what the user wants (feature / fix / refactor) and confirm scope.
+- Use `compass_explore` and `compass_recall` (speclaw's code index) BEFORE
+  grep/read to locate the real code the change touches and its blast radius.
+- Read the governing standards in `docs/standards/` (architecture, backend,
+  frontend, testing) so the change complies with the project's law.
+
+Next: read `steps/03-name-capabilities.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/draft/steps/03-name-capabilities.md

@@ -0,0 +1,14 @@
+# Pick a change name and its capabilities
+
+- **Change name:** kebab-case, action-oriented (e.g. `add-login`,
+  `fix-shift-overlap`). This is the folder under `lawbook/changes/`, and it is
+  per-feature — always distinct.
+- **Capabilities:** run `lawbook_list` to see the canonical capabilities. A
+  capability is the living contract for an area of behavior — it is *not* the
+  change. When your change modifies behavior an existing capability already
+  governs, reuse that capability's **exact** name so `sync` updates its spec.
+  Introduce a new capability only as a deliberate choice for a genuinely distinct
+  area of behavior — never as a near-duplicate (`transfer` next to an existing
+  `transfers`) of one that already exists.
+
+Next: read `steps/04-write-artifacts.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/draft/steps/04-write-artifacts.md

@@ -0,0 +1,41 @@
+# Write the artifacts
+
+Create under `lawbook/changes/<name>/`:
+
+- **proposal.md** — the why, the what, non-goals, and whether migrations are
+  needed. Reference the team's tracker ticket if there is one.
+- **specs/<capability>/spec.md** — the delta spec for each affected capability.
+  `sync` promotes this by overwriting the whole canonical file, so the delta must
+  carry the capability's **full** intended spec. When you are updating an existing
+  capability, **start from the current `lawbook/specs/<capability>/spec.md`** and
+  edit on top of it, so its existing requirements are carried forward — do not
+  author it from scratch, or promotion will silently drop them. Use normative
+  language and testable scenarios:
+  ```markdown
+  # <Capability>
+
+  ### Requirement: <name>
+  The system SHALL <requirement>.
+
+  #### Scenario: <name>
+  - Given <context>
+  - When <action>
+  - Then <observable outcome>
+  ```
+- **design.md** — always: approach, alternatives weighed, and the trade-offs
+  behind the decision. For a small change, keep it short — but write it.
+- **tasks.md** — ordered, checkable steps. MUST include the mandatory steps
+  from `lawbook/config.yaml` (feature branch first; tests reviewed and run;
+  manual verification executed by the agent; discipline reports produced; docs
+  updated; archive within the PR).
+- **reports/** — create the folder with a short `reports/README.md` naming the
+  discipline reports the change will need — one per discipline it touches, from an
+  open set (`backend.md`, `frontend.md`, `api.md`, `database.md`, `infra.md`,
+  `security.md`, … — and `api.md` is required when the change touches any API
+  surface) that `build` will fill, following the required report structure
+  (header · gates table · tests added · spec-scenario coverage · pre-existing
+  failures · pending manual · verdict — see the `build` skill's discipline-reports
+  step). Every change ships this folder; archive is blocked until it holds at
+  least one discipline report.
+
+Next: read `steps/05-validate.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/draft/steps/05-validate.md

@@ -0,0 +1,11 @@
+# Validate
+
+Run the `lawbook_validate` tool for the change and fix every issue it reports
+(missing artifacts, non-normative specs, missing scenarios) before handing off
+to implementation. Read its advisory **warnings** too: a near-duplicate
+capability name usually means you should reuse the existing capability's exact
+name, and a dropped-requirement warning means the delta should start from the
+canonical. Warnings do not block, but resolve them unless the divergence is
+intentional.
+
+Next: read `steps/06-hand-off.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/draft/steps/06-hand-off.md

@@ -0,0 +1,5 @@
+# Hand off
+
+Summarize the change and tell the user it's ready to `build`.
+
+No further steps remain — draft workflow complete.

package/dist/modules/lawbook/assets/skills/explore/SKILL.md

@@ -5,27 +5,11 @@ description: Enter explore mode — a thinking partner for investigating an idea
 
 # explore — Think it through
 
-A low-commitment mode for investigating ideas and the codebase before (or
-during) a change. Nothing is written to `lawbook/` here — the output is shared
-understanding and a recommended direction.
+A low-commitment thinking partner for investigating ideas and the codebase
+before (or during) a change. Nothing is written to `lawbook/` — the output is
+shared understanding and a recommended direction.
 
-## How to explore
+Use when the user wants to think something through, understand how something
+works, or clarify requirements before drafting a change.
 
-- **Refresh the index first.** Run `compass_index` before investigating — it is
-  incremental (unchanged files skipped by hash), so it is cheap and keeps your
-  reasoning on the current graph rather than a stale one.
-- **Understand the code first.** Use `compass_recall` to find relevant code by
-  meaning and `compass_explore` to read a symbol's source plus its callers and
-  callees — before grep/read.
-- **Ask sharp questions** to surface hidden assumptions, constraints, and edge
-  cases. Confirm scope and non-goals.
-- **Check the law.** Read the relevant `docs/standards/` so any direction you
-  propose already fits the project's architecture and conventions.
-- **Weigh approaches.** Lay out the viable options with trade-offs and give a
-  recommendation, not an exhaustive survey.
-
-## Output
-
-A concise summary: the problem as understood, the constraints, the recommended
-approach, and the open questions. When the direction is clear, offer to `draft`
-the change.
+Read `steps/01-investigate.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/explore/steps/01-investigate.md

@@ -0,0 +1,16 @@
+# Investigate
+
+- **Refresh the index first.** Run `compass_index` before investigating — it is
+  incremental (unchanged files skipped by hash), so it is cheap and keeps your
+  reasoning on the current graph rather than a stale one.
+- **Understand the code first.** Use `compass_recall` to find relevant code by
+  meaning and `compass_explore` to read a symbol's source plus its callers and
+  callees — before grep/read.
+- **Ask sharp questions** to surface hidden assumptions, constraints, and edge
+  cases. Confirm scope and non-goals.
+- **Check the law.** Read the relevant `docs/standards/` so any direction you
+  propose already fits the project's architecture and conventions.
+- **Weigh approaches.** Lay out the viable options with trade-offs and give a
+  recommendation, not an exhaustive survey.
+
+Next: read `steps/02-summarize.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/explore/steps/02-summarize.md

@@ -0,0 +1,7 @@
+# Summarize
+
+Produce a concise summary: the problem as understood, the constraints, the
+recommended approach, and the open questions. When the direction is clear,
+offer to `draft` the change.
+
+No further steps remain — explore workflow complete.

package/dist/modules/lawbook/assets/skills/sync/SKILL.md

@@ -13,33 +13,4 @@ become the source of truth but the change isn't finished (e.g. multi-PR work).
 promoting, YOU reconcile the delta specs against what was actually built, so the
 specs that become canonical describe reality, not just the original draft.
 
-## Steps
-
-1. Confirm which change to sync (run `lawbook_list` if unsure).
-
-2. **Reconcile code → delta specs (agent-executed).** Before promoting, compare
-   what was built against the change's delta specs:
-   - Reconstruct what shipped: `git diff <branch-point>...HEAD` for the change's
-     branch, then `compass_explore` / `compass_impact` on the touched symbols to
-     understand behavior, not just changed lines.
-   - Diff intent vs reality: list behavior that is implemented but missing from,
-     or contradicted by, `lawbook/changes/<name>/specs/**`.
-   - Write the gaps into the delta specs — normative `SHALL`/`MUST` requirements
-     under `### Requirement:` and `#### Scenario:` acceptance criteria — so the
-     contract matches what was built. Capture only behavior that actually
-     exists; never invent scope that was not implemented.
-   - If nothing drifted, make no edits and say so.
-
-3. Run `lawbook_validate` for the change; do not sync a change whose specs are
-   invalid.
-
-4. Run the `lawbook_sync` tool for the change. It copies each
-   `lawbook/changes/<name>/specs/<capability>/spec.md` over the canonical
-   `lawbook/specs/<capability>/spec.md` and reports what it promoted, flagging
-   each as **created** (new capability) or **updated** (overwrote an existing
-   one). A capability you expected to update showing up as *created* means the
-   delta forked a near-duplicate — fix the name before promoting.
-
-5. Report to the user what you reconciled (or that nothing drifted) and the
-   promoted files (created vs updated). The change stays active — `archive` it
-   when it's fully done.
+Read `steps/01-confirm.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/sync/steps/01-confirm.md

@@ -0,0 +1,5 @@
+# Confirm which change to sync
+
+Confirm which change to sync (run `lawbook_list` if unsure).
+
+Next: read `steps/02-reconcile.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/sync/steps/02-reconcile.md

@@ -0,0 +1,16 @@
+# Reconcile code → delta specs (agent-executed)
+
+Before promoting, compare what was built against the change's delta specs:
+
+- Reconstruct what shipped: `git diff <branch-point>...HEAD` for the change's
+  branch, then `compass_explore` / `compass_impact` on the touched symbols to
+  understand behavior, not just changed lines.
+- Diff intent vs reality: list behavior that is implemented but missing from,
+  or contradicted by, `lawbook/changes/<name>/specs/**`.
+- Write the gaps into the delta specs — normative `SHALL`/`MUST` requirements
+  under `### Requirement:` and `#### Scenario:` acceptance criteria — so the
+  contract matches what was built. Capture only behavior that actually
+  exists; never invent scope that was not implemented.
+- If nothing drifted, make no edits and say so.
+
+Next: read `steps/03-validate.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/sync/steps/03-validate.md

@@ -0,0 +1,6 @@
+# Validate
+
+Run `lawbook_validate` for the change; do not sync a change whose specs are
+invalid.
+
+Next: read `steps/04-promote.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/sync/steps/04-promote.md

@@ -0,0 +1,10 @@
+# Promote
+
+Run the `lawbook_sync` tool for the change. It copies each
+`lawbook/changes/<name>/specs/<capability>/spec.md` over the canonical
+`lawbook/specs/<capability>/spec.md` and reports what it promoted, flagging
+each as **created** (new capability) or **updated** (overwrote an existing
+one). A capability you expected to update showing up as *created* means the
+delta forked a near-duplicate — fix the name before promoting.
+
+Next: read `steps/05-report.md` and do only what it says.

package/dist/modules/lawbook/assets/skills/sync/steps/05-report.md

@@ -0,0 +1,7 @@
+# Report
+
+Report to the user what you reconciled (or that nothing drifted) and the
+promoted files (created vs updated). The change stays active — `archive` it
+when it's fully done.
+
+No further steps remain — sync workflow complete.

package/dist/modules/lawbook/register.js

@@ -1,6 +1,7 @@
 import path from "node:path";
 import { z } from "zod";
-import { text } from "../../shared/mcp.js";
+import { defineTool, text } from "../../shared/mcp.js";
+import { shouldExpose } from "../../shared/exposure.js";
 import { assetsDir } from "../../shared/paths.js";
 import { copyRendered } from "../../shared/install.js";
 import { specInit, specValidate, specSync, specArchive, specList } from "./engine.js";
@@ -16,41 +17,21 @@ export function installWorkflow(projectPath, vars, report, opts) {
     copyRendered(path.join(ASSETS, "commands"), path.join(aiSpecs, "commands", "lawbook"), vars, report, opts);
     copyRendered(path.join(ASSETS, "rules"), path.join(aiSpecs, "rules"), vars, report, opts);
 }
-// ─── The spec module: speclaw's own spec-driven workflow (no external OpenSpec) ───
-// Mechanical operations behind the draft/build/sync/archive/explore commands.
 /** Register the spec workflow MCP tools (init, list, validate, sync, archive). */
-export function registerSpec(server) {
-    server.registerTool("lawbook_init", {
-        description: "Initialize speclaw's spec-driven workflow in a project: creates lawbook/ (specs/, changes/, changes/archive/, config.yaml, README). Idempotent — never overwrites existing files.",
-        inputSchema: { projectPath: z.string().describe("Absolute path to the project") },
-    }, async ({ projectPath }) => text(specInit(projectPath)));
-    server.registerTool("lawbook_list", {
-        description: "List the spec workspace: active changes, archived changes, and canonical capabilities under spec/.",
-        inputSchema: { projectPath: z.string().describe("Absolute path to the project") },
-    }, async ({ projectPath }) => text(specList(projectPath)));
-    server.registerTool("lawbook_validate", {
-        description: "Validate a change's artifacts: proposal.md and tasks.md present, and delta specs use normative language (SHALL/MUST), '### Requirement:' headers, and '#### Scenario:' acceptance criteria. Returns the blocking issues to fix plus advisory (non-blocking) warnings — a capability name that resembles an existing canonical one, or requirements dropped versus the canonical. Used by the draft/build commands before proceeding.",
-        inputSchema: {
-            projectPath: z.string().describe("Absolute path to the project"),
-            change: z.string().describe("Change name (folder under lawbook/changes/)"),
-        },
-    }, async ({ projectPath, change }) => text(specValidate(projectPath, change)));
-    server.registerTool("lawbook_sync", {
-        description: "Promote a change's delta specs into the canonical lawbook/specs/ (per capability), without archiving. Reports each promoted spec as created (new capability) or updated (overwrote an existing one). Backs the `sync` command.",
-        inputSchema: {
-            projectPath: z.string().describe("Absolute path to the project"),
-            change: z.string().describe("Change name (folder under lawbook/changes/)"),
-        },
-    }, async ({ projectPath, change }) => text(specSync(projectPath, change)));
-    server.registerTool("lawbook_archive", {
-        description: "Finalize a change: sync its delta specs into lawbook/specs/, then move it to lawbook/changes/archive/<date>-<name>/. Backs the `archive` command. Pass today's date as YYYY-MM-DD.",
-        inputSchema: {
-            projectPath: z.string().describe("Absolute path to the project"),
-            change: z.string().describe("Change name (folder under lawbook/changes/)"),
-            date: z
-                .string()
-                .regex(/^\d{4}-\d{2}-\d{2}$/)
-                .describe("Today's date, YYYY-MM-DD"),
-        },
+export function registerSpec(server, opts = {}) {
+    const minimal = Boolean(opts.minimal);
+    const add = (name, description, inputSchema, handler) => {
+        if (!shouldExpose(name, minimal))
+            return;
+        defineTool(server, { name, description, inputSchema, handler });
+    };
+    add("lawbook_init", "Create the lawbook/ workspace (specs, changes, archive, config). Idempotent.", { projectPath: z.string() }, async ({ projectPath }) => text(specInit(projectPath)));
+    add("lawbook_list", "List active changes, archives, and canonical capabilities under lawbook/.", { projectPath: z.string() }, async ({ projectPath }) => text(specList(projectPath)));
+    add("lawbook_validate", "Validate a change's proposal, tasks, and delta specs before build or sync.", { projectPath: z.string(), change: z.string() }, async ({ projectPath, change }) => text(specValidate(projectPath, change)));
+    add("lawbook_sync", "Promote a change's delta specs into canonical lawbook/specs/ without archiving.", { projectPath: z.string(), change: z.string() }, async ({ projectPath, change }) => text(specSync(projectPath, change)));
+    add("lawbook_archive", "Sync a change into canonical specs, then move it under changes/archive/.", {
+        projectPath: z.string(),
+        change: z.string(),
+        date: z.string().regex(/^\d{4}-\d{2}-\d{2}$/),
     }, async ({ projectPath, change, date }) => text(specArchive(projectPath, change, date)));
 }

package/dist/modules/tools/register.js

@@ -1,27 +1,27 @@
 import { z } from "zod";
-import { text } from "../../shared/mcp.js";
+import { defineTool, text } from "../../shared/mcp.js";
+import { shouldExpose } from "../../shared/exposure.js";
 import { emptyReport } from "../../shared/install.js";
 import { refreshAgents } from "../../shared/agents.js";
 import { loadPacks, installPack } from "./packs.js";
 export { loadPacks, installPack };
-// ─── The tools module: opt-in packs of skills, agents, and commands ───
 /** Register the tools-module MCP tools (list_packs, add_pack). */
-export function registerTools(server) {
-    server.registerTool("list_packs", {
-        description: "List the available speclaw skill packs and what each contains.",
-        inputSchema: {},
-    }, async () => text(loadPacks()));
-    server.registerTool("add_pack", {
-        description: "Add a single pack to an already-initialized project, then refresh IDE symlinks. Pass template vars (organization, ...) if the pack needs them.",
-        inputSchema: {
-            projectPath: z.string().describe("Absolute path to the project"),
-            pack: z.string().describe("Pack name (see list_packs)"),
-            vars: z.record(z.string()).optional().describe("Template variables for rendering"),
-        },
+export function registerTools(server, opts = {}) {
+    const minimal = Boolean(opts.minimal);
+    const add = (name, description, inputSchema, handler) => {
+        if (!shouldExpose(name, minimal))
+            return;
+        defineTool(server, { name, description, inputSchema, handler });
+    };
+    add("list_packs", "List available speclaw skill packs and what each contains.", {}, async () => text(loadPacks()));
+    add("add_pack", "Install one pack into an initialized project and refresh IDE symlinks.", {
+        projectPath: z.string(),
+        pack: z.string(),
+        vars: z.record(z.string()).optional(),
     }, async ({ projectPath, pack, vars }) => {
         const report = emptyReport();
         installPack(projectPath, pack, vars ?? {}, report);
-        refreshAgents(projectPath, report); // link the new content into already-configured agents
+        refreshAgents(projectPath, report);
         return text(report);
     });
 }

package/dist/server.js

@@ -4,14 +4,20 @@ import { registerCompass } from "./modules/compass/register.js";
 import { registerSpec } from "./modules/lawbook/register.js";
 import { registerFoundation } from "./modules/foundation/register.js";
 import { registerTools } from "./modules/tools/register.js";
-/** Build the speclaw MCP server with every module's tools registered. */
-export function buildServer() {
+import { isMinimalMode } from "./shared/exposure.js";
+/**
+ * Build the speclaw MCP server with every module's tools registered.
+ *
+ * @param opts - Optional exposure overrides; defaults to {@link isMinimalMode}.
+ */
+export function buildServer(opts = {}) {
+    const minimal = opts.minimal ?? isMinimalMode();
     const server = new McpServer({ name: "speclaw", version: "0.1.0" });
-    // Each module contributes its own MCP tools. Adding a module = one line here.
-    registerFoundation(server); // init_project, scaffold, configure_agent, doctor
-    registerSpec(server); // lawbook_init, lawbook_validate, lawbook_sync, lawbook_archive, lawbook_list
-    registerCompass(server); // compass_index, explore, search, recall, impact, trace, watch
-    registerTools(server); // list_packs, add_pack
+    const reg = { minimal };
+    registerFoundation(server, reg);
+    registerSpec(server, reg);
+    registerCompass(server, reg);
+    registerTools(server, reg);
     return server;
 }
 /** Start the MCP server over stdio (used by `speclaw mcp`). */