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.
In this repository42 other files it gives its agents.
- ansible-hardeningSkill
- cavetechSkill
- ci-cdSkill
- claude-to-cursorSkill
- code-consistencySkill
- code-qualitySkill
- config-auditorSkill
- container-sandboxSkill
- cpa-tax-specialistSkill
- database-designSkill
- definition-of-doneSkill
- differential-reviewSkill
- exact-head-reviewSkill
- fast-ciSkill
- grill-meSkill
- inbound-syncSkill
- infosec-architectSkill
- insecure-defaultsSkill
- lonely-sysadminSkill
- mcp-createSkill
- mcp-hardeningSkill
- model-evaluationSkill
- modern-pythonSkill
- ms-office-suiteSkill
- mutation-checkSkill
- plan-to-execution-handoffSkill
- prd-to-planSkill
- property-based-testingSkill
- pr-truth-triageSkill
- repo-hardening-workflowSkill
- resume-writerSkill
- skill-updaterSkill
- software-developerSkill
- software-development-lifecycleSkill
- solutions-architectSkill
- supply-chain-risk-auditorSkill
- systematic-debuggingSkill
- tddSkill
- token-miserSkill
- triage-issueSkill
- verification-before-completionSkill
- write-a-prdSkill
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
- Distinctive: line 17
Run bounded prework: independent review, deploy check-mode, readiness probes, timing analysis, docs, blocker repair on isolated branches.
- Distinctive: line 22
Keep expensive work bounded: use the host's existing admission controls or disposable CI capacity, and protect interactive and inference …
- Very specific: line 33
Local qualification: run the full suite at the exact head AND at its merge base on an idle host with the same environment.
- Distinctive: line 42
CI diagnosis: read the failing job's own classification (new vs baseline failures).
- Distinctive: line 44
Anticipate the next failure: look one stage downstream (size limits, timeouts, budgets) and record it before it fires.
≈ “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.
Files
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
- 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.
- Run bounded prework: independent review, deploy check-mode, readiness probes, timing analysis, docs, blocker repair on isolated branches.
- Prepare the next command set now: change identity, worktree, credential presence (never values), runner capacity, IaC inputs, rollback, evidence locations.
- Fix deterministic blockers in their owning source, with the failure, commit and proof.
- Keep expensive work bounded: use the host's existing admission controls or disposable CI capacity, and protect interactive and inference headroom.
- Reconcile live changes back to IaC in the same cycle; temporary changes get an owner, expiry and source counterpart.
- 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.
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
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.

