thoth-agents 0.2.11 → 0.3.1

package/src/skills/requirements-interview/SKILL.md

@@ -1,233 +0,0 @@
----
-name: requirements-interview
-description: Mandatory step-0 requirements discovery for non-trivial work before any implementation or SDD routing decisions.
-metadata:
-  author: thoth-agents
-  version: '1.0'
----
-
-# Requirements Interview Skill
-
-Use this skill as the mandatory step-0 entry point for non-trivial requests.
-The goal is requirement clarity, scope calibration, and a user-approved
-handoff path before implementation begins.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## HARD GATE
-
-- Do not implement during the requirements interview.
-- Do not write code.
-- Do not patch files.
-- Do not create formal SDD artifacts until the user approves the route.
-
-## Root Session Bootstrap
-
-This skill is normally loaded by the root/main orchestrator at the start of a
-new root session. When thoth-mem tools are available, the root/main
-orchestrator MUST also load `thoth-mem-agents`, call
-`mem_session(action="start")` with the active project and session identity,
-and save the real user prompt with `mem_save(kind="prompt")` before later
-delegation.
-
-If thoth-mem tools or the required identity values are unavailable, disclose
-that memory bootstrap could not run and continue without claiming memory was
-saved. Do not save subagent prompts, generated handoffs, or interview
-scaffolding as user prompts.
-
-## Blocking User Input Surface Requirement
-
-- The interview flow MUST use the active harness blocking user input surface
-  for user-input prompts.
-- Do not embed interview questions as plain prose in normal response text when
-  a blocking user input surface exists.
-- Prefer one focused blocking input call at a time for the core interview loop.
-- Use short headers (<=30 chars), concise option labels, and concrete
-  descriptions.
-- Put the recommended option first and include `(Recommended)` in that label.
-- Do not add an `Other` option manually when the active harness already adds or
-  supports custom input. Use the equivalent runtime option unless custom input
-  must be disabled.
-- Use multi-select only when multiple simultaneous selections are genuinely
-  valid. Use the equivalent runtime option if one exists.
-
-## Workflow
-
-### Phase 1: Discovery Context Gathering
-
-1. Always use the semantic explorer role for codebase context. Use the
-   semantic librarian role for external APIs, dependency versions, library
-   migration, or public documentation.
-2. Collect only the minimum context needed to improve questions and reduce
-   user repetition.
-3. Prefer facts from the codebase and known references over asking the user
-   for information the environment can answer.
-
-### Phase 2: Requirements Interview
-
-1. Ask each interview question through the blocking user input surface.
-2. Ask 1 blocking input call at a time.
-3. Ask at most 5 total questions.
-4. Prefer multiple-choice questions when practical.
-5. Stop early when clarity is already sufficient.
-6. Focus on what the user truly needs, not only the first phrasing of the
-   request.
-7. Surface unstated assumptions and validate them with the user.
-8. Guide the user toward potentially better options when appropriate, but never
-   impose a decision.
-9. Always ask and confirm; never choose on the user's behalf.
-10. Do not ask for details that the codebase, task artifacts, or gathered
-   context already answer.
-11. Enforce scope faithfulness: scope calibration must not silently shrink the
-    user's stated intent.
-12. Alignment note: a genuine decision fork left unresolved at interview is not
-    settled here — downstream it becomes either a `[NEEDS CLARIFICATION]`
-    marker or a recorded entry in the spec's `## Assumptions` section
-    (informed-guess-first). This note is alignment only; the interview does not
-    own the clarification cap or the Assumptions gate.
-
-### Phase 3: Complexity Assessment
-
-Evaluate these 6 dimensions. Rate each as **Low**, **Medium**, or **High**:
-
-| Dimension | Low | Medium | High |
-| --- | --- | --- | --- |
-| **Logic depth** | Copy, CSS, rename, simple wiring | Localized behavior tweak, validation, one workflow step | Algorithm, state-machine, or business-rule rewrite with many invariants |
-| **Contract sensitivity** | Presentation only, internal refactor | User-visible behavior change in one flow | API, schema, data model, migration, auth, privacy, or public contract |
-| **Context span** | Can be done in one bounded pass | Several dependent edits or choices to coordinate | Many sequential steps where earlier decisions must be remembered |
-| **Discovery need** | Request and acceptance criteria are already clear | Some ambiguity, a few viable approaches | Goal is clear but solution requires investigation or tradeoff analysis |
-| **Failure cost** | Mistakes are obvious and cheap to revert | Needs integration or regression checks | Subtle correctness bugs, customer-facing, data, or compliance impact |
-| **Concern coupling** | Single concern | Two related concerns | Multiple independent concerns that could conflict |
-
-### Phase 4: Approach Proposal
-
-1. Present 2-3 viable options as recommendations, not decisions.
-2. For each option, give the main trade-offs and when it is a good fit.
-3. Mark one option as the current recommendation and explain why.
-4. Use the active harness blocking user input surface to confirm the preferred
-   approach before moving on.
-
-### Phase 5: User Approval Gate
-
-Present:
-
-- Summary of understanding
-- Broad user intent and product goal
-- Accepted scope boundaries
-- Deferred or unresolved affected areas that still belong to the accepted goal
-- Explicit exclusions and why they are excluded
-- Scope classification and why
-- Recommended approach options
-- Proposed handoff path
-
-Then wait for explicit user confirmation.
-
-Use the active harness blocking user input surface for this approval gate.
-
-Nothing proceeds without explicit approval in this phase. The user is the sole
-approver during requirements discovery. Do not request oracle review here.
-
-### Phase 6: Handoff
-
-Recommend a route based on the complexity assessment, then wait for the
-user to confirm it:
-
-**Direct implementation** — when all of:
-- No dimensions rated High
-- At most one dimension rated Medium
-- Contract sensitivity is Low
-- Failure cost is Low
-
-**Accelerated SDD** (`sdd-explore -> propose -> tasks`) — when:
-- 2-3 dimensions are Medium, or
-- 1 dimension is High in logic depth, context span, or discovery need
-- But contract sensitivity and failure cost are not High
-
-**Full SDD** (`sdd-explore -> propose -> spec -> clarify -> design -> tasks`) — when any of:
-- Contract sensitivity is High
-- Failure cost is High
-- 2 or more dimensions are High
-- Discovery need is High and at least one other dimension is
-  Medium or High
-- Concern coupling is High with risk of conflicting decisions
-
-Quick decision heuristics:
-
-1. Cosmetic work routes direct regardless of file count.
-2. Dense logic rewrites route to at least accelerated SDD regardless
-   of file count.
-3. End-to-end UX redesign across screens/workflows is usually full SDD when
-   user-flow contracts, behavior contracts, or multiple concerns are involved.
-4. External contracts (API, schema, migration, auth, privacy) usually
-   need full SDD.
-5. If the model must remember decisions across many steps, write them
-   down — that means SDD.
-6. Tie-breaker: unsure between direct and accelerated, choose
-   accelerated. Unsure between accelerated and full, ask: 'Do we
-   need a durable behavior contract?' If yes, full SDD.
-
-Before any SDD generation starts, present the artifact store policy choice:
-
-```text
-How would you like to persist planning artifacts?
-1. none — No persistence. Ephemeral exploration, privacy-sensitive work, or when no backend is available. Results are inline only and not saved across sessions.
-2. thoth-mem — Memory only. Lightest token cost. No repo files.
-3. openspec — Repo files only. Visible and reviewable.
-4. hybrid — Both. Maximum durability, higher token cost.
-Default: hybrid
-```
-
-Collect this choice with the active blocking user input surface rather than
-plain prose.
-
-When the user selects a mode that includes OpenSpec (`openspec` or `hybrid`),
-verify that `openspec/` is initialized AND not stale. If it is not initialized,
-or it exists but is stale (`config.yaml` missing one or more mechanism sections
-/ toggles, or `openspec/memory/constitution.md` absent), recommend running the
-`sdd-init` skill before proceeding so it can additively realign the project.
-
-Once route, persistence mode, and initialization are confirmed, hand off to the
-corresponding SDD pipeline phase. The handoff MUST include:
-- `pipeline-type`: `accelerated` or `full` (matching the confirmed route)
-- `persistence-mode`: the user's chosen artifact store mode
-- `change-name`: derived from the approved scope
-
-Hand off to:
-
-- **Explore**: delegate read-only repository discovery to explorer before artifact-producing phases.
-- **Propose**: [../sdd-propose/SKILL.md](../sdd-propose/SKILL.md)
-- **Spec** (full SDD only): [../sdd-spec/SKILL.md](../sdd-spec/SKILL.md)
-- **Clarify** (full SDD only): [../sdd-clarify/SKILL.md](../sdd-clarify/SKILL.md)
-- **Design** (full SDD only): [../sdd-design/SKILL.md](../sdd-design/SKILL.md)
-- **Tasks**: [../sdd-tasks/SKILL.md](../sdd-tasks/SKILL.md)
-
-Do not silently choose the handoff route or artifact store mode. Recommend,
-ask, and wait.
-
-## Guardrails
-
-- Maximum 5 interview questions.
-- Ask only one blocking input call at a time.
-- Do not ask what codebase context can answer.
-- Do not skip explicit user approval.
-- Do not auto-select the handoff route.
-- Do not auto-select the persistence mode.
-- Never convert recommendations into unilateral decisions.
-- Do not replace blocking input prompts with plain-text interview questions
-  when the harness exposes a blocking user input surface.
-- Do not narrow accepted scope by omission; surface broad intent, accepted
-  scope, deferred or unresolved affected areas, and explicit exclusions before
-  SDD handoff.
-
-## Anti-Patterns
-
-- Question dumping
-- Option inflation
-- Premature implementation
-- Silent route selection
-- Silent persistence-mode selection
-- Treating discovery as optional

