golem15/msd-core
4
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: hard-fork GSD -> MSD (Make Software Done)

Browse Source 
Mechanical rename produced by scripts/msd-rename.cjs: gsd/Gsd/GSD -> msd/Msd/MSD
across contents and paths, upstream package/repo coordinates -> @golem15/msd-core
and golem15com/msd-core. Deep links into upstream history, sibling upstream
packages, the GSD-2 import feature, CHANGELOG.md and .changeset/ are kept as-is.

Hand edits on top: MSD block-letter banner and logos, LICENSE copyright line,
package/plugin identity, regenerated lockfile, install-tree fixtures, derived
registries and benchmark baseline; migration checksum baseline re-locked
(MSD keeps its own install state, so no install had applied the old sums);
sort-order and regex-escaped expectations in tests adjusted.
This commit is contained in:
Jakub Zych
2026-10-06 01:47:40 +02:00
parent fe069b2a56
commit a9a7a328e6
2763 changed files with 78465 additions and 78434 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
docs/how-to/develop-a-capability.md
View File

@@ -1,6 +1,6 @@
# Develop a Capability for GSD 1.5+
# Develop a Capability for MSD 1.5+
This guide shows you how to add or change a first-party GSD Capability after the ADR-857 cutover. In GSD terms, the extension unit is a **Capability**. A plugin is a packaging or host-runtime term, for example a Claude Code plugin, not the unit that owns a GSD feature.
This guide shows you how to add or change a first-party MSD Capability after the ADR-857 cutover. In MSD terms, the extension unit is a **Capability**. A plugin is a packaging or host-runtime term, for example a Claude Code plugin, not the unit that owns a MSD feature.
A Capability is right when the feature can be toggled as one unit and owns its own skills, agents, hooks, config keys, or command family. Keep verifier predicate contracts, the five-step loop spine, and shared infrastructure in core unless the ADRs explicitly move that boundary.
@@ -60,13 +60,13 @@ At minimum, a feature Capability declares:
"requires": [],
"runtimeCompat": { "supported": ["*"], "unsupported": [] },
"skills": [],
"agents": ["gsd-example-agent"],
"agents": ["msd-example-agent"],
"hooks": [],
"config": {},
"steps": [
{
"point": "plan:pre",
"ref": { "agent": "gsd-example-agent" },
"ref": { "agent": "msd-example-agent" },
"fragment": { "path": "fragments/plan-pre.md" },
"produces": ["EXAMPLE.md"],
"consumes": ["CONTEXT.md"],
@@ -82,7 +82,7 @@ The registry generator validates the shape, ownership, and cross-capability cont
## Declare runtime compatibility
Every feature Capability must declare `runtimeCompat`. This is part of the GSD 1.5+ developer contract: a Capability says which runtime descriptors it can surface through, and the generator validates that declaration before the central registry is written.
Every feature Capability must declare `runtimeCompat`. This is part of the MSD 1.5+ developer contract: a Capability says which runtime descriptors it can surface through, and the generator validates that declaration before the central registry is written.
Use the wildcard when the Capability is runtime-agnostic:
@@ -113,7 +113,7 @@ Loop Extension Points are the stable sites where Capabilities attach to the host
Choose the hook kind that matches the behaviour:
- `steps` add a sequenced unit of work, such as running `gsd-phase-researcher` or `gsd-pattern-mapper`.
- `steps` add a sequenced unit of work, such as running `msd-phase-researcher` or `msd-pattern-mapper`.
- `contributions` add labelled context to a host prompt.
- `gates` check a condition and may block when `blocking` is true.
@@ -131,7 +131,7 @@ and rejects a manifest that declares a kind the point does not dispatch. You fin
capability "demo" steps[0].point "ship:pre" registers a step hook, but the host call site's
dispatch text never covers `kind == "step"` (it covers: gate). A hand-rolled single-kind consumer
silently never dispatches the other kinds — dispatch every registered kind per
gsd-core/references/loop-hook-dispatch.md.
msd-core/references/loop-hook-dispatch.md.
```
That error is the answer, not a bug to route around. Either pick a point that dispatches your kind,
@@ -148,7 +148,7 @@ or failed never drops a deliverable and never blocks UAT.
## Ship skills — and know what you are shipping
A skill your Capability declares is not an inert asset. Its `SKILL.md` body is copied **verbatim** into the user's runtime skills directory at install, where it becomes an agent-invocable instruction file. GSD does **not** scan it: there is no content inspection of any kind, at install or at any later point. What you write is what reaches the agent.
A skill your Capability declares is not an inert asset. Its `SKILL.md` body is copied **verbatim** into the user's runtime skills directory at install, where it becomes an agent-invocable instruction file. MSD does **not** scan it: there is no content inspection of any kind, at install or at any later point. What you write is what reaches the agent.
That makes a skill body an **instruction surface**, and it carries author responsibility that an inert artifact does not:
@@ -192,18 +192,18 @@ node scripts/gen-capability-registry.cjs --check
For a planning hook, verify the rendered output:
```bash
node gsd-core/bin/gsd-tools.cjs loop render-hooks plan:pre --raw
node msd-core/bin/msd-tools.cjs loop render-hooks plan:pre --raw
```
In installed workflow prose, the same resolver surface appears as `gsd-tools loop render-hooks plan:pre`.
In installed workflow prose, the same resolver surface appears as `msd-tools loop render-hooks plan:pre`.
The rendered JSON should include the active hook, the declared `ref`, and the materialised `fragment.inline`.
To verify a runtime-specific surface, pass the same config directory that the runtime installation uses:
```bash
node gsd-core/bin/gsd-tools.cjs loop render-hooks plan:pre --config-dir ~/.claude --raw
node gsd-core/bin/gsd-tools.cjs capability state --config-dir ~/.claude --raw
node msd-core/bin/msd-tools.cjs loop render-hooks plan:pre --config-dir ~/.claude --raw
node msd-core/bin/msd-tools.cjs capability state --config-dir ~/.claude --raw
```
`capability state` is the diagnostic view for the same state that workflow dispatch consumes. For each Capability, `enabled` is true only when the Capability is both installed by the active profile and surfaced by the runtime surface. A hook's `configured` field reflects the `when` config key; `active` is true only when the Capability is enabled and the hook is configured on.
@@ -234,7 +234,7 @@ Declare feature config keys in the Capability manifest:
}
```
Do not add migrated Capability keys to `gsd-core/bin/shared/config-schema.manifest.json`. The central schema remains for host/core keys; Capability-owned keys validate through the generated registry and are merged into `loadConfig` by the federated config overlay. Existing nested `.planning/config.json` values such as `{ "workflow": { "example_enabled": false } }` continue to override the Capability default.
Do not add migrated Capability keys to `msd-core/bin/shared/config-schema.manifest.json`. The central schema remains for host/core keys; Capability-owned keys validate through the generated registry and are merged into `loadConfig` by the federated config overlay. Existing nested `.planning/config.json` values such as `{ "workflow": { "example_enabled": false } }` continue to override the Capability default.
## Wire the workflow through the registry
@@ -242,9 +242,9 @@ Host workflows should ask the resolver for active hooks and then dispatch from t
The Phase 6 migrations follow this pattern:
- `research` registers a `plan:pre` step that invokes `gsd-phase-researcher`.
- `research` registers a `plan:pre` step that invokes `msd-phase-researcher`.
- `ai-integration` owns the AI-SPEC planning activation and config key.
- `pattern-mapper` registers a `plan:pre` step that invokes `gsd-pattern-mapper`.
- `pattern-mapper` registers a `plan:pre` step that invokes `msd-pattern-mapper`.
- `plan-phase.md` reads the resolved `PLAN_PRE_HOOKS_JSON` and dispatches `ref.agent` or `ref.skill` from that data.
- `code-review` registers an `execute:post` step and review workflows dispatch from the active hook's `ref.skill`.
- `security` registers a `plan:pre` contribution, a `verify:post` step, and a blocking `ship:pre` gate.
@@ -278,15 +278,15 @@ Every Phase 6 slice that changes capability behaviour must update the relevant d
## The capability ecosystem (1.6.0)
From GSD 1.6.0, capabilities are versioned (the `version` field is required in `capability.json`) and can be installed directly from a URL, a git ref, an npm package, or a local path — without modifying the core repo.
From MSD 1.6.0, capabilities are versioned (the `version` field is required in `capability.json`) and can be installed directly from a URL, a git ref, an npm package, or a local path — without modifying the core repo.
- **Tutorial** — [Build your first capability](../tutorials/build-your-first-capability.md): scaffold and install a declarative capability end-to-end in under ten minutes.
- **How-to** — [Publish a capability](../how-to/publish-a-capability.md): package and distribute a capability via a URL or registry.
- **How-to** — [Import a capability from a URL](../how-to/import-a-capability-from-a-url.md): install a third-party capability from a git URL, tarball, or npm package.
- **How-to** — [Version and update a capability](../how-to/version-a-capability.md): manage `version`, `engines.gsd`, and `compatVersions`; use `gsd capability update`.
- **How-to** — [Remove a capability](../how-to/remove-a-capability.md): uninstall cleanly with `gsd capability remove`, including the `--purge-data` option.
- **How-to** — [Ship a reviewer lane in your capability](../how-to/ship-a-reviewer-lane.md): declare a `reviewer` body (GSD 1.9.0+) so `/gsd-review` discovers and invokes your external review CLI or model endpoint.
- **How-to** — [List your reviewer lane in the registry](../how-to/list-your-reviewer-lane.md): publish a lane to the Reviewer Lane Registry (GSD 1.9.1+) so other people can find and install it.
- **How-to** — [Version and update a capability](../how-to/version-a-capability.md): manage `version`, `engines.msd`, and `compatVersions`; use `msd capability update`.
- **How-to** — [Remove a capability](../how-to/remove-a-capability.md): uninstall cleanly with `msd capability remove`, including the `--purge-data` option.
- **How-to** — [Ship a reviewer lane in your capability](../how-to/ship-a-reviewer-lane.md): declare a `reviewer` body (MSD 1.9.0+) so `/msd-review` discovers and invokes your external review CLI or model endpoint.
- **How-to** — [List your reviewer lane in the registry](../how-to/list-your-reviewer-lane.md): publish a lane to the Reviewer Lane Registry (MSD 1.9.1+) so other people can find and install it.
- **Reference** — [Capability manifest](../reference/capability-manifest.md): all fields and validation rules for `capability.json`.
- **Reference** — [Capability matrix](../reference/capability-matrix.md): which first-party capabilities exist, their extension points, and their compatibility matrix.
- **Explanation** — [Capability trust model](../explanation/capability-trust-model.md): how declarative and executable capabilities are treated differently at install time.