Catalog
Yeachan-Heo/principles

Yeachan-Heo

principles

Twenty-four engineering principles in five groups, mapped to the lane carrying each — premise testing, root causes, honest verification, domain modeling, convergence, context discipline. For design, debugging, or delegation briefs.

v1.0LATEST
NewUpdated Nov 8, 2026

Engineering Principles

Twenty-four principles distilled for OMC's lanes from the pstack principle library (credited above) and rewritten against OMC's own mechanisms. Each names when it applies and which lane carries it. This is a discipline skill: it shapes how work is done; it never gates delivery on its own.

When to use

  • a fix has failed twice, or two fixes share one explanation
  • debugging, verification, or benchmarking work is starting
  • a design choice repeats a shape assumption across files
  • delegation prompts are being written and a lane's standing principles should travel with the brief

When not to use

  • a one-line mechanical edit with an obvious check
  • a hotfix under time pressure — state which principle you skipped and why in one line, then proceed

Core

Laziness Protocol

Refactoring, sizing a diff, or tempted to add abstractions, layers, or signal threading. Bias to deletion and the smallest change that solves the problem. Composes with minimal-code-discipline. Carried by executor and code-simplifier.

Foundational Thinking

Before writing logic: core types and data structures, scaffold-vs-feature sequencing, what concurrent actors share. Carried by architect and planner.

Redesign from First Principles

Integrating a new requirement into an existing design. Redesign as if the requirement had been foundational from day one, instead of patching the old shape around it. Carried by architect.

Attack the premise

When two or more attempted fixes share one assumption and all failed the same gate, stop writing fix three. Write the shared assumption down, test it directly, and let the result choose the next move. Carried by critic during plan gap analysis and by debugger before a third retry.

Subtract before you add

Before sequencing an addition, refactor, or rewrite, remove the dead weight first and build on the simpler base. Carried by executor and code-simplifier.

Minimize reader load

Reviewing or shaping code that is hard to trace. Count layers and hidden state, collapse one-caller wrappers, shrink mutable scope. Carried by code-simplifier and writer.

Outcome-oriented execution

Planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture; do not preserve throwaway compatibility states. Carried by planner.

Experience first

Product, UX, or feature-scope tradeoffs. Choose user delight over implementation convenience, and say the tradeoff out loud when you take it. Carried by designer.

Exhaust the design space

A novel interaction or architectural decision with no precedent. Build 2-3 competing options and compare before committing — the arena and architect skills are this principle operationalized. Carried by architect.

Build the lever

Any non-trivial repeated work. Build the tool that does or proves it — codemod, script, generator — rather than doing it by hand a third time; the tool is the artifact a reviewer reruns. Carried by executor.

Architecture

Model the domain

When stateful logic branches a lot or repeats a shape assumption across files, encode the domain in a structure — a state machine, a typed model, a registry, a reducer — instead of scattering conditionals. OMC's graph runtime (graph skill) is this principle at full size. Carried by architect.

Boundary discipline

Wiring validation, error handling, or framework adapters. Guards at system boundaries, trust internal types, keep business logic pure. Carried by architect and executor.

Type system discipline

Designing types or signatures in any typed language. Make illegal states unrepresentable, brand primitives, parse external data at boundaries; in TypeScript, typescript-best-practices grounds this in syntax. Carried by architect and executor.

Make operations idempotent

Design commands, lifecycle steps, and loops that run amid crashes and retries to converge to the same end state. OMC's team recovery replays worker checkpoints idempotently; user code deserves the same property. Carried by executor.

Migrate callers, then delete legacy APIs

Introducing a new internal API while old callers exist. Migrate every caller and delete the old surface in one wave; a compatibility shim with no expiry is a second system. Carried by executor.

Separate before serializing shared state

