@esneiderbravo/speclaw 0.1.1 → 0.1.3

package/dist/modules/foundation/assets/docs/standards/conventions.template.md

@@ -6,23 +6,26 @@ Naming, branching, PR, and tracking conventions. A law of the project — see
 ## Branches
 
 - Pattern: `{{branch_pattern}}`
-- Branches without a tracker ticket reference must not be merged (except
-  explicitly scoped chores).
+- Follow the branch/ticket convention this repo already uses (inferred from its
+  existing branch names and history) — don't invent a new one.
 
 ## Pull requests
 
 - Title and body in the repo's artifact language, following the PR template.
-- The body references the tracker ticket ({{ticket_prefix}}-N) so it links.
-- The ticket lives in the PR title/body only — never in the code.
+- If the team uses a tracker, the body references its ticket so it links; the
+  ticket lives in the PR title/body only — never in the code.
 - CI must be green before requesting review.
 
 ## Tracker
 
-- Ticket prefix: `{{ticket_prefix}}`
-- New behavior, endpoints, schema changes, or UI flows get a ticket and a
-  spec change; one-line fixes need not.
-- Ticket ↔ PR traceability is mandatory: closing a ticket attaches its PR
-  (see the `close-ticket` skill).
+speclaw does not prescribe a ticket tool — each team configures its own. Follow
+whatever convention this repo already uses (inferred from its branches, PRs, and
+history); if there is none, leave tracker linkage to the team.
+
+- New behavior, endpoints, schema changes, or UI flows get a spec change;
+  one-line fixes need not.
+- Where a tracker is in use, ticket ↔ PR traceability is expected: closing a
+  ticket attaches its PR.
 
 ## Versioning & releases
 

package/dist/modules/foundation/assets/docs/standards/{spec-workflow.template.md → lawbook.template.md}

@@ -1,4 +1,4 @@
-# Spec Workflow — {{project_name}}
+# Lawbook — {{project_name}}
 
 The process law of the project — see [`../../LAWS.md`](../../LAWS.md). This
 repo is spec-driven through speclaw's **spec** module (no external CLI; the
@@ -9,18 +9,18 @@ mechanical steps are speclaw MCP tools).
 No non-trivial change lands without a spec change:
 
 1. **explore** — think an idea through before committing (writes nothing).
-2. **draft** — create `spec/changes/<name>/`: `proposal.md`, delta specs under
+2. **draft** — create `lawbook/changes/<name>/`: `proposal.md`, delta specs under
    `specs/<capability>/spec.md`, optional `design.md`, and `tasks.md`.
 3. **build** — implement the tasks in order, keeping code and spec in
    agreement.
 4. **sync** — promote the change's delta specs into the canonical
-   `spec/specs/` (`spec_sync`).
-5. **archive** — finalize: sync + move the change to `spec/changes/archive/`
-   (`spec_archive`), **within the same PR** — never a post-merge chore.
+   `lawbook/specs/` (`lawbook_sync`).
+5. **archive** — finalize: sync + move the change to `lawbook/changes/archive/`
+   (`lawbook_archive`), **within the same PR** — never a post-merge chore.
 
 ## Mandatory task steps
 
-`tasks.md` MUST include the steps defined in `spec/config.yaml` and the
+`tasks.md` MUST include the steps defined in `lawbook/config.yaml` and the
 `spec-tasks-mandatory-steps` rule: feature branch first, tests reviewed and
 run, manual verification executed by the agent, docs updated, archive within
 the PR. The agent performs the manual testing itself — never delegates it.
@@ -32,11 +32,11 @@ the PR. The agent performs the manual testing itself — never delegates it.
 - Scenario headers use exactly `#### Scenario:`.
 - Acceptance criteria are testable without production integrations.
 - The implemented code must match what the delta spec promises. Validate with
-  the `spec_validate` tool before syncing or archiving.
+  the `lawbook_validate` tool before syncing or archiving.
 
 ## Archiving discipline
 
-Always archive with the `archive` command / `spec_archive` tool, never a manual
+Always archive with the `archive` command / `lawbook_archive` tool, never a manual
 `mv` — the tool performs the spec promotion and validation a manual move skips.
 
 ## Amendments to the law

package/dist/modules/foundation/assets/docs/standards/testing-standards.template.md

@@ -30,5 +30,5 @@ suppressing a linter or deleting a test.
 - When a change affects runtime behavior and it's feasible, verify it works by
   exercising the endpoint/UI — don't assume green CI covers everything.
 - The mandatory spec task steps
