pattern-matching
Pattern Matching
Overview
Every codebase has a fingerprint. Your job is to replicate that fingerprint so precisely that no reviewer can tell where the original ends and your contribution begins.
Core principle: Observe before you act. Every function, file, and folder you produce must have a living precedent somewhere in the repository. If you cannot point to the model you followed, you have already introduced drift.
No exceptions. No workarounds. No shortcuts.
The Prime Directive
EVERY ADDITION MUST MIRROR AN EXISTING PRECEDENT
When the repository favors snake_case, you write snake_case. When services live under src/domain/, your service lands there too. When errors propagate through a custom Result<T> type, you adopt it without question. There is no room for personal preference.
When to Use
More from noobygains/godmode
fault-diagnosis
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
15task-planning
Use when you have a spec or requirements for a multi-step task, before touching code
15agent-messaging
Use when dispatching subagents, composing prompts for teammates, structuring handoff reports, or managing context boundaries between agents. Covers both subagent prompts and team-level messaging.
15intent-discovery
Use when starting any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.
15quality-enforcement
Use when preparing code for commit, PR, or merge - covers linting, type safety, bundle budgets, coverage thresholds, complexity limits, dependency audit, and dead code detection
14merge-protocol
Use when implementation is finished, tests are green, and you need to decide how to land the work - presents structured integration paths for local merge, pull request, deferral, or abandonment
14