scip-query 0.24.0 → 0.26.0

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

@@ -1,113 +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.
-metadata:
-  commands:
-    - template: 'scip-query search <text>'
-      when: 'Inventory: locate every status word and the renderer or JSON field that surfaces it.'
-    - template: 'scip-query refs <symbol>'
-      when: 'Classify: find every producer and consumer of a status-bearing function.'
-    - template: 'scip-query code <selector>'
-      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'
-      when: 'Spot-check: a known derived-status surface to calibrate what derived looks like here.'
----
-
-# scip-claim-audit
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Command and question manual
-
-| Command syntax | Question it answers |
-| --- | --- |
-| `scip-query search <text>` | Inventory: locate every status word and the renderer or JSON field that surfaces it. |
-| `scip-query refs <symbol>` | Classify: find every producer and consumer of a status-bearing function. |
-| `scip-query code <selector>` | Classify: read the producing function to see whether it computes or asserts. |
-| `scip-query trace <symbol>` | Classify: definition plus every reference for a status field or constant. |
-| `scip-query capabilities --matrix` | Spot-check: a known derived-status surface to calibrate what derived looks like here. |
-
-These commands are controls, not a checklist. Use every capability needed by the task, but make each query answer a distinct question. There is no required sequence or query limit. Run a command's `--help` when you need a flag not shown in its template.
-<!-- END GENERATED SKILL COMMANDS -->
-
-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, meaning 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.
-
-`$scip-integrity-audit` asks whether checkers can fail. This skill asks whether the words the system prints about itself were ever computed. Run this one over a status surface; run that one over the checkers behind it.
-
-## 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, do not just list it: every status word in scope gets exactly one of derived, hedged, or asserted.
-3. Severity follows the rubric: asserted plus agent-facing plus trust-bearing is high; asserted plus internal-only or low-consequence is low; hedged is not a finding, because 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. Claim, producer, classification, fix is the deliverable.
-
-## Workflow
-
-### 1. Inventory the status vocabulary
-
-Search 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 search verified -s <scope>
-scip-query search PASS -s <scope>
-```
-
-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, 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.
-
-Use `scip-query capabilities --matrix` as a spot-check: it is a known derived-status surface, useful for calibrating what "derived" looks like in this codebase before judging ambiguous cases.
-
-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 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 or 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 or hedged status is confirmed correct rather than 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-claim-audit 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-probe-reachability/SKILL.md

@@ -1,93 +0,0 @@
----
-name: scip-probe-reachability
-description: Prove whether a parser or AST branch is actually reachable by running the real parser on minimal inputs. Use for unreachable or dead node-type or shape branches, wrong node-type strings, tree-sitter grammar mismatches, or any conditional written for an AST or parser output that has never been checked against the real parser.
-metadata:
-  commands:
-    - template: 'scip-query outline <file> --signatures'
-      when: 'Enumerate branches: symbol tree with signatures for the target file.'
-    - template: 'scip-query code <selector>'
-      when: "Enumerate branches: read each branch condition's exact node-type check."
-    - template: 'scip-query trace <symbol>'
-      when: "Enumerate branches: confirm the function's callers and entry point."
----
-
-# scip-probe-reachability
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Command and question manual
-
-| Command syntax | Question it answers |
-| --- | --- |
-| `scip-query outline <file> --signatures` | Enumerate branches: symbol tree with signatures for the target file. |
-| `scip-query code <selector>` | Enumerate branches: read each branch condition's exact node-type check. |
-| `scip-query trace <symbol>` | Enumerate branches: confirm the function's callers and entry point. |
-
-These commands are controls, not a checklist. Use every capability needed by the task, but make each query answer a distinct question. There is no required sequence or query limit. Run a command's `--help` when you need a flag not shown in its template.
-<!-- END GENERATED SKILL COMMANDS -->
-
-Use this skill for code that branches on a parser or AST node's type or shape (`node.type === '...'`, a grammar-specific tag, a regex over token shape) where nobody has verified the real parser ever produces that type or shape. A branch written from documentation, memory, or a similar grammar in another language can be permanently dead: it looks correct, compiles, and is never exercised by a single test, because the input that should reach it never reaches it under the actual parser.
-
-## Rules
-
-1. Never trust a branch condition by reading it; run the real parser on an input constructed to hit it.
-2. Write scratch probe scripts only under the session scratchpad, never inside the repository. They are throwaway evidence, not product code.
-3. Never create a git worktree and never symlink `node_modules` for this skill's probes. Import the parser module directly (from `src/` via a TypeScript runner, or from the built package) in a standalone script that needs no repo-root install step.
-4. A branch is a finding whether it is truly unreachable (dead code) or reachable but under a different node-type string than the code checks (a silent misclassification, which is worse than dead code because it fails without raising anything).
-5. Completion requires every node-type or shape branch in the target function to have either a reached probe or a filed finding. Partial coverage is not done.
-
-## Workflow
-
-### 1. Enumerate branch conditions
-
-```bash
-scip-query outline <target-file> --signatures
-scip-query code <target-function>
-scip-query trace <target-function>
-```
-
-List every conditional that tests a node's `type`, tag name, or shape (an `if` or `else if` chain over `node.type === '...'`, a `switch` on a grammar tag, or a regex matched against node text standing in for a type check). Record the exact string or pattern each branch expects.
-
-This step is complete only when every node-type or shape branch in the target function is listed with its file:line and the exact condition text.
-
-### 2. Construct a minimal input per branch
-
-For each branch, write the smallest source snippet in the target language that should, by the language's grammar, produce a node of that type or shape at that point in the tree. Prefer one snippet per branch; note when a single snippet is expected to exercise more than one branch (siblings in a walk).
-
-This step is complete only when every branch has a candidate input snippet.
-
-### 3. Run the real parser
-
-Write one scratch script under the session scratchpad that imports the actual parser module used by the target code, not a reimplementation and not a mental model of the grammar, and, for each candidate snippet:
-
-1. Parses it.
-2. Walks the resulting tree and collects every node type actually produced.
-3. Reports whether the branch's expected type or shape appears anywhere in that set.
-
-Run the script (for example `npx vite-node <scratch-script>` from the repo root, or a plain `node` script importing the built package) and record reached or unreached per branch.
-
-This step is complete only when every branch from step 1 has a recorded reached or unreached result from an actual parser run, not an inference.
-
-### 4. File findings for unreached branches
-
-For each unreached branch, determine and record which of these it is:
-
-- **Dead branch**: the grammar never produces this node type or shape anywhere reachable from valid source in this language; the branch is unreachable code. Fix: delete it, or replace it with the branch that actually covers the intended case, found by inspecting the node types the parser did produce for the candidate input.
-- **Wrong node-type string**: the intended case is real and common, but the branch checks the wrong string (a rename in the grammar, a typo, or a mismatch borrowed from a different language or version). Fix: correct the string to what step 3 actually observed.
-
-This step is complete only when every unreached branch has one of these two labels and a fix direction.
-
-### 5. Report
-
-```markdown
-Target: <file:function>
-
-Branches:
-| Branch condition | Candidate input | Reached? | Finding |
-| --- | --- | --- | --- |
-
-Findings:
-
-- <branch>: dead branch | wrong node-type string; fix: <direction>
-```
-
-Completion requires every branch from step 1 to appear in the table with a reached or unreached result.

package/skills/scip-probe-reachability/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: 'SCIP Probe Reachability'
-  short_description: 'Prove parser and AST branches are reachable by running the real parser'
-  default_prompt: 'Use $scip-probe-reachability to enumerate the node-type or shape branches in the target parser function, construct a minimal input per branch, run the real parser on each in a scratch script, and file findings for every unreached branch.'

package/skills/scip-root-cause/SKILL.md

@@ -1,160 +0,0 @@
----
-name: scip-root-cause
-description: Diagnose the design flaw behind a family of related bugs with scip-query evidence. Use when similar bugs keep recurring, the same subsystem keeps needing patches, or the user lists fixed or observed bugs and asks what is really wrong; produces a falsifiable flaw diagnosis, a latent-instance hunt, and the least invasive remedy that kills the class.
-metadata:
-  commands:
-    - template: 'scip-query trace <symbol>'
-      when: 'Trace one bug mechanism: definition plus every reference of the symbol that broke the invariant.'
-    - template: 'scip-query code <selector>'
-      when: 'Read the exact body at a fix site or a suspected latent instance.'
-    - template: 'scip-query evidence --symbol <symbol> --edge dataflow --direction both --depth <n> --max-edges <n>'
-      when: 'Follow where a violated value comes from and where it goes.'
-    - template: 'scip-query co-change <file>'
-      when: 'Find fix-site partners from git history that the user may have forgotten.'
-    - template: 'scip-query system <scope>'
-      when: 'Define the owning system: its files, exports, and dependencies.'
-    - template: 'scip-query surface <scope>'
-      when: 'See what consumers actually rely on from the owning system.'
-    - template: 'scip-query similar <symbol> --full'
-      when: 'Hunt latent instances: callables that do the same work as a fixed symbol.'
-    - template: 'scip-query refs <symbol>'
-      when: 'Hunt latent instances: every site that touches the invariant carrier.'
-    - template: 'scip-query affected <symbol>'
-      when: 'Bound the blast radius before proposing any remedy above rung 1.'
----
-
-# scip-root-cause
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Command and question manual
-
-| Command syntax | Question it answers |
-| --- | --- |
-| `scip-query trace <symbol>` | Trace one bug mechanism: definition plus every reference of the symbol that broke the invariant. |
-| `scip-query code <selector>` | Read the exact body at a fix site or a suspected latent instance. |
-| `scip-query evidence --symbol <symbol> --edge dataflow --direction both --depth <n> --max-edges <n>` | Follow where a violated value comes from and where it goes. |
-| `scip-query co-change <file>` | Find fix-site partners from git history that the user may have forgotten. |
-| `scip-query system <scope>` | Define the owning system: its files, exports, and dependencies. |
-| `scip-query surface <scope>` | See what consumers actually rely on from the owning system. |
-| `scip-query similar <symbol> --full` | Hunt latent instances: callables that do the same work as a fixed symbol. |
-| `scip-query refs <symbol>` | Hunt latent instances: every site that touches the invariant carrier. |
-| `scip-query affected <symbol>` | Bound the blast radius before proposing any remedy above rung 1. |
-
-These commands are controls, not a checklist. Use every capability needed by the task, but make each query answer a distinct question. There is no required sequence or query limit. Run a command's `--help` when you need a flag not shown in its template.
-<!-- END GENERATED SKILL COMMANDS -->
-
-Use this skill to move from a family of related bugs to the design flaw that produces them, and to the least invasive remedy that eliminates the class. Ordinary debugging takes one failure to one minimal fix. `$principal-maintainability-review` finds structural smells without bug evidence. This skill starts from the evidence that patching has not worked, because the same kind of bug keeps coming back, and asks what the system's design gets wrong.
-
-## Terms
-
-A bug family is a set of failures whose mechanisms violate the same invariant. What makes it a family rather than a coincidence is that one stated flaw derives every member, so fixing members one at a time treats symptoms of a shared cause.
-
-A design flaw is a mismatch between what a system's design assumes and what its real responsibilities require. What makes it the root cause is that it is the earliest fact from which every family member's mechanism follows, so removing it removes the class.
-
-Retrodiction is deriving each already-known bug from the hypothesized flaw. What makes it a test is that a family member the flaw cannot derive either shrinks the family or kills the hypothesis.
-
-A latent instance is a not-yet-reported bug the flaw predicts must exist in unfixed code. What makes it decisive is that it is checkable now. Finding one confirms the diagnosis and becomes a fix target. An honest hunt that finds none weakens the diagnosis and must be reported as weakening it.
-
-The remedy ladder is the ordered set of interventions from least to most invasive. What makes the order binding is that each rung is only justified when a constructed family member survives the rung below it.
-
-## Rules
-
-1. Every bug in the family gets a mechanism traced to source, not a symptom description: which invariant broke, where, and what the fix did. Sources: fix commits (`git log`, `git show`) plus `trace`, `code`, and `evidence` dataflow.
-2. The flaw hypothesis must be falsifiable and stated as a design claim: "the design assumes X, but the system's responsibilities include Y." Never a narrative about unlucky bugs.
-3. State at least two rivals and kill them with evidence: unrelated coincidences, caller misuse rather than design, one missed edge case rather than a structural flaw.
-4. The hypothesis must retrodict every family member and predict at least one latent instance, and the latent-instance hunt must be executed with `similar`, `refs` over the invariant's carriers, or a constructed probe. It is never argued.
-5. Choose the lowest remedy rung that kills the whole class, retrodicted and latent members both. Climb a rung only when a constructed family member survives the rung below, and keep that counterexample in the record.
-6. Root-cause stories are the most rationalization-prone artifact in software. Prefer delegating the attack on the diagnosis and the remedy to a fresh subagent given only the family table, system definition, and hypothesis, briefed to win by refuting. Solo fallback: write the rival hypotheses and the latent-instance predictions before reading any more code.
-7. The verdict is derived with counts, and the diagnosis hands off to `$scip-plan` for implementation. This skill does not edit application code.
-
-## Workflow
-
-### 1. Assemble the bug family
-
-For each reported or fixed bug, fill one row:
-
-```markdown
-| Bug | Symptom | Mechanism (file:symbol) | Invariant violated | Fix applied | Source |
-| --- | ------- | ----------------------- | ------------------ | ----------- | ------ |
-```
-
-Evidence: the user's description, fix commits (`git log --follow`, `git show`), `scip-query trace` and `scip-query code` on the mechanism symbols, `scip-query co-change` on fix sites to find members the user forgot.
-
-This step is complete only when every row has a source-traced mechanism and a named invariant. A bug whose mechanism cannot be traced is listed as `unconfirmed member`, not silently included.
-
-### 2. Define the system
-
-Define the system that owns the family: its wider class, then the essential responsibility that explains its other traits in this codebase, with referents from `scip-query system <scope>` and `scip-query surface <scope>`. Then list the design's load-bearing assumptions as the code actually embodies them, not as the README states them, each with a `Source:` citation.
-
-This step is complete only when the system's real responsibilities and embodied assumptions are stated with citations.
-
-### 3. Hypothesize the flaw and its rivals
-
-State the flaw as a falsifiable design claim:
-
-```markdown
-Flaw hypothesis: the design assumes <X> (Source: <citation>), but the system's
-responsibilities include <Y> (Source: <citation>); every family member is an
-instance of the X and Y collision.
-
-Rivals:
-
-- R1. Coincidence: the members have unrelated causes. Killed by: <evidence> | ALIVE
-- R2. Misuse: callers hold the bug, the design is sound. Killed by: <evidence> | ALIVE
-- R3. <next-most-plausible>. Killed by: <evidence> | ALIVE
-```
-
-A rival still marked `ALIVE` at the end of the workflow caps the diagnosis at `CANDIDATE`, not `CONFIRMED`.
-
-### 4. Retrodict and predict
-
-Retrodiction: derive each family-table row from the flaw in one sentence each. A member that cannot be derived is removed from the family (say so) or refutes the hypothesis (start over).
-
-Prediction: the flaw implies unfixed instances exist. Name where they must be, then hunt:
-
-```bash
-scip-query similar <fixed-symbol> --full
-scip-query refs <invariant-carrier>
-scip-query evidence --symbol <invariant-carrier> --edge dataflow --direction outgoing --depth 2 --max-edges 80
-```
-
-plus a constructed probe when the claim is cheaply executable. Record each prediction with an executed result:
-
-```markdown
-- L1. <predicted latent instance> -> FOUND at <file:line> (new fix target) | NOT FOUND after <hunt executed>
-```
-
-This step is complete only when every family member is retrodicted and every prediction has an executed hunt result. Zero latent instances found is a reportable weakness of the diagnosis, not a detail to omit.
-
-### 5. Choose the lowest rung
-
-The remedy ladder, in order:
-
-1. **Enforce the invariant at a boundary** with a type, guard, constraint, lint, or trigger, without moving code.
-2. **Consolidate the responsibility into one owner** so the scattered decision gets one named mechanism.
-3. **Redesign the core behind its existing interface** with consumers untouched.
-4. **Redesign the interfaces** as a last resort; consumers migrate.
-
-For the chosen rung, run the attack: construct a family member, retrodicted or latent, that survives the rung. If one survives, keep the counterexample in the record and climb one rung. Check blast radius with `scip-query affected` before proposing any rung above 1. For protocol- or lifecycle-shaped flaws whose remedy must hold across interleavings, note the escalation path to a formal model with `scip-query tla`.
-
-This step is complete only when the chosen rung has an attack record showing no family member survives it, and every rejected lower rung keeps its surviving counterexample.
-
-### 6. Report and hand off
-
-```markdown
-## Root-cause diagnosis
-
-System: <definition with referents>
-Bug family: <n> members traced, <u> unconfirmed
-Flaw: <the design claim>: CONFIRMED | CANDIDATE (rival <id> alive)
-Rivals: <r> stated, <k> killed with evidence
-Retrodiction: <n>/<n> members derived
-Latent instances: <p> predicted, <f> found (each a fix target), hunts executed
-Remedy: rung <1-4>: <the intervention>; lower rungs rejected by <counterexamples>
-Blast radius: <affected summary>
-Escalation: <none | formal model for <property>>
-```
-
-Hand the diagnosis to `$scip-plan`: the flaw and invariants become its definitions and invariants, the family table and hunt results become premises, and the surviving-counterexample record seeds its attack pass.
-
-The diagnosis is complete only when the verdict line carries the counts and every count is backed by an entry in the record above it.

package/skills/scip-root-cause/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: 'SCIP Root Cause'
-  short_description: 'Diagnose the design flaw behind a family of recurring bugs'
-  default_prompt: 'Use $scip-root-cause to trace this family of related bugs to the design flaw that produces them: retrodict every member, hunt the latent instances the flaw predicts, and propose the least invasive remedy that eliminates the class.'

package/skills/scip-system-compression/SKILL.md

@@ -1,252 +0,0 @@
----
-name: scip-system-compression
-description: Compress systems with scip-query evidence. Use to zoom out, simplify architecture, eliminate layers, consolidate commands, scripts, or helpers, find the deeper role behind unlike-looking code, build a compression atlas before a large cleanup, or execute an ordered simplification without rework.
-metadata:
-  commands:
-    - template: 'scip-query system <scope>'
-      when: 'Map a module or directory: files, exported symbols, dependencies in and out.'
-    - template: 'scip-query surface <scope>'
-      when: 'See which symbols consumers actually use from the scope.'
-    - template: 'scip-query outline <file>'
-      when: 'Inventory one file before assigning its units to roles.'
-    - template: 'scip-query trace <symbol>'
-      when: 'Prove a key symbol: definition plus every reference.'
-    - template: 'scip-query call-graph <symbol>'
-      when: 'Prove a key symbol: callers and callees along its execution shape.'
-    - template: 'scip-query affected <symbol>'
-      when: 'Measure blast radius before choosing a compression model.'
-    - template: 'scip-query change-surface <file>'
-      when: 'Measure exports, consumers, and risk for a file a cluster will touch.'
-    - template: 'scip-query similar --cross-file-only'
-      when: 'Signal: functions with overlapping callee sets across files.'
-    - template: 'scip-query similar-files'
-      when: 'Signal: files with overlapping dependency profiles.'
-    - template: 'scip-query similar-chains'
-      when: 'Signal: parallel end-to-end flows that diverge at a few points.'
-    - template: 'scip-query extract-candidates'
-      when: 'Signal: large functions with isolated callee clusters.'
-    - template: 'scip-query wrapper-candidates'
-      when: 'Signal: single-consumer indirection that a compression may absorb.'
-    - template: 'scip-query passthrough-candidates'
-      when: 'Signal: pure forwarding functions.'
-    - template: 'scip-query stale-abstractions'
-      when: 'Signal: types and classes with zero or one consumer.'
-    - template: 'scip-query drift --architecture'
-      when: 'Signal: files deviating from sibling conventions and declared boundary violations.'
-    - template: 'scip-query diff-impact'
-      when: 'Audit after each implemented cluster: changed symbols and downstream consumers.'
-    - template: 'scip-query architecture'
-      when: 'Audit after each implemented cluster: declared boundaries still hold.'
----
-
-# SCIP System Compression
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Command and question manual
-
-| Command syntax | Question it answers |
-| --- | --- |
-| `scip-query system <scope>` | Map a module or directory: files, exported symbols, dependencies in and out. |
-| `scip-query surface <scope>` | See which symbols consumers actually use from the scope. |
-| `scip-query outline <file>` | Inventory one file before assigning its units to roles. |
-| `scip-query trace <symbol>` | Prove a key symbol: definition plus every reference. |
-| `scip-query call-graph <symbol>` | Prove a key symbol: callers and callees along its execution shape. |
-| `scip-query affected <symbol>` | Measure blast radius before choosing a compression model. |
-| `scip-query change-surface <file>` | Measure exports, consumers, and risk for a file a cluster will touch. |
-| `scip-query similar --cross-file-only` | Signal: functions with overlapping callee sets across files. |
-| `scip-query similar-files` | Signal: files with overlapping dependency profiles. |
-| `scip-query similar-chains` | Signal: parallel end-to-end flows that diverge at a few points. |
-| `scip-query extract-candidates` | Signal: large functions with isolated callee clusters. |
-| `scip-query wrapper-candidates` | Signal: single-consumer indirection that a compression may absorb. |
-| `scip-query passthrough-candidates` | Signal: pure forwarding functions. |
-| `scip-query stale-abstractions` | Signal: types and classes with zero or one consumer. |
-| `scip-query drift --architecture` | Signal: files deviating from sibling conventions and declared boundary violations. |
-| `scip-query diff-impact` | Audit after each implemented cluster: changed symbols and downstream consumers. |
-| `scip-query architecture` | Audit after each implemented cluster: declared boundaries still hold. |
-
-These commands are controls, not a checklist. Use every capability needed by the task, but make each query answer a distinct question. There is no required sequence or query limit. Run a command's `--help` when you need a flag not shown in its template.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Purpose
-
-Use this skill to move between concrete scip-query code facts and higher-level architectural ideas. The goal is not to find similar code. The goal is to find many code units that are doing the same kind of work in principle, build a whole-scope map of the compression opportunities before editing, then propose or execute fewer mechanisms that preserve the same behavior.
-
-This is not a score-improvement workflow. Do not optimize for health scores, issue counts, or detector counts. Use diagnostic commands only to find evidence. Judge success by whether the code now has fewer, clearer mechanisms that still preserve the required behavior.
-
-`$principal-maintainability-review` ranks smells in one scope. This skill owns the atlas: the whole-system inventory, ordering, and execution of a compression that spans several slices.
-
-## Core Terms
-
-System compression names an architecture investigation over real code units such as files, symbols, command handlers, query modules, helper layers, renderers, and tests. It identifies when several concrete mechanisms are separate expressions of one deeper role and replaces them, conceptually or in code, with fewer mechanisms that still explain and produce the same observed behavior.
-
-An abstraction ladder is an ordered set of descriptions of the same codebase facts, starting with files and symbols, rising through workflows and roles, and ending in principles that explain why those workflows exist. It lets the agent change the amount of detail without losing contact with the original code.
-
-A role is the job a code unit performs in a workflow, such as translating user input, choosing a policy, building a graph, running an analysis, formatting output, or preserving a public API. The role is identified by the effect the unit has on data, control flow, or users, not by the names or syntax it happens to use.
-
-A principle is a general codebase fact that explains many role-level observations at once. "CLI commands parse options, call a pure query, and render rows" is a principle if it predicts the structure of several commands and explains why their concrete handlers look related.
-
-A mechanism is the actual code structure that makes behavior happen: functions, classes, tables, registries, scripts, config files, tests, command builders, dispatch maps, SQL fragments, and module boundaries.
-
-An execution shape is the recurring control-flow form behind several concrete units, such as "open database, run pure query, render rows." Use shapes to group unlike-looking code by what must happen in what order.
-
-A compression atlas is a written work map over the selected scope. It records real files, symbols, roles, opportunities, dispositions, ordering constraints, and validation commands so the agent acts from a whole-system view instead of repeatedly rediscovering local chances to simplify. Load [`references/compression-atlas.md`](references/compression-atlas.md) for the template.
-
-An opportunity ledger is the atlas table that assigns each discovered opportunity exactly one disposition, which prevents already-understood work from reappearing as a "new" idea after nearby code changes.
-
-A deferred register is the written list of opportunities deliberately left out of the current implementation. Each entry names the opportunity, the verified blocking fact, and the concrete condition that would make it eligible again.
-
-A rework loop is repeated editing of the same file, symbol family, or role because an earlier pass handled one visible symptom without accounting for the wider opportunity set and dependency order. The atlas exists to prevent it.
-
-## Workflow
-
-### 1. Bound the inquiry
-
-Identify the target: whole repository, module, command family, feature, or suspected mess. If the scope is vague, start broad and state the assumed scope before running commands.
-
-Prefer a question shaped like:
-
-```text
-What is this part of the system trying to do, what roles recur across it, and what smaller mechanism could produce the same behavior?
-```
-
-Do not start by proposing a refactor. Start by discovering the current system. Do not edit code until the atlas accounts for all obvious subsystem-level opportunities in the chosen scope.
-
-### 2. Build a concrete evidence base
-
-```bash
-scip-query system <scope>
-scip-query surface <scope>
-scip-query outline <file>
-scip-query trace <symbol>
-scip-query call-graph <symbol>
-scip-query affected <symbol>
-scip-query change-surface <file>
-```
-
-Compression signals, used as starting points rather than boundaries:
-
-```bash
-scip-query similar --cross-file-only
-scip-query similar-files
-scip-query similar-chains
-scip-query extract-candidates
-scip-query wrapper-candidates
-scip-query passthrough-candidates
-scip-query stale-abstractions
-scip-query drift --architecture
-```
-
-If two units have the same role but different code, keep investigating. Use the first pass to decide which subsystems deserve deeper ladders, not to choose the first refactor.
-
-### 3. Climb the abstraction ladder
-
-For each important subsystem, write a short ladder:
-
-```text
-Concrete: files, symbols, commands, tests, data stores
-Workflow: user or caller path through those units
-Roles: what each unit contributes to the workflow
-Principle: the general rule that explains several roles together
-Pressure: why the current mechanisms feel too numerous, indirect, or inconsistent
-```
-
-Every role-level or principle-level sentence must be traceable back to files, symbols, call graphs, references, docs, tests, or observed command output.
-
-When the target is a command surface, API surface, worker set, or script family, add an execution-shape inventory:
-
-```text
-Shape: name the lifecycle in one sentence
-Units: commands, files, or functions that follow it
-Required order: setup -> policy -> core operation -> rendering or effects
-Variant points: inputs, query function, budget, renderer, error behavior
-Non-members: similar-looking units that must stay separate, and why
-```
-
-If most units fit a few shapes, the next abstraction should usually encode those shapes rather than only moving code into themed files. Every ladder's pressure becomes a ledger item; a pressure that never becomes a ledger item is only a note.
-
-### 4. Find same-in-principle repetition
-
-Look for repeated roles across unlike code:
-
-- handlers that all parse options, open a resource, call one query, render sections, and close
-- help text, README text, command metadata, and tests that all describe the same surface
-- query modules that each build equivalent structures before applying different filters
-- language- or kind-specific branches that share one dispatch shape
-- several checks that carry separate definitions of the same predicate, such as liveness or reachability
-- scripts that perform separate concrete steps of one lifecycle
-- wrappers, pass-throughs, and adapters that preserve an old surface after the real concept moved
-
-Ask: "What are these all instances of?" Then: "What single mechanism would make those instances natural?" Cluster opportunities by root cause, not by surface trait. Prefer clusters such as "one reachability policy" or "metadata renders command docs" over "files in src/queries" or "similar function names." Load [`references/compression-patterns.md`](references/compression-patterns.md) for a pattern catalog and its anti-patterns.
-
-### 5. Build the atlas
-
-Write the atlas before implementation. Save it under `docs/plans/YYYY-MM-DD-<scope>-compression-atlas.md` unless the user forbids file creation, in which case include it in the response. It must contain: scope map, role inventory, opportunity ledger, deferred register, compression clusters, dependency order, touch map, and validation plan.
-
-Dispositions, exactly one per opportunity:
-
-- `merge`: combine mechanisms that perform the same role
-- `delete`: remove a mechanism proven unused or replaced
-- `inline`: remove a wrapper, adapter, or single-use abstraction
-- `extract`: isolate a real shared role that multiple consumers need
-- `generate`: derive a surface from metadata instead of maintaining it by hand
-- `enforce`: centralize a policy or invariant so callers cannot drift
-- `supersede`: absorb a local issue into a larger compression cluster
-- `defer`: keep the opportunity visible but out of the current migration, only because of a verified blocker
-- `skip`: reject the opportunity because the compression is false, too costly, or net-negative
-
-Use `defer` only for a verified blocker: outside the stated scope, evidence unavailable, depends on an unimplemented earlier cluster, conflicts with unrelated live edits, needs unavailable runtime or generated artifacts, or the user limited this run. Every deferred entry needs its blocking fact and revisit condition. Do not defer merely because a change is large; if it is the right compression, order it and do it.
-
-Reject a plan that starts editing before it can answer: What full set of opportunities is this edit part of? Which later opportunities become easier after it? Which earlier opportunities would make it unnecessary? What file-touch conflicts or public surfaces constrain the order?
-
-### 6. Generate competing models
-
-For any substantial proposal, produce at least two models; for high-leverage refactors, three: conservative (delete or inline local bloat), shape-level (one small mechanism for a repeated role or lifecycle), and radical (replace a scattered surface with metadata, generation, or enforced policy).
-
-Evaluate each by: behavior preserved, concept count, blast radius (`affected`, `change-surface`), deletion potential, failure mode if the abstraction is false, migration path, and whether it deletes, generates, or enforces complexity rather than relocating it.
-
-Prefer the model that removes a concept or policy duplication. Do not prefer a model merely because it extracts a helper. Reject a model that creates a new thousand-line center unless that center is a temporary migration step and the next compression step is explicit.
-
-### 7. Sense-check, then implement in dependency order
-
-Turn the selected model into executor-ready clusters, each with thesis, evidence, old mechanisms, new mechanism, ordered steps naming files and symbols, and validation. Before editing, check: every step names existing files or symbols; overlapping clusters have an explicit order; the plan deletes, generates, or enforces instead of adding a larger abstraction; no step edits a file a later enabling cluster would rewrite; public surfaces that must stay stable are named.
-
-Read the source for every key symbol in the proposal with `scip-query code`. Implement cluster by cluster. Finish and validate the current cluster before replanning; change course only when a verified fact falsifies the plan. When the right compression is large, do not shrink it into cosmetic local edits.
-
-After each implemented cluster, run the repository's own tests plus:
-
-```bash
-scip-query diff-impact
-scip-query architecture
-scip-query system <new-center-or-module>
-scip-query wrapper-candidates
-scip-query passthrough-candidates
-```
-
-Then answer: what old mechanisms disappeared, what new mechanisms appeared, and which new file or symbol is now the next pressure point?
-
-## Report
-
-```text
-Current System Model: one paragraph from concrete evidence.
-Compression Thesis: the deeper principle and the smaller mechanism, in one sentence.
-Evidence: commands, files, and symbols that support the thesis.
-Proposed Shape: what owns the policy, workflow, or data afterward.
-What Disappears: specific scripts, branches, duplicated policies, hand-maintained text, or helper layers.
-Opportunity Ledger: every discovered opportunity with its disposition.
-Deferred Register: every deferral, its verified blocker, and its revisit condition.
-Dependency Order: cluster order and why earlier clusters enable later ones.
-Compression Audit: whether the proposal deletes, generates or enforces, or merely relocates complexity; the largest remaining pressure point.
-Risks: facts that could falsify the compression or make it too expensive.
-```
-
-## Guardrails
-
-Do not confuse textual duplication with conceptual duplication. Textual duplication is repeated code; conceptual duplication is repeated responsibility. Either can exist without the other.
-
-Do not package-deal unrelated concerns: a false grouping that treats different things as one because they share a surface trait while ignoring the facts that distinguish them.
-
-Do not invent a "clean architecture" vocabulary unless it identifies actual referents in this codebase. Prefer the project's existing names when they already isolate the right concepts.
-
-Do not let detectors decide the answer. They are instruments, not judgment. Use them to find clues; use source reading and graph facts to validate.
-
-Do not let the implementation loop become the discovery mechanism. Discovery produces the atlas; implementation follows it.

package/skills/scip-system-compression/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: 'SCIP System Compression'
-  short_description: 'Map and order conceptual simplifications across a whole subsystem'
-  default_prompt: 'Use $scip-system-compression to build a compression atlas for this scope: climb from files and symbols to roles and principles, inventory every simplification opportunity with a disposition, order clusters by dependency, and propose or execute the smaller mechanisms.'