-  ([`spec-workflow.md`](spec-workflow.md)) define which manual checks
+  ([`lawbook.md`](lawbook.md)) define which manual checks
   the agent must execute itself.

package/dist/modules/foundation/doctor.js

@@ -4,7 +4,7 @@ import { AGENTS, detectConfiguredAgents } from "../../shared/agents.js";
 /**
  * Run the speclaw installation health checks against a project: ai-specs and
  * LAWS.md presence, agent contracts, the docs/standards set, per-agent IDE
- * symlink health, the spec/ workflow, the Compass index, and .mcp.json wiring.
+ * symlink health, the lawbook/ workflow, the Compass index, and .mcp.json wiring.
  *
  * @param projectPath - Absolute path to the project root.
  * @returns One {@link Check} per verified item, each carrying a remediation hint.
@@ -39,7 +39,7 @@ export function doctor(projectPath) {
         "testing-standards",
         "documentation",
         "conventions",
-        "spec-workflow",
+        "lawbook",
     ];
     const missingStandards = standards.filter((s) => !has(path.join("docs/standards", `${s}.md`)));
     checks.push({
@@ -85,11 +85,11 @@ export function doctor(projectPath) {
         }
     }
     checks.push({
-        name: "spec workflow",
-        ok: has("spec"),
-        detail: has("spec")
-            ? "spec/ present"
-            : "missing — run the `spec_init` tool",
+        name: "lawbook workflow",
+        ok: has("lawbook"),
+        detail: has("lawbook")
+            ? "lawbook/ present"
+            : "missing — run the `lawbook_init` tool",
     });
     checks.push({
         name: "Compass index",

package/dist/modules/foundation/register.js

@@ -16,8 +16,6 @@ const profileShape = {
     branch_pattern: z.string().optional().describe("e.g. 'feature/<ticket-id>-<slug>'"),
     commit_style: z.string().optional().describe("e.g. 'conventional commits, imperative, English'"),
     custom_laws: z.string().optional().describe("Extra markdown appended to LAWS.md — project-specific binding rules the analysis surfaced"),
-    ticket_prefix: z.string().optional().describe("Ticket prefix in the team's tracker, e.g. 'FAR'"),
-    team_language: z.string().optional().describe("The team's working language for posted communication (reviews, replies, tickets), e.g. 'Spanish'. Repo artifacts stay in the repo's own language. Defaults to English."),
     compass_hints: z.string().optional().describe("Markdown bullets with the repo's real entrypoints and common traces, inserted into docs/compass.md"),
     base_standards_extra: z.string().optional().describe("Markdown with any project-specific cross-cutting rules, appended to docs/standards/base-standards.md"),
     modules_table: z.string().optional().describe("Markdown table of the repo's real modules/bounded contexts + one-line responsibility, for docs/standards/architecture.md"),
@@ -38,19 +36,19 @@ export function registerFoundation(server) {
         return text({
             instructions: [
                 "1. Analyze the repository at projectPath and fill in every profile field below with REAL values from the codebase (read package.json / pyproject.toml / CI configs / README — do not invent).",
-                "2. The foundation is a set of GRANULAR standards under docs/standards/ (base, architecture, backend, frontend, testing, conventions, spec-workflow), bound by LAWS.md and referenced from CLAUDE.md/AGENTS.md. Fill their structured fields from the real repo: modules_table and layering_rules (architecture), backend_layers, frontend_layers, versioning_rules, and any base_standards_extra. Omit a field only when that standard genuinely doesn't apply to this stack.",
-                "3. Suggest packs: add stack packs whose 'detect' hints match dependencies you found; offer the rest. Ask the user which packs to install (the spec workflow is always installed).",
-                "4. If the 'workflow' pack is selected, ask the user for their tracker's ticket prefix and team working language.",
+                "2. The foundation is a set of GRANULAR standards under docs/standards/ (base, architecture, backend, frontend, testing, conventions, lawbook), bound by LAWS.md and referenced from CLAUDE.md/AGENTS.md. Fill their structured fields from the real repo: modules_table and layering_rules (architecture), backend_layers, frontend_layers, versioning_rules, and any base_standards_extra. Omit a field only when that standard genuinely doesn't apply to this stack.",
+                "3. Suggest packs: add stack packs whose 'detect' hints match dependencies you found; offer the rest. Ask the user which packs to install (the lawbook workflow is always installed).",
+                "4. Infer the working language and the branch/commit/tracker conventions from the repo itself — the language already used in docstrings, commit messages, branch names, and PR/ticket bodies. Do NOT ask the user or assume English; match what the repo does, and set branch_pattern/commit_style accordingly. speclaw does not prescribe a ticket tool — leave tracker linkage to the team's own convention.",
                 "5. Draft any custom_laws (extra binding rules for LAWS.md) from conventions you observed that the standard set doesn't cover.",
                 "6. Call the 'scaffold' tool with { projectPath, profile, packs }.",
-                "7. Follow the nextSteps returned by scaffold: complete the HTML-comment sections still left in docs/standards/*, then run the spec_init and compass_index tools (both built into speclaw — no external installs).",
+                "7. Follow the nextSteps returned by scaffold: complete the HTML-comment sections still left in docs/standards/*, then run the lawbook_init and compass_index tools (both built into speclaw — no external installs).",
             ],
             profileFields: Object.fromEntries(Object.entries(profileShape).map(([key, schema]) => [key, schema.description ?? ""])),
             packs,
         });
     });
     server.registerTool("scaffold", {
-        description: "Write the speclaw setup into a project: the foundation (LAWS.md constitution + granular docs/standards/* + CLAUDE.md + AGENTS.md + docs/compass.md), the spec workflow (always), the selected tool packs, multi-IDE symlinks (.claude/.cursor/.codex/.agents), .mcp.json wiring for speclaw, and .gitignore for .speclaw/. Never overwrites existing files. Call init_project first.",
+        description: "Write the speclaw setup into a project: the foundation (LAWS.md constitution + granular docs/standards/* + CLAUDE.md + AGENTS.md + docs/compass.md), the lawbook workflow (always), the selected tool packs, multi-IDE symlinks (.claude/.cursor/.codex/.agents), .mcp.json wiring for speclaw, and .gitignore for .speclaw/. Never overwrites existing files. Call init_project first.",
         inputSchema: {
             projectPath: z.string().describe("Absolute path to the project"),
             profile: z.object(profileShape).describe("Project profile gathered by analyzing the repo"),
@@ -70,7 +68,7 @@ export function registerFoundation(server) {
         return text(report);
     });
     server.registerTool("doctor", {
-        description: "Verify a speclaw installation: ai-specs presence, the foundation (LAWS.md + standards + agent contracts), IDE symlinks health, the spec/ workflow, the Compass index, and .mcp.json wiring. Returns a checklist with remediation hints.",
+        description: "Verify a speclaw installation: ai-specs presence, the foundation (LAWS.md + standards + agent contracts), IDE symlinks health, the lawbook/ workflow, the Compass index, and .mcp.json wiring. Returns a checklist with remediation hints.",
         inputSchema: { projectPath: z.string().describe("Absolute path to the project") },
     }, async ({ projectPath }) => {
         const checks = doctor(projectPath);

package/dist/modules/foundation/scaffold.js

@@ -4,7 +4,7 @@ import { assetsDir } from "../../shared/paths.js";
 import { render } from "../../shared/render.js";
 import { emptyReport, ensureGitignore } from "../../shared/install.js";
 import { configureAgent } from "../../shared/agents.js";
-import { installWorkflow } from "../spec/register.js";
+import { installWorkflow } from "../lawbook/register.js";
 import { installPack, loadPacks } from "../tools/packs.js";
 const ASSETS = assetsDir(import.meta.url);
 // Every {{var}} the foundation templates may reference. Ones the agent didn't
@@ -19,7 +19,6 @@ const FOUNDATION_DEFAULTS = {
     frontend_layers: "",
     versioning_rules: "",
     documentation_extra: "",
-    team_language: "English",
 };
 /**
  * Render the foundation: walk the module's assets/, mirror its structure into
@@ -90,7 +89,7 @@ export function scaffold(projectPath, profile, packNames, agents = []) {
     for (const id of agents)
         configureAgent(projectPath, id, report); // only the chosen agents
     report.nextSteps = [
-        "Run the `spec_init` tool to set up the spec-driven workflow (creates spec/). No external CLI needed — it's built into speclaw.",
+        "Run the `lawbook_init` tool to set up the spec-driven workflow (creates lawbook/). No external CLI needed — it's built into speclaw.",
         "Run the `compass_index` tool to build the local code graph (.speclaw/). No install, no LLM — it's built into speclaw. Re-run it after significant edits.",
         "Analyze the repo's real entrypoints and core flows, then fill in the 'Project-specific starting points' section of docs/compass.md (or pass compass_hints in the profile) so agents know where to start querying.",
         "Fill in the per-standard sections left as HTML comments in docs/standards/* (architecture module table, backend/frontend layer tables, versioning) by analyzing the real repo. These are the granular laws CLAUDE.md, AGENTS.md and the dev agents reference.",

package/dist/modules/{spec → lawbook}/assets/commands/archive.md

@@ -5,6 +5,6 @@ description: Finalize a completed change — sync specs into canonical, then arc
 Archive the completed change: $ARGUMENTS
 
 Follow the `archive` skill: confirm every task is done and gates are green,
-run `spec_validate`, then `spec_archive` with today's date (YYYY-MM-DD). It
-syncs the specs and moves the change to `spec/changes/archive/`. Never move
+run `lawbook_validate`, then `lawbook_archive` with today's date (YYYY-MM-DD). It
+syncs the specs and moves the change to `lawbook/changes/archive/`. Never move
 the folder by hand.

package/dist/modules/{spec → lawbook}/assets/commands/draft.md

@@ -2,11 +2,11 @@
 description: Draft a new spec-driven change (proposal, delta specs, tasks) before coding.
 ---
 
-Draft a new change under `spec/changes/<name>/` for: $ARGUMENTS
+Draft a new change under `lawbook/changes/<name>/` for: $ARGUMENTS
 
-Follow the `draft` skill: ensure `spec/` exists (`spec_init`), investigate the
+Follow the `draft` skill: ensure `lawbook/` exists (`lawbook_init`), investigate the
 code with `compass_explore`/`compass_recall`, read the governing
 `docs/standards/`, then write `proposal.md`, `specs/<capability>/spec.md`
 (normative `SHALL`/`MUST` + `#### Scenario:`), optional `design.md`, and
-`tasks.md` (with the mandatory steps from `spec/config.yaml`). Finish by
-running `spec_validate` and fixing every issue.
+`tasks.md` (with the mandatory steps from `lawbook/config.yaml`). Finish by
+running `lawbook_validate` and fixing every issue.

package/dist/modules/{spec → lawbook}/assets/commands/explore.md

@@ -7,4 +7,4 @@ Explore: $ARGUMENTS
 Follow the `explore` skill: use `compass_recall`/`compass_explore` to understand
 the code, ask sharp questions, check the relevant `docs/standards/`, weigh
 approaches with trade-offs, and give a recommendation. Write nothing to
-`spec/`; when the direction is clear, offer to `draft` the change.
+`lawbook/`; when the direction is clear, offer to `draft` the change.

package/dist/modules/{spec → lawbook}/assets/commands/sync.md

@@ -4,6 +4,6 @@ description: Promote a change's delta specs into the canonical specs, without ar
 
 Sync the change's specs into canonical: $ARGUMENTS
 
-Follow the `sync` skill: validate the change (`spec_validate`), then run
-`spec_sync` to promote each delta spec into `spec/specs/`. Report what was
+Follow the `sync` skill: validate the change (`lawbook_validate`), then run
+`lawbook_sync` to promote each delta spec into `lawbook/specs/`. Report what was
 promoted; leave the change active.

package/dist/modules/{spec → lawbook}/assets/rules/spec-tasks-mandatory-steps.md

@@ -1,15 +1,15 @@
 ---
-description: Enforce the mandatory steps from spec/config.yaml when creating tasks.md, and ensure the agent executes all manual verification itself.
+description: Enforce the mandatory steps from lawbook/config.yaml when creating tasks.md, and ensure the agent executes all manual verification itself.
 alwaysApply: true
 ---
 
 # Spec Tasks: Mandatory Steps
 
-When creating or updating a `tasks.md` inside a `spec/changes/<name>/`, you MUST:
+When creating or updating a `tasks.md` inside a `lawbook/changes/<name>/`, you MUST:
 
-## 1. Read spec/config.yaml first
+## 1. Read lawbook/config.yaml first
 
-Before writing tasks, read `spec/config.yaml` for the project's mandatory task
+Before writing tasks, read `lawbook/config.yaml` for the project's mandatory task
 steps, branch convention, and testing/documentation requirements.
 
 ## 2. Include the mandatory steps, in order
@@ -22,7 +22,7 @@ steps, branch convention, and testing/documentation requirements.
 - Perform manual verification of the behavior — **the agent executes this
   itself, never the user.**
 - Update the technical documentation the change touches.
-- Archive the change within the same PR (the `archive` command / `spec_archive`
+- Archive the change within the same PR (the `archive` command / `lawbook_archive`
   tool).
 
 ## 3. Manual verification — the agent must execute it
@@ -33,5 +33,5 @@ not complete until the agent has verified it.
 
 ## 4. Archiving is part of the change
 
-A change is not done until it is archived with `spec_archive` (never a manual
+A change is not done until it is archived with `lawbook_archive` (never a manual
 `mv`). The archive lands in the same PR that implements the change.

package/dist/modules/{spec → lawbook}/assets/skills/archive/SKILL.md

@@ -1,22 +1,22 @@
 ---
 name: archive
-description: Finalize a completed change — sync its specs into canonical, then move it to the archive. Use when a change is done and merged-ready: "archive the change", "finalize X", "close out the change". Part of speclaw's spec module (draft → build → sync → archive). Archiving belongs in the same PR that implements the change.
+description: Finalize a completed change — sync its specs into canonical, then move it to the archive. Use when a change is done and merged-ready: "archive the change", "finalize X", "close out the change". Part of speclaw's lawbook module (draft → build → sync → archive). Archiving belongs in the same PR that implements the change.
 ---
 
 # archive — Finalize and archive a change
 
 Close out a completed change: its delta specs become canonical and the change
-folder moves to `spec/changes/archive/`. This is part of the PR that
+folder moves to `lawbook/changes/archive/`. This is part of the PR that
 implements the change, not a post-merge chore.
 
 ## Steps
 
 1. Confirm the change is truly done: every task in `tasks.md` checked, quality
    gates green, behavior verified.
-2. Run `spec_validate` for the change; resolve any issues first.
-3. Run the `spec_archive` tool with the change name and today's date
-   (`YYYY-MM-DD`). It syncs the delta specs into `spec/specs/` and then moves
-   `spec/changes/<name>/` to `spec/changes/archive/<date>-<name>/`.
+2. Run `lawbook_validate` for the change; resolve any issues first.
+3. Run the `lawbook_archive` tool with the change name and today's date
+   (`YYYY-MM-DD`). It syncs the delta specs into `lawbook/specs/` and then moves
+   `lawbook/changes/<name>/` to `lawbook/changes/archive/<date>-<name>/`.
 4. Report the archive path and the promoted specs. Never move the folder by
-   hand — always use `spec_archive`, which performs the sync and validation a
+   hand — always use `lawbook_archive`, which performs the sync and validation a
    manual move would skip.

package/dist/modules/{spec → lawbook}/assets/skills/build/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: build
-description: Implement the tasks of a drafted change, following its spec and the project's standards. Use when the user wants to start or continue implementing a change: "build X", "implement the change", "work through the tasks", "continue X". Part of speclaw's spec module (draft → build → sync → archive).
+description: Implement the tasks of a drafted change, following its spec and the project's standards. Use when the user wants to start or continue implementing a change: "build X", "implement the change", "work through the tasks", "continue X". Part of speclaw's lawbook module (draft → build → sync → archive).
 ---
 
 # build — Implement a change
@@ -10,8 +10,8 @@ in lockstep.
 
 ## Step 0 — Load the change
 
-- Read `spec/changes/<name>/proposal.md`, `tasks.md`, and the delta specs under
-  `specs/`. If unsure which change, run `spec_list`.
+- Read `lawbook/changes/<name>/proposal.md`, `tasks.md`, and the delta specs under
+  `specs/`. If unsure which change, run `lawbook_list`.
 - Read the governing standards in `docs/standards/` for the areas you'll touch.
 
 ## Step 1 — Branch first

package/dist/modules/{spec → lawbook}/assets/skills/draft/SKILL.md

@@ -1,17 +1,17 @@
 ---
 name: draft
-description: Draft a new spec-driven change — proposal, delta specs, and tasks — before writing any code. Use when the user wants to start, plan, or propose a new feature, fix, or refactor: "draft a change for X", "propose X", "let's plan X", "spec out X", "new change". Part of speclaw's spec module (draft → build → sync → archive).
+description: Draft a new spec-driven change — proposal, delta specs, and tasks — before writing any code. Use when the user wants to start, plan, or propose a new feature, fix, or refactor: "draft a change for X", "propose X", "let's plan X", "spec out X", "new change". Part of speclaw's lawbook module (draft → build → sync → archive).
 ---
 
 # draft — Draft a new change
 
-Turn a request into a complete, reviewable change under `spec/changes/<name>/`
+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
 
-If `spec/` is missing, run the `spec_init` tool once to create it.
+If `lawbook/` is missing, run the `lawbook_init` tool once to create it.
 
 ## Step 1 — Understand the request and the code
 
@@ -25,14 +25,14 @@ If `spec/` is missing, run the `spec_init` tool once to create it.
 ## Step 2 — Pick a change name
 
 Kebab-case, action-oriented (e.g. `add-login`, `fix-shift-overlap`). This is
-the folder under `spec/changes/`.
+the folder under `lawbook/changes/`.
 
 ## Step 3 — Write the artifacts
 
-Create under `spec/changes/<name>/`:
+Create under `lawbook/changes/<name>/`:
 
 - **proposal.md** — the why, the what, non-goals, and whether migrations are
-  needed. Reference the tracker ticket ({{ticket_prefix}}-N) if there is one.
+  needed. Reference the team's tracker ticket if there is one.
 - **specs/<capability>/spec.md** — the delta spec for each affected capability.
   Use normative language and testable scenarios:
   ```markdown
@@ -49,13 +49,13 @@ Create under `spec/changes/<name>/`:
 - **design.md** (optional) — for non-trivial changes: approach, alternatives,
   trade-offs.
 - **tasks.md** — ordered, checkable steps. MUST include the mandatory steps
-  from `spec/config.yaml` (feature branch first; tests reviewed and run;
+  from `lawbook/config.yaml` (feature branch first; tests reviewed and run;
   manual verification executed by the agent; docs updated; archive within the
   PR).
 
 ## Step 4 — Validate
 
-Run the `spec_validate` tool for the change and fix every issue it reports
+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.
 

package/dist/modules/{spec → lawbook}/assets/skills/explore/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: explore
-description: Enter explore mode — a thinking partner for investigating an idea, a problem, or the codebase before or during a change. Use when the user wants to think something through, understand how something works, or clarify requirements before committing to a spec: "help me think through X", "how does X work", "explore X", "I'm not sure how to approach X". Part of speclaw's spec module.
+description: Enter explore mode — a thinking partner for investigating an idea, a problem, or the codebase before or during a change. Use when the user wants to think something through, understand how something works, or clarify requirements before committing to a spec: "help me think through X", "how does X work", "explore X", "I'm not sure how to approach X". Part of speclaw's lawbook module.
 ---
 
 # explore — Think it through
 
 A low-commitment mode for investigating ideas and the codebase before (or
-during) a change. Nothing is written to `spec/` here — the output is shared
+during) a change. Nothing is written to `lawbook/` here — the output is shared
 understanding and a recommended direction.
 
 ## How to explore

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

@@ -0,0 +1,21 @@
+---
+name: sync
+description: Promote a change's delta specs into the canonical specs, without archiving. Use when the user wants to update the source-of-truth specs from a change: "sync the specs", "update the canonical specs", "promote the specs". Part of speclaw's lawbook module (draft → build → sync → archive).
+---
+
+# sync — Promote delta specs to canonical
+
+Update the project's canonical specifications (`lawbook/specs/`) with a change's
+delta specs, without archiving the change. Use this when the specs should
+become the source of truth but the change isn't finished (e.g. multi-PR work).
+
+## Steps
+
+1. Confirm which change to sync (run `lawbook_list` if unsure).
+2. Run `lawbook_validate` for the change; do not sync a change whose specs are
+   invalid.
+3. 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.
+4. Report the promoted files to the user. The change stays active — `archive`
+   it when it's fully done.

package/dist/modules/{spec → lawbook}/engine.js

@@ -4,20 +4,20 @@ import path from "node:path";
 // (proposals, delta specs, changes, archive) but implemented from scratch and
 // deliberately simpler: a change's specs/ holds the full intended spec for each
 // affected capability, and sync promotes those into the canonical specs/.
-const SPEC_DIR = "spec";
+const SPEC_DIR = "lawbook";
 function specRoot(projectPath) {
     return path.join(projectPath, SPEC_DIR);
 }
 /**
- * Report whether the spec workspace (spec/) has been initialized for a project.
+ * Report whether the lawbook workspace (lawbook/) has been initialized for a project.
  *
  * @param projectPath - Absolute path to the project root.
- * @returns True if the spec/ directory exists.
+ * @returns True if the lawbook/ directory exists.
  */
 export function specExists(projectPath) {
     return fs.existsSync(specRoot(projectPath));
 }
