@webpresso/codex-plugin 3.1.12 → 3.1.14

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.
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "agent-kit",
3
- "version": "3.1.12",
3
+ "version": "3.1.14",
4
4
  "description": "Webpresso agent-kit: blueprints, skills, hooks, and MCP server",
5
5
  "author": {
6
6
  "name": "Webpresso",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@webpresso/codex-plugin",
3
- "version": "3.1.12",
3
+ "version": "3.1.14",
4
4
  "private": false,
5
5
  "description": "Codex plugin adapter for Webpresso agent-kit skills, hooks, and MCP runtime.",
6
6
  "homepage": "https://github.com/webpresso/agent-kit#readme",
@@ -2,15 +2,15 @@
2
2
  "schemaVersion": 1,
3
3
  "host": "codex",
4
4
  "packageName": "@webpresso/codex-plugin",
5
- "packageVersion": "3.1.12",
6
- "runtimeDirs": [
7
- ".codex/skills",
8
- ".agents/skills"
9
- ],
5
+ "packageVersion": "3.1.14",
6
+ "runtimeDirs": [".codex/skills", ".agents/skills"],
10
7
  "skills": {
11
8
  "autopilot": {
12
9
  "digest": "sha256:7fc1fe9f5fb5b8a3e755f8e3ac4b807e4f140288544ffcf39e4cbfdea984014d"
13
10
  },
11
+ "autoresearch": {
12
+ "digest": "sha256:b4d51cd53beb4a3271827172dfbd0b1d27bd58761ca07a35d49a5d6324b87fdf"
13
+ },
14
14
  "best-practice-research": {
15
15
  "digest": "sha256:b0d355c7f4afe9c38be83e293788bf582bea068c1db2fa5c45400441e315735d"
16
16
  },
@@ -18,10 +18,10 @@
18
18
  "digest": "sha256:21fd24862e7f7c8a1feadea6bc376492b136b99fc381cf1b8927c9db80615431"
19
19
  },
20
20
  "claude": {
21
- "digest": "sha256:b75a472594d78bd9452c07fd791a426864848a2c9c726454dc72daf3813ae22b"
21
+ "digest": "sha256:2af483ef80c5e0cf3d6d3da94d54b5bd1e9cecc9b2bd05e085499c2745c2c238"
22
22
  },
23
23
  "codex": {
24
- "digest": "sha256:803cea9c1b37406d7bdc8e44e9d5e9f3988218277500d8d6cb0d955c933c3302"
24
+ "digest": "sha256:e8289cb51d023d8b20c1bfb2e349ee89c4d04cdfd5a03c7681328b3e60aab554"
25
25
  },
26
26
  "deep-research": {
27
27
  "digest": "sha256:01dafd194066a2936db0b437fd5c3beef6d7ff82478d0d995393093d89496f18"
@@ -45,7 +45,7 @@
45
45
  "digest": "sha256:a80fbacc765e8b886437b9fdf7dd71e1ceb1b98b939078ec90fc88d06a8b4c69"
46
46
  },
47
47
  "opencode-go": {
48
- "digest": "sha256:ccb2bcf09cc1c5c0d54027b84f580e688f5f5cf624e6cdc19870bd3ce99940fc"
48
+ "digest": "sha256:8bbfad8273c526c563ceef3c8b98efbc60c3b24dc6b0a2a25d8efd9e83788860"
49
49
  },
50
50
  "plan-ceo-review": {
51
51
  "digest": "sha256:4d426158518dd71f8998770e8d4037bcbfa3c65d7265a93a4a78a9b015ba881e"
@@ -62,6 +62,12 @@
62
62
  "plan-refine": {
63
63
  "digest": "sha256:891e84ff8592b8489b59e8642f6a602c9558fd57edd171af98499c94e2f62f13"
64
64
  },
65
+ "ralplan": {
66
+ "digest": "sha256:db285d477f43ed23df990d4c03750d9916cdc7809356c1bf025efdf6a9add9ed"
67
+ },
68
+ "team": {
69
+ "digest": "sha256:151ef81df917435073a2d7b41173d33c45cb8aa1e5fdf34a70043bb3a2e746ff"
70
+ },
65
71
  "tech-debt": {
66
72
  "digest": "sha256:8b1f30e55ec6e5ab185ff19ecf15384438dbd619f675c2c65f2e53cedecbae5c"
67
73
  },
@@ -72,7 +78,7 @@
72
78
  "digest": "sha256:bed3684a850651534f315d355cdeae50d951c429817df0f105cccdb7f4e1561b"
73
79
  },
74
80
  "verify": {
75
- "digest": "sha256:b088b138a985f94e29970edac1bcae70b29b15b5b3573787652ad590b789c9c7"
81
+ "digest": "sha256:ce0dd3a77508d1bf11c805dec2de04e75b689201d376b2ff0fa957604d584500"
76
82
  }
77
83
  }
