Update to Develoop

{
  "description": "Find and simplify implicit state machines across a repository or a specified pull request without regressing behavior. Use for requests such as \"find all of the implicit state machines in my app\" or a cleanup pass that removes redundant state and consolidates scattered transitions for readability and maintenance.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 260
    },
    {
      "relative_path": "references/decision-examples.md",
      "size_in_bytes": 2808
    }
  ],
  "name": "cleanup-slops",
  "skill_md_contents": "---\nname: cleanup-slops\ndescription: Find and simplify implicit state machines across a repository or a specified pull request without regressing behavior. Use for requests such as \"find all of the implicit state machines in my app\" or a cleanup pass that removes redundant state and consolidates scattered transitions for readability and maintenance.\nlicense: MIT\n---\n\n# Cleanup Slops\n\nStart from this prompt:\n\n> find all of the implicit state machines in my app\n\nUse it as a discovery lens for a behavior-preserving cleanup. Find lifecycle\nrules hidden across mutable flags, nullable values, effects, callbacks, and\nduplicated status fields. Remove unnecessary stored state and scattered\ncoordination; make essential transitions easier to understand and maintain.\n\nAn implicit state machine exists when the meaning or legality of an operation\ndepends on prior events and combinations of state, while its transitions and\ninvariants are distributed across the code. Multiple booleans alone are not\nevidence: independent settings may legitimately vary independently.\n\n## Establish the boundary\n\n- For a repository-wide request, map application entry points and runtime\n  modules, then track which areas were inspected. Start with first-party code;\n  exclude generated, vendored, and build output unless they own relevant\n  behavior. Do not claim exhaustive discovery from a few keyword searches.\n- For a specified PR, resolve the target repository, base, and head. Inspect the\n  merge-base-to-head diff and the full enclosing implementations, callers,\n  consumers, and tests needed to understand it. Address machines introduced,\n  modified, or relied on by that implementation; record unrelated discoveries\n  without expanding the patch. Keep findings tied to the inspected head.\n- Honor explicit inspection-only or planning requests. When cleanup is\n  requested, carry supported fixes through implementation and validation.\n  Local cleanup does not itself authorize remote comments, push, merge,\n  deployment, or changes to external data.\n- Read repository guidance and preserve unrelated working changes. For a new\n  cleanup branch, use the existing checkout unless isolation is required or\n  requested. Keep an existing PR's branch context when working on that PR.\n\n## Discover and reconstruct\n\nTrace behavior from entry points and state owners, using searches only as\nleads. Inspect loading and error flags, selected IDs plus cached objects,\nstatus enums, mirrored props or store values, subscription and connection\nlifecycles, pending promises, timers, retries, queues, persistence, and cleanup\nhandlers. Follow reads, writes, reset paths, and async completions across\nmodule boundaries. Include server, worker, and client paths where present.\n\nKeep a compact inventory for each candidate:\n\n| Evidence | What to establish |\n| --- | --- |\n| Owner and locations | Who owns the state, who writes it, and who observes it |\n| Effective states | Reachable combinations and combinations ruled out by code or contracts |\n| Events and transitions | Entry, success, failure, cancellation, retry, reset, and disposal paths |\n| Invariants and effects | What must remain true, including observable output and side effects |\n| Decision | Derive or remove redundant state, consolidate essential transitions, preserve, or defer with a reason |\n\nDistinguish demonstrated behavior from inferred intent. A suspicious combination\nis a candidate until its producers, consumers, and reachable transitions are\nunderstood. Prioritize redundant sources of truth, impossible combinations,\nduplicated transition logic, and effects that synchronize state with other\nstate. Preserve independent axes such as cached data and an in-flight refresh.\n\n## Establish regression evidence\n\nBefore editing a candidate, identify its observable contract and run the\nrelevant existing checks. Record baseline failures separately. Where coverage\ndoes not establish that contract, add focused characterization tests at the\npublic behavior boundary; confirm they pass before refactoring. Test outcomes\nand transitions, rather than private field names or the new representation.\n\nInclude the failure and recovery paths the candidate actually supports. For\nasync work, exercise overlapping requests completing out of order,\ncancellation, retry, and disposal where relevant. Preserve side-effect count\nand ordering, error propagation, and resource release. For UI paths, exercise\nthe affected interaction in the available browser or device as well as tests.\n\nCheck external consumers and persisted state before removing or renaming a\nfield. Preserve public APIs, serialized representations, event payloads, and\nstorage compatibility unless a contract change is explicitly in scope. An\ninternal simplification may need an adapter at that boundary.\n\n## Simplify one candidate at a time\n\nChoose the smallest representation that expresses the existing contract:\n\n- Derive values from an authoritative source instead of storing and\n  synchronizing equivalent flags or copied objects.\n- Remove unreachable branches or obsolete transitions only after tracing\n  their producers and externally supplied or restored state.\n- Group states that are demonstrably mutually exclusive when that prevents\n  invalid combinations. Keep independent facts independent.\n- Give essential lifecycle transitions one clear owner. A local transition\n  function, reducer, or discriminated union may help when the lifecycle cannot\n  be eliminated; do not add a framework or universal state-machine layer by\n  default.\n- Keep guards that enforce timing, request ownership, idempotency, cleanup,\n  or consistency. Fewer flags or lines are not sufficient evidence of a safe\n  simplification.\n\nUse [references/decision-examples.md](references/decision-examples.md) when\ndeciding whether state is redundant or protects meaningful history.\n\nKeep edits reviewable and run the focused checks after each coherent change.\nDo not quietly fix a pre-existing behavioral bug as part of an equivalence\nrefactor. Record it separately unless the requested scope includes its fix.\nIf a candidate's contract is ambiguous or cannot be verified, defer that\ncandidate with concrete missing evidence and continue with supported cleanup.\n\n## Verify and report\n\nRun the repository's required checks and the tests for affected consumers.\nRevisit the inventory: verify that removed state has no remaining writers or\nconsumers and that essential transitions still have an owner. Review the diff\nfor unrelated churn, changed defaults, altered event ordering, and accidental\nAPI or persistence changes.\n\nReport the inspected scope and PR head when applicable, the machines found,\nwhat was simplified, what was preserved or deferred and why, and the checks\nactually run. Identify baseline failures and untested behavior explicitly;\ndo not claim regression freedom from passing unrelated checks. State any\nuninspected areas when reporting repository-wide coverage. Finish when the\nin-scope inventory is addressed or explicitly deferred with evidence; do not\nkeep rewriting adjacent code merely to reduce the machine count.\n"
}