-const CONFIG_YAML = `# speclaw spec module configuration
+const CONFIG_YAML = `# speclaw lawbook module configuration
 # The spec-driven workflow: draft -> build -> sync -> archive (explore anytime).
 
 # Mandatory steps every change's tasks.md must include, in order.
@@ -27,14 +27,14 @@ mandatory_task_steps:
   - "Run the quality gates and verify they pass (see docs/standards/testing-standards.md)."
   - "Perform manual verification of the behavior — the agent executes this itself, never the user."
   - "Update the technical documentation touched by the change."
-  - "Archive the change within the same PR (spec:archive)."
+  - "Archive the change within the same PR (lawbook:archive)."
 
 # A change is required for new behavior, endpoints, schema changes, or UI flows;
 # one-line fixes need not have one.
 `;
-const README_MD = `# spec/ — the spec-driven workflow (speclaw)
+const README_MD = `# lawbook/ — the spec-driven workflow (speclaw)
 
-This directory is managed by speclaw's **spec** module.
+This directory is managed by speclaw's **lawbook** module.
 
 - \`specs/\` — the canonical specifications (the current source of truth).
 - \`changes/<name>/\` — an in-flight change: \`proposal.md\`, \`tasks.md\`,
@@ -44,11 +44,11 @@ This directory is managed by speclaw's **spec** module.
 
 ## Workflow
 
-1. \`spec:draft\` — describe the change; generates proposal, delta specs, tasks.
-2. \`spec:build\` — implement the tasks.
-3. \`spec:sync\` — promote the change's delta specs into \`specs/\`.
-4. \`spec:archive\` — sync + move the change to \`changes/archive/\`.
-5. \`spec:explore\` — think through an idea before or during a change.
+1. \`lawbook:draft\` — describe the change; generates proposal, delta specs, tasks.
+2. \`lawbook:build\` — implement the tasks.
+3. \`lawbook:sync\` — promote the change's delta specs into \`specs/\`.
+4. \`lawbook:archive\` — sync + move the change to \`changes/archive/\`.
+5. \`lawbook:explore\` — think through an idea before or during a change.
 `;
 /**
  * Initialize the spec/ workspace, creating the specs/, changes/, and archive
@@ -107,7 +107,7 @@ function deltaSpecFiles(changeDir) {
  * header, and a "#### Scenario:" acceptance criterion.
  *
  * @param projectPath - Absolute path to the project root.
- * @param change - Change name (folder under spec/changes/).
+ * @param change - Change name (folder under lawbook/changes/).
  * @returns The validation verdict and the list of issues to fix; never throws
  *   for a missing change — it is reported as an issue with `valid: false`.
  */
