feat(skills): add /nextwork readiness queue

[ifireball]

Summary

Adds a /nextwork skill and script that builds a readiness-oriented queue of assigned open issues/PRs, follows open GitHub blockers and sub-issues, classifies each item, and recommends the next action (with optional --apply / --take-over / --link-blocker).

Unlike /topissues, this has no RICE/project dependency — it answers “what can I work on next?” rather than “what is highest priority?”

Related Issue

N/A

Changes

• New skills/nextwork/ skill, Python classifier script, and unit tests
• Portable slash command in commands/nextwork.md
• Makefile wiring for the skill
• Status catalog covering waiting/stale automation, blockers, sub-issues, review threads, conflicts, and merge readiness
• Trivial actions via --apply (assign:self, /fs-* re-triggers, remove orphaned blocked label)

Testing

• Unit tests in skills/nextwork/scripts/nextwork_test.py
• make lint passes (stage changes first, then run)
• Tests added/updated for new or modified logic

Checklist

• PR title follows Conventional Commits (correct type, ! for breaking changes)
• Commits are signed off (DCO) — human and human-directed agent sessions only
• I wrote this contribution myself and can explain all changes in it

Made with Cursor

[qodo-code-review]

PR Summary by Qodo

feat(skills): add /nextwork readiness queue

✨ Enhancement 🧪 Tests 📝 Documentation ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Add a /nextwork skill that builds an actionable queue from assigned work plus open blockers.
• Classify issues/PRs into readiness statuses and suggest next actions, with optional auto-apply.
• Provide portable slash command docs, Makefile test wiring, and comprehensive unit tests.

Diagram

graph TD
  Cmd["/nextwork command"] --> Script(["nextwork.py"]) --> Gh[["gh CLI"]] --> API{{"GitHub GraphQL API"}}
  Docs["Skill + command docs"] --> Script --> Out["Markdown/JSON output"]
  Make["Makefile (script-test)"] --> Tests(["nextwork_test.py"]) --> Script

  subgraph Legend
    direction LR
    _doc["Docs"] ~~~ _script(["Script"]) ~~~ _cli[["CLI"]] ~~~ _ext{{"External API"}} ~~~ _test(["Tests"])
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Batch GraphQL fetching for queue expansion

• ➕ Fewer gh invocations and lower latency for large dependency graphs
• ➕ Reduces risk of partial results due to per-item failures/timeouts
• ➖ More complex query construction and response normalization
• ➖ Harder to keep within GraphQL complexity/connection limits

2. Extract shared link-parsing/utilities with /topissues

• ➕ Avoids duplicated regex/link parsing logic and keeps behavior consistent
• ➕ Simplifies future maintenance for shared primitives (refs, PR link parsing)
• ➖ Introduces a new shared module surface area and potential coupling
• ➖ Refactor scope could distract from landing the feature

3. Use REST/search-based queries (gh issue/pr list) instead of GraphQL per item

• ➕ Simpler operational model and fewer schema-specific fields
• ➕ Potentially more robust against GraphQL field changes
• ➖ Harder to get merge state, review thread resolution, blockedBy/sub-issues in one place
• ➖ Likely needs multiple endpoints and extra stitching anyway

Recommendation: The PR’s approach (stdlib-only Python + gh GraphQL, deterministic classification, and opt-in trivial mutations) is a good fit for a portable skill and provides the needed PR/issue fields (blockedBy, sub-issues, mergeability, reviewThreads) that are awkward via list/search alone. Consider a follow-up to extract shared helpers with /topissues and/or add batched fetching if API call volume becomes a problem on large queues.

Files changed (8) +3708 / -0

Enhancement (1) +1882 / -0

nextwork.pyImplement readiness queue builder with classification and optional actions +1882/-0

Implement readiness queue builder with classification and optional actions

• Adds the nextwork script that seeds from assigned items or explicit refs, traverses open blockedBy links and open sub-issues, and classifies each item into actionable vs eliminated readiness statuses. Implements merge readiness checks (mergeable/mergeStateStatus, checks state, unresolved review threads), stale automation detection from agent-status comments/launch signals, and optional mutations for --apply, --take-over, and --link-blocker.

skills/nextwork/scripts/nextwork.py

Tests (4) +1624 / -0

nextwork_test.pyAdd comprehensive unit tests for nextwork classification and actions +1538/-0

Add comprehensive unit tests for nextwork classification and actions

• Introduces network-free unittest coverage for ref parsing, GraphQL flag typing, inflight/stale logic, BFS queue expansion (blockers and sub-issues), PR/issue status classification, and mutation helpers (apply, take-over, link-blocker). Uses fixtures and mocks to validate behavior deterministically.

skills/nextwork/scripts/nextwork_test.py

issue_node_sample.jsonAdd sample Issue GraphQL node fixture +30/-0

Add sample Issue GraphQL node fixture

• Provides a representative Issue payload fixture used by normalize_item tests, including blockedBy and sub-issues fields.

skills/nextwork/scripts/testdata/issue_node_sample.json

pr_node_sample.jsonAdd sample PullRequest GraphQL node fixture +44/-0

Add sample PullRequest GraphQL node fixture

• Provides a representative PullRequest payload fixture used by normalize_item tests, including reviewThreads, merge state, and checks rollup fields.

skills/nextwork/scripts/testdata/pr_node_sample.json

pulls_for_linking_sample.jsonAdd sample PR list fixture for linked-issue detection +12/-0

Add sample PR list fixture for linked-issue detection

• Adds fixture data for testing PR-body keyword parsing and closing issue reference mapping for linked PR detection.

skills/nextwork/scripts/testdata/pulls_for_linking_sample.json

Documentation (2) +201 / -0

nextwork.mdAdd portable /nextwork slash command definition +19/-0

Add portable /nextwork slash command definition

• Defines a new /nextwork command entry that runs nextwork.py with JSON output and points to the skill loop. Documents expectations around showing blocked items and not inventing statuses.

commands/nextwork.md

SKILL.mdDocument nextwork skill loop, flags, and readiness status catalog +182/-0

Document nextwork skill loop, flags, and readiness status catalog

• Introduces the nextwork skill documentation, including prerequisites, CLI flags, status taxonomy, stale/re-trigger semantics, and the recommended interactive loop (prose blocker mining, link persistence, optional take-over, optional apply).

skills/nextwork/SKILL.md

Other (1) +1 / -0

MakefileWire nextwork unit tests into script-test target +1/-0

Wire nextwork unit tests into script-test target

• Adds nextwork's Python unit test runner to the existing script-test Makefile target so it runs in CI/local test flows.

Makefile

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 12:09 PM UTC · Ended 12:25 PM UTC
Commit: a797c4d · View workflow run →

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📜 Skill insights (0)

1. Seeding hides gh failures ✓ Resolved 🐞 Bug ☼ Reliability

Description

When no seed ITEMS are provided, seed_from_assigned() uses try_run_gh(), which returns None on
gh failures, and the code silently treats that as “no assigned items.” This can incorrectly return
an empty queue with exit code 0 during auth/outage/repo errors.

