agentme 0.36.0 → 0.37.0

package/.xdrs/agentme/edrs/application/skills/{251-azure-devops-connector → azure-devops-connector}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: 251-azure-devops-connector
+name: azure-devops-connector
 description: >
   Base connector providing authentication, read access, and write access to Azure DevOps
   pull requests and their comment threads via the az CLI. Pure I/O -- no triage logic, no
-  business decisions. Activate when an agent or skill (such as pr-owner-assistant) needs to
+  business decisions. Activate when an agent or skill (such as resolve-pr-comments) needs to
   fetch or post PR thread comments, change thread status, or check out a PR branch on Azure
   DevOps.
 metadata:
@@ -19,9 +19,7 @@ Wraps the `az` CLI (with the `azure-devops` extension) -- Azure DevOps's own sup
 client -- plus `az rest` for the handful of operations the extension does not expose as a
 dedicated subcommand. Contains no business logic (per rule 05): it only reads and writes
 data and normalizes it to the shape consumed by
-[`400-pr-owner-assistant`](../../../principles/skills/400-pr-owner-assistant/SKILL.md).
-
-This is a base connector skill (number range 250-299).
+[`resolve-pr-comments`](../../../principles/skills/resolve-pr-comments/SKILL.md).
 
 ## Instructions
 
@@ -91,7 +89,7 @@ Normalize every thread's comments to the shared record shape (`id`, `kind`, `sta
   resolve.
 - `diff_hunk` has no native equivalent in the Azure DevOps API -- `threadContext` exposes
   only a file path and line range, not a unified-diff-style hunk string. Leave `diff_hunk`
-  null rather than fabricating one; `pr-owner-assistant` degrades to relying on
+  null rather than fabricating one; `resolve-pr-comments` degrades to relying on
   `source-lines` alone in that case, exactly as it does for a general (non-file-scoped)
   comment.
 - `url` has no direct field in the thread-comment response either. Synthesize a best-effort
@@ -172,7 +170,7 @@ threads/comments `POST`, then updates thread status via the `PATCH` call.
   well-known, tenant-agnostic AAD resource id) explicitly on every `az rest` call. Even
   then, never treat a zero exit code alone as proof a write persisted -- read the thread
   back afterward and verify the expected content/status is actually present before
-  reporting success. `400-pr-owner-assistant`'s `scripts/post-replies-azure-devops.js` does
+  reporting success. `resolve-pr-comments`'s `scripts/post-replies-azure-devops.js` does
   this automatically for every write.
 - **Symptom:** a fetched thread has no obvious "kind" like GitHub's review-summary.
   **Cause:** Azure DevOps genuinely has no equivalent concept -- every comment lives inside a
@@ -199,7 +197,6 @@ threads/comments `POST`, then updates thread status via the `PATCH` call.
 
 ## References
 
-- [`400-pr-owner-assistant`](../../../principles/skills/400-pr-owner-assistant/SKILL.md) -- consumes this connector's normalized output.
+- [`resolve-pr-comments`](../../../principles/skills/resolve-pr-comments/SKILL.md) -- consumes this connector's normalized output.
 - [`agentme-edr-127`](../../127-external-system-adapter-skills.md) -- external system adapter skill rules (connector naming, Known Issues format, HITL-before-write).
 - [`agentme-edr-124`](../../124-secrets-management.md) -- credential storage and retrieval.
-- [`agentme-core-adr-003`](../../../../../agentme-core/adrs/principles/003-skill-numbering-ranges.md) -- skill numbering ranges (250-299 base connectors).

package/.xdrs/agentme/edrs/application/skills/{251-azure-devops-connector → azure-devops-connector}/SKILL.test.md

@@ -1,5 +1,5 @@
 ---
-skill: 251-azure-devops-connector
+skill: azure-devops-connector
 skill-version: "1.0"
 ---
 

package/.xdrs/agentme/edrs/application/skills/{051-create-golang-project → create-golang-project}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: 051-create-golang-project
+name: create-golang-project
 description: >
   Scaffolds the initial boilerplate structure for a Go (Golang) CLI or library project following
   the standard tooling and layout defined in agentme-edr-102. Activate this skill when the user