@@ -115,7 +115,7 @@ export function specValidate(projectPath, change) {
     const changeDir = path.join(specRoot(projectPath), "changes", change);
     const issues = [];
     if (!fs.existsSync(changeDir)) {
-        return { change, valid: false, issues: [`change "${change}" not found under spec/changes/`], deltaSpecs: [] };
+        return { change, valid: false, issues: [`change "${change}" not found under lawbook/changes/`], deltaSpecs: [] };
     }
     if (!fs.existsSync(path.join(changeDir, "proposal.md")))
         issues.push("missing proposal.md");
@@ -145,7 +145,7 @@ export function specValidate(projectPath, change) {
  * file for each affected capability.
  *
  * @param projectPath - Absolute path to the project root.
- * @param change - Change name (folder under spec/changes/).
+ * @param change - Change name (folder under lawbook/changes/).
  * @returns The change name and the list of promoted spec paths.
  * @throws If the change directory does not exist.
  */
@@ -168,7 +168,7 @@ export function specSync(projectPath, change) {
                 const dest = path.join(root, "specs", rel);
                 fs.mkdirSync(path.dirname(dest), { recursive: true });
                 fs.copyFileSync(full, dest);
-                promoted.push(path.join("spec/specs", rel));
+                promoted.push(path.join("lawbook/specs", rel));
             }
         }
     };
