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
In this repository55 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .codex/AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- skills/fable-tend/AGENTS.mdAGENTS.md
- skills/fable-wise/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- skills/fable-tend/CLAUDE.mdCLAUDE.md
- skills/fable-tend/site/CLAUDE.mdCLAUDE.md
- skills/fable-wise/CLAUDE.mdCLAUDE.md
- public/llms.txtllms.txt
- get-fableSkill
- typesafe-aiSkill
- get-fableSkill
- get-fableSkill
- fable-architectureSkill
- fable-artifactSkill
- fable-configSkill
- fable-context-thriftSkill
- fable-councilSkill
- fable-coworkSkill
- fable-datavizSkill
- fable-delegateSkill
- fable-discoverSkill
- fable-domainSkill
- fable-ecoSkill
- fable-evalSkill
- fable-executeSkill
- fable-finish-your-turnSkill
- fable-handoffSkill
- fable-healSkill
- fable-judgeSkill
- fable-learningSkill
- fable-loopSkill
- fable-memorySkill
- fable-methodSkill
- fable-native-codeSkill
- fable-outcome-firstSkill
- fable-planSkill
- fable-prove-itSkill
- fable-recoverSkill
- fable-redteamSkill
- fable-releaseSkill
- fable-researchSkill
- fable-reviewSkill
- fable-runSkill
- fable-scope-disciplineSkill
- fable-securitySkill
- fable-simplifySkill
- fable-simulatorSkill
- fable-skill-creatorSkill
- fable-sparkSkill
- fable-tddSkill
- fable-verifySkill
- fable-wiseSkill
- get-fableSkill
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
- Distinctive: line 70
If triaging an issue, attempt reproduction against a clean temporary worktree before modifying code.
- Very specific: line 76
Run local test suite (bun test, npm test, cargo test, pytest).
- Distinctive: line 77
Verify linter, typecheck, and format checks pass.
- Distinctive: line 98
Run build tools and package managers in isolated working directories.
- Distinctive: line 99
Never execute destructive git commands (git push --force, git reset --hard) against mainline branches.
- Distinctive: line 108
If a CI failure cannot be reproduced locally, isolate environment dependencies (Node/Bun version, OS differences, container configuration).
- Distinctive: line 109
If merge conflicts cannot be cleanly resolved without domain decisions, escalate with a conflict map to the branch author.
- Distinctive: line 114
All repository test suites pass without regression.
≈ “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
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-planorfable-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
- 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.
- 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.
- 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.
- Run local test suite (
- 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 Rationalization | Hard Reality / Invariant | Why |
| "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 --statproving 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.
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.