package/src/skills/sdd-apply/SKILL.md

@@ -1,89 +0,0 @@
----
-name: sdd-apply
-description: Execute assigned SDD tasks and return structured implementation results.
----
-
-# SDD Apply Skill
-
-Implement assigned SDD tasks and return durable execution results to the
-orchestrator.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Persistence Mode
-
-The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
-`hybrid`). Follow the persistence contract for read/write rules per mode.
-
-- `thoth-mem`: persist to thoth-mem only — do NOT create or modify
-  `openspec/` files.
-- `openspec`: write files only — do NOT call thoth-mem save tools.
-- `hybrid`: persist to both (default).
-
-## When to Use
-
-- A change has a task plan and implementation should begin or resume
-- A batch of checklist items must be executed and reported back to the
-  orchestrator
-
-## Prerequisites
-
-- `change-name`
-- `pipeline-type` (`accelerated` or `full`)
-- Assigned task numbers or phase range
-- Task artifact
-- Spec and design artifacts (full pipeline only)
-- Proposal artifact (accelerated pipeline — used as the acceptance reference)
-
-## Workflow
-
-1. Read the shared conventions.
-2. Recover artifacts with the retrieval protocol in
-   the persistence contract:
-   - **Always**: recover `tasks`
-   - **Full pipeline**: recover `spec` and `design`
-   - **Accelerated pipeline**: recover `proposal` (used as the acceptance reference)
-3. Read the affected code before editing anything.
-4. Execute only the assigned checklist items.
-5. In modes that include thoth-mem, persist an implementation progress report
-   with:
-
-   Use the memory tool binding for `mem_save` with the canonical SDD topic key
-   and required metadata fields: `title`, `topic_key`, `type`, `project`,
-   `scope`, and `content`.
-
-6. If the orchestrator requests it, include enough detail for it to update the
-   canonical tasks artifact and memory checkpoints accurately.
-
-## Response Format
-
-Return a structured result to the orchestrator using the Task Result envelope:
-
-**Status**: completed | failed | partial
-**Task**: {task reference}
-
-**What was done**: concrete list of changes
-**Files changed**: paths with descriptions
-**Verification**: check results (passed/failed)
-**Issues**: problems encountered with severity
-**Failure/Skip reason**: if applicable
-
-Progress tracking (checkbox state updates) is managed by the orchestrator
-via the harness-bound progress workflow in the `executing-plans` skill. Do not
-update task checkboxes yourself.
-
-## Rules
-
-- Read the acceptance contract before implementing: specs in full pipeline,
-  proposal in accelerated pipeline.
-- Follow the design unless you explicitly report a justified deviation.
-- Update only the tasks assigned in the current batch.
-- Persist the progress artifact whenever the selected mode includes thoth-mem.
-- Retrieve every SDD dependency with the mode-aware protocol in the
-  persistence contract.
-- Return structured execution evidence to the orchestrator so it can manage task
-  state correctly.