Code

skills/nextwork/scripts/nextwork.py[R1328-1369]

+def seed_from_assigned(repo: str, user: str, *, quiet: bool = False) -> list[tuple[str, int]]:
+    refs: list[tuple[str, int]] = []
+    # gh defaults --limit to 30; raise so "dozens" of assigned items are not truncated.
+    issues_raw = try_run_gh(
+        [
+            "issue",
+            "list",
+            "--repo",
+            repo,
+            "--assignee",
+            user,
+            "--state",
+            "open",
+            "--limit",
+            "1000",
+            "--json",
+            "number",
+        ]
+    )
+    if issues_raw:
+        for row in json.loads(issues_raw):
+            refs.append((repo, row["number"]))
+    pulls_raw = try_run_gh(
+        [
+            "pr",
+            "list",
+            "--repo",
+            repo,
+            "--assignee",
+            user,
+            "--state",
+            "open",
+            "--limit",
+            "1000",
+            "--json",
+            "number",
+        ]
+    )
+    if pulls_raw:
+        for row in json.loads(pulls_raw):
+            refs.append((repo, row["number"]))
+    return refs

Relevance

●●● Strong

They’ve rejected fail-open behavior on gh errors; hiding failures as “no items” risks incorrect
success.

PR-#3610

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

try_run_gh() explicitly returns None on CalledProcessError, and seed_from_assigned() only
processes results when the returned string is truthy, so failures become empty seeds without any
error path.

skills/nextwork/scripts/nextwork.py[895-903]
skills/nextwork/scripts/nextwork.py[1328-1369]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`seed_from_assigned()` suppresses gh failures by using `try_run_gh()` and simply returning an empty seed list when commands fail, which can make `/nextwork` report “nothing actionable” even though it actually couldn’t fetch assigned issues/PRs.

### Issue Context
This is particularly problematic for automation and for the interactive slash command because it returns a successful empty result instead of surfacing the underlying failure.

### Fix Focus Areas
- skills/nextwork/scripts/nextwork.py[895-903]
- skills/nextwork/scripts/nextwork.py[1328-1369]

### Implementation guidance
- Switch `seed_from_assigned()` to use `run_gh()` for both `gh issue list` and `gh pr list`, so failures exit non-zero (3) rather than being treated as empty.
 - Alternatively, extend `try_run_gh` to return `(stdout, rc)` or raise a custom exception so `seed_from_assigned` can distinguish “valid empty JSON array” from “command failed”.
- If keeping partial results is desired, at minimum emit a warning and exit 3 when *both* list calls fail, and consider failing when either fails to avoid silently dropping half the queue.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Scans all open PRs ✓ Resolved 🐞 Bug ➹ Performance

Description

Linked-PR detection paginates through every open PR in a repo to build an issue→PR map, making
runtime and API usage proportional to total open PR count. This can slow /nextwork significantly
or increase rate-limit risk in repos with many open PRs.

Code

skills/nextwork/scripts/nextwork.py[R1261-1285]

+    def _pulls_for_linking(self, repo: str) -> list[dict[str, Any]]:
+        if repo not in self._pulls_by_repo:
+            owner, name = repo.split("/", 1)
+            nodes: list[dict[str, Any]] = []
+            cursor: str | None = None
+            while True:
+                data = gh_graphql_or_none(
+                    OPEN_PULLS_FOR_LINKING_QUERY,
+                    {"owner": owner, "name": name, "cursor": cursor},
+                    quiet=self.quiet,
+                )
+                if data is None:
+                    break
+                conn = data["repository"]["pullRequests"]
+                nodes.extend(conn["nodes"])
+                page = conn["pageInfo"]
+                if not page["hasNextPage"]:
+                    break
+                cursor = page["endCursor"]
+            self._pulls_by_repo[repo] = nodes
+        return self._pulls_by_repo[repo]
+
+    def get_linked_prs(self, repo: str, issue_number: int) -> list[int]:
+        by_issue = build_pr_links_by_issue(self._pulls_for_linking(repo))
+        return by_issue.get(issue_number, [])

Relevance

●●● Strong

Performance/rate-limit reductions in GitHub queries have been accepted before; scanning all open PRs
likely flagged.

PR-#816

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

_pulls_for_linking() paginates until hasNextPage is false and caches the full node list;
fetch_item() calls get_linked_prs() for every issue, triggering the full scan for the first
issue in each repo.

skills/nextwork/scripts/nextwork.py[1246-1260]
skills/nextwork/scripts/nextwork.py[1261-1286]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`GhFetcher.get_linked_prs()` currently requires `_pulls_for_linking()` to paginate the entire `pullRequests(states: OPEN)` connection for the repo, which can be expensive in large repos.

### Issue Context
This work happens as soon as the first Issue is fetched (`fetch_item()` unconditionally calls `get_linked_prs()` for issues), even though many issues will be classified earlier via blockers/sub-issues/labels without needing linked-PR info.

### Fix Focus Areas
- skills/nextwork/scripts/nextwork.py[1246-1260]
- skills/nextwork/scripts/nextwork.py[1261-1286]

### Implementation guidance
- Make linked-PR lookup lazy:
 - Don’t compute `linked_prs` inside `fetch_item()`; instead compute only when classification reaches the `waiting_linked_pr` check (or as a targeted second pass).
- Consider adding a cap (e.g., only scan the most recent N open PRs) with a best-effort warning when the cap is hit.
- If feasible with gh APIs, replace the full scan with a search-based query that targets PRs referencing a specific issue number.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. link-blocker open check missing ✓ Resolved 🐞 Bug ≡ Correctness

Description

--link-blocker is documented to require the dependent to be an open Issue, but
ISSUE_ID_AND_BLOCKERS_QUERY does not fetch state and link_blocker() never verifies
state==OPEN. This can create links for closed issues and also returns a misleading “not an open
Issue” error only when the issue object is missing.

Code

skills/nextwork/scripts/nextwork.py[R1526-1538]

+    data = gh_graphql_or_none(
+        ISSUE_ID_AND_BLOCKERS_QUERY,
+        {"owner": dep_owner, "name": dep_name, "number": dep_number},
+        quiet=quiet,
+    )
+    issue = (data or {}).get("repository", {}).get("issue") if data else None
+    if issue is None:
+        return {
+            "dependent": format_ref(dep_repo, dep_number),
+            "blocker": format_ref(blk_repo, blk_number),
+            "action": "error",
+            "detail": "dependent ref is not an open Issue (GitHub blocked-by is issue-only)",
+        }

Relevance

●●● Strong

Docs require dependent be open; adding state fetch+validation is straightforward correctness
alignment.

PR-#3610

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The docs explicitly require an open dependent Issue, but the validation query omits state and the
function only checks issue is None, so it cannot enforce the documented rule.

skills/nextwork/SKILL.md[36-46]
skills/nextwork/scripts/nextwork.py[1106-1117]
skills/nextwork/scripts/nextwork.py[1519-1539]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`--link-blocker` is documented as requiring the dependent to be an **open** Issue, but the implementation doesn’t check openness.

