agentleFS
unclebobunclebob/ub-mode/SKILL.md

ub-mode

Skill7.3k starsChanged 17 days agoMITView on GitHub

Follow the reduced principles when writing or changing code. Every change follows First Make it Work, then Then Make it Right, then Follow Practice. Use when the user runs /ub-mode or asks for the reduced principles.

3 other projects use a version of this; 1 new project in the last 4 weeks, against 0 the 4 before.

Adopted by

Surging: 1 new project took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 1 new project
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 1 in all, so this is a hint, not a trend.

Most recently taken up by

Who's talking about unclebob/ub-mode

The biggest 5 of 60 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 60

Talked about on GitHub, YouTube and Hacker News (60 times).

On GitHub · 47

42 more on GitHub

On YouTube · 12

7 more on YouTube

On Hacker News · 1

  • Other versions3 projects use a version of this.

    Word for word · 3

    1. oott123/skills★ 9100% same
    2. bepaldes/heimdall-agent★ 2100% same
    3. OpenThrottle/monorepo★ 2100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    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.

The file

Show its rules and text

We split this skill into the rules it gives an agent

26 rules. About 0 are common, 26 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈26

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

    Every time you are asked to make a change follow:

    line 11
  2. Distinctive:

    Do first whatever helps every later phase.

    line 26
  3. Distinctive:

    If a concurrent writer would matter, do not share state.

    line 27
  4. Distinctive:

    Write the failing test before you change the code.

    line 31
  5. Distinctive:

    If an honest test is impractical, do not write a bad one.

    line 34
  6. Distinctive:

    Do not bolt a new requirement onto the old design.

    line 38
  7. Distinctive:

    Ask what you would have built if it had been there from the start, think that through, and deliver it in pieces.

    line 39
  8. Distinctive:

    When two fixes that share one premise fail the same gate, write that premise in one sentence and count which actors hold the imbalance.

    line 43
  9. Distinctive:

    Do not start another fix until you have done that.

    line 45
  10. Distinctive:

    If the work is not obvious at a glance, build the tool that does it.

    line 58
  11. Distinctive:

    Do one unit by hand, then make the tool match that unit.

    line 59
  12. Distinctive:

    Put the domain in a structure that makes the illegal states impossible.

    line 65
  13. Distinctive:

    If the code is already clear and local, leave it.

    line 67
  14. Distinctive:

    Check the data where it enters.

    line 71
  15. Distinctive:

    Keep the business logic in a pure function.

    line 73
  16. Distinctive:

    Do not silence the compiler.

    line 79
  17. Distinctive:

    If they do not need the same mutable thing, give each its own.

    line 87
  18. Distinctive:

    If they do, allow one writer, and enforce that in the structure.

    line 88
  19. Distinctive:

    If the test would still pass when every function returned nothing, throw it out.

    line 106
  20. Distinctive:

    Use the crapper tool

    line 110
  21. Distinctive:

    Consider whether case statements are worth reducing.

    line 112
  22. Distinctive:

    Use the dryer tool to eliminate duplication that rank 0.8 or above.

    line 116
  23. Distinctive:

    Use the mutator tool

    line 120
  24. Distinctive:

    Keep a log of every action you take and the reason you took it.

    line 135
  25. Distinctive:

    Keep the main thread small.

    line 140
  26. Distinctive:

    Commit often, in small ordered commits.

    line 150

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

ub-mode

Every time you are asked to make a change follow:

  • First Make it Work.
  • Then Make it Right.
  • Follow Practice

First Make it Work

Laziness Protocol

  • One decision lives in one place.
  • Ship the smallest edit that solves the problem.

Foundational Thinking

  • Get the data shape right before you write the logic.
  • Do first whatever helps every later phase.
  • If a concurrent writer would matter, do not share state.

TDD

  • Write the failing test before you change the code.
  • See it fail for the reason you expect.
  • Make the smallest change that makes it pass.
  • If an honest test is impractical, do not write a bad one.

Redesign From First Principles

  • Do not bolt a new requirement onto the old design.
  • Ask what you would have built if it had been there from the start, think that through, and deliver it in pieces.

Attack the Premise

  • When two fixes that share one premise fail the same gate, write that premise in one sentence and count which actors hold the imbalance.
  • Remove the assignment.
  • Do not start another fix until you have done that.

Subtract Before You Add

  • Take complexity out before you add anything.

Outcome-Oriented Execution

  • Aim at the end state you can check.
  • A break in the middle is allowed when you planned it and can undo it.

Build the Lever

  • If the work is not obvious at a glance, build the tool that does it.
  • Do one unit by hand, then make the tool match that unit.

Architecture

Model the Domain

  • Put the domain in a structure that makes the illegal states impossible.
  • Maintain a glossary of domain terms.
  • If the code is already clear and local, leave it.

Boundary Discipline

  • Check the data where it enters.
  • Inside, trust it.
  • Keep the business logic in a pure function.

Type System Discipline

  • Make the illegal value impossible to write.
  • Parse outside data once, where it comes in.
  • Do not silence the compiler.

Make Operations Idempotent

  • Running it twice, or running it after a crash halfway through, ends in the same state.

Separate Before Serializing Shared State

  • If they do not need the same mutable thing, give each its own.
  • If they do, allow one writer, and enforce that in the structure.

Then Make it Right

Fix Root Causes

  • Reproduce it.
  • Fix the cause.
  • A guard that only hides the crash is not a fix.

Sequence work into verifiable units

  • Finish one small unit and check it.
  • Then start the next.

Test Behavior, Not Implementation

  • The test calls the code the way its user does and checks the result that user would see.
  • If the test would still pass when every function returned nothing, throw it out.

Crapper

  • Use the crapper tool
  • Reduce each function under CRAP 10 by splitting it, by testing it, or both.
  • Consider whether case statements are worth reducing.

Dryer

  • Use the dryer tool to eliminate duplication that rank 0.8 or above.

Mutator

  • Use the mutator tool
  • Cover the uncovered.
  • Kill the survivors.
  • Delete dead code.

Refactoring

  • Pin what the code does.
  • Change the structure.
  • Prove the behavior did not change.

Practice

Keep a Log

  • Keep a log of every action you take and the reason you took it.
  • Report that log upon completion.

Guard the Context Window

  • Keep the main thread small.
  • Send the bulk elsewhere, and keep the summary.

Worktree Cleanup

  • Find what is safe to remove, confirm nothing still in use needs it, then reclaim the disk.
  • Uncommitted work waits for a decision.

Commit and Push

  • Commit often, in small ordered commits.
  • Each commit says why, what changed, and how you proved it.
  • Push to the main line at the end.

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.