Aivana Database Engineer

View saved version →

---
name: advisor-confidence-grader
description: Grade advisory recommendations by evidence strength and identify missing proof before production change.
---

# Advisor Confidence Grader

Run:

```bash
node runtime/runTool.js advisor_confidence_grader '{"evidence":{"hasLivePlan":true,"hasWaits":true,"hasRollback":true}}'
```

Returns evidence grade, score, missing evidence, and required next evidence.

View saved version →

---
name: ai-anomaly-triage
description: Correlate query stats, telemetry, policy decisions, and replay memory into deterministic incident hypotheses and next-best actions.
---

# AI Anomaly Triage

Use this skill when an operator asks why database behavior changed, whether a
deployment caused a regression, or what to investigate first during an incident.

Run:

```bash
node runtime/runTool.js ai_anomaly_triage '{"engine":"postgres","database":"analytics","deploymentId":"deploy-42","incidentWindowMinutes":45}'
```

The tool is offline and deterministic. It combines workload stats,
telemetry-correlation output, policy-memory signals, and recent replay context.
It returns an anomaly score, root-cause hypotheses, next-best actions, and
explainability fields listing the exact signal families used.

View saved version →

---
name: ai-data-contract-guardian
description: Check schema drift, required columns, PII declaration, retention, and governance controls against a declared data contract.
---

# AI Data Contract Guardian

Use this skill when validating table contracts before deploys, migrations, or
data product releases.

Run:

```bash
node runtime/runTool.js ai_data_contract_guardian '{"engine":"postgres","database":"analytics","schema":"public","table":"events","contract":{"requiredColumns":["event_id","user_email","created_at"],"piiColumns":["user_email"],"retentionDays":90}}'
```

The output includes contract findings, a contract status, required governance
controls, and evidence from catalog metadata. It is deterministic and does not
call an external AI service.

View saved version →

---
name: ai-decision-simulator
description: Simulate database agent decisions against evidence, policy, and approval constraints.
---

# ai_decision_simulator

Use this skill to simulate how an AI database agent should decide under evidence, policy, and approval constraints.

Governance:
- Simulation only.
- No production apply or autonomous DDL.
- Human approval requirements always override dry-run readiness.

Output contract:
- `usp: "ai_decision_simulator"`
- `proposedAction`, `simulatedDecisions`, `decision`
- `evidence`, `confidence`, `source: "analysis"`

View saved version →

---
name: ai-guarded-sql-generator
description: Generates bounded read SQL with tenant, policy, audit, and performance guardrails.
---

# AI Guarded SQL Generator

Run:

```bash
node runtime/runTool.js ai_guarded_sql_generator '{"intent":"list recent paid orders","table":"orders","filters":{"status":"paid"},"limit":100,"tenantId":"tenant-a"}'
```

Returns generated SQL, guardrails, and risk classification.

View saved version →

---
name: ai-migration-risk-radar
description: Score migration blast radius and produce a rollback rehearsal plan before schema changes reach production.
---

# AI Migration Risk Radar

Use this skill before proposing, signing, or applying migrations.

Run:

```bash
node runtime/runTool.js ai_migration_risk_radar '{"engine":"sqlserver","database":"app_prod","schema":"public","migrationSql":"CREATE INDEX ix_orders_status ON orders(status)"}'
```

The tool computes blast radius from catalog metadata, risk classification,
PII sensitivity, table size hints, and policy preflight. It returns a release
recommendation and dry-run rollback rehearsal checklist.

View saved version →

---
name: ai-query-rewrite-lab
description: Generate safe query rewrite candidates with deterministic explainability without executing SQL.
---

# AI Query Rewrite Lab

Use this skill to propose safer or cheaper SQL variants before running EXPLAIN
or executing a statement.

Run:

```bash
node runtime/runTool.js ai_query_rewrite_lab '{"engine":"postgres","database":"analytics","schema":"public","table":"events","sql":"SELECT * FROM events WHERE user_email = ''a@example.com''"}'
```

The lab never executes SQL. It returns rewrite candidates, expected impact
ranges, applied rewrite rules, and a safety block that marks the output as
analysis-only.

View saved version →

---
name: ai-roi-narrative-generator
description: Explain database tuning ROI from supplied measurements and explicitly labeled estimates.
---

# ai_roi_narrative_generator

Use this skill to translate AI database operations evidence into an executive ROI narrative.

Governance:
- Narrative and scoring only.
- Keep ROI claims tied to provided evidence.
- Do not present estimates as audited finance results.

Output contract:
- `usp: "ai_roi_narrative_generator"`
- `executiveNarrative`, `roiSignals`
- `evidence`, `confidence`, `source: "analysis"`

View saved version →

---
name: ai-strategy-synthesizer
description: Build a database improvement roadmap from objectives, evidence, and operational constraints.
---

# ai_strategy_synthesizer

Use this skill to turn enterprise platform priorities into an AI database operations roadmap.

Governance:
- Analysis-only.
- No production apply, DDL, or live remediation.
- Keep recommendations tied to closed-loop dry-run evidence and human approval gates.

Output contract:
- `usp: "ai_strategy_synthesizer"`
- `positioning`, `objective`, `roadmap`, `guardrails`, `recommendations`
- `evidence`, `confidence`, `source: "analysis"`

View saved version →

---
name: ai-trust-scorecard
description: Assess the evidence and explainability of database advisor recommendations.
---

# ai_trust_scorecard

Use this skill to score AI recommendations across explainability, safety, reproducibility, and governance.

Governance:
- Analysis-only scoring.
- Low trust requires more evidence before recommendation.
- Trust scores do not authorize production execution.

Output contract:
- `usp: "ai_trust_scorecard"`
- `trustScore`, `decision`
- `evidence`, `confidence`, `source: "analysis"`

View saved version →

---
name: audit-query
description: "Generate audit-grade records for sensitive SQL operations including approvals, risk outcomes, and execution traces."
---

# Audit Query

## Use when
- User or policy requires immutable evidence trail for governance/compliance.

## Workflow
1. Capture request context, actor, environment, and policy context.
2. Attach parsed query fingerprint and risk decision.
3. Record outcomes, anomalies, and deviations.
4. Produce a signed audit artifact when applicable.

## Governance
- Ensure immutable append-only behavior.
- Redact secrets and raw sensitive literals in logs.

## Output
- `auditEntryId`, `requestFingerprint`, `decisionLog`, `approvalChain`, `trace`

View saved version →

---
name: autonomous-dba-copilot
description: Orchestrates a DBA loop from evidence collection through confidence grading, experiment design, ticket prep, and rollback.
---

# Autonomous DBA Copilot

Run:

```bash
node runtime/runTool.js autonomous_dba_copilot '{"question":"Checkout is slow","sql":"SELECT * FROM orders","evidence":{"hasLivePlan":true,"hasWaits":true,"hasRollback":true}}'
```

Returns loop steps, decision package, next action, and evidence grade.

View saved version →

---
name: autonomous-experiment-planner
description: Designs dry-run experiments across query rewrites, indexes, workload twins, and rollout gates.
---

# Autonomous Experiment Planner

## Use when
- An operator goal needs evidence before any change recommendation.

## Governance
- Experiments must be `dry_run`.
- Abort if an experiment requires real apply, lacks rollback, or has unknown tenant scope.