78
- }
84
+ }
@@ -0,0 +1,49 @@
1
+ ---
2
+ type: skill
3
+ slug: autoresearch
4
+ title: Autoresearch
5
+ status: active
6
+ scope: repo
7
+ applies_to: [agents]
8
+ related: [deep-research, best-practice-research, plan-refine, verify]
9
+ created: "2026-07-13"
10
+ last_reviewed: "2026-07-13"
11
+ name: autoresearch
12
+ description: "Artifact-gated research loop with explicit validation."
13
+ argument-hint: "<research mission and validator>"
14
+ ---
15
+
16
+ # Autoresearch
17
+
18
+ Use when the user wants research to continue until a concrete validator accepts the result. This is for bounded research deliverables, not quick factual lookup or ordinary planning context.
19
+
20
+ ## Boundary
21
+
22
+ - Use `deep-research` for one-pass citation-backed reports.
23
+ - Use `best-practice-research` for focused upstream guidance.
24
+ - Use `autoresearch` when completion depends on an explicit evaluator, benchmark, review rubric, or acceptance artifact.
25
+
26
+ ## Workflow
27
+
28
+ 1. Define the research mission, output artifact path, validator, and stop condition.
29
+ 2. Choose one validation mode:
30
+ - command validator: a repo command or script must pass and write the result.
31
+ - review validator: an independent review must approve the produced artifact against the mission.
32
+ 3. Create or update the durable research artifact before iterating.
33
+ 4. Gather sources and repo context until the artifact addresses the mission and cites material claims.
34
+ 5. Run the validator. If it fails, preserve the failure evidence, revise the artifact, and repeat.
35
+ 6. Stop only when the validator passes or a blocker prevents more evidence-gathering.
36
+
37
+ ## Output
38
+
39
+ Return:
40
+
41
+ - mission
42
+ - artifact path
43
+ - validation mode
44
+ - validator command or review rubric
45
+ - evidence gathered
46
+ - pass/fail result
47
+ - remaining gaps or blocker
48
+
49
+ Do not treat elapsed turns, model confidence, or a draft report as completion evidence. Completion requires the declared validator to pass.
@@ -57,7 +57,7 @@ Claude's managed native subagent lifecycle does not provide a reliable parent-li
57
57
 
58
58
  Use single-file / single-question first for any non-trivial diff. Do not send a whole PR unless it already fits within the bounded payload below.
59
59
 
60
- **Model policy:** default to `sonnet` via `CLAUDE_REVIEW_MODEL=${CLAUDE_REVIEW_MODEL:-sonnet}`. Override to `opus` only when the review is approval evidence or the user explicitly asks for Opus. Never use `fable` for Claude outside-voice review. Any review used as blueprint approval evidence MUST run with Claude Opus and record `"model": "opus"`.
60
+ **Model policy:** default to the moving `opus` alias via `CLAUDE_REVIEW_MODEL=${CLAUDE_REVIEW_MODEL:-opus}`. Never use `fable` for Claude outside-voice review. Any review used as blueprint approval evidence MUST run with Claude Opus and record `"model": "opus"`.
61
61
 
62
62
  #### Bounded prompt payload
63
63
 
@@ -95,7 +95,7 @@ TARGET_FILE=${TARGET_FILE:?set TARGET_FILE to one changed file}
95
95
  Run both the availability probe and the full review through the typed `wp review run` owner. Skills must not embed subprocess supervision. The runtime consumes Claude's streaming JSON events, advances its idle clock only on monotonic semantic progress, and has no total wall-clock cutoff.
96
96
 
