scip-query 0.19.5 → 0.19.8

package/skills/scip-hyper-optimization/SKILL.md

@@ -1,156 +0,0 @@
----
-name: scip-hyper-optimization
-description: Optimize performance scientifically with scip-query evidence. Use for benchmarking, profiling, speeding up commands, workflows, indexers, detectors, app paths, cold/warm regressions, memory/cost reduction, or comparing current-pipeline tuning with alternative designs.
-commands:
-  - template: 'scip-query bench --json'
-    when: 'Target and harness: baseline timings for a scip-query command target.'
-  - template: 'scip-query bench --json --cold-index --include-heavy --timeout-ms 600000'
-    when: 'Target and harness: cold-path and heavy-detector timings.'
-  - template: 'scip-query work-audit <profile> --json'
-    when: 'Profile the chain: rank exact repeated computations by measured avoidable time.'
-  - template: 'scip-query plan-context <entry-symbol-or-file>'
-    when: 'Trace behavior: pre-edit context for the profiled entry point.'
-  - template: 'scip-query call-graph <entry-symbol>'
-    when: 'Trace behavior: callers/callees for the pipeline under test.'
-  - template: 'scip-query complexity <hot-symbol>'
-    when: 'Diagnose: branches, cyclomatic estimate, fan-in/out for a hot symbol.'
-  - template: 'scip-query change-surface <touched-file> --json --full'
-    when: 'Verify and report: blast radius of the optimization change.'
----
-
-# scip-hyper-optimization
-
-Use this skill to make a command, workflow, service, page, or tool faster without changing its observable result. Hyper optimization is a bounded campaign that improves runtime, memory, or computational cost against repeatable measurements.
-
-Campaign-level conduct — delegation, handoff verification, benchmark pre-registration across multiple phases — is `scip-conductor`; this skill is the performance-domain method that runs inside it (or standalone for a single target).
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-## Scale Gate
-
-Choose the mode before starting:
-
-- **QUICK** — a single command/function target with an obvious hot path: capture one `docs/benchmarks/runs/YYYY-MM-DD-<target>.jsonl` baseline, skip the ledger and the rest of the campaign artifact set, fix the hypothesis, measure after, done.
-- **CAMPAIGN** — multiple targets, an unclear bottleneck, or a decision between competing designs: run the full machinery below (baseline doc, ledger, profiling, alternative-design track).
-
-One sentence to decide: if you can already name the one function you expect to fix and a single before/after number will settle it, use QUICK; if naming that function requires investigation or the fix might be architectural, use CAMPAIGN.
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | Returns | Coverage | When |
-| --- | --- | --- | --- | --- |
-| `scip-query bench --json` | Benchmark indexing and command runtimes for this repository | timings, command outcomes, environment, and optional profiles | `sampled` | Target and harness: baseline timings for a scip-query command target. |
-| `scip-query bench --json --cold-index --include-heavy --timeout-ms 600000` | Benchmark indexing and command runtimes for this repository | timings, command outcomes, environment, and optional profiles | `sampled` | Target and harness: cold-path and heavy-detector timings. |
-| `scip-query work-audit <profile> --json` | Rank exact repeated computations in a profiling JSONL file by measured avoidable time | ranked repeated-work groups, counts, and avoidable duration | `bounded` | Profile the chain: rank exact repeated computations by measured avoidable time. |
-| `scip-query plan-context <entry-symbol-or-file>` | Pre-edit planning context for a symbol, file, or module | definitions and references; callers and callees; dataflow producers and consumers; backward and forward slices; affected symbols; change-surface risk; dependencies and reverse dependencies; module files and exports; external surface use; complexity; churn; co-change partners; active suppressions | `bounded` | Trace behavior: pre-edit context for the profiled entry point. |
-| `scip-query call-graph <entry-symbol>` | Show incoming callers and outgoing callees for a symbol | caller and callee symbol identities with files | `bounded` | Trace behavior: callers/callees for the pipeline under test. |
-| `scip-query complexity <hot-symbol>` | Per-symbol complexity: branches, cyclomatic estimate, fan-in/out, callees | LOC, branch, complexity, callee, fan-in, and fan-out counts | `bounded` | Diagnose: branches, cyclomatic estimate, fan-in/out for a hot symbol. |
-| `scip-query change-surface <touched-file> --json --full` | Pre-change briefing: exports, consumers, and blast-radius risk | defined symbols, external consumer counts, and risk levels | `bounded` | Verify and report: blast radius of the optimization change. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Terms
-
-A measurement harness is the repeatable set of commands, fixtures, corpora, environment notes, and result documents used to decide whether performance changed.
-
-A run history is the durable time series of measurements, with one record per run, command, subprocess, or profiled stage.
-
-A profile span is one named timed piece of work inside the target process, such as input loading, cache reads, database queries, graph traversal, rendering, or a child process.
-
-Hierarchical profiling is measuring coarse spans first, then recursively splitting only the dominant span until the expensive operation is concrete enough to fix.
-
-A command ledger is the living document for one target: output contract, current pipeline, timings, tried ideas, and decisions.
-
-## Rules
-
-1. Do not optimize until a measurement harness exists or is created.
-2. Capture representative inputs, output contract, and correctness checks before editing.
-3. Record every benchmark in machine-readable run history.
-4. Measure cold and warm paths separately when they can diverge.
-5. Profile the internal chain before choosing a fix.
-6. Attach cardinality to spans: files, rows, symbols, candidates, cache hits/misses, bytes, edges, nodes, retries, or output rows.
-7. Work both tracks: tune the current pipeline and evaluate alternative algorithms or data models.
-8. Keep only changes that improve real workloads without reducing accuracy, diagnostics, safety, or supported inputs.
-
-## Workflow
-
-### 1. Target and harness
-
-If the repo is not a reliable scip-query workspace, invoke `scip-setup` first. Choose the target from user pain, telemetry, benchmark ranking, regression data, cost, frequency, or risk.
-
-Create or update:
-
-- `docs/benchmarks/YYYY-MM-DD-<target>-baseline.md` (CAMPAIGN only — QUICK skips this)
-- `docs/benchmarks/runs/YYYY-MM-DD-<target>.jsonl` (both modes — the one required artifact)
-
-For scip-query command targets, start with:
-
-```bash
-scip-query bench --json
-scip-query bench --json --cold-index --include-heavy --timeout-ms 600000
-```
-
-This step is complete only when baseline timings, output identity evidence, corpus, environment, and run-history location exist.
-
-### 2. Create the ledger
-
-CAMPAIGN only — QUICK mode skips this step and goes straight to tracing behavior with the single run-history file as its record.
-
-Write `docs/benchmarks/YYYY-MM-DD-<target>-ledger.md` with Output Contract, Target Selection, Current Pipeline, Run History Location, Profile Spans, Bottleneck Candidates, Measurements, Current-Pipeline Optimizations, Alternative Designs, and Decisions.
-
-This step is complete only when the ledger can explain what must not change.
-
-### 3. Trace behavior
-
-```bash
-scip-query plan-context <entry-symbol-or-file>
-scip-query trace <entry-symbol>
-scip-query call-graph <entry-symbol>
-scip-query code <entry-symbol>
-scip-query dataflow <entry-symbol>
-scip-query complexity <hot-symbol>
-scip-query change-surface <touched-file> --json --full
-```
-
-Record input parsing, option resolution, subprocesses, lookups, database queries, graph traversal, source scans, semantic calls, cache reads/writes, rendering, serialization, and verification.
-
-This step is complete only when each major pipeline step can be timed as a profile span.
-
-### 4. Profile the chain
-
-0. Check whether the target app already has an instrumentation layer before adding spans — a bespoke profiling harness competes with the one the codebase already trusts. When the target is scip-query itself, its instrumentation is `src/instrumentation/profile.ts` (`profileSpan`/`profileAsyncSpan`, env-gated by `SCIP_QUERY_PROFILE`/`SCIP_QUERY_PROFILE_OUT`, with `SCIP_QUERY_PROFILE_CACHE_STATE` for cache-state labels and inherited workload/subsystem identities) — use it, don't add a parallel one.
-1. Measure the target unprofiled.
-2. Measure profiled once and compare overhead.
-3. Measure distinct states: cold index, cold evidence/cache fill, warm cache hit, repeated focused run, production-like mixed state.
-4. Add coarse spans covering the whole chain.
-5. Split the largest workload-weighted span.
-6. Repeat until the slow operation is a repeated lookup, initialization, scan, traversal, subprocess, serialization step, or wait.
-7. Write span records with cardinality to run history.
-8. When spans carry work identities, run `scip-query work-audit <profile> --json` to separate exact repeats from same-name work on different inputs.
-
-This step is complete only when the dominant cost is concrete enough to form a falsifiable hypothesis.
-
-### 5. Diagnose and test one hypothesis
-
-Classify the dominant shape: cold-only setup, warm slow path, repeated setup, N+1 work, broad scan, database time, subprocess startup, serialization, or cache invalidation. Prefer fixes in this order:
-
-1. Remove accidental repetition.
-2. Batch scalar work.
-3. Move stable derived work to an index/cache with invalidation.
-4. Replace broad scans with indexed lookups.
-5. Replace wrapper APIs only after output identity proves equivalence.
-6. Add pruning only when mathematically equivalent or corpus-proven.
-
-Make the smallest reversible change that tests one hypothesis.
-
-This step is complete only when before/after timings, profile deltas, and output identity are recorded.
-
-### 6. Verify and report
-
-Run the narrow correctness check, benchmark cases, routed postchecks, and invoke `scip-verify`.
-
-Reject faster changes that alter the output contract unless the user approved a behavior change.
-
-End with a scoreboard from run history: starting value, current value, delta, scenario, corpus, commit/version, output identity, accepted changes, rejected ideas, remaining bottlenecks, and next target.