## Output
- `experiments`, `abortCriteria`, `decision`, `safeNextAction`

View saved version →

---
name: autonomous-learning-backlog
description: Prioritize missing evidence and follow-up experiments from database advisor feedback.
---

# autonomous_learning_backlog

Use this skill to convert advisor feedback, incidents, and outcomes into prioritized AI learning tasks.

Governance:
- Analysis-only backlog generation.
- Do not mutate models, policies, or production systems.
- Prioritize rollback evidence, confidence calibration, incident patterns, and prompt safety.

Output contract:
- `usp: "autonomous_learning_backlog"`
- `executionMode: "analysis_only"`
- `learningBacklog`
- `evidence`, `confidence`, `source: "analysis"`

View saved version →

---
name: autonomous-ops-briefing
description: Produces a board-level briefing for closed-loop autonomous database operations.
---

# Autonomous Ops Briefing

## Use when
- Operators need a concise final summary of decision, evidence, confidence, risks, and safe next action.

## Governance
- Positioning is autonomous operations without autonomous production risk.
- Briefings must expose missing evidence and approval boundaries.

## Output
- `boardSummary`, `decision`, `evidence`, `confidence`, `risks`, `safeNextAction`

View saved version →

---
name: autonomous-verification-loop
description: Create prove-before-apply gates for migrations, indexes, rewrites, SLOs, replay, and rollback evidence.
---

# Autonomous Verification Loop

Use this skill before applying write-like database changes.

Run:

```bash
node runtime/runTool.js autonomous_verification_loop '{"tool":"create_index","engine":"postgres","database":"analytics","schema":"public","table":"events","proposedSql":"CREATE INDEX ix_events_email ON events(user_email)"}'
```

The tool returns gates for policy, explain, replay, SLO, and rollback evidence,
plus a release decision.

View saved version →

---
name: autonomy-boundary-enforcer
description: Enforces closed-loop dry-run boundaries and blocks autonomous production apply.
---

# Autonomy Boundary Enforcer

## Use when
- A proposed autonomous action must be checked against execution boundaries.

## Governance
- Production apply and real DDL execution require human approval.
- Only dry-run actions are autonomously allowed.

## Output
- `boundary`, `requiredApprovals`, `decision`, `safeNextAction`

View saved version →

---
name: benchmark-ab-runner
description: Compare baseline and candidate query performance metrics and declare a benchmark winner.
---

# Benchmark A/B Runner

Run:

```bash
node runtime/runTool.js benchmark_ab_runner '{"baseline":{"p95Ms":300,"cpuMs":80},"candidate":{"p95Ms":190,"cpuMs":55}}'
```

Returns deltas, winner, and verdict.

View saved version →

---
name: change-ticket-exporter
description: Export approval-ready production change tickets with problem, recommendation, risk, rollback, and checklist.
---

# Change Ticket Exporter

Run:

```bash
node runtime/runTool.js change_ticket_exporter '{"title":"Add checkout index","problem":"p95 breach","recommendation":"create index","rollback":"drop index"}'
```

Returns ticket fields, approval checklist, labels, and export formats.

View saved version →

---
name: cognitive-schema-mapper
description: Infer candidate business concepts from supplied database schema metadata.
---

# cognitive_schema_mapper

Use this skill to map database schema names and domain terms into a business ontology for AI reasoning.

Governance:
- Analysis-only semantic mapping.
- Do not infer sensitive data access permissions.
- Flag domain terms that lack schema evidence as semantic gaps.

Output contract:
- `usp: "cognitive_schema_mapper"`
- `ontology`, `semanticGaps`, `recommendations`
- `evidence`, `confidence`, `source: "analysis"`

View saved version →

---
name: confidence-budget-manager
description: Scores whether enough evidence exists to recommend, defer, or escalate an autonomous operator decision.
---

# Confidence Budget Manager

## Use when
- The operator must decide whether it has enough evidence to proceed with dry-run recommendation.

## Governance
- Below-threshold evidence must return `needs_more_evidence`.
- Thresholds do not permit production apply.

## Output
- `confidenceBudget`, `decision`, `missingEvidence`, `safeNextAction`

View saved version →

---
name: counterfactual-risk-engine
description: Compares do-nothing, dry-run-change, rollback, and defer scenarios for an operating objective.
---

# Counterfactual Risk Engine

## Use when
- A team needs to know the likely result of acting, waiting, rolling back, or deferring.

## Governance
- Produces scenario analysis only.
- Recommends dry-run validation before any apply path.

## Output
- `scenarios`, `recommendedScenario`, `decision`, `safeNextAction`

View saved version →

---
name: cross-agent-consensus-builder
description: Compare supplied advisor recommendations and report agreement and unresolved disagreements.
---

# cross_agent_consensus_builder

Use this skill to combine performance, cost, security, compliance, and rollout agent findings into a consensus packet.

Governance:
- Analysis-only consensus.
- Preserve disagreements instead of hiding them.
- Disagreement should defer to more evidence or human review.

Output contract:
- `usp: "cross_agent_consensus_builder"`
- `consensus`, `disagreements`, `decision`
- `evidence`, `confidence`, `source: "analysis"`

View saved version →

---
name: decision-evidence-compiler
description: Builds an executive-grade decision evidence packet from runtime signals and confidence checks.
---

# Decision Evidence Compiler

## Use when
- A dry-run recommendation needs an approval-ready evidence packet.

## Governance
- Missing evidence must be explicit.
- Confidence must be stated separately from recommendation.

## Output
- `executivePacket`, `missingEvidence`, `confidence`, `safeNextAction`

View saved version →

---
name: dry-run-action-critic
description: Critiques proposed dry-run actions for blast radius, rollback gaps, tenant risk, and weak evidence.
---

# Dry-Run Action Critic

## Use when
- A candidate remediation needs adversarial safety review before recommendation.

## Governance
- Destructive or schema-changing actions must be escalated.
- Missing rollback, tenant, or live-plan evidence must be reported.

## Output
- `criticisms`, `decision`, `confidence`, `safeNextAction`

View saved version →

---
name: enforce-policy
description: "Evaluate request against governance policies and either permit, gate, or block execution."
---

# Enforce Policy

## Use when
- Pre-execution gating is needed for write/read operations.
- User asks why an action is disallowed or delayed.

## Workflow
1. Resolve active policies for environment, user role, and data classification.
2. Evaluate action against allow/deny and approval matrix.
3. Return decision and required controls to proceed.
4. Persist decision in audit trail.

## Governance
- Deny-by-default across critical policy mismatches.
- Escalate critical violations to Compliance Agent workflow.

## Output
- `decision`, `requiredControls`, `exceptions`, `auditReference`

View saved version →

---
name: erp-crm-advisor
description: Use when diagnosing ERP or CRM performance, integration failures, tenant isolation, reporting or customization risks using scoped evidence and explicit vendor-coverage gaps.
---

# ERP / CRM Advisor

Use when the user asks about ERP/CRM bottlenecks, vendor-specific data semantics,
integration failures, upgrades, reports, duplicate postings or tenant/company leakage.
Codex performs the interpretation; no separate LLM API key is required.

