scip-query 0.19.4 → 0.19.6

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 | When |
-| --- | --- | --- |
-| `scip-query stats` | Show index statistics | Universal first pass: repo-wide size and shape. |
-| `scip-query files <feature-or-module-name>` | Find files matching a pattern | 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 | Universal first pass: symbol tree for a candidate file. |
-| `scip-query trace <symbol>` | Trace a symbol: definition + all references | Universal first pass: definition plus every reference. |
-| `scip-query code <symbol>` | Read the source code for a symbol (bounded to its definition range) | 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 | When |
-| --- | --- | --- |
-| `scip-query stats` | Show index statistics | Map evidence: repo-wide size before bounding the review. |
-| `scip-query system <scope>` | Full module map: files, symbols, deps in/out | Map evidence: files, symbols, deps in/out for the scope. |
-| `scip-query surface <scope>` | What symbols consumers actually use from this module | Map evidence: what consumers actually use from the scope. |
-| `scip-query change-surface <file>` | Pre-change briefing: exports, consumers, and blast-radius risk | Map evidence: exports, consumers, and blast-radius risk. |
-| `scip-query affected <symbol>` | Transitive closure of symbols that could break if this symbol changes | 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 | 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 routed postchecks from the shared reference, then invoke `scip-verify`.
-
-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."

package/skills/scip-react-maintainability/SKILL.md

@@ -1,101 +0,0 @@
----
-name: scip-react-maintainability
-description: Review React maintainability with scip-query. Use for React, TSX, JSX, Next.js, duplicated components, hook candidates, large components, frontend health pressure, or verifying reuse after refactors.
-commands:
-  - template: "scip-query react-component-duplicates --scope <scope> --full --json"
-    when: "Bound and scan: duplicated JSX structure candidates."
-  - template: "scip-query react-hook-candidates --scope <scope> --full --json"
-    when: "Bound and scan: shared state/effect/request extraction candidates."
-  - template: "scip-query react-large-component-pressure --scope <scope> --full --json"
-    when: "Bound and scan: components carrying several reasons to change."
-  - template: "scip-query recent-duplicates --scope <scope> --full --json"
-    when: "Bound and scan: recent code re-implementing established components."
-  - template: "scip-query similar <closest-existing-component-or-hook>"
-    when: "Cross-check candidates: existing component or hook to reuse instead."
-  - template: "scip-query health --scope <scope> --json"
-    when: "Bound and scan: frontend health pressure for the scope."
----
-
-# scip-react-maintainability
-
-Use this skill to review React frontends as maintainable systems of components, hooks, JSX structure, and behavior lifecycles.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | When |
-| --- | --- | --- |
-| `scip-query react-component-duplicates --scope <scope> --full --json` | Find heuristic duplicated React component structure candidates from JSX tags, props, events, and bindings | Bound and scan: duplicated JSX structure candidates. |
-| `scip-query react-hook-candidates --scope <scope> --full --json` | Find heuristic React hook extraction candidates from shared state, effects, requests, and handlers | Bound and scan: shared state/effect/request extraction candidates. |
-| `scip-query react-large-component-pressure --scope <scope> --full --json` | Find heuristic large React component pressure candidates from component lines, JSX structure, and hook behavior | Bound and scan: components carrying several reasons to change. |
-| `scip-query recent-duplicates --scope <scope> --full --json` | Directional duplicate candidates: recent code that re-implements established callable, React, or Vue code | Bound and scan: recent code re-implementing established components. |
-| `scip-query similar <closest-existing-component-or-hook>` | Find heuristic function similarity candidates from callee fingerprints | Cross-check candidates: existing component or hook to reuse instead. |
-| `scip-query health --scope <scope> --json` | Composite codebase health report with prioritized action list | Bound and scan: frontend health pressure for the scope. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Terms
-
-A React component duplicate candidate is a pair or group of rendered structures that repeat the same user-facing arrangement, controls, states, props, or data-presentation shape enough that a shared component may reduce drift.
-
-A React hook candidate is a pair or group of component behaviors that repeat the same state lifecycle, effects, requests, validation, persistence, callback policy, or derived-data rule enough that a shared hook may preserve behavior better.
-
-Large component pressure means one component or file contains several kinds of knowledge that change for different reasons.
-
-## Workflow
-
-### 1. Bound and scan
-
-Pick the narrowest React source root, feature area, or changed-file scope that still includes likely reuse partners. Run uncapped commands:
-
-```bash
-scip-query react-component-duplicates --scope <scope> --full --json
-scip-query react-hook-candidates --scope <scope> --full --json
-scip-query react-large-component-pressure --scope <scope> --full --json
-scip-query recent-duplicates --scope <scope> --full --json
-scip-query health --scope <scope> --json
-```
-
-This step is complete only when command scope, counts, and uncapped/full status are recorded.
-
-### 2. Cross-check candidates
-
-- Component duplicate only: inspect for shared presentational component or existing component reuse.
-- Hook candidate only: inspect for shared behavior, lifecycle, request, validation, persistence, or derived-state policy.
-- Both: inspect for a feature-level concept needing both component and hook boundaries.
-- Large component only: split by reason to change, not by line count.
-
-Use:
-
-```bash
-scip-query outline <file>
-scip-query deps <file>
-scip-query rdeps <file>
-scip-query similar-files --scope <scope>
-scip-query similar <closest-existing-component-or-hook>
-```
-
-This step is complete only when each top candidate is reuse, extract, split, skip, or blocked.
-
-### 3. Act on findings
-
-Prefer reuse before extraction. Extract components for repeated UI structure, states, props, slots/children, or design-system composition. Extract hooks for repeated state, effects, requests, subscriptions, memoized derivations, callbacks, or persistence. Keep domain-specific variation at call sites when essential.
-
-This step is complete only when the chosen action reduces future drift without creating boolean-soup APIs or wrapper components with no policy.
-
-### 4. Verify
-
-Run routed postchecks from the shared reference, including React commands, `incomplete-migration`, `recent-duplicates`, `unused-params`, and wrapper/passthrough/stale checks, then invoke `scip-verify`.
-
-The work is complete only when acted-on candidate pairs disappear, weaken materially, or are explicitly accepted as essential variation.
-
-## False Positive Checks
-
-Shared design-system primitives, icons, labels, route names, or test IDs are not enough. Similar JSX with different domain lifecycles may justify a presentational component but not a hook. A large file is review pressure, not proof of duplication.
-
-## Report
-
-Report executive read, command evidence, candidate groups, recommended action, post-change proof, and remaining accepted variation.

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

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP React Maintainability"
-  short_description: "Review React reuse and component pressure"
-  default_prompt: "Use $scip-react-maintainability to review React reuse, hooks, components, and frontend health pressure."