package/skills/scip-hyper-optimization/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: 'SCIP Hyper Optimization'
-  short_description: 'Hierarchical profiling-driven optimization'
-  default_prompt: 'Use $scip-hyper-optimization to choose an optimization target, capture output identity, measure cold and warm controls, profile the dominant span hierarchically, then optimize without changing behavior.'

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

@@ -1,152 +0,0 @@
----
-name: scip-integrity-audit
-description: Audit whether implementations are real with scip-query. Use for suspected faked or half-implemented features, decorative checkers or verifiers that never fail, dead code paths hidden behind graceful fallbacks, metrics that may be lying, or a "does any of this actually work" interrogation of a system.
-commands:
-  - scip-query refs <symbol>
-  - scip-query code <symbol>
-  - scip-query trace <symbol>
-  - scip-query call-graph <symbol>
-  - scip-query twin-drift -s <scope> --json
-  - scip-query twin-ab <symbolA> <symbolB>
-  - scip-query outline <file> --signatures
-  - scip-query decorative-checkers -s <scope> --json
-  - scip-query not-implemented -s <scope> --json
-  - scip-query test-quality -s <scope> --json
----
-
-# scip-integrity-audit
-
-Use this skill to interrogate whether a system's claims are backed by real
-implementations. Structural review asks "is this well organized?"
-(`scip-maintainability`); this skill asks **"is this real?"** — it hunts
-decorative checkers, adapters written against imagined data, features that
-have silently never run, and numbers nobody ever recomputed.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-## The Stance
-
-A green result you have never seen fail is unverified. Every status word,
-banner, and metric is testimony from the code, not evidence about the code —
-cross-examine the producer before believing it. The most dangerous code is
-not broken code; it is code that reports success without doing the work.
-
-## Drills
-
-Run all five over the chosen scope. Each has a checkable exit.
-
-### 1. Falsify every checker
-
-Inventory everything in scope that accepts/rejects, passes/fails, or
-validates (checkers, gates, verifiers, validators — find producers with
-`refs`/`call-graph` on the status words in output). For each one, construct
-an input that MUST fail — a wrong binding, a corrupt file, an impossible
-value — and run it. A checker that passes its should-fail input is
-decorative: file it as a defect, not a note.
-Before filing, attempt the defense: an accusation triggers a rewrite, so
-search for the failure exit the drill may have missed — a config-gated
-branch, an async rejection, one-hop delegation (the calibration's known
-noise archetypes). File the defect with the executed should-fail input
-attached and the defense attempt noted; a defense that succeeds clears the
-checker and stays in the record as its witness.
-Complete only when every checker in scope has been witnessed rejecting a
-constructed should-fail input, or is listed with a reason it cannot be.
-
-Mechanized by: `scip-query decorative-checkers` finds `validate*`/`verify*`/
-`check*`/`assert*`/`is*`/`has*` callables with no reachable failure exit
-anywhere in their body (calibrated 2026-07-03 against two external repos —
-standalone-only; noise archetypes past one-hop delegation in
-`docs/validation/2026-07-03-integrity-detector-calibration.md`). Run it first
-to shortlist candidates before hand-constructing should-fail inputs.
-
-### 2. Diff every adapter against captured reality
-
-For each parser/adapter of an external format (tool output, XML/JSON
-schemas, protocol messages): obtain ONE real sample from the actual source
-and diff it against the code's assumptions and the tests' fixtures. Ask of
-every fixture: was this generated from reality, or imagined? A parser and a
-hand-written fixture can validate each other's shared hallucination
-indefinitely.
-Complete only when every adapter has been checked against at least one
-captured-real sample.
-
-### 3. Autopsy every fallback
-
-Graceful degradation is where dead features hide: a primary path that has
-never worked looks identical to a healthy fallback. For every catch block,
-`?? fallback`, and degraded mode in scope: produce an execution witness that
-the PRIMARY path runs (a test, a probe, a log). Use `scip-probe-reachability`
-for parser/AST branch reachability. A fallback that always fires means the
-feature above it is dead — date of death: birth.
-Complete only when every fallback's primary path has a witness or a filed
-defect.
-
-Mechanized by: `scip-query not-implemented` finds reachable placeholder
-stubs (`throw new Error('not implemented')`, TODO-comment + return-default,
-empty bodies) that a real caller, entry surface, or package-surface export
-can actually reach — the graph fact that separates "primary path never
-built" from `dead`'s "primary path built but unreferenced." Standalone-only
-(calibrated 2026-07-03; 0 live findings on two external repos post-fix, see
-the calibration report) — treat a clean run as "nothing this shape found,"
-not as "every fallback's primary path is proven live."
-
-### 4. Hand-compute every metric twice
-
-For each number the system reports (scores, counts, estimates): pick two
-concrete instances, compute the expected value by hand from first
-principles, and compare. Off-by-a-factor errors (double counting, inflated
-estimates) survive for years because nobody ever recomputes one sample.
-Complete only when every reported metric has two hand-verified samples.
-
-### 5. Cross-examine same-concept twins
-
-Where one concept is computed in more than one place, feed both the same
-input and require the same answer. `twin-drift` finds the same-name cases
-mechanically; for same-concept-different-name pairs, trace the concept's
-consumers with `refs` and compare implementations with `code`. Once a pair
-is identified, `scip-query twin-ab <symbolA> <symbolB>` scaffolds a
-table-driven vitest file that imports both and asserts equal output —
-fill in the input table and run it. Disagreement between twins means at
-least one is wrong — determine which before consolidating.
-Complete only when every discovered twin pair has been compared on a shared
-input.
-
-## Severity
-
-Rank findings by what the failure does to a user who trusted the output:
-a decorative checker or false "verified" banner outranks everything; a
-dead-but-fallbacked feature outranks a wrong metric; a wrong metric outranks
-structural mess. Route structural findings to `scip-maintainability` —
-they are real but they are not lies.
-
-## Reporting
-
-File each finding with: the claim as displayed, the producer (file:line),
-the drill that exposed it, the should-fail input or real sample used, and
-the fix. The audit is complete only when every drill's exit criterion is
-met for the scope, and every defect found has a regression artifact — a
-test, fixture, or model that fails on the pre-fix behavior.
-
-End with a derived verdict, not an impression:
-
-```markdown
-Integrity: <scope> — <c> checkers witnessed failing, <a> adapters diffed
-against reality, <f> fallback primaries witnessed live, <m> metrics
-recomputed, <t> twins compared; <d> defects filed, <u> unverifiable (reasons)
-```
-
-A suspect scope that produces zero defects is itself a claim: state what
-made the suspicion wrong, or rerun the drill that should have caught it.
-
-A regression artifact that doesn't actually assert anything, or asserts the
-same literal it stubbed into its own mock, is a fake witness — the same
-"reports success without doing the work" failure mode this skill hunts in
-production code, just relocated to the test suite. Run `scip-query
-test-quality -s <scope>` over the audit's own regression artifacts (and,
-periodically, over the suite at large) to catch this: assertion-free test
-bodies, a skipped-test ledger with git-blame age (a skip with no fix date
-attached is a claim nobody is checking), and mock-echo (a test that only
-proves its own stub). Standalone-only, mixed precision by sub-check
-(calibrated 2026-07-03): assertion-free and skipped are high-precision;
-mock-echo is intentionally low-precision (syntactic same-literal matching,
-not dataflow) — treat its output as a reviewed candidate list, not a verdict.

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

