scip-query 0.19.4 → 0.19.6

package/skills/scip-directory-architecture/SKILL.md

@@ -1,254 +0,0 @@
----
-name: scip-directory-architecture
-description: Review directory architecture with scip-query evidence. Use to evaluate, design, reorganize, or migrate folder structure, ownership boundaries, locality config, messy repos, AI-generated layout, or safe file-move slices.
-commands:
-  - template: "scip-query system <scope>"
-    when: "Inventory evidence: files, symbols, deps in/out for the scope."
-  - template: "scip-query locality-candidates --json --full"
-    when: "Inventory evidence: directory-locality candidates from consumer ownership."
-  - template: "scip-query similar-files --full --json"
-    when: "Inventory evidence: files with overlapping dependency profiles."
-  - template: "scip-query cycles"
-    when: "Inventory evidence: circular dependency chains between files."
-  - template: "scip-query architecture --json"
-    when: "Measure configured boundaries, actual dependency traffic, forbidden edges, reciprocal pairs, and boundary cycles."
-  - template: "scip-query drift --architecture"
-    when: "Review direct drift findings together with boundary coverage and architecture signals."
-  - template: "scip-query co-change --json --full"
-    when: "Inventory evidence: hidden file-level coupling from git history."
-  - template: "scip-query health --write-baseline"
-    when: "Record reviewed existing debt before enabling architecture regression enforcement."
-  - template: "scip-query diff-gate"
-    when: "Verify that the current diff introduces no new declared architecture violation."
-  - template: "scip-query config-validate --json"
-    when: "Implement a slice: validate locality config after a move."
----
-
-# scip-directory-architecture
-
-Use this skill to answer where code should live. Directory architecture is the filesystem arrangement of source files by their main reason to change; what distinguishes a good structure is that a maintainer can predict where a concept belongs before reading every import.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | When |
-| --- | --- | --- |
-| `scip-query system <scope>` | Full module map: files, symbols, deps in/out | Inventory evidence: files, symbols, deps in/out for the scope. |
-| `scip-query locality-candidates --json --full` | Find directory-locality and ancestry candidates from consumer ownership | Inventory evidence: directory-locality candidates from consumer ownership. |
-| `scip-query similar-files --full --json` | Find heuristic similar-file candidates from dependency profiles | Inventory evidence: files with overlapping dependency profiles. |
-| `scip-query cycles` | Detect circular dependency chains between files | Inventory evidence: circular dependency chains between files. |
-| `scip-query architecture --json` | Evaluate project-owned architectural boundaries and dependency rules | Measure configured boundaries, actual dependency traffic, forbidden edges, reciprocal pairs, and boundary cycles. |
-| `scip-query drift --architecture` | Detect drift candidates: unused imports and declared architecture violations; pass --architecture for boundary context | Review direct drift findings together with boundary coverage and architecture signals. |
-| `scip-query co-change --json --full` | Files that change together in git history without a dependency edge — hidden coupling candidates | Inventory evidence: hidden file-level coupling from git history. |
-| `scip-query health --write-baseline` | Composite codebase health report with prioritized action list | Record reviewed existing debt before enabling architecture regression enforcement. |
-| `scip-query diff-gate` | Gate the current diff: architecture regressions plus echo, migration, coordination, doc-drift, unused-param, and new-dead candidates; exit 1 on blocking findings | Verify that the current diff introduces no new declared architecture violation. |
-| `scip-query config-validate --json` | Validate .scipquery.json, including structured suppressions and declared coupling groups | Implement a slice: validate locality config after a move. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Terms
-
-An ownership boundary is a folder, package, module, or convention that groups code around one stable responsibility.
-
-A dependency edge points from code that relies on something to the code it relies on. For imports, `A -> B` means A imports B.
-
-A forbidden edge is an actual cross-boundary dependency rejected by an explicit project rule. Directory distance or an unusual import does not make an edge forbidden by itself.
-
-A layer is a responsibility ordered by dependency direction, such as presentation depending on application. A subsystem is a responsibility that owns an end-to-end capability, such as authentication or rendering. A package is a publication or build unit. A service is an independently running unit. Do not force all four into one layer hierarchy.
-
-A reciprocal dependency is dependency traffic in both directions between two boundaries. It is a review signal because the boundaries exert mutual change pressure, not proof that either import is wrong.
-
-An architecture ratchet is an enforcement rule that records existing violations while preventing new ones, allowing a large codebase to improve without a speculative rewrite.
-
-A target structure is a proposed future layout that expresses an ownership model, not merely a prettier tree.
-
-A migration slice is the smallest set of file moves and import updates that can be verified independently.
-
-A slop codebase is a codebase whose files are arranged by accident, convenience, or recent edits rather than stable ownership rules.
-
-## Rules
-
-1. Start with evidence, not taste.
-2. Separate review from migration; do not move files unless asked.
-3. Preserve broad boundaries when evidence shows they are intentional.
-4. Do not reward generic `shared` unless the shared concept has a name, owner, and cross-boundary consumers.
-5. For messy repos, produce a discovery map and decisions instead of pretending the target is obvious.
-6. Prefer small verified moves.
-7. Configure descriptive boundaries before closing dependency rules.
-8. Treat graph shape as evidence about responsibilities, never as a substitute for identifying them.
-
-## Workflow
-
-### 1. Bound the question
-
-Classify the request: review, target structure, locality config, migration plan, or implementation.
-
-This step is complete only when the scope and deliverable are explicit.
-
-### 2. Inventory evidence
-
-```bash
-scip-query stats
-scip-query system <scope>
-scip-query files <pattern>
-scip-query surface <scope>
-scip-query deps <file>
-scip-query rdeps <file>
-scip-query change-surface <file>
-scip-query plan-context <file-or-symbol>
-scip-query locality-candidates --json --full
-scip-query cycles
-scip-query architecture --json
-scip-query drift --architecture
-scip-query co-change
-scip-query similar-files --min-similarity 0.6 --min-deps 3
-scip-query similar-chains --min-similarity 0.5
-scip-query recent-duplicates
-scip-query drift
-```
-
-Also read durable project guidance that names architecture, modules, ownership, routes, workflows, contracts, or domains.
-
-This step is complete only when each folder under review has evidence for exports, entry points, consumers, tests, co-change partners, and claimed ownership rules.
-
-### 3. Classify boundary maturity
-
-Classify each candidate:
-
-- Mature: repeated, documented, and enforced by imports, tests, routes, packages, standards, or review history.
-- Emerging: meaningful and partly repeated, but not consistent enough to configure.
-- Accidental: convenience bucket, legacy pile, generated artifact, recent edit cluster, or mixed reasons to change.
-
-This step is complete only when mature, emerging, and accidental boundaries are separated.
-
-### 4. Build a descriptive architecture model
-
-For a large existing codebase, identify real system units before calling them layers. Inventory:
-
-- workspace packages and public exports;
-- applications, services, and deployable entry points;
-- domain capabilities and end-to-end subsystems;
-- persistence, network, rendering, compiler, and other technical responsibilities;
-- tests, routes, contracts, and ownership or architecture documentation;
-- dependency and co-change evidence that shows which files already move as a unit.
-
-Add mature boundary path patterns to `.scipquery.json` without `allowedDependencies` rows first:
-
-```json
-{
-  "architecture": {
-    "boundaries": [
-      { "name": "domain", "paths": ["src/domain/**"] },
-      { "name": "runtime", "paths": ["src/runtime/**"] }
-    ]
-  }
-}
-```
-
-Then run:
-
-```bash
-scip-query config-validate --json
-scip-query architecture --json
-```
-
-Use unmapped and ambiguous files to repair boundary membership. Use actual boundary edges, reciprocal pairs, and strongly connected groups to test whether the names describe real separation.
-
-This step is complete only when every configured boundary has a stated responsibility and the mapping gaps are understood.
-
-### 5. Declare only supported dependency rules
-
-An `allowedDependencies` row is closed: an outgoing target omitted from a present row is forbidden. A missing row makes no dependency claim.
-
-```json
-{
-  "architecture": {
-    "boundaries": [
-      { "name": "domain", "paths": ["src/domain/**"] },
-      { "name": "runtime", "paths": ["src/runtime/**"] }
-    ],
-    "allowedDependencies": {
-      "domain": [],
-      "runtime": ["domain"]
-    },
-    "requireAcyclic": true
-  }
-}
-```
-
-For each closed row, record the evidence for its intended direction. Do not copy the current dependency graph into the allow-list merely to obtain zero findings. Leave emerging or disputed rows undeclared.
-
-This step is complete only when every forbidden edge is understood as either implementation debt, a false boundary, or a policy mistake.
-
-### 6. Propose structure or decisions
-
-Use this shape:
-
-```markdown
-# Directory Architecture Review
-
-## Scope
-## Current Structure Map
-## Boundary Maturity
-## Descriptive Architecture Model
-## Dependency Rules
-## Forbidden-Edge Ledger
-## Reciprocal and Cycle Review
-## Target Structure
-## Move Ledger
-## Locality Config
-## No-Move Decisions
-## Deferred Decisions
-## Migration Order
-```
-
-List no-move decisions when broad consumers, route/package/contract surfaces, infrastructure roles, generic shared risk, or weak evidence make a move harmful.
-
-This step is complete only when every proposed move has a reason and verification path.
-
-### 7. Ratchet, then implement one slice when asked
-
-For a large repository with existing violations, review the direct findings and
-write the shared health baseline:
-
-```bash
-scip-query drift --architecture
-scip-query health --write-baseline
-```
-
-The baseline records stable architecture identities by boundary pair, not by
-whichever example file happens to sort first. The default `scip-query
-diff-gate` architecture check then compares only architecture identities; it
-does not run every health detector. `diff-gate --baseline` remains the opt-in
-full health ratchet and does not duplicate architecture findings.
-
-Commit `.scipquery-baseline.json` with `.scipquery.json`. A missing baseline
-causes the architecture gate to report that enforcement is not enabled; it
-does not silently treat the current graph as accepted.
-
-Prefer inspecting the least-broad edge inside a boundary cycle first, but
-determine whether the repair is a move, dependency inversion, named shared
-contract, boundary merge, or policy correction.
-
-Before editing, state files to move, imports/exports/tests/docs to update, expected verification, and rollback risk. Then move the smallest high-confidence slice and run:
-
-```bash
-scip-query incomplete-migration
-scip-query recent-duplicates
-scip-query co-change <moved-file-or-config>
-```
-
-Also run project tests or typecheck for the affected workspace. If `.scipquery.json` locality changed, run:
-
-```bash
-scip-query config-validate
-scip-query locality-candidates --json --full
-scip-query architecture --json
-scip-query drift --architecture
-scip-query diff-gate
-```
-
-Then invoke `scip-verify`. The implementation is complete only when imports, tests, locality signals, and verification are checked.