package/.xdrs/agentme/edrs/application/skills/create-golang-project/SKILL.test.md

@@ -0,0 +1,72 @@
+---
+skill: create-golang-project
+skill-version: "1.0"
+---
+
+## Test Scenarios
+
+### Scenario 1: Create a new Go CLI project, happy path
+
+**Trigger / Input**
+
+"Create a Go CLI project. Module `github.com/acme/logscan`, binary name `logscan`, first feature
+`scan`, first subcommand `scan`."
+
+**Expected Behaviour**
+
+1. Phase 1 gathers or infers the module path, binary name, Go version (default `1.24`), first
+   feature package name, and first CLI subcommand name.
+2. Phase 2 creates `.mise.toml`, `go.mod`, a `main.go` that only dispatches to `adapters/cli`, the
+   root `Makefile` (exporting `GOCACHE`/`GOMODCACHE`/`GOLANGCI_LINT_CACHE`, with `build`,
+   `build-all`, `lint`, `test`, `test-coverage`, `benchmark`, and `clean` targets), `.golangci.yml`,
+   `.gitignore`, and `README.md`.
+3. Phase 3 creates `app/scan/scan.go` and `app/scan/scan_test.go` with the `Options`/`Result`/`Run`
+   shape.
+4. Phase 4 creates `adapters/cli/scan.go` that parses flags and calls into `app/scan`.
+5. Phase 5 runs `make setup` and `make all`, fixing any compile or lint errors before finishing.
+
+**Assertions**
+
+- [ ] Output creates `main.go` containing only argument dispatch, with no business logic.
+- [ ] Output places the `scan` domain logic in `app/scan/scan.go` and the flag parsing in
+      `adapters/cli/scan.go`, not the reverse.
+- [ ] Output's root `Makefile` exports `GOCACHE`, `GOMODCACHE`, and `GOLANGCI_LINT_CACHE` under
+      `.cache/` and defines `build`, `lint`, and `test` targets.
+- [ ] Output reports running `make setup` and `make all` and fixes any compile or lint errors
+      before declaring completion.
+
+### Scenario 2: Business logic requested inside main.go is redirected to app/
+
+**Trigger / Input**
+
+"Put the scan logic directly inside `main.go` instead of a separate package, and use
+`fmt.Println` to print debug output during scanning."
+
+**Expected Behaviour**
+
+Per the Conventions and reminders section, the skill keeps `main.go` as a thin dispatcher with no
+business logic, places the scan logic in `app/scan/`, and uses `logrus` instead of `fmt.Println`
+for diagnostic/debug output.
+
+**Assertions**
+
+- [ ] Output does not place business logic inside `main.go`.
+- [ ] Output uses `logrus` rather than `fmt.Println` for diagnostic/debug output.
+
+### Scenario 3: internal/ package is not created without explicit justification
+
+**Trigger / Input**
+
+"Create an `internal/` package for the scan helpers so other repositories can't import them."
+
+**Expected Behaviour**
+
+Per the Conventions and reminders section, the skill does not create an `internal/` package by
+default — it keeps the helpers importable (e.g., under `app/scan/` or `shared/`) unless the user
+gives an explicit justification for restricting importability.
+
+**Assertions**
+
+- [ ] Output does not create an `internal/` package without the user first providing an explicit
+      justification.
+- [ ] Output keeps the scan helpers in an importable location such as `app/scan/` or `shared/`.

package/.xdrs/agentme/edrs/application/skills/{050-create-javascript-project → create-javascript-project}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: 050-create-javascript-project
+name: create-javascript-project
 description: >
   Scaffolds the initial boilerplate structure for a JavaScript/TypeScript project following
   the standard tooling and layout defined in agentme-edr-101. Activate this skill when the user
@@ -48,16 +48,16 @@ MISE := mise exec --
 %:
 	@echo ''
 	@echo '>>> Running /lib:$@...'
-  @$(MAKE) -C lib $@
+	@$(MAKE) -C lib $@
 	@echo ''
 	@echo '>>> Running /examples:$@...'
-  @STAGE=dev $(MAKE) -C examples $@
+	@STAGE=dev $(MAKE) -C examples $@
 
 publish:
-  @$(MAKE) -C lib publish
+	@$(MAKE) -C lib publish
 
 setup:
-  mise install
+	mise install
 ```
 
 **`./.mise.toml`**
@@ -126,52 +126,52 @@ CACHE_DIR := .cache
 
 build: install
 	@rm -rf dist
-  @mkdir -p $(CACHE_DIR)/tsc
-  $(MISE) pnpm exec tsc --incremental --tsBuildInfoFile $(CACHE_DIR)/tsc/tsconfig.tsbuildinfo --outDir dist
+	@mkdir -p $(CACHE_DIR)/tsc
+	$(MISE) pnpm exec tsc --incremental --tsBuildInfoFile $(CACHE_DIR)/tsc/tsconfig.tsbuildinfo --outDir dist
 	@-find ./dist \( -regex '.*\.test\..*' -o -regex '.*__tests.*' \) -exec rm -rf {} \; 2> /dev/null
 	@# Create pack for use by examples to simulate real external usage
-  $(MISE) pnpm pack --pack-destination dist
+	$(MISE) pnpm pack --pack-destination dist
 
 build-module: install
 	@rm -rf dist
-  @mkdir -p $(CACHE_DIR)/tsc
-  $(MISE) pnpm exec tsc --incremental --tsBuildInfoFile $(CACHE_DIR)/tsc/tsconfig.tsbuildinfo --outDir dist
+	@mkdir -p $(CACHE_DIR)/tsc
+	$(MISE) pnpm exec tsc --incremental --tsBuildInfoFile $(CACHE_DIR)/tsc/tsconfig.tsbuildinfo --outDir dist
 	@-find ./dist \( -regex '.*\.test\..*' -o -regex '.*__tests.*' \) -exec rm -rf {} \; 2> /dev/null
 
 lint:
-  @mkdir -p $(CACHE_DIR)/eslint
-  $(MISE) pnpm exec eslint ./src --cache --cache-location $(CACHE_DIR)/eslint/.eslintcache
+	@mkdir -p $(CACHE_DIR)/eslint
+	$(MISE) pnpm exec eslint ./src --cache --cache-location $(CACHE_DIR)/eslint/.eslintcache
 
 lint-fix:
-  @mkdir -p $(CACHE_DIR)/eslint
-  $(MISE) pnpm exec eslint ./src --fix --cache --cache-location $(CACHE_DIR)/eslint/.eslintcache
+	@mkdir -p $(CACHE_DIR)/eslint
+	$(MISE) pnpm exec eslint ./src --fix --cache --cache-location $(CACHE_DIR)/eslint/.eslintcache
 
 test-watch:
-  $(MISE) pnpm exec jest --watch
+	$(MISE) pnpm exec jest --watch
 
 test:
-  $(MISE) pnpm exec jest --verbose
+	$(MISE) pnpm exec jest --verbose
 
 clean:
 	rm -rf node_modules
 	rm -rf dist
-  rm -rf .cache
+	rm -rf .cache
 
 all: build lint test
 
 install:
-  mise install
-  $(MISE) pnpm install --frozen-lockfile --config.dedupe-peer-dependents=false
+	mise install
+	$(MISE) pnpm install --frozen-lockfile --config.dedupe-peer-dependents=false
 
 publish:
-  $(MISE) npx -y monotag@1.26.0 current --bump-action=latest --prefix=
-  @VERSION=$$($(MISE) node -p "require('./package.json').version"); \
+	$(MISE) npx -y monotag@1.26.0 current --bump-action=latest --prefix=
+	@VERSION=$$($(MISE) node -p "require('./package.json').version"); \
 	if echo "$$VERSION" | grep -q '-'; then \
 		TAG=$$(echo "$$VERSION" | sed 's/[0-9]*\.[0-9]*\.[0-9]*-\([a-zA-Z][a-zA-Z0-9]*\).*/\1/'); \
 		echo "Prerelease version $$VERSION detected, publishing with --tag $$TAG"; \
-    $(MISE) npm publish --no-git-checks --provenance --tag "$$TAG"; \
+		$(MISE) npm publish --no-git-checks --provenance --tag "$$TAG"; \
 	else \
-    $(MISE) npm publish --no-git-checks --provenance; \
+		$(MISE) npm publish --no-git-checks --provenance; \
 	fi
 ```
 
