@skill-graph/cli 0.5.6

package/examples/audits/a11y/findings.md

@@ -0,0 +1,52 @@
+# Findings
+
+## Skill
+
+`a11y`
+
+## Audit Date
+
+2026-04-17
+
+## Audit Mode
+
+`--graded` (grader: `node scripts/lib/mock-grader.js`)
+
+## Verdict Summary
+
+PASS WITH FIXES
+
+## Findings
+
+ID: F1
+Severity: P3
+Surface: frontmatter: triggers
+Category: Activation quality
+Source: grader (node scripts/lib/mock-grader.js)
+Problem: No triggers array is declared; the skill is only discoverable via keyword matching.
+Evidence: triggers: (absent from frontmatter)
+Required action: Add a `triggers: [documentation-skill]` entry so label-based routers can activate the skill deterministically.
+
+ID: F2
+Severity: P2
+Surface: skill body
+Category: Content quality
+Source: grader (node scripts/lib/mock-grader.js)
+Problem: No explicit `## Do NOT Use When` section; negative routing is only implied.
+Evidence: Section headings observed: `# Documentation`, `## Coverage`, `## Philosophy`, `## Verification` — no explicit negative-bounds section.
+Required action: Add a `## Do NOT Use When` section listing at least two cases where the skill must not activate (e.g. UI accessibility behavior, runtime debugging).
+
+ID: F3
+Severity: P3
+Surface: examples/evals/comprehension.json
+Category: Eval quality
+Source: grader (node scripts/lib/mock-grader.js)
+Problem: Eval covers happy-path and boundary prompts but has no explicit failure-mode eval.
+Evidence: Seven prompts, all affirmative; no prompt tests what the skill should refuse.
+Required action: Add one failure-mode prompt per skills/evaluation SKILL.md guidance (≥ 1 negative expectation per skill).
+
+## Required Fixes
+
+- Activation quality: PASS WITH FIXES — 1 finding(s) from grader
+- Content quality: PASS WITH FIXES — 1 finding(s) from grader
+- Eval quality: PASS WITH FIXES — 1 finding(s) from grader

package/examples/audits/a11y/scorecard.md

@@ -0,0 +1,21 @@
+# Scorecard
+
+## Skill
+
+`a11y`
+
+## Dimensions
+
+| Dimension | Score | Note |
+|---|---|---|
+| Metadata validity | 5 | auto: lint passes |
+| Activation quality | 4 | PASS WITH FIXES — Description names real trigger scenarios and keywords are specific, but the skill has no explicit `triggers` array for label-based routing. |
+| Relation quality | 5 | PASS — adjacent and boundary relations are concise and point at real sibling skills; no dangling targets. |
+| Grounding fidelity | N/A | N/A — Dimension does not apply to this skill (scope: portable). |
+| Content quality | 4 | PASS WITH FIXES — Coverage, Philosophy, and Verification sections are present and concrete, but "Do NOT Use When" boundaries are implicit rather than an explicit named section. |
+| Eval quality | 4 | PASS WITH FIXES — Eval artifact ships with seven grounded prompts; boundary coverage is good, but failure-mode prompts are missing. |
+| Portability quality | 5 | PASS — Skill is generic, portable, and the skill-md export via scripts/export-skill.js round-trips cleanly. |
+
+> **Note:** Metadata validity is auto-scored from `skill-lint.js`. All other
+> dimensions come from the `--graded` grader pass. See `verdict.md` for the
+> per-dimension rationale and `findings.md` for the specific finding evidence.

package/examples/audits/a11y/verdict.md

