resolve-review declares commit_files but runs read-only — validates findings it cannot fix

[Trecek]

Problem

resolve-review declares the capabilities it needs to apply and commit fixes, but ran with a read-only grant and none of the MCP tools its own body instructs it to call. It validated all five review findings correctly and then could not act on any of them.

Observed 2026-07-26 resolving review comments on PR #4378 (issue #4351).

Read this first — a confound to eliminate before anything else

The invocation used the wrong positional signature. SKILL.md:23 documents:

/autoskillit:resolve-review <feature_branch> <base_branch> [mode=<local|github>]

The call actually made was:

/autoskillit:resolve-review 4378 /home/talon/projects/autoskillit-runs/worktrees/impl-4351-20260726-164021 <prose>

so feature_branch="4378" and base_branch="<a worktree path>". Step 1 of any work on this ticket is to reproduce with the correct signature. If correct arguments produce a writable session, this is not a capability defect and the real finding is that the skill accepts nonsense positionals without validating them — which is still worth fixing, but is a different fix.

The reason this is filed as a capability defect rather than closed as operator error: the write guard's read-only decision is made per-skill at session setup, before positional arguments are parsed, so bad arguments are not an obvious mechanism for it. That reasoning is an inference, not a measurement. Verify it.

What was observed

The session reported, and confirmed empirically by attempting both an Edit and a Bash sed -i:

Write/Edit/apply_patch blocked: read-only skill session.

and separately that commit_files, test_check, run_skill and open_kitchen were not present in its tool surface.

Result: four findings classified ACCEPT, one DISCUSS, and zero fixes applied. The skill correctly declined to post "fixed" replies for fixes it had not made, so the review threads were left with no replies at all. It also explicitly declined to route around the guard, correctly identifying it as an architectural control rather than a bug to bypass.

The declared-versus-granted contradiction

src/autoskillit/skills_extended/resolve-review/SKILL.md:4:

uses_capabilities: [agent_model, commit_files, github_api_write]

The skill body is unambiguous that these are load-bearing:

• :17-18 — "apply targeted fixes for actionable findings, commit each fix, and verify tests still pass"
• :75 — "call commit_files(paths=[<dirty files>], message=..., cwd=...). Count any failed call toward fix_failures."
• :60, :84 — run {test_command} after applying fixes; "The test_check MCP tool runs all configured commands automatically."

Supporting registry facts:

• core/types/_type_constants_registries.py:144 — HEADLESS_TOOLS contains test_check, unlock_agent_pack, commit_files
• :725 — "commit_files": frozenset({"kitchen-core"}), i.e. gated behind the kitchen-core agent pack
• :847 — SkillCapabilityDef for commit_files, "server-side git stage/commit"
• hooks/guards/write_guard.py:51 — WRITE_GUARD_DENY_TRIGGER = "read-only skill session"

A skill whose declared capability set includes commit_files should not receive a grant under which commit_files is absent and all write tools are denied. Either the declaration is authoritative and the grant is wrong, or the skill is intentionally read-only and its frontmatter, description and body are all wrong. Both cannot be true.

Note grep for a WriteBehaviorSpec naming resolve-review returns nothing, so no explicit read-only write-behaviour spec was found for this skill — the read-only posture appears to come from the default rather than a deliberate declaration. Worth confirming.

Impact

resolve-review is the recipe's review-loop repair step. As observed it can produce verdicts but never repairs, so every changes_requested verdict requires an out-of-band retry-worktree dispatch to apply the accepted fixes. That workaround was used successfully on PR #4378 and is documented in the programme handoff, but it means the review loop does not close on its own.

Secondary effect: review threads accumulate unanswered. resolve-review is the component that posts inline replies, and it correctly refuses to reply about fixes it did not make — so the threads stay open even after the fixes land in commits that reference them.

Related

Same shape as #3888 (CLOSED) — "resolve-failures skill missing git_metadata_write capability — dispatches to Codex where it cannot commit." That is a second skill in the same review/repair family whose declared capabilities did not match its runtime grant. If this reproduces with correct arguments, treat the pair as evidence that capability declarations are not verified against grants anywhere, and fix that rather than this one skill — per the source report, fixes aimed at a single instance of a class are the dominant reason work here fails to hold.

Acceptance

• Reproduced (or refuted) with the documented signature. If refuted, retitle to the argument-validation defect and close this framing.
• If confirmed: a skill declaring commit_files receives a session in which commit_files exists and writes to its work_dir are permitted.
• A test asserts that every skill's uses_capabilities is satisfiable by the grant it actually receives, so a declaration that is not honoured fails in CI rather than at run time.
• resolve-review completes a full validate → fix → commit → reply → test cycle on a PR with changes_requested, with no external retry-worktree step.
• The skill rejects positional arguments that do not match its documented signature instead of proceeding with them.

Wider context

Surfaced while running the remediation programme tracked by the Codex context-consumption report, 2026-07-26 (.autoskillit/temp/audit-friction/codex_context_report_2026-07-26.html; see its Handoff tab). Sibling machinery defects found in the same run: #4376, #4377.

---

Occurrence update — 2026-07-27 (session processing #4303 + #4369)

The premise does not reproduce. resolve-review applied fixes, committed them, resolved threads and posted inline replies in both modes during PR #4384.

Invocation	Result
/autoskillit:resolve-review codex-pin-reverify/4369 develop mode=local	3 findings fetched, 1 ACCEPT, fix applied and committed as f07bb78ce. Full suite re-run green.
/autoskillit:resolve-review codex-pin-reverify/4369 develop mode=github	3 inline comments fetched, 3 ACCEPT, fixes applied and committed as 9242b56aa and caa297608. All 3 threads resolved via batched GraphQL, 3 inline replies posted with autoskillit:resolved markers.

Both invocations used the documented positional signature <merge_target> <base_branch> mode=<mode> with cwd set to the clone and output_dir set to ..

One real defect surfaced, narrower than the title claims. In mode=local the session reported: "The commit_files MCP tool isn't available in this session — I'll fall back to plain git commands." It then completed the commit via plain git. So the declared commit_files tool is genuinely absent from the skill's tool grant, but the skill is not read-only — it degrades to git and still writes.

Suggested re-scoping. The actionable defect is the missing commit_files grant (and the resulting undeclared dependency on plain git being permitted), not an inability to fix. Retitle toward that, or close as not-reproducible and open a narrow issue for the tool grant. The prior observation was recorded in the programme handoff as possibly originating from a call with wrong positionals; this session is consistent with that explanation.

Handoff correction. The standing guidance "use resolve-review for verdicts only, then apply accepted fixes via retry-worktree" is now believed unnecessary and has been removed from the programme handoff.