package/skills/scip-directory-architecture/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP Directory Architecture"
-  short_description: "Review and propose source folder boundaries"
-  default_prompt: "Use $scip-directory-architecture to review this repository directory structure and propose safer ownership boundaries."

package/skills/scip-doc-reconcile/SKILL.md

@@ -1,89 +0,0 @@
----
-name: scip-doc-reconcile
-description: Reconcile living docs with current code using scip-query doc-drift. Use for stale standards, broken file references, docs that cite moved code, agent guidance, or normative contradictions between documentation and implementation.
-commands:
-  - template: "scip-query doc-drift --json --full"
-    when: "Build the worklist: every stale-doc candidate, ranked."
-  - template: "scip-query doc-drift <doc>"
-    when: "Reconcile one doc: staleness detail for a single target."
-  - template: "scip-query outline <subject-file>"
-    when: "Reconcile one doc: current shape of the code the doc describes."
-  - template: "scip-query trace <symbol>"
-    when: "Reconcile one doc: verify a symbol the doc mentions still exists as described."
-  - template: "scip-query code <symbol>"
-    when: "Reconcile one doc: re-derive a snippet from current source."
----
-
-# scip-doc-reconcile
-
-Use this skill to make living documentation true again. A living doc is documentation agents or maintainers use to make present-day changes, such as AGENTS.md, CLAUDE.md, standards, command docs, or workflow docs.
-
-Load shared mechanics from [`../_shared/SKILL.md`](../_shared/SKILL.md).
-
-<!-- BEGIN GENERATED SKILL COMMANDS -->
-## Commands for this skill
-
-| Command | Purpose | When |
-| --- | --- | --- |
-| `scip-query doc-drift --json --full` | Stale-doc candidates: code the doc references or co-changed with kept changing after the doc stopped | Build the worklist: every stale-doc candidate, ranked. |
-| `scip-query doc-drift <doc>` | Stale-doc candidates: code the doc references or co-changed with kept changing after the doc stopped | Reconcile one doc: staleness detail for a single target. |
-| `scip-query outline <subject-file>` | Tree view of symbols in a file, with line ranges | Reconcile one doc: current shape of the code the doc describes. |
-| `scip-query trace <symbol>` | Trace a symbol: definition + all references | Reconcile one doc: verify a symbol the doc mentions still exists as described. |
-| `scip-query code <symbol>` | Read the source code for a symbol (bounded to its definition range) | Reconcile one doc: re-derive a snippet from current source. |
-
-Use this shortlist first. Open [`../_shared/SKILL.md`](../_shared/SKILL.md) only when it is insufficient.
-<!-- END GENERATED SKILL COMMANDS -->
-
-## Rule
-
-Separate statement types:
-
-- Descriptive claims say what the code currently does or where it lives. Update them when code moves.
-- Normative claims say what code must or should do. If code violates them, fix the code or escalate the contradiction; do not weaken the standard silently.
-
-This distinction is the core of doc reconciliation.
-
-## Workflow
-
-### 1. Build the worklist
-
-```bash
-scip-query doc-drift --json --full
-scip-query doc-drift <doc-or-tree>
-```
-
-Prioritize broken references, highest staleness, then docs agents read most. Do not reconcile archival records such as dated plans, ADRs, or reports — list them in `.scipquery.json` `docs.snapshotPaths` so `doc-drift` excludes them with a labeled exclusion instead of resurfacing them every sweep.
-
-This step is complete only when each target doc is selected for a current-use reason.
-
-### 2. Reconcile one doc
-
-For each doc:
-
-```bash
-scip-query doc-drift <doc>
-scip-query outline <subject-file>
-scip-query system <module>
-scip-query trace <symbol-the-doc-mentions>
-scip-query code <symbol>
-```
-
-Use Git history only to understand why a subject changed, not as a substitute for current code evidence.
-
-Fix broken references by finding the current code or deleting the obsolete claim. Rewrite stale descriptive claims from current source evidence. Re-derive snippets from `scip-query code`. Record normative contradictions instead of changing standards to bless drifted code.
-
-This step is complete only when every edited claim is supported by evidence from this session.
-
-### 3. Verify
-
-```bash
-scip-query doc-drift <doc>
-```
-
-Invoke `scip-verify` when the documentation change is part of a codebase diff. The doc is complete only when staleness drops to zero or the remaining contradiction is explicitly reported.
-
-### 4. Report
-
-Report staleness before and after, broken references fixed, claims updated, normative contradictions, and docs recommended for deletion.
-
-Do not claim reconciliation is done until `doc-drift` has been rerun.

package/skills/scip-doc-reconcile/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "SCIP Doc Reconcile"
-  short_description: "Repair docs that drift from code"
-  default_prompt: "Use $scip-doc-reconcile to reconcile this documentation with current SCIP-backed code evidence."

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 | When |
-| --- | --- | --- |
-| `scip-query bench --json` | Benchmark indexing and command runtimes for this repository | 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 | 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 | 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 | 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 | Trace behavior: callers/callees for the pipeline under test. |
-| `scip-query complexity <hot-symbol>` | Per-symbol complexity: branches, cyclomatic estimate, fan-in/out, callees | 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 | 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.'