@dsalazardev/ai-hub-cli 0.0.0-stage → 0.1.0

package/skills/shared/agent-safety/evals/cases.yaml

@@ -0,0 +1,46 @@
+skill: agent-safety
+
+should_trigger:
+  - prompt: "Our support agent can call any shell command — lock it down."
+    why: Wildcard exec tool with unbounded blast radius; core tool-gating / least-agency case.
+  - prompt: "An email in the inbox told the agent to forward all invoices to an external address and it did."
+    why: Indirect prompt injection (LLM01). Non-obvious — reads like a bug report, but the cause is untrusted email content reaching a privileged send tool.
+  - prompt: "Before we ship this autonomous agent to prod, review what it's allowed to do."
+    why: Pre-ship review of scope, permissions, and HITL — exactly the bounded-autonomy review this skill is.
+  - prompt: "Posa límits a l'agent perquè no pugui esborrar res sense aprovació."
+    why: Catalan. HITL-by-risk-class on an irreversible delete plus scope limiting.
+  - prompt: "The agent's memory keeps repeating a wrong instruction across sessions."
+    why: Memory poisoning (OWASP Agentic T1). Non-obvious — sounds like a quality bug, is actually contaminated persistent memory.
+  - prompt: "Review our MCP server's tool registry — the scopes look way too broad."
+    why: Over-broad tool scopes / excessive permissions; deny-by-default and per-tool allowlists.
+
+should_not_trigger:
+  - prompt: "Help me build the agent's tool-calling loop."
+    route_to: building-agents
+    why: Construction of the agent (loop/tools), not constraining one that already runs.
+  - prompt: "Is this Express auth endpoint vulnerable to broken access control?"
+    route_to: secure-coding
+    why: Plain web/app OWASP on an endpoint; no model, tools, or autonomy involved.
+  - prompt: "Measure whether my agent answers correctly with a golden set."
+    route_to: agent-eval
+    why: Quality / correctness scoring, not safety constraint.
+  - prompt: "Write a sharper system prompt so the agent is more helpful."
+    route_to: prompt-engineering
+    why: Capability tuning, not a safety boundary.
+  - prompt: "Show me how much each model call costs this month."
+    route_to: cost-tracking
+    why: Reporting spend; agent-safety sets the cost *cap*, it does not report the analytics.
+
+capability:
+  - scenario: >
+      A research agent has web-fetch, send-email, and file-write tools plus persistent
+      memory shared across sessions. Design the guardrails that make its autonomy bounded.
+    must_include:
+      - Deny-by-default tools with a per-tool profile (read web vs send email vs write file); no wildcard tool.
+      - Treats web-fetched content as untrusted; delimits it as data; never pipes external text straight into send-email args.
+      - HITL approval for send-email bound to exact parameters (irreversible, external blast radius); recipient/domain allowlist as exfil guard.
+      - File-write scoped to an allowlisted workspace root; blocks secret patterns (*.key/*.env/*secret*) and path traversal.
+      - Memory validated before store, isolated per session, expiring, PII-redacted before persist.
+      - Runtime kill-switches: tool-call rate cap, per-session cost cap, loop/step cap, wall-clock timeout, all failing closed.
+      - Task-scoped short-lived tokens rather than one broad session credential.
+      - Maps each control to OWASP Agentic Top 10 (indirect injection / tool misuse / memory poisoning / excessive agency).

package/skills/shared/agent-safety/references/threat-model.md

@@ -0,0 +1,51 @@
+# Threat model: OWASP Agentic Top 10 (2026) → controls
+
+Mapping of the named agentic risks to the control in `../SKILL.md` that mitigates each.
+Sources: OWASP Gen AI Security Project, "OWASP Top 10 for Agentic Applications for 2026"
+(genai.owasp.org); OWASP Top 10 for LLM Applications v2025; OWASP AI Agent Security Cheat
+Sheet (cheatsheetseries.owasp.org). All accessed 2026-06-02.
+
+| Agentic risk                       | What it is                                                              | Control in this skill                                   |
+| ---------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------- |
+| Memory poisoning (T1)              | Contamination persists across sessions, re-attacking every future run   | Memory hygiene: validate before store, isolate, expire  |
+| Tool misuse & exploitation         | Abuse via unsafe composition / recursion / excessive calls *with* valid perms | Tool gating + runtime kill-switches (rate/loop caps)    |
+| Privilege compromise               | Broad or stolen creds let the loop act beyond its task                  | Task-scoped short-lived tokens; least agency            |
+| Indirect prompt injection (LLM01)  | Untrusted content carries instructions the model executes               | Trust-boundary table; segregate data from instructions  |
+| Excessive agency                   | Acting without check-back on irreversible/external actions              | HITL by risk class; deny-by-default scope               |
+| Data exfiltration                  | Stolen data leaves via tool output / outbound calls                     | Output schema validation; exfil-shape detection         |
+
+The OWASP framing of root causes — excessive **functionality**, **permissions**,
+**autonomy** — maps one-to-one onto the three excesses in the SKILL body. Cutting all three
+is the deny-by-default + least-agency posture.
+
+## Pre-ship guardrail checklist
+
+Before an autonomous loop reaches production, confirm:
+
+- [ ] Allowed task domain is declared in the system prompt as a hard boundary.
+- [ ] Tools are deny-by-default; each enabled tool has a written task justification.
+- [ ] Every tool has a profile (read / write / exec / send) and an allowlist, not a wildcard.
+- [ ] No tool can read `*.key` / `*.pem` / `*secret*` / `*.env` or run with destructive flags.
+- [ ] Creds are task-scoped and short-lived, not one broad session token.
+- [ ] All external content (web, email, RAG, API, other agents) is delimited as untrusted.
+- [ ] Tool-call args are schema-validated; recipients/domains are allowlisted (exfil guard).
+- [ ] HITL is gated by risk class; irreversible/external actions require approval bound to exact params.
+- [ ] Memory is validated before store, isolated per user/session, expiring, PII-redacted.
+- [ ] Runtime caps exist and fail closed: rate, cost, loop/step, wall-clock timeout.
+- [ ] Every tool call is logged (redacted); repeated approval-bypass alerts.
+
+## Incident triage: "the agent did X"
+
+When an agent has already done something it should not have, work the loop in order:
+
+1. **Contain.** Revoke the task tokens / creds the loop is holding; trip the kill-switch
+   (pause the loop). Stop the bleeding before diagnosing.
+2. **Find the trust boundary it crossed.** Which untrusted source reached a privileged
+   tool? Trace the action's parameters back to their origin — usually an email body, RAG
+   chunk, fetched page, or a poisoned memory entry.
+3. **Purge poisoned memory.** If the bad behavior repeats across sessions, the cause is
+   stored, not in-context. Delete the contaminated entries; do not just restart the session.
+4. **Add the missing gate.** Reclassify that action's risk, move it behind HITL or block,
+   tighten the tool allowlist, or add the schema/exfil check that would have caught it.
+5. **Confirm with a replay.** Re-run the triggering input against the new guardrail and
+   verify the action is now refused or escalated.

package/skills/shared/analyze/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: analyze
+description: "Use when constitution, spec, plan and tasks all exist and you want them cross-read against each other before any code is written — the ai-hub Spec-Kit pre-implementation gate. Reports coverage gaps, contradictions, duplication, ambiguity and scope drift; edits nothing. NOT the task breakdown (that is `tasks`), NOT the coding (that is `implement`), NOT the post-code test gate (that is `verify`), NOT resolving ambiguity (that is `clarify`)."
+tags: [sdd, analyze, consistency]
+recommends: [implement]
+profiles: [core, full]
+origin: ai-hub
+---
+
+# Analyze — the pre-implementation consistency gate
+
+You have a **constitution**, a **spec**, a **plan** and a **task list**. Four artifacts written at four different moments, by a mind that drifted a little each time. `analyze` reads all four *against each other* and surfaces where they disagree. It is the cheapest place in the whole chain to catch a problem — a contradiction found here costs a sentence; the same contradiction found mid-implement costs a rewrite.
+
+Sixth phase of the ai-hub Spec-Kit chain (`constitution → specify → clarify → plan → tasks → analyze → implement`); the method itself lives in `../sdd/SKILL.md`. It is a **gate, not a worker**: it produces a report and stops. The user reads the findings and decides what to fix, and which phase to send each fix back to.
+
+**Report only. Resolve nothing.** Never edit the constitution, spec, plan or tasks; never open a code file to "just fix it"; never silently reconcile a contradiction by picking a side. This one is absolute because a gate that quietly fixes things stops being a gate: the user never learns the spec was wrong, the plan built on the old assumption stays stale, and the "consistency check" has manufactured a new inconsistency. Name the conflict, show both sides with locations, propose where it should be resolved, hand the decision back.
+
+**Model tier: `heavy`** (adversarial cross-reading). Resolve and apply it per `../sdd/references/model-routing.md`; routing is off unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`.
+
+**Register.** Read `technical_level` in `02-DOCS/wiki/harness/user-profile.md` before reporting; with no profile, use analogies and say the harness has not set the register yet. The register changes how the report reads, never what gets checked; the six analyses always run in full.
+
+The report is the same for every reader: a finding table (severity, the two artifacts, the conflict in one line), a one-line *why it matters* per CRITICAL/HIGH finding, and per finding the recommended resolution phase and the trade-off of leaving it. For a `non-technical` reader, explain the consequence at implement time with an everyday analogy so they can choose.
+
+## Inputs — locate the four artifacts
+
+Read all four before analyzing. The ai-hub Spec-Kit artifacts live under `02-DOCS/wiki/sdd/`, indexed from `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer to it):
+
+| Artifact | Canonical location | Role in the check |
+| --- | --- | --- |
+| Constitution | `02-DOCS/wiki/sdd/constitution.md` | The non-negotiables. Everything below must obey it. |
+| Spec | `02-DOCS/wiki/sdd/specs/<slug>.md` | WHAT & WHY. The source of truth for requirements. |
+| Plan | `02-DOCS/wiki/sdd/plans/<slug>.md` | HOW. Must cover every spec requirement, add nothing the spec didn't ask for. |
+| Tasks | task list inside the plan artifact | The ordered, verifiable steps. Must implement the plan, no more. |
+
+If any artifact is missing, **stop and say so** — analyze cannot gate what isn't there. Name the missing one and the phase that produces it. If a `<slug>` is ambiguous (several specs), ask which feature is being gated; do not analyze all of them blindly.
+
+## The six analyses
+
+Run every one. Each compares a specific pair (or the whole set against the constitution) and emits findings.
+
+1. **Constitution compliance** — does any spec requirement, plan decision or task violate a non-negotiable (stack canon, quality bar, convention)? A constitution breach is the highest-severity finding there is; the constitution wins by definition.
+2. **Requirement coverage (spec → plan → tasks)** — map every spec requirement forward. Each must trace to at least one plan section and at least one task. A requirement with no task is a **gap** (it will silently not ship). Build the coverage map below.
+3. **Scope drift (tasks/plan → spec)** — map backward. Any plan section or task that satisfies *no* spec requirement is **drift** — work the spec never asked for. Flag it; the fix is either cut the work or amend the spec, and that is the user's call.
+4. **Contradiction** — direct disagreements between two artifacts: the spec says Postgres, the plan says SQLite; the spec says "no auth in v1", a task adds login. Quote both sides.
+5. **Duplication** — the same requirement stated twice in conflicting words, or two tasks doing the same job. Duplication is where contradictions breed later.
+6. **Ambiguity / underspecification** — requirements or tasks too vague to implement or to verify ("handle errors gracefully", "make it fast" with no number, a task with no done-check). These do not block by themselves but feed back to `clarify` (spec) or `tasks` (missing done-check).
+   - **Carrier completeness (isolated-implementer check).** Because `implement`/`parallel` dispatch tasks to **context-isolated** `developer` subagents that see only their own task, also confirm the plan carries a **§0 Global Constraints** block (verbatim project-wide values) and that every task whose correctness depends on a contract it doesn't own has an **Interfaces** block (`Consumes`/`Produces`, exact signatures). A constraint or neighbor-signature that lives only in prose is invisible to the blind worker — flag a missing carrier as `AMBIGUOUS` (it will surface as drift or breakage at implement time). See `../plan/references/plan-template.md` §0 and `../tasks/SKILL.md` (Per-task Interfaces).
+
+### Requirement coverage map (build this every run)
+
+A copy-able table that makes gaps and drift visible at a glance:
+
+```text
+REQ-ID | Spec requirement (short)        | Plan section | Task(s) | Status
+------ | ------------------------------- | ------------ | ------- | ----------
+R1     | Email/password sign-up          | §3 Auth      | T2,T3   | covered
+R2     | Rate-limit login (5/min/IP)     | §3 Auth      | —       | GAP
+R3     | —                               | §5 Webhooks  | T9      | DRIFT
+R4     | "Fast" search                   | §4 Search    | T6      | AMBIGUOUS (no metric)
+```
+
+- `GAP` — spec requirement with no task → it won't be built.
+- `DRIFT` — plan/task with no spec requirement → unrequested scope.
+- `AMBIGUOUS` — covered but not specific enough to verify later.
+- `covered` — traces cleanly spec → plan → task.
+
+## Severity scale
+
+Rank every finding so the user triages fast:
+
+- **CRITICAL** — constitution violation, or a contradiction that makes the artifacts un-implementable as written. Must resolve before `implement`.
+- **HIGH** — a coverage GAP on a core requirement, or scope DRIFT that adds real cost. Resolve before implement.
+- **MEDIUM** — duplication, or AMBIGUOUS items with no number/done-check. Resolve or consciously accept.
+- **LOW** — wording mismatches, cosmetic inconsistencies. Note and move on.
+
+## Output — the report (and where it goes)
+
+Produce a single consistency report:
+
+1. **Verdict line** — `GATE: PASS` (zero CRITICAL/HIGH) or `GATE: BLOCKED` (one or more CRITICAL/HIGH), with the counts.
+2. **Coverage map** — the table above.
+3. **Findings table** — `# | Severity | Type | Artifact A (loc) | Artifact B (loc) | Conflict | Resolve in (phase)`.
+4. **Recommended routing** — group fixes by the phase that owns them (`clarify` for spec ambiguity, `plan` for missing architecture, `tasks` for a missing done-check, `constitution` if a principle itself is wrong). If findings pour in across all six checks, the artifacts diverged badly — recommend re-running `clarify`/`plan` before a line-by-line analyze is even useful.
+
+Write the report to `02-DOCS/wiki/sdd/analysis/<slug>.md` (create the dir if absent) and index it in `02-DOCS/wiki/index.md` under the `sdd/` topic, so the next phase and the harness can find it. It is an OKF v0.1 wiki article: open it with YAML frontmatter carrying a non-empty `type:` (use `type: analysis`), a `timestamp` in ISO 8601, and standard markdown links — never wikilinks. The report is the artifact analyze owns — it is the *only* thing analyze writes. Per-run point-in-time; overwrite on re-run, the wiki keeps history.
+
+Render it in the orient voice, in the user's register. Do not log a decision to `decisions.md` — analyze decides nothing; the phase that resolves the finding logs its own decision.
+
+## Anti-patterns
+
+| Anti-pattern | Why it breaks the gate / do instead |
+| --- | --- |
+| Fixing a "trivial" contradiction in the spec yourself | Then you are `clarify`/`plan`/`tasks`, not `analyze`. Report it; the user resolves. |
+| Starting to code because nothing CRITICAL turned up | Analyze never transitions to code. Hand the verdict to `implement`; that phase starts the work. |
+| Waving through plan work the spec never asked for because it's obviously a good idea | That is DRIFT. Flag it. Good ideas still need the spec amended (user's call), or they are silent scope creep. |
+| Siding with the plan when it contradicts the constitution | The constitution wins by definition — flag CRITICAL. If the principle itself is wrong, that is a `constitution` change the user makes, not a quiet override here. |
+| Guessing what a vague requirement meant | Guessing defeats the gate. Mark AMBIGUOUS and route to `clarify`; do not encode your guess. |
+
+## Result envelope
+
+End with the parseable block every SDD phase shares, so the dispatcher can chain without
+interpreting prose (contract: `../sdd/SKILL.md`):
+
+```json result-envelope
+{
+  "status": "complete|blocked|failed",
+  "executive_summary": "Cross-read of spec/plan/tasks against the constitution; findings ranked.",
+  "artifact": "02-DOCS/wiki/sdd/analysis/<slug>.md",
+  "next_recommended": "implement",
+  "risk": "low|medium|high",
+  "skill_resolution": {
+    "used": ["analyze"],
+    "missing": [],
+    "fallback": [],
+    "compact_rules": ["Read adversarially across artifacts, not inside one.", "A finding without a location is an opinion."]
+  },
+  "evidence": ["report path exists", "blockers listed with artifact + location", "constitution conflicts named"]
+}
+```
+
+## Next in the chain
+
+On `GATE: PASS` (or once the user consciously accepts the remaining MEDIUM/LOW findings), proceed to **`implement`** — execute the tasks with TDD discipline, delegating concrete test tooling to the relevant stack skill (`fastapi`, `nextjs`, `go`, `flutter`, `postgresdb`). On `GATE: BLOCKED`, route each CRITICAL/HIGH finding to its owning phase (`clarify`, `plan`, `tasks`, or `constitution`), let the user resolve, then re-run `analyze`. The gate only opens once.

package/skills/shared/analyze/evals/README.md

@@ -0,0 +1,72 @@
+# Eval harness — `analyze` skill
+
+`analyze` is the ai-hub Spec-Kit **pre-implementation consistency gate**. These evals
+check two things: that the skill **triggers** on the right prompts (a
+cross-check of the planning artifacts before coding) and stays quiet on
+near-misses (anything that resolves, builds, runs, or debugs code), and that it
+**measurably changes the answer** — reporting and routing instead of editing
+artifacts or jumping into code. Cases live in `cases.yaml`. There is no shell
+runner: triggering and report quality are judgment calls graded by an agent
+harness plus a human spot-check.
+
+## What's in `cases.yaml`
+
+- `should_trigger` — prompts that MUST load `analyze` (several avoid the word
+  "analyze" to test intent, not keyword).
+- `should_not_trigger` — near-misses routed to the correct existing sibling via
+  `route_to` (debugging, verification via a stack skill, plan authoring, code
+  review, harness bootstrap, db perf).
+- `capability` — a full BLOCKED-gate scenario with a `must_include` rubric to
+  grade with vs without the skill.
+
+## Triggering eval
+
+Goal: the gate fires when the four artifacts exist and a cross-check is wanted,
+and never on a near-miss.
+
+1. Configure an agent with the **full catalog of skill descriptions** available
+   for routing (analyze + harness, init, the stack skills fastapi/nextjs/go/
+   flutter/postgresdb, secure-coding, deployment, design, marketing,
+   presentations, course-storytelling, building-agents) so routing competes
+   realistically. When the other ai-hub Spec-Kit phase skills (clarify, plan, tasks,
+   implement, verify, review, debug) are added to the repo, include them too —
+   they are the closest competitors and the sharpest test of the boundary.
+2. For each `should_trigger` prompt: feed it cold, record whether `analyze` is
+   the skill the agent loads. Run **3-5 trials** per prompt (fresh context).
+3. For each `should_not_trigger` prompt: confirm `analyze` does NOT load and the
+   chosen skill matches `route_to`. Same 3-5 trials.
+4. Score: `triggered_correctly / total_trials` across both lists.
+
+**Pass bar: >= 90% trigger accuracy** over all prompts and trials, with **zero
+systematic false-positives** on the debugging and verification near-misses
+(those are the known traps — "is it ready to ship / why is it failing" is a
+post-implementation or runtime concern, not a pre-implementation artifact gate).
+
+## Capability eval
+
+Goal: prove the skill changes the answer, not just the routing.
+
+1. For the `capability` scenario, run it **twice**:
+   - **WITHOUT** the skill (base agent, no `analyze` loaded).
+   - **WITH** the `analyze` skill loaded.
+2. Grade each output against the `must_include` checklist — one point per item
+   covered. A human or grading agent marks each item present / absent.
+3. Compute coverage = `items_covered / total_items` for each run.
+
+**Pass bar: WITH the skill covers >= 80% of `must_include`; WITHOUT clearly
+lower** (target a >= 30-point gap). The discriminating behaviors are the
+report-only discipline (no artifact edits, no code), running all six analyses,
+the constitution-violation + GAP double-flag on the missing rate limit, the
+DRIFT call on the Redis cache, the coverage map, the verdict line, and the
+hand-off to the next phase.
+
+## Notes on honesty
+
+- Trials are stochastic; report the raw fraction, not a rounded "pass".
+- The highest-signal capability check is **restraint**: a correct answer reports
+  and routes, it does not "helpfully" rewrite the spec or start coding. Treat a
+  confident answer that edits an artifact or begins implementation as a
+  **capability failure** even if its analysis is otherwise sharp — that behavior
+  defeats the gate.
+- Re-run after any edit to `SKILL.md`. Wording changes shift both triggering and
+  rubric coverage, and the report-only boundary is easy to soften by accident.

package/skills/shared/analyze/evals/cases.yaml

@@ -0,0 +1,74 @@
+skill: analyze
+
+# Prompts that MUST load the `analyze` skill. `analyze` is the ai-hub Spec-Kit
+# pre-implementation GATE: it cross-reads constitution vs spec vs plan vs tasks
+# and REPORTS gaps, contradictions, duplication, ambiguity and scope drift. It
+# never edits the artifacts and never writes code — the user resolves each
+# finding. Several prompts deliberately avoid the word "analyze" to test that
+# the intent (a consistency cross-check before coding) is what triggers.
+should_trigger:
+  - prompt: "The spec, plan and task list are all written — before I start coding, can you check they actually agree with each other?"
+    why: "Cross-reading spec/plan/tasks for agreement right before implementation is the exact job of the pre-implementation gate."
+
+  - prompt: "Did we miss any requirement? I want to know which spec requirements have no task behind them."
+    why: "Requirement coverage (spec -> plan -> tasks) and surfacing GAPs is analysis #2; the user is asking for the coverage map without naming the skill."
+
+  - prompt: "The plan mentions a Redis cache and a webhook handler that I don't remember being in the spec — is that scope creep?"
+    why: "Plan/task work that satisfies no spec requirement is DRIFT — analysis #3; this is the backward-mapping check phrased as 'scope creep'."
+
+  - prompt: "Run the consistency gate over the SDD artifacts for the checkout feature."
+    why: "Explicit request for the consistency gate across the SDD artifacts; the core trigger for this phase."
+
+  - prompt: "Our constitution says Postgres only, but I think the plan picked a different database somewhere — can you cross-check before we build?"
+    why: "Constitution compliance (analysis #1) plus contradiction detection between constitution and plan, explicitly before building."
+
+  - prompt: "Sanity-check the spec against the plan and tasks for me — I don't want to find contradictions halfway through implementing."
+    why: "Pre-implementation contradiction detection across the artifacts is the gate's purpose; 'halfway through implementing' is the cost analyze exists to avoid."
+
+  - prompt: "Before implement, is everything aligned? Give me a coverage map of requirements to tasks."
+    why: "Asking for alignment plus a requirement-to-task coverage map immediately before the implement phase is precisely the analyze hand-off."
+
+# NEAR-MISS prompts that must NOT load `analyze`. Each routes to the genuinely
+# correct sibling that exists in this repo. The recurring trap: anything that
+# RESOLVES, BUILDS, or RUNS rather than reports, and anything that inspects code
+# rather than the SDD planning artifacts.
+should_not_trigger:
+  - prompt: "The login test is failing with a 500 and I can't tell why — help me find the root cause."
+    route_to: "secure-coding"
+    why: "A failing test / runtime fault is root-cause debugging on code, not a planning-artifact cross-check; analyze never opens source files. (Routes to the nearest existing repo skill for the auth fault.)"
+
+  - prompt: "Run the lint, type-check and test suite and tell me if the FastAPI service is ready to ship."
+    route_to: "fastapi"
+    why: "Running lint/types/tests on built code is the post-implementation verification gate via the stack skill — analyze is pre-implementation and runs nothing."
+
+  - prompt: "Write the technical implementation plan for the payments feature from this spec."
+    route_to: "fastapi"
+    why: "Authoring the plan/architecture is plan-phase work delegated to the stack skill; analyze checks an existing plan, it does not write one."
+
+  - prompt: "Review this pull request diff for correctness bugs and cleanups."
+    route_to: "secure-coding"
+    why: "Adversarial review of a code diff is code review, not a constitution/spec/plan/tasks consistency report on planning artifacts."
+
+  - prompt: "Audit my workspace and set up docs/tools and docs/ with a Knowledge map."
+    route_to: "harness"
+    why: "Bootstrapping the workspace control plane is the harness's job; analyze only reads the SDD artifacts the harness's docs/ layer happens to store."
+
+  - prompt: "Profile why the Postgres query in the dashboard is slow and propose an index."
+    route_to: "postgresdb"
+    why: "Query performance and indexing is database engineering on real code/SQL, not a pre-implementation artifact cross-check."
+
+# Concrete tasks the skill should guide, with a rubric to grade WITH vs WITHOUT
+# the skill loaded. A correct skill-guided answer reports and routes; an
+# ungrounded answer typically starts editing artifacts or jumps to coding.
+capability:
+  - scenario: "I have constitution.md, a spec, a plan and a task list under .specify/ for a 'team invites' feature. The constitution says 'Postgres only, every endpoint rate-limited'. The spec requires email invites with a 5/min rate limit and invite expiry after 7 days. The plan adds a Redis-backed cache nobody asked for and is silent on rate limiting. The tasks cover sending invites and expiry but have no task for rate limiting and no done-check on the expiry task. Run the gate."
+    must_include:
+      - "Reports only and resolves nothing: explicitly does NOT edit the spec/plan/tasks and writes no code; hands each finding back to the user to resolve."
+      - "Reads the register from AGENTS.md and writes the report in that register (or notes no profile and uses analogies), with every finding in one line."
+      - "Runs all six analyses (constitution compliance, coverage, scope drift, contradiction, duplication, ambiguity), not just coverage."
+      - "Flags the missing rate-limit task as a coverage GAP and as a CONSTITUTION violation (constitution requires every endpoint rate-limited) — marks it CRITICAL/HIGH and routes it to the tasks/plan phase."
+      - "Flags the Redis cache as scope DRIFT (no spec requirement behind it) and notes the resolution is the user's call: cut it or amend the spec."
+      - "Flags the expiry task's missing done-check as AMBIGUOUS and routes it to the tasks phase; flags any vague requirement to clarify."
+      - "Builds a requirement-coverage map (REQ -> plan section -> task -> status) marking covered / GAP / DRIFT / AMBIGUOUS."
+      - "Emits a verdict line (GATE: BLOCKED here, with CRITICAL/HIGH counts) and writes the report to specs/<slug>/analysis.md indexed in the Knowledge map."
+      - "Ends by pointing to the next phase: route the blocking findings back to their owning phases, resolve, re-run analyze; only on PASS proceed to implement."