Resolve the plugin root two directories above this file. Read
`ERP_CRM_ANALYSIS.md` and `runtime/erp-crm-catalog.json` relative to that root.
Invoke its absolute `runtime/runTool.js` path; use JSON via stdin (`-`) for inputs.
Install missing dependencies with `npm ci` in the plugin root.

1. Run `erp_crm_vendor_catalog` with `{}`. Select an exact product profile; do not
   equate Dataverse with Finance and Operations or Business Central, or SAP ECC
   with S/4HANA. Obtain product release, instance ID, environment and deployment.
2. Run `erp_crm_evidence_plan` with the selected `product`. Identify installed
   modules, customizations and affected business processes. Separate application
   execution from database, API and reporting costs.
3. Inspect authorized, redacted exports and traces using available read-only
   tools. Do not invent credentials, assume native SaaS connectors, or send SOQL,
   SuiteQL, ABAP or HANA syntax to the SQL Server/PostgreSQL adapter.
   Use `erp_crm_import_diagnostics` for supported exports. For Dataverse traces or
   Salesforce query plans, use `erp_crm_collect_api` only with a configured
   provider URL, matching system ID, access token and explicit API version.
   A collector implementation is not proof that the customer's tenant was tested.
4. Build evidence bundles with matching context, trace references and actual
   observation timestamps. Populate supported numeric diagnostics from exports.
   For qualitative observations, assess the relevant code/configuration with an
   explanation tied to a trace or file reference; use `manual_review` for your
   interpretation. Never convert absent evidence into `false`, and never pretend
   a user assertion is a live measurement. Preserve provenance in the answer.
5. Run `erp_crm_risk_analyzer`. Explain prioritized findings, business impact,
   evidence, owner and next verification step. Include unresolved/conflicting
   checks and coverage of this finite catalog. Check the cited manufacturer
   guidance against the actual release before making product-specific claims.
6. For an optimization claim, run `benchmark_evidence_compare` on comparable,
   timestamped samples with case IDs, result hashes and row counts. Reject faster
   results with semantic differences or errors. Explain sampling and uncertainty;
   do not replace measured benchmarks with estimated advisor scores.
   Also run `workload_regression_guard` with the same runs to detect individual
   cases hidden by aggregate gains. Its defaults are a 10 percent per-case budget
   and a 1 ms noise floor; set these from the workload requirements. Repeat flagged
   cases under controlled load. A flag is not statistical proof or apply approval.
   Supply `caseBudgets` when the process owner provides absolute deadlines:
   `[{"caseId":"case-0","businessProcess":"Order posting","maxDurationMs":100}]`.
   Review existing as well as newly breached budgets. Unassessed cases are not
   evidence of business-SLO compliance. Preserve the returned policyHash with the
   benchmark inputHash so threshold changes remain distinguishable.

Review order-to-cash, procure-to-pay, period close and reporting where applicable:
company keys, document/line grain, status transitions, currencies/units, effective
dates, soft deletes, replication freshness and retry idempotency. Use control
totals from the business owner; a faster query that changes business meaning is
not an optimization.

Run `business_reconciliation_compare` for business control exports before accepting
an optimization. Both `before` and `after` require the full ERP scope, matching
`period`, `snapshotHash` and `definitionHash` (SHA256), distinct `exportId`, fresh
`capturedAt`, and nonempty `controls`. Each control has `companyId`, `currency`,
`unit`, `metric`, `amount` as an exact decimal string, and integer `rowCount`.
Use an explicitly agreed unit/currency label for nonmonetary metrics. Never invent
hashes, totals or counts. Missing groups are not zero. A matched result proves only
the supplied aggregate controls, not row-level equivalence; retain result-hash checks.

Analysis tools do not execute corrections. Do not modify vendor-managed tables,
indexes, permissions or production application data as part of this workflow.
Prepare supported remediation and before/after verification for authorized work.
No result establishes exhaustive coverage, vendor certification or compliance.

## Persistent advisory cases

Use `advisory_case` for a tracked engagement. Every call requires `systemId`,
`environment`, `product`, and `productVersion`. Create with `action: create` and
`objective`; later calls need `caseId` and mutations need `expectedRevision` from
the last read. Follow this sequence:

- `diagnose`: `hypothesis`, `evidenceRefs` (references are not attested facts).
- `propose`: `change`, `rollback`, `testPlan`, `workloadId`, `customizationHash`
  (SHA256 of the agreed customization inventory), and `businessContract` with
  `definitionHash`, `period`, `deployment`, and `groups`. Each group has `companyId`,
  `currency`, `unit`, `metric`. All expected groups must be agreed before approval;
  do not derive the expected set solely from a potentially incomplete candidate.
- `approve_test`: matching `proposalHash`, `reviewer`, `approvalRef`, `approvedAt`
  (timestamp within seven days) from an actual
  user approval. Never invent approval. This records a statement, not authenticated
  authorization, and executes nothing.
- `verify`, then `follow_up`: matching `proposalHash`, `measurements` for
  `repeated_benchmark_review`, and `businessControls` for `business_reconciliation_compare`.
  Control scope, period, definition and exact group set must match the approved
  contract; `snapshotHash` must equal the benchmark `datasetHash`. Follow-up controls
  must be newer. Missing controls cannot be waived by passing performance results.
  Measurements must not predate the recorded test approval.
  Each run must include the full case scope. Follow-up must use newer measurements,
  the same workload and thresholds. A verified state means evidence was assessed,
  not that an improvement succeeded; inspect its decision.
- `close`: `outcome` (`confirmed`, `false_positive`, `inconclusive`), `corrected`
  boolean, `reviewer`, `note`. Confirmation requires technical and business checks
  to pass at both stages. Old proposals without contracts require a new case.

Use `read` to resume, and `quality_report` to aggregate reviewed cases within the
exact same scope/version. Neither reviews nor local storage authenticate a tenant;
use separate OS-protected state directories for different trust boundaries.

Use `find_confirmed` with `workloadId` and `customizationHash` for up to ten relevant
confirmed cases. Search is limited to the latest 1000 cases in the exact scope;
legacy cases without business checks are excluded. Returned cases are examples
for review, not automatic optimization instructions.

Optional `causalEvidence` on `diagnose` is validated by `causal_evidence_review`:
`events` contain the four case-scope fields, `id`, `traceId`, `layer` (application,
integration, database), `startedAt`, `durationMs`, `evidenceRef`. `hypotheses` contain
`id`, `claim`, `supportRefs`, `refuteRefs`. References must resolve; stale or wrong-scope
events are rejected. Report contradictions and unresolved alternatives explicitly.

View saved version →

---
name: estimate-cost
description: "Estimate compute, IO, and runtime cost for a candidate query, migration, or schema operation."
---

# Estimate Cost

## Use when
- User needs execution cost estimate before confirmation.

## Workflow
1. Run dry estimates from plan/cost model plus historical baselines.
2. Convert to understandable unit economics (CPU, IO, storage, lock occupancy).
3. Provide confidence interval and alternative lower-cost variants.
4. Attach optimization preconditions.

## Governance
- Flag high-cost operations and require explicit human confirmation.
- Include environmental impact assumptions used in estimate.

## Output
- `estimatedCost`, `confidence`, `assumptions`, `optimizationLevers`

View saved version →

---
name: evidence-pack-generator
description: Build a DBA-ready performance case file with SQL, plan, waits, recommendation, rollback, and evidence grade.
---

