skills: add portable continue and status session-discipline skills

[justin808]

What

Add two portable skills — continue and status — that embody the "state where you are, verify, then report" discipline for any task, not just PR batches.

Why

continue replaces the common bare "continue from where you left off" with a checkpoint (what is done, what is next, definition of done + verification) so resumed work does not drift or repeat. status gives a tight done / in-progress / blocked / next report without kicking off new work.

These complement rather than duplicate the existing "portable closeout handoffs" guidance that lives inside the PR-processing workflows: those cover agent-to-agent handoff within a batch; these cover single-task resume and status.

Changes

• skills/continue/SKILL.md and skills/status/SKILL.md — concise, portable (no consumer-repo commands), honor AGENTS.md boundaries.
• README skill inventory updated with both rows.

Validation

bin/validate passes (skill frontmatter + helper suites + RuboCop clean).

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Warning

Review limit reached

@justin808, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 59 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 6dfad8aa-9b69-4329-a14c-8823e2b7086b

📥 Commits

Reviewing files that changed from the base of the PR and between 2d77671 and 5d4cdac.

📒 Files selected for processing (3)

• README.md
• skills/continue/SKILL.md
• skills/status/SKILL.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jg/continue-status-skills

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[justin808]

@claude review this PR

[claude]

Claude finished @justin808's task in 2s —— View job

---

I'll analyze this and get back to you.

[claude]

Code Review

This PR adds two portable session-discipline skills (continue and status) along with README inventory entries. The skill files are concise, free of consumer-repo specifics, and well-structured. Two issues found.

Finding 1 — README status description omits the "In progress" section (README.md line 125)

The table entry reads done/next/blocked but the skill body defines four sections: Done, In progress, Blocked / needs input, and Next. The frontmatter description field correctly lists all four; only the README table summary is truncated — a user skimming the table gets an incomplete picture.

Finding 2 — Hard-coded /status slash-command reference in continue creates a portability coupling (skills/continue/SKILL.md line 26)

The closing bullet says "Use /status to produce that report without starting new work." This names a specific slash-command by path. Per AGENTS.md editing rules, shared skills must stay generic. A consumer that installs continue without status, or renames the skill, ends up with a broken instruction. The reference should be dropped or reworded as prose, e.g. "run a status-only update without starting new work".

Both issues are minor and easy to fix before merge.

[claude]

Review

This PR adds two portable session-discipline skills — `/continue` and `/status` — that give agents a structured checkpoint for resuming work and reporting progress respectively. The skills are concise, contain no consumer-repo–specific commands or hardcoded paths, and comply with the AGENTS.md portability rules. Three issues are worth addressing before merge.

---

1. skills/status/SKILL.md — "nothing needed - proceeding" contradicts "Do not start new work"

The skill opens with "Do not start new work." but the suggested placeholder for the Blocked section says "If nothing, say 'nothing needed - proceeding'." The word proceeding reads as permission to resume execution immediately after the status report, which directly contradicts the skill's core invariant. An agent that interprets this literally will act instead of report.

Suggested fix: replace with something like "If nothing, say 'nothing blocked'."

---

2. skills/continue/SKILL.md — Step 4 and the closing bullet pull in opposite directions

Step 4 says "Continue working on the next step." (execute). The final bullet says "End with a short status line: … without starting new work." A model can read the closing bullet as a global constraint that overrides step 4, turning `/continue` into a status-report-only skill rather than an execution trigger. The ambiguity is especially sharp for models that process bullet constraints after numbered steps.

Suggested fix: clarify that "without starting new work" scopes only the status line itself, e.g. "End with a short status line … (this summary is not a trigger to start additional work beyond the step above)."

---

3. skills/continue/SKILL.md — Closing status line duplicates /status without referencing it

The closing bullet asks for "what changed, how it was verified, and what is left" — functionally the same content as /status, but in a different, unstructured format. When a caller chains `/continue` → `/status`, the two outputs are inconsistent in shape. If the formats diverge over time (e.g. someone adds a "Blocked" section to `/status`), `/continue` silently falls behind.

Suggested fix: reference the skill explicitly — "End by running `/status`." — or at least align the section labels with `skills/status/SKILL.md`.

[claude]

Review: skills/continue + skills/status

This PR adds two portable meta-skills — continue (structured resume with checkpoint) and status (tight progress snapshot without new work). Both are concise, pass the frontmatter validator, contain no consumer-repo hardcoding, and are correctly placed in the README table alphabetically. No binary, shell, or Ruby helpers were added, so there is no bin-safety surface.

Three findings survived verification, ranked below.

---

1. CONFIRMED — continue cold-start causes fabrication (skills/continue/SKILL.md line 12)

