# Uberaccept > Do not auto-trigger from task similarity. Use only when explicitly named by the user or routed by ubergoal. Performs proportional adversarial acceptance against the exact approved scope, candidate diff, and risk-mapped proof before completion or ship claims. - Skill: `rdleclerc/uberaccept` (Agent Skill, multi-file: 30 files) - Install (CLI): `npx skillmds@latest add rdleclerc/uberaccept` - Raw SKILL.md: https://api.skillmd.com/api/skills/rdleclerc/uberaccept/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: rdleclerc (https://skillmd.com/u/rdleclerc) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/rdleclerc/uberaccept --- # Uberaccept ## Core rule Try to prove the candidate is not ready. Accept only the exact claim whose material requirements are proved. Expand proof with evidenced risk, not with a universal checklist. Unit green, polished prose, or a validator cannot stand in for required black-box, integration, runtime, or user-visible evidence. `uberaccept` owns the terminal acceptance decision. It does not plan or repair the work. Use `$uberplan` for changed implementation contracts, `$ubergoal` for bounded execution, and `$uberskillevolver` for post-run learning. ## Authority and inputs Read the operator request and exact approved plan or micro-intent, candidate diff/touched files, evidence receipts, and relevant repository contract. Record their path and revision or digest when available. Also read planned `candidate_kind`, `change_budget`, and `mechanism_inventory`; bind them to the plan source; compare changed files, additions/deletions (churn), and mechanisms. A proved `no_change` candidate may be accepted with an empty diff. Scope fidelity compares the operator original instruction, agent-interpreted scope, proposed narrowed scope, explicit deferrals/non-goals, and approval evidence. Unapproved narrowing or expansion blocks acceptance. - The plan defines intended scope; the diff defines actual implementation; evidence proves claims. None may silently redefine another. - Use `UNKNOWN` or `not provided` for an absent input. Never reconstruct missing state from summaries, fixtures, source-adjacent data, or a green local test. - Preserve an authoritative upstream terminal decision and its evidence id. Missing or unknown status is not `rejected`. - Material edits make earlier diff review stale; same-agent review can be recorded as a lens but must not count as independent evidence. - When independent review is required, record reviewer identity/model/runtime and `independent_review: true/false`. ## Decision contract Return exactly one `acceptance_status`: - `accepted` — every material requirement for the scoped claim is proved, or a named residual gap has exact operator approval. - `fix_within_scope` — a bounded defect or missing proof is already authorized by the approved plan and can be corrected without changing scope or authority. - `replan` — evidence changes the implementation contract, causal repair set, architecture, or proof strategy without requiring a new product decision. - `user_decision` — proceeding requires approval for product scope, public behavior, ownership, dependency, irreversible tradeoff, acceptance, or an external action. - `blocked_with_failure_intake` — a required gate cannot currently run or an external/environmental barrier prevents acceptance. Name safe next actions and file or update the failure case. - `rejected` — preserve an authoritative terminal rejection, or reject a candidate whose evidenced contradiction cannot honestly be represented by one of the repair/replan/decision states above. Do not convert missing, malformed, or unknown status into `rejected`. Do not average a blocker away. Only `accepted` authorizes completion or ship language. ## Acceptance kernel 1. Echo the exact claim, tier, approved scope, and explicit non-goals. 2. Compare plan to diff on spec fidelity, repo/architecture fitness, change budget, and mechanism inventory; any mismatch can block acceptance. 3. Map each material requirement to exact diff and proof. Mark it `proved`, `weak`, `missing`, or `contradicted`. 4. Identify the concrete false-green risk for each activated risk: what could still fail despite the evidence shown? 5. Apply only the riders triggered by the plan, diff, claim, or repository contract. Check repository-mandatory gates even when the plan omitted them. 6. Return the typed decision, material blocker or residual, and smallest safe next action. Never edit the implementation during acceptance. Require a meaningful red-before/green-after result when it is practical and diagnostic. Do not manufacture a red phase, broad suite, extra reviewer, or artifact merely to fill a field. Tests must map to a concrete failure mode. For `no_change`, require baseline evidence and a partial-fix check instead of a manufactured diff. For partially fixed behavior, require proof of the remaining defect and the smallest complete repair. ### Acceptance-criteria verification Check every material criterion; block completion on any `fail`. A partial or residual result needs exact operator approval. Keep spec/intent fidelity separate from code and repository standards. ## Risk-activated riders Activate a rider only when its trigger is present; record trigger, required proof, observed proof, false-green risk, and verdict. - **Black-box/UI/user-visible behavior:** exercise the actual boundary and, for UI, rendered interaction and relevant accessibility behavior. - **Operational/live/adopted claim:** prove target wiring and authoritative target-system or user-visible readback. A registry, scaffold, shadow result, or local proof supports only that lower claim. - **External action/security/privacy:** require exact target, authorization, boundary negatives, idempotency, rollback, execution receipt, and authoritative readback. Planning never grants execution authority. - **Concurrency/retries/loops:** require race and duplicate-suppression proof, durable replay, correct stop, budgets/kill switches, per-iteration receipts, and independent verification as applicable; read `../references/loop-engineering.md`. - **Agentic or multi-agent failure:** verify the minimum complete causal repair set, upstream contract, human counterfactual, and behavior eval. Do not accept one repaired layer when another material user-visible failure remains. - **System-scale architecture:** require a `$uberarchitect` Architecture Stepback Packet for concurrency, queue/worker, gateway, orchestration, durability, backpressure, repeated-timeout, or symptom-patching claims. Local timeout/config patches do not prove the system class fixed. - **Product/rewrite/agentic-system spine:** locally polished micro-feature success that did not advance the basic working spine is a soft rejection signal. Reject a complex top-down harness unless the approved scope explicitly makes a non-readiness spike the final outcome. - **Tier 3/runtime/replacement:** retain the stated tier; require plan review, exact-diff review, independent adversarial review, security negatives, telemetry preflight, rollback rehearsal, authorized canary, authoritative runtime readback, and final acceptance as activated by the plan. - **Multi-child or plan tree:** inspect authoritative child states and receipts. Parent completion requires every required child operational, re-scoped-with-approval, or hard-blocked after safe work is exhausted. - **Repository topology/dependencies:** run the relevant boundary checks and distinguish unrelated known failures from candidate-caused failures. - **Mocked external boundary:** require real boundary proof or limit the claim to the mocked behavior; a mocked green test alone cannot prove the interaction. ### Loop acceptance lens For an activated loop rider, use per-iteration receipts and independent verification rather than maker-only self-review. Require durable replay, correct-stop proof, idempotency, and budget/time/retry kill-switches. ## Output Default to a compact decision receipt: 1. `acceptance_status` 2. exact claim and inputs read 3. material requirement-to-evidence findings 4. activated riders and false-green risks 5. blocker/residual and smallest safe next action 6. scoped confidence and completion recommendation Produce a durable report only when requested or when Tier 3, multi-child, long-running, resumable, or handoff work needs it. In that case use `templates/final-acceptance.md`, complete the core and activated rider sections, mark inactive template sections with one concise not-applicable reason, and validate with `scripts/validate_acceptance_report.py`. Failure intake is mandatory only for `blocked_with_failure_intake`, using the grammar in `evals/failures/README.md`. Report `git status --short --branch` for each touched repository when accepting code work. A dirty state is acceptable only when it is exactly the reviewed candidate or the operator explicitly approved it. ## Completion and learning Call `update_goal(status="complete")` only after `accepted` and only when no required work remains. All other statuses remain non-complete. For Tier 2/3 skill, prompt, workflow, multi-agent protocol, or agentic-system changes, route the observed lesson and eval evidence to `$uberskillevolver`. Never silently self-modify the skill. ## Optional Claude adversary Contract: `../references/claude-adversary.md` (opt-in only when the operator explicitly requests Claude by name; reconciliation + frame-independence rules there). Ask: 1. **Receipt reproducibility.** Are receipts deterministic tool output or model summaries? 2. **Scope/diff match.** Does the exact diff match the approved scope? 3. **Inherited assumption.** What could the next task inherit incorrectly? Then answer: **Ship: yes/no, one sentence.** ## Resources Use `templates/final-acceptance.md`; load architecture, agent-failure, `../references/operational-states.md`, loop, or adversary references only when their rider is activated.