@uniqbit/mate-core 0.18.4 → 1.0.0-canary.0

package/src/templates/capabilities/openspec-cap/mate-minimal/schema.yaml

@@ -1,5 +1,5 @@
 name: mate-minimal
-version: 3
+version: 4
 description: Mate's short OpenSpec workflow for one-Area, low-risk changes - specs → tasks
 artifacts:
   - id: specs
@@ -27,11 +27,13 @@ artifacts:
         include **Reason** and **Migration**.
 
       Every user story carries an **Area:** marker naming the Areas it binds, using values from
-      the frontmatter scopes - always, even when there is only one Area.
+      the `scopes` in the spec's `mate:delta` comment - always, even when there is only one Area.
 
-      **Obsidian**: Emit YAML frontmatter with `type: delta-spec`, the actual change name, the
-      capability, the `openspec/change`, `openspec/spec`, and `openspec/delta` tags, and paired
-      `scopes` metadata.
+      Start each spec file with a `<!-- mate:delta` comment on its very first line, not YAML
+      frontmatter. The comment holds YAML with the actual change name as `change`, the
+      `capability`, and paired `scopes` metadata, and closes with `-->` on its own line. Between
+      the comment and the first `## ` section, put nothing but blank lines and at most one `# `
+      title line, or `openspec validate --strict` reports the text archive would drop.
     requires: []
   - id: tasks
     generates: tasks.md
@@ -39,7 +41,7 @@ artifacts:
     template: tasks.md
     instruction: |
       Create a flat implementation checklist that satisfies the delta specs. Keep it short: this
-      profile uses the shared `/openspec-explore` and `/openspec-propose` planning steps but
+      profile uses the shared `/mate-explore-change` and `/mate-propose-change` planning steps but
       intentionally writes no explore, proposal, or design artifact.
 
       Number tasks `N.M` and group them under `## N. <group>` headers so apply tracking can address them individually.

package/src/templates/capabilities/openspec-cap/mate-minimal/templates/spec.md

@@ -1,12 +1,10 @@
----
-type: delta-spec
+<!-- mate:delta
 change: <change-name>
 capability: <capability>
-tags: [openspec/change, openspec/spec, openspec/delta]
 scopes:
   - repository: org/repository
     area: .
----
+-->
 
 ## ADDED Requirements
 
@@ -16,7 +14,7 @@ As a <!-- role -->, I want <!-- capability -->, so that <!-- benefit -->.
 The system MUST support this behavior.
 **Area:** `.` <!-- replace with the Area from scopes -->
 
-<!-- Every requirement must bind an Area from the frontmatter scopes. -->
+<!-- Every requirement must bind an Area from the `mate:delta` scopes. -->
 
 #### Acceptance Criteria
 

package/src/templates/capabilities/openspec-cap/mate-v1/schema.yaml

@@ -1,5 +1,5 @@
 name: mate-v1
-version: 9
+version: 10
 description: Mate's complete OpenSpec workflow - proposal → specs → design → tasks
 artifacts:
   - id: proposal
@@ -74,7 +74,7 @@ artifacts:
       - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently.
       - Every requirement MUST have at least one scenario.
 
-      New capabilities only: after the frontmatter and backlink lines, start the delta spec body with a `## Purpose` section - one or two sentences (50+ characters, or `openspec validate --strict` reports it as too brief) describing what the capability is for. Archive copies it into the main spec it creates; without it the new main spec is left with a `TBD ... Update Purpose after archive.` placeholder to fill in by hand. Do NOT add `## Purpose` to a delta for an existing capability - that spec already has one and the delta's is ignored. To change an existing capability's Purpose - including a leftover `TBD` placeholder - edit `openspec/specs/<capability>/spec.md` directly.
+      New capabilities only: after the `mate:delta` comment and any `#` title, start the delta spec body with a `## Purpose` section - one or two sentences (50+ characters, or `openspec validate --strict` reports it as too brief) describing what the capability is for. Archive copies it into the main spec it creates; without it the new main spec is left with a `TBD ... Update Purpose after archive.` placeholder to fill in by hand. Do NOT add `## Purpose` to a delta for an existing capability - that spec already has one and the delta's is ignored. To change an existing capability's Purpose - including a leftover `TBD` placeholder - edit `openspec/specs/<capability>/spec.md` directly.
 
       MODIFIED requirements workflow:
       1. Locate the existing requirement in `openspec/specs/<capability>/spec.md`.