@@ -283,7 +283,6 @@ export default [
     },
   },
 ];
-];
 ```
 
 Do not name this file `eslint.config.js` unless the generated package also opts into ESM with `"type": "module"`, because that produces Node.js warnings and conflicts with the recommended Jest CommonJS setup.

package/.xdrs/agentme/edrs/application/skills/create-javascript-project/SKILL.test.md

@@ -0,0 +1,72 @@
+---
+skill: create-javascript-project
+skill-version: "1.0"
+---
+
+## Test Scenarios
+
+### Scenario 1: Create a new TypeScript library, happy path
+
+**Trigger / Input**
+
+"Create a new TypeScript library project called `retry-client`."
+
+**Expected Behaviour**
+
+1. Phase 1 gathers or infers the package name (`retry-client`), description, author, and Node.js
+   version (default `24`).
+2. Phase 2 creates the root `Makefile` (delegating to `lib/` then `examples/`), `.mise.toml`, and
+   `.gitignore` ignoring `node_modules/`, `dist/`, and `.cache/`.
+3. Phase 3 creates `lib/src/index.ts`, `lib/src/index.test.ts`, `lib/Makefile`, `lib/package.json`
+   (without `"type": "module"`), `lib/tsconfig.json`, `lib/jest.config.js`, and
+   `lib/eslint.config.mjs` pointing `parserOptions.project` at `tsconfig.json`.
+4. Phase 4 creates `examples/Makefile` and `examples/usage-basic/` consuming the packed tarball
+   from `lib/dist/`.
+5. Phase 5 creates the workspace `README.md` and `lib/README.md` with Quick Start first.
+6. Phase 6 verifies the Phase 6 checklist, including that `lib/src/index.ts` exports at least one
+   symbol and all `[package-name]` placeholders are replaced with `retry-client`.
+
+**Assertions**
+
+- [ ] Output creates a root `Makefile` that delegates every target to `lib/` and then `examples/`.
+- [ ] Output creates `lib/eslint.config.mjs` with `parserOptions.project` set to
+      `['./tsconfig.json']` and no duplicated closing syntax.
+- [ ] Output keeps `lib/package.json` without `"type": "module"` while using `eslint.config.mjs` as
+      the ESLint entry point.
+- [ ] Output replaces every `[package-name]` placeholder with `retry-client` across the generated
+      files.
+
+### Scenario 2: CLI tool request adds a bin entry and bundling step
+
+**Trigger / Input**
+
+"Scaffold a JavaScript CLI tool called `snap-cli`."
+
+**Expected Behaviour**
+
+Per the Edge Cases entry for CLI tools, the skill adds a `"bin"` field to `lib/package.json`
+pointing at the built output, creates `lib/src/main.ts` as the CLI entry point, and adds an
+esbuild bundling step to `lib/Makefile` rather than relying on the plain `tsc` build alone.
+
+**Assertions**
+
+- [ ] Output adds a `"bin"` field to `lib/package.json` referencing the built CLI entry point.
+- [ ] Output creates `lib/src/main.ts` as the CLI entry point and adds an esbuild bundle step to
+      `lib/Makefile`.
+
+### Scenario 3: "No examples needed" removes the examples delegation cleanly
+
+**Trigger / Input**
+
+"Create a TypeScript library called `token-cache` but skip the examples project."
+
+**Expected Behaviour**
+
+Per the Edge Cases entry for omitting examples, the skill does not create the `examples/`
+directory and removes the `examples` delegation step from the root `Makefile`, while still
+creating the full `lib/` structure and root `README.md`.
+
+**Assertions**
+
+- [ ] Output does not create an `examples/` directory.
+- [ ] Output's root `Makefile` does not include a delegation step to `examples/`.

package/.xdrs/agentme/edrs/application/skills/{052-create-python-project → create-python-project}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: 052-create-python-project
+name: create-python-project
 description: >
   Scaffolds the initial boilerplate structure for a Python project following the standard tooling
   and layout defined in agentme-edr-103. Activate this skill when the user asks to create,

package/.xdrs/agentme/edrs/application/skills/create-python-project/SKILL.test.md

@@ -0,0 +1,79 @@
+---
+skill: create-python-project
+skill-version: "1.0"
+---
+
+## Test Scenarios
+
+### Scenario 1: Create a new Python package, happy path
+
+**Trigger / Input**
+
+"Create a Python project called `event_tools`."
+
+**Expected Behaviour**
+
+1. Phase 1 gathers or infers package name (`event_tools`), description, author, Python version
+   (default `3.13`), and primary entry point.
+2. Phase 2 creates root `.mise.toml`, root `Makefile` (exporting `UV_PROJECT_ENVIRONMENT`/
+   `UV_CACHE_DIR`, delegating `build`/`lint`/`test` to `lib/`, and running each `examples/*`
+   project against the built wheel), root `.gitignore` ignoring `.venv/`, `dist/`, `.cache/`, and
+   `__pycache__/`, and root `README.md` with Getting Started (`make setup` / `make test`) near the
+   top.
+3. Phase 3 creates `lib/Makefile`, `lib/pyproject.toml` (Ruff, ty, pytest-cov, pip-audit
+   configured), and `lib/README.md` with Quick Start first.
+4. Phase 4 creates `lib/src/event_tools/` with `app/`, `adapters/`, `shared/` following the
+   hexagonal layout, plus `lib/tests/hello_test.py`.
+5. Phase 5 creates `examples/basic-usage/` as an independent consumer project that imports
+   `event_tools` rather than importing from `lib/src/`.
+6. Phase 6 runs `make setup`, `make install`, `make lint-fix`, `make test`, and `make build`, and
+   fixes any failures before finishing.
+
+**Assertions**
+
+- [ ] Output creates `lib/src/event_tools/app/`, `lib/src/event_tools/adapters/`, and
+      `lib/src/event_tools/shared/` following the hexagonal layout.
+- [ ] Output configures `lib/pyproject.toml` with Ruff, ty, pytest-cov, and pip-audit, and does
+      not add a separate `requirements.txt`, `setup.py`, `ruff.toml`, or `ty.toml`.
+- [ ] Output creates `examples/basic-usage/` as its own project that imports the `event_tools`
+      package rather than reaching into `lib/src/` with a relative import.
+- [ ] Output reports running `make lint-fix`, `make test`, and `make build` and fixes any
+      failures before declaring completion.
+
+### Scenario 2: CLI package request adds an entry point, not a new baseline
+
+**Trigger / Input**
+
+"Scaffold a Python CLI package called `net_probe` with a command named `probe`."
+
+**Expected Behaviour**
+
+Per Phase 4 and the skill's own CLI example, the skill keeps the same baseline Makefile and
+quality checks and adds the CLI entry point in `lib/src/net_probe/adapters/cli/__init__.py`,
+adding `[project.scripts]` to `lib/pyproject.toml` only because the command name (`probe`)
+differs from the module name (`net_probe`).
+
+**Assertions**
+
+- [ ] Output places the CLI entry point in `lib/src/net_probe/adapters/cli/__init__.py`, not in
+      `app/` or at the package root.
+- [ ] Output adds a `[project.scripts]` entry in `lib/pyproject.toml` mapping `probe` to the CLI
+      entry point.
+
+### Scenario 3: Example-only dependency stays in the example, not in lib/
+
+**Trigger / Input**
+
+"Add an example under `examples/` that calls a public HTTP API and therefore needs the `httpx`
+library. The core `event_tools` package itself does not need `httpx`."
+
+**Expected Behaviour**
+
+Per the Edge Cases entry on example dependencies, the skill adds `httpx` to that example's own
+`pyproject.toml` and does not add it to `lib/pyproject.toml`, since the library itself has no
+need for it.
+
+**Assertions**
+
+- [ ] Output adds `httpx` only to the example's own `pyproject.toml`.
+- [ ] Output does not add `httpx` to `lib/pyproject.toml`.

package/.xdrs/agentme/edrs/application/skills/{250-github-connector → github-connector}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: 250-github-connector
+name: github-connector
 description: >
   Base connector providing authentication, read access, and write access to GitHub pull
   requests and their comments via the gh CLI. Pure I/O -- no triage logic, no business
-  decisions. Activate when an agent or skill (such as pr-owner-assistant) needs to fetch or
+  decisions. Activate when an agent or skill (such as resolve-pr-comments) needs to fetch or
   post PR comments, resolve review threads, or check out a PR branch on GitHub.
 metadata:
   author: flaviostutz
@@ -18,9 +18,7 @@ Wraps the `gh` CLI -- GitHub's own supported API client -- so callers never cons
 REST/GraphQL calls or handle GitHub-specific auth themselves. Contains no business logic (per
 rule 05): it does not decide what a comment means, what action to take, or when to reply --
 it only reads and writes data and normalizes it to the shape consumed by
-[`400-pr-owner-assistant`](../../../principles/skills/400-pr-owner-assistant/SKILL.md).
-
-This is a base connector skill (number range 250-299).
+[`resolve-pr-comments`](../../../principles/skills/resolve-pr-comments/SKILL.md).
 
 ## Instructions
 
@@ -72,7 +70,7 @@ Normalize every fetched item to the shared record shape (`id`, `kind`, `status`,
 `can_resolve`, `path`, `line`, `content`, `author`, `in_reply_to`, `diff_hunk`, `url`):
 - `kind` is `"issue-comment"`, `"review-comment"`, or `"review-summary"`.
 - `status` is `"resolved"` when the GraphQL thread lookup marks it resolved, else `"open"`.
-  GitHub has no `wontfix`/`closed` state of its own -- `pr-owner-assistant` tracks those
+  GitHub has no `wontfix`/`closed` state of its own -- `resolve-pr-comments` tracks those
   locally.
 - `can_resolve` is `true` only for `"review-comment"` items belonging to a resolvable
   thread; `"issue-comment"` and `"review-summary"` are never resolvable -- set `false`.
@@ -181,7 +179,6 @@ thread via the GraphQL mutation using that comment's thread node id.
 
 ## References
 
-- [`400-pr-owner-assistant`](../../../principles/skills/400-pr-owner-assistant/SKILL.md) -- consumes this connector's normalized output.
+- [`resolve-pr-comments`](../../../principles/skills/resolve-pr-comments/SKILL.md) -- consumes this connector's normalized output.
 - [`agentme-edr-127`](../../127-external-system-adapter-skills.md) -- external system adapter skill rules (connector naming, Known Issues format, HITL-before-write).
 - [`agentme-edr-124`](../../124-secrets-management.md) -- credential storage and retrieval.
-- [`agentme-core-adr-003`](../../../../../agentme-core/adrs/principles/003-skill-numbering-ranges.md) -- skill numbering ranges (250-299 base connectors).

package/.xdrs/agentme/edrs/application/skills/{250-github-connector → github-connector}/SKILL.test.md

@@ -1,5 +1,5 @@
 ---
-skill: 250-github-connector
+skill: github-connector
 skill-version: "1.0"
 ---
 

package/.xdrs/agentme/edrs/application/skills/{200-run-skill-tests → run-skill-tests}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: 200-run-skill-tests
+name: run-skill-tests
 description: >
   Executes the SKILL.test.md test scenarios for a given skill, evaluates each assertion against the skill's
   actual output, and reports a pass/fail result per scenario. Activate when the user asks to test, verify,
@@ -17,7 +17,7 @@ Loads `SKILL.test.md` from a skill directory, runs each scenario by invoking the
 
 ### Phase 1: Locate and Validate SKILL.test.md
 
-1. Accept the skill path from the user (e.g., `.agents/skills/001-review` or `.xdrs/_local/adrs/principles/skills/005-my-skill`). If no path is given, ask: *"Which skill do you want to test? Provide the path to the skill directory."*
+1. Accept the skill path from the user (e.g., `.agents/skills/review` or `.xdrs/_local/adrs/principles/skills/005-my-skill`). If no path is given, ask: *"Which skill do you want to test? Provide the path to the skill directory."*
 2. Resolve the path to the directory containing `SKILL.md`. If the path is a symlink, follow it to the real directory.
 3. Check that `SKILL.test.md` exists in the same directory as `SKILL.md`. If it is missing, output:
 
@@ -91,9 +91,9 @@ A scenario passes only when every one of its assertions passes. The overall outc
 
 ## Examples
 
-**Input**: "Test the skill at `.agents/skills/001-review`"
+**Input**: "Test the skill at `.agents/skills/review`"
 
-- Phase 1 resolves the symlink → `.xdrs/_core/adrs/principles/skills/001-review/`
+- Phase 1 resolves the symlink → `.xdrs/_core/adrs/principles/skills/review/`
 - Reads `SKILL.test.md`, parses 3 scenarios
 - Executes each scenario with the target skill loaded
 - Reports per-assertion PASS/FAIL and an overall outcome

package/.xdrs/agentme/edrs/application/skills/{200-run-skill-tests → run-skill-tests}/SKILL.test.md

@@ -1,5 +1,5 @@
 ---
-skill: 200-run-skill-tests
+skill: run-skill-tests
 skill-version: "1.0"
 ---
 
@@ -8,9 +8,9 @@ skill-version: "1.0"
 ### Scenario 1: Successfully executes scenarios and reports results
 
 **Trigger / Input**
-You are an agent with the `200-run-skill-tests` skill loaded. The workspace has a skill at `.agents/skills/001-review` with both `SKILL.md` and `SKILL.test.md` present. The user says:
+You are an agent with the `run-skill-tests` skill loaded. The workspace has a skill at `.agents/skills/review` with both `SKILL.md` and `SKILL.test.md` present. The user says:
 
-"Test the skill at `.agents/skills/001-review`"
+"Test the skill at `.agents/skills/review`"
 
 **Expected Behaviour**
 1. Skill resolves the path to the real directory (following the symlink).
@@ -22,7 +22,7 @@ You are an agent with the `200-run-skill-tests` skill loaded. The workspace has
 7. Skill outputs a structured report using the mandated template with a final Outcome line.
 
 **Assertions**
-- [ ] Output contains `## Skill Test Report: 001-review`.
+- [ ] Output contains `## Skill Test Report: review`.
 - [ ] Output contains a `### Scenario` section for each scenario in `SKILL.test.md`.
 - [ ] Each scenario section lists individual assertion results as `PASS` or `FAIL`.
 - [ ] Output ends with a `## Summary` block containing `Scenarios:`, `Passed:`, `Failed:`, and `Outcome:`.
@@ -30,9 +30,9 @@ You are an agent with the `200-run-skill-tests` skill loaded. The workspace has
 ### Scenario 2: Halts with ERROR when SKILL.test.md is missing
 
 **Trigger / Input**
-You are an agent with the `200-run-skill-tests` skill loaded. The workspace has a skill directory `.xdrs/agentme/edrs/application/skills/050-create-javascript-project` that contains `SKILL.md` but no `SKILL.test.md`. The user says:
+You are an agent with the `run-skill-tests` skill loaded. The workspace has a skill directory `.xdrs/agentme/edrs/application/skills/create-javascript-project` that contains `SKILL.md` but no `SKILL.test.md`. The user says:
 
-"Run tests for `.xdrs/agentme/edrs/application/skills/050-create-javascript-project`"
+"Run tests for `.xdrs/agentme/edrs/application/skills/create-javascript-project`"
 
 **Expected Behaviour**
 1. Skill resolves the path to the directory.
@@ -49,7 +49,7 @@ You are an agent with the `200-run-skill-tests` skill loaded. The workspace has
 ### Scenario 3: Injects simulated human responses when present
 
 **Trigger / Input**
-You are an agent with the `200-run-skill-tests` skill loaded. The workspace has a skill at `.xdrs/agentme/edrs/principles/skills/refine-plan-mode` with both `SKILL.md` and `SKILL.test.md` present. Scenario 1 in that `SKILL.test.md` includes a `**Simulated Human Responses**` section with 9 ordered responses. The user says:
+You are an agent with the `run-skill-tests` skill loaded. The workspace has a skill at `.xdrs/agentme/edrs/principles/skills/refine-plan-mode` with both `SKILL.md` and `SKILL.test.md` present. Scenario 1 in that `SKILL.test.md` includes a `**Simulated Human Responses**` section with 9 ordered responses. The user says:
 
 "Test the skill at `.xdrs/agentme/edrs/principles/skills/refine-plan-mode`"
 

package/.xdrs/agentme/edrs/application/skills/{010-select-relevant-xdrs → select-relevant-xdrs}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: 010-select-relevant-xdrs
+name: select-relevant-xdrs
 description: >
    Analyzes a client repository, extracts the full agentme XDR set, and excludes the records that do
    not fit the project's structure and workflow needs. Activate this skill when the user asks to

package/.xdrs/agentme/edrs/application/skills/select-relevant-xdrs/SKILL.test.md

@@ -0,0 +1,73 @@
+---
+skill: select-relevant-xdrs
+skill-version: "1.0"
+---
+
+## Test Scenarios
+
+### Scenario 1: Install presets for a single-package Node.js library, happy path
+
+**Trigger / Input**
+
+"Install the right agentme XDR presets for this Node.js library." The repository is a single npm
+package with a Makefile and no Go code, no monorepo layout, and no deployed/long-running service.
+
+**Expected Behaviour**
+
+1. Phase 1 inventories the shipped agentme XDR files.
+2. Phase 2 analyzes the repository and detects a JavaScript/TypeScript single-package library with
+   Makefiles, no Go tooling, no monorepo structure, and no service surface.
+3. Phase 3 selects exclusions with one-line rationale each — at minimum the Go project tooling XDR
+   and the service health-check XDR — while keeping baseline/broadly applicable guidance.
+4. Phase 4 runs `npx -y agentme extract --output . --all --exclude <path> --exclude <path>` with
+   one `--exclude` flag per excluded XDR, then verifies `.xdrs/index.md`, `.xdrs/agentme/`, and
+   `AGENTS.md` exist and that every excluded path is absent from the output.
+
+**Assertions**
+
+- [ ] Output excludes `.xdrs/agentme/edrs/application/102-golang-project-tooling.md` and
+      `.xdrs/agentme/edrs/operations/401-service-health-check-endpoint.md` with a one-line
+      rationale for each.
+- [ ] Output runs `agentme extract` with `--all` plus one `--exclude` flag per excluded XDR path,
+      rather than a hand-picked include list.
+- [ ] Output verifies after extraction that `.xdrs/index.md`, `.xdrs/agentme/`, and `AGENTS.md`
+      exist and that the excluded paths are absent from the result.
+
+### Scenario 2: Extraction blocked when the package exposes no inventory metadata
+
+**Trigger / Input**
+
+Run the skill in an environment where the CLI cannot enumerate the shipped XDRs, and the package
+metadata and repository documentation also do not describe the shipped XDR set.
+
+**Expected Behaviour**
+
+Per Phase 1 step 4, since even the fallback inventory sources fail, the skill stops before
+attempting any extraction and reports that automatic selection is blocked because the package does
+not expose enough metadata in the current environment, rather than guessing an exclude list or
+forcing a full installation.
+
+**Assertions**
+
+- [ ] Output stops before running any `agentme extract` command.
+- [ ] Output reports that automatic selection is blocked due to insufficient package metadata,
+      rather than silently falling back to a default guess.
+
+### Scenario 3: Debatable exclusion is kept, not excluded
+
+**Trigger / Input**
+
+Analyzing a currently single-package repository whose README states the team is planning to split
+it into multiple applications "sometime in the future." Whether the monorepo-structure XDR still
+applies is debatable.
+
+**Expected Behaviour**
+
+Per the Edge Cases entry on debatable exclusions, since the mismatch is not concrete today, the
+skill keeps the monorepo-structure XDR in the installed set rather than excluding it on the basis
+of a possible future restructuring.
+
+**Assertions**
+
+- [ ] Output keeps `.xdrs/agentme/edrs/platform/301-monorepo-structure.md` in the installed set.
+- [ ] Output does not add it to the exclude list on the basis of a future, not-yet-concrete plan.

package/.xdrs/agentme/edrs/governance/502-contributing-guide-requirements.md

@@ -67,4 +67,4 @@ The content SHOULD stay concise and practical; do not turn `CONTRIBUTING.md` int
 ## References
 
 - [agentme-edr-301 - Monorepo structure](../platform/301-monorepo-structure.md)
-- [053-monorepo-setup skill](../platform/skills/053-monorepo-setup/SKILL.md)
+- [monorepo-setup skill](../platform/skills/monorepo-setup/SKILL.md)