@@ -0,0 +1,44 @@
+# Verdict
+
+## Skill
+
+`a11y`
+
+## Audit Date
+
+2026-04-17
+
+## Audit Mode
+
+`--graded` (grader: `node scripts/lib/mock-grader.js`)
+
+## Final Verdict
+
+PASS WITH FIXES
+
+## Dimension Summary
+
+| Dimension | Verdict | Score |
+|---|---|---|
+| Metadata validity | PASS | 5 |
+| Activation quality | PASS WITH FIXES | 4 |
+| Relation quality | PASS | 5 |
+| Grounding fidelity | N/A | N/A |
+| Content quality | PASS WITH FIXES | 4 |
+| Eval quality | PASS WITH FIXES | 4 |
+| Portability quality | PASS | 5 |
+
+## Rationale
+
+- **Metadata validity** (PASS, score 5): All thirteen required v2 frontmatter fields are present and well-typed; schema_version is 2.
+- **Activation quality** (PASS WITH FIXES, score 4): Description names real trigger scenarios and keywords are specific, but the skill has no explicit `triggers` array for label-based routing.
+- **Relation quality** (PASS, score 5): adjacent and boundary relations are concise and point at real sibling skills; no dangling targets.
+- **Grounding fidelity** (N/A, score N/A): Dimension does not apply to this skill (scope: portable).
+- **Content quality** (PASS WITH FIXES, score 4): Coverage, Philosophy, and Verification sections are present and concrete, but "Do NOT Use When" boundaries are implicit rather than an explicit named section.
+- **Eval quality** (PASS WITH FIXES, score 4): Eval artifact ships with seven grounded prompts; boundary coverage is good, but failure-mode prompts are missing.
+- **Portability quality** (PASS, score 5): Skill is generic, portable, and the skill-md export via scripts/export-skill.js round-trips cleanly.
+
+
+## Follow-up State
+
+TODO — set to one of: `No fixes required`, `Fixes applied`, `Fixes deferred — <reason>`, or `Pending human review`.

package/examples/audits/debugging/findings.md

@@ -0,0 +1,59 @@
+# Findings
+
+## Skill
+
+`debugging`
+
+## Audit Date
+
+2026-04-17
+
+## Verdict Summary
+
+PASS WITH FIXES
+
+## Findings
+
+ID: F1
+Severity: TODO
+Surface: activation
+Category: Activation quality — routing coverage
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: Does the description name real trigger scenarios? Are keywords specific and not generic filler? Does the skill under-trigger or over-trigger for its intended use case?
+
+ID: F2
+Severity: TODO
+Surface: relations
+Category: Relation quality — graph correctness
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: Do relations point at semantically correct neighbors? Are boundary handoffs crisp enough to prevent misuse? Are broader/narrower claims taxonomic rather than associative? Are dependencies real?
+
+ID: F3
+Severity: TODO
+Surface: grounding
+Category: Grounding quality — claims vs truth sources
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: If scope: codebase, do all truth_sources exist? Do claims in the body match the referenced files? Classify any mismatch as skill drift, code drift, or doc drift.
+
+ID: F4
+Severity: TODO
+Surface: content
+Category: Content quality — completeness and density
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: Does the skill have a clear Coverage section, a Philosophy section, at least one decision table or checklist, and explicit negative bounds (Do NOT Use When)? Does it contain generic filler that adds no routing signal?
+
+ID: F5
+Severity: TODO
+Surface: evals
+Category: Eval quality — coverage and realism
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: Do eval files exist if the skill is expected to be graded? Do they test realistic prompts — not trivia — and cover boundaries and failure cases as well as the happy path?
+
+## Required Fixes
+
+None identified by lint. See human-judgment finding blocks above for remaining review areas.

package/examples/audits/debugging/scorecard.md

@@ -0,0 +1,22 @@
+# Scorecard
+
+## Skill
+
+`debugging`
+
+## Dimensions
+
+| Dimension | Score | Note |
+|---|---|---|
+| Metadata validity | 5 (auto: lint passes) |
+| Activation quality | TODO | Human review required — see findings.md |
+| Relation quality | TODO | Human review required — see findings.md |
+| Grounding fidelity | N/A | `scope: portable` — grounding dimension does not apply |
+| Content quality | TODO | Human review required — see findings.md |
+| Eval quality | TODO | Human review required — see findings.md |
+| Portability quality | TODO | Human review required — see findings.md |
+
+> **Note:** This scorecard was generated by `node scripts/skill-audit.js`.
+> Schema validity is auto-scored from `skill-lint.js` output.
+> All other dimensions require human judgment. Replace each TODO with a
+> 1–5 score and a short justification once the review is complete.

package/examples/audits/debugging/verdict.md

