scip-query 0.19.4 → 0.19.6

package/dist/direct-navigation-MRMQFIRB.js

@@ -1,3 +0,0 @@
-#!/usr/bin/env node
-import{n as a}from"./chunk-ZAIILQNP.js";import"./chunk-SVLTAG5O.js";export{a as directNavigationQueryCommandDescriptors};
-//# sourceMappingURL=direct-navigation-MRMQFIRB.js.map

package/skills/scip-api-impact/SKILL.md

@@ -1,139 +0,0 @@
----
-name: scip-api-impact
-description: Assess API impact with scip-query evidence. Use before changing public exports, module boundaries, schemas, routes, CLI commands, config fields, generated artifacts, signatures, docs-backed behavior, or consumer migrations.
-commands:
-  - template: "scip-query surface <module-or-package>"
-    when: "Identify the surface: what consumers actually use from the module."
-  - template: "scip-query refs <symbol>"
-    when: "Find consumers: every direct reference to the surface symbol."
-  - template: "scip-query affected <symbol> --json"
-    when: "Find consumers: transitive blast radius of the change."
-  - template: "scip-query co-change <file> --json --full"
-    when: "Find hidden partners: historically coupled files without a dependency edge."
-  - template: "scip-query doc-drift --json --full"
-    when: "Find hidden partners: docs that describe the surface and may need an update."
-  - template: "scip-query unused-params --json --full"
-    when: "Choose migration shape: reject speculative new parameters."
----
-
-# scip-api-impact
-
-Use this skill before changing a public surface. A public surface is a callable, export, route, schema, config field, CLI command, generated artifact, or documented behavior that other code or users can depend on. Its defining trait is that a local edit can require coordinated consumer, docs, tests, or migration changes outside the implementation file.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | When |
-| --- | --- | --- |
-| `scip-query surface <module-or-package>` | What symbols consumers actually use from this module | Identify the surface: what consumers actually use from the module. |
-| `scip-query refs <symbol>` | Find all files referencing a symbol | Find consumers: every direct reference to the surface symbol. |
-| `scip-query affected <symbol> --json` | Transitive closure of symbols that could break if this symbol changes | Find consumers: transitive blast radius of the change. |
-| `scip-query co-change <file> --json --full` | Files that change together in git history without a dependency edge — hidden coupling candidates | Find hidden partners: historically coupled files without a dependency edge. |
-| `scip-query doc-drift --json --full` | Stale-doc candidates: code the doc references or co-changed with kept changing after the doc stopped | Find hidden partners: docs that describe the surface and may need an update. |
-| `scip-query unused-params --json --full` | Speculative-generality candidates: trailing parameters no body ever uses (TS/JS) | Choose migration shape: reject speculative new parameters. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Rules
-
-1. Identify the actual surface before planning.
-2. Find direct consumers, reverse dependencies, transitive blast radius, and historical co-change partners.
-3. Treat docs, generated files, tests, and config as part of the API when they describe or enforce the surface.
-4. Prefer backward-compatible migrations when consumers are broad or external.
-5. Run `scip-verify` after implementation.
-
-## Workflow
-
-### 1. Identify the surface
-
-```bash
-scip-query surface <module-or-package>
-scip-query outline <file>
-scip-query trace <symbol-or-command>
-scip-query code <symbol-or-command>
-scip-query hierarchy <symbol> --json
-```
-
-This step is complete only when the real surface is named: member, class, module, package, route, schema, command, or config field.
-
-### 2. Find consumers
-
-```bash
-scip-query refs <symbol>
-scip-query fan-in <symbol>
-scip-query rdeps <file>
-scip-query affected <symbol> --json
-scip-query change-surface <file> --json --full
-```
-
-Record direct consumers separately from transitive consumers.
-
-This step is complete only when direct breakage and regression blast radius are known.
-
-### 3. Find hidden partners
-
-```bash
-scip-query co-change <file> --json --full
-scip-query doc-drift --json --full
-scip-query similar <symbol> --json --full
-scip-query similar-files <file> --json --full
-```
-
-This step is complete only when docs, generated files, fixtures, sibling APIs, and hand-synchronized partners are accounted for or ruled out.
-
-### 4. Choose migration shape
-
-Pick one:
-
-- Compatible extension.
-- Two-step migration.
-- Breaking coordinated change.
-- Adapter shim for external consumers or compatibility windows.
-
-Reject speculative inputs and empty wrappers with:
-
-```bash
-scip-query unused-params --json --full
-scip-query wrapper-candidates --json --full
-scip-query passthrough-candidates --json --full
-```
-
-This step is complete only when the migration shape explains deploy order, rollback, and compatibility risk.
-
-### 5. Build and verify the plan
-
-```markdown
-Surface:
-Consumer dispositions:
-| Consumer | Kind (direct/transitive/doc/config/test) | Disposition (unchanged-safe/update/shim/defer) |
-| --- | --- | --- |
-Required co-changes:
-Migration:
-Verification:
-- targeted tests
-- `scip-query diff-impact --json`
-- invoke `scip-verify`
-- `scip-query doc-drift --json --full` when docs changed
-- `scip-query config-validate` when config changed
-```
-
-Every consumer from `refs`/`affected` appears as a row — a blank disposition is unfinished analysis, and the plan is not complete while one exists. Non-indexed consumers (SQL, fixtures, dynamic strings, external callers) are checked with `rg` and rowed the same way.
-
-After editing, run routed checks from the shared reference and invoke `scip-verify`.
-
-The work is complete only when direct consumers, docs/config partners, and `scip-verify` have been checked.
-
-## Report
-
-```markdown
-API impact: low/medium/high
-Surface changed:
-Consumers:
-Migration plan:
-Co-changes:
-Verification:
-Remaining risk:
-```

