@danieljvdm/dev-kit 0.2.2 → 0.2.3

package/README.md

@@ -28,10 +28,18 @@ bun x dev-kit list --all
 bun x dev-kit add dev-kit effect
 ```
 
-Before adding external skills, scan the repository's agent instructions,
-package and lock files, framework or tool configuration, and CI workflows for
-the capabilities it actually uses. Search and inspect candidates using those
-signals, then add the matching skills individually:
+Before adding external skills, have the agent inspect repository instructions,
+workspace dependencies, framework and tool configuration, representative
+source boundaries, and CI workflows. It should compare that concrete capability
+inventory with catalog descriptions and select the narrowest useful set. Broad
+umbrella skills and source families belong only when their full breadth is
+intentional; explicit creative or advisory requests remain valid even without a
+mechanical dependency signal. Treat lazy reference folders inside one skill as
+progressive-disclosure content, not as separately triggered skills; a repository
+using several covered products may reasonably select that umbrella while still
+excluding unrelated top-level skills.
+
+Search and inspect candidates, then add the matching skills individually:
 
 ```bash
 bun x dev-kit search cloudflare

package/package.json

@@ -1,12 +1,12 @@
 {
   "name": "@danieljvdm/dev-kit",
-  "version": "0.2.2",
+  "version": "0.2.3",
   "private": false,
   "type": "module",
   "description": "Declarative project development toolkit with portable agent skills.",
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/danieljvdm/agent-skills.git"
+    "url": "git+https://github.com/danieljvdm/dev-kit.git"
   },
   "license": "MIT",
   "bin": {

package/schema/dev-kit.schema.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://raw.githubusercontent.com/danieljvdm/agent-skills/main/schema/dev-kit.schema.json",
+  "$id": "https://raw.githubusercontent.com/danieljvdm/dev-kit/main/schema/dev-kit.schema.json",
   "title": "Dev Kit Manifest",
   "description": "Project-local desired state for portable skills and explicit dev-kit setup tasks.",
   "type": "object",

package/schema/skill-sources.schema.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "https://raw.githubusercontent.com/danieljvdm/agent-skills/main/schema/skill-sources.schema.json",
+  "$id": "https://raw.githubusercontent.com/danieljvdm/dev-kit/main/schema/skill-sources.schema.json",
   "title": "External Agent Skill Sources",
   "description": "Repository-level sources approved for the skill catalog.",
   "type": "object",

package/skills/dev-kit/SKILL.md

@@ -21,23 +21,37 @@ stores explicit skill names and exact commit/content digests.
 
 ## Apply loop
 
-1. Establish the Git root. Read project agent instructions, `dev-kit.jsonc`,
-   `dev-kit.lock.json` when present, package and lock files, framework or tool
-   configuration, CI workflows, and the configured target paths. Derive the
-   capabilities the project actually uses from those signals.
-2. Use `dev-kit search <terms>` and `dev-kit info <skill>` to inspect matching
-   catalog entries. Prefer individual external skills; select an external
-   source family only when every approved skill from it applies. Update
-   `dev-kit.jsonc`, preserve JSONC comments, and validate against the package
-   schema. Finish with each desired resource represented once.
-3. Run `dev-kit plan`. Use `--manifest`, `--project-dir`, or `--lockfile` when
+1. Establish the Git root. Read project agent instructions, the current
+   manifest and lock, package and workspace manifests, framework and tool
+   configuration, representative source boundaries, and CI workflows. Build a
+   concrete inventory of the platforms, frameworks, tools, and workflows the
+   repository actually uses; do not infer capabilities from a product or
+   company name alone.
+2. Run `dev-kit list --all`, then use `dev-kit search <terms>` and `dev-kit info
+   <skill>` for each capability in the inventory. Compare every candidate's
+   trigger description with concrete repository evidence. Keep explicitly
+   requested creative or advisory skills even when they have no mechanical
+   dependency signal.
+3. Choose the narrowest useful set. Prefer focused external skills over a
+   generic umbrella when they cover the repository's work. Select an umbrella
+   or external source family only when its full breadth is intentionally useful;
+   never select one merely because one member or product matches. Explain any
+   uncertain inclusion before applying it. Distinguish separately triggered
+   skills from lazy `references/` bundled inside one skill: unused reference
+   folders cost repository space but are not loaded into agent context unless
+   the skill routes to them. A multi-product repository can therefore justify
+   an umbrella while still excluding unrelated top-level skills.
+4. Update `dev-kit.jsonc`. Preserve JSONC comments and validate against the
+   package schema. Finish with each desired resource represented once and every
+   external selection supported by repository evidence or an explicit request.
+5. Run `dev-kit plan`. Use `--manifest`, `--project-dir`, or `--lockfile` when
    the project overrides their defaults. Planning is read-only; inspect every
    create, update, remove, adoption, and conflict before proceeding. Finish
    when the plan contains only intended actions and understood conflicts.
-4. Resolve conflicts, then run `dev-kit apply`. Commit the manifest and
+6. Resolve conflicts, then run `dev-kit apply`. Commit the manifest and
    regenerated `dev-kit.lock.json`; keep `.dev-kit/` local. Finish when a second
    plan reports only unchanged resources and setup tasks.
-5. Use `dev-kit apply --locked` in CI and the package lifecycle. Finish when a
+7. Use `dev-kit apply --locked` in CI and the package lifecycle. Finish when a
    clean install converges from the committed manifest and lock.
 
 ## Manifest