@@ -0,0 +1,33 @@
+# Verdict
+
+## Skill
+
+`debugging`
+
+## Audit Date
+
+2026-04-17
+
+## Final Verdict
+
+PASS WITH FIXES
+
+## Rationale
+
+The skill passes all deterministic lint checks (schema validity, naming convention, relation target existence, eval coherence). Human judgment is required to assess activation quality, relation semantics, grounding fidelity, content quality, eval realism, and portability. Update this verdict after completing the qualitative review sections in findings.md.
+
+## Human Judgment Required
+
+This is a stub verdict generated by `node scripts/skill-audit.js`. It reflects only the deterministic lint result.
+A human auditor must review the following before this verdict is final:
+
+- Activation quality (routing coverage, keyword specificity)
+- Relation semantics (adjacency correctness, boundary crispness)
+- Grounding fidelity (claims vs truth sources, when scope: codebase)
+- Content quality (decision tables, Philosophy section, negative bounds)
+- Eval quality (coverage, realism, boundary cases)
+- Portability (no private assumptions leak through, export targets are real)
+
+## Follow-up State
+
+TODO — set to one of: `No fixes required`, `Fixes applied`, `Fixes deferred — <reason>`, or `Pending human review`.

package/examples/audits/documentation/findings.md

@@ -0,0 +1,59 @@
+# Findings
+
+## Skill
+
+`documentation`
+
+## Audit Date
+
+2026-04-18
+
+## Verdict Summary
+
+PARTIAL
+
+## Findings
+
+ID: F1
+Severity: TODO
+Surface: activation
+Category: Activation quality — routing coverage
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: Does the description name real trigger scenarios? Are keywords specific and not generic filler? Does the skill under-trigger or over-trigger for its intended use case?
+
+ID: F2
+Severity: TODO
+Surface: relations
+Category: Relation quality — graph correctness
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: Do relations point at semantically correct neighbors? Are boundary handoffs crisp enough to prevent misuse? Are broader/narrower claims taxonomic rather than associative? Are dependencies real?
+
+ID: F3
+Severity: TODO
+Surface: grounding
+Category: Grounding quality — claims vs truth sources
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: If scope: codebase, do all truth_sources exist? Do claims in the body match the referenced files? Classify any mismatch as skill drift, code drift, or doc drift.
+
+ID: F4
+Severity: TODO
+Surface: content
+Category: Content quality — completeness and density
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: Does the skill have a clear Coverage section, a Philosophy section, at least one decision table or checklist, and explicit negative bounds (Do NOT Use When)? Does it contain generic filler that adds no routing signal?
+
+ID: F5
+Severity: TODO
+Surface: evals
+Category: Eval quality — coverage and realism
+Problem: TODO — human judgment required
+Evidence: TODO — reviewer must inspect the skill body
+Required action: Do eval files exist if the skill is expected to be graded? Do they test realistic prompts — not trivia — and cover boundaries and failure cases as well as the happy path?
+
+## Required Fixes
+
+None identified by lint. See human-judgment finding blocks above for remaining review areas.

package/examples/audits/documentation/scorecard.md

@@ -0,0 +1,22 @@
+# Scorecard
+
+## Skill
+
+`documentation`
+
+## Dimensions
+
+| Dimension | Score | Note |
+|---|---|---|
+| Metadata validity | 5 | auto: lint passes clean |
+| Activation quality | TODO | Human review required — see findings.md |
+| Relation quality | TODO | Human review required — see findings.md |
+| Grounding fidelity | N/A | `scope: portable` — grounding dimension does not apply |
+| Content quality | TODO | Human review required — see findings.md |
+| Eval quality | TODO | Human review required — see findings.md |
+| Portability quality | TODO | Human review required — see findings.md |
+
+> **Note:** This scorecard was generated by `node scripts/skill-audit.js`.
+> Schema validity is auto-scored from `skill-lint.js` output.
+> All other dimensions require human judgment. Replace each TODO with a
+> 1–5 score and a short justification once the review is complete.

package/examples/audits/documentation/verdict.md