When /continue is invoked in a fresh session with no conversation history and a clean git tree, step 1 asks the agent to cite what is "already done". There is nothing to cite. The instruction on the same line — "state your best inference and proceed; do not stop to ask unless you are genuinely blocked" — actively suppresses the appropriate response. The agent will infer a plausible-sounding goal from ambient repo content and start executing it.

Suggested fix: add an explicit escape hatch — e.g. "If there is no task currently in progress (no prior conversation, no staged work, no recent commits on this branch), say so and ask the user what to continue instead of inferring a goal."

---

2. PLAUSIBLE — Duplicate label set risks silent divergence (skills/continue/SKILL.md line 26)

The closing-summary instruction in continue hardcodes the four labels Done, In progress, Blocked / needs input, Next — identical to the bold headers in status/SKILL.md. There is no citation between them. If a maintainer renames a label in status and tests /status in isolation, /continue silently diverges.

The inline self-containment is the right call for portability; the fix is to add a forward reference: "using the same labels as /status: Done, In progress, Blocked / needs input, Next".

---

3. PLAUSIBLE — status guard uses CI-specific vocabulary (skills/status/SKILL.md line 20)

"Do not run another review or build solely to produce a nicer status" is code-review/CI vocabulary. In a writing or design session, "review" means re-reading a draft — the lightweight check that grounds a good status update. A model working on prose could suppress that check incorrectly.

Suggested generic rewording: "Do not start new long-running work solely to produce a richer status report."

[claude]

Review: skills/continue and skills/status

This PR adds two portable session-discipline skills — continue and status — plus README inventory rows for both. The skills are generic, contain no consumer-repo commands or paths, and correctly defer repo-specific values to AGENTS.md. Two findings below, ranked by severity.

---

Finding 1 — Cross-skill reference uses internal file path instead of $status (medium)

skills/continue/SKILL.md line 28 says: 'End with a short status line using the same labels as skills/status/SKILL.md'

The established convention in this repo is to reference sibling skills by their invocation name with a $ prefix — e.g., $plan-pr-batch, $pr-batch in skills/spec/SKILL.md. The bare relative path skills/status/SKILL.md won't resolve once the skill is installed into an agent home (e.g., ~/.agents/skills/), where no skills/ subtree exists relative to the working directory.

Functional impact is low because the four labels are spelled out inline in the same sentence. But the path reference is a portability issue and inconsistent with the codebase convention. Suggested fix: replace with $status.

---

Finding 2 — continue skill body handles arguments but frontmatter lacks argument-hint (low)

skills/continue/SKILL.md line 21 says: 'If the user supplied focus text or arguments, treat it as additional direction or a narrowed scope for what to continue.' Every other skill that accepts arguments includes argument-hint in its YAML frontmatter (spec, evaluate-issue, pr-batch, triage, etc.). The continue frontmatter omits it. bin/validate does not enforce this key, so it won't break CI, but tooling that surfaces argument hints won't prompt the user. Suggested addition: argument-hint: '[focus text or scope]'

[justin808]

Address-review summary

Scan scope: unresolved review threads observed on 2026-06-30 after head aaf206c.

Mattered

• Portable cross-skill reference: fixed in 12116f9 by changing the closing status guidance to reference $status instead of an internal repo path.
• Optional argument metadata: fixed in 12116f9 by adding argument-hint: '[focus text or scope]' to skills/continue/SKILL.md.

Optional

• None.

Skipped

• None.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

[claude]

Review: skills — continue and status

This PR adds two portable meta-skills (continue and status) that layer structured checkpointing on top of any task. The scope is correct and neither file hardcodes consumer-repo commands, labels, branches, or paths. Portability passes cleanly.

Findings (most severe first)

1. Step 4 work scope is unbounded — continue/SKILL.md:20

Continue working on the next step does not say "exactly one step and then stop." Step 2 lists all remaining steps, and step 4 picks up from that list — an LLM can reasonably read step 4 as "work through the list until done" rather than "do just the single next item." The caveat on line 31 only restricts work beyond step 4, not the breadth of step 4 itself. Adding (stop after completing that one step) to line 20 would close the gap.

2. Step 3 verification assumes a runnable artifact — continue/SKILL.md:18–19

plus the command or test that will verify it only fits coding tasks. For documentation, research, or planning resumptions there is no runnable command. The LLM will either hallucinate a spurious command or stall asking the user. Adding "or describe how done will be confirmed" covers the non-code path.

3. Done in status conflates finished-but-unverified work — status/SKILL.md:12

Done — what is complete and verified merges two distinct states. Work that is finished but not yet tested cannot sit under Done (label says "verified") nor under In progress (it is no longer in progress). The report will silently drop or misclassify those items. Options: loosen to "Done — what is complete (cite whether verified)", or let "In progress" absorb "done but untested" items explicitly.

