agent-skillboard 0.1.0

package/docs/profiles.md

@@ -0,0 +1,166 @@
+# Source Profiles
+
+SkillBoard imports skill repositories through **source profiles**. A profile is a YAML file that tells SkillBoard how to find `SKILL.md` files in a source tree and how to classify the skills it finds, without writing repository-specific code.
+
+## Why Profiles Exist
+
+Agent skill repositories come in many layouts:
+
+- `skills/<category>/<skill>/SKILL.md`
+- `<skill>/SKILL.md`
+- deprecated or in-progress folders with special rules
+- namespaces such as `matt.tdd` or `anthropic.requirement-intake`
+
+Instead of hardcoding `if (repo === "mattpocock/skills")` branches, SkillBoard reads a declarative profile. The same importer code works for every source.
+
+## Profile Location
+
+Built-in profiles ship with the CLI under `profiles/`:
+
+- `profiles/mattpocock-skills.yaml`
+- `profiles/anthropics-skills.yaml`
+- `profiles/oh-my-openagent.yaml`
+- `profiles/wshobson-agents.yaml`
+- `profiles/voltagent-awesome-agent-skills.yaml`
+
+Project-specific profiles can live under `.skillboard/profiles/`:
+
+```bash
+skillboard import --profile .skillboard/profiles/my-team.yaml --source-root /path/to/repo
+```
+
+## Profile YAML Structure
+
+```yaml
+id: github.mattpocock.skills
+source: mattpocock/skills
+kind: marketplace
+namespace: matt
+target_path_prefix: matt
+scope: user-global
+default_status: vendor
+default_invocation: manual-only
+default_exposure: exported
+default_category: uncategorized
+category_path_segment: 1
+skill_paths:
+  - "skills/**/SKILL.md"
+  - "*/SKILL.md"
+path_rules:
+  - pattern: "skills/deprecated/**/SKILL.md"
+    status: deprecated
+    invocation: deprecated
+    category: deprecated
+  - pattern: "skills/in-progress/**/SKILL.md"
+    status: candidate
+    category: in-progress
+provided_components:
+  - skills
+permission_risk: medium
+rollback: reinstall
+```
+
+### Fields
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `id` | yes | Unique install-unit id used in `skillboard.config.yaml`. |
+| `source` | no | Human-readable source identifier, e.g. `owner/repo` or install command. |
+| `kind` | yes | One of the install-unit kinds: `skill`, `plugin`, `marketplace`, `harness`, `mcp-server`, `hook`, `agent`, `lsp`. |
+| `namespace` | no | Prefix added to every generated skill id. Empty means use the bare slug. |
+| `target_path_prefix` | no | Prefix added to every generated skill `path`. |
+| `scope` | no | Install scope: `user-global`, `project`, `local`, `admin`. |
+| `default_status` | no | Default skill `status`: `discovered`, `vendor`, `candidate`, `active`, `quarantined`, `blocked`, `deprecated`, etc. |
+| `default_invocation` | no | Default `invocation`: `manual-only`, `router-only`, `workflow-auto`, `blocked`, `deprecated`. `global-auto` is downgraded to `blocked`. |
+| `default_exposure` | no | Default `exposure`: `exported`, `global-meta`, `unit-managed`, `private`. |
+| `default_category` | no | Fallback category when no path rule or segment applies. |
+| `category_path_segment` | no | Reads a path segment from the matched `SKILL.md` path as category. `skills/engineering/tdd/SKILL.md` with segment `1` becomes `engineering`. |
+| `skill_paths` | yes | Glob patterns that identify `SKILL.md` files to import. |
+| `path_rules` | no | First-match overrides for paths such as `deprecated/**` or `in-progress/**`. |
+| `provided_components` | no | Components supplied by the install unit: `skills`, `commands`, `hooks`, `mcp_servers`. |
+| `permission_risk` | no | `low`, `medium`, `high`. |
+| `rollback` | no | Rollback strategy hint. |
+
+## How to Add a Built-In Profile
+
+1. **Create `profiles/<short-name>.yaml`.**
+
+   Pick a short, descriptive file name. The `id` field should be a stable dotted identifier.
+
+2. **Choose defaults that keep imported skills inactive.**
+
+   New external skills should default to `vendor` or `candidate` with `manual-only` or `router-only` invocation. Do not use `global-auto` for external repositories.
+
+3. **Add `path_rules` for repository conventions.**
+
+   If the repo has `deprecated/`, `in-progress/`, or `archive/` folders, override status and invocation there.
+
+4. **Test the profile against a real or fixture source.**
+
+   ```bash
+   skillboard import \
+     --profile github.myorg.skills \
+     --source-root /path/to/myorg-skills \
+     --out .skillboard/reports/myorg-import.yaml
+   ```
+
+   Review the emitted fragment before merging.
+
+5. **Add an integration test.**
+
+   Put a minimal fixture under `test/fixtures/` or `examples/` and add a test in `test/source-profiles.test.mjs` or `test/multi-source-integration.test.mjs`.
+
+6. **Update `package.json` `files` if needed.**
+
+   Profiles are already included via `"files": [..., "profiles", ...]`.
+
+## Example Walkthrough
+
+Given this repository layout:
+
+```
+myorg-skills/
+  engineering/
+    tdd/
+      SKILL.md
+    review/
+      SKILL.md
+  deprecated/
+    old-linter/
+      SKILL.md
+```
+
+and this profile:
+
+```yaml
+id: github.myorg.skills
+source: myorg/skills
+kind: marketplace
+namespace: myorg
+target_path_prefix: myorg
+scope: user-global
+default_status: vendor
+default_invocation: manual-only
+default_exposure: exported
+category_path_segment: 0
+skill_paths:
+  - "**/SKILL.md"
+path_rules:
+  - pattern: "deprecated/**/SKILL.md"
+    status: deprecated
+    invocation: deprecated
+    category: deprecated
+provided_components:
+  - skills
+permission_risk: medium
+```
+
+SkillBoard produces:
+
+- `myorg.tdd` → path `myorg/tdd`, category `engineering`, status `vendor`, invocation `manual-only`
+- `myorg.review` → path `myorg/review`, category `engineering`
+- `myorg.old-linter` → path `myorg/old-linter`, category `deprecated`, status `deprecated`, invocation `deprecated`
+
+## When to Use a Detector Instead
+
+Profiles cover most repository layouts. If a source mutates config files, exposes components only through command output, or requires parsing a non-YAML manifest, use `skillboard inventory detect` or write a small detector. See [adapters.md](adapters.md) for the adapter/detector model.