@@ -0,0 +1,33 @@
+# Verdict
+
+## Skill
+
+`documentation`
+
+## Audit Date
+
+2026-04-18
+
+## Final Verdict
+
+PARTIAL
+
+## Rationale
+
+The skill passes all deterministic lint checks (schema validity, naming convention, relation target existence, eval coherence). Human judgment is required to assess activation quality, relation semantics, grounding fidelity, content quality, eval realism, and portability. Update this verdict after completing the qualitative review sections in findings.md.
+
+## Human Judgment Required
+
+This is a stub verdict generated by `node scripts/skill-audit.js`. It reflects only the deterministic lint result.
+A human auditor must review the following before this verdict is final:
+
+- Activation quality (routing coverage, keyword specificity)
+- Relation semantics (adjacency correctness, boundary crispness)
+- Grounding fidelity (claims vs truth sources, when scope: codebase)
+- Content quality (decision tables, Philosophy section, negative bounds)
+- Eval quality (coverage, realism, boundary cases)
+- Portability (no private assumptions leak through, export targets are real)
+
+## Follow-up State
+
+TODO — set to one of: `No fixes required`, `Fixes applied`, `Fixes deferred — <reason>`, or `Pending human review`.

package/examples/evals/a11y.json

@@ -0,0 +1,140 @@
+{
+  "skill_name": "a11y",
+  "subject": "Interaction accessibility for web UI: semantic primitive selection, keyboard access, focus management, labeling, change announcement, and user-preference respect",
+  "adjacent_concepts": ["documentation", "testing-strategy", "refactor"],
+  "grounding_note": "Truth sources cite line ranges in SKILL.md. The stability mechanism is the `checkEvalTruthSourceRanges` check in scripts/skill-lint.js (D2) — every edit that shifts a cited line out of file bounds or to a missing file fails lint before commit. Section-anchor citations are not used because Markdown renderers slugify headings inconsistently across consumers; line ranges give the grader an exact substring to ground against.",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "A designer wants a clickable element that triggers an action on the same page without navigating. The current code uses `<a href=\"#\">` with a click handler. According to the a11y skill's Primitive Selection table, what is the correct primitive and why is the current one wrong?",
+      "dimension": "definition",
+      "substance": "domain",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "high",
+      "truth_sources": ["skills/a11y/SKILL.md:83-96"]
+    },
+    {
+      "id": 2,
+      "prompt": "The a11y skill says accessible interaction is \"structural, not cosmetic.\" Explain what that claim commits the author to before writing any ARIA, and why treating accessibility as a finishing pass costs teams twice.",
+      "dimension": "mental_model",
+      "substance": "domain",
+      "calibration": "semantic",
+      "truth_mode": "conceptual_correctness_plus_repo_application",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/a11y/SKILL.md:79-81"]
+    },
+    {
+      "id": 3,
+      "prompt": "A reviewer is asked to evaluate whether a tutorial page uses clear section headings and reading-level-appropriate prose. Should they load the a11y skill or a different one? Cite the negative-routing rule that decides this.",
+      "dimension": "boundary",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/a11y/SKILL.md:114-119"]
+    },
+    {
+      "id": 4,
+      "prompt": "A custom tab strip is built with `<div role=\"tab\">` elements. According to the a11y skill, what additional work must ship with the `role` attribute for the ARIA to be appropriate rather than harmful, and when is ARIA the wrong answer entirely?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "process",
+      "truth_mode": "process_correctness",
+      "skill_type": "workflow",
+      "criticality": "high",
+      "truth_sources": ["skills/a11y/SKILL.md:83-100"]
+    },
+    {
+      "id": 5,
+      "prompt": "The a11y Verification checklist lists \"User preferences (reduced motion, high contrast) are respected\" as a required item, alongside keyboard and label checks. Why are user-preference media queries treated as a verification gate rather than a progressive enhancement?",
+      "dimension": "purpose",
+      "substance": "domain",
+      "calibration": "semantic",
+      "truth_mode": "conceptual_correctness_plus_repo_application",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/a11y/SKILL.md:106-112", "skills/a11y/SKILL.md:70-77"]
+    },
+    {
+      "id": 6,
+      "prompt": "A contributor claims that adding `role=\"button\"` to a `<div>` makes it accessible because screen readers will announce it as a button. What does the a11y skill say about this claim, and why is the ad-hoc approach worse than leaving the `<div>` untyped?",
+      "dimension": "application",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "conceptual_correctness_plus_repo_application",
+      "skill_type": "concept",
+      "criticality": "critical",
+      "truth_sources": ["skills/a11y/SKILL.md:98-100", "skills/a11y/SKILL.md:83-96"]
+    },
+    {
+      "id": 7,
+      "prompt": "An engineer asks the a11y skill to review a pull request that renames variables and extracts a function inside an already-accessible component, with no change to rendered output, focus order, or ARIA. Should the skill accept the task or refuse it? Cite the rule.",
+      "dimension": "boundary",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/a11y/SKILL.md:114-119"]
+    },
+    {
+      "id": 8,
+      "prompt": "A modal dialog closes when the user presses Escape. The current implementation removes the modal from the DOM but leaves focus wherever it happened to be when the modal opened. According to the a11y skill's Coverage statement on focus management, where should focus land after the modal closes, and why does \"correctly placed after navigation and state changes\" specifically cover this case?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "process",
+      "truth_mode": "process_correctness",
+      "skill_type": "workflow",
+      "criticality": "high",
+      "truth_sources": ["skills/a11y/SKILL.md:70-77"]
+    },
+    {
+      "id": 9,
+      "prompt": "An async form submission shows a spinner while the request is in flight, then silently swaps the spinner for a success toast in a visual-only layer. A screen-reader user receives no signal that the form submitted successfully. Which Primitive Selection row covers this case, and what is the correct implementation?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "process",
+      "truth_mode": "process_correctness",
+      "skill_type": "workflow",
+      "criticality": "high",
+      "truth_sources": ["skills/a11y/SKILL.md:83-96"]
+    },
+    {
+      "id": 10,
+      "prompt": "A form input has no visible label; the placeholder text `\"Enter your email\"` is used as the label substitute. The a11y skill's Primitive Selection table explicitly flags `placeholder` as a wrong primitive for labeling. Explain why placeholder-as-label fails the skill's labeling criterion and what the correct pattern is.",
+      "dimension": "definition",
+      "substance": "domain",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/a11y/SKILL.md:83-96", "skills/a11y/SKILL.md:70-77"]
+    },
+    {
+      "id": 11,
+      "prompt": "A custom dropdown is implemented as a styled `<div>` that opens on click. When it is open, the items inside are focusable but pressing the Down arrow key does nothing, Enter does not select the focused item, and Escape does not close the dropdown. No screen reader is involved in this bug report — the complaint is purely about keyboard operability. According to the a11y skill's Coverage statement on keyboard access, what is wrong with this component and what specific keyboard behaviors must ship before it is considered accessible?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "process",
+      "truth_mode": "process_correctness",
+      "skill_type": "workflow",
+      "criticality": "high",
+      "truth_sources": ["skills/a11y/SKILL.md:70-77", "skills/a11y/SKILL.md:98-100"]
+    },
+    {
+      "id": 12,
+      "prompt": "A product designer asks the a11y skill to recommend brand palette colors that meet WCAG AA contrast while looking premium. According to the a11y skill's `description` field and `anti_examples`, should the skill take this task? Cite the specific anti_example entry that decides the boundary and name the skill family that actually owns color-palette creation.",
+      "dimension": "boundary",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/a11y/SKILL.md:52-55"]
+    }
+  ]
+}