4. continue's closing summary omits the "nothing blocked" fill-in — continue/SKILL.md:29

status/SKILL.md:16 mandates the exact phrase nothing blocked when there are no blockers, so the section is never silently dropped. The continue closing line references the same four labels but never mentions this fill-in rule. A model writing the closing summary under continue will drop the Blocked section entirely when nothing is blocked, producing a three-section summary instead of the consistent four-section format.

5. $status cross-reference creates undeclared co-install coupling — continue/SKILL.md:29

using the same labels as \$status`implies a live invocation reference. If a consumer installscontinuewithoutstatus, the instruction is incoherent; if statusis later renamed, the cross-reference silently drifts. The four label names are already inlined on the same line so the fix is cheap: drop the$statussigil and sayusing these four labels: Done, In progress, Blocked / needs input, Next`.

[justin808]

Address-review summary

Scan scope: unresolved Claude review threads observed on 2026-06-30 after head 12116f9.

Mattered

• Continue scope: fixed in c805ad7 by limiting $continue to the single selected next step and stopping after that step completes.
• Non-runnable verification: fixed in c805ad7 by allowing completion confirmation text when no command or test exists.
• Done bucket: fixed in c805ad7 by separating completed work from verified work and allowing done/awaiting-verification status.
• Closing summary labels: fixed in c805ad7 by inlining the four labels and requiring "nothing blocked" when applicable, without relying on a live $status install.

Optional

• None.

Skipped

• None.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

[claude]

Review

This PR adds two portable session-discipline skills — continue (structured resume with checkpoint) and status (tight progress report without new work) — plus two README rows. Both skills are correctly portable: no consumer-repo commands, labels, branches, or paths are hardcoded, and the frontmatter passes bin/validate. status/SKILL.md looks clean.

Three issues on skills/continue/SKILL.md, severity-ordered:

---

1. Missing "Read AGENTS.md first" prerequisite step (medium) — line 27

Every other action-taking skill in this repo (spec, verify) opens with an explicit numbered step to read AGENTS.md before doing any work. continue surfaces it only as a late bullet-point reminder. In a cross-session handoff or a fresh clone, the agent has no instruction to consult AGENTS.md first, so it may execute steps 1–4 and invoke operations the consumer repo prohibits (push, CI trigger, deployment).

Fix: prepend a step 0: "Read AGENTS.md first — canonical source for repo-specific commands, branch rules, review gates, and safety boundaries."

---

2. Empty-state detection too narrow; inference fallback lacks a confidence guard (low) — lines 13–16

The "no task in progress" check covers only three git/conversation-visible signals. Prior work in an open PR, a linked issue, or a planning doc is invisible to it. The second branch ("state your best inference and proceed") is uncapped — a single cryptic WIP commit satisfies "prior work exists" and the agent proceeds confidently in possibly the wrong direction.

Fix: extend the first branch to mention checking open PRs/issues, and add a low-confidence qualifier to the second branch so the agent flags uncertain inferences before acting.

---

3. Closing status format duplicates status/SKILL.md labels — will drift on update (low) — lines 29–31

The Done / In progress / Blocked / Next labels and the "nothing blocked" sentinel are redefined inline rather than delegated to $status. If status/SKILL.md gains a new label or renames one, continue's embedded format silently diverges.

Fix: replace the inline format definition with "run $status inline (or use its format verbatim)" so the two skills stay in sync.

---

Overall the skills are well-scoped and portable — the issues above are all confined to continue/SKILL.md and are straightforward to address.

🤖 Generated with Claude Code

[justin808]

Address-review summary

Scan scope: unresolved review threads observed on 2026-06-30 after head c805ad7.

Mattered

• Repo-rule prerequisite: fixed in d67a76b by making $continue read AGENTS.md before acting.
• Empty-state and inference guard: fixed in d67a76b by checking PRs/issues/planning docs and requiring confirmation before acting on low-confidence inference.
• Closing status format: fixed in d67a76b by referencing the companion status format and keeping the inline labels aligned with status/SKILL.md for independent installs.

Optional

• None.

Skipped

• None.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

[claude]

Review: skills: add portable continue and status skills

This PR adds two well-scoped, portable skills — `/continue` and `/status` — that complement the existing handoff guidance. The skills are concise, reference `AGENTS.md` seam keys correctly, and contain no consumer-repo hardcoding. Two issues in the pairing between the two files are worth addressing before merge.

---

Finding 1 — CONFIRMED · `skills/continue/SKILL.md` lines 32–33