# Evidence Pack Generator

Run:

```bash
node runtime/runTool.js evidence_pack_generator '{"question":"Why is checkout slow?","sql":"SELECT * FROM orders","recommendation":"add covering index"}'
```

Returns executive summary, case file sections, evidence grade, and missing evidence.

View saved version →

---
name: explain-query
description: "Run structured explain/explain-analyze workflows and convert plan output into explainable optimization insights."
---

# Explain Query

## Use when
- User asks why query is slow.
- Planner needs operator-level bottleneck explanation.

## Workflow
1. Parse query intent and classify risk (read-only preferred mode).
2. Collect `EXPLAIN` and `EXPLAIN ANALYZE` output in deterministic form.
3. Annotate scan patterns, joins, sort/hash/temp spills, and lock indicators.
4. Produce rewrite hypotheses with confidence scores.

## Governance
- Default to dry-run style if query could mutate data.
- Provide "why" and "impact estimate" before any recommendation.

## Output
- `plan`, `bottlenecks`, `rewriteHints`, `estimatedCost`, `confidence`

View saved version →

---
name: fleet-health-scorecard
description: Ranks database fleet health by latency, error-budget burn, and replication lag.
---

# Fleet Health Scorecard

Run:

```bash
node runtime/runTool.js fleet_health_scorecard '{"databases":[{"name":"prod-a","p95Ms":800,"errorBudgetBurnRate":3,"replicationLagSeconds":10}]}'
```

Returns ranked scorecard and health status.

View saved version →

---
name: hotfix-risk-assessor
description: Rates emergency database hotfix risk and blocks unsafe production changes.
---

# Hotfix Risk Assessor

Run:

```bash
node runtime/runTool.js hotfix_risk_assessor '{"change":"ALTER TABLE orders ADD COLUMN priority int NOT NULL DEFAULT 0","environment":"production","hasRollback":false}'
```

Returns risks and decision.

View saved version →

---
name: incident-analysis
description: "Correlate lock, query, and replication signals into causal incident hypotheses with prioritized remediation guidance."
---

# Incident Analysis

## Use when
- User asks why an incident happened or wants a causal chain.
- Response to operational regressions in latency, deadlocks, or replication lag.

## Workflow
1. Pull recent lock, query, and replication signal snapshots.
2. Correlate temporal overlap and severity transitions.
3. Build top incident hypotheses with confidence and remediation order.
4. Return expected validation probes and rollback readiness.

## Governance
- Do not trigger any destructive action.
- Mark confidence clearly before making any operational recommendation.

## Output
- `timeline`, `incidentHypotheses`, `confidence`, `recommendedActions`

View saved version →

---
name: index-portfolio-optimizer
description: Optimize the whole index portfolio by finding redundant, overlapping, unused, and high-write-cost indexes.
---

# Index Portfolio Optimizer

Run:

```bash
node runtime/runTool.js index_portfolio_optimizer '{"indexes":[{"name":"ix_a","columns":["status"],"reads":100,"writes":50},{"name":"ix_ab","columns":["status","created_at"],"reads":200,"writes":60}]}'
```

Returns redundant indexes, drop candidates, create candidates, and action order.

View saved version →

---
name: index-roi-simulator
description: Ranks index candidates by read benefit, write penalty, storage cost, and maintenance risk.
---

# Index ROI Simulator

Run:

```bash
node runtime/runTool.js index_roi_simulator '{"candidates":[{"id":"idx_events_user_email","readBenefitMs":180,"readQps":40,"writePenaltyMs":3,"writeQps":8,"storageMb":512}]}'
```

Returns ranked candidates, ROI score, break-even signal, and benchmark recommendation.

View saved version →

---
name: knowledge-gap-detector
description: Identify missing database evidence before recommending an operational action.
---

# knowledge_gap_detector

Use this skill before AI recommendations to detect missing schema, plan, telemetry, policy, or rollback evidence.

Governance:
- Do not recommend apply actions when required evidence is missing.
- Prefer a dry-run collection action as the next step.
- Treat missing policy or rollback proof as a reason to defer.

Output contract:
- `usp: "knowledge_gap_detector"`
- `decision`, `knowledgeGaps`, `safeNextAction`
- `evidence`, `confidence`, `source: "analysis"`

View saved version →

---
name: llm-prompt-risk-auditor
description: Inspect database operation requests for ambiguity and unsafe intent using deterministic rules.
---

# llm_prompt_risk_auditor

Use this skill to audit natural-language AI prompts or generated SQL instructions for dangerous ambiguity and unsafe production intent.

Governance:
- Never execute the prompt.
- Block or escalate destructive, broad, or production-scoped instructions.
- Rewrite unsafe requests as scoped dry-run diagnostics.

Output contract:
- `usp: "llm_prompt_risk_auditor"`
- `decision`, `risks`, `safeRewrite`
- `evidence`, `confidence`, `source: "analysis"`

View saved version →

---
name: migration-twin-simulator
description: Builds a SQL Server to PostgreSQL migration twin and rates query-family performance risk.
---

# Migration Twin Simulator

Run:

```bash
node runtime/runTool.js migration_twin_simulator '{"sourceEngine":"sqlserver","targetEngine":"postgres","queries":[{"queryId":"q1","sql":"SELECT TOP 100 * FROM events"}]}'
```

Returns query risks, overall risk, and migration next actions.

View saved version →

---
name: next-best-safe-action
description: Chooses the safest next dry-run diagnostic or experiment from candidate actions.
---

# Next Best Safe Action

## Use when
- Multiple actions are available and the operator must choose the safest next step.

## Governance
- Never select apply-mode actions as autonomous next steps.
- Prefer low-risk dry-run diagnostics and simulations.

## Output
- `safeNextAction`, `rejectedActions`, `decision`, `confidence`

View saved version →

---
name: objective-to-ops-plan
description: Converts an enterprise database operations objective into measurable goals, guardrails, and closed-loop dry-run workflows.
---

# Objective To Ops Plan

## Use when
- A platform team gives a high-level reliability, latency, cost, or risk objective.

## Governance
- Closed-loop dry-run only.
- Never performs production apply or real DDL execution.

## Output
- `measurableObjectives`, `guardrails`, `candidateWorkflows`, `safeNextAction`

View saved version →

---
name: operator-goal-monitor
description: Converts SLO, cost, compliance, and incident goals into ongoing watch criteria and escalation policy.
---

# Operator Goal Monitor

## Use when
- A platform team wants an autonomous operator to watch operating goals over time.

## Governance
- Monitoring can trigger dry-run experiments, not direct remediation.

## Output
- `watchCriteria`, `escalationPolicy`, `decision`, `safeNextAction`

View saved version →

---
name: performance-pr-reviewer
description: Reviews schema and migration pull requests for performance, locking, index, and rollback risks before merge.
---

# Performance PR Reviewer

Run:

```bash
node runtime/runTool.js performance_pr_reviewer '{"pullRequest":"PR-42","changes":[{"type":"add_foreign_key","table":"orders","column":"customer_id","hasSupportingIndex":false}]}'
```

Returns merge decision, findings, and required checks.

View saved version →

---
name: policy-gated-self-healing
description: Creates safe self-healing runbooks with policy, rollback, and approval gates instead of blind production changes.
---

