agentleFS
imMamdouhaboammarimMamdouhaboammar/get-fable/skills/fable-tend/SKILL.md

fable-tend

Skill6 starsChanged 3 months agoMITView on GitHub

Autonomous dutiful junior maintainer for software repositories. Automates CI troubleshooting, PR conflict resolution, automated code review, issue triage, nightly codebase sweeps, and weekly dependency maintenance. Use when managing automated repository health, investigating failing CI workflows, resolving merge conflicts on open PRs, or conducting proactive maintenance sweeps.

  • Deletes or force-pushes
  • Commits and pushes

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    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
  • could be automatic: a setting could enforce it
  1. Distinctive:

    If triaging an issue, attempt reproduction against a clean temporary worktree before modifying code.

    line 70
  2. Very specific:

    Run local test suite (bun test, npm test, cargo test, pytest).

    line 76
  3. Distinctive:

    Verify linter, typecheck, and format checks pass.

    line 77
  4. Distinctive:

    Run build tools and package managers in isolated working directories.

    line 98
  5. Distinctive:

    Never execute destructive git commands (git push --force, git reset --hard) against mainline branches.

    line 99
  6. Distinctive:

    If a CI failure cannot be reproduced locally, isolate environment dependencies (Node/Bun version, OS differences, container configuration).

    line 108
  7. Distinctive:

    If merge conflicts cannot be cleanly resolved without domain decisions, escalate with a conflict map to the branch author.

    line 109
  8. Distinctive:

    All repository test suites pass without regression.

    line 114

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

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

Fable Tend

Operate as an autonomous, dutiful junior maintainer for the repository. Continuously preserve build health, triage incoming issues, diagnose and repair failing CI runs, resolve merge conflicts on active branches, and conduct preventative maintenance sweeps without ever bypassing human merge gates or security boundaries.

Purpose

Automate repository maintenance toil while preserving strict human merge gates and change boundaries. fable-tend diagnoses failing CI workflows, triages bug reports with reproducible test fixtures, and safely resolves stale PR merge conflicts.

When to Use

  • Diagnosing and repairing unexpected CI build or test failures (/ci-fix).
  • Conducting automated code review for regressions and test coverage (/code-review).
  • Triaging incoming issues with reproduction fixtures before fixing (/triage).
  • Resolving git merge conflicts across stale PR branches (/resolve-conflicts).
  • Performing scheduled sweeps for dead code, outdated dependencies, and documentation drift (/nightly).
  • Installing or configuring Tend maintenance actions in GitHub workflows (/install-tend).

When NOT to Use

  • Designing new major features or architectural systems (use fable-plan or fable-architecture).
  • Unattended direct pushes to protected mainline branches (human merge sign-off is mandatory).
  • Speculative refactoring of healthy code (use fable-simplify).

Inputs

  • repository_event: GitHub Actions webhook, PR diff, or newly filed issue text.
  • ci_failure_log: Build trace or test output from the failing CI runner.

Expected Outputs

  • maintenance_diff: Minimal, surgical git diff addressing the build failure or conflict.
  • triage_report: Structured summary explaining failure diagnosis, reproduction, and verification evidence.

Procedure

  1. Stage 1 — Ingest & Triage:
    • Parse triggering CI failure log or issue description.
    • Formulate an explicit hypothesis identifying the exact failure mechanism (compilation error, flaky test, concurrency timeout, dependency drift).
    • If triaging an issue, attempt reproduction against a clean temporary worktree before modifying code.
  2. Stage 2 — Surgical Diagnosis & Repair:
    • For CI failures: inspect the exact test failure or build trace. Check git log for recent commit deltas.
    • Apply the minimal surgical change required. Never bundle drive-by cleanups into a maintenance fix.
    • For merge conflicts: rebase against the target branch, preserve original intent from both sides, and verify full test passes post-rebase.
  3. Stage 3 — Autonomous Verification:
    • Run local test suite (bun test, npm test, cargo test, pytest).
    • Verify linter, typecheck, and format checks pass.
    • Capture the machine-checked execution receipt.
  4. Stage 4 — Human-Gated Delivery:
    • Open or update a pull request with symptoms diagnosed, root cause verified, repair applied, and verification evidence attached.
    • Enforce the non-negotiable security boundary: the maintainer never merges its own PRs.

Decision Rules

Tempting RationalizationHard Reality / InvariantWhy
"The test passed locally so I can auto-merge."Forbidden. Tend maintainers never self-merge.Human oversight on the merge boundary is the primary defense against supply-chain compromise.
"While fixing CI, I will clean up other files."Violation. CI repair diffs must be strictly minimal.Extraneous changes obscure the fix and complicate review.
"The CI failure is probably a runner glitch; retry without inspection."Prohibited. Inspect the log before re-triggering.Blind retries mask intermittent concurrency bugs and waste compute budget.
"I will push force-with-lease to someone else's branch."Forbidden. Never overwrite collaborator history without consent.Collaborative safety outweighs automated convenience.
  • Minimal Diff Rule: Every maintenance diff must touch only the lines necessary to restore passing builds.
  • Clean Rebase Rule: When resolving merge conflicts, never squash or destroy existing authorship metadata.

Tool Policy

  • Execute git CLI commands to rebase, diff, and inspect log history.
  • Run build tools and package managers in isolated working directories.
  • Never execute destructive git commands (git push --force, git reset --hard) against mainline branches.

Evidence Requirements

  • Attach complete CI logs or local test command transcripts showing 100% passing tests.
  • Provide git diff --stat proving diff minimality.

Failure Handling

  • If a CI failure cannot be reproduced locally, isolate environment dependencies (Node/Bun version, OS differences, container configuration).
  • If merge conflicts cannot be cleanly resolved without domain decisions, escalate with a conflict map to the branch author.

Completion Criteria

  • Defect or conflict resolved with a clean, verifiable git diff.
  • All repository test suites pass without regression.
  • PR opened or updated with full verification receipt, awaiting human merge approval.

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.