package/src/skills/sdd-archive/SKILL.md

@@ -1,92 +0,0 @@
----
-name: sdd-archive
-description: Merge completed deltas into main specs and archive the change.
----
-
-# SDD Archive Skill
-
-Close the SDD loop by promoting verified change specs into main specs and
-recording an audit trail.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Persistence Mode
-
-The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
-`hybrid`). Follow the persistence contract for read/write rules per mode.
-
-- `thoth-mem`: persist to thoth-mem only — do NOT create or modify
-  `openspec/` files.
-- `openspec`: write files only — do NOT call thoth-mem save tools.
-- `hybrid`: persist to both (default).
-
-## When to Use
-
-- The change has an acceptable verification report and is ready to close
-- An archive attempt must be retried after an interrupted move or merge
-
-## Prerequisites
-
-- `change-name`
-- `pipeline-type` (`accelerated` or `full`)
-- Tasks artifact
-- Verify report artifact
-- Spec artifact (full pipeline only)
-- Design artifact (full pipeline only)
-- Proposal artifact (always — used for audit trail)
-
-## Workflow
-
-1. Read the shared conventions.
-2. Recover artifacts through the retrieval protocol in
-   the persistence contract:
-   - **Always**: recover `proposal`, `tasks`, and `verify-report`
-   - **Full pipeline only**: recover `spec` and `design`
-3. Refuse to archive if the verification report still contains unresolved
-   critical failures.
-4. If the selected mode includes OpenSpec and the pipeline is full, merge
-   every change spec from
-   `openspec/changes/{change-name}/specs/{domain}/spec.md` into
-   `openspec/specs/{domain}/spec.md`. In accelerated pipeline, skip the
-   spec merge (no delta specs exist).
-5. If the selected mode includes OpenSpec, move the completed change directory
-   to `openspec/changes/archive/YYYY-MM-DD-{change-name}/`.
-6. Create an audit trail report summarizing merged domains, archive location,
-   verification lineage, and any mode-based skips.
-7. Apply the governance-touched heuristic from
-   `_shared/openspec-convention.md` > Constitution Governance > Amendment
-   Auto-Suggest. When it matches, surface the shared report-only
-   `sdd-constitution` suggestion. This is advisory and MUST NOT block archival.
-8. In `thoth-mem` mode, do not create or move `openspec/` artifacts; record the
-   archive result only in the audit trail.
-9. If the selected mode includes thoth-mem, persist the audit trail with:
-
-   Use the memory tool binding for `mem_save` with the canonical SDD topic key
-   and required metadata fields: `title`, `topic_key`, `type`, `project`,
-   `scope`, and `content`.
-
-## Output Format
-
-Return:
-
-- `Change`
-- `Archive Path`: `openspec/changes/archive/YYYY-MM-DD-{change-name}/`
-- `Topic Key`: `sdd/{change-name}/archive-report`
-- `Merged Specs`: list of domains updated in `openspec/specs/`
-- `Audit Summary`: concise bullets
-- `Constitution Suggestion`: surfaced or none
-- `Status`: archived or blocked
-
-## Rules
-
-- Archive only after verification is acceptable.
-- In full pipeline, merge delta specs before moving the change folder.
-  In accelerated pipeline, skip the spec merge (no delta specs exist).
-- Preserve canonical spec structure and untouched requirements.
-- Persist the final audit trail through thoth-mem when the selected mode
-  includes it.
-- Use the retrieval protocol in the persistence contract for every dependency.

