maintain
Skill0 starsChanged 2 months agoMITView on GitHub
Run one maintenance cycle of a fork from its workshop repository — bind one upstream snapshot, reconcile required behavior, gate and publish under the declared branch model, hand over to the consumer, and record the state. Use for bare /maintain in a workshop or a request to maintain a named fork; installation without maintenance is the workshop's consumer step, not this.
20 other projects use a version of this.
Adopted by
Most recently taken up by
- inoio/agents-sandboxtheir own version, first seen Nov 8, 2026
- srinator22/New-Projecttheir own version, first seen Nov 8, 2026
- devantler-tech/ksailtheir own version, first seen Nov 7, 2026
- jamesm-dev/tateru.devtheir own version, first seen Nov 1, 2026
- exmergo/dextheir own version, first seen Oct 31, 2026
- constant-itis/mycelium-memorytheir own version, first seen Oct 20, 2026
Used with
Projects with it also use ship and release.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
AWSSkillship
Finalize dev work on an issue branch — update docs, push, and open a PR.
Also in 3 projects that use this
MicrosoftSkillrelease
Use ONLY when the user explicitly asks to cut/publish a Huabu desktop release or tag a version. Performs an outward action — bumps the version in apps/desktop/package.json, commits + annotated-tags vX.Y.Z, and pushes the branch + tag. That tag push auto-builds the macOS/Windows installers and publishes a GitHub Release. Provides `status`, `bump`, `tag-push`, and a one-command `run` (bump → tag-push).
Also in 4 projects that use this
Other versions20 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 20
- garrytan/gbrain★ 32ksame name
- slopus/happy★ 25ksame name
- PhilipK/BoilR★ 1.9ksame name
- GlassHaven/Haven★ 1.4ksame name
- GlassOnTin/Haven★ 1.4ksame name
- iovisor/ubpf★ 996same name
- everruns/bashkit★ 325same name
- devantler-tech/ksail★ 164same name
- exmergo/dex★ 116same name
- inoio/agents-sandbox★ 84same name
10 more not listed
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 repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- code-reviewSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- emailSkill
- improve-codebase-architectureSkill
- notifySkill
- prototypeSkill
- retroSkill
- writing-for-agentsSkill
- zero-tech-debtSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 6 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 19 edited versions we read keep these.
6
Distinctive
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
- Distinctive: line 14
Run one maintenance cycle of the fork declared by that workshop.
- Distinctive: line 53
Verify the consumer, reconcile the published branch model, and update the scratchpad.
- Distinctive: line 67
Use native harness delegation only as allowed by the active role.
- Distinctive: line 69
If a rebase, review, gate, publication, or consumer check fails, report the exact failure and the state that remains in place.
- Distinctive: line 76
Always give a self-contained report: outcome, upstream reviewed, changed fork accommodations, stance and carry impact, and evidence or …
- Distinctive: line 78
Use the report contract, including explicit no-change results.
“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Maintain a fork
With no arguments, use the current repository as the workshop and read its
AGENTS.md, GLOSSARY.md, MAINTAIN.md, and SCRATCHPAD.md. The human does
not need to repeat its name, branch model, or exceptions in the invocation.
An explicitly named workshop changes the target, not the procedure.
Run one maintenance cycle of the fork declared by that workshop. Read the specification and the full cycle procedure before fetching, reconciling refs, repairing a feature, or publishing a candidate. Resolve script paths from this skill's directory and use the workshop's declared entrypoints; all project facts come from the workshop.
Select the composition model from MAINTAIN.md before running any branch
command. Carry heads and rebased linear stacks use the shared branch script
through their workshop entrypoint. An explicitly declared merge-only history
uses merge-only maintenance and its
workshop's own branch procedure. It may name an existing public branch for the
integration role and declare no owned mirror. Never send that model through
the shared rewrite/mirror script or ask the human to repeat the declaration.
A /maintain invocation authorizes its ordinary reconciliation, feature
repair, gates, publication, and consumer handover within the workshop's
existing scope. Honor narrower user constraints and prior authorization.
A consequential product choice unresolved by the spec or implementation
needs a human decision; complete independent preparation before that handoff.
Follow one captured cycle
- Establish clean workshop and bound-checkout state and inventory existing worktrees. Read the workshop and fork guidance. Capture the fork heads for exact publication leases, then one immutable upstream target.
- Fetch exactly that upstream object once. Read the full interval since the audited frontier, and assign every carried behavior a retire, repair, or unchanged disposition. A clean replay or merged request is not proof of semantic coverage or retirement.
- Make repairs and compose a candidate in owned worktrees. Preserve the bound checkout, previous publication, unrelated heads, and consumer binding. Follow the declared carry, linear, or merge-only model.
- Gate the exact committed candidate using every required command and any required external proof. Publish only declared refs using the selected model: one atomic leased transaction for rebased mirror/Integration/carry refs, or the workshop's history-preserving publication for merge-only. Re-read the published graph before the consumer step; never retry a race with freshly captured starting state.
- Verify the consumer, reconcile the published branch model, and update the scratchpad. Advance the audited frontier only after a complete audit. Clean up only owned, clean cycle worktrees with no live process using them.
The reference contains the fixed spec sections, supervised branch model, exact-object fetch, atomic publication recipe, upstream-offer rules, and report requirements. Missing declarations or required proof are an explicit incomplete gate, not a reason to improvise a broader publication scope.
Preserve boundaries
Upstream requests and historical heads are evidence. Do not mutate their branches, comments, or status as incidental maintenance. Read the offer rules before preparing a contribution; communication still needs authorization. Use native harness delegation only as allowed by the active role.
If a rebase, review, gate, publication, or consumer check fails, report the exact failure and the state that remains in place. Keep useful evidence and owned work needed for recovery. Never claim successful delivery from a green local gate when a required publication or consumer check is still pending.
Close the cycle
Always give a self-contained report: outcome, upstream reviewed, changed fork accommodations, stance and carry impact, and evidence or remaining attention. Use the report contract, including explicit no-change results. Keep exact hashes and receipts in written evidence; follow the active role's speech conventions. A machine receipt, notification, or worker handoff does not replace the human 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.