package/docs/rollout-runbook.md

@@ -0,0 +1,60 @@
+# SkillBoard Rollout Runbook
+
+Use this runbook when SkillBoard is operated as an enterprise rollout gate for agent skills, plugins, harnesses, hooks, MCP servers, and workflow bundles.
+
+## Preconditions
+
+- Run on Node.js 20 or newer.
+- Keep `skillboard.config.yaml` as the source of truth.
+- Use `--json` for automation; rollout commands do not prompt or wait for user input.
+- Treat plugin, runtime extension, and external package sources as blocked from automatic activation unless an explicit reviewed/trusted policy is recorded in config.
+
+## Status and exit codes
+
+- `healthy`: exit code `0`; policy and source gates passed.
+- `safe-mode`: exit code `1`; reserved for usable-but-limited rollout states.
+- `strict-failed`: exit code `2`; policy/source gates failed and automation must not apply rollout.
+- `apply-failed`: exit code `3`; apply was blocked or failed before a committed transaction.
+- `rollback-needed`: exit code `4`; apply failed after mutation risk and operator rollback is required.
+
+## Standard rollout flow
+
+```bash
+skillboard rollout audit --config skillboard.config.yaml --skills skills --json
+skillboard rollout plan --config skillboard.config.yaml --skills skills --json
+skillboard rollout apply --config skillboard.config.yaml --skills skills --json
+skillboard rollout report --config skillboard.config.yaml --skills skills --json
+```
+
+`audit` and `plan` are read-only. `apply` creates a transaction directory under `.skillboard/rollouts/` with a manifest, report, state file, and exact-byte backup of the config before committing.
+
+## Source gate policy
+
+Rollout blocks unreviewed high-risk runtime/plugin/external sources when they could become active through model-selectable skills. Before apply, review each relevant install unit and set a reviewed/trusted trust level only after source ownership, pinning, and expected runtime components are understood.
+
+## Emergency rollback
+
+If a rollout report or operator check indicates `rollback-needed`, restore the committed transaction by id:
+
+```bash
+skillboard rollout rollback \
+  --config skillboard.config.yaml \
+  --skills skills \
+  --transaction rollout-YYYYMMDDHHMMSS \
+  --json
+```
+
+Rollback reads `.skillboard/rollouts/<transaction>/manifest.json` and restores configured files from their recorded backups. The config restore is byte-for-byte so accidental operator edits made after apply are removed.
+
+## Fleet report handling
+
+Use `skillboard rollout report --json` for dashboards and schedulers. The report includes deterministic status counters for `healthy`, `safe-mode`, `strict-failed`, `apply-failed`, and `rollback-needed`. Local paths and obvious secret/token values are redacted from machine-readable payloads by default.
+
+## Release gate checklist
+
+- `npm run check`
+- Node 20: `npx -y -p node@20 -c 'node -v && npm -v && npm run check'`
+- `git diff --check`
+- `npm audit --audit-level=moderate`
+- `npm pack --dry-run --json`
+- Secret scan changed source, docs, and config files before publishing or pushing.

