agentleFS
possibilitiespossibilities/agentguidance/skills/maintain/SKILL.md

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

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.
  • AWSSkill

    ship

    Finalize dev work on an issue branch — update docs, push, and open a PR.

    Also in 3 projects that use this

  • MicrosoftSkill

    release

    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

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
  1. Distinctive:

    Run one maintenance cycle of the fork declared by that workshop.

    line 14
  2. Distinctive:

    Verify the consumer, reconcile the published branch model, and update the scratchpad.

    line 53
  3. Distinctive:

    Use native harness delegation only as allowed by the active role.

    line 67
  4. Distinctive:

    If a rebase, review, gate, publication, or consumer check fails, report the exact failure and the state that remains in place.

    line 69
  5. Distinctive:

    Always give a self-contained report: outcome, upstream reviewed, changed fork accommodations, stance and carry impact, and evidence or …

    line 76
  6. Distinctive:

    Use the report contract, including explicit no-change results.

    line 78

“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.

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

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

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.