widoriezebos
@widoriezebos
Public Skills
design-critique
by widoriezebos
Run an adversarial critique loop over a written design before implementation, with a materiality criterion that decides both what a critic reports and when the loop stops. Use when a design document is complete enough to attack, when adjudicating critique findings, or when a critique loop keeps producing rounds without changing what would be built. Do not use for code review of an implementation (that is conformance review) or for investigations of failing behavior (take-a-step-back).
code-critique
by widoriezebos
Review an implementation against its brief and computed diff before attacking it adversarially, using an implementation-specific materiality test and a bounded correction loop. Use after code has been implemented from a brief or accepted design, when adjudicating implementation-review findings, or before certifying delegated implementation. Do not use to critique a design before implementation (use design-critique) or to diagnose an unexplained live failure (use take-a-step-back).
improve
by widoriezebos
Chase a measured improvement goal against a benchmark or evaluation, raising a primary metric without regressing guard metrics. Use when the task is to improve something an on-demand evaluation can measure (benchmark scores, quality evals, latency or cost budgets). Do not use when no runnable evaluation exists (building one is then the first deliverable), for behavior-preserving restructuring (refactor), or for diagnosing failures (take-a-step-back).
take-a-step-back
by widoriezebos
Diagnose and redesign work that is stuck, repeatedly failing, expensive, drifting, or accumulating abstractions without a current consumer. Use when the user asks to step back; patches or runs are not converging; debugger, benchmark, or model-heavy work needs stop-loss; progress is unclear; or a proposed support layer may be unnecessary.
retro
by widoriezebos
Run the metasystem retro, turning accumulated task receipts into instruction changes and reviewing the previous retro's changes against evidence to keep, amend, or revert them. Use when scripts/receipt.sh check reports a retro due or the human asks for one. Do not use for code changes (normal work) or for mid-task rule additions (forbidden by the contract).
inception
by widoriezebos
Guide a human through the birth of an app under the metasystem — vision, criteria, the minimal guardrail net, covenant v1, doctrine v1, and the steel-thread backlog — for a fresh repository or as a retrofit into a mature one. Use on the coordinator seat, outside every mission, after adoption (fresh) or reconciliation (mature). Do not use during an active mission, and never to edit an existing covenant — that is the warden's lane and the human tier.
verify
by widoriezebos
Prove a code change works by driving the changed behavior end-to-end and observing the result instead of inferring it from green checks. Use before calling any change with a runnable surface complete. Do not use for changes with no runtime surface (docs, comments, pure test edits) or as a substitute for focused unit tests.
debug-java
by widoriezebos
Diagnose live Java runtime behavior through JDWP and debugger tools. Use for runtime bugs, wrong branches or state, concurrency/deadlocks, variable or thread inspection, breakpoints and stepping, timeout attribution, or proving an end-to-end causal chain. Do not use when static code/tests already prove the cause or when the task only asks to implement a known fix.
refactor
by widoriezebos
Restructure code without changing behavior. Covers readability work, extractions, moves, and de-duplication where the contract is that existing behavior is preserved. Use when the task is refactor-shaped or the user asks for cleanup or restructuring. Do not use for changes meant to alter behavior (that is implementation under the design docs) or for diagnosing failures (take-a-step-back).