@@ -84,7 +84,7 @@ artifacts:
 
       Common pitfall: Using MODIFIED with partial content loses detail at archive time. If adding new concerns without changing existing behavior, use ADDED instead.
 
-      Example (frontmatter scopes cover `acme` and `packages/api`; every requirement carries an `**Area:**` marker, as always — the first binds both, the second one):
+      Example (scope metadata covers `acme` and `packages/api`; every requirement carries an `**Area:**` marker, as always — the first binds both, the second one):
 
       ```
       ## ADDED Requirements
@@ -107,21 +107,19 @@ artifacts:
 
       Specs should be testable - each scenario is a potential test case.
 
-       **Obsidian**: Emit this YAML frontmatter at the very top of each spec file. Replace `<change-name>`, `<repository>`, `<area>`, and `<capability>` with actual values. Each `scopes` entry MUST preserve its repository/Area pairing:
+      **Obsidian**: Start each spec file with this `mate:delta` comment as its very first line, not YAML frontmatter. Replace `<change-name>`, `<repository>`, `<area>`, and `<capability>` with actual values. Each `scopes` entry MUST preserve its repository/Area pairing:
 
       ```
-      ---
-      type: delta-spec
+      <!-- mate:delta
       change: <change-name>
       capability: <capability>
-      tags: [openspec/change, openspec/spec, openspec/delta]
       scopes:
         - repository: org/repository
           area: .
-      ---
+      -->
       ```
 
-      After the file's `#` title line, add a backlink on the next line: `← [[proposal]]`. If modifying an existing main spec, add on the line after: `Applies to: [[openspec/specs/<capability>/spec]]`.
+      Between the comment and the first `## ` section, put nothing but blank lines and at most one `# ` title line. OpenSpec skips the comment and the title, but `openspec validate --strict` reports any other text there, because archive drops it, so add no backlink or cross-reference lines.
 
       Canonical-spec shape, delta-to-canonical projection, and migration rules live in
       `openspec/mate-conventions.yaml`. Follow that reference when creating or repairing

package/src/templates/capabilities/openspec-cap/mate-v1/templates/spec.md

@@ -1,12 +1,10 @@
----
-type: delta-spec
+<!-- mate:delta
 change: <change-name>
 capability: <capability>
-tags: [openspec/change, openspec/spec, openspec/delta]
 scopes:
   - repository: org/repository
     area: .
----
+-->
 
 ## Purpose
 
@@ -17,7 +15,7 @@ scopes:
 ### Requirement: <!-- requirement name -->
 
 <!-- Write the normative requirement. EVERY requirement carries an **Area:** marker from the
-frontmatter scopes, for example **Area:** `packages/ui`. No **Repository:** marker is ever used.
+`mate:delta` scopes, for example **Area:** `packages/ui`. No **Repository:** marker is ever used.
 See openspec/mate-conventions.yaml for shared scope and canonical-spec rules. -->
 
 #### Scenario: <!-- scenario name -->

package/src/templates/capabilities/openspec-cap/openspec-conventions.yaml

@@ -2,17 +2,17 @@ name: mate-openspec-conventions
 version: 1
 description: Shared scope, frontmatter, delta, and canonical-spec rules for Mate schemas.
 rules: |
-  - Every change artifact MUST name at least one paired repository and area in its frontmatter scopes list.
-  - Repository identity comes from the Git remote. Normalize SSH and HTTPS forms such as git@github.com:org/repository.git and https://github.com/org/repository.git to org/repository.
+  - Every change artifact MUST name at least one paired repository and area in its scopes list: a delta spec in its mate:delta comment, every other change artifact in its frontmatter.
+  - Repository identity comes from the Git remote: its full path on the host, without host, credentials, or .git. Normalize SSH and HTTPS forms such as git@github.com:org/repository.git and https://github.com/org/repository.git to org/repository; keep every nested group, so git@gitlab.example.com:group/subgroup/repository.git becomes group/subgroup/repository.
   - In a monorepo, an Area is the owning workspace or package root: the directory containing the nearest package manifest (package.json, Cargo.toml, go.mod, and similar). A non-monorepo may use the exact affected path and uses . only when the repository root is affected.
   - Do not use a local checkout basename, internal repository ID, synthetic Area, or N/A as durable metadata.
   - Preserve each repository/Area pair. Never use separate repositories and areas arrays.
   - Default a new capability to one owning package root. Use one capability per repository when a change crosses repositories. A capability spec names exactly one repository, although a change may name several.
