@rosenfan/matrix 0.1.4 → 0.1.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -21
- package/README.md +29 -29
- package/README.zh-CN.md +27 -27
- package/{.claude → assets}/skills/matrix/SKILL.md +78 -78
- package/{.claude → assets}/skills/matrix/agents/openai.yaml +4 -4
- package/{.claude → assets}/skills/matrix/scripts/matrix_claude.py +11 -11
- package/{.claude → assets}/skills/matrix/scripts/matrix_state.py +49 -49
- package/assets/skills/matrix/scripts/test_matrix_claude.py +69 -0
- package/assets/skills/matrix/scripts/test_matrix_state.py +69 -0
- package/{.claude → assets}/skills/matrix-archive/SKILL.md +36 -36
- package/{.claude/skills/matrix-hotfix → assets/skills/matrix-archive}/agents/openai.yaml +4 -4
- package/{.claude → assets}/skills/matrix-build/SKILL.md +41 -41
- package/{.claude/skills/matrix-archive → assets/skills/matrix-build}/agents/openai.yaml +4 -4
- package/{.claude → assets}/skills/matrix-claude/SKILL.md +98 -98
- package/{.claude → assets}/skills/matrix-claude/agents/openai.yaml +4 -4
- package/{.claude → assets}/skills/matrix-design/SKILL.md +65 -65
- package/{.claude → assets}/skills/matrix-design/agents/openai.yaml +4 -4
- package/{.claude → assets}/skills/matrix-hotfix/SKILL.md +8 -8
- package/{.claude/skills/matrix-build → assets/skills/matrix-hotfix}/agents/openai.yaml +4 -4
- package/{.claude → assets}/skills/matrix-open/SKILL.md +39 -39
- package/assets/skills/matrix-open/agents/openai.yaml +4 -0
- package/{.claude → assets}/skills/matrix-status/SKILL.md +15 -15
- package/{.claude → assets}/skills/matrix-status/agents/openai.yaml +4 -4
- package/{.claude → assets}/skills/matrix-tweak/SKILL.md +8 -8
- package/assets/skills/matrix-tweak/agents/openai.yaml +4 -0
- package/{.claude → assets}/skills/matrix-verify/SKILL.md +62 -62
- package/assets/skills/matrix-verify/agents/openai.yaml +4 -0
- package/assets/skills-zh-CN/matrix/SKILL.md +14 -14
- package/assets/skills-zh-CN/matrix-build/SKILL.md +4 -4
- package/assets/skills-zh-CN/matrix-design/SKILL.md +4 -4
- package/assets/skills-zh-CN/matrix-open/SKILL.md +3 -3
- package/assets/skills-zh-CN/matrix-verify/SKILL.md +19 -19
- package/bin/matrix.js +15 -15
- package/package.json +4 -13
- package/src/catalog.js +79 -72
- package/src/cli.js +100 -100
- package/src/distribution.js +181 -178
- package/src/installer.js +10 -10
- package/src/matt-catalog.mjs +1 -1
- package/src/matt.js +115 -115
- package/src/messages.js +14 -14
- package/src/runtime-resolver.js +76 -76
- package/src/self-update.js +81 -81
- package/src/workflow-transaction.js +13 -13
- package/src/workflow.js +711 -705
- package/.claude/skills/matrix-open/agents/openai.yaml +0 -4
- package/.claude/skills/matrix-tweak/agents/openai.yaml +0 -4
- package/.claude/skills/matrix-verify/agents/openai.yaml +0 -4
|
@@ -1,73 +1,73 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: matrix-design
|
|
3
|
-
description: Design and freeze the active Matrix change before implementation. Use when the active Matrix phase is design or when build scope requires redesign.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Matrix Design
|
|
7
|
-
|
|
8
|
-
Design is used by `full` and resumable legacy shortcut changes only. A new lightweight hotfix/tweak moves directly from Open to Build and must not create Design artifacts merely to satisfy the full guard.
|
|
9
|
-
|
|
10
|
-
Use `artifact_language` from `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect` for all design and plan prose. Keep Runtime-required English heading tokens unchanged.
|
|
11
|
-
|
|
12
|
-
Run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect`, read the active proposal and frozen `orchestration`, then write `artifacts/design.md` with `## Decisions`, `## Boundaries`, `## Test seams`, and `## Risks`; write `artifacts/plan.md` with `## Steps`, `## Validation`, and `## Stop conditions`.
|
|
13
|
-
|
|
14
|
-
## Prim
|
|
15
|
-
|
|
16
|
-
Use Matrix's own capability to investigate the repository and design the change.
|
|
17
|
-
|
|
18
|
-
## Arch
|
|
19
|
-
|
|
20
|
-
Invoke only capabilities whose task-fact trigger is proven:
|
|
21
|
-
|
|
1
|
+
---
|
|
2
|
+
name: matrix-design
|
|
3
|
+
description: Design and freeze the active Matrix change before implementation. Use when the active Matrix phase is design or when build scope requires redesign.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Matrix Design
|
|
7
|
+
|
|
8
|
+
Design is used by `full` and resumable legacy shortcut changes only. A new lightweight hotfix/tweak moves directly from Open to Build and must not create Design artifacts merely to satisfy the full guard.
|
|
9
|
+
|
|
10
|
+
Use `artifact_language` from `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect` for all design and plan prose. Keep Runtime-required English heading tokens unchanged.
|
|
11
|
+
|
|
12
|
+
Run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect`, read the active proposal and frozen `orchestration`, then write `artifacts/design.md` with `## Decisions`, `## Boundaries`, `## Test seams`, and `## Risks`; write `artifacts/plan.md` with `## Steps`, `## Validation`, and `## Stop conditions`.
|
|
13
|
+
|
|
14
|
+
## Prim
|
|
15
|
+
|
|
16
|
+
Use Matrix's own capability to investigate the repository and design the change.
|
|
17
|
+
|
|
18
|
+
## Arch
|
|
19
|
+
|
|
20
|
+
Invoke only capabilities whose task-fact trigger is proven:
|
|
21
|
+
|
|
22
22
|
- `domain-modeling` for unclear vocabulary, invariants, or architectural decisions;
|
|
23
23
|
- `research` when required external facts cannot be established from the repository;
|
|
24
24
|
- `prototype` when a material design decision needs disposable empirical evidence;
|
|
25
25
|
- `codebase-design` when a deep-module, interface, or test-seam decision remains;
|
|
26
26
|
- `writing-for-agents` when the Contract creates or changes Skills, `AGENTS.md`, `CLAUDE.md`, or documents reached through agent pointers.
|
|
27
|
-
|
|
28
|
-
Order follows actual dependencies; never run a fixed companion sequence. Announce each invocation and reason. A correctly installed capability gets at most one same-capability Matrix fallback; installation-integrity failure stops the phase.
|
|
29
|
-
|
|
27
|
+
|
|
28
|
+
Order follows actual dependencies; never run a fixed companion sequence. Announce each invocation and reason. A correctly installed capability gets at most one same-capability Matrix fallback; installation-integrity failure stops the phase.
|
|
29
|
+
|
|
30
30
|
Long-lived domain, ADR, or research artifacts follow repository conventions, and material conclusions must be synchronized into the canonical design or plan. Prototypes default to an OS temporary directory unless the approved design promotes a project path. Companion output cannot own Matrix state or create a competing plan.
|
|
31
31
|
|
|
32
32
|
`wayfinder` and `improve-codebase-architecture` are explicit handoffs outside the active Design. Recommend one only when its purpose fits, then let the user invoke it; a selected result may enter a separate governed Change.
|
|
33
|
-
|
|
34
|
-
## Process
|
|
35
|
-
|
|
36
|
-
1. Establish repository facts and resolve only triggered design questions.
|
|
37
|
-
2. Write and synchronize the canonical Matrix design and plan.
|
|
38
|
-
3. Confirm material architecture choices with the user before freezing.
|
|
39
|
-
4. Run the guard, then choose the implementation actor.
|
|
40
|
-
|
|
41
|
-
```powershell
|
|
42
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard design
|
|
43
|
-
```
|
|
44
|
-
|
|
45
|
-
## Implementation Decision Point
|
|
46
|
-
|
|
47
|
-
After the design guard passes, the user chooses:
|
|
48
|
-
|
|
49
|
-
### Option A: Continue with Codex (default)
|
|
50
|
-
|
|
51
|
-
Run transition and enter `$matrix-build`:
|
|
52
|
-
|
|
53
|
-
```powershell
|
|
54
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition build
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
Then enter `$matrix-build` to implement directly in this session.
|
|
58
|
-
|
|
59
|
-
### Option B: Use Claude Code for implementation
|
|
60
|
-
|
|
61
|
-
First approve the frozen contract by transitioning to Build, then run `$matrix-claude` to export a bounded task package. This:
|
|
62
|
-
- Does not change the Build phase or state beyond the preceding transition
|
|
63
|
-
- Creates `artifacts/claude-task.md` with all implementation details
|
|
64
|
-
- Includes acceptance criteria, test seams, and required commands
|
|
65
|
-
|
|
66
|
-
After Claude Code completes and returns results, run the Build guard and enter `$matrix-verify`:
|
|
67
|
-
|
|
68
|
-
```powershell
|
|
69
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard build
|
|
70
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition verify
|
|
71
|
-
```
|
|
72
|
-
|
|
73
|
-
Then enter `$matrix-verify` to verify the implementation.
|
|
33
|
+
|
|
34
|
+
## Process
|
|
35
|
+
|
|
36
|
+
1. Establish repository facts and resolve only triggered design questions.
|
|
37
|
+
2. Write and synchronize the canonical Matrix design and plan.
|
|
38
|
+
3. Confirm material architecture choices with the user before freezing.
|
|
39
|
+
4. Run the guard, then choose the implementation actor.
|
|
40
|
+
|
|
41
|
+
```powershell
|
|
42
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard design
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
## Implementation Decision Point
|
|
46
|
+
|
|
47
|
+
After the design guard passes, the user chooses:
|
|
48
|
+
|
|
49
|
+
### Option A: Continue with Codex (default)
|
|
50
|
+
|
|
51
|
+
Run transition and enter `$matrix-build`:
|
|
52
|
+
|
|
53
|
+
```powershell
|
|
54
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition build
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
Then enter `$matrix-build` to implement directly in this session.
|
|
58
|
+
|
|
59
|
+
### Option B: Use Claude Code for implementation
|
|
60
|
+
|
|
61
|
+
First approve the frozen contract by transitioning to Build, then run `$matrix-claude` to export a bounded task package. This:
|
|
62
|
+
- Does not change the Build phase or state beyond the preceding transition
|
|
63
|
+
- Creates `artifacts/claude-task.md` with all implementation details
|
|
64
|
+
- Includes acceptance criteria, test seams, and required commands
|
|
65
|
+
|
|
66
|
+
After Claude Code completes and returns results, run the Build guard and enter `$matrix-verify`:
|
|
67
|
+
|
|
68
|
+
```powershell
|
|
69
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard build
|
|
70
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition verify
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
Then enter `$matrix-verify` to verify the implementation.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
interface:
|
|
2
|
-
display_name: "Matrix Workflow"
|
|
3
|
-
short_description: "Persistent development workflow stage"
|
|
4
|
-
default_prompt: "Use $name to continue a Matrix development workflow."
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Matrix Workflow"
|
|
3
|
+
short_description: "Persistent development workflow stage"
|
|
4
|
+
default_prompt: "Use $name to continue a Matrix development workflow."
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: matrix-hotfix
|
|
3
|
-
description: Run a constrained Matrix workflow for a reproducible small bug. Use for a bug fix that has no material architecture, API, schema, or multi-module coordination impact.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Matrix Hotfix
|
|
7
|
-
|
|
8
|
-
Start through `$matrix` with workflow `hotfix`. It uses the shared lightweight lifecycle `open → build → verify → archive`; there is no separate hotfix state machine. Before Build, record expected/actual behavior and a reproducible failure signal, present the compact Contract, and wait for confirmation. Build records reproduction and root-cause evidence; Verify records regression evidence. If the bug requires architecture, public API, schema, or broad coordination, use controlled Return to upgrade the change to full.
|
|
1
|
+
---
|
|
2
|
+
name: matrix-hotfix
|
|
3
|
+
description: Run a constrained Matrix workflow for a reproducible small bug. Use for a bug fix that has no material architecture, API, schema, or multi-module coordination impact.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Matrix Hotfix
|
|
7
|
+
|
|
8
|
+
Start through `$matrix` with workflow `hotfix`. It uses the shared lightweight lifecycle `open → build → verify → archive`; there is no separate hotfix state machine. Before Build, record expected/actual behavior and a reproducible failure signal, present the compact Contract, and wait for confirmation. Build records reproduction and root-cause evidence; Verify records regression evidence. If the bug requires architecture, public API, schema, or broad coordination, use controlled Return to upgrade the change to full.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
interface:
|
|
2
|
-
display_name: "Matrix Workflow"
|
|
3
|
-
short_description: "Persistent development workflow stage"
|
|
4
|
-
default_prompt: "Use $name to continue a Matrix development workflow."
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Matrix Workflow"
|
|
3
|
+
short_description: "Persistent development workflow stage"
|
|
4
|
+
default_prompt: "Use $name to continue a Matrix development workflow."
|
|
@@ -1,42 +1,42 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: matrix-open
|
|
3
|
-
description: Open or resume the Matrix open phase by clarifying a development request into an evidence-backed proposal. Use after $matrix initializes a change or when the active Matrix phase is open.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Matrix Open
|
|
7
|
-
|
|
8
|
-
Run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect` and follow its `profile` and `evidence_policy`.
|
|
9
|
-
|
|
10
|
-
Use its `artifact_language` for all proposal prose. Keep the required English heading tokens exactly as specified for Runtime guards; only the text beneath them is localized.
|
|
11
|
-
|
|
12
|
-
- **full**: produce `proposal.md` with `## Goal`, `## Scope`, `## Non-goals`, `## Acceptance`, and `## Risks`, then continue to Design.
|
|
13
|
-
- **lightweight**: produce the complete compact Contract before editing project implementation. Include `## Goal`, `## Scope`, `## Non-goals`, `## Approach`, `## Acceptance`, `## Validation`, `## Risks`, and `## Upgrade conditions`.
|
|
14
|
-
- **hotfix evidence**: also include `## Expected behavior`, `## Actual behavior`, and `## Reproduction`.
|
|
15
|
-
- **tweak evidence**: also include `## Current behavior`, `## Preserved behavior`, and `## Diff boundary`.
|
|
16
|
-
|
|
17
|
-
## Prim
|
|
18
|
-
|
|
19
|
-
Use Matrix's own capability to clarify the request and write the proposal.
|
|
20
|
-
|
|
21
|
-
## Arch
|
|
22
|
-
|
|
1
|
+
---
|
|
2
|
+
name: matrix-open
|
|
3
|
+
description: Open or resume the Matrix open phase by clarifying a development request into an evidence-backed proposal. Use after $matrix initializes a change or when the active Matrix phase is open.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Matrix Open
|
|
7
|
+
|
|
8
|
+
Run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect` and follow its `profile` and `evidence_policy`.
|
|
9
|
+
|
|
10
|
+
Use its `artifact_language` for all proposal prose. Keep the required English heading tokens exactly as specified for Runtime guards; only the text beneath them is localized.
|
|
11
|
+
|
|
12
|
+
- **full**: produce `proposal.md` with `## Goal`, `## Scope`, `## Non-goals`, `## Acceptance`, and `## Risks`, then continue to Design.
|
|
13
|
+
- **lightweight**: produce the complete compact Contract before editing project implementation. Include `## Goal`, `## Scope`, `## Non-goals`, `## Approach`, `## Acceptance`, `## Validation`, `## Risks`, and `## Upgrade conditions`.
|
|
14
|
+
- **hotfix evidence**: also include `## Expected behavior`, `## Actual behavior`, and `## Reproduction`.
|
|
15
|
+
- **tweak evidence**: also include `## Current behavior`, `## Preserved behavior`, and `## Diff boundary`.
|
|
16
|
+
|
|
17
|
+
## Prim
|
|
18
|
+
|
|
19
|
+
Use Matrix's own capability to clarify the request and write the proposal.
|
|
20
|
+
|
|
21
|
+
## Arch
|
|
22
|
+
|
|
23
23
|
Invoke `grilling` only when material ambiguity remains or the user asks to stress-test the request. Invoke `domain-modeling` only when domain vocabulary, invariants, or an architectural decision is unclear. Announce the capability and reason before invoking it; selecting Arch already authorizes triggered capabilities.
|
|
24
24
|
|
|
25
25
|
If progress is blocked by facts or decisions owned by another person, explain why `to-questionnaire` fits and ask the user to invoke it. Do not invoke the wrapper yourself.
|
|
26
|
-
|
|
27
|
-
Companion output is evidence for the Matrix proposal. It must not create another workflow, proposal, confirmation state, or phase transition. If a correctly installed capability fails, perform at most one Matrix-owned fallback for that same capability and record the failure and evidence. Installation-integrity failures require `matrix init --with-mattpocock` and are not eligible for fallback.
|
|
28
|
-
|
|
29
|
-
## Process
|
|
30
|
-
|
|
31
|
-
1. Resolve only ambiguities required by the active workflow.
|
|
32
|
-
2. Write the canonical proposal and synchronize material companion conclusions into it.
|
|
33
|
-
3. For full, ask for confirmation when scope or risk is material, then enter Design.
|
|
34
|
-
4. For lightweight, always present the compact Contract and wait for explicit confirmation before entering Build.
|
|
35
|
-
|
|
36
|
-
```powershell
|
|
37
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard open
|
|
38
|
-
# full
|
|
39
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition design
|
|
40
|
-
# hotfix/tweak, only after explicit confirmation
|
|
41
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition build --confirmed
|
|
42
|
-
```
|
|
26
|
+
|
|
27
|
+
Companion output is evidence for the Matrix proposal. It must not create another workflow, proposal, confirmation state, or phase transition. If a correctly installed capability fails, perform at most one Matrix-owned fallback for that same capability and record the failure and evidence. Installation-integrity failures require `matrix init --with-mattpocock` and are not eligible for fallback.
|
|
28
|
+
|
|
29
|
+
## Process
|
|
30
|
+
|
|
31
|
+
1. Resolve only ambiguities required by the active workflow.
|
|
32
|
+
2. Write the canonical proposal and synchronize material companion conclusions into it.
|
|
33
|
+
3. For full, ask for confirmation when scope or risk is material, then enter Design.
|
|
34
|
+
4. For lightweight, always present the compact Contract and wait for explicit confirmation before entering Build.
|
|
35
|
+
|
|
36
|
+
```powershell
|
|
37
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard open
|
|
38
|
+
# full
|
|
39
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition design
|
|
40
|
+
# hotfix/tweak, only after explicit confirmation
|
|
41
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition build --confirmed
|
|
42
|
+
```
|
|
@@ -1,15 +1,15 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: matrix-status
|
|
3
|
-
description: Inspect the active Matrix workflow and report its disk-backed phase, guard result, and recovery command. Use when the user asks for Matrix status, next step, or to resume interrupted Matrix work.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Matrix Status
|
|
7
|
-
|
|
8
|
-
Run the same Matrix state kernel used by the main entry and every phase Skill:
|
|
9
|
-
|
|
10
|
-
```powershell
|
|
11
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect
|
|
12
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs doctor
|
|
13
|
-
```
|
|
14
|
-
|
|
15
|
-
Report the returned change id, workflow, `profile`, `evidence_policy`, frozen `orchestration`, phase, guard result, `next_skill`, Workflow health, unfinished transactions, available strategies, and exact recovery commands. If Arch integrity fails, identify the affected platform/Skill facts and report `matrix init --with-mattpocock`; do not reinterpret the change as Prim. Both commands are read-only. Do not infer status from conversation history, run `--repair`, or modify state. If the guard is failing, name the missing evidence and direct the user to the current phase Skill.
|
|
1
|
+
---
|
|
2
|
+
name: matrix-status
|
|
3
|
+
description: Inspect the active Matrix workflow and report its disk-backed phase, guard result, and recovery command. Use when the user asks for Matrix status, next step, or to resume interrupted Matrix work.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Matrix Status
|
|
7
|
+
|
|
8
|
+
Run the same Matrix state kernel used by the main entry and every phase Skill:
|
|
9
|
+
|
|
10
|
+
```powershell
|
|
11
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect
|
|
12
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs doctor
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
Report the returned change id, workflow, `profile`, `evidence_policy`, frozen `orchestration`, phase, guard result, `next_skill`, Workflow health, unfinished transactions, available strategies, and exact recovery commands. If Arch integrity fails, identify the affected platform/Skill facts and report `matrix init --with-mattpocock`; do not reinterpret the change as Prim. Both commands are read-only. Do not infer status from conversation history, run `--repair`, or modify state. If the guard is failing, name the missing evidence and direct the user to the current phase Skill.
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
interface:
|
|
2
|
-
display_name: "Matrix Status"
|
|
3
|
-
short_description: "Inspect and recover active Matrix workflow state"
|
|
4
|
-
default_prompt: "Use $matrix-status to inspect the active Matrix workflow."
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Matrix Status"
|
|
3
|
+
short_description: "Inspect and recover active Matrix workflow state"
|
|
4
|
+
default_prompt: "Use $matrix-status to inspect the active Matrix workflow."
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: matrix-tweak
|
|
3
|
-
description: Run a lightweight Matrix workflow for a bounded small development change. Use for a small request with no schema, public API, architecture, or cross-module coordination impact.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Matrix Tweak
|
|
7
|
-
|
|
8
|
-
Start through `$matrix` with workflow `tweak`. It uses the shared lightweight lifecycle `open → build → verify → archive`; there is no separate tweak state machine or Design phase. Before editing implementation, define current/preserved behavior, the diff boundary, acceptance, and validation in the compact proposal, present it, and wait for confirmation. Build and Verify must prove scope and diff alignment. Use controlled Return to upgrade to full when the change crosses module, API, schema, or architecture boundaries.
|
|
1
|
+
---
|
|
2
|
+
name: matrix-tweak
|
|
3
|
+
description: Run a lightweight Matrix workflow for a bounded small development change. Use for a small request with no schema, public API, architecture, or cross-module coordination impact.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Matrix Tweak
|
|
7
|
+
|
|
8
|
+
Start through `$matrix` with workflow `tweak`. It uses the shared lightweight lifecycle `open → build → verify → archive`; there is no separate tweak state machine or Design phase. Before editing implementation, define current/preserved behavior, the diff boundary, acceptance, and validation in the compact proposal, present it, and wait for confirmation. Build and Verify must prove scope and diff alignment. Use controlled Return to upgrade to full when the change crosses module, API, schema, or architecture boundaries.
|
|
@@ -1,38 +1,38 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: matrix-verify
|
|
3
|
-
description: Verify the active Matrix change against its plan and review its diff. Use when the active Matrix phase is verify.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Matrix Verify
|
|
7
|
-
|
|
8
|
-
Run the approved Contract's acceptance commands and record their output summaries under `## Test evidence` in `artifacts/verification.md`.
|
|
9
|
-
|
|
10
|
-
Write verification prose in `artifact_language` from inspect while preserving the required English evidence headings.
|
|
11
|
-
|
|
12
|
-
## Input Sources
|
|
13
|
-
|
|
14
|
-
This phase can receive implementation from two sources:
|
|
15
|
-
|
|
16
|
-
1. **Direct Codex implementation** — from `$matrix-build` phase
|
|
17
|
-
2. **Claude Code implementation** — from `$matrix-claude` sidecar
|
|
18
|
-
|
|
19
|
-
Regardless of source, the verification process is the same: check that implementation evidence meets the plan's requirements.
|
|
20
|
-
|
|
21
|
-
## Prerequisites
|
|
22
|
-
|
|
23
|
-
Before starting verification, ensure:
|
|
24
|
-
|
|
25
|
-
- [ ] `artifacts/verification.md` exists
|
|
26
|
-
- [ ] `## Build evidence` section is present and substantive
|
|
27
|
-
- [ ] All commands from the plan's `## Validation` section have been run
|
|
28
|
-
- [ ] Test results are recorded
|
|
29
|
-
|
|
30
|
-
If these are missing (e.g., Claude Code didn't produce complete evidence), return to `$matrix-build` or ask Claude Code to补充.
|
|
31
|
-
|
|
32
|
-
## Orchestration
|
|
33
|
-
|
|
34
|
-
Run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect` and read the frozen mode.
|
|
35
|
-
|
|
1
|
+
---
|
|
2
|
+
name: matrix-verify
|
|
3
|
+
description: Verify the active Matrix change against its plan and review its diff. Use when the active Matrix phase is verify.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Matrix Verify
|
|
7
|
+
|
|
8
|
+
Run the approved Contract's acceptance commands and record their output summaries under `## Test evidence` in `artifacts/verification.md`.
|
|
9
|
+
|
|
10
|
+
Write verification prose in `artifact_language` from inspect while preserving the required English evidence headings.
|
|
11
|
+
|
|
12
|
+
## Input Sources
|
|
13
|
+
|
|
14
|
+
This phase can receive implementation from two sources:
|
|
15
|
+
|
|
16
|
+
1. **Direct Codex implementation** — from `$matrix-build` phase
|
|
17
|
+
2. **Claude Code implementation** — from `$matrix-claude` sidecar
|
|
18
|
+
|
|
19
|
+
Regardless of source, the verification process is the same: check that implementation evidence meets the plan's requirements.
|
|
20
|
+
|
|
21
|
+
## Prerequisites
|
|
22
|
+
|
|
23
|
+
Before starting verification, ensure:
|
|
24
|
+
|
|
25
|
+
- [ ] `artifacts/verification.md` exists
|
|
26
|
+
- [ ] `## Build evidence` section is present and substantive
|
|
27
|
+
- [ ] All commands from the plan's `## Validation` section have been run
|
|
28
|
+
- [ ] Test results are recorded
|
|
29
|
+
|
|
30
|
+
If these are missing (e.g., Claude Code didn't produce complete evidence), return to `$matrix-build` or ask Claude Code to补充.
|
|
31
|
+
|
|
32
|
+
## Orchestration
|
|
33
|
+
|
|
34
|
+
Run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect` and read the frozen mode.
|
|
35
|
+
|
|
36
36
|
- **Prim**: Matrix performs the Standards and Spec review itself.
|
|
37
37
|
- **Arch**: invoke `code-review` to produce both review axes; announce the invocation and reason.
|
|
38
38
|
|
|
@@ -51,39 +51,39 @@ node <matrix-skill-directory>/scripts/matrix-runtime.mjs review --source matrix-
|
|
|
51
51
|
```
|
|
52
52
|
|
|
53
53
|
Never label fallback output as a successful `code-review` run. `empty-head-diff` requires the fixed point so Runtime can verify the empty three-dot diff. `uncommitted-worktree` requires a fixed point and Runtime binds the staged, unstaged, and untracked candidate content into `candidate_hash`; any later change makes the receipt stale. If a receipt already exists or either axis failed, use a controlled Return before another attempt.
|
|
54
|
-
|
|
55
|
-
## Failure Handling
|
|
56
|
-
|
|
57
|
-
If verification or review fails:
|
|
58
|
-
- If the issue is in the implementation, run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs return build --reason verification-failed`, then enter `$matrix-build` or ask Claude Code to fix.
|
|
59
|
-
- If the issue is in the acceptance criteria or design, run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs return design --reason acceptance-or-design-gap`, then enter `$matrix-design`.
|
|
60
|
-
|
|
54
|
+
|
|
55
|
+
## Failure Handling
|
|
56
|
+
|
|
57
|
+
If verification or review fails:
|
|
58
|
+
- If the issue is in the implementation, run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs return build --reason verification-failed`, then enter `$matrix-build` or ask Claude Code to fix.
|
|
59
|
+
- If the issue is in the acceptance criteria or design, run `node <matrix-skill-directory>/scripts/matrix-runtime.mjs return design --reason acceptance-or-design-gap`, then enter `$matrix-design`.
|
|
60
|
+
|
|
61
61
|
Both Return paths rotate the current `verification.md` and any `review-receipt.json` into revisioned evidence history. Do not copy stale conclusions or receipts back into the new current evidence.
|
|
62
|
-
|
|
63
|
-
If documents or public behavior changed, record the required synchronization work before the guard.
|
|
64
|
-
|
|
65
|
-
## Process
|
|
66
|
-
|
|
67
|
-
1. Check that `artifacts/verification.md` exists with `## Build evidence`
|
|
68
|
-
2. Run the approved validation commands (full plan or lightweight proposal)
|
|
62
|
+
|
|
63
|
+
If documents or public behavior changed, record the required synchronization work before the guard.
|
|
64
|
+
|
|
65
|
+
## Process
|
|
66
|
+
|
|
67
|
+
1. Check that `artifacts/verification.md` exists with `## Build evidence`
|
|
68
|
+
2. Run the approved validation commands (full plan or lightweight proposal)
|
|
69
69
|
3. Record test output under `## Test evidence`
|
|
70
70
|
4. Produce both Standards and Spec review axes through the selected orchestration mode
|
|
71
71
|
5. Record findings under `## Review evidence` with `### Standards` and `### Spec`
|
|
72
72
|
6. In Arch, record the Runtime review receipt for the current revision
|
|
73
73
|
7. Run the guard
|
|
74
74
|
8. If it passes, transition to archive and enter `$matrix-archive`
|
|
75
|
-
|
|
76
|
-
```powershell
|
|
77
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard verify
|
|
78
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition archive
|
|
79
|
-
```
|
|
80
|
-
|
|
81
|
-
## Evidence Requirements
|
|
82
|
-
|
|
83
|
-
The guard checks for:
|
|
84
|
-
|
|
85
|
-
1. **Test evidence** — Output from running the plan's validation commands
|
|
75
|
+
|
|
76
|
+
```powershell
|
|
77
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard verify
|
|
78
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs transition archive
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
## Evidence Requirements
|
|
82
|
+
|
|
83
|
+
The guard checks for:
|
|
84
|
+
|
|
85
|
+
1. **Test evidence** — Output from running the plan's validation commands
|
|
86
86
|
2. **Review evidence** — Separate Standards and Spec findings from the selected review path
|
|
87
87
|
3. **Arch review receipt** — Runtime-bound identity for the current Contract, evidence, workspace, and normal or fallback source
|
|
88
|
-
|
|
89
|
-
Full requires Test and Review evidence. Hotfix additionally requires `## Regression evidence`; tweak additionally requires `## Scope review evidence`.
|
|
88
|
+
|
|
89
|
+
Full requires Test and Review evidence. Hotfix additionally requires `## Regression evidence`; tweak additionally requires `## Scope review evidence`.
|
|
@@ -9,13 +9,13 @@ description: 启动、恢复并治理持久化的 Matrix 开发工作流。
|
|
|
9
9
|
|
|
10
10
|
读取 `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect` 的 `artifact_language`。规范 Markdown 标题 token 必须保持不变;面向用户的产物正文、说明和 handoff 在 `zh-CN` 时写中文,在 `en` 时写英文。
|
|
11
11
|
|
|
12
|
-
所有 workflow 命令都先执行当前项目 Matrix Skill 自带的 Runtime,使项目兼容性权威优先于不同版本的全局启动器:
|
|
13
|
-
|
|
14
|
-
```powershell
|
|
15
|
-
node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect
|
|
16
|
-
```
|
|
17
|
-
|
|
18
|
-
全局 `matrix` 命令只负责 init、update 和 bootstrap。受信任的 0.1.4 启动器只会自动委派给版本与 hash 都精确匹配的 0.1.4 项目 Runtime。项目 Runtime 属于不同版本或无法识别版本时仍是项目权威,但必须执行启动器返回的精确直连命令;旧版启动器不具备这项跨版本检查,不能作为项目 workflow 入口。
|
|
12
|
+
所有 workflow 命令都先执行当前项目 Matrix Skill 自带的 Runtime,使项目兼容性权威优先于不同版本的全局启动器:
|
|
13
|
+
|
|
14
|
+
```powershell
|
|
15
|
+
node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
全局 `matrix` 命令只负责 init、update 和 bootstrap。受信任的 0.1.4 启动器只会自动委派给版本与 hash 都精确匹配的 0.1.4 项目 Runtime。项目 Runtime 属于不同版本或无法识别版本时仍是项目权威,但必须执行启动器返回的精确直连命令;旧版启动器不具备这项跨版本检查,不能作为项目 workflow 入口。
|
|
19
19
|
|
|
20
20
|
有活动变更时,报告其 phase、冻结的 `orchestration` 以及 Arch 安装完整性,再按 Runtime 结果进入 `next_skill`。没有活动变更时,为开发请求创建简短 kebab-case ID:
|
|
21
21
|
|
|
@@ -28,7 +28,7 @@ node <matrix-skill-directory>/scripts/matrix-runtime.mjs init <change-id> --work
|
|
|
28
28
|
## 编排模式
|
|
29
29
|
|
|
30
30
|
- **Prim**:各阶段使用 Matrix 自身能力,不依赖 Matt Skills。
|
|
31
|
-
- **Arch**:仅在任务事实满足触发条件时,调用活动 Change 冻结的十项自动能力。Matrix 0.1.4 审查 Matt Skills v1.2.3 官方 25 项角色,只把其中 23 项兼容 Skill 安装在项目本地;排除 `implement` 与 raw `resolving-merge-conflicts`。
|
|
31
|
+
- **Arch**:仅在任务事实满足触发条件时,调用活动 Change 冻结的十项自动能力。Matrix 0.1.4 审查 Matt Skills v1.2.3 官方 25 项角色,只把其中 23 项兼容 Skill 安装在项目本地;排除 `implement` 与 raw `resolving-merge-conflicts`。
|
|
32
32
|
|
|
33
33
|
两种编排模式使用已选定的 workflow profile:`full` 走 `open → design → build → verify → archive`;`hotfix` 与 `tweak` 共用内部 `lightweight` profile,走 `open → build → verify → archive`,仅证据策略不同。Arch 能力不得写 Matrix 状态、推进阶段、提交、归档或创建竞争工作流。
|
|
34
34
|
|
|
@@ -64,14 +64,14 @@ node <matrix-skill-directory>/scripts/matrix-runtime.mjs doctor --repair --lock
|
|
|
64
64
|
|
|
65
65
|
full 的 `design -> build` 会批准 proposal/design/plan;lightweight 的 `open -> build --confirmed` 只批准紧凑 proposal,并拒绝初始化后、批准前发生的项目实现改动。Contract 后续漂移都会阻断推进。
|
|
66
66
|
|
|
67
|
-
## 可选 Claude 交接
|
|
67
|
+
## 可选 Claude 交接
|
|
68
68
|
|
|
69
69
|
`$matrix-claude` 只在已批准的 Build 中使用,导出同一 Contract 快照给 Claude Code。它不拥有阶段推进或验收;直接由 Codex 实现仍使用原有 Matrix 主流程。
|
|
70
|
-
只有用户明确选择“Codex 设计、Claude Code 实现”时才使用,不得自动插入标准流程。
|
|
71
|
-
|
|
72
|
-
## 显式 Matt handoff
|
|
73
|
-
|
|
74
|
-
Matrix 不嵌套 user-invoked Skill。适用时只解释原因,并让用户显式调用:一次性配置使用 `setup-matt-pocock-skills`,工作流外架构扫描使用 `improve-codebase-architecture`,独立大型候选生成使用 `wayfinder`,上下文边界使用 `handoff`,他人掌握阻塞事实时使用 `to-questionnaire`。`ask-matt`、`grill-with-docs`、`triage`、`to-spec`、`to-tickets`、`grill-me`、`teach`、`wait-what` 保持 standalone。Matrix 不安装也不管理 `implement` 或 raw `resolving-merge-conflicts`;已有副本保留为未管理额外项,活动 Change 内不得建议使用。
|
|
70
|
+
只有用户明确选择“Codex 设计、Claude Code 实现”时才使用,不得自动插入标准流程。
|
|
71
|
+
|
|
72
|
+
## 显式 Matt handoff
|
|
73
|
+
|
|
74
|
+
Matrix 不嵌套 user-invoked Skill。适用时只解释原因,并让用户显式调用:一次性配置使用 `setup-matt-pocock-skills`,工作流外架构扫描使用 `improve-codebase-architecture`,独立大型候选生成使用 `wayfinder`,上下文边界使用 `handoff`,他人掌握阻塞事实时使用 `to-questionnaire`。`ask-matt`、`grill-with-docs`、`triage`、`to-spec`、`to-tickets`、`grill-me`、`teach`、`wait-what` 保持 standalone。Matrix 不安装也不管理 `implement` 或 raw `resolving-merge-conflicts`;已有副本保留为未管理额外项,活动 Change 内不得建议使用。
|
|
75
75
|
|
|
76
76
|
## 规则
|
|
77
77
|
|
|
@@ -12,9 +12,9 @@ Build 证据与面向用户的说明使用 `artifact_language`;Runtime 所需
|
|
|
12
12
|
## 编排
|
|
13
13
|
|
|
14
14
|
- **Prim**:使用 Matrix 自身实现与测试能力。
|
|
15
|
-
- **Arch**:可测试行为变化时调用 `tdd`;真实失败且根因未知时调用 `diagnosing-bugs`;批准 Contract 修改 agent-facing 指令时调用 `writing-for-agents`;只有 Contract 需要人工执行 shell 步骤时,才用 `wizard` 生成并静态验证脚本,绝不端到端执行或收集秘密。
|
|
16
|
-
|
|
17
|
-
进行中的 merge/rebase 冲突由 Matrix 自身治理,不调用会 stage、continue 或 commit 的 raw `resolving-merge-conflicts`。活动 Change 内不得调用 `implement`。
|
|
15
|
+
- **Arch**:可测试行为变化时调用 `tdd`;真实失败且根因未知时调用 `diagnosing-bugs`;批准 Contract 修改 agent-facing 指令时调用 `writing-for-agents`;只有 Contract 需要人工执行 shell 步骤时,才用 `wizard` 生成并静态验证脚本,绝不端到端执行或收集秘密。
|
|
16
|
+
|
|
17
|
+
进行中的 merge/rebase 冲突由 Matrix 自身治理,不调用会 stage、continue 或 commit 的 raw `resolving-merge-conflicts`。活动 Change 内不得调用 `implement`。
|
|
18
18
|
|
|
19
19
|
调用前说明能力与原因。companion 不得 commit、review、transition、archive 或扩大范围。正确安装的能力失败时最多执行一次同能力 Matrix fallback,并记录调用、失败、fallback 与证据;安装完整性问题必须停止并修复。
|
|
20
20
|
|
|
@@ -30,7 +30,7 @@ node <matrix-skill-directory>/scripts/matrix-runtime.mjs return design --reason
|
|
|
30
30
|
|
|
31
31
|
## 流程
|
|
32
32
|
|
|
33
|
-
1. 对可测试的行为变化使用 `tdd` 纵向切片;纯文档或不可观察的机械变更使用相称的静态检查。
|
|
33
|
+
1. 对可测试的行为变化使用 `tdd` 纵向切片;纯文档或不可观察的机械变更使用相称的静态检查。
|
|
34
34
|
2. 在 `## Build evidence` 记录共同事实;hotfix 另写 `## Reproduction evidence`、`## Root cause`,tweak 另写 `## Scope evidence`。
|
|
35
35
|
3. 运行 Build guard;它同时确认批准的 Contract 仍精确匹配。
|
|
36
36
|
4. 通过后推进至 Verify,并进入 `$matrix-verify`。
|
|
@@ -12,11 +12,11 @@ design 和 plan 正文使用 `node <matrix-skill-directory>/scripts/matrix-runti
|
|
|
12
12
|
读取 `node <matrix-skill-directory>/scripts/matrix-runtime.mjs inspect`、proposal 与冻结 `orchestration`,写入 `design.md`(`## Decisions`、`## Boundaries`、`## Test seams`、`## Risks`)与 `plan.md`(`## Steps`、`## Validation`、`## Stop conditions`)。
|
|
13
13
|
|
|
14
14
|
- **Prim**:使用 Matrix 自身能力调查并设计。
|
|
15
|
-
- **Arch**:仅按事实触发 `domain-modeling`、`research`、`prototype`、`codebase-design`;当 Contract 修改 Skill、`AGENTS.md`、`CLAUDE.md` 或 agent 指针可达文档时触发 `writing-for-agents`。不得机械执行固定序列;每次调用前说明能力与原因。
|
|
15
|
+
- **Arch**:仅按事实触发 `domain-modeling`、`research`、`prototype`、`codebase-design`;当 Contract 修改 Skill、`AGENTS.md`、`CLAUDE.md` 或 agent 指针可达文档时触发 `writing-for-agents`。不得机械执行固定序列;每次调用前说明能力与原因。
|
|
16
16
|
|
|
17
|
-
长期有效的领域、ADR 或研究产物遵循仓库约定,关键结论必须同步进入 Matrix design/plan。prototype 默认写入系统临时目录。companion 不得拥有 Matrix 状态或创建竞争计划。重大范围或架构决策须先由用户确认。
|
|
18
|
-
|
|
19
|
-
`wayfinder` 与 `improve-codebase-architecture` 只能作为活动 Design 外的显式 handoff;说明原因后由用户调用,选中的结果可另行进入受治理 Change。
|
|
17
|
+
长期有效的领域、ADR 或研究产物遵循仓库约定,关键结论必须同步进入 Matrix design/plan。prototype 默认写入系统临时目录。companion 不得拥有 Matrix 状态或创建竞争计划。重大范围或架构决策须先由用户确认。
|
|
18
|
+
|
|
19
|
+
`wayfinder` 与 `improve-codebase-architecture` 只能作为活动 Design 外的显式 handoff;说明原因后由用户调用,选中的结果可另行进入受治理 Change。
|
|
20
20
|
|
|
21
21
|
```powershell
|
|
22
22
|
node <matrix-skill-directory>/scripts/matrix-runtime.mjs guard design
|
|
@@ -15,9 +15,9 @@ proposal 正文使用其中的 `artifact_language`;Runtime 所需的英文标
|
|
|
15
15
|
- tweak 额外包含 `## Current behavior`、`## Preserved behavior`、`## Diff boundary`。
|
|
16
16
|
|
|
17
17
|
- **Prim**:使用 Matrix 自身能力澄清并编写提案。
|
|
18
|
-
- **Arch**:仅在存在重大歧义或用户要求压力测试时调用 `grilling`;仅在领域词汇、不变量或架构决定不清晰时调用 `domain-modeling`。调用前说明能力与原因。
|
|
19
|
-
|
|
20
|
-
若进展被另一人掌握的事实或决定阻塞,说明 `to-questionnaire` 适用的原因并让用户显式调用;Matrix 不得自行嵌套该 wrapper。
|
|
18
|
+
- **Arch**:仅在存在重大歧义或用户要求压力测试时调用 `grilling`;仅在领域词汇、不变量或架构决定不清晰时调用 `domain-modeling`。调用前说明能力与原因。
|
|
19
|
+
|
|
20
|
+
若进展被另一人掌握的事实或决定阻塞,说明 `to-questionnaire` 适用的原因并让用户显式调用;Matrix 不得自行嵌套该 wrapper。
|
|
21
21
|
|
|
22
22
|
companion 输出只能作为当前 proposal 的证据,不得创建第二套工作流、提案、确认状态或阶段转换。正确安装的能力失败时最多执行一次同能力 Matrix fallback;安装完整性问题必须修复。
|
|
23
23
|
|