agentme 0.35.2 → 0.37.0

package/.xdrs/agentme/edrs/application/skills/azure-devops-connector/SKILL.md

@@ -0,0 +1,202 @@
+---
+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 resolve-pr-comments) needs to
+  fetch or post PR thread comments, change thread status, or check out a PR branch on Azure
+  DevOps.
+metadata:
+  author: flaviostutz
+  version: "1.1"
+---
+
+## Overview
+
+Reusable authentication and connection skill for Azure DevOps pull requests, per
+[agentme-edr-127](../../127-external-system-adapter-skills.md) rule 06 (connector naming).
+Wraps the `az` CLI (with the `azure-devops` extension) -- Azure DevOps's own supported API
+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
+[`resolve-pr-comments`](../../../principles/skills/resolve-pr-comments/SKILL.md).
+
+## Instructions
+
+### Authentication check
+
+1. Verify the `az` CLI is installed (`az --version`); if missing, ask the human whether to
+   install it now via the appropriate package manager for their OS (e.g. `brew install
+   azure-cli` on macOS). Only run the install command after explicit confirmation; if the
+   human declines or the install fails, report the install requirement and stop.
+2. Verify the `azure-devops` extension is present; if missing, install it with
+   `az extension add --name azure-devops` (auto-installs on first use in most `az` versions,
+   but check explicitly rather than assuming).
+3. Run `az account show`. If authenticated, proceed -- prefer `az login`'s own session over
+   handling a token directly.
+4. If not authenticated, check the OS keychain for a stored Azure DevOps PAT per
+   [agentme-edr-124](../../124-secrets-management.md) rather than any `.env` file, hardcoded
+   value, or shell profile export. If found, export it only transiently as
+   `AZURE_DEVOPS_EXT_PAT` for the current command invocation -- never persist it to disk.
+5. If no session and no stored PAT exist, prompt the human to run `az login` interactively
+   or to store a PAT in the keychain first, per agentme-edr-124's `setup-secrets` pattern.
+   Do not proceed with a write operation without one of these. Unlike `gh auth login`, bare
+   `az login` already opens the browser directly with no preceding host/protocol/method
+   questions, so no extra flags are needed here to keep it non-interactive.
+6. Set the default organization/project once per session
+   (`az devops configure --defaults organization=<url> project=<project>`) to shorten
+   subsequent commands.
+7. Never substitute `az`/`az rest` with a direct HTTP call (`curl`, `fetch`, or any other
+   HTTP client) against the Azure DevOps REST API, and never scrape the PR's web UI as a
+   workaround -- this applies to reads as much as writes, and applies even when the target
+   data looks read-only. If `az`, the `azure-devops` extension, or a valid session/PAT is
+   missing, stop and resolve that first (steps 1-5 above); do not degrade to an alternative
+   retrieval method to route around it.
+
+### Reading data
+
+All read commands are exempt from HITL confirmation (per agentme-edr-127 rule 04, read-only
+operations need no confirmation -- but they are not exempt from the CLI-only channel).
+Every read below MUST go through `az`/`az rest`; never construct the equivalent REST call
+with `curl`/another HTTP client, and never fetch or scrape the PR's web UI as a substitute.
+
+- PR metadata: `az repos pr show --id <n> --output json`
+- All comment threads (Azure DevOps has no separate "list comments" call -- threads are the
+  unit of data and already include every comment and their status):
+  `az rest --method GET --uri "https://dev.azure.com/{org}/{project}/_apis/git/repositories/{repo}/pullRequests/{n}/threads?api-version=7.1"`
+  There is no dedicated `az repos pr` subcommand for threads -- `az rest` is required for both
+  reads and writes; verify this generic-URI capability with `az rest --help` and a smoke-test
+  GET before first use in a new environment.
+
+Normalize every thread's comments to the shared record shape (`id`, `kind`, `status`,
+`can_reply`, `can_resolve`, `path`, `line`, `content`, `author`, `in_reply_to`, `diff_hunk`,
+`url`):
+- `id` is `"thread-comment/<threadId>.<commentId>"` -- Azure DevOps ids are scoped per PR, not
+  global, so always keep the PR number alongside when persisting.
+- `kind` is always `"thread-comment"` -- Azure DevOps has no separate review-summary concept;
+  never emit a `"review-summary"` kind for this provider.
+- `status` maps from the thread's `status` field: `"active"` -> `"open"`, `"fixed"` /
+  `"closed"` -> `"resolved"`, `"wontFix"` -> `"wontfix"`, `"pending"` -> `"open"`.
+- `path`/`line` come from `threadContext.filePath` and the relevant line range; when
+  `threadContext` is `null`, this is a general (PR-level, not file-scoped) comment -- classify
+  it as a general comment, not a parsing error.
+- `can_reply` and `can_resolve` are `true` for any non-deleted comment in a non-deleted
+  thread; Azure DevOps does not have GitHub's permission-driven resolve restriction in the
+  same way, but a 403 on write still means `can_resolve` should be treated as `false` for
+  that session (see Known Issues).
+- `in_reply_to` is the thread's first comment id whenever the target is a reply within the
+  same thread -- Azure DevOps threads are flat, so there is no root-vs-reply distinction to
+  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; `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
+  permalink from the PR's own web URL plus a `?discussionId=<threadId>` anchor (Azure
+  DevOps' web UI convention for deep-linking to a thread); fall back to the PR's own URL
+  with no anchor when this convention cannot be confirmed reliable for the target
+  organization, rather than risking a broken or misleading link (see Known Issues).
+
+### Writing data
+
+Before any write below, show the mandatory confirmation (per agentme-edr-127 rule 04):
+**System** (org/project/repo + PR number), **Operation**, **Fields** (exact verbatim text to
+post), **Estimated impact** (visible to PR participants, triggers notifications). Wait for
+explicit confirmation; never proceed on an assumed "yes."
+
+- Reply within an existing thread:
+  `az rest --method POST --uri ".../pullRequests/{n}/threads/{threadId}/comments?api-version=7.1" --body '{"content": "...", "parentCommentId": <id>}'`
+- Post a new general (non-file-scoped) comment as a new thread:
+  `az rest --method POST --uri ".../pullRequests/{n}/threads?api-version=7.1" --body '{"comments": [{"content": "..."}]}'`
+- Change thread status (the resolve/won't-fix equivalent):
+  `az rest --method PATCH --uri ".../pullRequests/{n}/threads/{threadId}?api-version=7.1" --body '{"status": "fixed"}'` (use `"wontFix"` or `"closed"` as appropriate instead of `"fixed"`).
+- Check out the PR branch: `az repos pr checkout --id <n>`.
+
+### Constraints
+
+- MUST use `az`/`az rest` for every read and write handled by this connector -- never fall
+  back to `curl`, another raw HTTP client, or scraping the PR's web UI, even when `az` is
+  missing, unauthenticated, or erroring, and even when the target data looks read-only.
+- MUST stop and follow the Authentication check steps above when `az` cannot complete a
+  request, instead of silently degrading to an alternative retrieval method.
+
+## Examples
+
+**Input**: fetch all comments for
+`https://dev.azure.com/contoso/Widgets/_git/widgets-api/pullrequest/1029`
+
+Runs `az repos pr show --id 1029` for metadata, then the single threads `az rest GET` call
+above, and returns a single normalized list built from every thread's comments.
+
+**Input**: reply to thread comment id `thread-comment/12.1` and set the thread to fixed
+
+Shows the mandatory confirmation summary first. On explicit "yes," posts the reply via the
+threads/comments `POST`, then updates thread status via the `PATCH` call.
+
+## Edge Cases
+
+- **Modern vs legacy URL formats**: recognize both
+  `dev.azure.com/{org}/{project}/_git/{repo}/pullrequest/{id}` and
+  `{org}.visualstudio.com/{project}/_git/{repo}/pullrequest/{id}` as valid Azure DevOps PR
+  URLs; extract org/project/repo/id from either shape.
+- **`threadContext` is `null`**: classify as a general PR-level comment, never as a parse
+  failure.
+- **PR-scoped ids**: never assume a thread or comment id is unique outside its PR; always
+  carry the PR number alongside when the tracking file persists an id.
+
+## Known Issues
+
+- **Symptom:** the `azure-devops` extension has no `az repos pr comment` or `az repos pr
+  thread` subcommand at all.
+  **Cause:** the extension only covers a subset of the Git PR API; thread and comment
+  operations were never added as first-class subcommands.
+  **Fix:** always use `az rest` with the documented REST endpoints above for every thread
+  and comment read or write; do not search for a nonexistent dedicated subcommand.
+- **Symptom:** a thread that should be resolvable cannot be updated; the `PATCH` call returns
+  HTTP 403 despite `az account show` showing a valid, logged-in session.
+  **Cause:** the authenticated identity lacks the "Contribute to pull requests" permission
+  on the repository.
+  **Fix:** degrade to reply-only for that thread, report the permission gap plainly, and
+  never retry the same call silently.
+- **Symptom:** `az rest` against a `dev.azure.com/.../_apis/...` URL fails most calls with
+  `TF400813: The user 'aaaaaaaa-aaaa-...' is not authorized`, or -- observed once, isolated
+  to a single call in an otherwise-failing batch -- exits 0 (looks successful) while the
+  write never actually appears when the thread is re-read.
+  **Cause:** `az rest` cannot always derive the correct Azure AD resource from the URL
+  alone and can silently fall back to an anonymous/placeholder identity; this has been
+  observed to be intermittent within a batch of otherwise-identical calls.
+  **Fix:** always pass `--resource 499b84ac-1321-427f-aa17-267ca6975798` (Azure DevOps'
+  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. `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
+  thread.
+  **Fix:** never emit a `"review-summary"` kind for this connector; always normalize to
+  `"thread-comment"`.
+- **Symptom:** an agent fetched PR metadata or thread comments via `curl`/direct REST calls
+  or by scraping the PR's web UI instead of using `az`/`az rest`.
+  **Cause:** `az` was missing, unauthenticated, or lacked the `azure-devops` extension, and
+  the agent treated a direct unauthenticated REST call or the rendered PR page as an
+  acceptable substitute since the target data looked read-only.
+  **Fix:** never substitute `az`/`az rest` with a direct HTTP call or a page scrape. Stop at
+  the Authentication check step, report the missing or failed `az` session plainly, and wait
+  for the human to install, extend, or authenticate `az` before retrying the same read or
+  write through `az`.
+- **Symptom:** a synthesized comment permalink (`url`) 404s, or lands on the PR overview
+  instead of the specific thread, when opened.
+  **Cause:** Azure DevOps' web UI deep-link format for a specific thread
+  (`?discussionId=<threadId>`) is a UI convention, not a documented, versioned part of the
+  REST API, and can vary by organization or Azure DevOps version.
+  **Fix:** verify the `?discussionId=<threadId>` anchor against a live PR in the target
+  organization before relying on it; degrade to the PR's own URL with no anchor when
+  uncertain, rather than guessing at a format that might mislead the human.
+
+## References
+
+- [`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.

package/.xdrs/agentme/edrs/application/skills/azure-devops-connector/SKILL.test.md

@@ -0,0 +1,114 @@
+---
+skill: azure-devops-connector
+skill-version: "1.0"
+---
+
+## Test Scenarios
+
+### Scenario 1: Fetch and normalize thread comments, happy path
+
+**Trigger / Input**
+
+Fetch all comments for
+`https://dev.azure.com/contoso/Widgets/_git/widgets-api/pullrequest/1029`, a PR with one
+active file-scoped thread and one active general (PR-level) thread.
+
+**Expected Behaviour**
+
+The connector: (1) confirms `az account show` is authenticated; (2) runs
+`az repos pr show --id 1029`; (3) runs the single `az rest --method GET` threads call
+(there is no separate "list comments" call); (4) returns a normalized list where the
+file-scoped thread's comment has non-null `path`/`line` and `kind: "thread-comment"`, and
+the general thread's comment has null `path`/`line` and is still classified as a normal
+`"thread-comment"`, both with `status: "open"`.
+
+**Assertions**
+
+- [ ] Output normalizes every fetched comment to the shared record shape (id, kind, status,
+      can_reply, can_resolve, path, line, content, author, in_reply_to).
+- [ ] Output maps the thread `status: "active"` field to the normalized `status: "open"`.
+- [ ] Connector uses `az rest` for the threads read rather than searching for a dedicated
+      `az repos pr` comment subcommand.
+
+### Scenario 2: Null threadContext classified as a general comment, not an error
+
+**Trigger / Input**
+
+A fetched thread has `threadContext: null` in the raw API response.
+
+**Expected Behaviour**
+
+Per the Reading data normalization rule and the matching Edge Cases entry, the connector
+classifies this thread's comment as a general PR-level comment (`path`/`line` set to null in
+the normalized record) rather than treating the missing `threadContext` as a parsing failure
+or skipping the comment.
+
+**Assertions**
+
+- [ ] Connector includes the comment in its normalized output with `path`/`line` set to null.
+- [ ] Connector does not raise a parse error or silently drop the comment because of the
+      null `threadContext`.
+
+### Scenario 3: Thread status change writes via az rest PATCH with mandatory confirmation
+
+**Trigger / Input**
+
+Set thread id 12 on PR 1029 to resolved ("fixed") status after a fix was applied.
+
+**Expected Behaviour**
+
+The connector shows the mandatory System/Operation/Fields/Estimated impact confirmation
+(naming org/project/repo + PR number and the target status), waits for explicit
+confirmation, then issues
+`az rest --method PATCH --uri ".../pullRequests/1029/threads/12?api-version=7.1" --body '{"status": "fixed"}'`.
+No dedicated `az repos pr` subcommand is used for this operation.
+
+**Assertions**
+
+- [ ] Connector shows the mandatory confirmation before issuing the PATCH call.
+- [ ] Connector does not issue the PATCH call before explicit human confirmation.
+- [ ] Connector uses `az rest` rather than a nonexistent dedicated thread-status subcommand.
+
+### Scenario 4: Legacy visualstudio.com URL parses the same as a modern dev.azure.com URL
+
+**Trigger / Input**
+
+`https://contoso.visualstudio.com/Widgets/_git/widgets-api/pullrequest/1029` (legacy format)
+versus `https://dev.azure.com/contoso/Widgets/_git/widgets-api/pullrequest/1029` (modern
+format) for the same underlying PR.
+
+**Expected Behaviour**
+
+The connector extracts the same org (`contoso`), project (`Widgets`), repo
+(`widgets-api`), and PR id (`1029`) from either URL shape and proceeds identically from
+that point on.
+
+**Assertions**
+
+- [ ] Connector extracts identical org/project/repo/PR-id values from both URL formats.
+- [ ] Connector does not require the human to reformat a legacy URL before use.
+
+### Scenario 5: az unavailable or unauthenticated never triggers a curl/scrape fallback
+
+**Trigger / Input**
+
+Fetch PR metadata and thread comments for
+`https://dev.azure.com/contoso/Widgets/_git/widgets-api/pullrequest/1029` while `az account
+show` reports no session and no PAT is stored in the keychain (or `az`/the `azure-devops`
+extension is not installed).
+
+**Expected Behaviour**
+
+The connector does not issue any direct `curl`/HTTP request against the Azure DevOps REST
+API, and does not fetch or scrape the PR's web UI as a substitute -- even if the project
+looks publicly reachable. Instead it follows the Authentication check steps, reports the
+missing session/PAT or missing installation plainly, and halts every read and write until
+`az account show` succeeds or a keychain PAT is available.
+
+**Assertions**
+
+- [ ] Connector does not issue a `curl` or other raw HTTP request to any Azure DevOps
+      endpoint as a substitute for `az`/`az rest`.
+- [ ] Connector does not fetch or scrape the PR's web UI as a fallback.
+- [ ] Connector halts reads and writes and prompts for `az` installation/authentication
+      rather than degrading to an alternative retrieval method.

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`.