The closing bullet instructs the agent to end with a "short status line using the companion status format," but the `Done` field in `status/SKILL.md` carries an extra requirement not mentioned here: note whether the item was verified, cite the check result, or mark it as awaiting verification. Since `continue` only names the four section headings (`Done / In progress / Blocked / Next`) without repeating the verification sub-rule, an agent following `/continue` will silently produce a `Done` entry that omits the verification status that `/status` mandates — the very alignment the file promises.

Fix: add one phrase to the Done part of the closing instruction, e.g. "for Done items, note whether verified or awaiting verification."

---

Finding 2 — PLAUSIBLE · `skills/continue/SKILL.md` line 32

The instruction says "End with a short status line" (singular). A model reading this literally may compress the entire Done/In-progress/Blocked/Next report into one inline sentence rather than the four-bullet block `status/SKILL.md` defines. The follow-on phrase "using the companion status format" softens this, but the tension between "line" and a four-bullet block is real and a source of inconsistency between `/continue` outputs and `/status` outputs.

Fix: change "status line" → "status block" or "status summary" to match the multi-bullet structure.

🤖 Generated with Claude Code

[justin808]

Address-review summary

Scan scope: unresolved review threads observed on 2026-06-30 after head d67a76b.

Mattered

• Status format alignment: fixed in 66b2781 by making the $continue closing status a status block and including Done verification / awaiting-verification detail.

Optional

• None.

Skipped

• None.

Next default scan starts after this comment. Say check all reviews to rescan the full PR.

[claude]

Review: skills/continue and skills/status

Both skills are well-scoped and portable — no consumer-repo commands, labels, or hardcoded paths were found. The README table rows are alphabetically ordered correctly. Three issues worth addressing before merge:

1. Maintainer note embedded in AI-facing instructions (most important)
continue/SKILL.md line 34 contains "Keep this block aligned with status/SKILL.md when editing either skill" — a note addressed to human editors — inside the bullet block that the AI reads as operator instructions. An AI executing /continue will encounter this as a directive and may attempt to open or verify status/SKILL.md as a side effect. Move this note out of the instruction block (e.g., into a comment or the PR description), or eliminate it by fixing the underlying coupling (see #2).

2. Status format duplication creates maintenance coupling
continue/SKILL.md lines 32-34 fully re-enumerate the Done / In progress / Blocked / Next format that is already defined in status/SKILL.md. The "keep aligned" note is the only guard against divergence. A cleaner design: replace the inline re-enumeration with End with a \$status` report.` — this delegates to the canonical definition and eliminates the coupling entirely.

3. Inconsistent length cap for the same output
status/SKILL.md line 19 says "Keep it to roughly ten lines", but continue/SKILL.md line 32 calls it "a short status block" with no line count. The same artifact has two different size constraints depending on which skill triggered it. If the inline enumeration is replaced by $status delegation (per #2), this inconsistency disappears automatically; otherwise, align the phrasing.

Bonus (not blocking): continue/SKILL.md line 34's sync note is one-directional — it tells editors to keep continue aligned with status, but status/SKILL.md has no reciprocal instruction. A contributor who only opens the shorter file gets no signal that continue depends on it.

[claude]

Review: skills: add portable continue and status session-discipline skills

This PR adds two well-scoped, portable skills — continue and status — that bring explicit checkpoint discipline to session resumption and status reporting. The content is concise, all AGENTS.md portability rules are respected (no hardcoded consumer commands, labels, branches, or paths), the README table insertions are correctly alphabetised, and the YAML frontmatter follows the repo's established conventions.

Two PLAUSIBLE concerns are noted via inline comments below:

1. $status cross-skill dependency (continue/SKILL.md:32) — the closing bullet invokes $status without declaring the dependency, which silently degrades when status is not installed.
2. Ten-line cap tension (status/SKILL.md:19) — four mandatory sections routinely produce 12–16 lines, creating a soft contradiction with the "roughly ten lines" guidance.

Neither is a blocker, but the first is worth a deliberate decision before merge.

[claude]

Code Review

This PR adds two portable session-discipline skills — continue and status — and registers them in the README table. Both skills are portable (no consumer-repo commands, labels, branches, or paths), consistent with AGENTS.md editing rules, and the alphabetical insertion positions in the README are correct.

Two findings:

1. skills/continue/SKILL.md:32 — ambiguous skill-presence check (inline comment).
   "When that companion skill is installed" names no detection mechanism. An agent has no specified way to determine if status is available, so behavior will vary across harnesses. Consider always using the inline four sections or always delegating to $status unconditionally.

2. README.md:125 — Blocked / needs input truncated to blocked (inline comment with suggestion).
   The "/ needs input" qualifier distinguishes passive waiting from items that need a human decision or credential. The README entry drops it, which undersells the section's call-to-action intent.

No portability violations, no hardcoded consumer-repo specifics, and no binary or script files to audit.

🤖 Generated with Claude Code