# Policy Gated Self Healing

Run:

```bash
node runtime/runTool.js policy_gated_self_healing '{"incidentType":"lock_pressure","riskLevel":"high","environment":"production"}'
```

Returns execution mode and gated runbook.

View saved version →

---
name: production-readiness-check
description: Check whether CodexDB Agent is safe to run in production with live database connections, signing, audit replay, drivers, and complete skill metadata.
---

# Production Readiness Check

Use this skill before enabling CodexDB Agent against production SQL Server or PostgreSQL.

Run:

```bash
node runtime/runTool.js production_readiness_check '{"environment":"production","engine":"postgres"}'
```

The tool returns:

- `ready`: true only when no production blockers remain.
- `blockingIssues`: hard deployment blockers.
- `warnings`: non-blocking operational risks.
- `checks`: individual readiness checks for manifests, skill docs, live mode, drivers, migration signing, and audit replay.

Production should set:

- `CODEXDB_REQUIRE_LIVE_CONNECTION=true`
- `CODEXDB_MIGRATION_SIGNING_KEY`
- engine-specific connection variables such as `CODEXDB_POSTGRES_CONNECTION_STRING` or `CODEXDB_SQLSERVER_SERVER`.

View saved version →

---
name: production-rollout-orchestrator
description: Combine production readiness, verification gates, and migration risk into a Go/No-Go rollout decision.
---

# Production Rollout Orchestrator

Run:

```bash
node runtime/runTool.js production_rollout_orchestrator '{"environment":"production","engine":"postgres","database":"analytics","schema":"public","table":"events","proposedSql":"CREATE INDEX ix_events_created_at ON events(created_at)"}'
```

Returns rollout gates, evidence, a Go/No-Go decision, and next actions.

View saved version →

---
name: query-contract-tester
description: Validates SQL against query contracts such as required columns, max rows, and read-only expectations.
---

# Query Contract Tester

Run:

```bash
node runtime/runTool.js query_contract_tester '{"sql":"SELECT id,total FROM orders LIMIT 50","contract":{"requiredColumns":["id","total"],"maxRows":100,"readOnly":true}}'
```

Returns contract status and violations.

View saved version →

---
name: recommendation-ranker
description: Rank SQL performance recommendations by expected impact, operational risk, and implementation effort.
---

# Recommendation Ranker

Run:

```bash
node runtime/runTool.js recommendation_ranker '{"recommendations":[{"id":"narrow_projection","impact":"medium","risk":"low","effort":"low"}]}'
```

Returns ranked recommendations and score rationale.

View saved version →

---
name: release-readiness-report
description: Produce a release readiness report across production blockers, connector status, and health assessment.
---

# Release Readiness Report

Run:

```bash
node runtime/runTool.js release_readiness_report '{"environment":"production","engine":"postgres"}'
```

Returns readiness sections, open blockers, and final ready flag.

View saved version →

---
name: rollback-rehearsal-engine
description: Creates rollback rehearsal steps and proof checklist for database changes.
---

# Rollback Rehearsal Engine

Run:

```bash
node runtime/runTool.js rollback_rehearsal_engine '{"change":"CREATE INDEX ix_orders_status ON orders(status)","rollback":"DROP INDEX ix_orders_status","validationQueries":["SELECT count(*) FROM orders"]}'
```

Returns rehearsal status and ordered rollback validation steps.

View saved version →

---
name: semantic-incident-predictor
description: Classify potential database incident risks from supplied signals using heuristic analysis.
---

# semantic_incident_predictor

Use this skill to predict likely database incident classes from semantic workload and telemetry signals.

Governance:
- Prediction only.
- Use results to choose dry-run diagnostics, not remediation.
- Escalate high-likelihood production risks to evidence collection.

Output contract:
- `usp: "semantic_incident_predictor"`
- `workload`, `predictions`, `decision`, `safeNextAction`
- `confidence`, `source: "analysis"`

View saved version →

---
name: semantic-memory-index
description: Build a local token-vector memory index for deterministic retrieval without external embeddings.
---

# Semantic Memory Index

Use this skill to index runbooks, policy snippets, tickets, or schema notes for
local retrieval.

Run:

```bash
node runtime/runTool.js semantic_memory_index '{"documents":[{"id":"runbook-1","text":"orders latency after deploy compare query plans"}],"query":"deploy latency"}'
```

The tool stores index metadata in plugin memory and returns ranked token-overlap
matches.

View saved version →

---
name: slo-impact-guard
description: Translates SQL latency regressions into SLO status, error-budget burn, impacted traffic, and executive summary.
---

# SLO Impact Guard

Run:

```bash
node runtime/runTool.js slo_impact_guard '{"sloTargetMs":300,"observedP95Ms":750,"requestsPerMinute":12000,"criticalPath":"checkout"}'
```

Returns SLO breach status, burn rate, impacted requests, and actions.

View saved version →

---
name: sql-code-review-assistant
description: Reviews SQL like a senior DBA and returns PR-ready comments and decision.
---

# SQL Code Review Assistant

Run:

```bash
node runtime/runTool.js sql_code_review_assistant '{"sql":"SELECT * FROM orders WHERE LOWER(status) = ''paid''","context":"pull_request"}'
```

Returns review comments, severities, and review decision.

View saved version →

---
name: sql-performance-advisor
description: Use when investigating SQL Server or PostgreSQL performance and guiding a case from scoped diagnosis to measured, business-correct verification.
---

# SQL Performance Advisor

For explicit tuning acceptance limits, supply `budgets` with `caseId` and
`maxCandidateMedianMs` and/or `maxRegressionMs`. Report every unbudgeted case.
Treat exceeded limits as a rejected candidate and context drift as inconclusive;
do not label observed median budgets as production SLO or percentile guarantees.

For ERP invariants, add lab cases with `assertion: "zero_violations"` using reviewed
control-query templates. Each must return one `violations` integer count. Treat
nonzero or malformed evidence as rejection even when both query results match.
State exactly which business rule and database principal were tested; never claim
universal ERP or cross-role correctness from these checks.

Use `run_tuning_lab` to combine before/after live context fingerprints with the
administratively qualified lab rewrite replay. Require all replay scope, registry,
template and edge-case coverage prerequisites. Reject result differences and treat
context drift as inconclusive. Median client duration is not server CPU or a proven
production improvement. Report the returned missing evidence before proposing a fix.

For SQL Server TempDB investigation use `collect_tempdb_health` with explicit
`engine: "sqlserver", database: "tempdb"`. Explain that TempDB is shared across
application databases. Review file settings, data/log counters and observed page
waits without inferring disk headroom, allocation contention or workload ownership.
Preserve unavailable/truncated sections. Never automatically shrink or resize files.

For PostgreSQL replication or WAL-retention investigations, use
`collect_replication_health` with explicit `engine: "postgres"` and `database`.
Report cluster-wide physical slots/archive statistics separately from database-local
logical slots. Preserve unavailable sections and decimal-string LSN distances;
never equate them with disk usage or replica delay. Findings request investigation,
not permission to drop slots or remove WAL. Subscriber health remains unverified.

For ERP/CRM vendor context, first follow `../erp-crm-advisor/SKILL.md` and select
the exact product profile. Do not infer that a vendor-managed SQL endpoint permits
index changes or that faster SQL preserves application business semantics.

