bygama
- 4 skills
- 0 followers
- 13 hours ago last updated
- ▌ Testing First · bygama bundleEnforces test-first implementation — the Iron Law (no production code without a failing test first), RED-GREEN-REFACTOR with both verification beats mandatory, and the rationalization table that catches "just this once". Cycle evidence lands in the lane's PROGRESS.md, and completion hands off to work-verify instead of being self-claimed. Use before writing implementation code for any feature, bugfix, or behavior change; when writing or reviewing a test; when tests are being added after the fact; when authoring a skill or an eval, where the eval is the failing test; and whenever time pressure, sunk cost, or "I already manually tested it" is arguing for skipping TDD. Covers test-driven development (TDD).
- ▌ Tracing Root Causes · bygama bundleOwns debugging end to end — reproduce, isolate, hypothesize, disconfirm, fix — with competing hypotheses, evidence ranked by strength, active disconfirmation, and a fix at the source rather than the symptom. Use for any bug, test failure, crash, regression, flaky or intermittent failure, performance problem, build failure, or unexpected behavior, BEFORE proposing or applying a fix; and for explaining why something happened (production incidents, surprising benchmark results) when no fix is on the table yet. Especially when an "obvious culprit" is tempting, when a previous fix did not work, or when time pressure makes guessing attractive. Supersedes superpowers:systematic-debugging as the house debugging skill.
- ▌ Extracting Design Md · bygama bundleReverse-engineers a DESIGN.md (Google Labs format) from an already-built project — electing tokens from the surfaces the owner designates as reference rather than from whichever value is most frequent, shipping everything unconfirmed as `[provisional]`, and writing decisions per module under a `### Global` tier. Use whenever an existing codebase should adopt DESIGN.md, when UI values have multiplied (several grays, mixed radii, inconsistent buttons), when the owner says the UI looks inconsistent or "quedó desprolijo", when an app has too many surfaces for one flat list of decisions, or to re-audit drift after a migration batch — even if nobody says the word DESIGN.md.
- ▌ Designing Consistently · bygama bundleKeeps UI work consistent with the design system an app actually has — discovering what already governs when no DESIGN.md exists, reading a bounded slice of the decision log however large the app is, and repairing that record as the work proves it. Use when building or modifying UI in any repo, whether its system lives in a DESIGN.md or only in tokens, context-file gotchas and prose docs, when new screens must match existing ones, when an app has too many surfaces to read its whole decision log in one session, when buttons or patterns come out different every session, or when design decisions get lost between sessions.