Concurrent actors might write the same file, branch, key, or object. Eliminate the sharing first (a writer per worktree is OMC's house form); locking is the fallback, not the first move. Carried by executor and team.

Verification

Prove it works

Done means verified against the real artifact — the command's actual output, the passing test, the rendered page — never a proxy and never "it compiles". The verify skill owns the evidence format. Carried by verifier.

Fix root causes

Trace each symptom to the first place the system went wrong and fix it there. A guard for a state that should not exist is a workaround, not a fix; it is legitimate only when that state itself is legitimate. Carried by debugger; verifier treats symptom-level patches as incomplete work.

Sequence work into verifiable units

Multi-step work — sweeps, migrations, runs of similar edits — and how commits and PRs stack. Small units that each end in a check, verified before the next, ordered so the sequence proves itself. Carried by planner and git-master.

Test behavior, not implementation

Assert what users of the code can observe. A test worth keeping fails when the behavior breaks and passes when only internals change. Carried by test-engineer.

Explain the number

Before trusting, reporting, or acting on a measured number, find what limits it and rule out that it measured something other than the work you think. Label every claim measured, inferred, or guess in the same sentence. The benchmark-checklist skill owns the full procedure. Carried by scientist and by any lane reporting performance.

Delegation

Guard the context window

Route bulk reading and large outputs to subagents; keep summaries in the lead thread. Context spent on a wall of log output is context not spent on judgment. Applies to every lane and to the orchestrator itself.

Never block on the human

Tempted to ask "should I do X?" on reversible work. Proceed, present the result, let the human course-correct; reserve questions for genuine product calls no experiment can settle. Carried by every lane.

Meta

Encode lessons in structure

The second time you write the same instruction, stop writing it a third time: encode it as a lint rule, a runtime check, a script, or — in OMC — a learned skill via skillify, or an enforcement via correct. Text rots; structure reruns. Carried by skillify and self-improve.

Distribution map

When delegating, prepend the delegate lane's standing principles to the brief.

Lane Standing principles
critic Attack the premise
debugger Attack the premise, Fix root causes
verifier Prove it works, Fix root causes
test-engineer Test behavior, not implementation
architect Foundational Thinking, Redesign from First Principles, Model the domain, Exhaust the design space
planner Foundational Thinking, Outcome-oriented execution, Sequence work into verifiable units
executor Laziness Protocol, Subtract before you add, Make operations idempotent, Boundary discipline, Type system discipline, Migrate callers, Separate before serializing, Build the lever
scientist Explain the number
designer Experience first
code-simplifier Laziness Protocol, Subtract before you add, Minimize reader load
writer Minimize reader load
git-master Sequence work into verifiable units
every lane Guard the context window, Never block on the human, Encode lessons in structure

Reporting

When this skill is active, name in the reply which principle shaped each non-obvious decision, in one clause. When a principle and an explicit user instruction conflict, the user wins; say so in one sentence.

Files1
1 files · 1.0 KB

Select a file to preview

Overall Score

82/100

Grade

B

Good

Grades are signals, not a certification. Always review a skill yourself before use.

Safety

90

Quality

78

Clarity

88

Completeness

72

Summary

This skill distills 24 engineering principles organized into five groups (Core, Architecture, Verification, Delegation, Meta) and maps each to the OMC lane responsible for carrying it. It serves as a discipline guide for design, debugging, and delegation briefs—shaping how work is done without gating delivery. The skill references a curated principle library and provides a distribution map for routing principles to delegated agents.

Detected Capabilities

principle retrieval and mappingdelegation routinglane-specific principle assignmentdecision justification framework

Trigger Keywords

Phrases that agents use to match this skill to user intent.

debug repeated failureswrite delegation briefguide architectural decisionrefactor for claritystructure verification work

Referenced Domains

External domains referenced in skill content, detected by static analysis.

github.com

Use Cases

  • Debugging repeated failures by identifying and testing shared assumptions across fixes
  • Writing delegation briefs with standing principles prepended for consistency
  • Guiding architectural decisions through first-principles redesign and design-space exploration
  • Shaping code review by minimizing reader load and enforcing boundary discipline
  • Structuring multi-step work into verifiable units with explicit phase boundaries
  • Choosing between competing design options using principle-driven comparison

Quality Notes

  • Comprehensive principle catalog with clear lane ownership and applicability conditions
  • Distribution map provides explicit routing for delegation, reducing ambiguity about which principles apply to which agents
  • When-to-use and when-not-to-use sections establish appropriate activation boundaries
  • Principle descriptions are concise (2-4 sentences) with concrete framing (e.g., 'Carried by [lane]') that grounds them in the OMC architecture
  • Cross-references to related skills (e.g., graph skill, verify skill, benchmark-checklist) connect principles to operationalized practices
  • Reporting section defines how to apply the skill: name the principle shaping each non-obvious decision, and defer to user instructions when conflicts arise
  • Frontmatter credits and attribution honor pstack library origins and ports
  • Principle categories (Core, Architecture, Verification, Delegation) provide logical hierarchy
  • No edge cases or troubleshooting guidance for when principles conflict with each other or with production constraints
  • Limited guidance on trade-offs between opposing principles (e.g., Laziness Protocol vs. Exhaust the Design Space)
Model: claude-haiku-4-5-20251001Analyzed: Nov 8, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Use Yeachan-Heo/principles in your dev environment

Command Palette

Search for a command to run...