oss-loop
Skill2 starsChanged 11 days agoMITView on GitHub
Use when carrying an OSS tool from idea/spec to a shipped, published release through one closed loop where the agent does everything reversible and a human touches only the irreversible gates (publish, merge, tag, DNS, secrets). Triggers, /oss-loop, "ship the next version of <tool>", "take <tool> to vN", "run the OSS build-ship loop". Composes your prompt/research/TDD/launch skills; it does not reimplement them. NOT for a one-off code change (that is a TDD/implement loop) or the public product page alone (that is your launch skill).
In this repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- apply-review-findingsSkill
- author-workflow-fanoutSkill
- chain-launcherSkill
- delegateSkill
- design-consultationSkill
- design-fail-closed-gateSkill
- document-releaseSkill
- gistSkill
- goal-promptSkill
- grokbotSkill
- incident-as-codeSkill
- investigateSkill
- learn-captureSkill
- office-hoursSkill
- orion-deep-researchSkill
- pre-compactSkill
- pre-prSkill
- prove-control-bindsSkill
- prove-deploy-is-liveSkill
- readonlySkill
- reassert-guards-on-rewriteSkill
- reprobe-stale-premiseSkill
- scope-guardSkill
- shipSkill
- tdd-loopSkill
- tools-routerSkill
- triage-fanout-verdictsSkill
- xSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 44
If a research pass returns "all refuted / inconclusive", check for an abstention (a verifier that crashed / rate-limited and returned no …
- Distinctive: line 68
Do CODE work in a fresh worktree/branch off the repo's detected default branch (never assume main, never the canonical checkout).
- Distinctive: line 72
Never echo secrets; pass a secret scan (e.g.
- Distinctive: line 90
Does NOT cross any irreversible gate autonomously.
- Distinctive: line 91
Does NOT reimplement the prompt / research / TDD / launch steps, it sequences them.
≈ “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
OSS Build-Ship Loop (operator-gates-only)
Overview
Carry an OSS tool from idea/spec to a shipped, published release through one closed loop where the agent does everything reversible and a human touches only the irreversible gates:
build the prompt → research → human approves the plan → TDD the change to a CI-green PR → human merges/tags → launch the public surface → verify live → capture the lesson.
This skill is the orchestrator + gate boundary: it COMPOSES whatever skills your
harness has for each step; it does not reimplement them. In this library those steps
map to goal-prompt (build the prompt), tdd-loop (the hardened implement loop), and
learn-capture (close the loop); the launch step is whatever publishes your
microsite / registry page. Swap in your own equivalents, the gates bind to artifacts
either way.
When to use
- A new version of an already-shipped OSS tool (the common case → a parameter bump + a recon delta, not a harness rebuild).
- A new tool, discover → build → ship.
- Triggers:
/oss-loop, "ship the next version", "run the OSS build-ship loop".
When NOT to use:
- A single code change with no release → a TDD/implement loop (
tdd-loop). - Just the public product page → your launch/microsite skill.
- An undecided idea ("should I build this?") → brainstorming, not this.
The loop (compose each step; do not reinvent)
- RECALL + RECON: pull prior-arc artifacts (the prompt set, the approved plan, where the repo/registry homes are); for a new version, run the recon DELTA against the last release. Refuse if preconditions fail.
- PROMPT: build the research(+implement) prompt: recon-grounded, with a
transcript-checkable terminal condition (
goal-prompt). Never fire it from here, the approval gate is a separate human fire. - RESEARCH: the human fires the research/loop run → a reviewed plan (a "MAP"). If a research pass returns "all refuted / inconclusive", check for an abstention (a verifier that crashed / rate-limited and returned no votes) before trusting it, a crashed verifier is not a refutation.
- GATE (human): the human approves/edits the plan's DO set.
- IMPLEMENT: drive the change to a CI-green PR through a self-correcting
RED→GREEN loop with a BLOCKING adversarial + security review (
tdd-loop). The agent OPENS the PR; it does not tag or merge. - OPERATOR GATES (human): merge the human-merged PR first, then tag the merged commit on the default branch (order matters: a tag-triggered release must build merged code, never a pre-merge branch head), then change DNS. The agent is incapable of these by construction.
- LAUNCH: publish the public surface (microsite / product page), only if it changed.
- VERIFY LIVE: the installer's source of truth, live: the package index shows vN
as latest (
pip index versions <pkg>or your ecosystem's equivalent), the image registry tag pulls anonymously, the microsite returns 200 over TLS. "merged" is not "published". - CAPTURE: route the lessons to durable homes (
learn-capture).
Rails (operator-gates-only: non-negotiable)
- The agent MUST STOP at every irreversible gate: publish to a package/image registry, merge a human-merged PR, push a tag, change DNS, arm a scheduled job, write a secret. Make this fail-closed by construction (the agent literally cannot perform them), never a prose "please don't".
- Do CODE work in a fresh worktree/branch off the repo's detected default branch
(never assume
main, never the canonical checkout); never force-push. - Scaffolding a microsite from a template: EXCLUDE the deploy-provider dir (e.g.
.vercel/), a leaked one can clobber the template's production project. - Never echo secrets; pass a secret scan (e.g. gitleaks) before every commit. Severity-grade findings BLOCKING / WARNING / INFO.
Red flags: STOP
| Thought | Reality |
| "I'll just merge/tag/publish to finish the loop." | Those are the human's gates. The agent STOPS and hands them over. |
| "I'll rebuild the harness for the new version." | A new version is a parameter bump + a recon delta, not a rebuild. |
| "The research pass said all refuted, so the research failed." | Check for an abstention (a crashed/rate-limited verifier returning no votes) first, silence is not a refutation. |
| "It merged, so it's shipped." | Verify the installer's source of truth (the package/image registry), live. |
Boundary (defer to the consumer's repo)
This skill owns the sequence and the gate boundary, not your deploy mechanics. Branch naming, the secret manager, the package/image registries, DNS, and the CI specifics are your repo's doctrine, this skill only insists the agent stops at the irreversible gates and verifies the live source of truth before claiming "shipped".
What it deliberately does NOT do
- Does NOT cross any irreversible gate autonomously.
- Does NOT reimplement the prompt / research / TDD / launch steps, it sequences them.
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.