package/docs/user-flow.md

@@ -0,0 +1,231 @@
+# First-Time Skill Control Flow
+
+This flow assumes a user installed SkillBoard because they want to see and
+control which agent skills can affect a workflow.
+
+## 1. Bootstrap The Control Plane
+
+```bash
+skillboard init
+skillboard doctor
+```
+
+`init` creates the config, local `skills/` directory, report directories, and
+agent bridge blocks. It also scans known local agent skill locations and records
+discovered skills as managed entries. Trusted user-local skills, including
+Hermes profile skills under `.hermes/profiles/*/skills`, are immediately
+attached to a generated manual workflow as `status: active` with
+`invocation: manual-only` when the project has no workflows yet, so existing
+manual skills keep working through `can-use` and guard checks without creating
+legacy-state warning noise. Runtime-supplied or external skills are quarantined
+until an explicit source and workflow decision exists. Reviewable items should
+appear as "Needs your decision"; only provenance failures, explicit user blocks,
+disabled sources, or other hard policy failures should remain "Blocked for
+safety". Use
+`skillboard doctor --strict` when review-needed safe-mode warnings should fail
+automation.
+
+When the user asks the agent what it can use, the agent should run
+`skillboard brief --json` first and answer from the brief rather than reading
+skill files directly. The user-facing text output uses sections such as "What
+your AI can use now", "Needs your decision", and "Blocked for safety"; text
+briefs include previewable action cards by default, while the JSON form keeps
+action cards opt-in. For large skill sets, the default text brief stays compact:
+counts, top categories, next safe action, short previews per section, and short
+action summaries. Use `skillboard brief --verbose` when you need every skill and
+full copyable command details. Those action cards are suggestions only: the
+agent should pick one current action id from the brief, request confirmation
+before applying risk-bearing changes, then run
+`skillboard apply-action <action-id> --config skillboard.config.yaml --skills skills --yes --json`
+with `--workflow <name>` when a workflow is selected. The agent should read the
+returned post-apply brief before making the next availability claim.
+`apply-action` re-resolves the current brief and refuses stale action ids instead
+of replaying cached action-card shell text.
+
+Run this again after installing agent packages, plugins, workflow bundles, or
+harnesses:
+
+```bash
+skillboard inventory refresh --dry-run
+skillboard inventory refresh
+```
+
+## 2. Add A User-Owned Skill
+
+Create the skill under the project `skills/` directory:
+
+```bash
+mkdir -p skills/user-helper
+$EDITOR skills/user-helper/SKILL.md
+```
+
+Register it without making it callable yet:
+
+```bash
+skillboard add skill user.helper \
+  --path user-helper \
+  --config skillboard.config.yaml \
+  --skills skills \
+  --dry-run
+
+skillboard add skill user.helper \
+  --path user-helper \
+  --config skillboard.config.yaml \
+  --skills skills
+```
+
+The dry run reports semantic YAML changes and leaves the config untouched. The
+real command adds the skill as a direct user-owned `candidate` by default.
+
+Create a workflow or harness for the skill without hand-editing YAML:
+
+```bash
+skillboard add harness codex \
+  --config skillboard.config.yaml \
+  --skills skills
+
+skillboard add workflow daily-workflow \
+  --harness codex \
+  --skill user.helper \
+  --config skillboard.config.yaml \
+  --skills skills
+```
+
+When `add workflow` attaches a `candidate` / `manual-only` skill, it promotes the
+skill to `active` with `invocation: manual-only` for that workflow. It still
+does not grant automatic model invocation.
+
+## 3. Inspect Influence Before Use
+
+```bash
+skillboard explain user.helper \
+  --config skillboard.config.yaml \
+  --skills skills
+
+skillboard can-use user.helper \
+  --workflow daily-workflow \
+  --config skillboard.config.yaml \
+  --skills skills
+
+skillboard impact disable user.helper \
+  --config skillboard.config.yaml \
+  --skills skills \
+  --out .skillboard/reports/user-helper-impact.md
+```
+
+`explain` shows source class, trust, owner install unit, workflow roles, and
+capability roles. `can-use` is the machine-readable gate for agents. `impact`
+shows which workflows and required outputs would be affected before disabling or
+removing a skill.
+
+For an actual invocation, `brief` is not the final permission check. Agents
+should run `skillboard guard use ...` immediately before calling a skill so
+state changes made after the brief cannot slip through.
+
+When wiring a guard hook from an action card, keep `apply-action` as the
+action-card primary flow:
+
+```bash
+skillboard apply-action <action-id> --workflow daily-workflow --config skillboard.config.yaml --skills skills --yes --json
+```
+
+The raw hook commands are underlying manual operator detail for previewing and
+materializing an executable guard hook outside the action-card approval loop:
+
+```bash
+skillboard hook install --workflow daily-workflow --config skillboard.config.yaml --skills skills --out .skillboard/hooks/daily-workflow-guard.sh --dry-run --json
+skillboard hook install --workflow daily-workflow --config skillboard.config.yaml --skills skills --out .skillboard/hooks/daily-workflow-guard.sh
+```
+
+For direct manual hook installation, inspect the JSON `planned.preview.shell`
+before an operator materializes the matching non-dry-run hook command.
+
+## 4. Enable, Disable, Or Prefer
+
+Enable the skill only for the workflow that should see it:
+
+```bash
+skillboard activate user.helper \
+  --workflow daily-workflow \
+  --config skillboard.config.yaml \
+  --skills skills
+```
+
+If you already used `skillboard add workflow ... --skill user.helper`, this
+manual activation step is not needed for direct user invocation.
+
+Block it from a workflow without deleting the declaration or file:
+
+```bash
+skillboard block user.helper \
+  --workflow daily-workflow \
+  --config skillboard.config.yaml \
+  --skills skills
+```
+
+Prefer it for a capability when the workflow should depend on a role rather than
+a raw skill id:
+
+```bash
+skillboard prefer user.helper \
+  --workflow daily-workflow \
+  --capability task-review \
+  --config skillboard.config.yaml \
+  --skills skills
+```
+
+## 5. Remove Governance Without Deleting User Files
+
+First try the safe remove:
+
+```bash
+skillboard remove skill user.helper \
+  --config skillboard.config.yaml \
+  --skills skills
+```
+
+If workflows, capabilities, or install units still reference the skill, the
+command refuses to remove it and prints the references. After reviewing the
+impact, remove the config declaration and references:
+
+```bash
+skillboard remove skill user.helper \
+  --config skillboard.config.yaml \
+  --skills skills \
+  --force \
+  --dry-run
+
+skillboard remove skill user.helper \
+  --config skillboard.config.yaml \
+  --skills skills \
+  --force
+```
+
+This removes SkillBoard policy references only. It does not delete
+`skills/user-helper/SKILL.md`.
+
+## 6. Stop Using SkillBoard Safely
+
+```bash
+skillboard uninstall --dry-run
+skillboard uninstall
+```
+
+Uninstall removes generated bridge blocks and unchanged helper files. It
+preserves `skillboard.config.yaml`, `skills/`, reports, and user-authored
+content in bridge files.
+
+For a fresh policy lifecycle during testing, use:
+
+```bash
+skillboard uninstall --reset-config --remove-reports --remove-hooks --dry-run
+skillboard uninstall --reset-config --remove-reports --remove-hooks
+skillboard init
+```
+
+`--reset-config` discards the current SkillBoard config even if it contains
+imported skills or workflow edits. `--remove-reports` also discards generated
+dashboard and impact reports. `--remove-hooks` discards the entire
+`.skillboard/hooks/` directory contents when you explicitly want a full test or
+test reset, so `.skillboard/` can disappear when no other SkillBoard state
+remains. These reset flags do not delete local `skills/` files.

