@webpresso/claude-plugin 3.1.17 → 3.1.19
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/.claude-plugin/marketplace.json +2 -2
- package/.claude-plugin/plugin.json +1 -1
- package/package.json +1 -1
- package/plugin-skill-ownership.json +11 -5
- package/skills/ai-deslop/SKILL.md +91 -0
- package/skills/codex/SKILL.md +20 -0
- package/skills/fix/SKILL.md +27 -11
- package/skills/investigate/SKILL.md +61 -0
- package/skills/plan-refine/SKILL.md +1 -0
- package/skills/verify/SKILL.md +14 -4
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
},
|
|
7
7
|
"metadata": {
|
|
8
8
|
"description": "Webpresso agent-kit Claude Code plugin: blueprints, skills, hooks, MCP server",
|
|
9
|
-
"version": "3.1.
|
|
9
|
+
"version": "3.1.19"
|
|
10
10
|
},
|
|
11
11
|
"plugins": [
|
|
12
12
|
{
|
|
@@ -34,5 +34,5 @@
|
|
|
34
34
|
}
|
|
35
35
|
}
|
|
36
36
|
],
|
|
37
|
-
"version": "3.1.
|
|
37
|
+
"version": "3.1.19"
|
|
38
38
|
}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@webpresso/claude-plugin",
|
|
3
|
-
"version": "3.1.
|
|
3
|
+
"version": "3.1.19",
|
|
4
4
|
"private": false,
|
|
5
5
|
"description": "Claude Code plugin adapter for Webpresso agent-kit skills, commands, and MCP runtime.",
|
|
6
6
|
"homepage": "https://github.com/webpresso/agent-kit#readme",
|
|
@@ -2,9 +2,12 @@
|
|
|
2
2
|
"schemaVersion": 1,
|
|
3
3
|
"host": "claude",
|
|
4
4
|
"packageName": "@webpresso/claude-plugin",
|
|
5
|
-
"packageVersion": "3.1.
|
|
5
|
+
"packageVersion": "3.1.19",
|
|
6
6
|
"runtimeDirs": [".claude/skills"],
|
|
7
7
|
"skills": {
|
|
8
|
+
"ai-deslop": {
|
|
9
|
+
"digest": "sha256:c1da1003009073dd3923454947e1141efc2e7df5ad8d725a511ed5cff03bfb5c"
|
|
10
|
+
},
|
|
8
11
|
"autopilot": {
|
|
9
12
|
"digest": "sha256:9e0b47c8438fe7c8123bec3361fcb17fd2fcd818a840f46ea272a7712e4c0b10"
|
|
10
13
|
},
|
|
@@ -21,7 +24,7 @@
|
|
|
21
24
|
"digest": "sha256:2af483ef80c5e0cf3d6d3da94d54b5bd1e9cecc9b2bd05e085499c2745c2c238"
|
|
22
25
|
},
|
|
23
26
|
"codex": {
|
|
24
|
-
"digest": "sha256:
|
|
27
|
+
"digest": "sha256:98187c2845b5cd88ba9eb9f682d16fec648932a084b3d1cebd066945b1fb6fdf"
|
|
25
28
|
},
|
|
26
29
|
"deep-research": {
|
|
27
30
|
"digest": "sha256:01dafd194066a2936db0b437fd5c3beef6d7ff82478d0d995393093d89496f18"
|
|
@@ -33,11 +36,14 @@
|
|
|
33
36
|
"digest": "sha256:306355888da0827e3523022077f731845726bbaaf595ca12515cc91d8605b5e6"
|
|
34
37
|
},
|
|
35
38
|
"fix": {
|
|
36
|
-
"digest": "sha256:
|
|
39
|
+
"digest": "sha256:647aa94890e06b38b08e6cc12cd219343e963b4d3b469c349610b3a33f559dd5"
|
|
37
40
|
},
|
|
38
41
|
"hooks-doctor": {
|
|
39
42
|
"digest": "sha256:3bfb0af64ff6796c56d51e4cd2bede7fb24c869f89b292546ea13ad2f5d3bb73"
|
|
40
43
|
},
|
|
44
|
+
"investigate": {
|
|
45
|
+
"digest": "sha256:2051bccb2daf97ee91a8c15c7ef5bc7cc705d49beb4cbc7c8f6c63f4acda88a2"
|
|
46
|
+
},
|
|
41
47
|
"lore-protocol": {
|
|
42
48
|
"digest": "sha256:a80fbacc765e8b886437b9fdf7dd71e1ceb1b98b939078ec90fc88d06a8b4c69"
|
|
43
49
|
},
|
|
@@ -57,7 +63,7 @@
|
|
|
57
63
|
"digest": "sha256:b728dad90254d4c9f81b3818321d34ab53519b79ce20ff3bfe08bfacb2aa3e86"
|
|
58
64
|
},
|
|
59
65
|
"plan-refine": {
|
|
60
|
-
"digest": "sha256:
|
|
66
|
+
"digest": "sha256:1ad9175b999e946482109138ea23d4496f95987bf66ff41cf32fac5a764339a5"
|
|
61
67
|
},
|
|
62
68
|
"ralplan": {
|
|
63
69
|
"digest": "sha256:db285d477f43ed23df990d4c03750d9916cdc7809356c1bf025efdf6a9add9ed"
|
|
@@ -78,7 +84,7 @@
|
|
|
78
84
|
"digest": "sha256:dc6d3b2bd48a494d7a5cd30ad9c6c9999989b9920ca06ccd1f86a7cfaff60d54"
|
|
79
85
|
},
|
|
80
86
|
"verify": {
|
|
81
|
-
"digest": "sha256:
|
|
87
|
+
"digest": "sha256:2964a54ef0f9db389d3ef5fa779fa2f095c9f8df47f19f3e4947d2403cdbf156"
|
|
82
88
|
}
|
|
83
89
|
}
|
|
84
90
|
}
|
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
---
|
|
2
|
+
type: skill
|
|
3
|
+
slug: ai-deslop
|
|
4
|
+
title: AI Deslop
|
|
5
|
+
status: active
|
|
6
|
+
scope: repo
|
|
7
|
+
applies_to: [agents]
|
|
8
|
+
related: [fix, verify, investigate]
|
|
9
|
+
created: "2026-07-16"
|
|
10
|
+
last_reviewed: "2026-07-16"
|
|
11
|
+
name: ai-deslop
|
|
12
|
+
description: "Bounded anti-slop cleanup pass: simplify, delete noise, or review-only with --review."
|
|
13
|
+
license: MIT
|
|
14
|
+
upstream:
|
|
15
|
+
source: https://github.com/Yeachan-Heo/oh-my-claudecode/tree/590fb988931d34a12604be0ca4215c818079018e/skills/ai-slop-cleaner
|
|
16
|
+
last_synced: "2026-07-16"
|
|
17
|
+
argument-hint: "[--review] <files|path|scope>"
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
# AI Deslop
|
|
21
|
+
|
|
22
|
+
Use this skill after behavior is already correct but the resulting code or docs
|
|
23
|
+
still feel bloated, repetitive, over-scaffolded, or obviously machine-shaped.
|
|
24
|
+
|
|
25
|
+
## Boundary
|
|
26
|
+
|
|
27
|
+
- `ai-deslop` is a cleanup pass, not a feature lane.
|
|
28
|
+
- Preserve behavior. If the work needs a logic change, route back to `fix`.
|
|
29
|
+
- Prefer deletion and simplification over new abstraction.
|
|
30
|
+
- Keep scope bounded to the requested files, changed files, or clearly named
|
|
31
|
+
area. Do not expand into broad redesign.
|
|
32
|
+
|
|
33
|
+
## When to use it
|
|
34
|
+
|
|
35
|
+
- The user explicitly asks to deslop, clean up AI slop, simplify, or trim noise.
|
|
36
|
+
- A completed feature still contains dead code, duplicate helpers, wrapper
|
|
37
|
+
layers, weak boundaries, or generated-sounding prose/comments.
|
|
38
|
+
- `verify` finds stale compatibility branches, cargo-cult abstractions, or
|
|
39
|
+
cleanup debt after the behavioral proof is already green.
|
|
40
|
+
- The user wants a reviewer-only anti-slop pass via `--review`.
|
|
41
|
+
|
|
42
|
+
## When not to use it
|
|
43
|
+
|
|
44
|
+
- Behavior is still failing or root cause is not established.
|
|
45
|
+
- The request is really a new feature, redesign, or semantic refactor.
|
|
46
|
+
- Verification is too weak to protect preserved behavior.
|
|
47
|
+
|
|
48
|
+
## Modes
|
|
49
|
+
|
|
50
|
+
### Standard mode
|
|
51
|
+
|
|
52
|
+
1. Lock behavior first with the narrowest regression proof available.
|
|
53
|
+
2. Write a short cleanup plan naming the concrete slop to remove.
|
|
54
|
+
3. Classify each smell:
|
|
55
|
+
- dead code / unused exports
|
|
56
|
+
- duplication / needless wrappers
|
|
57
|
+
- compatibility scaffolding that no longer serves a consumer
|
|
58
|
+
- noisy comments, docs, or prompts that restate the obvious
|
|
59
|
+
- weak boundaries or helper proliferation with no clear owner
|
|
60
|
+
4. Apply the smallest safe deletions and consolidations first.
|
|
61
|
+
5. Re-run the same scoped verification after each meaningful pass.
|
|
62
|
+
|
|
63
|
+
### Review mode (`--review`)
|
|
64
|
+
|
|
65
|
+
Use this to review a drafted cleanup pass without writing code.
|
|
66
|
+
|
|
67
|
+
1. Inspect the cleanup plan, changed files, and verification evidence.
|
|
68
|
+
2. Look specifically for leftover dead code, duplicate logic, needless
|
|
69
|
+
abstraction, and accidental behavior drift.
|
|
70
|
+
3. Return a verdict plus required follow-ups.
|
|
71
|
+
4. Do not both write and self-approve the same high-impact cleanup pass.
|
|
72
|
+
|
|
73
|
+
## Verification
|
|
74
|
+
|
|
75
|
+
Run only the narrowest checks that protect preserved behavior:
|
|
76
|
+
|
|
77
|
+
- targeted tests
|
|
78
|
+
- targeted lint/typecheck
|
|
79
|
+
- any changed docs or command-surface checks
|
|
80
|
+
|
|
81
|
+
If the cleanup touches shared/public surfaces or broad repo-owned docs, hand the
|
|
82
|
+
result to `verify` before calling it done.
|
|
83
|
+
|
|
84
|
+
## Output
|
|
85
|
+
|
|
86
|
+
Return:
|
|
87
|
+
|
|
88
|
+
- cleanup scope
|
|
89
|
+
- slop classes removed
|
|
90
|
+
- proof that behavior stayed locked
|
|
91
|
+
- remaining follow-ups, if any
|
package/skills/codex/SKILL.md
CHANGED
|
@@ -50,6 +50,24 @@ fi
|
|
|
50
50
|
|
|
51
51
|
Codex native subagent events are not currently parent-linked in the managed lifecycle. They are shown as unsupported, never inferred from text, PIDs, or timestamps.
|
|
52
52
|
|
|
53
|
+
## Options
|
|
54
|
+
|
|
55
|
+
Every mode runs through the `wp review run` runtime and honors these environment
|
|
56
|
+
overrides (defaults shown). Set them inline, e.g.
|
|
57
|
+
`CODEX_REVIEW_MODEL=gpt-5.6-sol CODEX_REVIEW_EFFORT=high /codex`.
|
|
58
|
+
|
|
59
|
+
- `CODEX_REVIEW_MODEL` — the Codex model. Defaults to the `model = "..."` in the
|
|
60
|
+
active Codex config (`${CODEX_HOME:-~/.codex}/config.toml`), falling back to
|
|
61
|
+
`gpt-5.4`. It MUST be a model the current login is provisioned for: ChatGPT-account
|
|
62
|
+
logins use the config's codenamed ids (e.g. `gpt-5.6-sol`) and reject a bare
|
|
63
|
+
`gpt-5.6`. When the user names a model ("review with 5.6-sol"), pass it here.
|
|
64
|
+
- `CODEX_REVIEW_EFFORT` — reasoning effort, default `medium`. The probe and
|
|
65
|
+
review stages accept only `medium` or `high`; any other value is rejected.
|
|
66
|
+
- `CODEX_REVIEW_IDLE_SECONDS` / `CODEX_REVIEW_PROBE_IDLE_SECONDS` — idle timeout
|
|
67
|
+
(seconds) for the review stage and the preflight probe, default `180` each.
|
|
68
|
+
- `CODEX_REVIEW_ARTIFACT_ROOT` — directory for the recorded review transcript
|
|
69
|
+
used as outside-review evidence, default `<cwd>/.webpresso/reviews`.
|
|
70
|
+
|
|
53
71
|
## Modes
|
|
54
72
|
|
|
55
73
|
### Review
|
|
@@ -59,6 +77,8 @@ Codex native subagent events are not currently parent-linked in the managed life
|
|
|
59
77
|
3. Run Codex through the typed review runtime in read-only mode:
|
|
60
78
|
|
|
61
79
|
```bash
|
|
80
|
+
# CODEX_REVIEW_MODEL / CODEX_REVIEW_EFFORT are overridable — see ## Options for
|
|
81
|
+
# the full option list, valid values, and how to pick a login-supported model.
|
|
62
82
|
CODEX_REVIEW_MODEL=${CODEX_REVIEW_MODEL:-gpt-5.4}
|
|
63
83
|
CODEX_REVIEW_EFFORT=${CODEX_REVIEW_EFFORT:-medium}
|
|
64
84
|
case "$CODEX_REVIEW_EFFORT" in
|
package/skills/fix/SKILL.md
CHANGED
|
@@ -9,7 +9,7 @@ related: [verify, testing-philosophy]
|
|
|
9
9
|
created: "2026-05-13"
|
|
10
10
|
last_reviewed: "2026-05-22"
|
|
11
11
|
name: fix
|
|
12
|
-
description: "Root-cause fix workflow
|
|
12
|
+
description: "Root-cause fix workflow that runs investigate first when diagnosis or failing proof is still missing."
|
|
13
13
|
argument-hint: '<target> where target is: file|symptom|error|test|"free-text description"'
|
|
14
14
|
---
|
|
15
15
|
|
|
@@ -19,16 +19,9 @@ Fix the issue at its root, future-proof, aligned with repo philosophy.
|
|
|
19
19
|
|
|
20
20
|
**Arguments**: $ARGUMENTS
|
|
21
21
|
|
|
22
|
-
This command turns "please fix it well" into an enforceable workflow:
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
`/investigate` and `systematic-debugging` are folded into this workflow. Keep the
|
|
27
|
-
old iron law: no fixes before evidence. Reproduce or capture the failure, read
|
|
28
|
-
the complete error/stack, trace the bad value or broken invariant to its owner,
|
|
29
|
-
compare with a working local pattern, and disconfirm cheap hypotheses before
|
|
30
|
-
editing. If the issue crosses component boundaries, add temporary diagnostics at
|
|
31
|
-
each boundary, run once, then remove or convert them to durable tests.
|
|
22
|
+
This command turns "please fix it well" into an enforceable workflow: diagnose
|
|
23
|
+
first, repair at the owner, prove the repair, and escalate to `/verify` when
|
|
24
|
+
the blast radius is broader than a local fix.
|
|
32
25
|
|
|
33
26
|
## Non-negotiable invariants
|
|
34
27
|
|
|
@@ -42,6 +35,26 @@ each boundary, run once, then remove or convert them to durable tests.
|
|
|
42
35
|
|
|
43
36
|
## Protocol
|
|
44
37
|
|
|
38
|
+
### Step 0 — Run the investigate phase when evidence is missing
|
|
39
|
+
|
|
40
|
+
Before editing, check whether the current context already contains all of the
|
|
41
|
+
following:
|
|
42
|
+
|
|
43
|
+
- a named root-cause hypothesis
|
|
44
|
+
- a failing proof tied to that hypothesis
|
|
45
|
+
- the owning boundary that should be repaired
|
|
46
|
+
|
|
47
|
+
If any of those are missing, run the `investigate` phase inline first:
|
|
48
|
+
|
|
49
|
+
- reproduce or capture the failure
|
|
50
|
+
- read the full error site and one nearby working pattern
|
|
51
|
+
- disconfirm cheap alternative explanations
|
|
52
|
+
- produce failing proof
|
|
53
|
+
- stop only when you can name the broken invariant and owner
|
|
54
|
+
|
|
55
|
+
Do not skip this phase because the fix "looks obvious". If the evidence is not
|
|
56
|
+
there, the investigation work is part of `fix`.
|
|
57
|
+
|
|
45
58
|
### Step 1 — Reproduce and name the broken invariant
|
|
46
59
|
|
|
47
60
|
- Run the exact command, test, or user flow that surfaces the failure.
|
|
@@ -98,6 +111,9 @@ Escalate to `/verify <target>` when any of these are true:
|
|
|
98
111
|
- the fix touched docs, plans, blueprints, or repo SSOT
|
|
99
112
|
- the fix needs dead-code / compat / broad regression review before claiming done
|
|
100
113
|
|
|
114
|
+
If the repaired behavior is already green but the diff still needs a bounded
|
|
115
|
+
cleanup pass, use `ai-deslop` before the final verify handoff.
|
|
116
|
+
|
|
101
117
|
### Step 6 — Report with evidence
|
|
102
118
|
|
|
103
119
|
Keep it short:
|
|
@@ -0,0 +1,61 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: investigate
|
|
3
|
+
description: "Root-cause investigation workflow: reproduce, isolate, prove, and hand off the minimal repair scope."
|
|
4
|
+
license: MIT
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Investigate
|
|
8
|
+
|
|
9
|
+
Use this skill when the task is to understand a bug, failure, regression,
|
|
10
|
+
flaky behavior, or confusing symptom before editing code.
|
|
11
|
+
|
|
12
|
+
## Boundary
|
|
13
|
+
|
|
14
|
+
- `investigate` owns diagnosis, reproduction, hypothesis testing, and proof.
|
|
15
|
+
- `fix` owns repair. If the user asked to fix the problem and root-cause
|
|
16
|
+
evidence is still missing, `fix` should run this phase inline first.
|
|
17
|
+
- Stop once you can name the broken invariant, show the failing proof, and
|
|
18
|
+
point at the owner that should be repaired.
|
|
19
|
+
|
|
20
|
+
## Workflow
|
|
21
|
+
|
|
22
|
+
1. Reproduce or capture the failure.
|
|
23
|
+
- Run the exact failing command or trace the exact user path.
|
|
24
|
+
- Keep the evidence that matters: error text, failing assertion, exit code,
|
|
25
|
+
log path, or boundary mismatch.
|
|
26
|
+
2. Read the whole boundary.
|
|
27
|
+
- Inspect the full error site, the owning module, and one nearby working
|
|
28
|
+
pattern.
|
|
29
|
+
- Do not edit code yet.
|
|
30
|
+
3. State the root-cause hypothesis.
|
|
31
|
+
- Name the broken invariant in one sentence.
|
|
32
|
+
- Name the owner that should enforce it.
|
|
33
|
+
- Separate facts from guesses.
|
|
34
|
+
4. Disconfirm cheap alternatives.
|
|
35
|
+
- Test the obvious competing explanations before settling on one cause.
|
|
36
|
+
- Add temporary diagnostics only when needed, and remove them after one pass.
|
|
37
|
+
5. Produce failing proof.
|
|
38
|
+
- Prefer a targeted failing test.
|
|
39
|
+
- If test-first is impossible at this boundary, use the nearest deterministic
|
|
40
|
+
reproduction instead.
|
|
41
|
+
6. Hand off the minimal repair scope.
|
|
42
|
+
- List the owner, direct consumers, and the smallest safe verification set.
|
|
43
|
+
- If the issue is broader than one coherent repair, say so before any edit.
|
|
44
|
+
|
|
45
|
+
## Output
|
|
46
|
+
|
|
47
|
+
Return:
|
|
48
|
+
|
|
49
|
+
- reproduced symptom
|
|
50
|
+
- broken invariant
|
|
51
|
+
- root-cause hypothesis status: confirmed / likely / blocked
|
|
52
|
+
- failing proof
|
|
53
|
+
- owning file or boundary
|
|
54
|
+
- recommended next step: `fix`, `verify`, or a scoped blocker
|
|
55
|
+
|
|
56
|
+
## Anti-patterns
|
|
57
|
+
|
|
58
|
+
- Editing before you can name the invariant
|
|
59
|
+
- Treating a stack trace as proof of root cause
|
|
60
|
+
- Hiding uncertainty behind broad "probably X" explanations
|
|
61
|
+
- Expanding a debugging pass into cleanup or refactor work
|
|
@@ -32,6 +32,7 @@ A plan is only as strong as its weakest unchecked assumption and only as fast as
|
|
|
32
32
|
## Mandatory gates
|
|
33
33
|
|
|
34
34
|
- Apply DRY, SOLID, YAGNI, and KISS; reject speculative abstractions.
|
|
35
|
+
- Choose the most elegant and durable solution the constraints allow, not merely a correct one: prefer deleting/reusing over adding, shrink public/export surface to the minimum real consumers require, keep the change scoped to one coherent idea, and reject the heavier option even when it works — record in the plan why the chosen shape is the durable one.
|
|
35
36
|
- For package, catalog, generated-surface, or release changes, require package-surface and public-content checks.
|
|
36
37
|
- Prefer deletion/reuse over new layers or dependencies.
|
|
37
38
|
- Stop on unverified external claims, unresolved shared-file conflicts, or missing authority for destructive work.
|
package/skills/verify/SKILL.md
CHANGED
|
@@ -17,7 +17,9 @@ argument-hint: "<target> [--full] where target is: package|file|plan-slug|all"
|
|
|
17
17
|
|
|
18
18
|
Post-implementation quality gate. Run after implementation exists, before claiming `done`.
|
|
19
19
|
|
|
20
|
-
`/fix` owns
|
|
20
|
+
`/fix` owns investigation-if-missing, root-cause analysis, and the minimal
|
|
21
|
+
repair. `/verify` owns the broader question: **is this work actually complete,
|
|
22
|
+
integrated, and free of stale garbage?**
|
|
21
23
|
|
|
22
24
|
## Iron law — evidence before claims
|
|
23
25
|
|
|
@@ -125,6 +127,10 @@ For command-surface, install/setup/update, or operator-guidance changes, explici
|
|
|
125
127
|
|
|
126
128
|
Hard stop if a shared contract changed and consumers were not updated.
|
|
127
129
|
|
|
130
|
+
Every session that changes behavior, commands, setup, or operator guidance must
|
|
131
|
+
update every affected doc/help/instruction surface in the same change. Keep
|
|
132
|
+
those doc edits concise and direct.
|
|
133
|
+
|
|
128
134
|
## Phase 4 — Test quality and behavioral audit
|
|
129
135
|
|
|
130
136
|
The passing test suite is necessary, not sufficient.
|
|
@@ -149,6 +155,10 @@ Before claiming done:
|
|
|
149
155
|
- justify every new exported/helper surface with a real consumer or test
|
|
150
156
|
- run the repo's dead-code / dependency checks when the change broadened public surface or added new files
|
|
151
157
|
|
|
158
|
+
If behavior is already locked and the remaining work is purely anti-slop
|
|
159
|
+
cleanup, route that pass through `ai-deslop` first rather than broadening
|
|
160
|
+
`verify` into a writer lane.
|
|
161
|
+
|
|
152
162
|
This phase exists to catch the garbage that often slips in beside otherwise-correct work.
|
|
153
163
|
|
|
154
164
|
## Phase 6 — Outside-model approval gate
|
|
@@ -158,7 +168,7 @@ user explicitly asked for a different approval count or reviewer mix.
|
|
|
158
168
|
|
|
159
169
|
Default policy:
|
|
160
170
|
|
|
161
|
-
- Require **
|
|
171
|
+
- Require **one extra model approval** by default. At most **one OpenCode Go reviewer** counts toward the requirement unless the user explicitly asks for multiple OpenCode models.
|
|
162
172
|
- If the user asks for more, fewer, zero, or specific reviewers, follow that
|
|
163
173
|
explicit instruction and report the chosen requirement.
|
|
164
174
|
- These approvals are model outside-voice approvals, not a substitute for
|
|
@@ -166,8 +176,8 @@ Default policy:
|
|
|
166
176
|
|
|
167
177
|
Reviewer preference:
|
|
168
178
|
|
|
169
|
-
- When running from Codex, prefer **Claude
|
|
170
|
-
- When running from Claude, prefer **Codex
|
|
179
|
+
- When running from Codex, prefer **Claude** (fall back to one OpenCode Go reviewer if Claude is unavailable).
|
|
180
|
+
- When running from Claude, prefer **Codex** (fall back to one OpenCode Go reviewer if Codex is unavailable).
|
|
171
181
|
- When Codex/Claude outside voice is unavailable, use **one OpenCode Go
|
|
172
182
|
reviewer** if OpenCode is logged in.
|
|
173
183
|
- Prefer the repo's outside-voice skills instead of hand-rolled commands:
|