-  - Area identity comes only from frontmatter. Capability and change folder names are descriptive and have no scope authority.
-  - A delta lives at openspec/changes/<name>/specs/<capability>/spec.md.
+  - Area identity comes only from frontmatter or a delta's mate:delta comment. Capability and change folder names are descriptive and have no scope authority.
+  - A delta lives at openspec/changes/<name>/specs/<capability>/spec.md. It starts with a mate:delta comment, never YAML frontmatter, and holds nothing but blank lines and at most one # title line between that comment and its first ## section; openspec validate --strict reports any other text there.
   - A canonical spec lives at openspec/specs/<capability>/spec.md. The archive command merges delta requirement blocks into this durable file.
   - OpenSpec parses only ## ADDED Requirements, ## MODIFIED Requirements, ## REMOVED Requirements, and ## RENAMED Requirements. Every parsed requirement starts with ### Requirement:. Do not substitute User Stories in these headers.
-  - Every requirement MUST carry an Area marker whose values appear in the delta frontmatter. This survives archive, which copies requirement blocks but discards delta frontmatter.
+  - Every requirement MUST carry an Area marker whose values appear in the delta's mate:delta comment. This survives archive, which copies requirement blocks but discards the mate:delta comment.
   - A canonical spec uses flat frontmatter: type: spec, capability, scalar repository, areas list, and tags: [openspec/spec]. It MUST NOT retain a nested scopes list or delta-only change and delta tags.
   - To project a delta, all its scope entries MUST name the same repository. Emit that repository as the canonical scalar and distinct Areas as areas in their original order. If repositories differ, split the capability before archive.
 verification: |
@@ -20,16 +20,14 @@ verification: |
   - mate-react-doctor: when writing tasks, end the task list of every Area whose tasks change React code (components, hooks, or other .tsx/.jsx modules) with one verification task, numbered like its neighbours, for example `- [ ] N.M Verify React changes with React Doctor [skill:mate-react-doctor]`. Areas whose tasks do not change React code get no verification task.
   - During apply, a tagged verification task is worked like any other task by invoking its skill.
   - Before reporting a change complete, check every Area that changed React code: if its tagged verification task is already checked, do nothing more; otherwise invoke the skill once for that Area.
-example_delta_frontmatter: |
-  ---
-  type: delta-spec
+example_delta_metadata: |
+  <!-- mate:delta
   change: <change-name>
   capability: <capability>
-  tags: [openspec/change, openspec/spec, openspec/delta]
   scopes:
     - repository: org/repository
       area: .
-  ---
+  -->
 notes:
-  - "Change frontmatter uses paired scopes. Canonical frontmatter uses flat repository and areas scalars instead."
-  - "Do not add a ## Scopes body section; frontmatter is the only source of scope identity."
+  - "Change frontmatter and the delta mate:delta comment use paired scopes. Canonical frontmatter uses flat repository and areas scalars instead."
+  - "Do not add a ## Scopes body section; frontmatter and the mate:delta comment are the only sources of scope identity."

package/src/templates/mate-skills/THIRD-PARTY-NOTICES.md

