[Extension]: Update adrkit to 0.1.4 — widen Spec Kit compatibility to >=0.13.0,<1.1.0 (current entry is unusable on 0.16+/1.0)

[mbeacom]

This is an update to an existing catalog entry, not a new submission — per the Publishing Guide ("Updating an Existing Extension"). adrkit is currently listed at 0.1.2, and its entry still advertises speckit_version: >=0.13.0,<0.16.0, so catalog users installing today receive a manifest that refuses to install on any current Spec Kit release. The 0.1.3 release was never reflected either.

Extension ID

adrkit

Extension Name

adrkit — decision memory for spec-driven development

Version

0.1.4 (previously listed: 0.1.2)

Description

Pulls the decisions governing this work into agent context, checks produced plans against them, and drafts an ADR from a plan artifact.

Author

Mark Beacom (@mbeacom)

Repository URL

https://github.com/mbeacom/adrkit

Download URL

https://github.com/mbeacom/adrkit/releases/download/spec-kit-v0.1.4/adrkit.zip

(Returns 200; extension.yml is at the archive root. Previously listed URL pointed at the spec-kit-v0.1.2 asset.)

License

Apache-2.0

Homepage

https://adrkit.dev

Documentation URL

https://github.com/mbeacom/adrkit/blob/main/packages/adapters/spec-kit/README.md

Changelog URL

https://github.com/mbeacom/adrkit/blob/main/CHANGELOG.md

Required Spec Kit Version

>=0.13.0,<1.1.0 — this is the substantive change (was >=0.13.0,<0.16.0).

Required Tools

• adr (>=0.3.0) — required. Install via npm install -g @adrkit/cli, a project-local install, or ADRKIT_CLI pointing at its entry point.

Number of Commands

3

Number of Hooks

1 (after_plan, optional: true — it asks rather than firing automatically)

Tags

adr, governance, decision-records, architecture, compliance

Key Features

• Retrieve the decisions governing the current work before planning against them (read-only)
• Check a produced plan against the governing decision corpus (read-only)
• Draft one new ADR from the current plan artifact — the only command that writes
• Optional after_plan hook that offers the check rather than seizing the plan loop
• Path-aware governance, including inbound @adr markers declared in source files

Testing Checklist

• Extension installs successfully via download URL
• All commands execute without errors
• Documentation is complete and accurate
• No security vulnerabilities identified
• Tested on at least one real project

Submission Requirements

• Valid extension.yml manifest included
• README.md with installation and usage instructions
• LICENSE file included
• GitHub release created with version tag
• All command files exist and are properly formatted
• Extension ID follows naming conventions (lowercase-with-hyphens)

Testing Details

The compatibility widening in this release was a re-verification, not an inference. Upstream sources were diffed and the extension was installed and rendered against each release, rather than assuming the range held:

Check	Result
extensions/EXTENSION-API-REFERENCE.md at v0.16.5 → v1.0.4 → v1.0.5 → v1.0.6	byte-identical across all four (896 lines)
src/specify_cli/extensions/__init__.py, v0.15.1 → v1.0.6	additive, refactor, or strictly more permissive; .extensionignore handling and SpecifierSet parsing unchanged
specify extension add --dev on 0.16.5, 1.0.0, 1.0.4, 1.0.5, 1.0.6 (Python 3.12)	exit 0 on all; 3 commands and 3 agent skills registered; after_plan recorded optional: true
Negative control: the previous pin <0.16.0 against 1.0.4	rejected with a compatibility error naming both specifiers, exit 1 — the fail-loud contract observed working, not assumed

Install of this exact published asset, macOS 15 / Python 3.12 / Spec Kit 1.0.6, --integration copilot:

specify extension add adrkit --from https://github.com/mbeacom/adrkit/releases/download/spec-kit-v0.1.4/adrkit.zip
→ exit 0, "3 agent skill(s) auto-registered"

Installed tree contained exactly LICENSE, NOTICE, README.md, commands/, extension.yml, scripts/ — no test suite, tsconfig.json, package.json, or node_modules/. .specify/extensions.yml recorded the hook as optional: true. Skills rendered at .github/skills/speckit-adrkit-{context,check,draft}.