97
97
  ```bash
98
- CLAUDE_REVIEW_MODEL=${CLAUDE_REVIEW_MODEL:-sonnet}
98
+ CLAUDE_REVIEW_MODEL=${CLAUDE_REVIEW_MODEL:-opus}
99
99
  CLAUDE_REVIEW_EFFORT=${CLAUDE_REVIEW_EFFORT:-medium}
100
100
  CLAUDE_REVIEW_PROBE_IDLE_SECONDS=${CLAUDE_REVIEW_PROBE_IDLE_SECONDS:-180}
101
101
  CLAUDE_REVIEW_IDLE_SECONDS=${CLAUDE_REVIEW_IDLE_SECONDS:-180}
@@ -104,7 +104,8 @@ PROBE_FILE=$(mktemp -t wp-claude-probe.XXXXXX)
104
104
  trap 'rm -f "$PROMPT_FILE" "$PROBE_FILE"' EXIT
105
105
  printf 'Reply exactly CLAUDE_OK.\n' >"$PROBE_FILE"
106
106
 
107
- wp review run \
107
+ CLAUDE_REVIEW_CODE=0
108
+ if wp review run \
108
109
  --provider claude \
109
110
  --prompt-file "$PROBE_FILE" \
110
111
  --model "$CLAUDE_REVIEW_MODEL" \
@@ -112,17 +113,20 @@ wp review run \
112
113
  --stage probe \
113
114
  --expected-marker CLAUDE_OK \
114
115
  --artifact-root "$CLAUDE_REVIEW_ARTIFACT_ROOT" \
115
- --idle-seconds "$CLAUDE_REVIEW_PROBE_IDLE_SECONDS"
116
-
117
- wp review run \
118
- --provider claude \
119
- --prompt-file "$PROMPT_FILE" \
120
- --model "$CLAUDE_REVIEW_MODEL" \
121
- --effort "$CLAUDE_REVIEW_EFFORT" \
122
- --stage review \
123
- --artifact-root "$CLAUDE_REVIEW_ARTIFACT_ROOT" \
124
- --idle-seconds "$CLAUDE_REVIEW_IDLE_SECONDS"
125
- CLAUDE_REVIEW_CODE=$?
116
+ --idle-seconds "$CLAUDE_REVIEW_PROBE_IDLE_SECONDS"; then
117
+ wp review run \
118
+ --provider claude \
119
+ --prompt-file "$PROMPT_FILE" \
120
+ --model "$CLAUDE_REVIEW_MODEL" \
121
+ --effort "$CLAUDE_REVIEW_EFFORT" \
122
+ --stage review \
123
+ --artifact-root "$CLAUDE_REVIEW_ARTIFACT_ROOT" \
124
+ --idle-seconds "$CLAUDE_REVIEW_IDLE_SECONDS"
125
+ CLAUDE_REVIEW_CODE=$?
126
+ else
127
+ CLAUDE_REVIEW_CODE=$?
128
+ echo "Claude preflight failed; full review not started." >&2
129
+ fi
126
130
  ```
127
131
 
128
132
  After the review runtime exits, emit its terminal state using the same artifact path:
@@ -56,16 +56,45 @@ Codex native subagent events are not currently parent-linked in the managed life
56
56
 
57
57
  1. Capture the current branch, base branch, and `git diff --stat`.
58
58
  2. Write a concise prompt asking Codex to find correctness, security, data-loss, and maintainability risks.
59
- 3. Run Codex non-interactively in read-only mode:
59
+ 3. Run Codex through the typed review runtime in read-only mode:
60
60
 
61
61
  ```bash
62
+ CODEX_REVIEW_MODEL=${CODEX_REVIEW_MODEL:-gpt-5.4}
62
63
  CODEX_REVIEW_EFFORT=${CODEX_REVIEW_EFFORT:-medium}
63
64
  case "$CODEX_REVIEW_EFFORT" in
64
65
  medium|high) ;;
65
66
  *) echo "CODEX_REVIEW_EFFORT must be one of: medium, high" >&2; exit 2 ;;
66
67
  esac
68
+ CODEX_REVIEW_PROBE_IDLE_SECONDS=${CODEX_REVIEW_PROBE_IDLE_SECONDS:-180}
69
+ CODEX_REVIEW_IDLE_SECONDS=${CODEX_REVIEW_IDLE_SECONDS:-180}
70
+ CODEX_REVIEW_ARTIFACT_ROOT=${CODEX_REVIEW_ARTIFACT_ROOT:-"$(pwd)/.webpresso/reviews"}
71
+ PROBE_FILE=$(mktemp -t wp-codex-probe.XXXXXX)
72
+ trap 'rm -f "$PROMPT_FILE" "$PROBE_FILE"' EXIT
73
+ printf 'Reply exactly CODEX_OK.\n' >"$PROBE_FILE"
74
+
67
75
  CODEX_REVIEW_CODE=0
68
- codex exec -c model_reasoning_effort="\"$CODEX_REVIEW_EFFORT\"" --sandbox read-only --cd "$PWD" - <"$PROMPT_FILE" || CODEX_REVIEW_CODE=$?
76
+ if wp review run \
77
+ --provider codex \
78
+ --prompt-file "$PROBE_FILE" \
79
+ --model "$CODEX_REVIEW_MODEL" \
80
+ --effort "$CODEX_REVIEW_EFFORT" \
81
+ --stage probe \
82
+ --expected-marker CODEX_OK \
83
+ --artifact-root "$CODEX_REVIEW_ARTIFACT_ROOT" \
84
+ --idle-seconds "$CODEX_REVIEW_PROBE_IDLE_SECONDS"; then
85
+ wp review run \
86
+ --provider codex \
87
+ --prompt-file "$PROMPT_FILE" \
88
+ --model "$CODEX_REVIEW_MODEL" \
89
+ --effort "$CODEX_REVIEW_EFFORT" \
90
+ --stage review \
91
+ --artifact-root "$CODEX_REVIEW_ARTIFACT_ROOT" \
92
+ --idle-seconds "$CODEX_REVIEW_IDLE_SECONDS"
93
+ CODEX_REVIEW_CODE=$?
94
+ else
95
+ CODEX_REVIEW_CODE=$?
96
+ echo "Codex preflight failed; full review not started." >&2
97
+ fi
69
98
  ```
