Skip to content

feat(work-items): absorb v4 loop-prompt execution rules into work skill (#479) - #563

Merged
kyle-sexton merged 8 commits into
mainfrom
feat/479-work-skill-absorb-v4-rules
Jul 20, 2026
Merged

feat(work-items): absorb v4 loop-prompt execution rules into work skill (#479)#563
kyle-sexton merged 8 commits into
mainfrom
feat/479-work-skill-absorb-v4-rules

Conversation

@kyle-sexton

@kyle-sexton kyle-sexton commented Jul 19, 2026

Copy link
Copy Markdown
Contributor

Summary

Absorbs the proven v4 loop-prompt execution rules into the work-items work skill (#479's rule-lifecycle: prompt rule → proven over days → skill absorption). The seven absorbed rules land as durable skill behavior; week-priority directives and batch numbers deliberately stay prompt-level. Composed atop main's 0.12.3 as 0.13.0.

Fix

Verification

Closes #479

Related

…ll (#479)

Absorb 7 session-prompt execution rules into /work-items:work's execute step so
the skill owns them instead of a hand prompt, delegating anything a sibling skill
already owns rather than restating it.

- Orchestrator-dispatch as the documented default for autonomous execution, chaining
  to /implementation:implement-dispatch for mechanics (#451)
- Dispatch brief carries the /source-control:pull-request contract forward (#462)
- Post-green review pass; VALID-but-deferred finding requires a filed follow-up
  issue cited in the reply and ## Related, then hand off to /source-control:babysit-prs
- High-blast-radius pre-PR full-diff gate
- Concurrency and batch caps resolve from new userConfig scalars; batch cap bounds a
  cycle, never the loop; same-plugin serialization deferred (#464)
- Staleness pre-check skips a frontier item with an open PR (interim, retire on #463)
- Explicit never-merge boundary

Bumps work-items to 0.13.0 with CHANGELOG, README, and eval coverage.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KyLj6oaFVTE6xFuoYCC2KC
@kyle-sexton kyle-sexton added the automated Opened by automation. label Jul 19, 2026
@claude

claude Bot commented Jul 19, 2026

Copy link
Copy Markdown

Claude finished @kyle-sexton's task in 5m 1s —— View job


PR Review — feat(work-items): absorb v4 loop-prompt execution rules into work skill (#479)

Tasks

  • Gather context and understand the PR
  • Read changed files and diff
  • Review SKILL.md changes (core behavior)
  • Review plugin.json changes (userConfig, version)
  • Review evals.json changes
  • Review CHANGELOG.md and README.md
  • Post findings

Summary

A clean absorption of the 7 v4 rules into the execute step. The cross-skill delegation pattern is well-applied throughout (implement-dispatch owns dispatch mechanics, worktree owns lifecycle, pull-request owns the PR body contract, babysit-prs owns the fleet loop), the userConfig wiring is correct and consistent with repo convention, the version bump (0.12.2 → 0.13.0 minor) is appropriate for the feature additions, and the evals correctly reconcile the old inline-workflow default. Three concerns below, ordered by impact.


Finding 1 — MEDIUM · Correctness gap: the orchestrator PR-creation step is implicit but never stated

File: plugins/work-items/skills/work/SKILL.md · Step 5

The execute sub-step dispatches a worker for "source edits in its own out-of-tree worktree" and the flow then has a diff gate "before a PR is opened" followed by a "post-green review pass." These three steps collectively imply that the orchestrator (not the worker) opens the PR by chaining to /source-control:pull-request — but that instruction is never written.

The risk: the execute bullet also says the worker MUST follow "every step of the consuming project's development workflow." If that workflow says "create a PR" (as many project CLAUDE.md files do), a worker can create the PR itself before the orchestrator's diff gate even runs, rendering the gate useless. The scope-fence restricts "source edits" but the SKILL.md never adds "PR creation is forbidden in the worker brief / handled orchestrator-side."

Suggested addition — between the diff gate and the post-green pass, one sentence:

Chain to /source-control:pull-request to open the PR. The worker's scope fence must list PR-creation operations as FORBIDDEN — the orchestrator opens the PR after the gate, not the worker.

Fix this →


Finding 2 — LOW-MEDIUM · Clarity: work_dispatch_concurrency_cap vs. implement-dispatch's own cap

File: plugins/work-items/skills/work/SKILL.md · line 147

The execute sub-step says the concurrent-wave cap is "owned by /implementation:implement-dispatch" (and implement-dispatch hard-codes "Cap concurrent dispatch waves at 3–5 workers" in its own prose). Then the next sentence says "The maximum concurrent dispatch waves is ${user_config.work_dispatch_concurrency_cap}."

The relationship between the two caps is not stated:

  • Is work_dispatch_concurrency_cap the value passed to implement-dispatch as its wave-cap parameter, overriding its 3–5 default?
  • Or is it a separate work-level cap that could diverge from whatever implement-dispatch enforces internally?

If the intent is the former (the work config feeds implement-dispatch's cap), saying so explicitly avoids an implementation that applies two separate caps in series. If the intent is the latter, it's worth explaining why the work skill needs its own cap on top of implement-dispatch's.

Fix this →


Finding 3 — LOW · Interim skip provides no detection mechanism

File: plugins/work-items/skills/work/SKILL.md · line 125

The "already-in-flight" heuristic correctly marks itself as interim (retire on #463), but names no adapter operation or search query for detecting whether a work item has an open PR. Agents implementing this will invent their own method, creating silent variation. The staleness check bullets above it are more specific (check file exists, check similar tests). Even a one-line hint — e.g., "search open PRs for Closes #<number> or the branch pattern <type>/<N>-" — would bound implementation variance without adding much text.


Other notes (no action needed)

  • min in userConfig: Valid — confirmed used in source-control, knowledge, and claude-ops plugin manifests.
  • Unset-key placeholder behavior: The "surviving literal ${user_config.…} placeholder means that key is unset" instruction is the established codebase pattern, confirmed by docs/extensibility-contract-smoke-tests.md line 150–156 (manifests' default documents the UI; it is not delivered through substitution). Correct as written.
  • Eval feat: markdown-formatter plugin (pilot migration) #3 scenario framing: The prompt presupposes mid-execution state, so it's a knowledge/protocol assertion test rather than an executable scenario. This is an acceptable design choice for documentation-heavy skills, but worth noting it won't catch a skill that dispatches correctly but then breaks at PR-time.
  • Version bump: 0.12.2 → 0.13.0 is correct for feature additions with no breaking changes.
  • CHANGELOG format: Consistent with existing entries.

@claude

claude Bot commented Jul 19, 2026

Copy link
Copy Markdown

Claude finished @kyle-sexton's task in 3m 20s —— View job


PR Review — feat(work-items): absorb v4 loop-prompt execution rules into work skill (#479)

Tasks

  • Gather context and understand the PR
  • Read changed files and diff
  • Review SKILL.md changes (core behavior)
  • Review plugin.json changes (userConfig, version)
  • Review evals.json changes
  • Review CHANGELOG.md and README.md
  • Post findings

Summary

The cross-skill delegation pattern is well applied throughout — implement-dispatch owns dispatch mechanics, worktree owns lifecycle, pull-request owns the PR body contract, babysit-prs owns the fleet loop, and track owns follow-up filing. The userConfig wiring is schema-correct, the version bump (0.12.2 → 0.13.0) is appropriate for feature additions with no breaking changes, the eval reconciliation is accurate, and CHANGELOG / README are consistent with the existing format. Five concerns below, ordered by impact.


Finding 1 — MEDIUM · Correctness gap: orchestrator PR-creation step is implicit but never stated

File: plugins/work-items/skills/work/SKILL.md · line 149

The diff gate bullet reads "Before a PR is opened…" and the review pass reads "After CI is green…" — implying the orchestrator opens the PR between the two. But the PR-creation action is never actually stated: there's no bullet saying "chain to /source-control:pull-request to open the PR."

The follow-on risk: the execute bullet (line 143) requires the worker to "follow every step of the consuming project's development workflow." Many project CLAUDE.md files and workflow skills include a PR-creation step. Without an explicit scope-fence exclusion, a worker can open the PR before the orchestrator's diff gate runs, making the gate a no-op.

Suggested fix — between the diff gate and post-green pass bullets, add:

Chain to /source-control:pull-request to open the PR. The worker's scope fence must list PR-creation as FORBIDDEN — the orchestrator opens the PR after the gate, not the worker.

Fix this →


Finding 2 — LOW-MEDIUM · "Owning subagent" for CI-found fixes is ambiguous

File: plugins/work-items/skills/work/SKILL.md · line 151

"fix branch-owned findings via the owning subagent (the orchestrator still never edits source)"

The worker subagent completed and returned its result before CI ran. Its out-of-tree worktree may have been cleaned up by /source-control:worktree at that point. "Owning subagent" could mean:

  • Re-dispatch the same worker in the same worktree (requires the worktree to still exist)
  • Dispatch a new subagent in a new worktree
  • Re-enter the same subagent if it was kept alive across the CI wait (unusual, expensive)

Each interpretation has different implications for the worktree lifecycle. Since the principle "orchestrator never edits source" applies here, the intent is clearly to re-dispatch — but the worktree lifecycle contract with /source-control:worktree needs to align. One sentence clarifying "dispatch a new scope-fenced fix subagent (same worktree if still open, new worktree otherwise)" would remove the ambiguity.

Fix this →


Finding 3 — LOW-MEDIUM · work_dispatch_concurrency_cap vs implement-dispatch's internal cap: relationship unstated

File: plugins/work-items/skills/work/SKILL.md · line 147

Line 143 states implement-dispatch "owns" the concurrent-wave cap. Line 147 then says "The maximum concurrent dispatch waves is ${user_config.work_dispatch_concurrency_cap}." These two claims create ambiguity about which value governs:

  • Option A: work_dispatch_concurrency_cap is passed to implement-dispatch as its cap parameter (overrides implement-dispatch's internal 3–5 default). One cap total.
  • Option B: work_dispatch_concurrency_cap is a work-skill outer cap applied independently of whatever implement-dispatch enforces internally. Two caps in series.

The plugin.json description says it "Mirrors" the implement-dispatch cap — "mirrors" suggests Option B (separate but aligned). If Option B, it's worth explaining why two separate caps are needed. If Option A, saying "passed to implement-dispatch as its wave-cap parameter" would close the ambiguity.

Fix this →


Finding 4 — LOW · work_cycle_batch_cap enforcement is delegated to /loop but not explained

File: plugins/work-items/skills/work/SKILL.md · line 147

The skill says "Wakeup scheduling and the next-cycle delay are owned by the driving loop (/loop); this skill's contract is only that cycle-end ≠ loop-end." This means work_cycle_batch_cap is a value the skill documents but does not enforce — enforcement is in /loop. A consumer who reads only this skill and sets work_cycle_batch_cap: 5 will not understand that the skill itself never counts items or signals cycle-end; that contract lives in the loop layer.

A one-sentence note — "the batch cap is read by the driving /loop invocation, not enforced within a single skill invocation; this skill selects and executes one item per call" — would help consumers understand the integration point.


Finding 5 — LOW · Already-in-flight check has no detection mechanism

File: plugins/work-items/skills/work/SKILL.md · line 125

The "already-in-flight" heuristic says to skip a frontier item that "already has an open PR" but provides no adapter query or search method. The staleness bullets above it are specific (check file exists, check similar tests exist). A one-line hint would bound variance:

e.g., search open PRs for Closes #<number> in the body or a branch matching <type>/<N>-


Other notes (no action needed)

  • min in userConfig schema: Valid — consistent with source-control, knowledge, and claude-ops plugin manifests.
  • Eval chore: initialize marketplace scaffold #1 reconciliation: The updated expectation and new "Whichever execution path runs…" bullet accurately reflect the new SKILL.md posture. ✓
  • Eval feat: markdown-formatter plugin (pilot migration) #3 scenario framing: Uses mid-execution state as a knowledge/protocol assertion test rather than a runnable scenario — an acceptable and established pattern for documentation-heavy skills, though it won't catch a skill that dispatches correctly but breaks at PR-time.
  • Version bump 0.12.2 → 0.13.0: Correct for feature additions with no breaking changes. ✓
  • CHANGELOG format: Consistent with existing entries. ✓
  • README Configuration section: Accurately describes the new userConfig scalars and preserves the existing "everything else is project-specific" framing. ✓
  • CLAUDE.md alignment: All design rules satisfied — repo-agnostic via ${CLAUDE_PLUGIN_ROOT} and ${user_config.*}, no hardcoded paths, plugin-form-safe, no PII/secrets, versioned. ✓

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3b3e988de8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/skills/work/SKILL.md Outdated
Comment thread plugins/work-items/skills/work/SKILL.md Outdated
The interim already-in-flight staleness check (Step 4) said to skip a
frontier item that "already has an open PR" but named no detection method,
leaving agents to invent their own and vary silently. Point at the two
conventions the skill already establishes: the item's `<type>/<N>-` head
branch pattern and the `Closes #<number>` closing keyword the branch parse
injects. Bounds implementation variance without new machinery; the check
still retires on #463.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown

PR Review — feat(work-items): absorb v4 loop-prompt execution rules

Tasks

  • Read diff, review SKILL.md, plugin.json, evals, README, CHANGELOG
  • Check which prior findings were addressed
  • Post findings

What the second commit fixed

Commit 8686c76 addressed Finding 5 from both prior reviews. The already-in-flight detection at SKILL.md line 125 is well-specified: two concrete match targets (head-branch <type>/<N>- or Closes #<number> in the PR body) bound implementation variance without over-constraining the PR-host lookup. Interim-retire signal (#463) preserved. ✓

Three prior findings still open

Finding 1 — MEDIUM (carried from both prior reviews)
SKILL.md lines 149–151: The diff gate reads "Before a PR is opened" and the review pass reads "After CI is green" — implying a PR was opened between them, but no bullet says so. The worker is told to follow "every step of the consuming project's development workflow"; many project CLAUDE.md files include PR-creation. Without an explicit scope-fence prohibition a worker can open the PR before the diff gate, making the gate a dead letter. Suggested addition: "Chain to /source-control:pull-request to open the PR. The worker's scope fence must list PR-creation as FORBIDDEN."

Finding 2 — LOW-MEDIUM (carried from 2nd review)
SKILL.md line 151: "Fix branch-owned findings via the owning subagent" remains ambiguous. The original worker may have completed and had its worktree torn down before CI findings arrive. Whether to re-dispatch into the same live worktree or open a new one has different lifecycle contracts with /source-control:worktree. One clarifying sentence resolves this.

Finding 3 — LOW-MEDIUM (carried from both reviews)
SKILL.md line 147: Whether work_dispatch_concurrency_cap is passed to implement-dispatch as its cap parameter (one cap) or is a separate work-level cap in series (two caps) is still not stated. The "mirrors" phrasing in plugin.json implies two separate caps, but if so, the reason needs one sentence.

New finding

Finding 4 — LOW (new)
SKILL.md line 141: "Suggest branch name" ends with "Agent emits git checkout -b ... for the user; never executes itself." In autonomous dispatch there is no human to run this — the orchestrator creates the worktree via /source-control:worktree. The computed <type>/<N>-<slug> is never explicitly passed to the worktree creation call, so the worktree could land on any branch, breaking Closes #N auto-injection silently.

No action needed

Eval #1 reconciliation and Eval #3 are accurate. Version bump, CHANGELOG, README are correct and consistent.

View job run

@kyle-sexton

Copy link
Copy Markdown
Contributor Author

Review-response — PR-review comment posted 2026-07-19T23:29Z (3 findings)

# Finding Classification Evidence Reacted
1 Orchestrator PR-creation step implicit; worker could open PR before diff gate (SKILL.md:149) VALID (defer → #572) Diff gate is orchestrator-owned and "pre-PR", but no bullet states who opens the PR or when, and the worker's "follow every step of the project workflow" mandate can include PR creation. The truthful fix (scope-fence PR-creation as FORBIDDEN + orchestrator-owned PR timing) is entangled with the out-of-tree-worker / orchestrator-never-edits provisioning question — deferred to #572 (facet 2). 👍
2 work_dispatch_concurrency_cap vs implement-dispatch's internal cap relationship unstated (SKILL.md:147) VALID (defer → #573) /implementation:implement-dispatch hardcodes the 3–5 wave cap (implement-dispatch SKILL.md:17) and reads no userConfig; the relationship cannot be made true in work/SKILL.md prose alone. Deferred to #573. 👍
3 Already-in-flight skip has no detection mechanism (SKILL.md:125) VALID — fixed in 8686c76 Added a detection clause pointing at the two conventions the skill already establishes: the item's <type>/<N>- head branch pattern and the Closes #<number> closing keyword the branch parse injects. 👍

"Other notes (no action needed)" — acknowledged; all confirmed correct/no-op, nothing to change.

@kyle-sexton

Copy link
Copy Markdown
Contributor Author

Review-response — PR-review comment posted 2026-07-19T23:35Z (5 findings)

# Finding Classification Evidence Reacted
1 Orchestrator PR-creation step implicit; worker could open PR before diff gate (SKILL.md:149) VALID (defer → #572) Same concern as the earlier review's finding 1. Deferred to #572 (facet 2). 👍
2 "Owning subagent" for CI-found fixes is ambiguous (SKILL.md:151) VALID (defer → #572) Whether it is the original worker (whose out-of-tree worktree may already be cleaned up by /source-control:worktree) or a newly dispatched fix subagent depends on whether the per-pick worktree persists to CI-green — a lifecycle-design question. Deferred to #572 (facet 3). 👍
3 work_dispatch_concurrency_cap vs implement-dispatch cap relationship unstated (SKILL.md:147) VALID (defer → #573) Concurrency half of #573 (duplicate of the earlier review's finding 2). 👍
4 work_cycle_batch_cap enforcement delegated to /loop but not explained (SKILL.md:147) VALID (defer → #573) No in-repo consumer reads the key (grep finds it only in work-items docs); /loop is the external harness. Batch half of #573. 👍
5 Already-in-flight check has no detection mechanism (SKILL.md:125) VALID — fixed in 8686c76 Same fix as the earlier review's finding 3 — detection clause added pointing at the <type>/<N>- branch pattern and Closes #<number> keyword. 👍

"Other notes (no action needed)" — acknowledged; all confirmed correct/no-op.

kyle-sexton and others added 2 commits July 20, 2026 02:18
# Conflicts:
#	plugins/work-items/.claude-plugin/plugin.json
#	plugins/work-items/CHANGELOG.md
…tended, defer enforcement (#572, #573)

The absorbed execute step asserted guarantees the review found untrue:
the userConfig concurrency/batch caps read as the operative limits, and the
orchestrator-dispatch flow read as an operational end-to-end autonomous path.
Neither holds today (implement-dispatch hardcodes its 3-5 wave cap and reads no
userConfig; nothing reads the batch cap; nothing provisions a non-default
branch before the dispatch preflight). Narrow the wording so the merged docs
do not over-promise, and point each gap at its tracking issue:

- SKILL.md: caps are the *intended* values; enforcement not yet wired (#573).
  Autonomous branch/worktree provisioning, PR-creation timing, and fix-subagent
  re-dispatch deferred with an interim note (#572), matching the #463/#464 pattern.
- plugin.json: both userConfig descriptions state enforcement is unwired (#573);
  fixed a double-encoded em-dash mojibake in the batch-cap description.
- README: Configuration section reframed to intended values + enforcement note (#573).

No behavior change; documentation-only truthfulness fix. Enforcement remains
tracked in #572 and #573.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown

Claude finished @kyle-sexton's task in 2m 22s —— View job


PR Review — feat(work-items): absorb v4 loop-prompt execution rules into work skill (#479)

Tasks

  • Gather context and understand the PR
  • Read diff and changed files (HEAD: bd3d24b)
  • Check prior findings and what the latest commit addressed
  • Review SKILL.md, plugin.json, evals, README, CHANGELOG
  • Post findings

What bd3d24b fixed

The final commit ("narrow work-skill cap/provisioning guarantees to intended, defer enforcement #572, #573") is a documentation truthfulness pass that closes out all remaining open findings from the three prior review rounds. Specifically:

Autonomous branch/worktree provisioning (→ #572, SKILL.md line 143):
The execute sub-step now carries an explicit deferral note that consolidates Findings 1, 2, and 4 from prior reviews and Codex P1 into one honest statement: the seam that puts an autonomous run on a non-default branch before the dispatch preflight — along with orchestrator-owned PR-creation timing and whether a CI fix re-dispatches to the original or a fresh worker — is not guaranteed end-to-end today and is tracked in #572. This is the correct approach; papering over it in prose would have been worse.

Cap enforcement (→ #573, SKILL.md line 147):
The concurrency/batch cap paragraph is reworded from "resolve from userConfig" to "configured via userConfig" with an explicit "Enforcement of both caps is not yet wired (#573)" note. The *intended* qualifier on both cap references reinforces this. The plugin.json descriptions match, both stating "Enforcement is not yet wired" and citing #573. ✓

Already-in-flight detection (fixed in 8686c76):
Detection now names two concrete match targets — head branch <type>/<N>- pattern and Closes #<number> in the PR body — bounding implementation variance. ✓


Prior-findings status

Finding Source Status
Orchestrator PR-creation step implicit (MEDIUM) Reviews 1, 2, 3 ✓ Deferred to #572 — explicit deferral note in SKILL.md:143
"Owning subagent" ambiguity for CI-found fixes (LOW-MEDIUM) Reviews 2, 3 ✓ Deferred to #572 — same deferral note covers all three facets
Branch suggestion in autonomous mode (LOW) Review 3 ✓ Deferred to #572 — deferral note covers the branch/worktree seam
work_dispatch_concurrency_cap cap relationship (LOW-MEDIUM) Reviews 1, 2, 3 ✓ Deferred to #573 — "not yet wired" stated explicitly
work_cycle_batch_cap enforcement not explained (LOW) Review 2 ✓ Deferred to #573 — enforcement status now explicit
Already-in-flight detection missing (LOW) Reviews 1, 2 ✓ Fixed in 8686c76 — two-convention detection clause added
Codex P1: worker branch before autonomous dispatch Codex ✓ Deferred to #572 — same deferral note
Codex P2: caps not wired Codex ✓ Deferred to #573 — same deferral note

One observation (non-blocking)

CHANGELOG "Added" section (line 31–35): the "Concurrency and batch caps as userConfig" entry says "the execute step resolves them from config with no hardcoded literal." This is technically accurate — the SKILL.md does reference ${user_config.…} variables rather than hardcoded values — but a reader scanning just the CHANGELOG would not know that enforcement is deferred to #573. The SKILL.md and plugin.json are explicit; the CHANGELOG is the only surface that doesn't carry the enforcement caveat.

This is not a merge blocker since the SKILL.md and manifest are the operative surfaces. If you want consistency, one parenthetical ("enforcement wired in #573") would close the gap.


Other notes (no action needed)

  • Evals reconciliation: Eval feat: markdown-formatter plugin (pilot migration) #3 expectation "Concurrency and batch caps resolve from ${user_config…} with no hardcoded literal" tests the documented interface (variables, not literals) rather than actual enforcement — still valid with the new "intended" wording. ✓
  • plugin.json userConfig schema: Both entries have min: 1, type: number, and accurate descriptions matching the SKILL.md deferral language. ✓
  • Deferral pattern consistency: The #572/#573 deferral approach matches the #463/#464 pattern used elsewhere in the skill. ✓
  • Version 0.13.0 and CHANGELOG format: Correct for feature additions; format consistent with existing entries. ✓
  • CLAUDE.md alignment: Repo-agnostic, configurable without editing the plugin, plugin-form-safe, no PII/secrets, versioned. ✓

The PR is ready to merge. The approach of documenting what works now and explicitly tracking what doesn't is the right call — all open seams have tracking issues and the skill is honest about its current guarantees.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bd3d24b7c4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/skills/work/SKILL.md Outdated
…fline local-markdown binding (#563)

The interim already-in-flight staleness check (Step 4) made a PR-host lookup
unconditional, but the supported local-markdown provider is offline-only — never a
coordination surface, touches no gh/curl (tracker CONTRACT.md). In that binding the
check had no PR host to query and would either stall the pre-claim checks or reach
for a forbidden network tool. State the fail-open path: when no PR host is
configured or available, skip the check and proceed to claim.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown

Claude finished @kyle-sexton's task in 1m 26s —— View job


PR Review — feat(work-items): absorb v4 loop-prompt execution rules into work skill (#479)

Tasks

  • Gather context and understand the PR
  • Read the diff at HEAD (751fadb) and identify what the latest commit changed
  • Review SKILL.md at current HEAD
  • Check prior findings status
  • Post findings

What 751fadb fixed

Commit 751fadb is a single-line change to SKILL.md line 125, directly addressing the Codex P2 finding ("Preserve offline local-markdown execution"):

The already-in-flight check previously made a PR-host lookup unconditional. The local-markdown binding is explicitly documented as offline-only (touches no network tool per the tracker CONTRACT.md), so it had no PR host to query. The fix appends an explicit fail-open path:

Fail open when there is no PR host: the offline local-markdown binding is never a coordination surface and touches no network tool, so when no PR host is configured or available this check has nothing to query — skip it and proceed to claim rather than blocking or reaching for a network tool.

The fix is correct, well-scoped, and does not inadvertently widen or narrow any other behavior: it preserves the two-convention detection (branch pattern + Closes #N) for bindings that do have a PR host, and explicitly designates fail-open (proceed to claim) rather than fail-closed (block) as the safe path for offline bindings. The interim/retire-on-#463 framing is preserved. ✓


All prior findings — final status

Finding Source Status
Orchestrator PR-creation step implicit (MEDIUM) Reviews 1–3 ✓ Deferred to #572 — explicit deferral note at SKILL.md:143
"Owning subagent" for CI-found fixes ambiguous (LOW-MEDIUM) Reviews 2–3 ✓ Deferred to #572 — same deferral note
work_dispatch_concurrency_cap cap relationship unstated (LOW-MEDIUM) Reviews 1–3 ✓ Deferred to #573 — "enforcement not yet wired" explicit at SKILL.md:147
work_cycle_batch_cap enforcement not explained (LOW) Review 2 ✓ Deferred to #573 — same deferral note
Already-in-flight detection missing (LOW) Reviews 1–2 ✓ Fixed in 8686c76 — two-convention detection clause
Autonomous branch/worktree seam (Codex P1) Codex + Review 3 ✓ Deferred to #572
Caps not wired (Codex P2) Codex ✓ Deferred to #573
Offline local-markdown check blocks on no PR host (Codex P2 re-review) Codex Fixed in 751fadb — fail-open path added

One non-blocking observation

The fail-open trigger condition "no PR host is configured or available" is slightly open to interpretation — "available" could mean pre-configured (a static config check) or a failed network attempt (a runtime exception path). Given the interim nature of this heuristic and the fact that local-markdown is the only documented offline binding, the ambiguity is harmless in practice. If the deferral to #463 resolves before this wording is revisited, it will retire anyway.


Other notes (no action needed)

  • Fail-open semantics: "skip it and proceed to claim" is the correct behavior — a duplicate branch at claim time is recoverable, a stall or a forbidden network-tool call is not. ✓
  • Scope of change: The fix appends only to the already-in-flight bullet and does not touch detection conventions, the interim/retire signal, or any other step. ✓
  • CHANGELOG / README / plugin.json / evals.json: Unchanged in 751fadb — no updates needed for a documentation truthfulness pass on an interim check. ✓

The PR is ready to merge. All findings from four review rounds are either fixed in-branch or explicitly deferred with tracking issues; the skill is honest about its current guarantees at every surface.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 751fadb9e5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/skills/work/SKILL.md
…ELOG bullets (#572, #573)

The 0.13.0 CHANGELOG entry still over-promised where the SKILL/README/plugin.json
prose was already narrowed: the caps bullet read "resolves them from config with no
hardcoded literal" with no enforcement caveat, and the dispatch bullet described the
orchestrator-dispatch flow with no end-to-end caveat. Add both, matching the narrowed
prose: caps are the intended values with enforcement tracked in #573; the autonomous
dispatch handoff is not yet guaranteed end-to-end, deferred to #572.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown

Claude finished @kyle-sexton's task in 1m 19s —— View job


PR Review — feat(work-items): absorb v4 loop-prompt execution rules into work skill (#479)

Tasks

  • Gather context and understand the PR
  • Read the diff at HEAD (9a5370c) and identify what the latest commit changed
  • Review CHANGELOG.md changes
  • Check prior findings status
  • Post findings

What 9a5370c fixed

Commit 9a5370c is a targeted documentation truthfulness pass on CHANGELOG.md only. It directly addresses the one non-blocking observation raised in the bd3d24b review round:

"The CHANGELOG is the only surface that doesn't carry the enforcement caveat."

Two insertions, matching the already-narrowed prose in SKILL.md, README, and plugin.json:

Dispatch bullet (CHANGELOG.md line 19–20): Appends the autonomous dispatch handoff caveat — branch/worktree provisioning before the dispatch preflight and orchestrator-owned PR creation are not yet guaranteed end-to-end, deferred to #572. ✓

Caps bullet (CHANGELOG.md line 35–38): Replaces the previously accurate-but-incomplete "resolves them from config with no hardcoded literal" with the enforcement caveat — these are intended values, implement-dispatch still applies its own internal cap, no consumer reads the batch cap, tracking in #573. ✓

Both caveats are concise, cite the correct tracking issue, and exactly mirror the SKILL.md / plugin.json language. The "A batch cap bounds one CYCLE, never the loop" sentence that follows reads correctly with the insertion before it.


All findings — final status across five review rounds

Finding Status
Orchestrator PR-creation step implicit (MEDIUM) ✓ SKILL.md:143 deferral note → #572
"Owning subagent" for CI-found fixes ambiguous (LOW-MEDIUM) ✓ SKILL.md:143 deferral note → #572
work_dispatch_concurrency_cap cap relationship unstated (LOW-MEDIUM) ✓ SKILL.md:147 + CHANGELOG:35 → #573
work_cycle_batch_cap enforcement not explained (LOW) ✓ SKILL.md:147 + CHANGELOG:35 → #573
Already-in-flight detection missing (LOW) ✓ Fixed 8686c76 — two-convention detection clause
Branch suggestion in autonomous mode / worktree seam (LOW) ✓ SKILL.md:143 deferral note → #572
Offline local-markdown blocked by mandatory PR-host lookup ✓ Fixed 751fadb — fail-open path added
CHANGELOG over-promised on enforcement + dispatch handoff Fixed 9a5370c — caveats added matching SKILL.md/plugin.json prose

Other notes (no action needed)

  • Surface consistency: All four operative surfaces (SKILL.md, README, plugin.json, CHANGELOG) now consistently disclose: caps are intended with enforcement tracking in #573; autonomous dispatch handoff is not guaranteed end-to-end with design tracking in #572. ✓
  • Commit message: Accurately describes the over-promise, the fix, and the narrowing target. ✓
  • Co-authorship trailer: Claude Opus 4.8 — consistent with the authorship pattern used across this PR's commits. ✓
  • No other files changed: Correct — only CHANGELOG.md needed updating; SKILL.md, README, and plugin.json were already fully narrowed in bd3d24b. ✓

The PR is ready to merge. All findings from five review rounds are either fixed in-branch or explicitly deferred with tracking issues; the skill is honest about its current guarantees at every surface.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9a5370c311

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/skills/work/SKILL.md Outdated
…y-in-flight check (#563)

The interim already-in-flight detection (Step 4) matched only `Closes #N` in a
candidate PR body, but /source-control:pull-request recognizes all nine GitHub
closing keywords (close/closes/closed, fix/fixes/fixed, resolve/resolves/resolved,
case-insensitive, optional colon). A PR opened from an orphan or noncanonical branch
that links the item via `Fixes #N` or `Resolved #N` was missed, so after lease expiry
/work-items:work could reclaim and dispatch duplicate work for an already-open PR.
Recognize all nine forms with exact-number boundaries.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown

Claude finished @kyle-sexton's task in 1m 58s —— View job


PR Review — feat(work-items): absorb v4 loop-prompt execution rules into work skill (#479)

Tasks

  • Gather context and understand the PR
  • Read diff at HEAD (2e317ad) and identify what the latest commit changed
  • Review SKILL.md changes
  • Verify keyword list against /source-control:pull-request reference (create.md)
  • Check prior findings status
  • Post findings

What 2e317ad fixed

Commit 2e317ad is a single-line change to SKILL.md line 125, directly addressing the Codex P2 finding raised in the 9a5370c review round:

"Match every supported issue-closing keyword — a PR opened from an orphan or noncanonical branch that links via Fixes #N or Resolved #N was missed."

Before: the body-match condition covered only the single form the branch-name parser injects: Closes #<number>

After: the condition covers all nine GitHub closing keywords — close/closes/closed, fix/fixes/fixed, resolve/resolves/resolved (case-insensitive, optional colon) followed by #<number> with exact-number boundaries.

Keyword list verified against the authoritative source. create.md line 202 defines:

KEYWORD_REGEX='^(close|closes|closed|fix|fixes|fixed|resolve|resolves|resolved):? #[0-9]+'

The SKILL.md enumeration matches that set exactly:

  • close/closes/closed
  • fix/fixes/fixed
  • resolve/resolves/resolved
  • case-insensitive ✓
  • optional colon ✓
  • "exact-number boundaries" — prevents Closes #1 matching Closes #12 for the wrong item ✓

The cross-reference pointer ("the same nine forms /source-control:pull-request recognizes") is accurate and keeps the SKILL.md description in sync with create.md by pointer rather than duplication. ✓

The parenthetical "(a PR opened from an orphan or noncanonical branch can link via any of them)" is a well-placed in-context explanation for why the broader set matters.


All findings — final status across six review rounds

Finding Status
Orchestrator PR-creation step implicit (MEDIUM) ✓ Deferred to #572 — explicit deferral note at SKILL.md:143
"Owning subagent" for CI-found fixes ambiguous (LOW-MEDIUM) ✓ Deferred to #572 — same deferral note
work_dispatch_concurrency_cap cap relationship unstated (LOW-MEDIUM) ✓ Deferred to #573 — "enforcement not yet wired" explicit
work_cycle_batch_cap enforcement not explained (LOW) ✓ Deferred to #573 — same deferral note
Already-in-flight detection missing (LOW) ✓ Fixed 8686c76 — two-convention detection clause
Autonomous branch/worktree seam (Codex P1) ✓ Deferred to #572
Caps not wired (Codex P2) ✓ Deferred to #573
Offline local-markdown blocked by mandatory PR-host lookup ✓ Fixed 751fadb — fail-open path added
CHANGELOG over-promised on enforcement + dispatch handoff ✓ Fixed 9a5370c — caveats added matching SKILL.md/plugin.json prose
Match all nine issue-closing keywords (Codex P2) Fixed 2e317ad — full nine-form detection clause with source pointer

Other notes (no action needed)

  • Scope: Only SKILL.md changed. No CHANGELOG update for the keyword expansion — defensible since the already-in-flight check is an interim heuristic (retire on #463); the CHANGELOG entries document the primary feature additions.
  • Commit message: Accurately describes the before/after, names the affected forms, and explains the duplicate-dispatch risk. ✓
  • Co-authorship trailer: Consistent with prior commits in this PR. ✓

The PR is ready to merge. All findings across six review rounds are either fixed in-branch or explicitly deferred with tracking issues; every operative surface (SKILL.md, README, plugin.json, CHANGELOG) is consistent in disclosing current guarantees.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2e317adeb1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/skills/work/SKILL.md Outdated
…tier claim (#563)

The never-merge boundary said "consistent with /source-control:babysit-prs never
merging" — accurate only for babysit-prs's safe default tier. Its opt-in worker and
autopilot tiers DO merge behind a deterministic readiness gate (babysit-prs SKILL.md
frontmatter + tier table). The bullet's main claim (work itself never merges) stands;
qualify the babysit-prs sub-clause so the autonomous handoff carries the correct
lifecycle/safety contract.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@claude

claude Bot commented Jul 20, 2026

Copy link
Copy Markdown

Claude finished @kyle-sexton's task in 1m 49s —— View job


PR Review — feat(work-items): absorb v4 loop-prompt execution rules into work skill (#479)

Tasks

  • Gather context and understand the PR
  • Read diff at HEAD (6b959eb) and identify what the latest commit changed
  • Verify the babysit-prs merge-tier fix against the source SKILL.md
  • Check all prior findings status
  • Post findings

What 6b959eb fixed

Commit 6b959eb is a single-line change to SKILL.md line 153, addressing the last open Codex P2 finding ("Do not claim babysit-prs never merges"):

Before: "consistent with /source-control:babysit-prs never merging and /source-control:pull-request merges being human-gated"

After: "consistent with /source-control:babysit-prs's safe default never merging (its opt-in worker/autopilot tiers merge only behind a deterministic readiness gate) and /source-control:pull-request merges being human-gated"

Verified against babysit-prs SKILL.md:

  • Line 22: "The safe tier never resolves threads and never merges" → "safe default never merging" ✓
  • Line 22: "merging exists only behind the explicit worker/autopilot opt-in and a deterministic merge gate" → "deterministic readiness gate" matches "deterministic merge gate" ✓
  • Line 38–39: worker / autopilot tiers merge only when the gate proves readiness ✓

The main claim — that work itself never merges — remains correct. The imprecise sub-clause (babysit "never" merging) is now correctly scoped to the safe default tier with an explicit acknowledgment of the opt-in merge tiers. ✓


All findings — final status across seven review rounds

Finding Status
Orchestrator PR-creation step implicit (MEDIUM) ✓ Deferred to #572 — explicit deferral note at SKILL.md:143
"Owning subagent" for CI-found fixes ambiguous (LOW-MEDIUM) ✓ Deferred to #572 — same deferral note
work_dispatch_concurrency_cap cap relationship unstated (LOW-MEDIUM) ✓ Deferred to #573 — "enforcement not yet wired" explicit at SKILL.md:147
work_cycle_batch_cap enforcement not explained (LOW) ✓ Deferred to #573 — same deferral note
Already-in-flight detection missing (LOW) ✓ Fixed 8686c76 — two-convention detection clause
Autonomous branch/worktree seam (Codex P1) ✓ Deferred to #572
Caps not wired (Codex P2) ✓ Deferred to #573
Offline local-markdown blocked by mandatory PR-host lookup (Codex P2) ✓ Fixed 751fadb — fail-open path added
CHANGELOG over-promised on enforcement + dispatch handoff ✓ Fixed 9a5370c — caveats added matching SKILL.md/plugin.json prose
Match all nine issue-closing keywords (Codex P2) ✓ Fixed 2e317ad — full nine-form detection clause with source pointer
Never-merge bullet inaccurate for babysit-prs opt-in tiers (Codex P2) Fixed 6b959eb — qualified to safe default + parenthetical for opt-in tiers

Other notes (no action needed)

  • Scope: Only SKILL.md line 153 changed. No CHANGELOG entry for this correction — defensible since this is a prose-accuracy fix on the handoff description, not a behavior change.
  • Commit message: Accurately diagnoses the before/after, names the affected tiers, and explains why the main claim stands while only the sub-clause needed correction. ✓
  • Surface consistency: The fix uses the same "deterministic readiness gate" language consistent with babysit-prs SKILL.md's "deterministic gate scripts" and "deterministic merge gate" phrasing. ✓

The PR is ready to merge. All findings from seven review rounds are either fixed in-branch or explicitly deferred with tracking issues; every operative surface is consistent in disclosing current guarantees.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6b959ebf6e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread plugins/work-items/skills/work/SKILL.md
@kyle-sexton
kyle-sexton merged commit 3657964 into main Jul 20, 2026
17 checks passed
@kyle-sexton
kyle-sexton deleted the feat/479-work-skill-absorb-v4-rules branch July 20, 2026 07:15
kyle-sexton added a commit that referenced this pull request Jul 24, 2026
…le (#572) (#1244)

Closes #572

## Summary

Resolves the previously-deferred autonomous orchestrator-dispatch
lifecycle — the seam that spanned `/work-items:work`,
`/implementation:implement-dispatch`, `/source-control:worktree`, and
`/source-control:pull-request`, where each sibling skill's preflight
assumed the others already solved provisioning and PR-creation timing.
Adopts the posted decision brief's **Option A (orchestrator-owned PR
invocation)**, reconciled with the interim worker-side-provisioning
workaround already landed in `work-loop`.

The lifecycle is now specified end-to-end across its three facets:

- **Provisioning is worker-side.** The dispatched worker materializes
its own out-of-tree worktree as its first step (via
`/source-control:worktree`'s non-entering seam when installed, or a
plain `git worktree add`) and works it via `git -C` **without entering
it** — matching `implement-dispatch`'s existing worktree-cwd contract,
and avoiding any dependency on `EnterWorktree`-in-a-subagent. The
orchestrator never invokes `/source-control:worktree create` (its
`EnterWorktree` terminal would transition the orchestrator's own
session). The worker commits, pushes, and brings the branch current with
the default branch before returning the worktree path + branch; a worker
that cannot provision parks and escalates.
- **PR creation is orchestrator-owned.** After the worker returns and
the pre-PR diff gate passes, the orchestrator opens the PR via a new
**`/source-control:pull-request create --pushed --worktree <path>`**
PR-only entry that re-resolves branch and diff from the target worktree
(ignoring the session-cwd pre-computed context), passes the branch
explicitly to `parse-branch-issue.sh` so `Closes #N` is parsed from the
worker's branch, skips commit/push/rebase, and calls `gh pr create
--head <branch>`. The worker scope-fence forbids PR creation; detection
of a consuming project's own PR stage lives in the orchestrator
(invoke-vs-defer).
- **Fix re-dispatch + worktree persistence.** Branch-owned fixes
(failing CI, review findings) re-dispatch a fresh scope-fenced subagent
into the *same persisted worktree* — the worktree is the state carrier
across dispatches. It persists through the whole PR lifecycle and is
cleaned up only by whoever merges, never by the `work` lane.

`work-loop`'s former interim `#572` workaround (SKILL + evals) is
reframed as the now-canonical behavior it inherits from `work`.

### Authority

The `needs-human` + `wayfind: design` decision was delegated to the
session by the operator (session `d557362f` handoff, "have you do ALL of
these"); the delegation is the human decision. A decision-adoption
comment is posted on #572. Labels are left in place — repo convention
keeps `needs-human` / `wayfind: design` on issues through close (e.g.
#1065, #1041, #696, #695, #684 all retain them closed).

## Test plan

- **changelog-parity `--check-bump origin/main`:** green — all three
bumped plugins (work-items 0.22.1→0.23.0, implementation 0.7.8→0.8.0,
source-control 0.25.1→0.26.0) carry a matching `## [<version>]`
CHANGELOG entry.
- **markdownlint-cli2** over all 9 changed markdown files: 0 errors.
- **skill-quality static gate** (`check-skill.sh`) on all 5 changed
skills (`work`, `work-loop`, `implement-dispatch`, `pull-request`,
`worktree`): PASS, 0 errors (only pre-existing line-count / Gotchas /
quote-style warnings inherited from base).
- **`check-skill-portability`, `check-skill-leaf-names`,
`check-orphaned-fixtures`, `check-silent-skips`:** all green.
- **Both changed `evals.json`** (`work`, `work-loop`) validate against
`plugins/skill-quality/reference/evals.schema.json`.
- Docs-only change (SKILL/reference/CHANGELOG/manifest prose + version
bumps); no shell or hook logic touched, so `preflight.test.sh` and the
shared-lib tests are unaffected.

## Related

- #573 — sibling from the same PR #563 review (cap-enforcement wiring);
independent gap, implemented after this PR merges. This PR deliberately
does not touch its `userConfig` cap scope.
- #563 / #479 — source of the deferral (MERGED); absorbed the execute
step and deferred this design to #572.
- #451 / #462 — orchestrator-dispatch and PR-contract-forward lane
lineage referenced by the execute step.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
kyle-sexton added a commit that referenced this pull request Jul 24, 2026
…#573) (#1247)

Closes #573

## Summary

Wires the previously-inert `work_dispatch_concurrency_cap` to real
enforcement and removes the `work_cycle_batch_cap` knob that bound
nothing — adopting the posted decision brief's **Option 1**
(verify-then-recommend: "wire concurrency for real; remove the batch cap
from `userConfig`"). Both scalars had shipped as tunable execution caps
that no code read, sitting against this repo's `PLUGIN-PHILOSOPHY.md`
("schema used honestly"; "a silently skipped feature is a defect").

- **Concurrency cap — now enforced through a single real parameter.**
`/implementation:implement-dispatch` gains an optional `--wave-cap <N>`
argument that overrides its internal "3–5 concurrent dispatch waves"
default. `/work-items:work`'s autonomous execute step resolves
`${user_config.work_dispatch_concurrency_cap}` and threads it into the
delegated dispatch as `--wave-cap` when the operator set it, passing
nothing when it is unset so implement-dispatch's internal 3–5 default
still applies. The value now reaches real fan-out behavior through that
one parameter.

- **Default-preservation is load-bearing, so the manifest `default: 3`
is removed.** The brief guarantees the internal 3–5 stays the default
when the cap is unpassed. That only holds if an unset key stays
distinguishable from a configured one. Per the plugins-reference, a
declared `default` is "the value used when the user provides nothing" —
an unset-but-defaulted key would resolve `${user_config.…}` to a hard
`3`, collapsing the 3–5 range. Dropping `default` (keeping `min: 1`)
leaves a surviving `${user_config.…}` placeholder on unset — the exact
"unset" signal `work` already keys off — so implement-dispatch owns the
real default range. (This is also robust against the
currently-unimplemented-upstream `default` substitution noted in #1242.)

- **Batch cap removed, not downgraded.** `work` selects and executes
exactly one item per invocation — it has no "cycle" to count, so
`work_cycle_batch_cap` had no honest in-skill enforcement point. The
autonomous per-cycle item budget already exists and is enforced as the
`work-loop` lane's adaptive item cap (`work_loop_item_cap_*`). A future,
demonstrated need for a distinct loop-side batch budget reopens as a
`/loop`-side concern rather than an indefinite inert knob.

Consistent with the just-merged #572 lifecycle: the concurrency value
rides the same `work` → `implement-dispatch` delegation, worker-side
provisioning and orchestrator-owned PR creation are untouched.

### Authority

The `needs-human` + `wayfind: design` decision was delegated to the
session by the operator (session `d557362f` handoff, "have you do ALL of
these"); the delegation is the human decision. A decision-adoption
comment is posted on #573. Labels are left in place per the repo
convention that keeps `needs-human` / `wayfind: design` on issues
through close (as #572 / #1244 did).

## Test plan

- **changelog-parity `--check-bump origin/main`:** green — both bumped
plugins (implementation 0.8.0→0.9.0, work-items 0.23.0→0.24.0) carry a
matching `## [<version>]` entry.
- **skill-quality static gate (`check-skill.sh`)** on the three changed
skills (`implement-dispatch`, `work`, `work-loop`): PASS, 0 errors; all
base-ref trigger phrases preserved (8/8 `work`, 7/7 `work-loop`).
- **markdownlint-cli2** over the changed markdown (SKILLs via
check-skill; `README.md` + both `CHANGELOG.md` directly): 0 errors.
- **All three changed `evals.json`** validate against
`plugins/skill-quality/reference/evals.schema.json`; a new
implement-dispatch eval (id 7) covers `--wave-cap N` → cap N while eval
id 1 keeps the unset → 3–5 assertion.
- Docs-only change (SKILL / manifest / README / CHANGELOG / evals prose
+ version bumps); no shell or hook logic touched.

## Related

- #572 / #1244 — sibling from the same PR #563 review (deferred
config-vs-enforcement gaps); merged the orchestrator-dispatch lifecycle
this cap wiring rides. This PR completes the cap-enforcement half #1244
deliberately left out of scope.
- #563 / #479 — source of the deferral (MERGED); introduced the two caps
as `userConfig` and deferred their enforcement to #573.
- #464 — same-plugin serialization (still deferred; unchanged here).
- #1242 — documents the currently-unimplemented-upstream `userConfig`
`default` substitution the default-removal above is robust against.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
kyle-sexton added a commit that referenced this pull request Jul 25, 2026
…w replies

fetch-all-pr-comments.sh never projected the GitHub REST field that marks an
inline review comment as a threaded reply, so callers reading the script's
output saw the key absent even for properly-threaded replies GraphQL
confirmed were linked. Reproduced against live PR #563 data: the raw
pulls/<pr>/comments response correctly carries in_reply_to_id — the script's
jq mapping for the inline surface simply dropped it.

Adds in_reply_to_id to all three surfaces (sourced from the raw field for
inline comments; null for general/review, which have no reply-parent
concept). Additive schema change, no breaking impact on existing consumers.

Closes #587

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kyle-sexton added a commit that referenced this pull request Jul 25, 2026
…ge() range

Two follow-ups from review of 431a27e:

- The in_reply_to_id docstring asserted "the id of the inline comment this
  one replies to" and steered callers away from the REST cross-check that
  reference/review-discipline.md and skills/pull-request/SKILL.md already
  prescribe. Live PR #563 data shows GitHub sets the field to the
  THREAD-OPENING comment id, not the immediately-preceding reply (every
  parent referenced in that thread set was itself a root comment) — the
  docstring now states that correctly and stops contradicting the two
  canonical reference docs, which were never wrong.
- usage()'s `sed -n '2,18p'` range was written against the old (pre-fix)
  header length. Adding the in_reply_to_id block pushed the Usage/Env
  overrides sections past line 18 without updating the range, so --help
  silently truncated before showing them. Range corrected to 2,30p and
  verified against actual --help output.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kyle-sexton added a commit that referenced this pull request Jul 25, 2026
…w replies (#1350)

## Summary

- `fetch-all-pr-comments.sh` never projected the GitHub REST
`in_reply_to_id` field into its unified output schema for inline review
comments, so any caller reading the script's own output saw the key
absent (surfacing as `None`/`null` downstream) even for comments that
GraphQL confirmed were properly threaded replies.
- Reproduced against live PR #563 data: `gh api
repos/melodic-software/claude-code-plugins/pulls/563/comments` correctly
carries `in_reply_to_id` on reply comments (e.g. id `3611618764` →
`in_reply_to_id: 3611576636`) — the script's `jq` mapping for the inline
surface simply dropped the field on the way out.
- Added `in_reply_to_id: .in_reply_to_id` to the inline mapping, and
`in_reply_to_id: null` to the general/review mappings (those surfaces
have no reply-parent concept). Purely additive to the schema — no
existing consumer (`babysit_findings.py`, `babysit_classify.py`) reads
this key today, so nothing breaks.
- Bumped `source-control` to 0.26.3 with a matching CHANGELOG entry.

Closes #587

## Test plan

- [x] Reproduced root cause against live GitHub API data for PR #563
before writing the fix (Bug Investigation Rule)
- [x] Added 4 new regression-test cases to
`fetch-all-pr-comments.test.sh`: top-level inline comment →
`in_reply_to_id: null`; threaded inline reply → true parent id;
general/review comments → `in_reply_to_id: null`
- [x] Full suite: `bash
plugins/source-control/scripts/fetch-all-pr-comments.test.sh` — 21/21
pass
- [x] `shellcheck` clean on both modified scripts

## Related

N/A

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

automated Opened by automation.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

work-items(work): absorb v4 loop-prompt execution rules into the skill

1 participant