Command execution, against a real 38-record ADR corpus with @adrkit/cli on PATH:

• scripts/context.sh (no args → queue projection): exit 0, valid JSON
• scripts/context.sh <path> (path-scoped → governing decisions): exit 0, valid JSON
• scripts/check.sh with no Spec Kit feature directory: exit 0 with the correct diagnostic (run /speckit.specify first, or set ADRKIT_FEATURE_DIR) rather than a failure or a fabricated result

Scope stated honestly: draft is the one command that writes, and it deliberately refuses to run without a plan artifact, so it was exercised through its precondition guard rather than through a completed write in this session. It has been exercised end-to-end in the project's own reference-verification repository. The "no security vulnerabilities" box reflects that the package declares zero dependencies (enforced by a packaging test), ships only POSIX sh scripts and Markdown, and has a test asserting the writing command is unreachable from any hook — not an external audit.

Two upstream behaviors observed on 1.0.x, neither requiring a change here and both noted in case they are useful:

1. On 1.0.x with the Copilot integration, extension commands render as agent skills under .github/skills/speckit-adrkit-* (the same surface upstream's own commands use) rather than as .github/agents/ and .github/prompts/ files.
2. As of 1.0.6, generated skill metadata carries author from extension.author; on 1.0.4 it emitted github-spec-kit. This appears to be the intended effect of passing manifest.data["extension"].get("author") into skill generation, and it correctly credits the extension author.

Example Usage

# Pull the decisions governing this work into context, before planning against them
/speckit.adrkit.context

# Check a produced plan against the decision corpus
/speckit.adrkit.check

# Draft one ADR from the current plan artifact
/speckit.adrkit.draft

After /speckit.plan, the optional after_plan hook offers: "Check this plan against the decisions that govern it?"

Proposed Catalog Entry

{
  "name": "adrkit — decision memory for spec-driven development",
  "id": "adrkit",
  "description": "Pulls the decisions governing this work into agent context, checks produced plans against them, and drafts an ADR from a plan artifact.",
  "author": "Mark Beacom (@mbeacom)",
  "version": "0.1.4",
  "download_url": "https://github.com/mbeacom/adrkit/releases/download/spec-kit-v0.1.4/adrkit.zip",
  "repository": "https://github.com/mbeacom/adrkit",
  "homepage": "https://adrkit.dev",
  "documentation": "https://github.com/mbeacom/adrkit/blob/main/packages/adapters/spec-kit/README.md",
  "changelog": "https://github.com/mbeacom/adrkit/blob/main/CHANGELOG.md",
  "license": "Apache-2.0",
  "category": "process",
  "effect": "read-write",
  "requires": {
    "speckit_version": ">=0.13.0,<1.1.0",
    "tools": [
      {
        "name": "adr",
        "version": ">=0.3.0",
        "required": true
      }
    ]
  },
  "provides": {
    "commands": 3,
    "hooks": 1
  },
  "tags": [
    "adr",
    "governance",
    "decision-records",
    "architecture",
    "compliance"
  ],
  "verified": false,
  "downloads": 0,
  "stars": 0,
  "created_at": "2026-08-03T00:00:00Z",
  "updated_at": "2026-09-13T00:00:00Z"
}

Only four fields change from the current entry: version, download_url, requires.speckit_version, and updated_at. created_at, verified, downloads, and stars are preserved as listed.

Additional Context

effect stays read-write even though the hook surface and two of three commands write nothing, because exactly one command (draft) writes a single record. Claiming read-only for the majority case would be the convenient answer rather than the true one.

The upper bound is treated as a verification boundary rather than a guess, and it is declared at minor granularity: verified at the endpoints and samples of each admitted line, not at every patch. <1.1.0 therefore asserts "verified through the 1.0 line" — a later 1.0.x patch does not silently invalidate it, and 1.1.0 is where the extension fails loud and re-verification is owed.

Happy to adjust any field to match catalog conventions.