clean-all-slop

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Clean All Slop

## Mission

Find unsupported success, hidden fallback, and low-signal AI residue before it
ships. When a failure is found, expose it as useful evidence instead of hiding it
behind apology, retry, fallback, or reassuring prose. When fixes are in scope,
remove the slop with behavior locked by direct evidence and tests. When the user
asks only for review, stay read-only.

This skill is intended for code review, midpoint inspection, post-failure
analysis, broad-scope cleanup planning, or next-turn continuation after a large
agent pass. It is not a default ceremony for tiny tasks.

## Mode Selection

- Use **audit mode** when the request asks for review, skeptical audit, prior
  turn inspection, evidence checking, midpoint checking, continuation review, or
  contamination detection. Do not edit.
- Use **failure handoff mode** when a failure, contradiction, false pass, stale
  state, tool error, missing evidence, or unsupported completion claim is found
  and the user did not already authorize repair.
- Use **cleanup mode** when the request asks to clean, refactor, deslop, fix, or
  remove the issues. Keep changes scoped to the requested files or feature.
- If mode is ambiguous, start with audit mode. Report findings and preserve a
  failure handoff when needed. Proceed to cleanup only when fixes are already in
  scope or the user explicitly authorized them.

## Audit Mode

1. Reconstruct the claim: user goal, promised changes, claimed checks, skipped
   checks, and completion wording.
2. Compare claims to artifacts: touched files, diffs, generated files,
   metadata, indexes, config, runtime state, hook state, MCP/session state, and
   unrelated changes.
3. Attack validation: require command output, exit status, path evidence, line
   references, screenshots, or reproducible observations. Reject stale output,
   partial runs, hidden failures, pass labels, and "looks good" claims.
4. Search for defect classes:
   - Hardcoding: fixed paths, IDs, magic constants, test-only values, locale
     assumptions.
   - Legacy residue: old paths, duplicate mechanisms, stale comments,
     placeholders, abandoned files.
   - Hidden fallback: swallowed errors, fake defaults, degraded behavior
     reported as success.
   - Contamination: leaked prompt/context, unrelated artifacts,
     machine-specific assumptions, secret-adjacent material.
   - Instruction skipping: ignored user constraints, AGENTS.md, skills,
     read-only limits, language rules, verification rules.
   - Bypass behavior: commands or tools that evade hooks, tests, review,
     policy, or the normal workflow.
   - Reward hacking: optimizing for PASS, green output, or reassuring prose
     instead of the user goal.
   - Slop: vague implementation, brittle parsing, broad exceptions, unclear
     ownership, unreviewed generated code.
5. Lead with findings. Mark any actionable issue `FIX REQUIRED`; mark no
   actionable issue `CLEAN` with checked evidence, not-checked items, and
   residual risk.

## Failure Capsule

When a failure, contradiction, false pass, blocked check, stale state, tool
error, or unsupported claim is discovered, preserve it as evidence. Do not smooth
it over.

A failure capsule must include:

- Expected: what should have happened.
- Observed: what actually happened.
- First mismatch: the earliest confirmed divergence from the claim, plan, or
  expected behavior.
- Evidence: command, path, line, diff, screenshot, log excerpt, or tool output.
- Changed surface: files, config, runtime state, generated output, hook state,
  MCP/session state, cache, database, toolchain, or external surface.
- Current risk: what may be wrong if this is ignored.
- Next-turn target: the smallest causal question to answer next.
- Unsafe next actions: actions that would destroy evidence, hide the failure, or
  replace the failed proof with easier evidence.

## Compact Failure Taxonomy

Classify the failure before repair. Use the smallest label set that explains the
observed evidence.

- **Claim failure**: final wording claimed more than the evidence supports.
- **Validation failure**: a check failed, was partial, stale, not actually run,
  or was replaced by weaker evidence.
- **Tool failure**: shell, path, sandbox, MCP, permission, package, runtime, or
  command execution failed.
- **Instruction failure**: user constraints, scoped instructions, read-only
  limits, skill rules, or language requirements were skipped.
- **State failure**: cache, generated files, session state, hook state, DB state,
  browser state, MCP reload, or runtime injection was stale or mismatched.
- **Boundary failure**: unrelated files, secrets, external surfaces, destructive
  actions, or out-of-scope areas were touched.
- **Design failure**: implementation works mechanically but fails product intent,
  UX clarity, hierarchy, accessibility, or visual quality.
- **Maintenance failure**: the change adds duplicate mechanisms, hidden fallback,
  dead code, unclear ownership, over-abstraction, or drift-prone policy.

## Root-Cause Ladder

Do not stop at a symptom. Stop at the shallowest evidenced cause that explains
all observed evidence.

1. **Reproduce**: can the failure or mismatch be observed again?
2. **Boundary**: which file, command, state, tool, or workflow surface first
   diverged?
3. **Mechanism**: what code, config, dependency, tool behavior, or assumption
   caused the divergence?
4. **Masking**: did fallback, retry, stale output, broad exception handling, or
   final prose hide the divergence?
5. **Prevention**: what check, test, guard, workflow note, or deletion prevents
   recurrence?

Do not claim root cause until the mechanism level is evidenced. If mechanism is
not yet known, report `root cause not proven` and preserve the next-turn target.

## Turn Boundary Rule

From andy4917/Agentic-workspace-software, Apache-2.0.

More from andy4917/Agentic-workspace-software