Immutable. This exact content is served forever at /api/v1/blob/8167b5a3092235c4.
--- name: sweep description: Use when someone asks to inspect a whole project for broad maintenance risks and return an evidence-linked, decision-ready plan without changing files. Do not use for generic questions about what to do next, roadmap or backlog prioritization, review of a specific change, or implementation. --- # Hope Sweep Use the active host session to set the scope, inspect the project, merge evidence, and return a read-only maintenance plan. Do not edit files during Sweep. Read `../write/references/writing-standard.md` before drafting user-facing language. Apply it without changing the inspected coverage, evidence, decisions, uncertainty, or required result. ## Establish coverage Identify the repository root and current revision. Inspect tracked files and relevant untracked files owned by the project. Exclude ignored dependencies, caches, build outputs, external directories, and other non-owned paths. Report every material exclusion and coverage gap. Treat symbolic links as entries. Record their target text without following them outside the project. Use subagents for disjoint batches when that materially improves coverage. Every batch inspector must use a fresh context with no inherited conversation, previous reasoning, findings, or another inspector's output. Give each subagent an explicit file assignment. Give it only the person's exact request, project-owned instructions, assigned files, applicable maintenance risks, exclusions, the location of this Skill, and expected evidence format. Tell each inspector to read this Skill before acting. If fresh contexts are unavailable, inspect sequentially in the active session and disclose that independent batch inspection was unavailable. Merge their evidence and report missing or overlapping coverage. Reconcile reported counts and coverage claims against the source inventory. Every project-owned entry must be inspected, excluded with a reason, or named as a coverage gap. Do not claim whole-project coverage when inspection was partial. ## Inspect maintenance risks Consider: - broken references and configuration drift; - dead or stale code and content; - missing, repeated, or premature abstractions; - test gaps and documentation drift; - checks that freeze wording, file names, or implementation shape without guarding a concrete failure; - dependency, security, license, and compatibility risk; - performance, package, build, and CI waste; - generated-source and release-boundary drift; and - unclear ownership or project structure. The list guides inspection. It does not require a finding in every area. ## Require evidence Tie each finding to concrete files, symbols, configuration, tests, or authoritative external sources. Separate confirmed facts from inferences and open questions. Name the affected behavior or contract precisely. Do not collapse distinct input versions, stored artifacts, compatibility paths, or product promises into one label such as "legacy" or "history." Check consumers, generated copies, public contracts, and history before calling something unused. Do not treat a passing test as proof that a file or abstraction is necessary. Do not treat a missing reference search as proof that removal is safe when an external contract may exist. Try to disprove every material finding before reporting it. Check the strongest plausible alternative explanation and contradictory evidence. Remove the finding or lower its certainty when it does not survive that check. For a visual or interactive finding, reproduce the relevant viewport and state in the intended viewer. Treat thumbnails, composite previews, and screenshots from another state as leads, not confirmation. ## Make decisions easy Classify every actionable finding as one of: - `Recommend`: evidence supports a specific change and no material product choice remains; - `Decide`: the person owns a product, compatibility, retention, or other material trade-off; or - `Defer`: evidence or authority is insufficient for a recommendation. Give each item a stable ID and include: - the exact behavior, promise, or files in scope; - evidence and whether it is fact, inference, or an open question; - user or maintenance impact; and - the verification needed after implementation. When dependencies, recommended order, compatibility, or release effects are material, include them. Mark any that evidence does not establish as `unknown`. For each `Decide` item, ask one concrete question, recommend a default with a reason, and state the consequence of each viable option. Turn a broad concern into the behavior the choice would preserve or remove. Do not put a `Defer` item in the recommended implementation order. Group compatible `Recommend` items and already accepted `Decide` items into proposed, bounded implementation batches with their file scope and checks. For each unresolved `Decide` item, show which proposed batch its recommended default would join if accepted. Finalize and run selected batches only in a separate implementation task after the person accepts any included defaults. ## Return the plan Lead with the most important conclusion. Report: - coverage, exclusions, and gaps; - `Recommend`, `Decide`, and `Defer` items; - proposed implementation batches and their order; and - the smallest response needed from the person. Keep the final request to answers for unresolved `Decide` items and selection of proposed batches for a separate implementation task. Offer one reply that accepts every recommended default and selects all recommended batches. If no product decision remains, say so directly. A no-change or findings-only result is valid. Prefer removing an unneeded product promise, its implementation, and its tests together. Do not create approval records, completion records, session records, or Polish composition data. Do not invoke Polish. After returning the plan, wait for the person to select a separate implementation task.