@@ -0,0 +1,40 @@
+# Third-Party Notices
+
+The following files contain workflow text from OpenSpec 1.15.0
+(https://github.com/Fission-AI/OpenSpec), with command references rewritten to
+the matching Mate skills:
+
+- `claude/mate-explore-change/references/openspec-explore.md`
+- `claude/mate-propose-change/references/openspec-propose.md`
+- `claude/mate-apply-change/references/openspec-apply-change.md`
+- `claude/mate-propose-change/references/openspec-update-change.md`
+- `agents/mate-explore-change/references/openspec-explore.md`
+- `agents/mate-propose-change/references/openspec-propose.md`
+- `agents/mate-apply-change/references/openspec-apply-change.md`
+- `agents/mate-propose-change/references/openspec-update-change.md`
+
+OpenSpec is distributed under this license:
+
+```text
+MIT License
+
+Copyright (c) 2024 OpenSpec Contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```

package/src/templates/mate-skills/agents/mate-apply-change/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: mate-apply-change
+description: Implement a change on a recorded delivery branch, offering change/<change-name> instead of a protected branch. Builds on the OpenSpec apply workflow. Use when the user wants to implement, apply, or continue implementing a reviewed change.
+allowed-tools: Bash(mate:*), Bash(openspec:*), Bash(git:*)
+license: MIT
+compatibility: Requires the mate CLI and the openspec capability enabled.
+metadata:
+  author: mate
+  version: "1.0"
+---
+
+# Mate Apply Change
+
+The Apply change stage of the Delivery Path. Before any code changes, it records the
+Working Repository branch the change is delivered through, so archive and publication
+later know which merge to wait for. Then it runs the OpenSpec apply workflow.
+
+## Step 1: Read the branch and the record
+
+In the Working Repository, read local Git state only:
+
+```bash
+git symbolic-ref --quiet --short HEAD          # current branch; fails when detached
+git symbolic-ref --quiet --short refs/remotes/origin/HEAD   # default branch
+```
+
+Read the change's existing record without changing it:
+
+```bash
+mate artifact link "<change-name>" --json
+```
+
+## Step 2: Settle the delivery branch
+
+A branch is **protected** when it is the default branch or matches a configured
+protected pattern; `mate artifact link` refuses a
+protected branch unless it is recorded as a direct delivery.
+
+- **A branch is already recorded** and it is the current branch → continue. When the
+  current branch differs, warn, name both branches, and ask before implementing
+  whether to switch to the recorded branch or record the current one.
+- **On `change/<change-name>`** → record it without asking:
+  `mate artifact link "<change-name>" --branch "change/<change-name>" --json`.
+- **On another unprotected branch** (a shared feature branch) → ask once whether this
+  change is delivered through it, then record it on confirmation.
+- **Detached HEAD** → ask for the branch name, then record it.
+- **On a protected branch** → do not implement there by default. First name every
+  local commit that is not on the remote (`git log --oneline HEAD --not --remotes`) and
+  leave them where they are; never move, reset, or rebase them. Then offer:
+  1. **Create `change/<change-name>`** (default): `git switch -c change/<change-name>`;
+     uncommitted edits carry over. Record it.
+  2. **Use an existing branch**: switch to the branch the user names and record it.
+  3. **Work directly here** — only when the user explicitly chooses it. Record it as a
+     direct delivery: `mate artifact link "<change-name>" --branch "<branch>" --direct --json`.
+
+Record the branch before writing any code. When `mate artifact link` refuses, report
+its message and ask; never work around it.
+
+When its result lists `warnings`, a `dependsOn` change is not implemented yet, so this
+change would be built without the code it builds on. Report each warning and ask
+whether to apply the dependency first or continue here.
+
+## Step 3: Apply
+
+Read [references/openspec-apply-change.md](references/openspec-apply-change.md) and
+follow it for the implementation. The PR need not exist yet; the branch is the delivery.
+After implementation, the optional peers `/mate-show-me` and `/mate-simplify-code` may
+run in any order, then `/mate-archive-change`. Name them as next steps; do not invoke
+them.
+
+## Guardrails
+
+- Never push, open a PR, or merge on the user's behalf.
+- Never record a protected branch except as an explicit direct delivery.
+- The forge token, when one is used by `mate artifact link`, is never printed or
+  written; do not read or echo `MATE_GIT_TOKEN`.

package/src/templates/mate-skills/agents/mate-apply-change/references/openspec-apply-change.md

@@ -0,0 +1,198 @@
+<!-- Vendored from OpenSpec 1.15.0: the `openspec-apply-change` workflow its `agents` tool generates.
+     Copyright (c) OpenSpec Contributors, MIT License (see THIRD-PARTY-NOTICES.md in Mate).
+     Regenerated by `bun run vendor:openspec`; do not edit. -->
+
+Implement tasks from an OpenSpec change.
+
+**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
+
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
+**Input**: Optionally specify a change name (e.g., `/mate-apply-change add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and ask the user to select one
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/mate-apply-change <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status, source path, and source line
+   - Dynamic instruction based on current state
+   - Optional `context`: current required project instruction input from the selected root
+   - Optional `operationGuidance`: current advisory guidance for apply
+   - `missingArtifacts` (when present): required artifact ids with no output
+
+   **Handle states:**
+   - If `state: "blocked"`: show the message and pause implementation.
+     - If `missingArtifacts` is non-empty: suggest completing the missing artifacts. Run `openspec status --change "<name>" --json`, select the next `ready` artifact (not `skipped` or `blocked`), and use `openspec instructions "<artifact-id>" --change "<name>" --json` for its rules and template. Keep the selected `--store <id>` on both commands.
+     - Otherwise, follow the CLI instruction to create or repair the schema-configured tracking file from existing planning artifacts. Do not assume another artifact is ready or start implementation while blocked.
+   - If `state: "all_done"`: report that all tracked tasks are complete and suggest review or verification as appropriate before archiving
+   - Otherwise: proceed to implementation
+
+   Treat `context` as a required prompt-level input. Read and consider it, and
+   apply relevant project facts, conventions, and constraints while implementing.
+   Treat `operationGuidance` as optional additive advice. Read and consider every
+   entry, and follow entries that are applicable and compatible with the built-in
+   workflow.
+
+   Keep both fields separate from CLI-returned state, missing artifacts, tasks,
+   progress, `contextFiles`, and the built-in `instruction`. They are not
+   evidence of task completion, do not replace the built-in instruction, and do
+   not permit bypassing a blocked state. If context conflicts with the built-in
+   instruction, an explicit user choice, or a CLI-controlled value, report the
+   conflict and preserve the controlling value. If guidance is inapplicable or
+   conflicts with those controlling inputs, do not follow it and explain why.
+   These are prompt-level behavior contracts, not enforceable checks.
+
+4. **Read context files**
+
+   Read every file path listed under `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+   Do not copy `context` or `operationGuidance` verbatim into implementation
+   files or planning artifacts unless the user separately asks for that content.
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Before editing, confirm the checkbox at the returned `sourcePath` and `line` still matches the task description; if it does not, rerun the apply instructions and use the refreshed location
+   - Mark the task complete at its returned `sourcePath` and `line`: `- [ ]` → `- [x]`
+   - Rerun the apply instructions and confirm that task is now done and progress changed
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: report that tracked tasks are complete and suggest review or verification as appropriate before archiving
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tracked tasks are complete. Review or verify the change as appropriate
+before archiving. You can archive this change with `/mate-archive-change`.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior
+- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred
+- Use contextFiles from CLI output, don't assume specific file names
+- Use each task's sourcePath and line to update its exact checkbox
+- Do not use context or operation guidance as proof that a task is complete
+- Apply relevant project context; report conflicts with controlling workflow inputs
+- Consider every guidance entry; explain any inapplicable or conflicting advice
+- Do not copy runtime context or operation guidance into implementation files or planning artifacts
+- Preserve CLI-controlled blocked/ready/all-done behavior and completion criteria
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

package/src/templates/mate-skills/agents/mate-archive-change/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: mate-archive-change
+description: Archive a change through mate artifact archive, which records its delivery, reports merge state and its warnings, and runs the OpenSpec archive, also before the merge. Use when the user wants to archive, finalize, or close out an implemented change.
+allowed-tools: Bash(mate:*), Bash(git:*)
+license: MIT
+compatibility: Requires the mate CLI and the openspec capability enabled.
+metadata:
+  author: mate
+  version: "1.0"
+---
+
+# Mate Archive Change
+
+The Archive change stage of the Delivery Path. Archiving applies the change's delta
+specs to the local canonical specs, so a feature's later changes build on it. It is
+allowed **before** the delivery branch merges: publication, not archive, waits for the
+merge. Archiving is local and uncommitted; it publishes nothing.
+
+## Steps
+
+1. **Archive.**
+
+   ```bash
+   mate artifact archive "<change-name>" --json
+   ```
+
+   Run it from the companion or the linked Working Repository. It shows warnings,
+   refreshes merge state from the forge when a token is available, writes the change's
+   `delivery.yaml`, and runs `openspec archive` itself. Do not run `openspec archive`
+   separately.
+
+2. **Answer a missing branch.** When the result's `status` is `needs-branch`, nothing
+   was archived. Ask the user which branch delivers the change, suggesting
+   `suggestedBranch` when it is set, and re-run with exactly one of:
+
+   - `--branch "<branch>"` — a protected branch only with `--direct`, after the user
+     explicitly confirms a direct delivery;
+   - `--not-applicable "<reason>"` — for a specification-only change;
+   - `--skip-branch` — when the user skips the question; publication will ask again.
+
+3. **Report.** Relay every entry of `warnings` first: another active change that
+   modifies the same requirement, a declared dependency that is not archived yet, or
+   planning artifacts its schema requires that are missing (`incomplete-planning`).
+   Warnings never block. Then report the archive `path` and the delivery: each branch
+   with its merge result and source (`forge` or `user`) and PR link, or the
+   not-applicable reason. An open or unknown merge is information, not a failure.
+
+4. **Hand off.** Name `/mate-publish-artifact` as the next step and say that
+   publication holds the archive back until its delivery branch is merged. Do not
+   invoke it.
+
+When `status` is `failed`, report the message (typically incomplete tasks or a
+validation error) and stop.
+
+## Guardrails
+
+- Never commit, tag, or push; publication is `mate-publish-artifact`.
+- A merger account is provenance, never an artifact review.
+- Do not read or echo `MATE_GIT_TOKEN`.

package/src/templates/mate-skills/{claude/mate-openspec-backfill → agents/mate-backfill-spec}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: mate-openspec-backfill
+name: mate-backfill-spec
 description: Reverse-engineer an OpenSpec spec for one existing feature and write it directly to the canonical spec, ready to publish. Use when the user wants to backfill, document, or spec existing or legacy behavior that has no spec yet.
 allowed-tools: Bash(openspec:*), Bash(mate:*), Bash(git remote:*), Bash(git diff:*)
 license: MIT
@@ -11,7 +11,7 @@ metadata:
 
 # Mate OpenSpec Backfill
 
-Specify one feature that already exists in the working repository. A backfill records behavior that already shipped, so the run writes the canonical spec `openspec/specs/<capability>/spec.md` directly and leaves it uncommitted. It never creates a change and never publishes; publication happens afterwards through `mate-artifact-publish`.
+Specify one feature that already exists in the working repository. A backfill records behavior that already shipped, so the run writes the canonical spec `openspec/specs/<capability>/spec.md` directly and leaves it uncommitted. It never creates a change and never publishes; publication happens afterwards through `mate-publish-artifact`.
 
 ## Scope rules
 
@@ -70,12 +70,12 @@ Specify one feature that already exists in the working repository. A backfill re
 
    Fix every reported error and re-validate until it passes. Do not hand off a spec that fails validation.
 
-8. **Hand off.** Report the written path and show the uncommitted diff (`git diff -- openspec/specs/<capability>/`, or the file itself when it is new). Point the user to `mate-artifact-publish`: the spec appears there under **Drifted specs** and can be published on its own or with the rest.
+8. **Hand off.** Report the written path and show the uncommitted diff (`git diff -- openspec/specs/<capability>/`, or the file itself when it is new). Point the user to `mate-publish-artifact`: the spec appears there under **Drifted specs** and can be published on its own or with the rest.
 
 ## Guardrails
 
 - Never create an OpenSpec change, change artifacts, or verification tasks, and never archive.
-- Never commit, tag, push, or publish — never run `mate artifact publish`. Publication belongs to `mate-artifact-publish`.
+- Never commit, tag, push, or publish — never run `mate artifact publish`. Publication belongs to `mate-publish-artifact`.
 - Never write any file before the user approves the review table.
 - Never write a requirement without a citation in the review table, and never spec a suspected bug without the user's ruling.
 - Never write citations or evidence tags into the canonical spec.