agentleFS
scoobydont-666scoobydont-666/shared-claude-skills/skills/stay-ready/SKILL.md

stay-ready

Skill1 starsChanged 33 days agoMITView on GitHub

Keep work moving while a CI, review, merge or deploy gate is pending. Prepare the next verified step, unblock later dependencies and finish peripheral work, without moving frozen heads or claiming green before evidence exists.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run bounded prework: independent review, deploy check-mode, readiness probes, timing analysis, docs, blocker repair on isolated branches.

    line 17
  2. Distinctive:

    Keep expensive work bounded: use the host's existing admission controls or disposable CI capacity, and protect interactive and inference …

    line 22
  3. Very specific:

    Local qualification: run the full suite at the exact head AND at its merge base on an idle host with the same environment.

    line 33
  4. Distinctive:

    CI diagnosis: read the failing job's own classification (new vs baseline failures).

    line 42
  5. Distinctive:

    Anticipate the next failure: look one stage downstream (size limits, timeouts, budgets) and record it before it fires.

    line 44

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Stay ready

Do prework while a gate is pending: unblock a likely roadblock or finish peripheral work. When the gate opens, be ready to move.

Rules while a gate is pending

  1. Preserve the exact candidate and its evidence. Never push to a frozen head, rerun a failed check without a diagnosed cause, or manufacture a green result.
  2. Run bounded prework: independent review, deploy check-mode, readiness probes, timing analysis, docs, blocker repair on isolated branches.
  3. Prepare the next command set now: change identity, worktree, credential presence (never values), runner capacity, IaC inputs, rollback, evidence locations.
  4. Fix deterministic blockers in their owning source, with the failure, commit and proof.
  5. Keep expensive work bounded: use the host's existing admission controls or disposable CI capacity, and protect interactive and inference headroom.
  6. Reconcile live changes back to IaC in the same cycle; temporary changes get an owner, expiry and source counterpart.
  7. At every gate transition re-derive the current head; stale reviews, plans and commands are invalid until re-stamped.

Prework catalog

  • Freeze the candidate: lock the PR head branch (lock_branch: true, enforce admins, no force-push). Findings go on the finder's own branch from the frozen head; the author makes ONE batched update (unlock, push, re-lock); reviewers re-stamp only the delta.
  • Local qualification: run the full suite at the exact head AND at its merge base on an idle host with the same environment; report only head-only failures (comm -23 head.txt base.txt). Environment gaps (missing tool on PATH) are not product.
  • Reviewer eligibility: list authors with git log --format=%an main..HEAD; authors and co-authors cannot be legs. Line up two clean independent reviewers before the head is final.
  • Post-merge runbook: exact check/diff command, expected diff, apply, readback, proof, rollback, written before merge.
  • Supersession: for a PR the candidate replaces, compute file containment (blob equality per path) and have the close comment ready, missing only the merge sha.
  • CI diagnosis: read the failing job's own classification (new vs baseline failures); compare against the same tests at the merge base before blaming the candidate.
  • Anticipate the next failure: look one stage downstream (size limits, timeouts, budgets) and record it before it fires.

Status report

Name the active gate, each live prework lane, the blocker it attacks, and the evidence ready for the next transition. "Waiting on CI" alone is an incomplete report.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.