agentme 0.36.0 → 0.37.1

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

@@ -1,13 +1,14 @@
 ---
-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
-  version: "1.1"
+  version: "1.2.0"
+  updated: 2026-09-21
 ---
 
 ## Overview
@@ -18,9 +19,28 @@ 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).
+[`resolve-pr-comments`](../../../principles/skills/resolve-pr-comments/SKILL.md).
 
-This is a base connector skill (number range 250-299).
+### Inputs
+
+#### Required
+- PR identifier (`owner/repo` + number) and operation
+
+#### Optional
+- Comment/thread id (replies, resolution)
+
+### Outputs
+
+#### Contents
+- Normalized comment/thread records; write confirmation
+
+#### Changes
+- PR comments, replies, thread resolution (writes only)
+
+### Halt Conditions
+- `gh` CLI missing or unauthenticated
+- Write operation lacks explicit human confirmation
+- Only a non-`gh` HTTP fallback is available
 
 ## Instructions
 
@@ -72,7 +92,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`.
@@ -179,9 +199,20 @@ thread via the GraphQL mutation using that comment's thread node id.
   `GH_PAGER=cat gh api repos/{owner}/{repo}/issues/{n}/comments`) when running non-
   interactively, which disables `gh`'s pager unconditionally.
 
+## Anti-Patterns
+
+- **Mistake:** Falling back to `curl`/HTML scraping when `gh` is missing or unauthenticated.
+  **Why it happens:** The target data is often technically public, so a workaround feels harmless.
+  **Instead:** Stop at the Authentication check and wait for the human to fix `gh`.
+- **Mistake:** Assuming a numeric REST comment/review id also works for GraphQL mutations.
+  **Why it happens:** Both values look like ordinary identifiers for the same comment.
+  **Instead:** Always resolve the thread's GraphQL node id first via `reviewThreads`.
+- **Mistake:** Posting a write without showing the mandatory confirmation summary.
+  **Why it happens:** The payload already looks correct, so confirmation feels redundant.
+  **Instead:** Always show System/Operation/Fields/Impact and wait for explicit confirmation.
+
 ## 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,6 +1,6 @@
 ---
-skill: 250-github-connector
-skill-version: "1.0"
+skill: github-connector
+skill-version: "1.2.0"
 ---
 
 ## Test Scenarios

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

@@ -1,23 +1,45 @@
 ---
-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,
   or validate a skill, or before merging a PR that modifies a skill or its SKILL.test.md.
 metadata:
   author: flaviostutz
-  version: "1.0"
+  version: "1.1.0"
+  updated: 2026-09-21
 ---
 
 ## Overview
 
 Loads `SKILL.test.md` from a skill directory, runs each scenario by invoking the target skill with the specified trigger, evaluates every assertion against the output, and produces a structured test report.
 
+### Inputs
+
+#### Required
+- Path to the skill directory to test
+
+#### Optional
+- None
+
+### Outputs
+
+#### Contents
+- Structured PASS/FAIL test report, per scenario and assertion
+
+#### Changes
+- None (read-only; never modifies the skill or test file)
+
+### Halt Conditions
+- Skill path not provided and not inferable from context
+- Skill directory or `SKILL.test.md` not found
+- `SKILL.test.md` has no scenarios
+
 ## Instructions
 
 ### 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 +113,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
@@ -111,6 +133,18 @@ A scenario passes only when every one of its assertions passes. The overall outc
 - If the target skill fails to activate (e.g., not registered in VS Code), note this in the report as FAIL with reason "skill could not be activated" and continue to remaining scenarios.
 - If `skill-version` in `SKILL.test.md` does not match `SKILL.md`, emit a WARNING at the top of the report but do not halt.
 
+## Anti-Patterns
+
+- **Mistake:** Modifying the skill or its test file while testing it.
+  **Why it happens:** An obvious bug seen mid-test is tempting to fix right away.
+  **Instead:** Never modify either file; only report the FAIL and evidence.
+- **Mistake:** Treating an INCONCLUSIVE assertion as a pass.
+  **Why it happens:** An ambiguous result can feel close enough to success.
+  **Instead:** Always treat INCONCLUSIVE the same as FAIL, with a reason.
+- **Mistake:** Silently continuing when `skill-version` mismatches `SKILL.md`.
+  **Why it happens:** A version-string mismatch looks cosmetic and unimportant.
+  **Instead:** Emit a visible WARNING at the top of the report.
+
 ## References
 
 - [`agentme-edr-policy-017`](../../../principles/017-skill-testing.md) — Skill testing mandate and SKILL.test.md format specification

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

@@ -1,6 +1,6 @@
 ---
-skill: 200-run-skill-tests
-skill-version: "1.0"
+skill: run-skill-tests
+skill-version: "1.1.0"
 ---
 
 ## Test Scenarios
@@ -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
@@ -7,7 +7,8 @@ description: >
    bootstrap agentme guidance into a repository without manually deciding which records to keep.
 metadata:
   author: flaviostutz
-  version: "1.0"
+  version: "1.1.0"
+  updated: 2026-09-21
 compatibility: Node.js 18+
 ---
 
@@ -17,6 +18,27 @@ Installs the full agentme XDR set for a repository through the published CLI, th
 records that clearly do not fit the target project by passing explicit `--exclude` flags during
 extraction.
 
+### Inputs
+
+#### Required
+- Target repository to install/update agentme XDRs into
+
+#### Optional
+- Explicit list of XDRs to keep or exclude
+
+### Outputs
+
+#### Contents
+- Installed `.xdrs/` tree, minus excluded records
+
+#### Changes
+- Existing `.xdrs/` merged/updated in place
+
+### Halt Conditions
+- Package does not expose enough metadata to enumerate shipped XDRs
+- Extraction would overwrite locally customized agent files
+- Candidate exclusion is debatable (keep instead of guessing)
+
 ## Instructions
 
 ### Phase 1: Discover the available extractable artifacts
@@ -131,6 +153,18 @@ Input: "Set up agentme for this repo"
 - If the repository is a spike or intentionally minimal experiment, still prefer the smallest preset
    set of workflow artifacts and avoid adding scaffolding that the project will not use.
 
+## Anti-Patterns
+
+- **Mistake:** Excluding an XDR whenever its fit is merely debatable.
+  **Why it happens:** Fewer records feels like a cleaner, more tailored result.
+  **Instead:** Keep the XDR; exclude only records that clearly do not fit.
+- **Mistake:** Overwriting locally customized agent files during extraction.
+  **Why it happens:** Preset extraction defaults to replacing existing files.
+  **Instead:** Warn the user first and describe the likely merge points.
+- **Mistake:** Failing immediately when the CLI cannot list shipped XDRs directly.
+  **Why it happens:** The direct enumeration path is the expected happy path.
+  **Instead:** Fall back to published package metadata or the README inventory.
+
 ## References
 
 - [agentme README](../../../../../../README.md)

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

@@ -0,0 +1,73 @@
+---
+skill: select-relevant-xdrs
+skill-version: "1.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)

package/.xdrs/agentme/edrs/index.md

@@ -8,12 +8,12 @@ Propose changes via pull request. All changes must be verified for clarity and n
 
 Foundational standards, principles, and guidelines.
 
-- [150-refine-plan-mode](principles/skills/150-refine-plan-mode/SKILL.md) - **Refine plan mode** — MANDATORY skill for ANY planning activity (plan, design, propose, outline, draft, brainstorm, architect). Read and follow in full before any execution begins. Must be read from XDRS even when not in `.agents/skills`. *(skill)*
-- [151-refine-user-story](principles/skills/151-refine-user-story/SKILL.md) - **Refine user stories** — Refine, elaborate, study or develop the contents of a user story used to create a unit of work for an agile team. Runs a structured 10-phase refinement process: understand the request, qualify requirements, research context, review consistency, validate visually, challenge from 9 user-perspective angles (Phase 6), challenge from 8 implementer-perspective angles (Phase 7), produce a ready-to-implement story (Phase 8), and run a final readiness double-check (Phase 9). *(skill)*
-- [400-pr-owner-assistant](principles/skills/400-pr-owner-assistant/SKILL.md) - **PR owner assistant** — Helps the OWNER of a pull request work through comments left by others: fetches every comment (GitHub or Azure DevOps) from its URL, tracks them in a local file, and walks through triaging each one (reply-question, won't-fix, work-on-a-fix) with explicit human confirmation at every step. A hands-on, mutating workflow to answer feedback and land fixes -- not a code-review skill. Delegates provider-specific reads/writes to `250-github-connector` or `251-azure-devops-connector`. *(skill)*
+- [refine-plan-mode](principles/skills/refine-plan-mode/SKILL.md) - **Refine plan mode** — MANDATORY skill for ANY planning activity (plan, design, propose, outline, draft, brainstorm, architect). Read and follow in full before any execution begins. Must be read from XDRS even when not in `.agents/skills`. *(skill)*
+- [refine-user-story](principles/skills/refine-user-story/SKILL.md) - **Refine user stories** — Refine, elaborate, study or develop the contents of a user story used to create a unit of work for an agile team. Runs a structured 10-phase refinement process: understand the request, qualify requirements, research context, review consistency, validate visually, challenge from 9 user-perspective angles (Phase 6), challenge from 8 implementer-perspective angles (Phase 7), produce a ready-to-implement story (Phase 8), and run a final readiness double-check (Phase 9). *(skill)*
+- [resolve-pr-comments](principles/skills/resolve-pr-comments/SKILL.md) - **Resolve PR comments** — Helps the OWNER of a pull request work through comments left by others: fetches every comment (GitHub or Azure DevOps) from its URL, tracks them in a local file, and walks through triaging each one (reply, won't-fix, fix) at a human-chosen automation level -- from fully automatic to fully guided, with fine-grained free-text control over the mix -- while syncing back to the provider always stays its own explicitly confirmed step. A hands-on, mutating workflow to answer feedback and land fixes -- not a code-review skill. Delegates provider-specific reads/writes to `github-connector` or `azure-devops-connector`. *(skill)*
 - [agentme-edr-012](principles/012-continuous-xdr-enrichment.md) - **Continuous xdr improvement policy** - Promote recurring delivery lessons into reusable XDRs
 - [agentme-edr-016](principles/016-cross-language-module-structure.md) - **Cross-language module structure** - Organize modules consistently across supported languages
-- [agentme-edr-017](principles/017-skill-testing.md) - **skill testing** - Mandates a `SKILL.test.md` co-located with every skill in scopes that follow agentme; defines test scenario format (trigger, expected behaviour, assertions) and requires execution before merging any skill change *(includes skill: [200-run-skill-tests](application/skills/200-run-skill-tests/SKILL.md))*
+- [agentme-edr-017](principles/017-skill-testing.md) - **skill testing** - Mandates a `SKILL.test.md` co-located with every skill in scopes that follow agentme; defines test scenario format (trigger, expected behaviour, assertions) and requires execution before merging any skill change *(includes skill: [run-skill-tests](application/skills/run-skill-tests/SKILL.md))*
 
 ## Articles
 
@@ -31,17 +31,17 @@ Language and framework-specific tooling and project structure.
 - [agentme-edr-124](application/124-secrets-management.md) - **Secrets management** - Handle secrets securely using native keychains and cloud secret managers
 - [agentme-edr-125](application/125-coding-abstraction-practices.md) - **Coding abstraction practices** - Define when abstractions are justified and when they must be inlined
 - [agentme-edr-127](application/127-external-system-adapter-skills.md) - **External system adapter skills** - Priority-ordered approach and adapter skill authoring standards for automating interactions with external systems
-- [250-github-connector](application/skills/250-github-connector/SKILL.md) - **GitHub connector** — Base connector providing authentication, read access, and write access to GitHub pull requests and their comments via the `gh` CLI. *(skill)*
-- [251-azure-devops-connector](application/skills/251-azure-devops-connector/SKILL.md) - **Azure DevOps connector** — Base connector providing authentication, read access, and write access to Azure DevOps pull requests and their comment threads via the `az` CLI. *(skill)*
+- [github-connector](application/skills/github-connector/SKILL.md) - **GitHub connector** — Base connector providing authentication, read access, and write access to GitHub pull requests and their comments via the `gh` CLI. *(skill)*
+- [azure-devops-connector](application/skills/azure-devops-connector/SKILL.md) - **Azure DevOps connector** — Base connector providing authentication, read access, and write access to Azure DevOps pull requests and their comment threads via the `az` CLI. *(skill)*
 
 ### Language and framework tooling
 
-- [agentme-edr-101](application/101-javascript-project-tooling.md) - **JavaScript project tooling and structure** - Scaffold JavaScript libraries with the standard toolchain *(includes skill: [050-create-javascript-project](application/skills/050-create-javascript-project/SKILL.md))*
-- [agentme-edr-102](application/102-golang-project-tooling.md) - **Go project tooling and structure** - Scaffold Go CLIs and libraries with the standard layout *(includes skill: [051-create-golang-project](application/skills/051-create-golang-project/SKILL.md))*
-- [agentme-edr-103](application/103-python-project-tooling.md) - **Python project tooling and structure** - Scaffold Python packages and CLIs with the standard layout *(includes skill: [052-create-python-project](application/skills/052-create-python-project/SKILL.md))*
+- [agentme-edr-101](application/101-javascript-project-tooling.md) - **JavaScript project tooling and structure** - Scaffold JavaScript libraries with the standard toolchain *(includes skill: [create-javascript-project](application/skills/create-javascript-project/SKILL.md))*
+- [agentme-edr-102](application/102-golang-project-tooling.md) - **Go project tooling and structure** - Scaffold Go CLIs and libraries with the standard layout *(includes skill: [create-golang-project](application/skills/create-golang-project/SKILL.md))*
+- [agentme-edr-103](application/103-python-project-tooling.md) - **Python project tooling and structure** - Scaffold Python packages and CLIs with the standard layout *(includes skill: [create-python-project](application/skills/create-python-project/SKILL.md))*
 - [agentme-edr-104](application/104-cli-tool-standards.md) - **CLI tool standards** - Define command UX and behavior for CLI tools
 - [agentme-edr-126](application/126-pragmatic-hexagonal-architecture.md) - **Pragmatic hexagonal architecture** - Organize application layers as External/Adapters/Application with practical coupling rules
-- [010-select-relevant-xdrs](application/skills/010-select-relevant-xdrs/SKILL.md) - **Select relevant XDRs**
+- [select-relevant-xdrs](application/skills/select-relevant-xdrs/SKILL.md) - **Select relevant XDRs**
 
 ### AI development
 
@@ -75,7 +75,7 @@ Data layer implementation and data management decisions.
 
 Infrastructure implementation, delivery pipeline, and developer environment decisions.
 
-- [agentme-edr-301](platform/301-monorepo-structure.md) - **Monorepo structure** - Standardize monorepo layout, tooling, and package boundaries *(includes skill: [053-monorepo-setup](platform/skills/053-monorepo-setup/SKILL.md))*
+- [agentme-edr-301](platform/301-monorepo-structure.md) - **Monorepo structure** - Standardize monorepo layout, tooling, and package boundaries *(includes skill: [monorepo-setup](platform/skills/monorepo-setup/SKILL.md))*
 - [agentme-edr-302](platform/302-github-pipelines.md) - **GitHub CI/CD pipelines** - Define required CI stages and workflow structure
 - [agentme-edr-303](platform/303-common-targets.md) - **Common development script names** - Reuse standard build, lint, and test target names
 - [agentme-edr-304](platform/304-tool-execution-and-scripting.md) - **Tool execution and scripting** - Run tools consistently across shells, Makefiles, and CI
@@ -93,3 +93,8 @@ Contribution and collaboration standards shared across projects.
 Production behavior and operational response decisions.
 
 - [agentme-edr-401](operations/401-service-health-check-endpoint.md) - **Service health check endpoint** - Expose a standard runtime health-check endpoint for services
+- [agentme-edr-402](operations/402-dora-metrics-framework.md) - **DORA metrics framework** - Per-service/team measurement, sub-metric composition, maturity tiers, and adoption order for DORA's four key metrics
+- [agentme-edr-403](operations/403-dora-deployment-frequency.md) - **DORA deployment frequency** - Calculation, examples, and challenges for deploys-per-week, batch size, and automation ratio
+- [agentme-edr-404](operations/404-dora-lead-time-for-changes.md) - **DORA lead time for changes** - Calculation, examples, and challenges for PR cycle time, review latency, deploy-pipeline time, and total lead time
+- [agentme-edr-405](operations/405-dora-change-failure-rate.md) - **DORA change failure rate** - Calculation, examples, and challenges for hotfix/revert rate, incident-linked deploy rate, and escaped defect rate, including cross-team attribution
+- [agentme-edr-406](operations/406-dora-time-to-restore-service.md) - **DORA time to restore service** - Calculation, examples, and challenges for total restore time, detection time, acknowledgement time, and resolution time

package/.xdrs/agentme/edrs/operations/402-dora-metrics-framework.md

@@ -0,0 +1,82 @@
+---
+name: agentme-edr-policy-402-dora-metrics-framework
+description: Defines the framework for measuring DORA's four software delivery metrics per team and service, including sub-metric composition, maturity-tier definition, distribution reporting, adoption order, and daily usage by role. Use when implementing or reviewing DORA metrics measurement, dashboards, or reporting.
+apply-to: Teams and organizations measuring, reporting, or improving software delivery performance using DORA's four key metrics
+valid-from: 2026-09-18
+---
+
+# agentme-edr-policy-402: DORA metrics framework
+
+## Context and Problem Statement
+
+Teams need objective signals of software delivery performance, but without a shared framework, teams measure different things, blend unlike services together, or reduce delivery health to one misleading number. How should DORA's four key metrics be scoped, combined into a maturity signal, and used across teams so results stay comparable, actionable, and resistant to gaming?
+
+## Decision Outcome
+
+**Adopt DORA's four key metrics, each measured per service and rolled up per team, decomposed into incrementally-adoptable sub-metrics defined in one companion policy per metric.**
+
+Every team gets a maturity tier per metric plus one blended tier; company-wide reporting always shows a tier distribution, never a company-wide average.
+
+### Details
+
+#### 01-four-key-metrics
+
+This framework covers DORA's four key metrics: Deployment Frequency ([agentme-edr-403](403-dora-deployment-frequency.md)), Lead Time for Changes ([agentme-edr-404](404-dora-lead-time-for-changes.md)), Change Failure Rate ([agentme-edr-405](405-dora-change-failure-rate.md)), and Time to Restore Service ([agentme-edr-406](406-dora-time-to-restore-service.md); DORA's current term is "Failed Deployment Recovery Time"). Sub-metrics MUST follow a hybrid composition model: Lead Time and Time to Restore sub-metrics are additive and sum to the parent value, while Deployment Frequency and Change Failure Rate sub-metrics are complementary signals that MUST NOT be summed. All time-based sub-metrics MUST use the median (p50) as the headline statistic instead of the mean, to resist outlier skew; percentile bands (p85/p95) MAY be added for distribution visibility.
+
+#### 02-per-service-and-team-accounting
+
+Every metric and sub-metric MUST be measured and reported per team, never only as an org-wide aggregate. The atomic unit of attribution MUST be the deployable service, not the team directly: a team's figures MUST be a rollup of its owned services, per [agentme-bdr-402](../../bdrs/operations/402-digital-product-roles.md)'s `01-product-team-purpose`/`02-product-team-scope-of-work` (a team owns its product's full lifecycle end-to-end). A change touching multiple services MUST be measured independently against each affected service's own timeline; it MUST NOT be flagged as cross-team or assigned to one majority owner.
+
+#### 03-artifact-to-service-mapping
+
+Code-path-based artifacts (pull requests, commits, deploy-workflow runs) MUST be attributed to a service using the repository's CODEOWNERS file, with path patterns defined at service-directory granularity. CODEOWNERS MUST NOT be used for GH Issues, since issues have no file path; issue-based sub-metrics MUST instead use an explicit label or component convention (for example a `service:<name>` label) cross-walked to the owning service.
+
+#### 04-cross-team-incident-attribution
+
+When an incident's root cause is traced to a different team's change, it MUST be counted against the root-cause team's Change Failure Rate ([agentme-edr-405](405-dora-change-failure-rate.md)) and, separately, tagged as a non-tiered visibility signal for the impacted team. It MUST NOT be double-counted into the impacted team's own numerator. Root-cause determination MUST follow [agentme-bdr-405](../../bdrs/operations/405-digital-product-roles-raci.md)'s `04-accountability-network-and-root-cause-tracing` methodology rather than a separate one defined here.
+
+#### 05-maturity-level-definition
+
+Each team MUST be assigned a named maturity tier (Elite, High, Medium, or Low, per DORA's current published bands, cited and dated rather than hardcoded here) for each of the four metrics. Each team MUST also receive one blended maturity label equal to the floor (worst) of its four per-metric tiers. This floor combination is this framework's own practical proxy, since DORA does not publish an official per-team combination formula; it is grounded in DORA's own finding that top performers tend to do well across all metrics. A Low tier on a metric with a genuine regulatory floor MUST NOT be treated as an excuse to stop improving the rest of that metric or any other metric within the team's control.
+
+#### 06-maturity-level-distribution-reporting
+
+Maturity level MUST NOT be averaged across teams into one company-wide figure. Company-wide reporting MUST show the percentage of teams at each blended tier as the headline view, with the four per-metric tier distributions available as a supporting drill-down. Distributions MUST NOT be used to rank or compete teams against each other, and individual team results MUST NOT be reported in a way that isolates one team's metrics from the others' — both patterns are documented by DORA as pitfalls that fuel finger-pointing and gaming.
+
+#### 07-adoption-order
+
+Teams SHOULD adopt the four metrics in this order: Deployment Frequency, then Lead Time for Changes, then Change Failure Rate, then Time to Restore Service. Each step needs one more data source or organizational capability than the last (deploy-workflow history only; then PR data; then a failure-labeling convention; then incident-management timestamps), and DORA's research shows that improving batch size and frequency first cascades into better lead time and stability. Each companion policy defines its own internal sub-metric adoption order using the same ease-plus-impact rationale.
+
+#### 08-daily-usage-by-role
+
+Roles SHOULD consult these metrics at the cadence below when carrying out their accountabilities as defined in [agentme-bdr-402](../../bdrs/operations/402-digital-product-roles.md), [agentme-bdr-404](../../bdrs/operations/404-team-roles-and-specialists.md), and [agentme-bdr-405](../../bdrs/operations/405-digital-product-roles-raci.md):
+
+| Role | Cadence | Usage |
+|---|---|---|
+| Tech Lead / AI Lead | Daily | Primary consumer; accountable for CI/CD pipeline health and incident response; reads review latency ([agentme-edr-404](404-dora-lead-time-for-changes.md) `02`) jointly with Change Failure Rate to catch rubber-stamping |
+| PO | Weekly | Reads Deployment Frequency and Lead Time alongside Change Failure Rate before go-live approvals |
+| EM | Weekly/quarterly | Cross-checks a sustained Low tier against the team's `agentme-bdr-402` `03-workforce-allocation` operations-and-controls capacity |
+| PjM | As-needed | Investigates cross-team blockers when Lead Time or Change Failure Rate issues trace to cross-team dependencies |
+| PM / Leadership | Quarterly | Reads the tier distribution from rule `06`, never a company-wide average |
+
+## Considered Options
+
+* (REJECTED) **Single composite delivery score** — blend all four metrics into one number
+  * Reason: Hides which metric needs attention; contradicts DORA's own guidance against "one metric to rule them all"
+* (REJECTED) **Company-wide averaged maturity score** — one blended number across all teams
+  * Reason: Masks teams that need help; contradicts DORA's guidance against disparate comparisons and siloed competition
+* (REJECTED) **Strict-composition redesign for Deployment Frequency and Change Failure Rate** — force all sub-metrics to sum to the parent value
+  * Reason: Would require dropping batch size (an orthogonal dimension) and escaped-defect-rate (different attribution lag) to force a clean sum
+
+## References
+
+- [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics-four-keys/)
+- [agentme-edr-403](403-dora-deployment-frequency.md) — Deployment Frequency
+- [agentme-edr-404](404-dora-lead-time-for-changes.md) — Lead Time for Changes
+- [agentme-edr-405](405-dora-change-failure-rate.md) — Change Failure Rate
+- [agentme-edr-406](406-dora-time-to-restore-service.md) — Time to Restore Service
+- [agentme-edr-401](401-service-health-check-endpoint.md) — Service health check endpoint
+- [agentme-edr-302](../platform/302-github-pipelines.md) — GitHub CI/CD pipelines
+- [agentme-bdr-402](../../bdrs/operations/402-digital-product-roles.md) — Digital product roles: org & cross-team
+- [agentme-bdr-404](../../bdrs/operations/404-team-roles-and-specialists.md) — Digital product roles: team & specialists
+- [agentme-bdr-405](../../bdrs/operations/405-digital-product-roles-raci.md) — Digital product roles: RACI

package/.xdrs/agentme/edrs/operations/403-dora-deployment-frequency.md

@@ -0,0 +1,37 @@
+---
+name: agentme-edr-policy-403-dora-deployment-frequency
+description: Defines calculation, examples, and challenges for DORA's Deployment Frequency metric and its deploys-per-week, batch-size, and automation-ratio sub-metrics. Use when instrumenting or reviewing deployment frequency measurement.
+apply-to: Teams and organizations measuring, reporting, or improving software delivery performance using DORA's four key metrics
+valid-from: 2026-09-18
+---
+
+# agentme-edr-policy-403: DORA deployment frequency
+
+## Context and Problem Statement
+
+Deployment Frequency is the easiest of DORA's four metrics to start measuring, but teams need a concrete, per-service calculation method rather than just the concept. How should deploys-per-week, batch size, and automation ratio be calculated, and in what order should a team adopt them?
+
+## Decision Outcome
+
+**Measure three complementary, non-summing sub-metrics per deployable service, adopted in order of increasing data-source complexity.**
+
+Each sub-metric MUST be scoped per [agentme-edr-402](402-dora-metrics-framework.md)'s `02-per-service-and-team-accounting` and rolled up per team; none of the three sum to a single formula.
+
+### Details
+
+#### 01-deploys-per-week
+
+Deploys-per-week MUST be calculated by counting successful deploy-workflow runs on the service's default or release branch per week, using CODEOWNERS to attribute each run to its service. Example: a service with 12 successful deploy runs over 4 weeks has a Deployment Frequency of 3/week. Challenges: a change touching multiple services MUST be counted independently against each service's own timeline; the measurement window MUST span the service's own release-train or freeze-window cadence rather than a fixed calendar snapshot; "one deploy event" for canary, staged, or multi-region rollouts MUST be defined consistently per service (for example, pipeline-run start); re-run or retry executions of the same release MUST NOT inflate the count. This is the first sub-metric to adopt: it needs only deploy-workflow history as a single data source, and gives the fastest, most direct throughput signal.
+
+#### 02-batch-size
+
+Batch size MUST be calculated by counting commits or PRs merged between two consecutive deploys of the same service. Example: 8 PRs merged between deploy N and deploy N+1 gives a batch size of 8. Challenges: squash-merge collapses commit history, so the count MUST be based on merged PRs rather than raw commits. Teams SHOULD adopt this second: it needs no data source beyond `01`'s deploy history, and is a leading indicator for both Lead Time and Change Failure Rate risk (see [agentme-edr-402](402-dora-metrics-framework.md)'s `07-adoption-order`).
+
+#### 03-automation-ratio
+
+Automation ratio MUST be calculated by dividing automated deploy-workflow runs (triggered by merge, tag, or schedule) by all deploy-workflow runs for the service. Example: 18 automated of 20 total runs gives a 90% automation ratio. Challenges: a mandatory regulatory or manual QA approval gate MUST NOT be conflated with an ad-hoc manual deploy; only the latter counts against automation ratio. Teams SHOULD adopt this third, since it requires classifying trigger type per run and is most useful once volume and batch size are already understood.
+
+## References
+
+- [agentme-edr-402](402-dora-metrics-framework.md) — DORA metrics framework
+- [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics-four-keys/)

package/.xdrs/agentme/edrs/operations/404-dora-lead-time-for-changes.md

@@ -0,0 +1,41 @@
+---
+name: agentme-edr-policy-404-dora-lead-time-for-changes
+description: Defines calculation, examples, and challenges for DORA's Lead Time for Changes metric and its PR-cycle-time, review-latency, deploy-pipeline-time, and total-lead-time sub-metrics. Use when instrumenting or reviewing lead time measurement.
+apply-to: Teams and organizations measuring, reporting, or improving software delivery performance using DORA's four key metrics
+valid-from: 2026-09-18
+---
+
+# agentme-edr-policy-404: DORA lead time for changes
+
+## Context and Problem Statement
+
+Lead Time for Changes is often reduced to one number that hides whether delay lives in review or in deployment. How should its phases be calculated so a team can see where time is actually spent, and how do the phases combine into a total?
+
+## Decision Outcome
+
+**Measure four additive sub-metrics per deployable service that sum to a total lead time, using the median (p50) as the headline statistic.**
+
+Review latency is a phase inside PR cycle time; PR cycle time plus deploy-pipeline time MUST equal total lead time.
+
+### Details
+
+#### 01-pr-cycle-time
+
+PR cycle time MUST be measured from a PR's first commit to its `merged_at` timestamp. Example: first commit at day 0, merged at day 2 gives a 2-day PR cycle time. Challenges: squash-merge loses the first-commit timestamp, so the PR's `created_at` SHOULD be used as a proxy; stacked PRs and long-lived branches with rebases distort the start time. Teams SHOULD adopt this first, since it uses a single data source (GitHub PRs) and is usually the dominant contributor to total lead time.
+
+#### 02-review-latency
+
+Review latency MUST be measured from a PR's `created_at` to its first review `submitted_at`, as a drill-down inside `01`. Example: PR opened at hour 0, first review at hour 20, gives 20 hours of review latency. Challenges: this is the sub-metric most at risk of being gamed by rubber-stamping; an unusually fast review latency MUST be read jointly with [agentme-edr-405](405-dora-change-failure-rate.md)'s Change Failure Rate rather than treated as a win on its own. Teams SHOULD adopt this second: it reuses `01`'s data source with one extra timestamp, and is usually the most common, most actionable bottleneck.
+
+#### 03-deploy-pipeline-time
+
+Deploy-pipeline time MUST be measured from merge to deploy completion for the affected service, covering any merge-to-deploy gate whether automated or manual (including mandatory regulatory or QA approval gates). Example: merged at hour 0, service deployed at hour 6, gives 6 hours of deploy-pipeline time. Challenges: a PR shipping to multiple services MUST have this computed once per affected service, since deploy timing differs by service; flaky CI re-runs inflate the measurement. Teams SHOULD adopt this third: it requires a second data source (deploy-workflow runs) correlated with PR data, and isolates exactly how much delay sits outside the team's own review process.
+
+#### 04-total-lead-time
+
+Total lead time MUST equal `01` plus `03` (with `02` already counted inside `01`), computed once per PR-and-affected-service pair and rolled up per team. Example: 2-day PR cycle time plus 6-hour deploy-pipeline time gives a total of roughly 2.25 days. Challenges: a handful of extreme outliers can skew a mean, which is why the median MUST be the headline statistic. Teams SHOULD adopt this last: it requires correlating both data sources together, the hardest sub-metric to compute reliably, but it is the single clearest measure of overall delivery speed.
+
+## References
+
+- [agentme-edr-402](402-dora-metrics-framework.md) — DORA metrics framework
+- [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics-four-keys/)