### Issue Context
- The query used for validation (`ISSUE_ID_AND_BLOCKERS_QUERY`) does not request the Issue `state`.
- The error message claims the dependent is not an open Issue, but the code only detects the “issue not found / not an issue” case.

### Fix Focus Areas
- skills/nextwork/SKILL.md[36-46]
- skills/nextwork/scripts/nextwork.py[1106-1117]
- skills/nextwork/scripts/nextwork.py[1519-1539]

### Implementation guidance
- Extend `ISSUE_ID_AND_BLOCKERS_QUERY` to include `state` (and optionally `closedAt`).
- In `link_blocker()`, reject `state != "OPEN"` with a clear error detail and do **not** attempt the mutation.
- Adjust the existing error detail string so it matches the actual validation failure reason.
- Add unit tests for closed dependent behavior by mocking the GraphQL response with `state: "CLOSED"`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Wrong no-repo exit code ✓ Resolved 🐞 Bug ≡ Correctness

Description

resolve_repo() calls run_gh(gh repo view ...), but run_gh exits with code 3 on any gh failure,
so running outside a gh-resolvable repo returns 3 instead of the documented exit code 1. This breaks
the script’s own exit-code contract and can misclassify a local context problem as an API failure.

Code

skills/nextwork/scripts/nextwork.py[R976-983]

+def resolve_repo(override: str | None) -> str:
+    if override:
+        if "/" not in override or override.count("/") != 1:
+            print(f"error: --repo must be owner/name, got: {override!r}", file=sys.stderr)
+            sys.exit(2)
+        return override
+    raw = run_gh(["repo", "view", "--json", "nameWithOwner"])
+    repo = json.loads(raw)["nameWithOwner"]

Relevance

●●● Strong

Team often fixes scripts to match documented exit-code contracts; low-risk correctness change.

PR-#3610

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The script documents exit code 1 for missing gh or not being in a resolvable repository, but
run_gh exits 3 on any gh failure and resolve_repo uses run_gh directly, so a gh repo view
failure can’t produce exit code 1.

skills/nextwork/SKILL.md[150-157]
skills/nextwork/scripts/nextwork.py[906-918]
skills/nextwork/scripts/nextwork.py[976-990]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`resolve_repo()` is documented to exit with code **1** when not inside a gh-resolvable repository, but it currently calls `run_gh(...)`, which hard-exits with code **3** on `CalledProcessError`.

### Issue Context
This makes the CLI’s exit-code contract in `skills/nextwork/SKILL.md` incorrect in a common scenario (running from a directory without a gh-resolvable git remote).

### Fix Focus Areas
- skills/nextwork/scripts/nextwork.py[906-918]
- skills/nextwork/scripts/nextwork.py[976-990]
- skills/nextwork/SKILL.md[150-157]

### Implementation guidance
- Detect “not in a repo context” explicitly (e.g., `git rev-parse --is-inside-work-tree` and/or checking for a resolvable remote) and `sys.exit(1)` for that case.
- Preserve `sys.exit(3)` for genuine API/auth/network failures.
- Add/adjust a unit test for `resolve_repo` behavior by patching `subprocess.run` for both the git check and the `gh repo view` call.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. nextwork.py runs gh directly 📘 Rule violation ⌂ Architecture

Description

skills/nextwork/scripts/nextwork.py shells out to the gh CLI via subprocess.run() outside of
internal/forge/github/, violating the restriction on where gh may be invoked. This bypasses the
repo’s intended GitHub/forge abstraction boundary and makes GitHub integration harder to audit and
evolve consistently.

Code

skills/nextwork/scripts/nextwork.py[R895-903]

+def try_run_gh(args: list[str]) -> str | None:
+    """Run gh and return stdout, or None if the command failed."""
+    try:
+        result = subprocess.run(["gh", *args], check=True, capture_output=True, text=True)
+    except FileNotFoundError:
+        _gh_not_found()
+    except subprocess.CalledProcessError:
+        return None
+    return result.stdout.strip()

Relevance

● Weak

Close precedent: team previously rejected enforcing “gh only under internal/forge/github” for
another gh subprocess call.

PR-#2277

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1062053 restricts gh CLI invocation to code under internal/forge/github/. The
new file skills/nextwork/scripts/nextwork.py adds direct gh execution via `subprocess.run(["gh",
...])`, which is outside the allowed directory.

Rule 1062053: Restrict gh CLI exec.Command usage to internal/forge/github
skills/nextwork/scripts/nextwork.py[895-903]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`skills/nextwork/scripts/nextwork.py` invokes the `gh` CLI directly (via `subprocess.run(["gh", ...])`) even though the compliance policy restricts `gh` usage to `internal/forge/github/`.

## Issue Context
This PR introduces a new GitHub-integrating script (`/nextwork`). To comply with the repo’s forge boundaries, GitHub CLI invocation should be centralized in the allowed location and consumed via an abstraction instead of being called directly from a skill script.

## Fix Focus Areas
- skills/nextwork/scripts/nextwork.py[895-973]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context used

✅ Compliance rules (platform): 54 rules

✅ Skills: writing-user-docs, writing-adrs

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[fullsend-ai-review]

Review

Findings

High

• [protected-path] skills/nextwork/ — 8 files under the protected skills/ path are added or modified: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, 3 testdata fixtures, skills/topissues/scripts/topissues.py, and skills/topissues/scripts/topissues_test.py. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:341 — agent_terminal_succeeded returns True as its default fallback when no explicit success or failure markers are found in the body text. A terminal agent-status comment with a malformed or unanticipated body format would be silently classified as success, potentially clearing a launch wait prematurely. The function docstring documents this as intentional for legacy sticky triage posts, and the function is only called after AGENT_TERMINAL_MARKER in body is confirmed, bounding the surface. The test test_ambiguous_body_defaults_to_success exercises this path.

• [naming-inconsistency] skills/nextwork/scripts/nextwork.py:1171 — The new run_gh_soft function name diverges from the established try_run_gh name used for the same pattern in topissues.py (a gh wrapper that returns None on failure). nextwork.py defines both names — try_run_gh as a thin delegate to run_gh_soft — introducing a second name for the same concept. run_gh_soft adds a quiet parameter used by apply_trivial_actions, so the function is a superset, but the naming divergence creates style inconsistency. Additionally, try_run_gh is defined but never called within nextwork.py — all call sites use run_gh_soft directly.
  Remediation: Consider renaming run_gh_soft to try_run_gh (adding the quiet parameter there) and removing the wrapper.

• [code-duplication] skills/nextwork/scripts/nextwork.py:28 — Substantial code is explicitly copied from skills/topissues/scripts/topissues.py (comment at line 28). Duplicated helpers include regex patterns, link-parsing functions, and gh CLI wrappers. The PR also updates the topissues.py regex to stay in sync, demonstrating the maintenance cost. Both files now carry cross-reference comments, which partially mitigates the risk.
  Remediation: Consider extracting shared helpers into a common module, or accept the duplication as a trade-off for stdlib-only scripts.