package/src/skills/sdd-clarify/SKILL.md

@@ -1,105 +0,0 @@
----
-name: sdd-clarify
-description: Resolve residual spec ambiguity in place before design, with a bounded taxonomy-driven clarification pass.
----
-
-# SDD Clarify Skill
-
-Resolve residual ambiguity that survives `sdd-spec` by writing clarified
-resolutions back into the authoritative delta spec, before `sdd-design`
-consumes it.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Persistence Mode
-
-The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
-`hybrid`). Follow the persistence contract for read/write rules per mode.
-
-- `thoth-mem`: persist to thoth-mem only — do NOT create or modify
-  `openspec/` files.
-- `openspec`: write files only — do NOT call thoth-mem save tools.
-- `hybrid`: persist to both (default).
-
-## When to Use
-
-- The delta specs are authored and residual ambiguity (unresolved
-  `[NEEDS CLARIFICATION]` markers or taxonomy-classified gaps) must be resolved
-  before design.
-- A `full` SDD pipeline run reaches the `clarify` phase between `spec` and
-  `design`. The phase is full-pipeline only; accelerated and direct pipelines
-  skip it.
-
-## Prerequisites
-
-- `change-name`
-- The spec artifact must exist (recoverable under `sdd/{change-name}/spec`).
-- `openspec/changes/{change-name}/checklists/requirements.md` must exist.
-
-## Workflow
-
-1. Read the shared conventions.
-2. Recover `sdd/{change-name}/spec` using the recall funnel in the persistence
-   contract (`mem_recall(mode="compact")` -> `mem_recall(mode="context")` ->
-   `mem_get(...)`), and read the delta spec file(s) under
-   `openspec/changes/{change-name}/specs/{domain}/spec.md`.
-3. **Taxonomy scan** — scan the recovered spec against the ambiguity taxonomy to
-   produce resolution candidates:
-   - ambiguous quantifiers (e.g. "fast", "several", "most")
-   - undefined terms (domain nouns with no pinned meaning)
-   - missing error/edge behavior (no failure/edge path specified)
-   - unresolved decision forks (competing options with no default)
-   - underspecified data shapes (fields, types, or cardinality not pinned)
-   - unstated non-functional bounds (latency, size, concurrency, limits)
-   - plus every unresolved `[NEEDS CLARIFICATION]` marker already in the spec.
-4. **Bounded Q&A** — resolve candidates capped at
-   `rules.clarification.max_markers_per_spec` (default 3) per spec file. With
-   more than the cap, resolve at most the cap's worth, prioritizing the
-   highest-impact ambiguities; leave the rest as explicit markers for a later
-   pass. Prefer an informed-guess default recorded in `## Assumptions` over a
-   blocking question when a defensible default exists.
-5. **Write-back in place** — replace each resolved `[NEEDS CLARIFICATION]`
-   marker / ambiguous statement with its resolved decision directly in the same
-   delta spec file(s) (inline, or folded into the spec's `## Assumptions`
-   section when the resolution is a recorded default). Do NOT create a new
-   artifact (`clarifications.md`, `spec-clarified.md`, etc.). In
-   `hybrid`/`thoth-mem` mode, re-save the edited spec under the SAME canonical
-   key `sdd/{change-name}/spec` (upsert) — no `spec-clarified` key.
-6. **Re-validate** `openspec/changes/{change-name}/checklists/requirements.md`
-   against the clarified spec: flip items that were waived or open due to a
-   now-resolved ambiguity, and declare `handoffHints` for design (the resolved
-   decisions and the re-validated checklist state design must preserve). Do not
-   advance past design with an unresolved checklist.
-
-## Boundary
-
-`sdd-clarify` targets only **post-spec residual** ambiguity. It MUST NOT
-re-run or duplicate the upfront `requirements-interview`, and MUST NOT re-ask
-questions already resolved during requirements discovery. It edits only the
-spec and its requirements checklist; it produces no new permanent artifact.
-
-## Output Format
-
-Return:
-
-- `Change`
-- `Artifact`: clarified delta spec path(s) (edited in place)
-- `Topic Key`: `sdd/{change-name}/spec`
-- `Resolved`: list of ambiguities resolved (marker/taxonomy class -> resolution)
-- `Next Step`: `sdd-design`
-
-## Rules
-
-- Write resolutions back into the authoritative spec in place; never leave a
-  resolved ambiguity standing as unresolved.
-- Reuse the canonical `sdd/{change-name}/spec` topic key (upsert); introduce no
-  new artifact or key.
-- Cap resolutions at `rules.clarification.max_markers_per_spec` per spec file.
-- Re-validate `checklists/requirements.md` before handing off to design.
-- Do not duplicate `requirements-interview`; resolve only residual post-spec
-  ambiguity.
-- Use the recall funnel from the persistence contract for every SDD dependency.