package/skills/scip-api-impact/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP API Impact"
-  short_description: "Assess public API and boundary change impact"
-  default_prompt: "Assess the impact of this public API or module-boundary change with scip-query evidence and produce a migration-safe plan."

package/skills/scip-calibrate/SKILL.md

@@ -1,131 +0,0 @@
----
-name: scip-calibrate
-description: Calibrate scip-query's detectors against a repo before trusting them. Use when adopting scip-query in a new or foreign codebase, after major detector changes, when a health score or gate output seems too noisy or too clean, or before letting diff-gate block anyone's work.
-commands:
-  - scip-query health --json
-  - scip-query diff-gate --base <commit> --json
-  - scip-query twin-drift -s <scope> --json
-  - scip-query dead --json
-  - scip-query similar <symbol>
-  - scip-query config-validate
-  - scip-query effectiveness --since 30d --json
----
-
-# scip-calibrate
-
-Use this skill to measure whether scip-query's detectors tell the truth about a
-specific repository before believing anything they say about it. A detector
-tuned on one codebase's conventions can be precise there and noisy elsewhere;
-calibration is how you find out which you have — and it converts every noise
-archetype you find into either a repo-side knob or an upstream detector bug.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-## The Stance
-
-A health score you have not calibrated is a number, not a fact. Never present
-detector output from an uncalibrated repo as findings — present it as
-candidate findings pending classification. The score must EARN trust the same
-way a checker earns it in `scip-integrity-audit`: by being witnessed telling
-the truth on samples you verified yourself.
-
-## Protocol
-
-Run all five stages. Each has a checkable exit.
-
-### 1. Index and inventory
-
-`scip-query reindex`, then `scip-query status --capabilities`. Record which
-languages got which evidence tier (SCIP-indexed vs source-fallback vs regex) —
-a detector's expected precision differs per tier, and a repo that is 80%
-fallback-tier must be judged against fallback expectations. Note monorepo
-shape (workspaces, cross-package imports): historically the single largest
-false-positive source (dead/new-dead on cross-package consumers).
-Complete when: languages, tiers, and workspace shape are written down.
-
-### 2. Battery sweep
-
-Run the full detector battery and `health --json`. Do not react to anything
-yet — big numbers are not findings, they are sampling frames.
-Complete when: every detector's finding count is recorded.
-
-### 3. Retro-gate replay
-
-Replay `diff-gate` against the last 15–20 real commits (worktree per commit,
-never the user's live tree). This is the stage that exposes finding WALLS —
-one hub file or one convention mismatch generating dozens of near-identical
-findings per commit. A wall is always either a missing repo knob or a detector
-bug; it is never "the repo is just bad."
-Complete when: per-commit finding counts and every wall are recorded.
-
-### 4. Sample and classify — the actual calibration
-
-For each detector with findings: sample about 10 (all of them if fewer),
-READ THE CODE at each site, and classify actionable vs noise. Two rules make
-this real calibration instead of theater:
-
-- Classify from the code, never from the finding text. A finding that sounds
-  plausible and a finding that is true are different things; the difference is
-  only visible at the cited file and line.
-- For every noise finding, name the ARCHETYPE (e.g. "type-only import
-  invisible to indexer", "delegation chain flagged as twin", "generic shared
-  helpers saturating similarity"). Archetypes are the deliverable: a noise
-  rate without archetypes cannot be fixed.
-
-Then give each detector a verdict: **keep** (precision acceptable), **retune**
-(name the threshold and the value), or **demote to advisory** for this repo.
-Complete when: every detector has sampled precision, named archetypes, and a
-verdict.
-
-### 5. Tune the knobs, file the bugs
-
-Apply repo-side fixes for what belongs to the repo, and file upstream for what
-belongs to the detector:
-
-- `.scipquery.json` suppressions — one per accepted finding, WITH a reason;
-  a reasonless suppression is hiding, not tuning.
-- `docs.snapshotPaths` — dated/archival docs that must never generate
-  doc-reference findings.
-- Coverage contracts — enumerations the gate should police.
-- `commandAnalysisBudget` — cap analysis honestly on very large indexes.
-- Detector bugs (noise archetypes no knob can express) go to the tool's
-  followup ledger with the archetype, a concrete example, and the sampled
-  rate. Never tune a threshold to hide an archetype — that trades visible
-  noise for invisible blindness.
-
-Complete when: the gate replay from stage 3 re-runs materially quieter, and
-every remaining finding class is either actionable, suppressed-with-reason, or
-filed upstream.
-
-## Failure Modes (each observed in a real calibration)
-
-- **Sampling too few.** One good finding does not make a detector precise;
-  one bad finding does not make it noise. Ten per detector is the floor.
-- **Classifying from the finding text.** The finding always sounds right —
-  it was generated to. Only the code knows.
-- **Tuning to green.** Raising a threshold until the noise disappears also
-  disappears the real findings. If the archetype is a detector bug, file it
-  and live with the noise until it is fixed.
-- **Trusting a clean run.** Zero findings on a detector can mean precision or
-  can mean the detector cannot see this repo's conventions at all (wrong
-  import style, unindexed language). Verify at least one known-true positive
-  per major detector — plant one if none exists.
-- **Calibrating the wrong tree.** Clones or worktrees for anything that
-  mutates; the target repo is read-only unless its owner said otherwise.
-
-## After Calibration
-
-The finding-outcome ledger keeps calibrating for you: once the repo uses
-diff-gate, per-detector precision is recomputed from real outcomes
-(`detectorPrecision` in `health --json`), and the committed event ledger
-makes those outcomes durable and queryable — `scip-query effectiveness
---since 30d --json` reports per-check caught/comparison-verified-fixed/
-suppressed/open/unverified counts, precision, and median days-to-fix from the
-individual records under `.scipquery/events/*.json`. Run diff-gate before and
-after the repair. If `HEAD` advances, use a clean worktree so scip-query can
-replay the stored comparison base instead of mistaking an empty diff for a fix.
-Re-run this protocol only after major detector upgrades or when the
-ledger's precision numbers drift from what you measured. Write the calibration report to
-`docs/validation/YYYY-MM-DD-external-calibration-<repo>.md` in the shape of
-the exemplars this skill was distilled from — battery table, retro-gate
-walls, per-detector verdicts, noise archetypes, caps and deviations.

package/skills/scip-calibrate/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "scip calibrate"
-  short_description: "Measure scip-query's detector precision on a repo before trusting scores or gating anyone."
-  default_prompt: "Run the scip-calibrate protocol against this repository: battery sweep, retro-gate replay, sample-and-classify each detector from the code, then tune repo knobs and file detector bugs."

package/skills/scip-claim-audit/SKILL.md

@@ -1,106 +0,0 @@
----
-name: scip-claim-audit
-description: Audit output-facing status claims for evidence with scip-query. Use to classify whether an "available", "verified", "safe", "PASS", or "complete" status word is derived from a real check, hedged as a candidate, or merely asserted without being probed.
-commands:
-  - template: "scip-query files <pattern>"
-    when: "Inventory: locate the renderer or status-producing module for a claim."
-  - template: "scip-query refs <symbol>"
-    when: "Classify: find every producer and consumer of a status-bearing function."
-  - template: "scip-query code <symbol>"
-    when: "Classify: read the producing function to see whether it computes or asserts."
-  - template: "scip-query trace <symbol>"
-    when: "Classify: definition plus every reference for a status field or constant."
-  - template: "scip-query capabilities --matrix --json"
-    when: "Spot-check: an already-known example of a fixed derived-status surface."
----
-
-# scip-claim-audit
-
-Use this skill to find agent-facing claims that sound verified but are not. A status word is **derived** when its producer computes it from a real probe, scan, or computation (a compiler run, a runtime capability probe, a graph traversal). It is **hedged** when the code or its label already says it is a candidate, heuristic, or unverified. It is **asserted** when the value is a constant, a hardcoded table entry, or a string literal presented with the same confidence as a derived value but backed by nothing the code actually checked at that call site. Asserted status words that are agent-facing and trust-bearing (an agent would route a decision — "use this evidence", "skip this check", "delete this" — based on the word) are the highest-severity class this skill exists to find.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | When |
-| --- | --- | --- |
-| `scip-query files <pattern>` | Find files matching a pattern | Inventory: locate the renderer or status-producing module for a claim. |
-| `scip-query refs <symbol>` | Find all files referencing a symbol | Classify: find every producer and consumer of a status-bearing function. |
-| `scip-query code <symbol>` | Read the source code for a symbol (bounded to its definition range) | Classify: read the producing function to see whether it computes or asserts. |
-| `scip-query trace <symbol>` | Trace a symbol: definition + all references | Classify: definition plus every reference for a status field or constant. |
-| `scip-query capabilities --matrix --json` | Report which evidence and verification capabilities are available in this project | Spot-check: an already-known example of a fixed derived-status surface. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Rules
-
-1. Ground every claim in the producing function's source, not its label or variable name alone — a variable named `verified` that is never checked against a real result is still asserted.
-2. Classify status, don't just list it: every status word in scope gets exactly one of derived / hedged / asserted.
-3. Severity follows the rubric: asserted + agent-facing + trust-bearing = high; asserted + internal-only or low-consequence = low; hedged is not a finding (the label already discloses uncertainty).
-4. A status that used to be asserted and now calls a real probe is fixed — say so and move on; do not re-report it.
-5. File findings as a table, not prose; a claim → producer → classification → fix format is the deliverable.
-
-## Workflow
-
-### 1. Inventory the status vocabulary
-
-Grep the target scope (a file, module, or command family) for user-visible or JSON-facing status words: `available`, `unavailable`, `partial`, `verified`, `safe`, `PASS`, `FAIL`, `complete`, `derived`, `asserted`. For each hit, note the file:line and the renderer or JSON field that surfaces it to an agent or user.
-
-```bash
-scip-query files <target-file-or-pattern>
-```
-
-This step is complete only when every status-bearing string or field in scope is listed with its surface (human output, `--json` field, or both).
-
-### 2. Classify each producer
-
-For each status word's producing function:
-
-```bash
-scip-query refs <producing-function>
-scip-query code <producing-function>
-scip-query trace <status-field-or-constant>
-```
-
-Read the function body. Classify:
-
-- **Derived**: the status is computed from a probe, scan, spawn result, file check, or graph query performed at or near that call site.
-- **Hedged**: the label, descriptor evidence tier, or surrounding text already marks the value as heuristic, candidate, or unverified.
-- **Asserted**: the value is a literal, a static table lookup, or a branch that returns a fixed status without invoking any check for that specific branch.
-
-This step is complete only when every producer has one of these three labels with the one line of source evidence that justifies it.
-
-### 3. File findings for every asserted status
-
-For each **asserted** status, apply the severity rubric (rule 3) and write:
-
-```markdown
-Claim: <status word and where it appears>
-Producer: <file:line function name>
-Classification: asserted
-Severity: high/low
-Fix: probe it (name the real check to add), generate it (derive from a registry/config that is itself kept honest), or soften the language (hedge the label to match what is actually known)
-```
-
-This step is complete only when every asserted status in scope has a filed finding with a fix direction, and every derived/hedged status is confirmed correct (not silently asserted behind a computed-looking name).
-
-### 4. Report
-
-Write the report under `docs/scip-query/` unless the user asked only for a conversational answer.
-
-```markdown
-Scope:
-Status words inventoried: N
-Classified: <d> derived / <h> hedged / <a> asserted — must sum to N; a gap is an unfinished audit
-
-Claim table:
-| Claim | Producer | Classification | Fix |
-| --- | --- | --- | --- |
-
-Fixed since last audit:
-- <claim> — now derived via <probe>, no longer a finding.
-```
-
-The audit is complete only when every status word in scope is classified and every asserted, trust-bearing claim has a filed finding.

package/skills/scip-claim-audit/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP Claim Audit"
-  short_description: "Classify output-facing status claims as derived, hedged, or asserted"
-  default_prompt: "Use scip-query to inventory output-facing status words in the target scope, classify each producer as derived, hedged, or asserted, and file findings for asserted trust-bearing claims."

package/skills/scip-cleanup-audit/SKILL.md

@@ -1,126 +0,0 @@
----
-name: scip-cleanup-audit
-description: Audit and rank scip-query cleanup signals without editing code. Use for health reports, de-bloat reports, recent AI residue audits, score-framed cleanup queues, confirming raw findings, or preparing a cleanup plan.
-commands:
-  - template: "scip-query health --json"
-    when: "Establish evidence: composite score and prioritized action list."
-  - template: "scip-query cleanup-plan --verify --json"
-    when: "Sweep signals: compiler-verified deletion plan, batched."
-  - template: "scip-query duplicate-bodies --json --full"
-    when: "Sweep signals: exact duplicate small-body candidates."
-  - template: "scip-query recent-duplicates --json --full"
-    when: "Sweep signals: recent code that re-implements established code."
-  - template: "scip-query incomplete-migration --json --full"
-    when: "Sweep signals: partially-completed extractions."
-  - template: "scip-query doc-drift --json --full"
-    when: "Sweep signals: stale docs referencing changed code."
----
-
-# scip-cleanup-audit
-
-Use this skill to turn raw scip-query signals into a confirmed cleanup queue. Do not edit application code in this skill.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | When |
-| --- | --- | --- |
-| `scip-query health --json` | Composite codebase health report with prioritized action list | Establish evidence: composite score and prioritized action list. |
-| `scip-query cleanup-plan --verify --json` | Ordered, batched deletion plan: graph-fact dead code plus the cascade candidates it unlocks | Sweep signals: compiler-verified deletion plan, batched. |
-| `scip-query duplicate-bodies --json --full` | Find exact duplicate small-body candidates across files | Sweep signals: exact duplicate small-body candidates. |
-| `scip-query recent-duplicates --json --full` | Directional duplicate candidates: recent code that re-implements established callable, React, or Vue code | Sweep signals: recent code that re-implements established code. |
-| `scip-query incomplete-migration --json --full` | Partially-completed extraction candidates: new helpers in the diff wired into some sites while similar un-migrated sites remain | Sweep signals: partially-completed extractions. |
-| `scip-query doc-drift --json --full` | Stale-doc candidates: code the doc references or co-changed with kept changing after the doc stopped | Sweep signals: stale docs referencing changed code. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Modes
-
-- Whole-repo audit: rank all cleanup signals.
-- Recent AI residue: focus on echoes, twins, incomplete migrations, speculative params, stale agent-facing docs, and hidden couplings.
-- Score-framed audit: explain health score deductions and the safest first batch.
-
-## Workflow
-
-### 1. Establish evidence
-
-```bash
-scip-query doctor
-scip-query status --capabilities
-scip-query health --json
-scip-query capabilities --json
-scip-query config-validate --json
-```
-
-This step is complete only when unavailable capabilities are recorded as unavailable.
-
-### 2. Sweep signals
-
-Run every relevant class, or record why it is unavailable:
-
-```bash
-scip-query cleanup-plan --verify --json
-scip-query duplicate-bodies --json --full
-scip-query recent-duplicates --json --full
-scip-query incomplete-migration --json --full
-scip-query unused-params --json --full
-scip-query passthrough-candidates --json --full
-scip-query dead --json --full
-scip-query isolated --json --full
-scip-query cycles
-scip-query co-change --json --full
-scip-query doc-drift --json --full
-```
-
-For frontend repos, add the React or Vue duplicate, hook/composable, and large-component/view commands.
-
-Optional deep-dive (near-zero precision on codebases with intentional layering/ambient types — run only when the sweep above is exhausted, and treat every hit as a lead to confirm, not a finding):
-
-```bash
-scip-query stale-abstractions --json --full
-scip-query wrapper-candidates --json --full
-```
-
-### 3. Confirm candidates
-
-For each high-priority candidate, inspect source and graph evidence:
-
-```bash
-scip-query code <symbol-or-file>
-scip-query refs <symbol>
-scip-query fan-in <symbol>
-scip-query fan-out <symbol-or-file>
-scip-query affected <symbol> --json
-scip-query change-surface <file> --json --full
-scip-query similar <symbolA> <symbolB> --plan
-scip-query co-change <file> --json --full
-```
-
-Classify every candidate as `confirmed fix target`, `intentional design`, `false positive`, or `blocked`.
-
-A deletion is this skill's scrutiny-ending verdict, so a `confirmed fix target` that deletes code must survive refutation first. Run the known blind-spot checks and record them on the entry: `rg` for the symbol name as a string (dynamic dispatch, config keys, serialized references, CLI/doc text), and the cross-package barrel re-export gap (the one shape `dead` self-labels `unconfirmed`). Record `refutation: survived — <checks run>` on the entry, or reclassify it; the note stays either way.
-
-### 4. Report
-
-```markdown
-Health score: N/100
-
-Classification counts: <n> confirmed / <i> intentional / <fp> false positive / <b> blocked (must cover every collected signal)
-
-Confirmed items:
-- [priority] finding - evidence - first safe action
-
-Unconfirmed signals:
-- signal - evidence still needed
-
-Unavailable or blocked checks:
-- check - reason
-
-Recommended first cleanup batch:
-- batch - why safe now
-```
-
-The audit is complete only when each collected signal is classified and the next action is visible.

package/skills/scip-cleanup-audit/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP Cleanup Audit"
-  short_description: "Confirm and rank cleanup, de-bloat, and recent AI residue signals without editing"
-  default_prompt: "Audit scip-query cleanup signals, classify findings with evidence, and report the safest next cleanup batch."

package/skills/scip-cleanup-improve/SKILL.md

@@ -1,84 +0,0 @@
----
-name: scip-cleanup-improve
-description: Improve scip-query health autonomously with verified cleanup. Use when the user asks to fix cleanup findings, raise health, keep cleaning, continue after setup, or work until no safe confirmed cleanup remains.
-commands:
-  - template: "scip-query health --json"
-    when: "Before editing: report current score and remaining signals."
-  - template: "scip-query cleanup-plan --verify --json"
-    when: "Loop: confirm the next compiler-verified deletion batch."
-  - template: "scip-query cleanup-apply --verified --batch <n>"
-    when: "Loop: apply one verified deletion batch."
-  - template: "scip-query duplicate-bodies --json --full"
-    when: "Priority: exact duplicate small-body echoes to consolidate."
-  - template: "scip-query incomplete-migration --json --full"
-    when: "Priority: un-migrated call sites left behind by a new helper."
----
-
-# scip-cleanup-improve
-
-Use this skill for bounded autonomous cleanup. The target is not score chasing; the target is fixing confirmed issues that make the codebase harder to understand, verify, or change.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | When |
-| --- | --- | --- |
-| `scip-query health --json` | Composite codebase health report with prioritized action list | Before editing: report current score and remaining signals. |
-| `scip-query cleanup-plan --verify --json` | Ordered, batched deletion plan: graph-fact dead code plus the cascade candidates it unlocks | Loop: confirm the next compiler-verified deletion batch. |
-| `scip-query cleanup-apply --verified --batch <n>` | Apply a compiler-verified cleanup-plan batch to the working tree | Loop: apply one verified deletion batch. |
-| `scip-query duplicate-bodies --json --full` | Find exact duplicate small-body candidates across files | Priority: exact duplicate small-body echoes to consolidate. |
-| `scip-query incomplete-migration --json --full` | Partially-completed extraction candidates: new helpers in the diff wired into some sites while similar un-migrated sites remain | Priority: un-migrated call sites left behind by a new helper. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Rules
-
-1. Start with `scip-cleanup-audit` evidence or run the audit sweep yourself.
-2. Report current health and the first confirmed batch before editing.
-3. Prioritize high-confidence, low-blast-radius, clearly verifiable fixes.
-4. Apply one small batch at a time.
-5. After a cleanup pass, run `scip-query health --write-baseline` to snapshot finding identities, then compare with `scip-query health --baseline` at the start of the next pass.
-
-## Priority
-
-1. Compiler-verified deletion batches.
-2. Incomplete migrations and recent duplicate echoes.
-3. Unused params, unused imports, dead symbols, and isolated symbols.
-4. Broken or stale docs, config validation issues, and missing co-change partners.
-5. Thin wrappers, passthroughs, stale abstractions, and speculative generality.
-6. Frontend component/hook/composable duplication and large-view pressure.
-7. Directory architecture and maintainability repairs only when evidence is strong and the blast radius is bounded.
-
-## Loop
-
-Before editing:
-
-```markdown
-Health score: N/100
-First confirmed batch:
-- finding - evidence - planned fix - verification
-Remaining signals:
-- signal - status
-```
-
-Then repeat:
-
-1. Apply one verified deletion batch or one small targeted refactor.
-2. Run the narrow project check for touched behavior.
-3. Run `scip-query health --json`.
-4. Invoke `scip-verify`.
-5. If `docs/scip-query/health-dossier.md` exists (or a custom `--dossier-dir` was used), refresh it by rerunning `scip-query setup --json` (add the same `--dossier-dir` if one was used).
-6. Pick the next highest-priority confirmed item.
-
-Use `scip-query cleanup-apply --verified --batch <n>` for verified deletion batches. Use `--all` only with explicit user approval.
-
-## Stop
-
-Stop when only intentional, false-positive, blocked, or unconfirmed items remain; when the next improvement needs a product/API/ownership decision; when a missing toolchain prevents trustworthy verification; or when further work would be broad redesign rather than bounded cleanup.
-
-## Closeout
-
-Report starting and final health scores, batches applied, important files changed, verification commands, remaining accepted or blocked items, and highest-value follow-up.

package/skills/scip-cleanup-improve/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP Cleanup Improve"
-  short_description: "Fix confirmed cleanup findings batch by batch with verification"
-  default_prompt: "Improve scip-query health by fixing confirmed cleanup findings one verified batch at a time."