70
99
 
71
100
  4. Summarize findings with severity, evidence, and whether you independently verified them.
@@ -82,7 +82,7 @@ PROBE_FILE=$(mktemp -t wp-opencode-go-probe.XXXXXX)
82
82
  trap 'rm -f "$PROMPT_FILE" "$PROBE_FILE"' EXIT
83
83
  printf 'Reply exactly OPENCODE_GO_OK.\n' >"$PROBE_FILE"
84
84
 
85
- wp review run \
85
+ if ! wp review run \
86
86
  --provider opencode \
87
87
  --prompt-file "$PROBE_FILE" \
88
88
  --model "$MODEL" \
@@ -90,7 +90,10 @@ wp review run \
90
90
  --stage probe \
91
91
  --expected-marker OPENCODE_GO_OK \
92
92
  --artifact-root "$OPENCODE_GO_REVIEW_ARTIFACT_ROOT" \
93
- --idle-seconds "$OPENCODE_GO_PROBE_IDLE_SECONDS"
93
+ --idle-seconds "$OPENCODE_GO_PROBE_IDLE_SECONDS"; then
94
+ echo "OpenCode Go preflight failed; full review not started." >&2
95
+ exit 1
96
+ fi
94
97
 
95
98
  wp review run \
96
99
  --provider opencode \