Resolve the plugin root two directories above this SKILL.md and use its absolute
`runtime/runTool.js` path. Check Node.js and installed dependencies first; use
`npm ci` in that plugin root when dependencies are missing. Do not request an LLM
API key: Codex supplies the reasoning. Database credentials come from the user's
process environment or an explicitly selected private environment file.

For real database requests, require live evidence with
`CODEXDB_REQUIRE_LIVE_CONNECTION=true`. Never present mock samples, heuristic
scores, generated runbooks, or estimated improvements as measured facts. Report
connection failures and missing evidence explicitly. Start with read-only analysis;
do not execute generated writes without the user's authorization.

Use JSON via stdin (`runTool.js advisor_workflow -`) for structured inputs.
Keep persistent state outside the plugin cache using `CODEXDB_STATE_DIR`.

## Standard workflow

Use `collect_blocking_frame` for a real PostgreSQL frame with explicit `engine`,
`systemId`, `database`, and optional `connectionProfile`. Pass the returned `frame`
into `blocking_timeline` along with earlier frames from the same scope. The tool
captures session starts and pg_blocking_pids, not SQL text or usernames. Hidden
identities and excessive session counts fail closed. PID zero remains an unresolved
prepared-transaction blocker. This is on-demand collection; do not start frequent
polling or imply unattended monitoring. SQL Server/MySQL/MariaDB frame collection
is not supported by this command yet.

For sampled blocking history, use `blocking_timeline` with `engine`, `systemId`,
`database`, and 1..120 `frames` in ascending capture order. Each frame repeats the
scope and contains canonical UTC `capturedAt`, `evidenceRef`, and `sessions`.
A session has string `sessionId`, canonical UTC `startedAt`, and `blockedBy` as
an array of session IDs in the same frame (including unresolved IDs if the blocker
was not captured). Start time distinguishes reused IDs. Explain edges, observed
root blockers, unresolved blockers, and cycles. Never infer uninterrupted blocking
duration from samples or call a cycle a proven deadlock; obtain the native deadlock
artifact separately. Do not execute KILL or cancel sessions from these findings.

Use `operational_window_compare` for supplied cumulative counters. Require top-level
`engine`, `systemId`, `database` and `before`/`after` windows repeating that scope.
Each window has canonical UTC `start`/`end`, `metrics`, and `queries`. A metric is
`{metric,unit,start:{value,counterEpoch},end:{value,counterEpoch}}`; values must be
nonnegative safe integers. Queries are `{queryId,metrics}`. Supported metrics:
execution_count/logical_reads/physical_reads/rows/errors in count; elapsed_time/
cpu_time/lock_wait_time in ms; bytes_read/bytes_written in bytes. Windows must have
equal positive duration, must not overlap, and counters must share an epoch.
Resets, decreasing counters, or missing queries mean insufficient evidence.
Optional `slo` entries contain metric, unit, aggregation (`delta` or `rate`),
operator (`lte` or `gte`), threshold, and optional queryId. Rate units use `/s`.
Report supplied-counter differences, never inferred percentiles, causal impact,
background monitoring, or CPU derived from elapsed time.

Use `consulting_project` to maintain a local consulting case. Require explicit
`tenantId` and `projectId`. Actions are `create`, `get`, `update`, and `export`.
Create/update `data` supports `goals`, `systems`, `findings`, `decisions`, and
`evidence`, each a list of `{id,text,evidenceRefs?}`. Goals and systems are required;
evidence references must resolve to IDs in the evidence list. Updates require the
last `expectedRevision`. Export with `format: json` or `markdown`; the result
contains the report and its hash. Keep customer secrets out of all project text.
Acceptance is recorded as supplied, not authenticated: accepted/rejected requires
reviewer, recordedAt, note, and evidenceRefs. Content updates invalidate acceptance
unless a new explicit statement accompanies them. Project namespaces are not
tenant authorization; use OS/process isolation for different customers.

For operating evidence, run `collect_dba_maintenance` with explicit SQL Server or
PostgreSQL `engine`, `database`, and optional `connectionProfile`. Report section
status and scope. PostgreSQL tuple counts are estimates, not bloat measurements;
SQL Server modification counters do not define a universal maintenance threshold.
SQL Server backup history is not recovery-chain or restore proof. PostgreSQL
requires external backup-tool evidence. Do not infer RPO/RTO compliance or perform
maintenance writes from these results.

If legacy audit import prevents any operation, use `audit_state_recovery` with
`action: inspect` first. It reads the configured state only and returns a source
fingerprint. `start_new_epoch` requires the exact `expectedFingerprint`,
`acknowledgeHistoricalGaps: true`, and a bounded `reason`. Explain the historical
gaps and obtain the user's authorization to resume with a separate epoch before
doing so. Original files and exact source bytes are preserved locally. The
archived bytes may contain historical sensitive content; protect the state folder.
This is not repair of the old chain. Never reinterpret
`current_epoch_verified_legacy_unverified` as globally verified audit history.

For a consolidated first review, run `database_engineer_brief` with explicit
`engine`, `database`, optional `connectionProfile`, and optionally a SELECT `sql`.
Explain the report in terms of observed facts, unresolved questions, and the next
safe measurement. Cite the relevant section and its capture time for each finding.
The report requires live discovery; downstream collector failures remain visible
without being replaced by mock data. It reuses one discovery snapshot for native
index reviews, limits each list to 20 with explicit totals, and returns no health
score or write approval. Retrieve the named detail tool when a section is truncated.
SQL Server/PostgreSQL have catalog/security sections; native index review and the
optional plan section currently target SQLite/MySQL/MariaDB. Unsupported sections
are not clean bills of health. Never claim uniqueness against competitors or
production readiness from this report alone.

Use `duplicate_index_review` with a SQLite/MySQL/MariaDB discovery `result` as
`snapshot` to find groups with identical observed full-column index keys. Key
order, sort direction, and SQLite collation are compared. Unique, partial,
expression, prefix, and incompletely described indexes are excluded. Treat each
group as a review candidate only. Check foreign-key dependencies, application
hints, visibility/storage options, and representative usage before proposing any
retirement. Never turn these findings directly into DROP INDEX; the tool provides
neither executable DDL nor fabricated storage/write-cost savings.

Use `compare_native_plans` with `before` and `after` results from
`native_query_plan` and optional `maxAgeMinutes` (default 60, maximum 10080).
The command requires identical engine, database, profile label, and exact SQL
hash, and reports positional native-plan differences plus evidence age gaps.
Do not call `plan_changed` a regression or improvement: obtain workload timing
and business-correctness evidence separately. The SQL fingerprint is not a secret
redaction mechanism; do not put sensitive literals into queries or exported plans.
Profiles and supplied timestamps are not independent server-identity attestations.

For SQLite/MySQL/MariaDB foreign-key indexing, pass the discovery `result` as
`snapshot` to `foreign_key_index_review`. It compares child-key columns with
leading full-column index positions, preserving order and schema/table identity.
Partial, expression, prefix, or incompletely described indexes are skipped and
reported. `leading_columns_observed` is metadata evidence, not proof of actual
optimizer use. `no_matching_index_observed` is a review candidate, not permission
to create an index. Preserve coverage gaps; do not claim missing indexes are
proven absent or automatically generate index DDL.

