@llman-sdd/core 0.1.2 → 0.1.4

package/templates/en/skills/llman-sdd-graph.md

@@ -27,9 +27,9 @@ flowchart LR
 **Focus view (seed mode):** Show a specific change and its relationship neighborhood.
 
 ```bash
-llman sdd graph <change-id>              # the change + direct relationships (depth 1)
-llman sdd graph <change-id> --depth 3    # recurse 3 levels
-llman sdd graph <change-id> --depth 0    # just the change itself
+llman-sdd graph <change-id>              # the change + direct relationships (depth 1)
+llman-sdd graph <change-id> --depth 3    # recurse 3 levels
+llman-sdd graph <change-id> --depth 0    # just the change itself
 ```
 
 Seed mode traverses three directions: upstream (depends_on), downstream (depended by), and blocks, automatically discovering active and archived changes.
@@ -37,17 +37,17 @@ Seed mode traverses three directions: upstream (depends_on), downstream (depende
 **Global view (scope mode):** Show all changes by scope.
 
 ```bash
-llman sdd graph                          # all active changes (default)
-llman sdd graph --scope archived         # all archived (completed) changes
-llman sdd graph --scope all              # everything
+llman-sdd graph                          # all active changes (default)
+llman-sdd graph --scope archived         # all archived (completed) changes
+llman-sdd graph --scope all              # everything
 ```
 
 ## Output
 
 - Output is a mermaid flowchart to stdout, pipeable to a file or renderer:
   ```
-  llman sdd graph c50 > deps.mmd
-  llman sdd graph c50 --depth 2 | mmdc -i - -o deps.png
+  llman-sdd graph c50 > deps.mmd
+  llman-sdd graph c50 --depth 2 | mmdc -i - -o deps.png
   ```
 - Archived (completed) changes are shown with "✓ done" suffix and green highlight.
 - When the graph contains disconnected groups, each group renders as an independent subgraph labeled "Active", "Done", or "Mixed".
@@ -68,7 +68,7 @@ blocks:
 
 > 💡 This is just a utility — main flow: `llman-sdd-propose` (Branch binding + Specs landing) → `llman-sdd-apply` (requires `readyToImplement`) → `llman-sdd-verify` → `llman-sdd-archive`.
 
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 
 {{ unit("skills/ethics-governance") }}

package/templates/en/skills/llman-sdd-onboard.md

@@ -11,23 +11,23 @@ Use this skill to onboard to llman SDD in a repository.
 
 ## Steps
 1. Read `llmanspec/config.yaml` for project context, conventions, and rules.
-2. Use `llman sdd list --specs --json` to see all specs at a glance.
-   - Or use `llman sdd context --task "<task description>" --paths "<files>"` to find task-relevant specs.
-   - If context returns `quality: "unavailable"`, run `llman sdd index rebuild` first (default backend is `pageindex`; it needs `LLMAN_SDD_INDEX_CHAT_MODEL` for retrieval but not for rebuilding).
+2. Use `llman-sdd list --specs --json` to see all specs at a glance.
+   - Or use `llman-sdd context --task "<task description>" --paths "<files>"` to find task-relevant specs.
+   - If context returns `quality: "unavailable"`, run `llman-sdd index rebuild` first (default backend is `pageindex`; it needs `LLMAN_SDD_INDEX_CHAT_MODEL` for retrieval but not for rebuilding).
 3. Read only the `direct` spec files from context output.
 4. Assess change scale (see triage rules): behavioural contract change → full SDD; implementation change → quick path.
 5. Advance by path:
    - **Full path**: planning shell (draft → designed [+design.md] → planned [+tasks.md]) → Branch binding → Specs landing (or `needs_specs_change: false`) → `readyToImplement=true` → apply → verify → finalize/archive (skill navigation: propose → apply → verify → archive).
    - **Quick path**: no MUST/SHALL change; edit code and commit (live specs only on a bound branch — see `llman-sdd-quick`).
-6. Use `llman sdd graph` to visualize change dependencies.
+6. Use `llman-sdd graph` to visualize change dependencies.
 
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 
 ## Notes
 - `llmanspec/config.yaml` holds project context, rules, locale, and skills paths.
 - Locale affects templates/skills only; CLI stays English.
-- Refresh skills with `llman sdd init --update`.
+- Refresh skills with `llman-sdd init --update`.
 
 {{ unit("skills/validation-hints") }}
 

package/templates/en/skills/llman-sdd-propose.md

@@ -40,7 +40,7 @@ flowchart LR
 {% else %}
 - **If change already exists**: STOP. If `readyToImplement=true`, suggest `llman-sdd-apply`; otherwise finish the planning shell / Branch binding / Specs landing (edit `llmanspec/changes/<id>/`, or enable `extra_skills: [llman-sdd-continue]`).
 {% endif %}
-- **Frontmatter has a fixed schema**: when fleshing out `proposal.md`, only the allowed fields in `llmanspec/AGENTS.md` "Change Proposal Frontmatter SSOT" are accepted (including `depends_on`, `blocks`, `branch`, `base_sha`, `needs_specs_change`). `status`/`title`/`priority`/`author` etc. are rejected by `llman sdd validate` as ERROR; lifecycle stage is inferred (query via `llman sdd show`/`list`), never stored in frontmatter. Do not re-declare frontmatter fields in the prose body; the body H1 is a human-readable title, not a repeat of the change id.
+- **Frontmatter has a fixed schema**: when fleshing out `proposal.md`, only the allowed fields in `llmanspec/AGENTS.md` "Change Proposal Frontmatter SSOT" are accepted (including `depends_on`, `blocks`, `branch`, `base_sha`, `needs_specs_change`). `status`/`title`/`priority`/`author` etc. are rejected by `llman-sdd validate` as ERROR; lifecycle stage is inferred (query via `llman-sdd show`/`list`), never stored in frontmatter. Do not re-declare frontmatter fields in the prose body; the body H1 is a human-readable title, not a repeat of the change id.
 
 ## Quick-capture routing
 
@@ -50,9 +50,9 @@ If the user just wants to **capture an idea** (e.g. "draft a proposal", "note do
 
 ### 0) Preflight
 - Read `llmanspec/config.yaml` for project context, rules, locale.
-- `llman sdd validate --all --strict --no-interactive`: ensure current artifacts are clean.
+- `llman-sdd validate --all --strict --no-interactive`: ensure current artifacts are clean.
   - If pre-existing errors, stop and report (stacking new changes on dirty artifacts causes cascading errors).
-- **Check spec valid_scope integrity**: use `llman sdd list --specs --json` to list all specs, then for each spec verify every path in its `valid_scope` exists on disk. If any scope file/directory is missing, stop and suggest updating the spec (remove the deleted path from `valid_scope`).
+- **Check spec valid_scope integrity**: use `llman-sdd list --specs --json` to list all specs, then for each spec verify every path in its `valid_scope` exists on disk. If any scope file/directory is missing, stop and suggest updating the spec (remove the deleted path from `valid_scope`).
 
 ### 1) Assess change scale (triage)
 1. Classify:
@@ -60,18 +60,18 @@ If the user just wants to **capture an idea** (e.g. "draft a proposal", "note do
    - **Implementation change** (refactor, typo, perf) → quick path via `llman-sdd-quick`
    - **Meta-spec change** (SDD templates/process) → full SDD workflow
    - When uncertain, choose full SDD (conservative).
-2. Use `llman sdd context --task "<goal>" --paths "<scope>"` to find relevant specs.
-   - If context unavailable, rebuild with `llman sdd index rebuild` (default `pageindex`, no model needed) and continue.
+2. Use `llman-sdd context --task "<goal>" --paths "<scope>"` to find relevant specs.
+   - If context unavailable, rebuild with `llman-sdd index rebuild` (default `pageindex`, no model needed) and continue.
 3. Gather input:
    - A short description of the change
    - A change id (user-supplied if given; otherwise derive it with the non-blocking rule above and announce it)
    - The impacted capability/capabilities (to name `specs/<capability>`)
 
 ### 2) Ensure project is initialized
-   - `llmanspec/` must exist; if missing, tell the user to run `llman sdd init`, then STOP.
+   - `llmanspec/` must exist; if missing, tell the user to run `llman-sdd init`, then STOP.
 
 ### 3) Create change directory and artifacts
-   - Prefer `llman sdd change new <change-id>` for the draft `proposal.md` shell (or create `llmanspec/changes/<change-id>/` manually).
+   - Prefer `llman-sdd change new <change-id>` for the draft `proposal.md` shell (or create `llmanspec/changes/<change-id>/` manually).
 {% if extra_skill_continue %}
    - If the change already exists, STOP and suggest `llman-sdd-continue`.
 {% else %}
@@ -81,14 +81,14 @@ If the user just wants to **capture an idea** (e.g. "draft a proposal", "note do
    - `design.md` only when tradeoffs/migrations matter
    - **Confirm seams before writing tasks.md**: list the seams to be tested and confirm with the user. A seam = the public boundary driven by `*.feature` GWT steps (CLI subprocess or public interface) — MUST reuse existing harness seams, MUST NOT invent seams detached from `.feature`. Without `.feature`, seam = the CLI subcommand or public function boundary under test.
    - `tasks.md`: split into **vertical slices** (each task cuts a narrow but complete path through schema→API→UI→tests, independently verifiable), with `[blocked-by: <task-id>]` dependency markers. **Wide-refactor exception** (one mechanical change sweeping the codebase, single edit breaks many call sites): sequence as expand-contract (add new beside old → migrate call sites in batches → delete old), don't force into a vertical slice.
-   - **First** `llman sdd change start <change-id>` (recommended; clean tree on the default branch) or manually create a branch then `change attach <change-id>` to reach Full (bound).
+   - **First** `llman-sdd change start <change-id>` (recommended; clean tree on the default branch) or manually create a branch then `change attach <change-id>` to reach Full (bound).
    - **Then** edit live `llmanspec/specs/<capability>.feature` (flat, or directory `llmanspec/specs/<capability>/` main file) on the bound non-default branch and commit (Specs landing). **Do not** edit live specs before start; **do not** commit live specs to the default branch just to satisfy the clean-tree gate. If already attached, do not re-run `start` (recover lost specs by checkout/recreate + `attach --force` if needed).
-   - For changes with no live contract edits, set frontmatter `needs_specs_change: false`. Enter apply only when `llman sdd show <id> --json` has `readyToImplement=true`.
+   - For changes with no live contract edits, set frontmatter `needs_specs_change: false`. Enter apply only when `llman-sdd show <id> --json` has `readyToImplement=true`.
    - **Breaking contract changes** (removed/renamed fields, commands, tags, or stage values) MUST plan the upgrade path: `migrations/v<from>-v<to>/` with README prompt + one-shot script (ship the upgrade dir + one-shot script in the same repo) — include it in the proposal's What Changes.
 
 ### 4) Validate
    ```bash
-   llman sdd validate <change-id> --strict --no-interactive
+   llman-sdd validate <change-id> --strict --no-interactive
    ```
    This MUST pass before proceeding. If TOON parse errors appear, fix quoting:
    values containing commas/colons/brackets must be double-quoted in tabular rows.
@@ -104,8 +104,8 @@ If the user just wants to **capture an idea** (e.g. "draft a proposal", "note do
 ### 4b) Single-track feature authoring
 - Planning shell (proposal/design/tasks) may briefly live on the default branch; **do not** edit live `llmanspec/specs/**` on the default branch. After Branch binding, Specs landing and implementation happen on the bound branch.
 - **Single-track**: each capability is ONE `<capability>.feature`. Constraint rules are `@req:<id> @human` scenarios (statement verbatim in the description); executable acceptance scenarios carry `@executable` and link back via `@req:<req_id>`. Never nest scenarios in `Rule:` blocks (the runner skips them).
-- Change shell: `llman sdd change new <change-id>` → fill proposal/design/tasks → `llman sdd change start <change-id>` (or `change attach`) → **then** edit live specs on the bound branch and commit (Specs landing).
-- Do **not** use `change delta` / solidify / `*.feature.delta.toon`; if an active `*.feature.delta.toon` or a legacy `spec.toon` exists, run `llman sdd project migrate --kind toon2features` first.
+- Change shell: `llman-sdd change new <change-id>` → fill proposal/design/tasks → `llman-sdd change start <change-id>` (or `change attach`) → **then** edit live specs on the bound branch and commit (Specs landing).
+- Do **not** use `change delta` / solidify / `*.feature.delta.toon`; if an active `*.feature.delta.toon` or a legacy `spec.toon` exists, run `llman-sdd project migrate --kind toon2features` first.
 
 ### 5) Summarize and suggest next step
    - Enter implementation phase: `llman-sdd-apply`.
@@ -113,8 +113,8 @@ If the user just wants to **capture an idea** (e.g. "draft a proposal", "note do
 
 > 💡 Proposal done → next: `llman-sdd-apply` (implement)
 
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 {{ unit("skills/validation-hints") }}
 
 {{ unit("skills/structured-protocol") }}

package/templates/en/skills/llman-sdd-quick.md

@@ -36,9 +36,9 @@ flowchart LR
 - Is not a meta-spec change (SDD templates/process)
 
 ## Steps
-1. Use `llman sdd context --task "..." --paths "..."` to confirm no spec changes needed.
-   - If context returns `quality: "unavailable"`, rebuild with `llman sdd index rebuild` (default `pageindex`, no model needed).
-   - Use `llman sdd list --specs --json` for keyword-level spec metadata.
+1. Use `llman-sdd context --task "..." --paths "..."` to confirm no spec changes needed.
+   - If context returns `quality: "unavailable"`, rebuild with `llman-sdd index rebuild` (default `pageindex`, no model needed).
+   - Use `llman-sdd list --specs --json` for keyword-level spec metadata.
 2. Modify the code directly.
 3. If you need to touch `llmanspec/specs/**`, STOP unless you are on a bound non-default change branch (mini change: `change start`/`attach` → edit → commit). Never commit live specs on the default branch — not even for typo or scope-only fixes. Prefer routing live-spec maintenance to `llman-sdd-propose`, or require an existing bound branch.
 4. git commit (message must explain why).
@@ -46,11 +46,11 @@ flowchart LR
 
 ## Boundary handling
 - If during modification you find a behavioral contract change → STOP, switch to `llman-sdd-propose` (full path).
-- If multiple files are involved and scope is unclear → verify with `llman sdd context` first.
+- If multiple files are involved and scope is unclear → verify with `llman-sdd context` first.
 
 > 💡 Quick path done → git commit. If you need the full path → `llman-sdd-propose` → `llman-sdd-apply` → `llman-sdd-verify` → `llman-sdd-archive`
 
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 
 {{ unit("skills/ethics-governance") }}

package/templates/en/skills/llman-sdd-research.md

@@ -40,7 +40,7 @@ The background agent's job:
 
 `llman-sdd-wayfinder`'s research tickets delegate to this skill for background resolution; on completion, write back to the ticket proposal and record a one-line gist in the map's Decisions-so-far.
 
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 
 {{ unit("skills/structured-protocol") }}

package/templates/en/skills/llman-sdd-show.md

@@ -10,14 +10,14 @@ metadata:
 Use this skill to inspect changes, specs, and JSON output.
 
 ## Steps
-1. List items: `llman sdd list` or `llman sdd list --specs`.
+1. List items: `llman-sdd list` or `llman-sdd list --specs`.
 2. If the id is unknown or ambiguous, show the list and ask the user to pick.
-3. Show details: `llman sdd show <id>`.
+3. Show details: `llman-sdd show <id>`.
 4. Disambiguate with `--type change|spec` when needed.
 5. For changes, use `--json`: status SSOT fields are `stage` / `specsLanded` / `needsSpecsChange` / `readyToImplement` (never decide apply-readiness from vague "complete artifacts" wording).
 
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 
 {{ unit("skills/validation-hints") }}
 

package/templates/en/skills/llman-sdd-specs-compact.md

@@ -37,13 +37,13 @@ flowchart LR
 - **Editing live `llmanspec/specs/**` requires a change**: Branch binding first (`change start` / `attach`), then commit on the bound branch (Specs landing style); **never** compact-rewrite live specs on the default branch.
 
 ## Workflow
-1. Inventory current specs (`llman sdd list --specs`).
+1. Inventory current specs (`llman-sdd list --specs`).
 2. If archived history is large, run archive freeze first:
-   - Preview: `llman sdd archive freeze --dry-run`
-   - Execute: `llman sdd archive freeze --before <YYYY-MM-DD> --keep-recent <N>`
+   - Preview: `llman-sdd archive freeze --dry-run`
+   - Execute: `llman-sdd archive freeze --before <YYYY-MM-DD> --keep-recent <N>`
 3. Identify overlapping items across capabilities.
 4. Produce a compaction plan (canonical requirements + keep/merge/remove decisions + migration notes).
-5. Execute and validate (`llman sdd validate --specs --strict --no-interactive`).
+5. Execute and validate (`llman-sdd validate --specs --strict --no-interactive`).
 
 ## Decision Policy
 - Prefer merging when two requirements are semantically equivalent.
@@ -58,8 +58,8 @@ flowchart LR
 
 > 💡 After maintenance, new work goes through the normal pipeline: `llman-sdd-propose` (Branch binding + Specs landing) → `llman-sdd-apply` (requires `readyToImplement`) → `llman-sdd-verify` → `llman-sdd-archive`.
 
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 
 {{ unit("skills/validation-hints") }}
 

package/templates/en/skills/llman-sdd-validate.md

@@ -10,8 +10,8 @@ metadata:
 Use this skill to validate change/spec format and staleness.
 
 ## Steps
-1. Validate one item: `llman sdd validate <id>`.
-2. Validate all: `llman sdd validate --all` (or `--changes` / `--specs`).
+1. Validate one item: `llman-sdd validate <id>`.
+2. Validate all: `llman-sdd validate --all` (or `--changes` / `--specs`).
 3. Use `--strict` and `--no-interactive` for CI-like checks.
 4. If validation fails, summarize the errors and propose minimal, concrete fixes.
 {% if bdd_enabled %}
@@ -19,13 +19,13 @@ Use this skill to validate change/spec format and staleness.
    - Validate live `.feature` Gherkin and `@req` / dual-write gates on the **bound branch** (Branch binding required).
    - `.feature` is the harness authority — executable GWT lives only in live `.feature` (no solidify; no `feature_delta` / `change delta`).
    - Change lifecycle gates: `change start` / `attach` (Branch binding), `finalize` (close-out; auto commit `archive(sdd): <id>`, `--no-commit` to skip) / `diff` (read-only). `change checkpoint` is removed (no mid-flight archive point; `change finalize` does not require a clean tree).
-   - `llman sdd validate --specs` runs `bdd.run_command` by default.
+   - `llman-sdd validate --specs` runs `bdd.run_command` by default.
    - Use `list --specs --json` for `morphology` (includes `dualWriteCount`).
    - Change JSON status fields: `stage` (draft/designed/planned/full) / `specsLanded` / `needsSpecsChange` / `readyToImplement` (`show --json`).
 {% endif %}
 
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 
 {{ unit("skills/validation-hints") }}
 

package/templates/en/skills/llman-sdd-verify.md

@@ -34,9 +34,9 @@ flowchart LR
 {{ unit("skills/stage-guard") }}
 
 ## Steps
-1. Select the change id (or ask the user to pick from `llman sdd list --json`).
+1. Select the change id (or ask the user to pick from `llman-sdd list --json`).
 2. Run a fast validation gate:
-   - `llman sdd validate <id> --strict --no-interactive`
+   - `llman-sdd validate <id> --strict --no-interactive`
    - **When diagnosing structural issues (Gherkin parse / `@req` linkage / dual-write / global req_id uniqueness), prefer adding `--no-check`** (skips the potentially slow `bdd.run_command` under BDD-on); run the full `--check` (full mode) only after structural gates are green. Each `FAIL <item_type>/<id>` line lists a failing item (above the Totals line).
 3. Read:
    - Live specs on the feature branch: `llmanspec/specs/**` (`<capability>.feature`) — SSOT
@@ -69,8 +69,8 @@ flowchart LR
    - The two axes may be reviewed in parallel (sub-agents); the report MUST present them separately, MUST NOT merge or cross-rerank (one axis passing must not mask the other failing).
 5. **BDD-on verification (Git-native Partitioned SSOT)** — only when `config.yaml` has a `bdd:` block:
    - Confirm the change is attached and you are on that feature branch.
-   - `llman sdd validate --specs`: Gherkin + `@req`/dual-write gates; runs `bdd.run_command` by default (`--no-check` to skip).
-   - Optional read-only review: `llman sdd change diff <id>` (or `--export-patch <path>`). Diff is review/export only — never treat it as an apply step.
+   - `llman-sdd validate --specs`: Gherkin + `@req`/dual-write gates; runs `bdd.run_command` by default (`--no-check` to skip).
+   - Optional read-only review: `llman-sdd change diff <id>` (or `--export-patch <path>`). Diff is review/export only — never treat it as an apply step.
    - Check: legacy `spec.toon` / `*.feature.delta.toon` absent; if present, run toon2features first (do not invent a solidify / repair hunt).
    - Next step after verify passes: `llman-sdd-archive` (not inline finalize here).
 {% if bdd_verify_prompt %}
@@ -80,7 +80,7 @@ flowchart LR
    - **CRITICAL** (must fix before archive)
    - **WARNING** (should fix)
    - **SUGGESTION** (nice to have)
-7. **Human review checkpoint**: once the report has no CRITICAL findings and before suggesting archive, run `llman sdd review`:
+7. **Human review checkpoint**: once the report has no CRITICAL findings and before suggesting archive, run `llman-sdd review`:
    - Exit code zero → suggest `llman-sdd-archive` for finalize/archive.
    - Non-zero exit = CRITICAL findings: fix via `llman-sdd-apply`, then re-run review; MUST NOT enter finalize/archive with CRITICAL findings open.
 
@@ -88,8 +88,8 @@ flowchart LR
 
 {{ unit("skills/git-native-flow-brief") }}
 {{ unit("skills/human-readable-summary") }}
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 
 {{ unit("skills/validation-hints") }}
 

package/templates/en/skills/llman-sdd-wayfinder.md

@@ -9,7 +9,7 @@ metadata:
 
 A loose, large idea has arrived — too big for a single agent session, wrapped in fog: the way from here to the **destination** isn't visible yet. This skill finds that way rather than charging at the destination.
 
-It charts the path as an llman SDD **change dependency graph** (`llman sdd graph`): each sub-work (ticket) resolves a **decision** rather than delivering a slice, worked one at a time until the way is clear.
+It charts the path as an llman SDD **change dependency graph** (`llman-sdd graph`): each sub-work (ticket) resolves a **decision** rather than delivering a slice, worked one at a time until the way is clear.
 
 ## Pipeline position
 
@@ -25,7 +25,7 @@ Auxiliary tool, for **pre-planning large work** before the main pipeline. When t
 
 ## Map structure
 
-The map is a change (overview proposal); its sub-decisions are `depends_on` child changes. Use `llman sdd graph <map-id> --scope active` to visualize the **frontier** (takeable items).
+The map is a change (overview proposal); its sub-decisions are `depends_on` child changes. Use `llman-sdd graph <map-id> --scope active` to visualize the **frontier** (takeable items).
 
 The map's `proposal.md` structure:
 
@@ -66,8 +66,8 @@ The map is **deliberately** incomplete. The test for ticket-vs-fog: **can you st
 ### Chart the map
 1. **Name the destination**: use `llman-sdd-explore`'s grilling branch to pin down what this map is finding its way to.
 2. **Breadth-first scan**: grill again, fanning out rather than deep-diving, surfacing open decisions and the first takeable steps. If **no fog surfaces** — the way is already clear, the whole effort fits one session — you don't need a map; stop and ask the user how to proceed.
-3. **Create the map** (overview change): `llman sdd change new <map-id>`, fill Destination/Notes, leave Decisions-so-far empty, write fog into Not yet specified.
-4. **Create the tickets you can specify now** as child changes, then wire blocking edges with `llman sdd graph` (second pass: ids needed before cross-referencing).
+3. **Create the map** (overview change): `llman-sdd change new <map-id>`, fill Destination/Notes, leave Decisions-so-far empty, write fog into Not yet specified.
+4. **Create the tickets you can specify now** as child changes, then wire blocking edges with `llman-sdd graph` (second pass: ids needed before cross-referencing).
 5. Spin up `llman-sdd-research` background subagents for each research ticket.
 6. Stop — charting is one session's work; resolve nothing by hand.
 
@@ -79,9 +79,9 @@ The map is **deliberately** incomplete. The test for ticket-vs-fog: **can you st
 5. Add newly-surfaced tickets (create-then-wire); graduate fog that the answer has made specifiable, clearing it from Not yet specified. If the answer reveals a ticket sits beyond the destination, rule it out of scope rather than resolving it on the route.
 
 ## Output
-Map change + child decision changes' dependency graph (`llman sdd graph`). When the way is clear, proceed to `llman-sdd-propose` (Branch binding → Specs landing through `readyToImplement=true`) to collapse decisions into an implementable plan.
+Map change + child decision changes' dependency graph (`llman-sdd graph`). When the way is clear, proceed to `llman-sdd-propose` (Branch binding → Specs landing through `readyToImplement=true`) to collapse decisions into an implementable plan.
 
-> For command details run `llman sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
-> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman sdd list --specs` or `llman sdd show <capability>`.
+> For command details run `llman-sdd <cmd> --help`; the CLI is the command reference — skills embed no command tables.
+> "Spec" here = a `.feature` file under this project's `llmanspec/specs/`; run `llman-sdd list --specs` or `llman-sdd show <capability>`.
 
 {{ unit("skills/structured-protocol") }}

package/templates/en/units/migrate-prompt.md

@@ -1,15 +1,15 @@
-# llman sdd project migrate — collaboration notes
+# llman-sdd project migrate — collaboration notes
 
 ## Command intent
 
-- `llman sdd project migrate --kind toon2features`: legacy `spec.toon` → single-track `.feature` (one-shot, idempotent).
-- `llman sdd project migrate --kind specs-flatten`: pure single-file directories `specs/<cap>/<cap>.feature` → flat `specs/<cap>.feature` (git mv preserves history).
+- `llman-sdd project migrate --kind toon2features`: legacy `spec.toon` → single-track `.feature` (one-shot, idempotent).
+- `llman-sdd project migrate --kind specs-flatten`: pure single-file directories `specs/<cap>/<cap>.feature` → flat `specs/<cap>.feature` (git mv preserves history).
 
 ## What the agent does
 
 - First confirm migration is actually needed (no legacy / single-file dirs → no-op).
 - Run `--dry-run` first and read the precheck report; resolve `conflict` / `misnamed` entries manually — never force.
-- After migrating, run `llman sdd validate --specs --strict --no-interactive` and the project BDD suite.
+- After migrating, run `llman-sdd validate --specs --strict --no-interactive` and the project BDD suite.
 
 ## What the human does
 
@@ -24,5 +24,5 @@
 
 ## Next steps
 
-- `llman sdd validate --specs --strict --no-interactive`
+- `llman-sdd validate --specs --strict --no-interactive`
 - project BDD run (e.g. `cargo test --features bdd`)

package/templates/en/units/skills/ethics-governance.md

@@ -1,6 +1,6 @@
 ## Ethics Governance
 - `ethics.risk_level`: low — reads/writes this repo and `llmanspec/` only, no outward-facing actions; a skill body may override.
 - `ethics.prohibited_actions`: actions violating the skill body's hard rules; push / PR / external upload without an explicit user request.
-- `ethics.required_evidence`: conclusions backed by command output or file paths; gate state per `llman sdd validate`.
+- `ethics.required_evidence`: conclusions backed by command output or file paths; gate state per `llman-sdd validate`.
 - `ethics.refusal_contract`: gate CRITICAL not cleared → refuse to advance; self-repair cap reached → report a blocker.
 - `ethics.escalation_policy`: pause and ask the user before changing SDD contracts/templates or irreversible actions.

package/templates/en/units/skills/git-native-flow.md

@@ -35,6 +35,6 @@ flowchart TB
 
 Hard rules:
 1. **First** `change start` / `attach` (Branch binding) to enter Full; **then** edit `llmanspec/specs/**` on the bound non-default branch and commit (Specs landing).
-2. For changes with no live contract edits, set frontmatter `needs_specs_change: false`. Enter apply only when `llman sdd show <id> --json` has `readyToImplement=true` — `Full ∧` every `gateChecks` item passes (specs-landed = `specsLanded ∨ needs_specs_change=false`; ranges are live merge-bases, stored `base_sha` is audit-only).
-3. `change checkpoint` is removed (no mid-flight archive point; `change finalize` does not require a clean tree). Close-out is `llman sdd change finalize <id>`: it auto-commits `archive(sdd): <id>` (impl diff + rename in one commit); `--no-commit` skips the auto commit for manual/CI histories. Commits on the change branch are free (segmented or finalize single-shot).
+2. For changes with no live contract edits, set frontmatter `needs_specs_change: false`. Enter apply only when `llman-sdd show <id> --json` has `readyToImplement=true` — `Full ∧` every `gateChecks` item passes (specs-landed = `specsLanded ∨ needs_specs_change=false`; ranges are live merge-bases, stored `base_sha` is audit-only).
+3. `change checkpoint` is removed (no mid-flight archive point; `change finalize` does not require a clean tree). Close-out is `llman-sdd change finalize <id>`: it auto-commits `archive(sdd): <id>` (impl diff + rename in one commit); `--no-commit` skips the auto commit for manual/CI histories. Commits on the change branch are free (segmented or finalize single-shot).
 4. **Do not** commit live specs to the default branch just to satisfy the clean-tree gate; if already attached, do not re-run `start`.

package/templates/en/units/skills/stage-guard.md

@@ -3,7 +3,7 @@
 Decide from authoritative JSON (never from vague "complete artifacts" wording):
 
 ```bash
-llman sdd show <id> --json --type change
+llman-sdd show <id> --json --type change
 ```
 
 Read: `stage`, `specsLanded`, `needsSpecsChange`, `readyToImplement`, `gateChecks` (per-item `pass` + one-line `hint` when failing).

package/templates/en/units/skills/structured-protocol.md

@@ -1,6 +1,6 @@
 ## Context
-- Check state before acting: change/spec status comes from `llman sdd show/list/validate` output.
-- Locate relevant specs with `llman sdd context --task --paths` before reading spec files.
+- Check state before acting: change/spec status comes from `llman-sdd show/list/validate` output.
+- Locate relevant specs with `llman-sdd context --task --paths` before reading spec files.
 
 ## Goal
 - Reach one verifiable outcome for this command; report result paths and validation state.
@@ -10,8 +10,8 @@
 - Keep changes minimal; never force past a known validation failure.
 
 ## Workflow
-- Treat `llman sdd` command output as the source of truth at every step; run `llman sdd validate` after touching artifacts.
-- Command details: the generated command reference below, or `llman sdd <cmd> --help`.
+- Treat `llman-sdd` command output as the source of truth at every step; run `llman-sdd validate` after touching artifacts.
+- Command details: the generated command reference below, or `llman-sdd <cmd> --help`.
 
 ## Decision Policy
 - Clarify high-impact ambiguity before proceeding; verify facts yourself, ask the user only for decisions.
@@ -22,6 +22,6 @@
 ## Ethics Governance
 - `ethics.risk_level`: low — reads/writes this repo and `llmanspec/` only, no outward-facing actions; a skill body may override.
 - `ethics.prohibited_actions`: actions violating the skill body's hard rules; push / PR / external upload without an explicit user request.
-- `ethics.required_evidence`: conclusions backed by command output or file paths; gate state per `llman sdd validate`.
+- `ethics.required_evidence`: conclusions backed by command output or file paths; gate state per `llman-sdd validate`.
 - `ethics.refusal_contract`: gate CRITICAL not cleared → refuse to advance; self-repair cap reached → report a blocker.
 - `ethics.escalation_policy`: pause and ask the user before changing SDD contracts/templates or irreversible actions.

package/templates/en/units/skills/validation-hints.md

@@ -15,10 +15,10 @@ Every capability `.feature` (`llmanspec/specs/<capability>.feature` or `llmanspe
 - `@manual` requires `@human`. Never combine `@human` with `@executable`.
 
 3) Legacy `spec.toon` present (`legacy spec.toon found ... run ... toon2features`):
-Run `llman sdd project migrate --kind toon2features --yes`, review the diff, commit.
+Run `llman-sdd project migrate --kind toon2features --yes`, review the diff, commit.
 
 Git-native guardrail:
 - **Branch binding** → **Specs landing**: first `change start` / `attach`, then edit live `.feature` files on the bound non-default branch and commit.
-- Locked rules (report-only): editing/removing an existing `@human` scenario yields a WARNING and never blocks validate / change finalize / change diff; the report names the edited rule by `@req:<id>`. Control points: git branch diff plus `llman sdd review` / `change diff` output. Legacy lock-ack metadata (frontmatter `rules_touched` / `agent_acked`, the `@agent` tag, the `--yes` ack semantics) is fully removed — no aliases, no compat layer (locked rules are report-only: a warning, never a block).
+- Locked rules (report-only): editing/removing an existing `@human` scenario yields a WARNING and never blocks validate / change finalize / change diff; the report names the edited rule by `@req:<id>`. Control points: git branch diff plus `llman-sdd review` / `change diff` output. Legacy lock-ack metadata (frontmatter `rules_touched` / `agent_acked`, the `@agent` tag, the `--yes` ack semantics) is fully removed — no aliases, no compat layer (locked rules are report-only: a warning, never a block).
 - Apply requires `readyToImplement=true` (or `needs_specs_change: false`). Close-out prefers `change finalize`.
 - Do not use `change delta` / solidify / `*.feature.delta.toon`.

package/templates/en/units/workflow/archive-freeze-guidance.md

@@ -1,6 +1,6 @@
 ## Archive Cold Backup Guidance
 - If archived directories are growing too large, use cold backup maintenance:
-  - Preview freeze candidates: `llman sdd archive freeze --dry-run`
-  - Freeze old archives: `llman sdd archive freeze --before <YYYY-MM-DD> --keep-recent <N>`
-  - Restore when needed: `llman sdd archive thaw --change <YYYY-MM-DD-id>`
+  - Preview freeze candidates: `llman-sdd archive freeze --dry-run`
+  - Freeze old archives: `llman-sdd archive freeze --before <YYYY-MM-DD> --keep-recent <N>`
+  - Restore when needed: `llman-sdd archive thaw --change <YYYY-MM-DD-id>`
 - Apply freeze/thaw only to dated archive directories (`YYYY-MM-DD-*`) and keep a small recent window unfrozen when possible.

package/templates/shared/review.html

@@ -2,7 +2,7 @@
 <html lang="en">
 <head>
 <meta charset="utf-8">
-<title>llman sdd review — __GENERATED__</title>
+<title>llman-sdd review — __GENERATED__</title>
 <style>
   body { font-family: system-ui, sans-serif; margin: 2rem; }
   .critical { color: #b91c1c; font-weight: 700; }
@@ -13,7 +13,7 @@
 </style>
 </head>
 <body>
-<h1>llman sdd review</h1>
+<h1>llman-sdd review</h1>
 <p>critical=<span class="critical">__CRITICAL__</span>
    warning=<span class="warning">__WARNING__</span></p>
 <h2>Signals</h2>

package/templates/zh-Hans/agents-root-stub.md

@@ -6,4 +6,4 @@
 
 使用 `/llman-sdd-explore` 开始，然后按照 pipeline：`/llman-sdd-propose` → `/llman-sdd-apply` → `/llman-sdd-verify` → `/llman-sdd-archive`。
 
-保留此托管块，便于 `llman sdd init --update` 刷新。
+保留此托管块，便于 `llman-sdd init --update` 刷新。

package/templates/zh-Hans/skills/llman-sdd-apply-cycle.md

@@ -16,13 +16,13 @@ disable-model-invocation: true
 
 ### 0) 门禁 + 状态
 ```bash
-llman sdd show <change-id> --json --type change
+llman-sdd show <change-id> --json --type change
 ```
-> 阶段判定：用 `llman sdd show <id> --json --type change` 的 `stage` / `readyToImplement` 字段；完整判定表见 llman-sdd-apply。
+> 阶段判定：用 `llman-sdd show <id> --json --type change` 的 `stage` / `readyToImplement` 字段；完整判定表见 llman-sdd-apply。
 
 - 须在绑定的非默认分支上。
 - `readyToImplement` 不为 true → STOP（先 Specs landing 或 `needs_specs_change: false`）；**不要**直接 finalize。
-- 进度以 `tasks.md` checkbox 为准（或 `llman sdd list` 的任务计数）；实现时仍须阅读 `tasks.md`、proposal/design 与绑定分支上的 live `llmanspec/specs/**`（SSOT）。
+- 进度以 `tasks.md` checkbox 为准（或 `llman-sdd list` 的任务计数）；实现时仍须阅读 `tasks.md`、proposal/design 与绑定分支上的 live `llmanspec/specs/**`（SSOT）。
 
 ### 1) 循环：实施 → 测试
 对每个未完成 task：
@@ -33,7 +33,7 @@ llman sdd show <change-id> --json --type change
 
 ### 2) 校验
 ```bash
-llman sdd validate <change-id> --strict --no-interactive
+llman-sdd validate <change-id> --strict --no-interactive
 ```
 失败则修复重试（自修复预算与 `llman-sdd-apply` 一致：上限 8 轮）。
 
@@ -42,7 +42,7 @@ llman sdd validate <change-id> --strict --no-interactive
 
 ### 4) 归档
 ```bash
-llman sdd change finalize <change-id>
+llman-sdd change finalize <change-id>
 ```
 （工作区可脏；自动合并（squash 缺省）+ 文档改名 + **自动提交** `archive(sdd): <change-id>` 单进程完成。`--no-commit` 跳过自动提交用于手动/CI 历史——此时自行 `git add -A && git commit -m "archive(sdd): <change-id>"`。）
 
@@ -71,5 +71,5 @@ push / Hosting PR 仅当用户明确要求。
 - `ethics.refusal_contract`: 门禁或校验自修复 8 轮仍失败 → 报告 blocker，禁止强行归档
 - `ethics.escalation_policy`: 若改动 SDD 工作流 spec/模板，归档前暂停请用户确认
 
-> 命令细节用 `llman sdd <cmd> --help` 查看；命令参考以 CLI 为准，skill 不内嵌命令表。
-> 文中「规约」= 本项目 `llmanspec/specs/` 下的 `.feature` 文件；用 `llman sdd list --specs` / `llman sdd show <capability>` 查全文。
+> 命令细节用 `llman-sdd <cmd> --help` 查看；命令参考以 CLI 为准，skill 不内嵌命令表。
+> 文中「规约」= 本项目 `llmanspec/specs/` 下的 `.feature` 文件；用 `llman-sdd list --specs` / `llman-sdd show <capability>` 查全文。