vyas-devgna/braids

Use before implementing, reviewing, or approving a code change, and before stating what one achieved. Always use before removing a check, weakening a guarantee, touching auth or permissions, rewriting or deleting stored data, changing a stored format, anything that cannot be undone or that older versions cannot read, or claiming faster, secure, reliable, compatible, or production-ready. A direct instruction still qualifies; calling it small or quick does not lower it. Triggers: architecture, design, refactor, migration, security, auth, permissions, secrets, data integrity, concurrency, race, retry, fallback, timeout, error handling, edge case, performance, memory, dependency, upgrade, deploy, rollback, review, audit, cross-module impact, callers. A one-line edit qualifies if it removes a check or crosses a trust boundary. Skip spelling, formatting, comments, explanations, and behaviour-preserving renames. Match behavior, not identifier names.

Whole-repository engineering audit with no diff: ranked risk surface, trust boundaries, failure gaps, dependency burden. Use for audit this repo, where is this risky, pre-launch check. For a diff use braids-review.

Map every engineering claim to the evidence that would prove it, and mark what is unproven. Use for is this actually faster, prove it, what evidence do we have, can we say production-ready.

Set how hard Braids works: threshold low, high, or ultra, and engineering depth D0-D4. Use for braids low, braids high, braids ultra, keep it light, quick pass, go deep, be thorough, maximum rigour, production-grade.

Reference card for Braids: what each skill does, the low/high/ultra threshold, and how depth D0-D4 works. Use for braids help, braids commands, what can braids do.

Engineering review of a diff, branch, or pull request, ending in a merge verdict: what breaks, what the change asserts without evidence, what costs more than it buys, and the residual risk of merging. Use for review this change, review my PR, is this ready to merge, is this safe to ship, what did this miss. Adds claim and cost judgement to a correctness-focused review rather than repeating it. For a whole repo with no diff use braids-audit.

Adversarial pre-mortem: weakest assumption, partial failure, retry, concurrency, upgrade, scale, corrupt state, outage, attack path. Use for what could go wrong, red-team this, poke holes in this, what am I missing.