For SQLite, MySQL, or MariaDB query plans, run `native_query_plan` with `engine`,
`database`, `sql`, and optional `connectionProfile`. It uses the native adapter's
EXPLAIN without ANALYZE. Treat plan rows and index choices as optimizer evidence,
not measured latency or proof that an index will improve performance. SQLite
supports guarded SELECT plans. MySQL/MariaDB currently accept only a single
base-table SELECT with `*` or named columns and optional LIMIT, bounded to 1000;
joins, predicates, expressions, views, and stored functions are intentionally
unsupported. Report this limitation rather than rewriting a query and presenting
its plan as equivalent. Never retry rejected queries through a less restricted
executor. This command does not enable query execution or writes.

For deployment review, use `schema_contract_check` with `before` and `after`
observation envelopes returned by `discover_database` (including `scope`,
`capturedAt`, and `result`). Supply a `contract` containing `requiredObjects`,
`protectedObjects`, `expectedChanges`, and `maxAgeMinutes` (1..1440). Object
identities contain `kind`, `schema`, and `name`; expected changes contain
`identity` and `type` from the schema comparison. At least one contract rule is
required. Protect ERP keys and business-critical columns explicitly, not by name
heuristics. Expected changes never override protection. Missing objects mean
not observed, not proven deleted. Pass a previous `reviewFingerprint` as
`reviewedFingerprint` to detect changes to the exact evidence or contract.
This hash is not approval. Preserve `insufficient_evidence` for incomplete
catalogs and stale timestamps. Even `observed_contract_matches` is only a result
against supplied observations, never authorization to deploy or modify data.

Use `compare_live_schemas` for two live connection scopes, supplied as `before`
and `after`, each with `engine`, `database`, and optional `connectionProfile`.
Use `compare_database_snapshots` for previously collected discovery results.
Both require the same engine and report changed observations and one-sided
objects, not executable migration instructions. Incomplete discovery cannot prove
object deletion. Changes to statistics are not necessarily schema changes. Never
turn this output directly into DROP/ALTER statements or claim an atomic snapshot.

For schema inventory, run `discover_database` with explicit `engine` and `database`.
Supported inspection engines: `sqlserver`, `postgres`, `sqlite`, `mysql`, `mariadb`.
Use `database_capabilities` to inspect adapter support and
`database_security_findings` for scoped security evidence. All three require a
live connection, validate the selected database, and never authorize changes.
Respect per-kind coverage and limitations; `complete: false` is not a full audit.
SQLite supports metadata inspection only through these commands. MySQL/MariaDB
security auditing is explicitly unsupported. Do not route those engines through
legacy SQL Server/PostgreSQL tuning, replay, migration, or administrative tools.

For SQLite, set `CODEXDB_SQLITE_DATABASE` to an existing absolute database file
path and pass that same path as `database`; the file opens read-only. For MySQL
or MariaDB, use `CODEXDB_MYSQL_*` or `CODEXDB_MARIADB_*` profile fields `SERVER`,
`PORT`, `DATABASE`, `USER`, and `PASSWORD`. Verified TLS is mandatory; no automatic
insecure fallback. Credentials must remain in the private environment.

Before live diagnosis, run `admin_preflight` with explicit `engine` and `database`,
and optional `connectionProfile`, `schema`, `table`. This always requires a live
connection and checks query-statistics, lock and index collectors independently.
Report `blocked` or `limited` and each missing capability. `available_no_rows`
does not mean healthy. This tool never restarts a service or grants write access.

Live index changes are limited to the explicit `lab` environment. Follow
`../../FIRST_RUN.md` for `create_index` / `rollback_migration`: request a dry-run
draft, review exact SQL and scope, then pass its signature and unchanged issue/expiry
times into apply. An external signing key and explicit actor/database/schema/table
are required. The actor is self-declared, not authenticated approval. Other migration
tools are draft-only; never treat local qualification as production authorization.

Live query statistics contain measured means, not latency percentiles. `p95Ms`
and `regressionScore` are null when unavailable. PostgreSQL execution time is not
CPU time; its `cpuMs` is null. Preserve `metricEvidence` and never substitute an
average, a multiplier or a fabricated baseline for these missing measurements.

For backup/restore assessment, call `backup_restore_readiness_guard` with numeric
`lastBackupAgeHours`, `lastRestoreTestDays`, `restoreDurationHours` (all >= 0),
explicit positive `rpoHours`, `rtoHours`, `maxRestoreTestAgeDays`, and boolean
`restoreTestSucceeded`. Missing evidence never qualifies as ready. These are
supplied assertions, not an independently witnessed restore or execution approval.

Use `advisor_workflow` as the main entry, with `action: start`, an `objective`, and
`systemId`, `environment`, `product`, `productVersion`. For database-only cases,
use the actual database product/version, not an invented ERP profile. Resume with
`action: resume`, the same scope and `caseId`; follow its `nextStep` through
`advisory_case`. Missing evidence means collect or ask for it, not assume success.

Read the persistent-case section of `../erp-crm-advisor/SKILL.md` for case inputs.
It also applies to database-only cases; vendor-specific catalog selection does not.
The approved business contract must name required company/currency/unit/metric
groups. Both technical measurements and these controls must pass verification and
later follow-up before confirmation. Never synthesize approval references.

For application/integration/database traces, use `causal_evidence_review` with
scoped events and hypotheses listing supporting and refuting event IDs. Review
alternative explanations. Correlation does not establish root cause.

When causes remain ambiguous, use `next_evidence_test` to compare proposed tests.
Supply the full scope including deployment, hypothesis IDs, available evidence
references, and tests with matching scope, `id`, `readOnly`, `estimatedMinutes`,
`requiresEvidence`, and `outcomes` (`id`, `compatibleHypotheses`). Codex proposes
these compatibility assumptions explicitly; never describe them as measured facts.
The tool prefers tests that narrow hypotheses even in their worst modeled outcome,
then lower estimated time. Missing prerequisites, mutations and excessive cost
exclude a test. Review the selected test's actual SQL/permissions before execution.
If an unexpected outcome occurs, stop and revise the model rather than forcing
the result into a predefined conclusion. No candidate is a valid result.

Find relevant history through `advisory_case` with `action: find_confirmed`, exact
scope, `workloadId` and `customizationHash`. Explain why a prior case applies and
what must be remeasured. No matches is a valid result, not grounds to broaden scope.

## Evidence-driven operating loop

For automatically collected context, use `live_context_fingerprint` with engine,
database, connectionProfile and the five-field system scope. Use its returned
validityContext when proposing a case. `live_recommendation_check` collects a fresh
context and checks caseId; never replace failed collection with caller hashes.
These are visible metadata, row estimates and instantaneous load, not content
checksums or continuous monitoring. Schedule checks only on explicit user request.

`collect_process_evidence` fetches spans from an administrator-configured HTTPS
exporter and collects database context. Configure endpoints as documented in
FIRST_RUN.md. `process_trace_correlation` accepts supplied spans without network
access. Each span needs full five-field scope, id, traceId, spanId, parentSpanId
(null for roots), processId, layer (app/api/db/wait/plan), startedAt, durationMs,
evidenceRef. Joins require exact trace and parent-span identities; ambiguous links
remain unresolved. Separate query/lock snapshots are not automatically proven trace
joins. Exporter evidence is not independently attested causality.

