Menú
Fine-grained outside-in RED-GREEN-REFACTOR microcycles with specialist agents and single-diagnostic implementation.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
RGR sequence, observed-failure evidence, drill-down unit tests, and non-behavioral exemptions for Phoenix/Commanded work.
Phoenix 1.8, Postgres, Commanded, Ecto, ExUnit, Dialyzer, and strict static-check conventions.
Phoenix auth/session/CSRF, command authorization, event data sensitivity, Postgres, dependency, secret, and threat-model review triggers.
Process Forgejo PR feedback with reflection, guardrail-gap classification, and inline thread replies.
Classify review feedback and choose proportionate guardrails without inflating default context cost.
Write implementation plans as test-addressed red-green-refactor cycles rather than component waterfalls.
| name | outside-in-rgr-microcycle |
| description | Fine-grained outside-in RED-GREEN-REFACTOR microcycles with specialist agents and single-diagnostic implementation. |
Use this skill when /outside-in-rgr is orchestrating one behavior through specialist-agent handoffs.
Keep a visible ledger for each active cycle:
Goal:
Current test:
Focused command:
Observed failure:
Expected failure reason:
Reviewer decision:
Diagnostic under treatment:
Allowed immediate change:
Result:
Next control owner:
RED is valid when a focused command was run and produced an observed failure that is expected for the requested behavior. Compile errors count as RED when the test intentionally pressures a missing module, context API, command, event, schema, or boundary.
Fix test misuse before production edits. Do not treat accidental misuse of existing code as implementation pressure.
Send every new or activated RED test to rgr-test-reviewer before production edits. A reviewer veto blocks implementation until the test author addresses the mandatory notes and records a new RED.
The implementer may treat exactly one current diagnostic at a time. The allowed production edit is the smallest concrete change that removes or changes that diagnostic. Do not predict later errors, prebuild adjacent behavior, refactor opportunistically, or batch fixes.
If the current diagnostic does not identify one concrete code change, write or request a lower-level unit test that exposes the next decision point. That lower-level test must go through RED and test review before production edits.
GREEN means the focused command for the current test passes after the smallest demanded implementation change. When the observed failure changes but the test still fails, stop the implementer turn and return control to the orchestrator with the new diagnostic.
After GREEN, send the production diff to rgr-implementation-reviewer. A reviewer veto blocks refactor, broader verification, and handoff until the implementer addresses the mandatory notes with focused tests still green.
Refactor only after GREEN and implementation review approval. Refactors must preserve behavior and keep the focused command green. Avoid abstractions not demanded by the current behavior.
Return control to the orchestrator whenever a test is authored, a reviewer approves or vetoes, a diagnostic changes, a focused test passes, the same failure remains after an attempted edit, or a blocked state needs a decision.
Stop the active microcycle when all current cycle tests pass, reviewer vetoes are resolved, focused verification passes, and the ledger identifies the next handoff. Do not commit unless the user explicitly requests it.
Report a blocked state when no focused command can be run, the failure output is unavailable, the diagnostic is ambiguous and no lower-level test seam is apparent, or required changes would touch unrelated user work.
Run the narrow focused test first. Before handoff, run the strongest relevant gate feasible for the files changed and state any skipped gate with the reason.