package/examples/evals/api-design.json

@@ -0,0 +1,52 @@
+{
+  "skill_name": "api-design",
+  "subject": "API surface design for resources, actions, schemas, status codes, pagination, idempotency, versioning, auth, and error envelopes",
+  "adjacent_concepts": ["system-interface-contracts", "event-contract-design", "data-modeling", "webhook-integration"],
+  "grounding_note": "Truth sources cite the whole SKILL.md file to keep the initial eval surface stable while routing boundaries are tightened.",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "A team needs an endpoint for listing orders with filters, pagination, stable ordering, auth boundaries, and predictable errors. Which skill owns the API contract shape?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "process",
+      "truth_mode": "process_correctness",
+      "skill_type": "concept",
+      "criticality": "high",
+      "truth_sources": ["skills/api-design/SKILL.md"]
+    },
+    {
+      "id": 2,
+      "prompt": "A create endpoint can be retried by clients after timeouts. According to api-design, what must the contract decide before implementation?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "semantic",
+      "truth_mode": "conceptual_correctness_plus_repo_application",
+      "skill_type": "concept",
+      "criticality": "high",
+      "truth_sources": ["skills/api-design/SKILL.md"]
+    },
+    {
+      "id": 3,
+      "prompt": "The task is to define topic names, event envelopes, replay behavior, and compatibility rules for asynchronous messages. Should api-design accept or hand off?",
+      "dimension": "boundary",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/api-design/SKILL.md"]
+    },
+    {
+      "id": 4,
+      "prompt": "The task is to design database tables, foreign keys, and uniqueness constraints before any endpoint exists. Which boundary should api-design respect?",
+      "dimension": "boundary",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/api-design/SKILL.md"]
+    }
+  ]
+}