@@ -1,4 +0,0 @@
-interface:
-  display_name: "scip integrity audit"
-  short_description: "Interrogate whether implementations are real: falsify checkers, diff adapters against reality, autopsy fallbacks."
-  default_prompt: "Run the scip-integrity-audit drills over this codebase and report every decorative checker, dead-behind-fallback feature, and lying metric."

package/skills/scip-language-playbook/SKILL.md

@@ -1,106 +0,0 @@
----
-name: scip-language-playbook
-description: Choose language-specific scip-query commands. Use when entering an unfamiliar TypeScript, Python, Java, Scala, Kotlin, Rust, Go, C, C++, Ruby, C#, Visual Basic, Dart, PHP, Clojure, ClojureScript, or Vue codebase and you need high-signal exploration or de-bloat commands first.
-commands:
-  - template: 'scip-query stats'
-    when: 'Universal first pass: repo-wide size and shape.'
-  - template: 'scip-query files <feature-or-module-name>'
-    when: 'Universal first pass: locate the files for a feature or module.'
-  - template: 'scip-query outline <file>'
-    when: 'Universal first pass: symbol tree for a candidate file.'
-  - template: 'scip-query trace <symbol>'
-    when: 'Universal first pass: definition plus every reference.'
-  - template: 'scip-query code <symbol>'
-    when: 'Universal first pass: confirm behavior claims with source.'
----
-
-# scip-language-playbook
-
-Use this reference to pick the shortest command path from "what is this system doing?" to verified language-specific answers.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | Returns | Coverage | When |
-| --- | --- | --- | --- | --- |
-| `scip-query stats` | Show index statistics | document, symbol, definition, reference, size, and build-time totals | `complete` | Universal first pass: repo-wide size and shape. |
-| `scip-query files <feature-or-module-name>` | Find files matching a pattern | matching file paths | `complete` | Universal first pass: locate the files for a feature or module. |
-| `scip-query outline <file>` | Tree view of symbols in a file, with line ranges | symbol names, nesting, and line ranges | `complete` | Universal first pass: symbol tree for a candidate file. |
-| `scip-query trace <symbol>` | Trace a symbol: definition + all references | definition sites with source and signature; referencing files with line numbers | `bounded` | Universal first pass: definition plus every reference. |
-| `scip-query code <symbol>` | Read the source code for a symbol (bounded to its definition range) | definition identity, source, and line range | `complete` | Universal first pass: confirm behavior claims with source. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Rules
-
-1. Start with the active language row before broader or noisier commands.
-2. Pair relationship commands with `code` for behavior claims.
-3. For de-bloat, cross-check multiple detector families.
-4. When a command is weaker in a language, use the listed fallback.
-
-## Universal First Pass
-
-```bash
-scip-query stats
-scip-query kind-counts
-scip-query files <feature-or-module-name>
-scip-query outline <file>
-scip-query by-kind function --scope <feature-or-module-name>
-scip-query trace <symbol>
-scip-query hierarchy <symbol>
-scip-query code <symbol>
-```
-
-## Language Rows
-
-| Language                | Use first                                                                          | De-bloat set                                                                                                                                                 | Fallback note                                                                                |
-| ----------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
-| TypeScript              | `system`, `surface`, `call-graph`, `dataflow`, `change-surface`                    | `health`, `dead`, `similar`, `similar --plan`, `wrapper-candidates`, `passthrough-candidates`, `stale-abstractions`, `unused-imports`, `redundant-reexports` | Strongest verified surface. Vue script blocks use this path too.                             |
-| Python                  | `outline`, `kind-counts --scope`, `system`, `imports`, `imported-by`, `call-graph` | `dead`, `unused-imports`, `drift`, `similar-signatures`, `complexity`, `complexity-hotspots`                                                                 | Prefer source-backed fallbacks when call/kind metadata is sparse.                            |
-| Java                    | `system`, `surface`, `call-graph`, `deps`, `rdeps`, `slice`                        | `health`, `dead`, `similar-files`, `similar-chains`, `wrapper-candidates`, `stale-abstractions`, `extract-candidates`                                        | Use module/package surfaces to avoid class-only tunnel vision.                               |
-| Scala                   | `surface`, `trace`, `call-graph`, `imports`, `imported-by`                         | `dead`, `similar-files`, `similar-chains`, `extract-candidates`, `stale-abstractions`, `unused-imports`                                                      | Confirm behavior with `code`.                                                                |
-| Kotlin                  | `surface`, `trace`, `call-graph`, `imports`, `imported-by`                         | `dead`, `similar-files`, `similar-chains`, `extract-candidates`, `stale-abstractions`, `unused-imports`                                                      | Confirm behavior with `code`.                                                                |
-| Rust                    | `trace`, `call-graph`, `refs`, `methods`, `surface`                                | `dead`, `wrapper-candidates`, `passthrough-candidates`, `stale-abstractions`, `similar-signatures`, `redundant-reexports`                                    | Methods and surface are usually high signal.                                                 |
-| Go                      | `surface`, `trace`, `call-graph`, `refs`, `fan-in`                                 | `dead`, `wrapper-candidates`, `passthrough-candidates`, `similar-files`, `similar-signatures`, `complexity`                                                  | Use package-level surfaces and confirm exported APIs before cleanup.                         |
-| C++                     | `trace`, `refs`, `methods`, `surface`, `code`                                      | `dead`, `wrapper-candidates`, `similar-files`, `similar-chains`, `extract-candidates`, `unused-imports`                                                      | Try `call-graph` after trace/refs/code.                                                      |
-| C                       | `trace`, `call-graph`, `refs`, `outline`, `fan-out`                                | `dead`, `wrapper-candidates`, `similar-files`, `similar-chains`, `extract-candidates`, `unused-imports`                                                      | Skip class/member commands.                                                                  |
-| Ruby                    | `trace`, `call-graph`, `refs`, `imports`, `imported-by`                            | `dead`, `wrapper-candidates`, `passthrough-candidates`, `stale-abstractions`, `similar-files`, `similar-signatures`                                          | Confirm dynamic-looking paths with source.                                                   |
-| C#                      | `surface`, `call-graph`, `trace`, `methods`, `refs`                                | `dead`, `wrapper-candidates`, `passthrough-candidates`, `stale-abstractions`, `similar-files`, `extract-candidates`                                          | Use surfaces and methods together.                                                           |
-| Visual Basic            | `surface`, `call-graph`, `trace`, `methods`, `refs`                                | `dead`, `wrapper-candidates`, `passthrough-candidates`, `stale-abstractions`, `similar-files`, `extract-candidates`                                          | Use surfaces and methods together.                                                           |
-| Dart                    | `surface`, `call-graph`, `trace`, `imports`, `imported-by`                         | `dead`, `wrapper-candidates`, `stale-abstractions`, `similar-files`, `similar-signatures`, `redundant-reexports`                                             | Confirm exported API shape with `surface`.                                                   |
-| PHP                     | `trace`, `refs`, `methods`, `surface`, `code`                                      | `dead`, `wrapper-candidates`, `stale-abstractions`, `similar-files`, `similar-signatures`, `extract-candidates`                                              | Try `call-graph` after trace/refs/code.                                                      |
-| Clojure / ClojureScript | `files`, `outline`, `trace`, `refs`, `call-graph`                                  | `dead`, `similar-files`, `similar-signatures`, `complexity`, `complexity-hotspots`                                                                           | SCIP indexing comes from `scip-clojure`; no TypeScript-style semantic provider is available. |
-
-## Minimal Workflows
-
-Understand a feature:
-
-```bash
-scip-query files <feature>
-scip-query outline <file>
-scip-query kind-counts --scope <feature>
-scip-query fan-out <file>
-scip-query trace <entry-symbol>
-scip-query call-graph <entry-symbol>
-scip-query code <entry-symbol>
-scip-query surface <module>
-```
-
-Find DRY and de-bloat wins:
-
-```bash
-scip-query health
-scip-query dead
-scip-query wrapper-candidates
-scip-query passthrough-candidates
-scip-query stale-abstractions
-scip-query similar-files
-scip-query similar-chains
-scip-query similar-signatures
-scip-query extract-candidates
-```
-
-When recommending a command sequence, name the language and why these commands are highest-signal for it.