package/docs/versioning.md

@@ -0,0 +1,201 @@
+# Versioning
+
+SkillBoard has several versioned surfaces. They should not all move at the same
+pace, and not every skill file belongs in central version control.
+
+This document defines the public alpha policy for releases, config compatibility,
+source profiles, and the generated lockfile.
+
+## Status
+
+Current package version: `0.1.0`
+
+Current config schema version:
+
+```yaml
+version: 1
+```
+
+The project is a public alpha. Breaking changes are allowed before `1.0.0`, but
+they must be documented in release notes and should include a migration note when
+they affect user config.
+
+## Versioned Surfaces
+
+SkillBoard versions these surfaces deliberately:
+
+- CLI package version: the npm package and command behavior.
+- Config schema version: the top-level `version` field in
+  `skillboard.config.yaml`.
+- Source profile format: YAML files under `profiles/` and project-specific
+  `.skillboard/profiles/`.
+- Workflow contracts: workflow names, required capabilities, active skill pools,
+  required outputs, and harness choices.
+- Capability contracts: canonical skill, alternatives, and default policy for a
+  capability.
+- Exported skill entries: shared or vendor skills governed by SkillBoard.
+- Install-unit entries: plugin, marketplace, package, harness, MCP, hook, agent,
+  and LSP sources.
+- Lockfile data: pinned source/cache digest, skill content digests, policy, and
+  compatible harnesses.
+
+SkillBoard does not try to centrally version every prompt or helper skill. A
+workflow-internal private skill can remain inside that workflow package until it
+becomes shared, auto-invokable, vendor-provided, or cross-workflow.
+
+## Release Versioning
+
+The package follows SemVer with a stricter alpha convention:
+
+- Patch: bug fixes, docs, new tests, safer validation, and non-breaking profile
+  additions.
+- Minor: new commands, new config fields with safe defaults, new report sections,
+  new built-in source profiles, and new policy checks that are warnings first.
+- Major: post-`1.0.0` breaking CLI, config, or policy behavior.
+
+Before `1.0.0`, breaking changes may happen in minor releases, but the changelog
+must call them out clearly.
+
+Suggested tags:
+
+- `v0.1.0-alpha`: first public GitHub alpha.
+- `v0.2.0-alpha`: source inventory refresh, doctor/status, source pin refresh,
+  installer/config detection, resilient detector warnings, and richer dry-run
+  plans.
+- `v0.3.0-alpha`: signed remote source verification hardening and migration
+  workflow.
+- `v1.0.0`: config schema and core CLI behavior are stable enough for external
+  workflows to rely on.
+
+## Config Schema Version
+
+The top-level `version` field is the schema version, not the package version.
+
+Rules:
+
+- `version: 1` is the only supported schema today.
+- Missing `version` is treated as `1` for early compatibility.
+- Unsupported future versions must fail fast rather than silently parsing with
+  older semantics.
+- New fields should default to the safest behavior.
+- New automatic invocation behavior must be opt-in.
+- New policy checks should start as warnings unless they protect an important
+  safety boundary.
+
+Breaking schema changes need a migration note. A future `skillboard migrate`
+command can automate those changes, but it is not implemented yet.
+
+## Source Profile Versioning
+
+Source profiles are data, not hardcoded adapter branches. Built-in profiles live
+under `profiles/`; project profiles can live under `.skillboard/profiles/`.
+
+Profile compatibility rules:
+
+- Adding a new built-in profile is a patch or minor change.
+- Changing a built-in profile's namespace, target path prefix, default status,
+  default invocation, or default exposure is a breaking profile behavior change.
+- External profiles should not grant `global-auto` unless they also mark the
+  imported skills as `global-meta`.
+- External repository skills should normally import as `vendor`, `candidate`, or
+  `quarantined`, with `manual-only` or `router-only` invocation.
+- Harness/plugin bundle profiles should use `unit-managed` for child skills when
+  the parent bundle owns commands, hooks, MCP servers, or config mutation.
+
+Profile imports can be reviewed as fragments or merged directly:
+
+```bash
+skillboard import \
+  --profile github.mattpocock.skills \
+  --source-root /path/to/source \
+  --out .skillboard/reports/import-fragment.yaml
+```
+
+```bash
+skillboard import \
+  --profile github.mattpocock.skills \
+  --source-root /path/to/source \
+  --config skillboard.config.yaml \
+  --merge \
+  --dry-run
+```
+
+`--merge` is append-only by default. `--replace` is required to overwrite
+existing skill or install-unit ids. Drop `--dry-run` only after reviewing the
+reported text and YAML semantic change plan.
+
+## Workflow And Capability Versioning
+
+The primary unit of compatibility is the workflow, not an individual skill.
+
+Version these centrally:
+
+- workflow name and intent;
+- harness and fallback harness assumptions;
+- required capabilities;
+- active, blocked, and manual-only skill pools;
+- required outputs;
+- exported skill contracts used by more than one workflow;
+- policy decisions that allow automatic invocation.
+
+Avoid central versioning for:
+
+- one-off prompts;
+- workflow-internal helper skills;
+- private skills used by only one workflow;
+- temporary templates that are not auto-invokable;
+- implementation details inside a harness bundle.
+
+When a workflow changes its required outputs, required capabilities, or
+workflow-auto skill set, treat it as a compatibility change even if no file paths
+changed.
+
+## Lockfile Policy
+
+`skillboard lock write` generates `skillboard.lock.yaml` from the current
+workspace.
+
+The lockfile pins:
+
+- config schema version;
+- install-unit source, cache path, verified path, digest, and trust status;
+- skill id, path, and content hash;
+- workflow/capability bindings;
+- generated timestamp.
+
+The lockfile should represent a verified working set, not a desired-state file.
+Users should edit `skillboard.config.yaml`; tools should generate the lockfile.
+Local `source` and `cache_path` entries are digest-verified by `skillboard audit
+sources --verify`. Remote or command-based sources need a configured
+`source_digest` and, when signatures are used, a matching `public_key`.
+Fetchable Git sources can be materialized and pinned with `skillboard sources
+refresh`, which updates `cache_path`, `source_digest`, and `verified_at` in the
+config after cloning into `.skillboard/sources/`.
+Relative local paths are resolved from the config directory first and then from
+the current working directory, so bundled examples can use project-root-relative
+paths while project configs can still keep config-local paths.
+`skillboard lock write` refuses to write when verification has errors unless
+`--allow-unverified` is passed explicitly for investigation artifacts.
+
+## Release Checklist
+
+Before tagging a public release:
+
+- Run `npm run check`.
+- Run `node --check` across `src`, `test`, and `bin`.
+- Run `npm pack --dry-run --json` and confirm internal artifacts are excluded.
+- Run at least one CLI smoke test through the public surface.
+- Confirm docs mention any breaking config, profile, or CLI changes.
+- Update package version and release notes.
+
+For alpha releases, include a short "completion notes" section. Current
+completion notes:
+
+- source inventory refresh covers known local agent skill roots, plugin-cache
+  manifests, and user-supplied scan roots;
+- `sources refresh` covers Git-compatible remote sources and digest pin refresh;
+- `inventory detect` covers installer output and explicit mutated config files
+  for commands, hooks, MCP servers, and modified config paths;
+- dry-run plans report a capped YAML semantic change list rather than full patch
+  hunks;
+- unusual YAML trivia may still be normalized during structured config writes.

package/examples/multi-source-skills/anthropic/docx/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: anthropic.docx
+description: Create and edit Word documents.
+---
+
+# Anthropic DOCX
+
+Document workflow skill.

package/examples/multi-source-skills/anthropic/skill-creator/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: anthropic.skill-creator
+description: Create Agent Skills with the standard skill structure.
+---
+
+# Anthropic Skill Creator
+
+Reference skill authoring workflow.

package/examples/multi-source-skills/matt/grill-me/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: matt.grill-me
+description: Clarify vague requirements before implementation.
+---
+
+# Matt Grill Me
+
+Vendor requirement clarification skill.

package/examples/multi-source-skills/matt/tdd/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: matt.tdd
+description: Run test-driven implementation loops.
+---
+
+# Matt TDD
+
+Vendor TDD workflow skill.