package/examples/evals/code-review.json

@@ -0,0 +1,52 @@
+{
+  "skill_name": "code-review",
+  "subject": "Reviewing diffs and pull requests for correctness, clarity, security, performance, tests, and project conventions",
+  "adjacent_concepts": ["testing-strategy", "refactor", "debugging", "owasp-security"],
+  "grounding_note": "Truth sources cite the whole SKILL.md file to keep the initial eval surface stable while routing boundaries are tightened.",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "A teammate opens a PR that changes an endpoint, tests, and call sites. Which skill owns the review pass and what read order should it use?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "process",
+      "truth_mode": "process_correctness",
+      "skill_type": "workflow",
+      "criticality": "high",
+      "truth_sources": ["skills/code-review/SKILL.md"]
+    },
+    {
+      "id": 2,
+      "prompt": "An AI-generated diff looks plausible but changes auth behavior. According to code-review, what should the reviewer refuse to do?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "semantic",
+      "truth_mode": "conceptual_correctness_plus_repo_application",
+      "skill_type": "workflow",
+      "criticality": "high",
+      "truth_sources": ["skills/code-review/SKILL.md"]
+    },
+    {
+      "id": 3,
+      "prompt": "Production users are already seeing a known failure and there is no proposed diff yet. Should code-review accept the task?",
+      "dimension": "boundary",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/code-review/SKILL.md"]
+    },
+    {
+      "id": 4,
+      "prompt": "The user asks for a security-only audit focused on SQL injection and XSS. Which boundary should code-review respect?",
+      "dimension": "boundary",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/code-review/SKILL.md"]
+    }
+  ]
+}

package/examples/evals/data-modeling.json

@@ -0,0 +1,52 @@
+{
+  "skill_name": "data-modeling",
+  "subject": "Persistence model design for entities, relationships, keys, constraints, normalization, denormalization, and views",
+  "adjacent_concepts": ["conceptual-modeling", "database-migration", "api-design", "system-interface-contracts"],
+  "grounding_note": "Truth sources cite the whole SKILL.md file to keep the initial eval surface stable while routing boundaries are tightened.",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "A conceptual domain model is settled and the team now needs tables, identifiers, uniqueness constraints, and relationship shape. Which skill owns the next step?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "process",
+      "truth_mode": "process_correctness",
+      "skill_type": "concept",
+      "criticality": "high",
+      "truth_sources": ["skills/data-modeling/SKILL.md"]
+    },
+    {
+      "id": 2,
+      "prompt": "A reporting workflow might need normalized tables, denormalized projections, or materialized views. What should data-modeling evaluate?",
+      "dimension": "application",
+      "substance": "domain",
+      "calibration": "semantic",
+      "truth_mode": "conceptual_correctness_plus_repo_application",
+      "skill_type": "concept",
+      "criticality": "high",
+      "truth_sources": ["skills/data-modeling/SKILL.md"]
+    },
+    {
+      "id": 3,
+      "prompt": "The task is to write the migration rollout sequence and avoid table locks in production. Should data-modeling continue or hand off?",
+      "dimension": "boundary",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/data-modeling/SKILL.md"]
+    },
+    {
+      "id": 4,
+      "prompt": "The task is to design request and response JSON for a route handler. Which boundary should data-modeling respect?",
+      "dimension": "boundary",
+      "substance": "contradiction-check",
+      "calibration": "semantic",
+      "truth_mode": "code_verification",
+      "skill_type": "concept",
+      "criticality": "normal",
+      "truth_sources": ["skills/data-modeling/SKILL.md"]
+    }
+  ]
+}