@skill-graph/cli 0.5.6

package/README.md

@@ -0,0 +1,398 @@
+# Skill Graph
+
+[![Version 0.5.0](https://img.shields.io/badge/version-0.5.0-blue?style=flat-square)](CHANGELOG.md) [![Protocol v1.1.0](https://img.shields.io/badge/protocol-v1.1.0-blueviolet?style=flat-square)](https://github.com/jacob-balslev/skill-metadata-protocol) [![License Apache-2.0 + CC-BY-4.0](https://img.shields.io/badge/license-Apache--2.0%20%2B%20CC--BY--4.0-green?style=flat-square)](LICENSE) [![Exports SKILL.md](https://img.shields.io/badge/exports-SKILL.md-orange?style=flat-square)](https://agentskills.io/specification)
+
+**The library-level system for structured `SKILL.md` libraries. Lint, manifest compiler, router, drift sentinel, and export pipeline.**
+
+Skill Graph operates across a library of [Skill Metadata Protocol](https://github.com/jacob-balslev/skill-metadata-protocol) records. A plain `SKILL.md` gives an agent a procedure to load. Skill Metadata Protocol adds the structured frontmatter contract. Skill Graph turns those declarations into a compiled manifest, routing map, drift sentinel, overlap detector, and export path back to the plain `SKILL.md` format.
+
+## Ecosystem
+
+| Repo | npm | Purpose |
+|------|-----|---------|
+| **[skill-metadata-protocol](https://github.com/jacob-balslev/skill-metadata-protocol)** | `@skill-graph/protocol` | Normative spec + JSON schemas |
+| **skill-graph** *(this repo)* | `@skill-graph/cli` | Library tooling: lint, manifest, router, drift |
+| **[skill-audit-loop](https://github.com/jacob-balslev/skill-audit-loop)** | `@skill-graph/audit` | 5-phase audit procedure |
+| **[skills](https://github.com/jacob-balslev/skills)** | — | Public open-source skill library |
+
+[Skill Graph system](SKILL_GRAPH.md) | [Full template](examples/skill-metadata-template.md) | [Primer](docs/PRIMER.md) | [Field reference](docs/field-reference.md) | [Adoption guide](docs/ADOPTION.md) | [Conformance](docs/CONFORMANCE.md)
+
+> **Surface scope:** The OSS-portable canonical library lives at `skills/skills/` (141 v6-compliant skills). A separate personal/Sales Hub surface at `skills/` (263 pre-v6) is frozen — new skills are curated into the OSS surface only when non-PII, non-Sales-Hub, and generalizable. See [ADR 0008](docs/adr/0008-skill-surface-split-and-curation-policy.md).
+
+## How SKILL.md, Skill Metadata Protocol, and Skill Graph Differ
+
+| Layer | Job | Concrete output |
+|---|---|---|
+| **SKILL.md format** | Portable skill packaging. | A folder with `SKILL.md`, optional `scripts/`, `references/`, and `assets/`. |
+| **Skill Metadata Protocol** | The per-skill relevance contract. | YAML frontmatter that declares identity, scope, taxonomy, activation signals, relations, grounding, eval state, and portability. |
+| **Skill Graph** | The library-level system around the protocol. | Lint, manifest generation, routing, clustering, overlap checks, drift checks, audits, evals, and `SKILL.md` export. |
+
+The distinction matters. The `SKILL.md` format answers "what can this skill do?" Skill Metadata Protocol answers "what is this skill relevant for, where does it belong, and what makes it trustworthy?" Skill Graph answers "how do we operate across a whole library of those declarations?"
+
+## Why More Structured Skills Help
+
+The plain `SKILL.md` format only needs `name` and `description` for the smallest useful skill. That is enough for small libraries. It breaks down when a project has many skills, overlapping domains, multiple workspaces, stale codebase assumptions, or a team that needs to audit why a skill was loaded.
+
+Skill Metadata Protocol makes these questions explicit:
+
+| Question | Protocol fields |
+|---|---|
+| What kind of skill is this? | `type`, `scope`, `version`, `owner` |
+| Where does it belong? | `category`, `domain`, `workspace_tags`, `routing_bundles` |
+| When should it load? | `description`, `keywords`, `triggers`, `examples`, `anti_examples`, `paths` |
+| What is it near, dependent on, or not responsible for? | `relations.related`, `relations.depends_on`, `relations.verify_with`, `relations.boundary`, `relations.broader`, `relations.narrower` |
+| What evidence makes it true? | `grounding.truth_sources`, `grounding.failure_modes`, `grounding.evidence_priority` |
+| Is it current and tested? | `freshness`, `drift_check`, `eval_artifacts`, `eval_state`, `routing_eval`, `eval_last_run`, `lifecycle` |
+| Can it move to another runtime? | `portability`, `compatibility`, `allowed-tools` |
+
+Once those fields exist, a skill library stops being a flat folder of Markdown files. It becomes a map of project knowledge that humans can browse and agents can route through.
+
+## Skill Metadata Protocol
+
+This is a compact example. The full authoring scaffold is [`examples/skill-metadata-template.md`](examples/skill-metadata-template.md).
+
+```yaml
+---
+schema_version: 6
+name: product-page-ux-review
+description: "Use when reviewing a product page's UX, visual hierarchy, interaction patterns, accessibility, and conversion-critical content. Do NOT use for backend Shopify API work, production incident debugging, or general copy editing outside the product-page experience."
+version: 1.0.0
+type: capability
+category: design
+domain: design/ux
+scope: codebase
+owner: design-platform
+freshness: "2026-05-13"
+drift_check:
+  last_verified: "2026-05-13"
+eval_artifacts: planned
+eval_state: unverified
+routing_eval: absent
+keywords:
+  - product page UX
+  - visual hierarchy
+  - Shopify product detail page
+  - conversion friction
+  - dark mode review
+examples:
+  - "Review this Shopify product page for UX problems before launch."
+  - "Map which design skills should be loaded for a dark-mode PDP redesign."
+anti_examples:
+  - "Fix the Shopify webhook signature validation failure."
+  - "Diagnose why the checkout build failed in CI."
+workspace_tags:
+  - ecommerce
+  - shopify
+  - frontend
+routing_bundles:
+  - product-experience
+paths:
+  - app/products/**/*
+  - components/product/**/*
+relations:
+  related:
+    - visual-hierarchy
+    - color-system-design
+    - typography-system
+    - dark-mode-implementation
+  boundary:
+    - skill: shopify
+      reason: "shopify owns API, integration, and platform behavior; this skill owns product-page UX review"
+    - skill: debugging
+      reason: "debugging owns concrete runtime failures; this skill owns pre-release design review"
+  verify_with:
+    - a11y
+    - usability-testing
+grounding:
+  domain_object: Shopify product page UX surface
+  grounding_mode: repo_specific
+  truth_sources:
+    - path: app/products/[handle]/page.tsx
+    - path: components/product/ProductGallery.tsx
+  failure_modes:
+    - visual_hierarchy_unclear
+    - color_contrast_regression
+    - interaction_feedback_missing
+  evidence_priority: repo_code_first
+portability:
+  readiness: scripted
+  targets:
+    - skill-md
+lifecycle:
+  stale_after_days: 90
+  review_cadence: quarterly
+---
+```
+
+The protocol is the contract. The template is just the easiest way to author the contract correctly.
+
+## Library Axes
+
+Skill Metadata Protocol uses several independent axes. They should not be collapsed into one taxonomy.
+
+| Axis | Field | Cardinality | Use |
+|---|---|---:|---|
+| **Archetype** | `type` | one | Skill shape: `capability`, `workflow`, `router`, or `overlay`. |
+| **Scope** | `scope` | one | Where it applies: `portable`, `codebase`, or `reference`. |
+| **Top-level category** | `category` | one | Flat top-level shelf for browsing. |
+| **Domain path** | `domain` | zero or one | Slash-delimited hierarchy, such as `design/ux` or `architecture/events`. |
+| **Project group** | `workspace_tags` | many | Which project families, workspaces, or product areas this skill applies to. |
+| **Routing group** | `routing_bundles` | many | Runtime bundles or dispatch groups. |
+| **Relations** | `relations.*` | many | Typed graph edges between skills. |
+| **Grounding** | `grounding.*` | conditional | Truth sources and failure modes for repo-grounded skills. |
+
+The schema uses `category` for the flat top-level shelf and `domain` for the hierarchical path. Adopters can choose their own values for `category`, `domain`, `workspace_tags`, and `routing_bundles`. This repo currently demonstrates the following values.
+
+### Current Top-Level Categories
+
+These are the current `category` values across the shipped skills and specimen skills:
+
+`content`, `design`, `engineering`, `frontend`, `integrations`, `knowledge`, `quality`, `security`
+
+### Current Domain Paths
+
+| Domain root | Current `domain` paths |
+|---|---|
+| `ai-engineering` | `ai-engineering/analysis`, `ai-engineering/architecture`, `ai-engineering/concepts`, `ai-engineering/context`, `ai-engineering/evaluation`, `ai-engineering/knowledge`, `ai-engineering/knowledge-extraction`, `ai-engineering/knowledge-representation`, `ai-engineering/language`, `ai-engineering/prompts`, `ai-engineering/safety`, `ai-engineering/strategy`, `ai-engineering/tool-use` |
+| `architecture` | `architecture/contracts`, `architecture/decision-records`, `architecture/dependencies`, `architecture/domain-boundaries`, `architecture/domain-discovery`, `architecture/events`, `architecture/technology-selection` |
+| `content` | `content/build/images`, `content/maintenance`, `content/markdown/frontmatter`, `content/migrations`, `content/routing` |
+| `data` | `data/migrations`, `data/modeling` |
+| `design` | `design/information-architecture`, `design/interaction`, `design/ux`, `design/visual` |
+| `engineering` | `engineering/api-design`, `engineering/debugging`, `engineering/observability`, `engineering/performance`, `engineering/quality`, `engineering/version-control` |
+| `frontend` | `frontend/design-system`, `frontend/layout` |
+| `integrations` | `integrations/webhooks` |
+| `modeling` | `modeling/conceptual`, `modeling/ontology`, `modeling/state-machines`, `modeling/taxonomy` |
+| `skill-system` | `skill-system/authoring`, `skill-system/health` |
+
+### Current Project And Routing Groups
+
+`workspace_tags` demonstrated in this repo:
+
+`build-pipeline`, `content`, `markdown`, `migrations`, `skill-authoring`, `static-site`
+
+`routing_bundles` demonstrated in this repo:
+
+`quality`
+
+Downstream projects should add their own tags: `shopify`, `checkout`, `billing`, `design-system`, `docs-site`, `mobile`, `b2b-saas`, `healthcare`, and so on. Tags are not a global ontology. They are routing and maintenance handles for your workspace.
+
+## Skill Clusters And Triangulation
+
+The main payoff is not the YAML. The payoff is that a project can load the right cluster of skills for a real task.
+
+Triangulation means selecting skills from multiple independent signals:
+
+| Signal | Example |
+|---|---|
+| **Project surface** | `workspace_tags: [shopify, frontend]`, `paths: components/product/**/*` |
+| **Top-level and domain category** | `category: design`, `domain: design/ux` |
+| **Method or phase** | `design-thinking`, `user-research`, `ideation`, `prototyping`, `usability-testing` |
+| **Related skills** | `visual-hierarchy`, `color-system-design`, `typography-system`, `dark-mode-implementation` |
+| **Verification skills** | `a11y`, `testing-strategy`, `code-review` |
+| **Negative boundaries** | `shopify` for API work, `debugging` for runtime failures |
+
+For a UX designer working on a Shopify product page, Skill Graph can form a cluster like this:
+
+| Design phase | Skills to load |
+|---|---|
+| **Empathize** | `user-research`, `task-analysis`, `journey-mapping` |
+| **Define** | `problem-framing`, `information-architecture`, `research-synthesis` |
+| **Ideate** | `ideation`, `visual-design-foundations`, `interaction-patterns` |
+| **Prototype** | `prototyping`, `layout-composition`, `design-module-composition`, `color-system-design`, `typography-system`, `dark-mode-implementation` |
+| **Test** | `usability-testing`, `a11y`, `interaction-feedback` |
+| **Project-specific context** | `shopify`, `frontend-architecture`, `design-system-architecture` |
+
+That is the difference between asking an agent to "use the UX skill" and giving it a structured project map: what area is being changed, which design phase the work is in, which sibling skills should co-load, and which nearby skills should not take over.
+
+## Skill Audit Loop
+
+A skill is a contract about a subject. The contract is inert on its own — it stays useful only while the things it was written against still hold. Two of those things move: the codebase the skill is grounded in, and the subject the skill describes. The Skill Audit Loop re-grounds a skill against both. It is what keeps a skill true to its declared `grounding.truth_sources` once time has passed — whether a maintainer runs it across a whole library or an adopter runs it against their own repo.
+
+The loop adapts two useful patterns:
+
+- From [Karpathy's `autoresearch`](https://github.com/karpathy/autoresearch): a tight loop with a constrained action surface, a fixed experiment, a measurable result, and keep-or-revert pressure.
+- From [Stanford d.school design thinking](https://dschool.stanford.edu/resources/design-thinking-bootleg) and [IDEO's design thinking framing](https://designthinking.ideo.com/faq/isnt-design-thinking-a-set-step-by-step-process): human-centered iteration through discovery, framing, ideation, prototyping, testing, and loop-back when evidence changes the problem.
+
+For skills, the loop is:
+
+1. Pick a skill or project area.
+2. Gather evidence: the `SKILL.md`, eval files, manifest entry, related skills, and `grounding.truth_sources`.
+3. Run deterministic checks first: schema lint, relation integrity, manifest validation, routing evals, overlap checks, and drift checks.
+4. Audit the skill as a contract: activation, boundaries, taxonomy, grounding, examples, anti-examples, and verification partners.
+5. Fix the skill or its metadata when the evidence supports the change.
+6. Re-run checks and record the new state.
+7. Move to the next skill or loop back if the fix changed the graph.
+
+This is not "self-improving skills" as a slogan. It is a re-grounding loop with evidence, constraints, and repeatable checks.
+
+## Quick Start
+
+### Using the skills (end users)
+
+The public, ready-to-install skill library lives at [`jacob-balslev/skills`](https://github.com/jacob-balslev/skills) — install with:
+
+```bash
+npx skills add jacob-balslev/skills
+```
+
+That repo holds 141+ canonical skills in plain Agent-Skills shape, indexed on `skills.sh`. You do not need to clone this `skill-graph` tooling repo to consume the skills.
+
+### Running the tooling (authors and maintainers)
+
+Install the CLI from npm:
+
+```bash
+npm install --global @skill-graph/cli
+skill-graph --help
+```
+
+The tooling operates against a skill library configured via [`.skill-graph/config.json`](.skill-graph/config.json) → `workspace.skill_roots`. Post-2026-05-16 monorepo split, the shipped config points at the sibling [`jacob-balslev/skills`](https://github.com/jacob-balslev/skills) repo (canonical 141-skill library). Clone the canonical skills as a sibling of this repo and the tooling resolves automatically — no env-vars needed:
+
+```bash
+git clone https://github.com/jacob-balslev/skills.git ~/Development/skills
+cd ~/Development/skill-graph    # this repo (tooling)
+
+# Validate every skill against the schema and lint rules.
+node scripts/skill-lint.js
+
+# Route a real request and print why each skill was selected, co-loaded, or excluded.
+node scripts/skill-graph-route.js "audit my skills for schema conformance"
+
+# Check grounded skills against recorded truth-source hashes.
+node scripts/skill-graph-drift.js
+```
+
+If your layout differs from the canonical-sibling assumption (e.g., canonical skills cloned elsewhere), override via the `SKILL_GRAPH_WORKSPACE` env-var or edit `.skill-graph/config.json` to point `workspace.skill_roots` at your skill directory.
+
+To regenerate the plain public marketplace staging surface from the canonical source:
+
+```bash
+node scripts/export-marketplace-skills.js
+node scripts/export-marketplace-skills.js --check
+node scripts/verify-skill-md-export.js --plain marketplace/skills
+```
+
+The staging surface lands under `marketplace/` for the two-step sync into `jacob-balslev/skills` (see `AGENTS.MD § Release sync`). The canonical end-user install path is `npx skills add jacob-balslev/skills` — that is the path consumers see, and it must remain working before any marketplace badge is added.
+
+The npm package exposes the same scripts through a `skill-graph` binary:
+
+```bash
+skill-graph init my-skill            # Scaffold a new SKILL.md from the template
+skill-graph add debugging            # Install a skill from the marketplace
+skill-graph lint                     # Validate all SKILL.md files
+skill-graph audit my-skill           # Seed or run a single-skill audit
+skill-graph route "schema drift"     # Select skills for a query
+skill-graph drift                    # Check truth-source hashes
+skill-graph export                   # Generate marketplace export surface
+skill-graph evolve --top 5           # Run the continuous improvement loop
+```
+
+Run `skill-graph --help` to see all commands (including legacy aliases).
+
+## What You Get
+
+| Tool | Purpose |
+|---|---|
+| `scripts/skill-lint.js` | Per-skill schema validation, relation target checks, eval coherence, required body sections, routing-quality checks. |
+| `scripts/check-protocol-consistency.js` | Cross-artifact checks so schemas, docs, generated field references, and sample manifests stay aligned. |
+| `scripts/generate-manifest.js` | Compiles all skills into a deterministic manifest for routing and downstream tooling. |
+| `scripts/skill-graph-route.js` | Reference router that explains selected, co-loaded, and excluded skills. |
+| `scripts/skill-graph-routing-eval.js` | Checks `examples` and `anti_examples` against router behavior. |
+| `scripts/skill-graph-drift.js` | Hashes `grounding.truth_sources` and reports drift, broken sources, stale skills, or missing baselines. |
+| `scripts/skill-overlap.js` | Finds overlapping skill ownership and routing ambiguity. |
+| `scripts/skill-audit.js` | Generates audit artifacts and optional graded review prompts. |
+| `scripts/export-skill.js` | Exports protocol-enriched skills back to plain `SKILL.md` shape. |
+| `scripts/export-marketplace-skills.js` | Generates and validates the public plain `SKILL.md` marketplace surface with provenance, description-limit, privacy, and link gates. |
+
+## Repository Map
+
+| Path | Purpose |
+|---|---|
+| [`SKILL_GRAPH.md`](SKILL_GRAPH.md) | Library-level system model and authority tiers. |
+| [`schemas/`](schemas/) | Skill and manifest JSON Schemas, including pinned v4, v5, and v6 copies; the unversioned mirror tracks v6. |
+| [`examples/skill-metadata-template.md`](examples/skill-metadata-template.md) | Copyable authoring template. |
+| [`examples/projects/markdown-static-site/`](examples/projects/markdown-static-site/) | Specimen project showing codebase-grounded skills. |
+| [`docs/field-reference.md`](docs/field-reference.md) | Field-by-field reference. |
+| [`docs/field-decision-guide.md`](docs/field-decision-guide.md) | Decision tables for hard field choices. |
+| [`docs/quality-doctrine.md`](docs/quality-doctrine.md) | Quality bar for preserving scope, readable names, organization-over-trimming, compression, and verification. |
+| [`docs/SKILL-MD-FORMAT-COMPATIBILITY.md`](docs/SKILL-MD-FORMAT-COMPATIBILITY.md) | How export maps protocol-enriched skills back to plain `SKILL.md`. |
+| [`docs/marketplace-syndication.md`](docs/marketplace-syndication.md) | How to syndicate the full library to public `SKILL.md` marketplaces and mine gaps for new skills. |
+
+**Sibling repos** (post-2026-05-16 monorepo split — content moved out of this tooling repo):
+
+| Repo | Purpose |
+|---|---|
+| [`jacob-balslev/skill-metadata-protocol`](https://github.com/jacob-balslev/skill-metadata-protocol) | Normative protocol contract (formerly `SKILL_METADATA_PROTOCOL.md` here). |
+| [`jacob-balslev/skills`](https://github.com/jacob-balslev/skills) | Canonical 141-skill library (formerly `skills/` here). |
+| [`jacob-balslev/skill-audit-loop`](https://github.com/jacob-balslev/skill-audit-loop) | Repeatable audit workflow (formerly `SKILL_AUDIT_LOOP.md` + `SKILL_AUDIT_CHECKLIST.md` here). |
+
+## Releasing (Maintainers)
+
+### Local development note (pnpm workspace)
+
+If you have a parent `pnpm-workspace.yaml` above this directory (e.g. when this repo is checked out inside the `Development` monorepo), pnpm will absorb `skill-graph/` into the parent workspace. That blocks standalone `pnpm-lock.yaml` generation here. For local dev/lockfile work, run:
+
+```bash
+pnpm install --ignore-workspace
+pnpm install --frozen-lockfile --ignore-workspace
+```
+
+CI is unaffected — `.github/workflows/publish.yml` runs in a clean checkout with no parent workspace, so the unflagged `pnpm install --frozen-lockfile` works correctly there.
+
+### Prerequisites
+
+Before cutting the first release, ensure these one-time steps are done:
+
+1. **npm org** — the `@skill-graph` npm org must exist. The npm CLI does NOT support `npm org create`; orgs are created via the website. Go to https://www.npmjs.com/org/create, enter `skill-graph` as the org name, pick "Unlimited public packages — Free", and add yourself as owner. Verify with `npm org ls skill-graph`.
+2. **NPM_TOKEN secret** — generate a publish token (`npm token create --read-only=false`) and add it as `NPM_TOKEN` in the GitHub repo secrets (`Settings → Secrets and variables → Actions`). For finer scoping, manage tokens at https://www.npmjs.com/settings/<user>/tokens.
+
+### Cutting a release
+
+```bash
+# Bump version, commit, and tag in one step
+pnpm version patch   # or minor, or major
+
+# Push the commit and the tag — CI picks up the tag and publishes
+git push && git push --tags
+```
+
+The publish pipeline at `.github/workflows/publish.yml` triggers on any `v*.*.*` tag, runs `pnpm test`, then publishes `@skill-graph/cli` with provenance attestation. The npm package is always published from CI — do not run `pnpm publish` locally.
+
+### Manual prereq summary
+
+| Step | Who | Command |
+|------|-----|---------|
+| Create `@skill-graph` npm org (once) | Jacob | https://www.npmjs.com/org/create — pick "Unlimited public packages — Free" |
+| Add `NPM_TOKEN` GitHub secret (once) | Jacob | GitHub Settings → Secrets |
+| Cut a release | Maintainer | `pnpm version <patch\|minor\|major> && git push --tags` |
+
+> CLI distribution via npm (`@skill-graph/cli`) is separate from skill library syndication. The skill library is published from [`jacob-balslev/skills`](https://github.com/jacob-balslev/skills) via `npx skills add jacob-balslev/skills`. See [`docs/marketplace-syndication.md`](docs/marketplace-syndication.md) for the skill library syndication workflow. See SH-6110 for install verification.
+
+## What This Is Not
+
+Skill Graph is not:
+
+- a hosted skill marketplace
+- an agent runtime
+- persistent agent memory
+- a replacement for `AGENTS.md` or `CLAUDE.md`
+- a prompt library
+- a guarantee that every skill is correct
+
+It is a structured protocol and reference toolchain for making skills easier to route, cluster, verify, maintain, and port.
+
+## External Context
+
+Skill Metadata Protocol is designed to sit next to existing agent-context conventions, not replace them:
+
+- [SKILL.md format reference](https://agentskills.io/specification) describes the portable base skill layout used by multiple agent runtimes.
+- [AGENTS.md](https://agents.md/) and [Codex AGENTS.md docs](https://developers.openai.com/codex/guides/agents-md) define always-on repository instructions.
+- [Claude Code memory docs](https://code.claude.com/docs/en/memory) document one memory model for persistent context.
+- [Model Context Protocol](https://github.com/modelcontextprotocol/modelcontextprotocol) and [OpenTelemetry Specification](https://github.com/open-telemetry/opentelemetry-specification) are useful examples of protocol-first repos that separate spec, schema, docs, and reference tooling.
+- The project framing was also discussed in [GitHub Discussion #1](https://github.com/jacob-balslev/skill-graph/discussions/1) and the linked [Bluesky thread](https://bsky.app/profile/did:plc:dydxbat6yyyhjfaln22sx66t/post/3mln2lefdi22u).
+
+## Status
+
+Latest release checkpoint: **0.5.0 (2026-05-13)**. The current contract is `schema_version: 6` — see [`skill-metadata-protocol/schemas/skill.v6.schema.json`](https://github.com/jacob-balslev/skill-metadata-protocol/blob/main/schemas/skill.v6.schema.json) for the authoritative shape and [`skill-metadata-protocol/docs/migrations/v5-to-v6.md`](https://github.com/jacob-balslev/skill-metadata-protocol/blob/main/docs/migrations/v5-to-v6.md) for the migration procedure. The local `schemas/` directory pins v4, v5, and v6 copies for tooling that consumes the schemas directly.
+
+Code is licensed under Apache-2.0. Skill content and documentation are licensed under CC-BY-4.0 where noted. See [`LICENSE`](LICENSE) and [`NOTICE`](NOTICE).