@@ -180,7 +180,7 @@ export function specSync(projectPath, change) {
  * it to changes/archive/<date>-<name>/.
  *
  * @param projectPath - Absolute path to the project root.
- * @param change - Change name (folder under spec/changes/).
+ * @param change - Change name (folder under lawbook/changes/).
  * @param date - Archive date prefix, formatted YYYY-MM-DD.
  * @returns The promoted specs and the archive destination path.
  * @throws If the change does not exist, or the archive target already exists.

package/dist/modules/{spec → lawbook}/register.js

@@ -13,40 +13,40 @@ const ASSETS = assetsDir(import.meta.url);
 export function installWorkflow(projectPath, vars, report) {
     const aiSpecs = path.join(projectPath, "ai-specs");
     copyRendered(path.join(ASSETS, "skills"), path.join(aiSpecs, "skills"), vars, report);
-    copyRendered(path.join(ASSETS, "commands"), path.join(aiSpecs, "commands", "spec"), vars, report);
+    copyRendered(path.join(ASSETS, "commands"), path.join(aiSpecs, "commands", "lawbook"), vars, report);
     copyRendered(path.join(ASSETS, "rules"), path.join(aiSpecs, "rules"), vars, report);
 }
 // ─── 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("spec_init", {
-        description: "Initialize speclaw's spec-driven workflow in a project: creates spec/ (specs/, changes/, changes/archive/, config.yaml, README). Idempotent — never overwrites existing files.",
+    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("spec_list", {
+    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("spec_validate", {
+    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 issues to fix. 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 spec/changes/)"),
+            change: z.string().describe("Change name (folder under lawbook/changes/)"),
         },
     }, async ({ projectPath, change }) => text(specValidate(projectPath, change)));
-    server.registerTool("spec_sync", {
-        description: "Promote a change's delta specs into the canonical spec/specs/ (per capability), without archiving. Backs the `sync` command.",
+    server.registerTool("lawbook_sync", {
+        description: "Promote a change's delta specs into the canonical lawbook/specs/ (per capability), without archiving. Backs the `sync` command.",
         inputSchema: {
             projectPath: z.string().describe("Absolute path to the project"),
-            change: z.string().describe("Change name (folder under spec/changes/)"),
+            change: z.string().describe("Change name (folder under lawbook/changes/)"),
         },
     }, async ({ projectPath, change }) => text(specSync(projectPath, change)));
-    server.registerTool("spec_archive", {
-        description: "Finalize a change: sync its delta specs into spec/specs/, then move it to spec/changes/archive/<date>-<name>/. Backs the `archive` command. Pass today's date as YYYY-MM-DD.",
+    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 spec/changes/)"),
+            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"),
         },
     }, async ({ projectPath, change, date }) => text(specArchive(projectPath, change, date)));

package/dist/modules/tools/assets/packs/agents/backend-developer.md

@@ -22,7 +22,7 @@ Output path:
 - [`docs/standards/backend-standards.md`](../../docs/standards/backend-standards.md) — layers, docstrings, typing, tests, migrations
 - [`docs/standards/architecture.md`](../../docs/standards/architecture.md) — modules and layer boundaries
 - [`docs/standards/testing-standards.md`](../../docs/standards/testing-standards.md) — quality gates
-- [`docs/standards/spec-workflow.md`](../../docs/standards/spec-workflow.md) — spec-driven workflow
+- [`docs/standards/lawbook.md`](../../docs/standards/lawbook.md) — spec-driven workflow
 - [`docs/standards/base-standards.md`](../../docs/standards/base-standards.md) — cross-cutting rules
 
 Use `compass_explore` to locate the real entrypoints, routers, schemas,

package/dist/modules/tools/assets/packs/agents/frontend-developer.md

@@ -22,7 +22,7 @@ Output path:
 - [`docs/standards/frontend-standards.md`](../../docs/standards/frontend-standards.md) — layers, rendering boundaries, state, i18n, UI
 - [`docs/standards/architecture.md`](../../docs/standards/architecture.md) — modules and layer boundaries
 - [`docs/standards/testing-standards.md`](../../docs/standards/testing-standards.md) — quality gates
-- [`docs/standards/spec-workflow.md`](../../docs/standards/spec-workflow.md) — spec-driven workflow
+- [`docs/standards/lawbook.md`](../../docs/standards/lawbook.md) — spec-driven workflow
 - [`docs/standards/base-standards.md`](../../docs/standards/base-standards.md) — cross-cutting rules
 
 Use `compass_explore` to locate the real entry files, feature routes, shared

package/dist/modules/tools/register.js

@@ -12,7 +12,7 @@ export function registerTools(server) {
         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, ticket_prefix, team_language, ...) if the pack needs them.",
+        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)"),