• [type-hint-inconsistency] skills/topissues/scripts/topissues.py:296 — _gh_not_found() is declared with return type None in topissues.py but NoReturn in nextwork.py. Both functions always call sys.exit(1) and never return, so NoReturn is the more accurate type hint.
  Remediation: Update topissues.py to use -> NoReturn for _gh_not_found().

• [missing-cross-reference] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md includes a "vs /topissues" section, but the reverse reference is absent.
  Remediation: Add a "See also" note to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run

Review

Findings

High

• [protected-path] skills/nextwork/ — 8 files under the protected skills/ path are added or modified: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, 3 testdata fixtures, skills/topissues/scripts/topissues.py, and skills/topissues/scripts/topissues_test.py. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:326 — agent_terminal_succeeded returns True as its default fallback when no explicit success or failure markers are found in the body text. A terminal agent-status comment with a malformed or unanticipated body format would be silently classified as success, potentially clearing a launch wait prematurely. The function docstring documents this as intentional for legacy sticky triage posts, and the function is only called after AGENT_TERMINAL_MARKER in body is confirmed, bounding the surface. The test test_ambiguous_body_defaults_to_success exercises this path.

• [naming-inconsistency] skills/nextwork/scripts/nextwork.py:1162 — The new run_gh_soft function name diverges from the established try_run_gh name used for the same pattern in topissues.py (a gh wrapper that returns None on failure). nextwork.py defines both names — try_run_gh as a thin delegate to run_gh_soft — introducing a second name for the same concept. run_gh_soft adds a quiet parameter used by apply_trivial_actions, so the function is a superset, but the naming divergence creates style inconsistency.
  Remediation: Consider renaming run_gh_soft to try_run_gh (adding the quiet parameter there) and removing the wrapper.

• [code-duplication] skills/nextwork/scripts/nextwork.py:27 — Substantial code is explicitly copied from skills/topissues/scripts/topissues.py (comment at line 27). Duplicated helpers include regex patterns, link-parsing functions, and gh CLI wrappers. The PR also updates the topissues.py regex to stay in sync, demonstrating the maintenance cost. Both files now carry cross-reference comments, which partially mitigates the risk.
  Remediation: Consider extracting shared helpers into a common module, or accept the duplication as a trade-off for stdlib-only scripts.

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md includes a "vs /topissues" section, but the reverse reference is absent.
  Remediation: Add a "See also" note to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (2)

Review

Findings

High

• [protected-path] skills/nextwork/ — 8 files under the protected skills/ path are added or modified: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, 3 testdata fixtures, skills/topissues/scripts/topissues.py, and skills/topissues/scripts/topissues_test.py. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:326 — agent_terminal_succeeded returns True as its default fallback when no explicit success or failure markers are found in the body text. A terminal agent-status comment with a malformed or unanticipated body format would be silently classified as success, potentially clearing a launch wait prematurely. The function docstring documents this as intentional for legacy sticky triage posts, and the function is only called after AGENT_TERMINAL_MARKER in body is confirmed, bounding the surface. The test test_ambiguous_body_defaults_to_success exercises this path.

• [code-duplication] skills/nextwork/scripts/nextwork.py:27 — Substantial code is explicitly copied from skills/topissues/scripts/topissues.py (comment at line 27). Duplicated helpers include regex patterns, link-parsing functions, and gh CLI wrappers. The PR also updates the topissues.py regex to stay in sync, demonstrating the maintenance cost.
  Remediation: Consider extracting shared helpers into a common module, or add a cross-reference comment in topissues.py pointing back to nextwork.py.

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md cross-references /topissues (in the "vs /topissues" section), but the reverse reference is absent.
  Remediation: Add a "See also" note to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (3)

Review

Findings

High

• [protected-path] skills/nextwork/ — 7 files under the protected skills/ path are added or modified: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, 3 testdata fixtures, and skills/topissues/scripts/topissues.py. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Medium

• [null-handling] skills/nextwork/scripts/nextwork.py:1616 — _pulls_for_linking accesses data["repository"]["pullRequests"] without defensive null handling after the gh_graphql_or_none call. If the GraphQL response returns {"data": {"repository": null}} (e.g., insufficient permissions for a cross-repo linked-PR scan), this raises an unhandled TypeError. Other GhFetcher methods (fetch_item, _default_branch, is_in_merge_queue) all use the defensive (data.get("repository") or {}).get(...) pattern, making this an inconsistency.
  Remediation: Use the same defensive access pattern: repo_data = data.get("repository") or {}; conn = repo_data.get("pullRequests"); if conn is None: break.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:326 — agent_terminal_succeeded returns True as its default fallback when no explicit success or failure markers are found in the body text. A terminal agent-status comment with a malformed or unanticipated body format would be silently classified as success, potentially clearing a launch wait prematurely. The function docstring documents this as intentional for legacy sticky triage posts, and the function is only called after AGENT_TERMINAL_MARKER in body is confirmed, bounding the surface. The test test_ambiguous_body_defaults_to_success exercises this path.

• [test-adequacy] skills/topissues/scripts/topissues.py:17 — The PR_ISSUE_RE regex in topissues.py was broadened to match additional verb forms (closed, fixed, resolved) alongside the existing ones. The topissues test suite only tests closes and partial-fix, so the newly-matched verb forms are not exercised by topissues tests. The broadening is correct by inspection.