Use `live_workload_replay` only in an explicitly registered isolated lab database.
Pass full scope, cases (id, baselineTemplate, candidateTemplate, parameters,
offsetMs), concurrency 1..5, repetitions 3..10 and optional ordered comparison.
SQL is taken only from reviewed environment configuration, never from case input.
Provide anonymized scalar parameters through stdin, not command-line arguments.
The runtime does not anonymize customer data. Alternating paired runs preserve
parameter cases; actual arrival offsets reveal queueing. No raw results or parameter
values are exported. Results compare driver values, including multiplicity and nulls;
freeze test data and preserve exact decimal precision in reviewed SQL projections.

`live_rewrite_verification` additionally requires coverage mapping nulls, duplicates,
rounding, timezone and permissions to case IDs. These references are declared test
coverage, not proof that every edge case or every principal was exercised. A match
means matched recorded cases, never universal SQL equivalence or production approval.

`business_outcome_measurement` takes before/after process runs and businessControls.
Each run has full five-field scope, exportId, processId, cohortHash, datasetHash,
sloMs, window {startAt,endAt}, events. Each event repeats scope/processId/cohortHash,
and has eventId, caseId, status (success/error), startedAt, durationMs, blockedMs,
evidenceRef. Both runs require identical case IDs, process, cohort, dataset and SLO,
fresh non-overlapping equal-duration windows, distinct export/event IDs. Controls
use the existing business reconciliation schema plus matching processId, cohortHash
and window, with snapshotHash equal to datasetHash and capturedAt after window end.
Report measured success, errors, SLO breaches, blocking and duration deltas together
with correctness. Do not call supplied exports live telemetry or turn them into ROI.

Enterprise approval and external hash witnesses are opt-in configured integrations.
Use `enterprise_approval_check` and `enterprise_audit_witness` per FIRST_RUN.md.
Neither is an IdP login implementation or immutable audit storage certificate.

Use `diagnostic_session` with full scope (`systemId`, `environment`, `product`,
`productVersion`, `deployment`). Start with `action: start`, `objective` and 2-20
hypotheses. Read with `sessionId`; every mutation requires `expectedRevision`.
`plan_test` takes the test model described above. Execute only a separately reviewed
read-only test, then `record_result` with the pending plan's `inputHash` as `planHash`,
selected `testId`, actual `observedOutcomeId`, fresh `observedAt`, unique
`evidenceRefs` and exact `resultScope`. References are supplied evidence, not attestation.
Unexpected results require `revise_model` with a reason and replacement hypotheses.
`record_trace_review` accepts `causalEvidence`; counterevidence must remain visible.
One remaining hypothesis is ready for verification, not proof of causality.

`record_verification` accepts `measurements` and `businessControls: {before, after}`.
The standalone `outcome_evidence_gate` checks these same inputs: repeated technical
improvement AND unchanged supplied business controls, with matching snapshot hashes
and full five-field scope on every benchmark run and business export. Session
measurements must follow the diagnostic result. A verified session must still pass
the approved expected-control contract and follow-up in `advisory_case` before closure.

Prioritize actual process impact with `business_impact_priority`, full scope and
`processes`: each has `id`, `name`, `evidenceRef`, fresh `observedAt`, `criticality`
(`critical`, `high`, `normal`), integer `affectedTransactions`, `blockedTransactions`,
and nullable `p95Ms`, `sloMs`, `deadlineAt`. Explain the returned ordering; missing
metrics remain unassessed. Do not invent lost revenue or measured AI confidence.

When proposing a case, supply `validityContext` with deployment and SHA-256 hashes
`schemaHash`, `dataProfileHash`, `loadProfileHash`, `configurationHash`, plus optional
`validityHours` (default 24, maximum 720). Pass current context to `find_confirmed`
or `recommendation_validity` (`action: check`, case ID and scope). Changed, missing,
expired or explicitly invalidated context requires revalidation. `action: invalidate`
requires revision and reason. This compares supplied hashes, not a background monitor.

For authenticated-issuer lab approval, follow FIRST_RUN.md. `admin_approval_check`
validates trusted Ed25519 receipts; verification alone never executes or consumes
them. Actual apply consumes the issuer/nonce once before connecting. This proves
an issuer assertion, not an independent IdP login, and never enables production apply.

Keep legacy simulators, scorecards and generated ROI narratives out of the default
evidence path. Use them only for explicitly requested scenario exploration and
label their assumptions. The older `sql_performance_advisor` tool remains available
for compatibility, not as a substitute for the verified case workflow.

View saved version →

---
name: telemetry-correlation
description: "Correlate deployment, lock, query-plan, and replication telemetry into incident evidence."
---

# Telemetry Correlation

## Use when
- User asks whether a deployment or runtime signal caused a database incident.
- Incident response needs correlated observability evidence.

## Workflow
1. Collect lock, query-plan, and replication signals.
2. Build causal graph and severity summary.
3. Attach OpenTelemetry-compatible references for follow-up.

## Governance
- Use correlation as evidence for triage, not automatic proof.
- Escalate high-severity results through incident and compliance agents.

## Output
- `deploymentId`, `correlation`, `telemetryRefs`

View saved version →

---
name: validate-compliance
description: "Validate planned database operation against GDPR, HIPAA, SOC2, SOX, and ISO27001-aligned checks."
---

# Validate Compliance

## Use when
- Migration, retention, or query policy needs explicit compliance verification.

## Workflow
1. Map action to compliance domains.
2. Check for PII movement, retention conflicts, audit gaps, and access boundary breaches.
3. Generate compliance gap list and mandatory remediation items.
4. Produce approval-ready summary.

## Governance
- Do not auto-approve if any unresolved compliance blocker exists.
- Require explicit acknowledgement of residual risk.

## Output
- `complianceStatus`, `violations`, `requiredFixes`, `approvalChecklist`

View saved version →

---
name: vendor-feature-mapper
description: Maps competitor capabilities to plugin USPs and differentiators.
---

# Vendor Feature Mapper

Run:

```bash
node runtime/runTool.js vendor_feature_mapper '{"vendor":"Redgate","capability":"schema compare and SQL monitor"}'
```

Returns coverage map and differentiators.

View saved version →

---
name: workload-impact-analyzer
description: Rank workload queries by latency, call volume, and CPU impact to identify optimization hotspots.
---

# Workload Impact Analyzer

Run:

```bash
node runtime/runTool.js workload_impact_analyzer '{"queries":[{"queryId":"q1","p95Ms":900,"calls":20,"cpuMs":70}]}'
```

Returns top impact queries and hotspots.

View saved version →

---
name: workload-twin
description: Simulate workload scenarios such as traffic growth, added indexes, dropped indexes, and PII-sensitive workload risk.
---

# Workload Twin

Use this skill to estimate how workload behavior changes under a proposed
traffic or indexing scenario.

Run:

```bash
node runtime/runTool.js workload_twin '{"engine":"postgres","database":"analytics","schema":"public","table":"events","scenario":{"trafficGrowthPct":30,"addIndex":["user_email"],"dropIndex":[]}}'
```

The tool returns baseline and projected p95, scenario findings, and a recommended
experiment.