package/skills/scip-language-playbook/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP Language Playbook"
-  short_description: "Pick high-signal SCIP commands by language"
-  default_prompt: "Use $scip-language-playbook to choose the best scip-query commands for this language and task."

package/skills/scip-maintainability/SKILL.md

@@ -1,158 +0,0 @@
----
-name: scip-maintainability
-description: Review maintainability with scip-query evidence. Use for hidden policies, scattered concepts, accidental variation, weak boundaries, system compression, architecture smells, structural refactors, or maintainability improvements beyond health scores.
-commands:
-  - template: 'scip-query stats'
-    when: 'Map evidence: repo-wide size before bounding the review.'
-  - template: 'scip-query system <scope>'
-    when: 'Map evidence: files, symbols, deps in/out for the scope.'
-  - template: 'scip-query surface <scope>'
-    when: 'Map evidence: what consumers actually use from the scope.'
-  - template: 'scip-query change-surface <file>'
-    when: 'Map evidence: exports, consumers, and blast-radius risk.'
-  - template: 'scip-query affected <symbol>'
-    when: 'Map evidence: transitive consumers of a candidate symbol.'
-  - template: 'scip-query drift --patterns --architecture'
-    when: 'Map evidence: declared architecture violations plus boundary and pattern signals; treat opt-in pattern hits as leads, not findings.'
----
-
-# scip-maintainability
-
-Use this skill to review a codebase as a maintainer who must make future changes safely. Maintainability is the degree to which real code units let a maintainer understand, verify, and change behavior without rediscovering hidden knowledge.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | Returns | Coverage | When |
-| --- | --- | --- | --- | --- |
-| `scip-query stats` | Show index statistics | document, symbol, definition, reference, size, and build-time totals | `complete` | Map evidence: repo-wide size before bounding the review. |
-| `scip-query system <scope>` | Full module map: files, symbols, deps in/out | module file paths; exported symbols with line ranges; internal dependencies; reverse dependencies | `complete` | Map evidence: files, symbols, deps in/out for the scope. |
-| `scip-query surface <scope>` | What symbols consumers actually use from this module | consumer paths and consumed symbol identities | `complete` | Map evidence: what consumers actually use from the scope. |
-| `scip-query change-surface <file>` | Pre-change briefing: exports, consumers, and blast-radius risk | defined symbols, external consumer counts, and risk levels | `bounded` | Map evidence: exports, consumers, and blast-radius risk. |
-| `scip-query affected <symbol>` | Transitive closure of symbols that could break if this symbol changes | affected symbol identities, files, and traversal depths | `bounded` | Map evidence: transitive consumers of a candidate symbol. |
-| `scip-query drift --patterns --architecture` | Detect drift candidates: unused imports and declared architecture violations; pass --architecture for boundary context | drifted symbol families, files, and evidence | `bounded` | Map evidence: declared architecture violations plus boundary and pattern signals; treat opt-in pattern hits as leads, not findings. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Terms
-
-A code smell is an observable codebase fact that predicts avoidable future mistakes because the same knowledge must be rediscovered, synchronized, or defended in more than one place.
-
-A concept boundary is the line around code units that exist for one reason to change.
-
-A hidden policy is a rule for choosing behavior when several plausible behaviors exist, but the rule lives in local branches, comments, conventions, or caller folklore instead of a named mechanism.
-
-A lifecycle is a repeatable sequence of states or steps that makes a result valid.
-
-Accidental variation is difference in code shape that does not correspond to behavior, domain facts, runtime constraints, or external contracts.
-
-Essential variation is difference that must remain because the real units differ: language grammars, user-visible APIs, runtime environments, or compatibility boundaries.
-
-System compression is replacing several mechanisms that perform the same role, policy, lifecycle, or surface job with fewer named mechanisms that preserve behavior.
-
-A unifying definition is the single essential trait that makes several code sites one concept; what makes it a test is that failing to state it proves the sites are not one concept, and consolidating them anyway would package-deal essential variation into a false abstraction.
-
-## Rules
-
-1. Ground claims in files, symbols, references, call graphs, dependencies, surfaces, and blast radius.
-2. Do not chase health scores; detector counts are clues, not objectives.
-3. Name concrete referents before naming the smell.
-4. Preserve essential variation.
-5. Add an abstraction only when it removes hidden policy, names a lifecycle, enforces a rule, or reduces concept count.
-6. Prefer deletion, inlining, merging, generation, or enforcement before broad frameworks.
-7. A scattered-concept or consolidation claim ships its unifying definition. If no single essential trait covers every cited site, the variation is essential: record it and do not consolidate.
-
-## Workflow
-
-### 1. Bound the review
-
-Restate the question:
-
-```text
-What future-maintenance mistakes does this structure invite, and what smaller named mechanisms would prevent them without hiding real variation?
-```
-
-Name the scope: repo, module, command family, query family, runtime surface, fixture set, or feature path.
-
-This step is complete only when the review question and scope are concrete.
-
-### 2. Map evidence
-
-```bash
-scip-query stats
-scip-query system <scope>
-scip-query surface <scope>
-scip-query files <pattern>
-scip-query outline <file>
-scip-query deps <file>
-scip-query rdeps <file>
-scip-query trace <symbol>
-scip-query call-graph <symbol>
-scip-query affected <symbol>
-scip-query change-surface <file>
-```
-
-Use cleanup commands as probes: `health`, `similar`, `similar-files`, `similar-chains`, `extract-candidates`, `wrapper-candidates`, `passthrough-candidates`, `stale-abstractions`, `drift`, and `cycles`.
-
-This step is complete only when concrete units, consumers, tests, fallbacks, adapters, generated artifacts, and compatibility constraints are visible.
-
-### 3. Build the role inventory
-
-For each cluster, ask:
-
-- What one concept appears in several places — and what single essential trait makes them one concept? If the trait cannot be stated, they are not one concept.
-- What policy is hidden?
-- What lifecycle is unnamed?
-- Which differences are essential?
-- What must a maintainer know that the local interface does not admit?
-- Would a smaller mechanism remove a reason to change, or only move code?
-
-This step is complete only when every candidate smell names its referents and its future-maintenance failure mode.
-
-### 4. Rank pressure
-
-Prefer severe smells in this order:
-
-1. Hidden correctness or evidence policy spread across modules.
-2. Repeated lifecycle or pipeline with no owner.
-3. Public surface exposing accidental internals.
-4. Large module with unrelated reasons to change.
-5. Tests that encode incident history without contract vocabulary.
-6. Adapter families with repeated capability or fallback shapes.
-7. Suppression comments that document architecture decisions instead of exceptions.
-8. Thin wrappers and passthroughs that do not buy clarity.
-
-Reject smells that are aesthetic, unverifiable, or false compression.
-
-This step is complete only when each target is ranked, skipped, or deferred with evidence.
-
-### 5. Choose a model
-
-For substantial changes, compare at least two models:
-
-- Conservative: delete or inline local bloat.
-- Shape-level: introduce one small mechanism for a repeated role or lifecycle.
-- Radical: replace a scattered surface with metadata, generation, or enforced policy.
-
-Evaluate behavior preserved, concept count removed, blast radius, deletion potential, false-abstraction failure mode, migration path, and verification cost.
-
-This step is complete only when the chosen model removes a concept or policy duplication rather than merely extracting a helper.
-
-### 6. Produce a register or atlas
-
-For broad review, write a register under `docs/plans/` unless the user asks not to edit files. For implementation, write an atlas before editing.
-
-Use dispositions: `merge`, `delete`, `inline`, `extract`, `generate`, `enforce`, `supersede`, `defer`, `skip`.
-
-Every `merge`, `extract`, or `generate` entry carries its unifying definition and its strongest dissenter — the cited site most likely to differ essentially — with the evidence that it does not. A dissenter that survives moves the entry to `skip` with reason `essential variation`; the dissenter stays in the register either way.
-
-This step is complete only when each opportunity has evidence, disposition, dependency order, touch map, and validation plan.
-
-### 7. Implement and verify when asked
-
-Implement the smallest named mechanism that matches the real concept. Keep essential variation near the adapter or domain code that knows it. After changes, run focused tests and the routed postchecks in `scip-verify`, then complete that verification skill.
-
-Report the smell addressed, mechanism introduced or removed, what was deliberately not compressed, and verification results.

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

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP Maintainability"
-  short_description: "Review hidden policy and boundaries"
-  default_prompt: "Use $scip-maintainability to find maintainability risks, hidden policies, and weak boundaries with SCIP evidence."

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

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