Menu
Maintain and apply RASS v1 scorecards with fixed weights, hard gates, and anti-gaming protections.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Improve, audit, simplify, rewrite, or migrate prompts, tool descriptions, agent instructions, and prompt stacks for GPT-5.6 Sol or the GPT-5.6 family. Use for outcome-first prompt design, autonomy boundaries, tool routing, PTC, grounding, verbosity, reasoning effort, and prompt evals.
Apply a deep, design-minded engineering workflow for complex work that needs careful planning, iteration, and simplification.
Use when preparing or running a Claude CLI agentic engineering review through claude -p for repository audits, architecture analysis, system design, security review, large refactors, specs, RFCs, or evidence-grounded long-form engineering analysis.
Use when preparing or running a ZCode GLM-5.2 agentic builder workflow through zcode --prompt for fast implementation, iterative code generation, focused fixes, and validation on an existing repository.
Apply adversarial opposite-analysis to plans, specs, architecture, code changes, and claims. Use when the user asks for adversarial review, opposing analysis, contrarian review, red-team reasoning, or Z.ai and MiniMax cross-checks through the Ralph MCP router.
Review and adjudicate Bugbot, Cursor, Seer, and similar automated PR feedback with local evidence before accepting, fixing, or dismissing findings.
| name | scorecard |
| description | Maintain and apply RASS v1 scorecards with fixed weights, hard gates, and anti-gaming protections. |
RASS v1 uses five weighted categories. Effectiveness is 35%. Efficiency is 20%. Reliability and safety are 20%. Memory and research quality are 15%. Maintainability and simplicity are 10%.
Every scorecard must include these hard gates. Tests pass. No secret leak. Eval files unchanged. No scope violation. No eval gaming.
Version scorecards explicitly. Keep metric names concrete and observable. Prefer a small set of metrics that a script can normalize to 0..1. Do not change a scorecard during the run that uses it.
Fixtures are protected eval inputs. Do not rewrite them during candidate evaluation. If a fixture or scorecard needs improvement, open a separate phase or commit and re-baseline before using it for candidate decisions.
Use scripts/evals/run_scorecard.py for single fixtures and suite-specific scripts for richer flows. A candidate can be kept only when the hard gates pass and the documented threshold is met.