Skip to main content

ub-mode

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.

ソース情報

リポジトリ
unclebob/ub-mode
ソースの最終更新活動
2026年10月25日 16:07
検出された SKILL.md の言語
英語
スター
332
フォーク
16

ub-mode: Reduced Clean Code / TDD principles for agents

Forces every change through First Make it Work, Then Make it Right, then Follow Practice—laziness protocol, TDD, redesign from first principles, subtract-before-add, and related reduced principles.

Uses

Use when the user runs /ub-mode or asks for the reduced principles while writing or changing code.

Prerequisites

A concrete change request; willingness to write a failing test before code when TDD applies.

How to use

Make it work with the smallest edit → make it right (structure, tests, domain) → follow practice (boundaries, types, levers).

Limitations

Principles are procedural guidance for the agent, not an automatic refactorer. Skip bad tests when an honest test is impractical.

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
name
ub-mode
description
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.
# 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.
GitHubで見る