• [code-duplication] skills/nextwork/scripts/nextwork.py:27 — Substantial code is explicitly copied from skills/topissues/scripts/topissues.py (comment at line 27). Duplicated helpers include regex patterns, link-parsing functions, and gh CLI wrappers. The PR also updates the topissues.py regex to stay in sync, demonstrating the maintenance cost.
  Remediation: Consider extracting shared helpers into a common module, or add a cross-reference comment in topissues.py pointing back to nextwork.py.

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md cross-references /topissues (in the "vs /topissues" section), but the reverse reference is absent.
  Remediation: Add a "See also" note to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (4)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:326 — agent_terminal_succeeded returns True as its default fallback when no explicit success or failure markers are found in the body text. A terminal agent-status comment with a malformed or unanticipated body format would be silently classified as success, potentially clearing a launch wait prematurely. The function docstring documents this as intentional for legacy sticky triage posts, and the function is only called after AGENT_TERMINAL_MARKER in body is confirmed, bounding the surface. The test test_ambiguous_body_defaults_to_success exercises this path.

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md cross-references /topissues(in the "vs/topissues" section), but the reverse reference is absent. Remediation: Add a "See also" note to skills/topissues/SKILL.mdmentioning/nextwork`.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (5)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:326 — agent_terminal_succeeded returns True as its default fallback when no explicit success or failure markers are found in the body text. A terminal agent-status comment with a malformed or unanticipated body format would be silently classified as success, potentially clearing a launch wait prematurely. The function docstring documents this as intentional for legacy sticky triage posts, and the function is only called after AGENT_TERMINAL_MARKER in body is confirmed, bounding the surface. The test test_ambiguous_body_defaults_to_success exercises this path.

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md cross-references /topissues (in the "vs /topissues" section), but the reverse reference is absent.
  Remediation: Add a "See also" note to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (6)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:326 — agent_terminal_succeeded returns True as its default fallback when no explicit success or failure markers are found in the body text. A terminal agent-status comment with a malformed or unanticipated body format would be silently classified as success, potentially clearing a launch wait prematurely. The function docstring documents this as intentional for legacy sticky triage posts, and the function is only called after AGENT_TERMINAL_MARKER in body is confirmed, bounding the surface.
  Remediation: Add a test for the default-to-True fallback path with an ambiguous body.

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md cross-references /topissues (in the "vs /topissues" section), but the reverse reference is absent.
  Remediation: Add a "See also" note to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (7)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md cross-references /topissues (in the "vs /topissues" section), but the reverse reference is absent.
  Remediation: Add a "See also" note to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (8)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [error-handling] skills/nextwork/scripts/nextwork.py:451 — classify_inflight_agent calls is_stale(latest['created_at'], ...) where latest['created_at'] could be the empty string ''. This happens when latest_agent_status encounters a comment whose created_at is None (using or ""). The empty string propagates to is_stale → hours_since, which guards with if not iso_value: return 0.0, so no crash occurs. In practice GitHub always populates createdAt, making this a defensive-coding concern.
  Remediation: Have is_stale or hours_since handle empty/None inputs by returning False/0.0, mirroring the guard in created_at_key.

• [edge-case] skills/nextwork/scripts/nextwork.py:320 — latest_agent_status uses max(key=created_at_key) with (created_at_key, index) tie-breaking to select the chronologically latest agent-status comment. If two comments share the same created_at, max returns the last one in list order. This is correct since GitHub API returns comments in chronological order, but is an implicit dependency on input ordering.

• [edge-case] skills/nextwork/scripts/nextwork.py:375 — latest_completed_triage picks the chronologically latest completion signal from both terminal agent-status and sticky <!-- fullsend:triage-agent --> markers. The max over candidates with (created_at_key, index) tie-breaking means the chronologically latest signal wins regardless of type, which is correct per the docstring.

• [logic-error] skills/nextwork/scripts/nextwork.py:956 — In classify_pr, when review_decision is None and there are no explicit launch signals, updated_at is used as a fallback review signal. The condition review_decision in (None, "REVIEW_REQUIRED") is always True when review_decision is None, so every PR without a review_decision that reaches this point enters the review launch-wait path. The inline comment at lines 951–954 documents this as intentional design.

• [naming-convention] skills/nextwork/scripts/nextwork.py:1048 — _gh_not_found() is annotated -> NoReturn, while topissues.py's equivalent at line 295 uses -> None. NoReturn is more accurate since both call sys.exit(1), but the inconsistency between the two files is notable.
  Remediation: Update topissues.py to use -> NoReturn (the technically correct annotation per PEP 484), or match the existing pattern for consistency.

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md cross-references /topissues (lines 62–70), but the reverse reference is absent.
  Remediation: Add a "See also" section to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (9)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [error-handling] skills/nextwork/scripts/nextwork.py:429 — classify_inflight_agent calls is_stale(latest['created_at'], ...) where latest['created_at'] could be the empty string ''. This happens when latest_agent_status encounters a comment whose created_at is None (using or ""). The empty string would propagate to is_stale → hours_since → parse_iso('') which raises ValueError. In practice GitHub always populates createdAt, making this a defensive-coding concern. The codebase already handles empty/None in created_at_key but is_stale lacks the same guard.
  Remediation: Have is_stale or hours_since handle empty/None inputs by returning False/0.0, mirroring the guard in created_at_key.

• [logic-error] skills/nextwork/scripts/nextwork.py:934 — In classify_pr, when review_decision is None and there are no explicit launch signals, updated_at is used as a fallback review signal. The condition review_decision in (None, "REVIEW_REQUIRED") is always True when review_decision is None, so every PR without a review_decision that reaches this point enters the review launch-wait path. The inline comment at lines 929–932 documents this as intentional design.

• [edge-case] skills/nextwork/scripts/nextwork.py:325 — latest_agent_status uses max(key=created_at_key) to select the chronologically latest agent-status comment. If two comments share the same created_at, max returns the last one in list order (Python 3 guarantee). This is correct since GitHub API returns comments in chronological order, but is an implicit dependency on input ordering.

• [edge-case] skills/nextwork/scripts/nextwork.py:372 — latest_completed_triage unconditionally prefers a terminal agent-status over a sticky <!-- fullsend:triage-agent --> marker, even if the sticky comment is chronologically newer. This is by design per the docstring but means a scenario with terminal run A followed by newer sticky-only run B would report run A’s timestamp.

• [naming-convention] skills/nextwork/scripts/nextwork.py:1026 — _gh_not_found() is annotated -> NoReturn, while topissues.py’s equivalent at line 295 uses -> None. NoReturn is more accurate since both call sys.exit(1), but the inconsistency between the two files is notable.
  Remediation: Update topissues.py to use -> NoReturn (the technically correct annotation per PEP 484), or match the existing pattern for consistency.

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork’s SKILL.md cross-references /topissues (lines 19–27), but the reverse reference is absent.
  Remediation: Add a "See also" section to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (10)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Low

• [logic-error] skills/nextwork/scripts/nextwork.py:1374 — In classify_pr, when review_decision is None and there are no explicit launch signals, updated_at is used as a fallback review signal. The condition at line 1377 is always true when review_decision is None (since None in (None, "REVIEW_REQUIRED") is True), meaning every PR without a review_decision that reaches this point enters the review launch-wait path. For old PRs, this produces trigger_review even without review-related labels. However, by this point the PR has passed extensive preceding checks (assignee, in-flight agent, conflict, manual-review labels, CI failure, unresolved threads, draft, approved, etc.), making this a reasonable design heuristic. Consider documenting this fallback behavior explicitly.

• [edge-case] skills/nextwork/scripts/nextwork.py:777 — latest_agent_status selects the chronologically latest agent-status comment by comparing created_at strings lexicographically. GitHub API consistently returns ISO 8601 timestamps in YYYY-MM-DDTHH:MM:SSZ format which sorts correctly, but the parse_iso helper (used for arithmetic elsewhere) is not used here — a theoretical fragility if GitHub ever changed timestamp formats.

• [edge-case] skills/nextwork/scripts/nextwork.py:929 — In classify_launch_wait, the comparison completed["created_at"] >= at uses the same lexicographic string pattern. Consistent within the file (ordering uses strings, arithmetic uses parse_iso) but worth noting as a design choice.

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md cross-references /topissues, but the reverse reference is absent.
  Remediation: Add a "See also" section to skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (11)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Medium

• [missing-authorization] skills/nextwork/SKILL.md — No linked issue for a substantial new feature (4000+ lines across 8 files). The PR body explains the intent clearly and includes a dedicated "vs /topissues" rationale, but non-trivial features should have explicit authorization via a linked issue establishing scope and acceptance criteria.
  Remediation: Create a GitHub issue documenting the problem /nextwork solves, acceptance criteria, and scope boundaries. Link it to this PR.

• [architectural-coherence] skills/nextwork/SKILL.md:19 — The skill introduces a parallel work-queue mechanism alongside /topissues with overlapping conceptual territory (both answer "what to work on"). SKILL.md includes an inline "vs /topissues" justification (readiness vs. priority, no project dependency), which is reasonable — but the repo has an established ADR practice and this is a substantive architectural decision about skill scope boundaries that should be formally documented.
  Remediation: Document the architectural decision in an ADR: why the project maintains two work-queue skills, the boundary between them, and when to use each.

• [shared-code-duplication] skills/nextwork/scripts/nextwork.py:27 — Substantial code is explicitly copied from skills/topissues/scripts/topissues.py (comment on line 27). Duplicated helpers include regex patterns (PR_ISSUE_RE, REF_URL_RE, REF_REPO_HASH_RE, REF_BARE_RE), link-parsing functions (parse_pr_links, build_pr_links_by_issue, parse_open_blockers), and gh CLI wrappers (_gh_not_found, try_run_gh, run_gh, gh_graphql). Notably, nextwork.py introduces a more correct graphql_var_flags implementation (typed -F flags for int/bool/float) that topissues.py lacks — illustrating the maintenance divergence risk.
  Remediation: Extract shared helpers into a common module and import from both scripts. Backport graphql_var_flags to topissues.py.

Low

• [missing-documentation] skills/topissues/SKILL.md — The /topissues skill documentation does not mention the new /nextwork skill. nextwork's SKILL.md cross-references /topissues, but the reverse reference is absent. Adding a "See also" section would help users discover the complementary skill.
  Remediation: Add a brief cross-reference in skills/topissues/SKILL.md mentioning /nextwork.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (12)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Medium

• [shared-code-duplication] skills/nextwork/scripts/nextwork.py:25 — Substantial code is explicitly copied from skills/topissues/scripts/topissues.py (comment on line 25). Duplicated helpers include regex patterns (PR_ISSUE_RE, REF_URL_RE, REF_REPO_HASH_RE, REF_BARE_RE), link-parsing functions (parse_pr_links, build_pr_links_by_issue, parse_open_blockers), and gh CLI wrappers (_gh_not_found, try_run_gh, run_gh, gh_graphql, resolve_repo, resolve_user). Notably, nextwork.py introduces a more correct graphql_var_flags implementation (typed -F flags for int/bool/float) that topissues.py lacks — illustrating the maintenance divergence risk.
  Remediation: Extract shared helpers into a common module and import from both scripts.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:536 — In classify_issue and classify_pr, assigned_elsewhere is checked before in-flight agent detection. This is a deliberate design choice documented in the SKILL.md status catalog ("Classification priority: structured blockers and assigned_elsewhere win over in-flight automation waits").

• [edge-case] skills/nextwork/scripts/nextwork.py:455 — is_completed_triage_stale exempts /fs-code and /fs-triage commands from stale-flipping but does not exempt /fs-review or /fs-fix. If someone comments /fs-review or /fs-fix on an issue after a completed triage, it would mark the triage as stale and trigger re-triage. In practice these commands are only used on PRs, so the impact is minimal.

• [error-handling] skills/nextwork/scripts/nextwork.py:910 — _gh_not_found always calls sys.exit(1) but is annotated as returning None. A type checker would flag result as potentially unbound in callers. Annotating as -> NoReturn (from typing) would be more precise.

• [architectural-coherence] skills/nextwork/SKILL.md:60 — Conceptual overlap with /topissues exists. The SKILL.md includes a dedicated "vs /topissues" section that articulates the distinction (readiness vs. priority, no project dependency), which provides reasonable justification for separate skills.

Previous run (13)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Medium

• [shared-code-duplication] skills/nextwork/scripts/nextwork.py:25 — Substantial code is explicitly copied from skills/topissues/scripts/topissues.py (comment on line 25). Duplicated helpers include regex patterns (PR_ISSUE_RE, REF_URL_RE, REF_REPO_HASH_RE, REF_BARE_RE), link-parsing functions (parse_pr_links, build_pr_links_by_issue, parse_open_blockers), and gh CLI wrappers (_gh_not_found, try_run_gh, run_gh, gh_graphql, resolve_repo, resolve_user). Notably, nextwork.py introduces a more correct graphql_var_flags implementation (typed -F flags for int/bool/float) that topissues.py lacks — illustrating the maintenance divergence risk.
  Remediation: Extract shared helpers into a common module and import from both scripts.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:536 — In classify_issue and classify_pr, assigned_elsewhere is checked before in-flight agent detection. This is a deliberate design choice documented in the SKILL.md status catalog ("Classification priority: structured blockers and assigned_elsewhere win over in-flight automation waits").

• [edge-case] skills/nextwork/scripts/nextwork.py:455 — is_completed_triage_stale exempts /fs-code and /fs-triage commands from stale-flipping but does not exempt /fs-review or /fs-fix. If someone comments /fs-review or /fs-fix on an issue after a completed triage, it would mark the triage as stale and trigger re-triage. In practice these commands are only used on PRs, so the impact is minimal.

• [error-handling] skills/nextwork/scripts/nextwork.py:910 — _gh_not_found always calls sys.exit(1) but is annotated as returning None. A type checker would flag result as potentially unbound in callers. Annotating as -> NoReturn (from typing) would be more precise.

• [architectural-coherence] skills/nextwork/SKILL.md:60 — Conceptual overlap with /topissues exists. The SKILL.md includes a dedicated "vs /topissues" section that articulates the distinction (readiness vs. priority, no project dependency), which provides reasonable justification for separate skills.

Previous run (14)

Review

Findings

High

• [protected-path] skills/nextwork/ — 6 files under the protected skills/ path are added: skills/nextwork/SKILL.md, skills/nextwork/scripts/nextwork.py, skills/nextwork/scripts/nextwork_test.py, and 3 testdata fixtures. The PR has no linked issue (Related Issue: N/A) justifying the addition of governance/infrastructure files. Human approval is required for all protected-path changes regardless of context.

Medium

• [shared-code-duplication] skills/nextwork/scripts/nextwork.py:25 — Substantial code is explicitly copied from skills/topissues/scripts/topissues.py (comment on line 25: "copied from skills/topissues/scripts/topissues.py"). Duplicated helpers include regex patterns (PR_ISSUE_RE, REF_URL_RE, REF_REPO_HASH_RE, REF_BARE_RE), link-parsing functions (parse_pr_links, build_pr_links_by_issue, parse_open_blockers), and gh CLI wrappers (_gh_not_found, try_run_gh, run_gh, gh_graphql, resolve_repo, resolve_user). Bug fixes would need to be applied in both locations.
  Remediation: Extract shared helpers into a common module and import from both scripts.

• [architectural-coherence] skills/nextwork/SKILL.md:60 — Significant conceptual overlap with /topissues: both traverse GitHub issues/PRs, both filter by assignment, both recommend next actions. The SKILL.md distinguishes the two ("readiness-oriented, not priority-scored") but the architectural justification for maintaining two parallel work-queue systems is thin. A design rationale (or ADR) explaining when users should invoke /nextwork vs /topissues would help.

Low

• [edge-case] skills/nextwork/scripts/nextwork.py:1159 — Comment bodies are truncated to 500 characters in normalize_item before classification. Agent-status detection functions search for HTML markers (<!-- fullsend:agent-status:... -->, <!-- fullsend:status:terminal -->) in the truncated body. These markers appear at the start of comments in practice, so truncation is safe today, but applying truncation at the normalization layer rather than at output time is slightly fragile if the comment format ever changes.

• [edge-case] skills/nextwork/scripts/nextwork.py:538 — In classify_issue and classify_pr, assigned_elsewhere is checked before in-flight agent detection. The SKILL.md status catalog presents waiting-on-automation statuses before blocked/deferred/owned-elsewhere statuses, which could imply the opposite priority. Consider adding a note to SKILL.md clarifying that assignment takes precedence over automation status.

• [edge-case] skills/nextwork/scripts/nextwork.py:815 — An approved PR that retains a stale ready-for-review label (without ready-for-merge) would be classified as waiting_review (eliminated) rather than surfacing as actionable. Narrow edge case, but could surprise users whose PR was approved but still shows as waiting.

---

Labels: PR adds a new skill under skills/nextwork/ and introduces a new user-facing feature

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 12:09 PM UTC · Completed 12:25 PM UTC
Commit: a797c4d · View workflow run →

[ifireball]

Babysit update

Merged upstream/main (no rebase) and pushed fix(nextwork): address review feedback and CI lint failures (8570cdb).

CI: prior test failure was ruff E501/format + ty max(thread_times) — fixed in that commit.

Review threads: replied and resolved all 9 inline threads (qodo + fullsend-ai-review). Shared-helper extraction across /topissues deferred as follow-up.

Protected-path (skills/): intentional new skill; still needs human approval (no linked issue yet).

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 8:33 PM UTC · Ended 8:35 PM UTC
Commit: 8570cdb · View workflow run →

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 8:37 PM UTC · Ended 8:54 PM UTC
Commit: eb58e7f · View workflow run →

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 8:37 PM UTC · Completed 8:54 PM UTC
Commit: eb58e7f · View workflow run →

[waynesun09]

Automated review pass: 8 findings (2 high, 6 medium) on skills/nextwork/scripts/nextwork.py, posted inline. These are additional to prior review rounds and were checked against existing PR comments to avoid duplicates.

[waynesun09]

Review-only sweep: 3 findings (all MEDIUM), verified against the current head and checked against the existing review comments/fix threads on this PR — none of these three are covered by prior fixes.

[waynesun09]

Approving — no blocking issues. The confirmation-gate bypass for --take-over/--link-blocker (flagged last round) is confirmed fixed across the last 3 commits. Remaining 3 findings are non-blocking MEDIUM fast-follows: prose-only (not code-enforced) mutation gating as defense-in-depth, markdown output missing the truncation notice that JSON output already has, and a misleading suggested-action string for fullsend-no-fix. CI green, all other threads resolved.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 11:55 AM UTC · Completed 12:09 PM UTC
Commit: 03dfa63 · View workflow run →

[waynesun09]

Automated review sweep: 2 findings posted inline (1 high, 1 medium).

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 5:24 PM UTC · Completed 5:40 PM UTC
Commit: e6247ca · View workflow run →

[fullsend-ai-review]

See the review comment for full details.

---

Note: The following inline comments could not be posted on the diff (GitHub returned 422) and are included here instead:

• skills/nextwork/scripts/nextwork.py:341: [low] edge-case

agent_terminal_succeeded returns True as its default fallback when no explicit success or failure markers are found in the body text. A terminal agent-status comment with a malformed or unanticipated body format would be silently classified as success, potentially clearing a launch wait prematurely. The function docstring documents this as intentional for legacy sticky triage posts, and the function is only called after AGENT_TERMINAL_MARKER in body is confirmed, bounding the surface. The test test_ambiguous_body_defaults_to_success exercises this path.

• skills/nextwork/scripts/nextwork.py:1171: [low] naming-inconsistency

The new run_gh_soft function name diverges from the established try_run_gh name used for the same pattern in topissues.py (a gh wrapper that returns None on failure). nextwork.py defines both names - try_run_gh as a thin delegate to run_gh_soft - introducing a second name for the same concept. Additionally, try_run_gh is defined but never called within nextwork.py - all call sites use run_gh_soft directly.

Suggested fix: Consider renaming run_gh_soft to try_run_gh (adding the quiet parameter there) and removing the wrapper.

• skills/nextwork/scripts/nextwork.py:28: [low] code-duplication

Substantial code is explicitly copied from skills/topissues/scripts/topissues.py (comment at line 28). Duplicated helpers include regex patterns, link-parsing functions, and gh CLI wrappers. The PR also updates the topissues.py regex to stay in sync, demonstrating the maintenance cost. Both files now carry cross-reference comments, which partially mitigates the risk.

Suggested fix: Consider extracting shared helpers into a common module, or accept the duplication as a trade-off for stdlib-only scripts.

• skills/topissues/scripts/topissues.py (file-level): Line 296 · [low] type-hint-inconsistency

_gh_not_found() is declared with return type None in topissues.py but NoReturn in nextwork.py. Both functions always call sys.exit(1) and never return, so NoReturn is the more accurate type hint.

Suggested fix: Update topissues.py to use -> NoReturn for _gh_not_found().

[ifireball]

Triaging the latest fullsend-ai-review findings (sticky comment; inline posts failed on this push):

[high] protected-path (skills/) — Process gate only. Human reviews already APPROVED (ascerra, waynesun09). No code change.

[medium] shared-code-duplication — Ignored for this PR (accepted with cross-reference comments). Shared module is follow-up.

[medium] architectural-coherence (/nextwork vs /topissues) — Already covered in skills/nextwork/SKILL.md § “vs /topissues”.

[low] comment truncation before classification — Incorrect on current head: COMMENT_TRUNCATE_CHARS applies only to JSON --include-text output, not to classification inputs.

[low] assignment vs waiting catalog order — Already documented under Classification priority in the skill.

[low] APPROVED + leftover ready-for-review — Already fixed: approved PRs short-circuit to actionable human_work before the review-wait path.

No new code changes for this round — PR stays merge-ready.

Findings triaged in #5641 (comment) — already fixed, docs-covered, or deferred; no actionable code changes remain.

[waynesun09]

Review-only sweep: 3 findings (all MEDIUM), verified against current head (e6247ca) and checked against the ~170 existing review comments/fix threads on this PR — none of these three are covered by prior fixes.

[waynesun09]

[MEDIUM] Skipped terminal runs behave like failures, risking a stale-hours re-trigger loop for skip reasons that won't change

agent_terminal_succeeded() (line 340) correctly returns False for a ⏭️ Skipped terminal body, so latest_terminal_agent() never counts it as completed. In classify_launch_wait() (line 541+), when completed is None and the original launch signal goes stale (>= --stale-hours, default 6h), the function falls into the branch that recommends (and under --apply, re-posts) the exact same /fs-* command that just got skipped.

That's consistent with intent for genuine failures (per the earlier fix: "Failed/cancelled/terminated runs leave the launch wait in place so we can re-trigger after stale hours"), but a skip is different: skip reasons like ⏭️ Skipped (change is already in review on #123) describe a condition that a mere retry after N hours doesn't change. There's no test exercising the compounding scenario (skip → stale → re-trigger → skip again), and this is a distinct interaction from the already-fixed "skip treated as success" bug — that fix changed skip from clearing the wait to not clearing it, which is what now feeds it into the blind-retry path.

Suggestion: consider distinguishing skip from failure for retry purposes (e.g., only re-trigger a skip after a longer/backoff window, or surface it as human_work asking a person to confirm the skip reason no longer applies) instead of treating it identically to a hard failure that's likely to succeed on blind retry.

[waynesun09]

[MEDIUM] Default markdown output never surfaces suggested_actions, so it doesn't stand alone as the documented "recommend the next action" tool

_format_item_line() renders only - {link} {title} — _{status}_: {reason} — no suggested_actions. format_markdown_output() calls this for every Do now / Waiting / Blocked / Assigned elsewhere item and never threads suggested_actions through at all, even though every Classification populates it and format_json_output emits it in full.

SKILL.md's own description states the skill's job is to "...classify every item into a status catalog, and recommend the next action", and --format markdown is the documented default. This isn't called out anywhere as a known limitation. Anyone running python3 skills/nextwork/scripts/nextwork.py directly (i.e., not through the /nextwork skill, which always forces --format json) sees only a status label and a reason, not the concrete recommended action.

Suggestion: render suggested_actions (or a short human-readable summary of it) per item in _format_item_line, at least in the "Do now" section, so direct markdown usage matches the tool's stated purpose.

[waynesun09]

[MEDIUM] Post-triage staleness exemption for /fs-* commands has no author-trust check, unlike the equivalent launch-signal path

is_completed_triage_stale() walks comments after a completed triage and, for each non-agent-marker comment, does cmd = comment_command(body); if cmd in ("/fs-code", "/fs-triage", "/fs-review", "/fs-fix"): continue — exempting it from counting as "non-exempt conversation" that would otherwise flip a fresh triage to needs_triage. This exemption calls comment_command(body) directly with no author/trust filtering.

By contrast, the equivalent launch-signal path was already hardened in a prior fix round: latest_fs_command_at() now requires _is_trusted_fs_commenter() (OWNER/MEMBER/COLLABORATOR authorAssociation or a fullsend bot) before trusting a /fs-* comment. is_completed_triage_stale() wasn't updated to use the same gate — any commenter, including an untrusted external user, can post a line starting with one of those four tokens to keep a triage looking "fresh" indefinitely, suppressing the needs_triage reclassification. This is a distinct code path from the already-fixed latest_fs_command_at/launch-signal trust gate.

Suggestion: filter the exemption check through _is_trusted_fs_commenter(c) (or equivalent) before treating a slash-command-prefixed comment as exempt from the post-triage staleness scan, matching the trust gate already applied to launch-signal detection.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 6:44 PM UTC · Completed 7:05 PM UTC
Commit: e6247ca · View workflow run →

[fullsend-ai-retro]

Retro: PR #5641 — feat(skills): add /nextwork readiness queue

Timeline. PR #5641 was a human-authored PR by ifireball adding a /nextwork skill (~5400 lines across 10 files, including a 2600-line Python script). Opened Jul 27, merged Aug 5 (9 days). The review bot ran 14 review rounds over the PR's lifetime; human reviewer waynesun09 conducted 7 review passes. A second human reviewer (ascerra) approved on Aug 3. No code, fix, or triage agents were dispatched — this was a human-authored feature branch with no linked issue.

Review quality gap. The review bot found 0 HIGH-severity findings across all 14 rounds. Its only HIGH was protected-path (a governance gate flagging that skills/ files need human approval — a process check, not a code bug). The bot produced ~12 distinct findings total, of which 5 were actionable and 4 were false positives or low-value. By contrast, waynesun09 found 11 HIGH and 27 MEDIUM findings (49 distinct total), with 44 leading to code fixes and 0 false positives. Every critical correctness, security, and safety bug was found exclusively by the human reviewer:

• Trust boundary violations (agent-status markers accepted from any commenter)
• Mutation safety gate bypasses (--take-over/--link-blocker bypassing confirmation on read-only pass)
• Traversal order contradiction (docs say BFS, code is DFS)
• Cross-repo sub-issue misattribution
• Failed/cancelled agent runs treated as success
• Fix-thread bot-only detection only checking first comment

The bot's findings were entirely function-scoped edge cases, naming issues, and documentation gaps. It never performed cross-function or system-level analysis.

Evidence for existing issues:

• Review agent misses security-critical findings on large architectural PRs #898 (review agent misses security-critical findings on large architectural PRs): Strong evidence — 0/11 HIGH findings found on a 2600-line feature PR with complex trust boundaries and mutation logic.
• Review agent should deduplicate findings across re-review iterations on the same PR #2959, Deduplicate inline review comments across force-push re-reviews #5007, Review agent posts excessive inline comments on re-review — 54 comments on a 78-line file across 6 runs #5760 (stale/repeated findings): The bot repeated the agent_terminal_succeeded edge-case finding 7 times and shared-code-duplication 6 times across rounds, even after the author addressed or acknowledged them.
• Review agent should produce consistent verdicts when re-reviewing similar code on the same PR #5107 (inconsistent verdicts on re-review): On Aug 5, the bot filed DISMISSED (06:57), then CHANGES_REQUESTED (12:09), then DISMISSED (17:40) — all with essentially the same findings (1 HIGH protected-path + 4-5 LOWs).
• Review bot should not override human approval with stale findings #1922 (review bot overriding human approval with stale findings): The bot filed CHANGES_REQUESTED 11 times total, continuing even after two human APPROVED reviews existed on the PR.
• Review agent correctness sub-agent should construct concrete impact examples before assigning severity to edge-case findings #5264 (correctness sub-agent severity calibration): The bot's severity model rated its governance finding as HIGH while rating actual correctness edge cases as LOW; it never elevated any code-quality finding above MEDIUM.

What went well. The human review process was exceptionally thorough — 49 distinct findings across 7 passes, all substantive, with zero false positives. The author resolved every finding promptly. The PR was well-tested (2300-line test file, codecov confirmed full coverage). The bot's protected-path governance flag and cross-reference checks, while not bug-finding, did provide useful process signals.

Proposals filed

• Review agent should suppress governance CHANGES_REQUESTED when human approvals already satisfy the gate (in fullsend-ai/agents)