@@ -103,4 +106,4 @@ wp review run \
103
106
  ```
104
107
 
105
108
  If `$MODEL` is empty, run `opencode models opencode-go` and choose a present reviewer.
106
- Treat `true-idle`, `protocol-unsupported`, provider failure, abort, spawn failure, or artifact failure as unavailable review evidence. Never replace them with a static timeout, arbitrary byte-growth heartbeat, or buffered-output fallback.
109
+ Treat a provider-wide usage limit as terminal for every OpenCode Go model in the current review; do not fall back to another family. Treat `true-idle`, `protocol-unsupported`, provider failure, abort, spawn failure, or artifact failure as unavailable review evidence. Never replace them with a static timeout, arbitrary byte-growth heartbeat, or buffered-output fallback.
@@ -0,0 +1,50 @@
1
+ ---
2
+ type: skill
3
+ slug: ralplan
4
+ title: Ralplan Consensus Planning
5
+ status: active
6
+ scope: repo
7
+ applies_to: [agents]
8
+ related: [plan-refine, plan-eng-review, plan-ceo-review, plan-design-review, plan-devex-review]
9
+ created: "2026-07-13"
10
+ last_reviewed: "2026-07-13"
11
+ name: ralplan
12
+ description: "Consensus planning gate for plan-refine"
13
+ ---
14
+
15
+ # Ralplan Consensus Planning
16
+
17
+ Use when the user invokes `$ralplan`, asks for RALPLAN, or wants consensus planning before execution.
18
+
19
+ `ralplan` is an agent-kit planning gate, not an implementation lane. It applies consensus review to a durable plan before execution starts.
20
+
21
+ ## Workflow
22
+
23
+ 1. Create or identify the durable blueprint or plan artifact that will own the work.
24
+ 2. Run the `plan-refine` methodology against that artifact: verify local code facts, verify external claims when relevant, sharpen acceptance criteria, split independent work, and lock verification gates.
25
+ 3. Apply the relevant review lenses before execution:
26
+ - `plan-eng-review` for architecture, sequencing, tests, and rollout risk.
27
+ - `plan-ceo-review` when scope, customer value, or sequencing tradeoffs matter.
28
+ - `plan-design-review` when UI/UX is material.
29
+ - `plan-devex-review` when docs, CLI/API ergonomics, onboarding, or migration risk is material.
30
+ 4. Consolidate the reviews into one decision record with:
31
+ - decision and drivers
32
+ - alternatives considered
33
+ - material corrections
34
+ - implementation tasks and dependencies
35
+ - verification gates
36
+ - residual risks or blockers
37
+ 5. Stop at an approved plan or an explicit blocker. Do not edit implementation code from this skill unless the user explicitly changes the task from planning to execution.
38
+
39
+ ## Output
40
+
41
+ Return a concise consensus plan with:
42
+
43
+ - verdict: ready / ready with edits / blocked
44
+ - decision and rationale
45
+ - accepted review findings
46
+ - task breakdown
47
+ - required verification
48
+ - recommended execution lane, usually `goal` for durable sequential work or `autopilot` for the full autonomous pipeline
49
+
50
+ Use `plan-refine` as the detailed checklist source of truth when deeper plan surgery is needed.
@@ -0,0 +1,60 @@
1
+ ---
2
+ type: skill
3
+ slug: team
4
+ title: Team
5
+ status: active
6
+ scope: repo
7
+ applies_to: [agents]
8
+ related: [autopilot, goal, plan-refine, verify]
9
+ created: "2026-07-13"
10
+ last_reviewed: "2026-07-13"
11
+ name: team
12
+ description: "Coordinate multiple dashboard-backed agent sessions on one task."
13
+ argument-hint: "<brief|role plan>"
14
+ ---
15
+
16
+ # Team
17
+
18
+ Use `team` when the work needs coordinated parallel lanes with a leader-owned
19
+ task list, explicit handoffs, and independent verification. Prefer native
20
+ subagents for small bounded lookups; use `team` when the parallel work should be
21
+ visible, durable, and operator-controllable from `wp dash`.
22
+
23
+ ## Protocol
24
+
25
+ 1. Start from a grounded brief or an approved blueprint. If scope is vague, run
26
+ `plan-refine` first and define task lanes, shared files, and verification.
27
+ 2. Open or reuse `wp dash` and launch the provider sessions needed for the
28
+ lanes. Direct `wp claude`, `wp codex`, and `wp opencode` commands are
29
+ expected to enter the dashboard in interactive terminals.
30
+ 3. Assign one owner per lane. Include the task, allowed files or surfaces,
31
+ expected output, verification command, and blocker-report rule.
32
+ 4. Keep one lane or leader pass responsible for integration and evidence.
33
+ Workers report findings, patches, tests, and unresolved risks; they do not
34
+ self-approve or mark blueprint tasks complete.
35
+ 5. Integrate only after checking shared-file conflicts, updated assumptions,
36
+ and verification evidence. Use `wp_blueprint_task_verify` for task completion
37
+ when a blueprint owns the work.
38
+ 6. Stop when every lane is complete, cancelled, or explicitly blocked and the
39
+ leader has recorded verification evidence.
40
+
41
+ ## Coordination Rules
42
+
43
+ - Use a single source of truth for assignments: the blueprint, goal handoff, or
44
+ leader-maintained task list.
45
+ - Require ACK-style lane starts for shared files, dependency boundaries, or
46
+ handoffs.
47
+ - Reassign or narrow blocked lanes instead of letting work drift.
48
+ - Escalate changed assumptions before widening scope.
49
+ - Never bypass review provenance, push to main, self-approve, or increase
50
+ timeouts to hide coordination failures.
51
+
52
+ ## Output
53
+
54
+ Report:
55
+
56
+ - lane roster and ownership
57
+ - files or surfaces touched by each lane
58
+ - integration decisions and conflicts resolved
59
+ - verification commands and results
60
+ - remaining blockers or risks
@@ -7,14 +7,10 @@ scope: repo
7
7
  applies_to: [agents]
8
8
  related: [testing-philosophy, tph]
9
9
  created: "2026-05-07"
10
- last_reviewed: "2026-07-03"
10
+ last_reviewed: "2026-07-13"
11
11
  name: verify
12
12
  description: "Post-implementation quality gate: run checks, TPH audit, cleanup, docs, proof."
13
13
  argument-hint: "<target> [--full] where target is: package|file|plan-slug|all"
14
- hooks:
15
- Stop:
16
- - command: wp audit agents
17
- timeout: 20
18
14
  ---
19
15
 
20
16
  # Verify