package/src/skills/sdd-constitution/SKILL.md

@@ -1,107 +0,0 @@
----
-name: sdd-constitution
-description: Guide a semver constitution amendment and Sync-Impact Report entry.
-metadata:
-  author: thoth-agents
-  version: 1.0.0
----
-
-# SDD Constitution Skill
-
-Perform a guided, human-confirmed amendment of `openspec/memory/constitution.md`
-ONLY — a semver version bump, an updated `Last-Amended` date, and one prepended
-`## Sync-Impact Report` entry. This skill closes the constitution lifecycle by
-adding its AMENDMENT side; it never edits any other bundled asset.
-
-## Shared Conventions
-
-- [../_shared/openspec-convention.md](../_shared/openspec-convention.md)
-- [../_shared/persistence-contract.md](../_shared/persistence-contract.md)
-- [../_shared/thoth-mem-convention.md](../_shared/thoth-mem-convention.md)
-
-## Persistence Mode
-
-The orchestrator passes the artifact store mode (`thoth-mem`, `openspec`, or
-`hybrid`). Follow the persistence contract for read/write rules per mode.
-
-- `thoth-mem`: record the amendment as a governance observation only — do NOT
-  create or modify `openspec/` files.
-- `openspec`: write `openspec/memory/constitution.md` only — do NOT call
-  thoth-mem save tools.
-- `hybrid`: do both — write the file AND record the governance observation
-  (default).
-
-## When to Use
-
-- A native principle must be added, redefined, removed, or its guidance
-  materially expanded or clarified, and the constitution must record it.
-- A report-only suggestion from `sdd-verify` or `sdd-archive` flagged a
-  completed change as governance-touching and a human chooses to record an
-  amendment.
-
-## Prerequisites
-
-- An existing `openspec/memory/constitution.md` (bootstrapped by `sdd-init`).
-- A human-described principle change (what changed and why).
-- `change-name` — OPTIONAL context only; the skill may run standalone and is not
-  a per-change pipeline phase.
-- Selected persistence mode (default: `hybrid`).
-
-## Workflow
-
-1. Read the shared conventions, especially `openspec-convention.md` >
-   Constitution Governance (amendment doctrine, read-only-asset rules, and the
-   Sync-Impact Report entry format).
-2. Load `openspec/memory/constitution.md` and read its `Version:`, `Ratified:`,
-   `Last-Amended:` header fields and the existing `## Sync-Impact Report`
-   section. If the file is absent, instruct the user to run `sdd-init` first;
-   do NOT create the constitution here.
-3. Determine the principle change from the human description. If no principle
-   change is warranted, report a no-op and stop — write nothing.
-4. Classify the bump per policy: MAJOR = a principle is removed or redefined;
-   MINOR = a principle is added or guidance materially expanded; PATCH =
-   clarification or wording with no behavioral change. Present the
-   classification for confirmation via the harness blocking-input surface
-   (AskUserQuestion-equivalent). Do NOT write any version bump before the user
-   confirms, and NEVER use a runtime parser to auto-select the bump.
-5. Apply the amendment to `openspec/memory/constitution.md` ONLY: bump the
-   `Version:` field, set `Last-Amended:` to the current date, and PREPEND
-   exactly one entry to the top of the `## Sync-Impact Report` section in the
-   canonical format
-   `- X.Y.Z | change type | principles touched | downstream gates/artifacts affected`.
-   Preserve all existing content and ALL prior Sync-Impact Report entries.
-6. Emit REPORT-ONLY impact: name the live-read consuming gates (`sdd-design`,
-   `plan-reviewer`) in the Sync-Impact entry, and FLAG any in-flight change
-   `openspec/changes/{name}/design.md` or `tasks.md` that reference now-changed
-   principles for HUMAN re-review. Do NOT edit those artifacts or any other
-   bundled asset.
-7. Persist per the selected mode: in modes that include OpenSpec write the
-   constitution file; in modes that include thoth-mem record a governance
-   observation per the persistence contract.
-
-## Output Format
-
-Return:
-
-- `Constitution Version`: old `X.Y.Z` -> new `X.Y.Z` (or unchanged on no-op)
-- `Bump`: MAJOR, MINOR, PATCH, or no-op
-- `Sync-Impact Entry`: the single prepended line (or none on no-op)
-- `Consuming Gates`: live-read gates that consume the changed principles
-  (e.g. `sdd-design`, `plan-reviewer`)
-- `In-Flight Artifacts Flagged`: change `design.md` / `tasks.md` flagged for
-  human re-review, or none
-- `Files Written`: `openspec/memory/constitution.md` only, or none
-- `Status`: amended or no-op
-
-## Rules
-
-- NEVER edit, create, or delete any other `SKILL.md`, any file under `src/`, or
-  any bundled/template asset — the ONLY writable target is
-  `openspec/memory/constitution.md`.
-- NEVER auto-bump: there is no runtime parser, and no `Version:` change is
-  written without explicit human confirmation via the blocking-input surface.
-- No-op when no principle change is warranted: report it and write nothing.
-- Preserve all existing constitution content and ALL prior `## Sync-Impact
-  Report` entries; only PREPEND the new entry and update the version/date.
-- Propagation is report-only: document the consuming gates and flag in-flight
-  change artifacts for human re-review; NEVER auto-fix them.