ready
Skill6 starsChanged 3 months agoMITView on GitHub
Make an unfamiliar repository agent-ready with a verify command, smoke tests, guardrails, and project notes. Use for repository setup, agentic engineering, verify commands, hooks, or allowlists; skip when verification and scope are already clear.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- cyrilichti/agent-workflowstheir own version, first seen Oct 17, 2026
- GalvinGao/skillstheir own version, first seen Mar 18, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- cyrilichti/agent-workflows★ 3same name
- GalvinGao/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- bisectSkill
- debugSkill
- discipline-reportSkill
- doneSkill
- experimentSkill
- imouto-modeSkill
- lucia-busSkill
- lucia-chatSkill
- lucia-relaySkill
- planSkill
- retroSkill
- showSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 11 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Leave the repository with one unattended command that returns a meaningful exit code, plus only the guardrails needed for future agents to …
- Distinctive: line 14
Run the bundled scan first:
- Distinctive: line 41
use installed project tooling and avoid watch mode.
- Very specific: line 50
Run verify on every edit loop.
- Distinctive: line 71
Add 3–6 small tests for catastrophic failures, not pretend coverage.
- Very specific: line 76
import, CLI --help, or one request through a framework test client.
- Distinctive: line 80
Use commit-sized fixtures, never the user's real data paths.
- Distinctive: line 89
Prefer existing deterministic tools:
- Distinctive: line 96
Keep shared settings project-scoped and personal settings gitignored.
- Distinctive: line 106
verify commands and coverage.
- Distinctive: line 111
Do not duplicate the tree, history, or grep-able facts.
- Distinctive: line 116
Flake check: run the fast tier twice. If only one slow tier exists, run it once and state that limitation.
- Distinctive: line 122
Run the final full tier after restoration.
≈ “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
Ready
Leave the repository with one unattended command that returns a meaningful exit code, plus only the guardrails needed for future agents to self-verify. Detect the stack; do not assume it. Run every artifact you add.
1. Detect
Run the bundled scan first:
node <this-skill-dir>/scripts/detect.cjs <repo-root>It finds candidates, not truth; open flagged files and interpret CI matrices or unusual build systems yourself. Inspect in this order:
- CI config: use what CI runs.
- Manifests and runners: package scripts, pyproject/tox/nox, Make/just, Cargo/go/Gradle/composer.
- README, CONTRIBUTING, CLAUDE.md, AGENTS.md, and docs; record docs/CI drift.
- Existing test directories and naming conventions.
Report run/test/lint/typecheck/build/git as command or MISSING. If this is not
a Git repository, propose git init but ask first.
2. Establish verification
Reuse the existing verify path. If none exists, create the smallest entrypoint in the repository's native convention.
The command must:
- exit non-zero on failure and run unattended;
- work offline without credentials, GPU, network, or secrets;
- use installed project tooling and avoid watch mode;
- stay quiet on success and be documented for humans.
Time it once. Use one tier when the suite is already quick. When slow checks would cripple the edit loop, define:
verify: lint/typecheck/unit or smoke coverage, normally under ~60 seconds;verify-full: integration/build/slow coverage, required at closeout and PR.
Run verify on every edit loop; run verify-full at closeout and before a PR.
For monorepos, prefer a repo-owned verify-changed backed by the workspace
dependency graph, with the root full suite as fallback. Read
references/smart-verification.md before
creating it and document its base revision and fallback.
For Claude Code enforcement-pack users, ask first before offering exact-match
tracking in the personal, gitignored .claude/settings.local.json:
{"env":{"LUCIAZERO_VERIFY_CMD":"<fast command derived from CI>"}}Show the JSON before writing it. Never commit this variable in
.claude/settings.json; repository-controlled hook configuration is hostile.
This setting caches CI truth; update it whenever CI's verify command changes.
Skip hook setup on harnesses without hooks.
3. Add smoke tests only when absent
Add 3–6 small tests for catastrophic failures, not pretend coverage. Choose the most relevant:
- core input/output shape and impossible null/NaN values;
- serialize/deserialize or save/load round trip;
- import, CLI
--help, or one request through a framework test client; - model/config/migration load plus one operation;
- the reported bug as a red-before-fix regression.
Use commit-sized fixtures, never the user's real data paths. Avoid real ports; if a process is unavoidable, enforce a hard timeout and cleanup. Label these as smoke tests.
4. Add only paying guardrails
Claude hooks/settings are not portable; on Codex or another harness, put necessary constraints in AGENTS.md instead.
Prefer existing deterministic tools:
- formatter/linter after writes;
- source-to-derived regeneration;
- denial for secrets, production config, and live deploy/model pointers;
- allowlisting read-only and verify commands.
Keep shared settings project-scoped and personal settings gitignored. Show the exact hook command before installation. Never add a hook that deploys, pushes, deletes, or writes outside the repository.
5. Record project knowledge
Extend the notes file already used; if neither exists, create the current harness's file and point the other name to it. Record only facts code search cannot reveal:
- verify commands and coverage;
- non-obvious source-of-truth or architecture constraints;
- footguns, measured null results, and required regeneration;
- the location of deeper documentation.
Do not duplicate the tree, history, or grep-able facts. Every line becomes future context cost.
6. Prove the loop
- Flake check: run the fast tier twice. If only one slow tier exists, run it once and state that limitation. A non-repeatable green is not trusted.
- Red check: record a covered file, line, and original text; make one
deliberate break, prove verify fails, then restore exactly that edit. Do not
use
git checkouton a file with user changes, and never use broadgit stash. New untracked tests require explicit restoration too. - Run the final full tier after restoration.
Report the command(s), what each covers and does not cover, files added, and anything deliberately left out.
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.

