agentme 0.7.3 → 0.7.4

package/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md

@@ -13,7 +13,7 @@ What tooling and project structure should JavaScript/TypeScript projects follow
 
 ## Decision Outcome
 
-**Use a Mise-managed Node.js and pnpm toolchain together with pnpm, tsc, esbuild, eslint, and jest in a module-root layout that follows [agentme-edr-016](../principles/016-cross-language-module-structure.md), with runnable usage examples in sibling `examples/` folders and Makefiles as the only entry points.**
+**Use a Mise-managed Node.js and pnpm toolchain together with pnpm, tsc, esbuild, eslint, and jest in a module-root layout that follows [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md), with runnable usage examples in sibling `examples/` folders and Makefiles as the only entry points.**
 
 Clear, consistent tooling and layout enable fast onboarding, reliable CI pipelines, and a predictable developer experience across projects.
 
@@ -30,7 +30,7 @@ Clear, consistent tooling and layout enable fast onboarding, reliable CI pipelin
 | **eslint** | Linting — code style and quality enforcement |
 | **jest** | Testing — unit and integration test runner |
 
-All commands are run exclusively through Makefiles, not through `package.json` scripts. The repository root MUST define a `.mise.toml` that pins at least Node.js and pnpm. Contributors and CI MUST bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe MUST execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-017](../devops/017-tool-execution-and-scripting.md). Calling project tools directly in docs, CI, or daily workflows instead of `make <target>` is not allowed.
+All commands are run exclusively through Makefiles, not through `package.json` scripts. The repository root MUST define a `.mise.toml` that pins at least Node.js and pnpm. Contributors and CI MUST bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe MUST execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-017](/.xdrs/agentme/edrs/devops/017-tool-execution-and-scripting.md). Calling project tools directly in docs, CI, or daily workflows instead of `make <target>` is not allowed.
 
 #### ESLint
 
@@ -116,7 +116,7 @@ Benchmarks belong in `lib/tests_benchmark/` when they require dedicated harnesse
 
 The examples folder MUST exist for any libraries and utilities that are published or have more than 500 lines of code
 
-### Related Skills
+## References
 
 - [001-create-javascript-project](skills/001-create-javascript-project/SKILL.md) — scaffolds a new project following this structure
 

package/.xdrs/agentme/edrs/application/010-golang-project-tooling.md

@@ -13,7 +13,7 @@ What tooling and project structure should Go projects follow to ensure consisten
 
 ## Decision Outcome
 
-**Use a Mise-managed Go toolchain with `go build`, `go test`, and `golangci-lint`, module-root folder responsibilities from [agentme-edr-016](../principles/016-cross-language-module-structure.md), feature packages in subdirectories, a `cli/` package for command wiring, and a Makefile as the single entry point for all development tasks.**
+**Use a Mise-managed Go toolchain with `go build`, `go test`, and `golangci-lint`, module-root folder responsibilities from [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md), feature packages in subdirectories, a `cli/` package for command wiring, and a Makefile as the single entry point for all development tasks.**
 
 A predictable layout and minimal external tooling keep Go projects approachable, fast to build, and easy to distribute as cross-platform binaries.
 
@@ -28,7 +28,7 @@ A predictable layout and minimal external tooling keep Go projects approachable,
 | **golangci-lint** | Linting — aggregates many linters in one fast run; configured via `.golangci.yml` |
 | **monotag** | Version tagging from git history for the `publish` target |
 
-All commands are run exclusively through the Makefile, never ad-hoc. The project root **MUST** define a `.mise.toml` that pins `go`, `golangci-lint`, and any other Go-related CLIs used by the project. Contributors and CI **MUST** bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe **MUST** execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-017](../devops/017-tool-execution-and-scripting.md).
+All commands are run exclusively through the Makefile, never ad-hoc. The project root **MUST** define a `.mise.toml` that pins `go`, `golangci-lint`, and any other Go-related CLIs used by the project. Contributors and CI **MUST** bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe **MUST** execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-017](/.xdrs/agentme/edrs/devops/017-tool-execution-and-scripting.md).
 Direct installation of project-required Go CLIs with `go install ...@latest` as a repair step is **NOT** allowed unless an XDR for that repository explicitly permits it.
 
 #### Project structure
@@ -151,6 +151,6 @@ Use `github.com/sirupsen/logrus` for structured logging. Set the log level from
 
 Use the standard library `flag` package for CLI flags. Each `cli/<feature>` package defines its own `FlagSet`, parses it from `os.Args[2:]`, and calls the corresponding domain function.
 
-### Related Skills
+## References
 
 - [003-create-golang-project](skills/003-create-golang-project/SKILL.md) — scaffolds a new Go project following this structure

package/.xdrs/agentme/edrs/application/014-python-project-tooling.md

@@ -13,7 +13,7 @@ What tooling and project structure should Python projects follow to ensure consi
 
 ## Decision Outcome
 
-**Use a Mise-managed Python and uv toolchain with `pyproject.toml`, `ruff`, `pyright`, `pytest`, `pytest-cov`, `pip-audit`, and a layout that follows [agentme-edr-016](../principles/016-cross-language-module-structure.md): a module root under `lib/`, runnable consumer examples in sibling `examples/`, and standardized `dist/` and `.cache/` locations.**
+**Use a Mise-managed Python and uv toolchain with `pyproject.toml`, `ruff`, `pyright`, `pytest`, `pytest-cov`, `pip-audit`, and a layout that follows [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md): a module root under `lib/`, runnable consumer examples in sibling `examples/`, and standardized `dist/` and `.cache/` locations.**
 
 A single dependency manager, isolated package internals under `lib/`, and a standard Makefile contract keep Python projects predictable for contributors and CI while keeping the repository root clean.
 
@@ -34,7 +34,7 @@ A single dependency manager, isolated package internals under `lib/`, and a stan
 
 All routine commands must run through the project `Makefile`, never by calling `uv`, `ruff`, `pytest`, or `pyright` directly in docs, CI, or daily development workflows.
 
-The repository root MUST define a `.mise.toml` that pins Python and uv. Contributors and CI MUST bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe MUST execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-017](../devops/017-tool-execution-and-scripting.md). Using routine project CLI commands directly outside the Makefile contract is not allowed.
+The repository root MUST define a `.mise.toml` that pins Python and uv. Contributors and CI MUST bootstrap with `make setup` or `mise install`, then invoke routine work with `make <target>`. Each Makefile recipe MUST execute the underlying tool through `mise exec -- <tool> ...`, following [agentme-edr-017](/.xdrs/agentme/edrs/devops/017-tool-execution-and-scripting.md). Using routine project CLI commands directly outside the Makefile contract is not allowed.
 
 The root `.venv/` is the canonical environment location for both the library and all examples. Subdirectory commands must set `UV_PROJECT_ENVIRONMENT` to the workspace root `.venv/` instead of creating nested virtual environments.
 
@@ -80,7 +80,7 @@ Keep the repository root clean: source code, tests, distribution artifacts, and
 
 Use the `lib/src/` layout for import safety and packaging clarity. Keep tests under `lib/tests/` and shared test setup in `lib/tests/conftest.py`. Do not introduce `requirements.txt`, `setup.py`, `setup.cfg`, `tox.ini`, `ruff.toml`, or `pyrightconfig.json` by default; keep project metadata and tool configuration in `lib/pyproject.toml`.
 
-Libraries and shared utilities must include an `examples/` folder and wire example execution into the root `test` flow, following [agentme-edr-007](../principles/007-project-quality-standards.md). Each example directory is its own Python project with its own `pyproject.toml`, and examples must import the library as a consumer would rather than reaching back into `lib/src/` with relative imports. Local example verification must install the wheel built into `lib/dist/`; do not use editable or path-based dependencies back to `lib/`.
+Libraries and shared utilities must include an `examples/` folder and wire example execution into the root `test` flow, following [agentme-edr-007](/.xdrs/agentme/edrs/principles/007-project-quality-standards.md). Each example directory is its own Python project with its own `pyproject.toml`, and examples must import the library as a consumer would rather than reaching back into `lib/src/` with relative imports. Local example verification must install the wheel built into `lib/dist/`; do not use editable or path-based dependencies back to `lib/`.
 
 Python keeps unit tests under `lib/tests/` by default because that remains the more common and maintainable convention for typed/package-based projects than co-locating tests beside every source file. Integration tests belong in `lib/tests_integration/`, and benchmark harnesses belong in `lib/tests_benchmark/` when they are more than a single micro-benchmark helper.
 
@@ -98,7 +98,7 @@ Ruff is the default formatter and linter. Do not add Black, isort, or Flake8 unl
 
 Pyright must run on every lint pass. `typeCheckingMode = "standard"` is the minimum baseline; projects may raise this to `strict` when the codebase is ready.
 
-Pytest coverage must fail below 80% line and branch coverage, following [agentme-edr-004](../principles/004-unit-test-requirements.md).
+Pytest coverage must fail below 80% line and branch coverage, following [agentme-edr-004](/.xdrs/agentme/edrs/principles/004-unit-test-requirements.md).
 
 #### Makefile targets
 
@@ -137,7 +137,7 @@ The root `Makefile` is the only contract for CI and contributors. It delegates l
 | `dev` | Same as `run`, optionally with repository-specific dev defaults |
 | `publish` | `mise exec -- uv publish --project .` after versioning and packaging are complete |
 
-The root `Makefile` must remain the only contract for CI and contributors, in line with [agentme-edr-008](../devops/008-common-targets.md).
+The root `Makefile` must remain the only contract for CI and contributors, in line with [agentme-edr-008](/.xdrs/agentme/edrs/devops/008-common-targets.md).
 
 ## Considered Options
 
@@ -148,7 +148,7 @@ The root `Makefile` must remain the only contract for CI and contributors, in li
 
 ## References
 
-- [agentme-edr-004](../principles/004-unit-test-requirements.md) - Coverage and unit-test baseline
-- [agentme-edr-007](../principles/007-project-quality-standards.md) - Examples and quality requirements
-- [agentme-edr-008](../devops/008-common-targets.md) - Standard Makefile target names
+- [agentme-edr-004](/.xdrs/agentme/edrs/principles/004-unit-test-requirements.md) - Coverage and unit-test baseline
+- [agentme-edr-007](/.xdrs/agentme/edrs/principles/007-project-quality-standards.md) - Examples and quality requirements
+- [agentme-edr-008](/.xdrs/agentme/edrs/devops/008-common-targets.md) - Standard Makefile target names
 - [005-create-python-project](skills/005-create-python-project/SKILL.md) - Scaffold a project following this EDR

package/.xdrs/agentme/edrs/application/015-cli-tool-standards.md

@@ -99,9 +99,9 @@ This keeps the user-facing command predictable while preserving a clean library
 ## References
 
 - [agentme-edr-003](003-javascript-project-tooling.md) - JavaScript project packaging and structure
-- [agentme-edr-007](../principles/007-project-quality-standards.md) - README and examples baseline
-- [agentme-edr-008](../devops/008-common-targets.md) - Standard command names for project entry points
-- [agentme-edr-009](../principles/009-error-handling.md) - Process error signaling and error handling expectations
+- [agentme-edr-007](/.xdrs/agentme/edrs/principles/007-project-quality-standards.md) - README and examples baseline
+- [agentme-edr-008](/.xdrs/agentme/edrs/devops/008-common-targets.md) - Standard command names for project entry points
+- [agentme-edr-009](/.xdrs/agentme/edrs/principles/009-error-handling.md) - Process error signaling and error handling expectations
 - [agentme-edr-010](010-golang-project-tooling.md) - Go CLI structure and verbose logging baseline
 - [agentme-edr-014](014-python-project-tooling.md) - Python packaging and CLI entry-point guidance
 - [cosmiconfig](https://github.com/cosmiconfig/cosmiconfig) - Example JSON configuration discovery library for JavaScript CLIs

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

@@ -19,7 +19,7 @@ the sibling `examples/` folder, redirects persistent caches into `.cache/`, and
 the only entry points. Boilerplate is derived from the [filedist](https://github.com/flaviostutz/filedist)
 project.
 
-Related EDRs: [agentme-edr-003](../../003-javascript-project-tooling.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
+Related EDRs: [agentme-edr-003](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md), [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md)
 
 ## Instructions
 
@@ -418,7 +418,7 @@ Review all created files and confirm:
 - [ ] `lib/eslint.config.mjs` points `parserOptions.project` to `tsconfig.json`
 - [ ] `lib/README.md` starts with Quick Start and ends with module development commands
 - [ ] All `[package-name]` placeholders are replaced with the actual name
-- [ ] Structure matches the layout in [agentme-edr-003](../../003-javascript-project-tooling.md)
+- [ ] Structure matches the layout in [agentme-edr-003](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md)
 
 ## Examples
 

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

@@ -12,9 +12,9 @@ compatibility: Go 1.21+
 
 ## Overview
 
-Creates a complete Go CLI project from scratch, following the layout from [agentme-edr-010](../../010-golang-project-tooling.md). Business logic lives in named feature packages; CLI wiring lives in `cli/<feature>/`; `main.go` is a thin dispatcher. The module root owns its `Makefile`, `README.md`, `dist/`, and `.cache/` folders.
+Creates a complete Go CLI project from scratch, following the layout from [agentme-edr-010](/.xdrs/agentme/edrs/application/010-golang-project-tooling.md). Business logic lives in named feature packages; CLI wiring lives in `cli/<feature>/`; `main.go` is a thin dispatcher. The module root owns its `Makefile`, `README.md`, `dist/`, and `.cache/` folders.
 
-Related EDRs: [agentme-edr-010](../../010-golang-project-tooling.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
+Related EDRs: [agentme-edr-010](/.xdrs/agentme/edrs/application/010-golang-project-tooling.md), [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md)
 
 ## Instructions
 

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

@@ -159,9 +159,9 @@ Input: "Set up agentme for this repo and keep the speckit workflow we already us
 
 ## References
 
-- [agentme README](../../../../../../README.md)
-- [agentme-edr-003 - JavaScript project tooling and structure](../../003-javascript-project-tooling.md)
-- [agentme-edr-005 - Monorepo structure](../../../devops/005-monorepo-structure.md)
-- [agentme-edr-007 - Project quality standards](../../../principles/007-project-quality-standards.md)
-- [agentme-edr-008 - Common development script names](../../../devops/008-common-targets.md)
-- [_core-adr-003 - Skill standards](../../../../../_core/adrs/principles/003-skill-standards.md)
+- [agentme README](/README.md)
+- [agentme-edr-003 - JavaScript project tooling and structure](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md)
+- [agentme-edr-005 - Monorepo structure](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md)
+- [agentme-edr-007 - Project quality standards](/.xdrs/agentme/edrs/principles/007-project-quality-standards.md)
+- [agentme-edr-008 - Common development script names](/.xdrs/agentme/edrs/devops/008-common-targets.md)
+- [_core-adr-003 - Skill standards](/.xdrs/_core/adrs/principles/003-skill-standards.md)

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

@@ -18,7 +18,7 @@ Pyright, Pytest, and Makefiles. The default layout keeps the library self-contai
 uses a shared root `.venv/`, redirects persistent caches into `.cache/`, and places runnable
 consumer projects under the sibling `examples/` folder.
 
-Related EDRs: [agentme-edr-014](../../014-python-project-tooling.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
+Related EDRs: [agentme-edr-014](/.xdrs/agentme/edrs/application/014-python-project-tooling.md), [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md)
 
 ## Instructions
 
@@ -375,5 +375,5 @@ After creating the files:
 
 ## References
 
-- [agentme-edr-014](../../014-python-project-tooling.md)
-- [_core-adr-003 - Skill standards](../../../../../_core/adrs/principles/003-skill-standards.md)
+- [agentme-edr-014](/.xdrs/agentme/edrs/application/014-python-project-tooling.md)
+- [_core-adr-003 - Skill standards](/.xdrs/_core/adrs/principles/003-skill-standards.md)

package/.xdrs/agentme/edrs/devops/005-monorepo-structure.md

@@ -16,11 +16,11 @@ What monorepo structure, naming conventions, tooling, and build standards should
 **Adopt a standardized monorepo layout with top-level application folders that aggregate independent module roots, shared parent-level example and test areas, Mise-managed tooling, and Makefiles at every level.**
 
 For step-by-step scaffolding instructions see [skill 002-monorepo-setup](skills/002-monorepo-setup/SKILL.md).
-Module folder responsibilities, artifact locations, and test-folder conventions follow [agentme-edr-016](../principles/016-cross-language-module-structure.md).
+Module folder responsibilities, artifact locations, and test-folder conventions follow [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md).
 
-### Policies
+### Implementation Details
 
-#### 1. Top-level directory layout
+#### 01-top-level-directory-layout
 
 ```
 /
@@ -48,7 +48,7 @@ Module folder responsibilities, artifact locations, and test-folder conventions
 └── .mise.toml            # Mise tool version configuration
 ```
 
-#### 2. Application folders
+#### 02-application-folders
 
 - Represent a cohesive unit with its own lifecycle (e.g., `mymobileapp`, `graph-visualizer`).
 - **MUST** depend only on resources in `/shared/`. Direct cross-application dependencies are forbidden; use published artifacts (container images, published libraries) instead.
@@ -57,22 +57,22 @@ Module folder responsibilities, artifact locations, and test-folder conventions
 
 *Why:* Isolating applications prevents implicit coupling and makes the `shared/` boundary explicit and intentional.
 
-#### 3. Module folders
+#### 03-module-folders
 
 - A module is a subfolder inside an application that is independently compilable and produces a build artifact.
 - May depend on sibling modules within the same application or on `/shared/` resources.
 - **MUST NOT** depend on modules from other applications.
 - **MUST** contain its own `Makefile`, `README.md`, and language/tooling configuration.
-- **MUST** keep build outputs under `dist/` and persistent caches under `.cache/`, following [agentme-edr-016](../principles/016-cross-language-module-structure.md).
+- **MUST** keep build outputs under `dist/` and persistent caches under `.cache/`, following [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md).
 - **MUST NOT** keep consumer examples inside the module folder; those belong in a sibling `examples/` folder at the nearest parent aggregation root.
 
-#### 4. Naming conventions
+#### 04-naming-conventions
 
 - All folder and file names **MUST** be **lowercase**.
 - Use hyphens (`-`) to separate words (e.g., `data-loader`, `graph-visualizer`).
 - Avoid abbreviations unless universally understood in the domain (e.g., `cli`, `api`).
 
-#### 5. Makefiles at every level
+#### 05-makefiles-at-every-level
 
 A `Makefile` **MUST** be present at the repository root, in every application folder, and in every module folder.
 
@@ -87,7 +87,7 @@ The root `setup` target **MUST** run `mise install` and any small repository boo
 
 *Why:* Makefiles provide a universal, stack-agnostic entry point regardless of programming language.
 
-#### 6. Mise for tooling management
+#### 06-mise-for-tooling-management
 
 - [Mise](https://mise.jdx.dev/) **MUST** be used to pin all tool versions (compilers, runtimes, CLI tools).
 - A `.mise.toml` **MUST** exist at the repository root.
@@ -100,15 +100,15 @@ The root `setup` target **MUST** run `mise install` and any small repository boo
 
 *Why:* Eliminates "works on my machine" build failures by ensuring identical tool versions across all environments.
 
-#### 7. Root README
+#### 07-root-readme
 
 The root `README.md` **MUST** include: overview, machine setup, quickstart, and a repository map.
 
-#### 8. Root `.gitignore`
+#### 08-root-gitignore
 
 The repository root **MUST** ignore `dist/` and `.cache/` so module artifacts and tool caches are never committed accidentally.
 
-#### 9. Git tagging and artifact versioning
+#### 09-git-tagging-and-artifact-versioning
 
 All releases **MUST** be tagged using the format `<module-name>/<semver>` (e.g., `graphvisualizer/renderer/1.0.0`, `shared/libs/mylib/2.1.0`).
 
@@ -118,7 +118,7 @@ All releases **MUST** be tagged using the format `<module-name>/<semver>` (e.g.,
 
 ---
 
-#### 11. Summary of requirements
+#### 11-summary-of-requirements
 
 | Requirement | Scope | Mandatory |
 |---|---|---|

package/.xdrs/agentme/edrs/devops/006-github-pipelines.md

@@ -31,7 +31,9 @@ All workflows run on `ubuntu-latest`. Tool versions MUST be managed by Mise via
 
 ---
 
-#### 1. CI workflow — `.github/workflows/ci.yml`
+#### 01-ci-workflow
+
+File: `.github/workflows/ci.yml`
 
 Triggered on every PR targeting `main` and every push to `main`. Runs the standard `build`, `lint`, and `test` targets from the root Makefile and fails the workflow if any step exits non-zero.
 
@@ -59,7 +61,9 @@ jobs:
 
 ---
 
-#### 2. Release workflow — `.github/workflows/release.yml`
+#### 02-release-workflow
+
+File: `.github/workflows/release.yml`
 
 Manually dispatched (`workflow_dispatch`). Calculates the next semantic version tag using **monotag** and pushes that tag to the repository. Pushing the tag then automatically triggers the publish workflow.
 
@@ -102,7 +106,9 @@ jobs:
 
 ---
 
-#### 3. Publish workflow — `.github/workflows/publish.yml`
+#### 03-publish-workflow
+
+File: `.github/workflows/publish.yml`
 
 Triggered exclusively when a tag matching `v*.*.*` is pushed to the repository. This ensures only explicitly tagged commits produce published artifacts. Runs `make publish` against the tagged commit.
 
@@ -134,7 +140,7 @@ jobs:
 
 *Why rebuild on publish:* The checkout is done from the exact tag commit. Rebuilding ensures the published artifact matches exactly what is tagged, rather than relying on a prior CI artifact.
 
-*Why `id-token: write`:* Required for npm provenance attestation via `npm publish --provenance`, as specified in [agentme-edr-003](../application/003-javascript-project-tooling.md).
+*Why `id-token: write`:* Required for npm provenance attestation via `npm publish --provenance`, as specified in [agentme-edr-003](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md).
 
 ---
 

package/.xdrs/agentme/edrs/devops/008-common-targets.md

@@ -19,7 +19,7 @@ Standardizing both the target names and the execution chain removes per-project
 
 ### Implementation Details
 
-#### 1. Every project MUST have a root `Makefile` exposing the standard target names
+#### 01-every-project-must-have-root-makefile
 
 The project root must contain a single authoritative `Makefile` that exposes the standard target names defined in rule 3. Developers and CI pipelines must invoke routine actions through this `Makefile`, never by calling underlying tools directly in documentation, CI, or daily workflow commands.
 
@@ -34,7 +34,7 @@ The project root must contain a single authoritative `Makefile` that exposes the
 
 *Why:* The project entry point must stay language-agnostic and obvious. A developer should be able to inspect the `Makefile` and immediately see which real tool commands will run.
 
-#### 2. Makefile recipes MUST use the shared Mise execution rules
+#### 02-makefile-recipes-must-use-mise
 
 After a checkout, the shared execution flow is:
 
@@ -62,7 +62,7 @@ make <target>
 
 ---
 
-#### 3. Standard target groups and names
+#### 03-standard-target-groups-and-names
 
 Targets are organized into five lifecycle groups. Projects must use these names unchanged. Extensions are allowed (see rule 5) but the core names must not be repurposed.
 
@@ -114,7 +114,7 @@ Targets are organized into five lifecycle groups. Projects must use these names
 
 ---
 
-#### 3. Standard environment variables
+#### 04-standard-environment-variables
 
 Two environment variables have defined semantics and must be used consistently.
 
@@ -125,7 +125,7 @@ Two environment variables have defined semantics and must be used consistently.
 
 ---
 
-#### 5. Extending targets with prefixes
+#### 05-extending-targets-with-prefixes
 
 Projects may add custom targets beyond the standard set. Custom targets must be named by prefixing a standard target name with a descriptive qualifier, keeping the naming intuitive and consistent with the group it belongs to.
 
@@ -147,7 +147,7 @@ The prefix convention ensures developers can infer the purpose of any target wit
 
 ---
 
-#### 6. Monorepo usage
+#### 06-monorepo-usage
 
 In a monorepo, each module has its own `Makefile` with its own `build`, `lint`, `test`, and `deploy` targets scoped to that module. Parent-level Makefiles (at the application or repo root) delegate to child Makefiles in sequence. The parent Makefile should call `$(MAKE) -C <child> <target>` directly, while each child `Makefile` runs its actual tool commands through `mise exec --`.
 
@@ -168,7 +168,7 @@ A developer can run `make test` at the repo root to test everything, or `cd modu
 
 ---
 
-#### 7. Quick-reference — commands a developer can always rely on
+#### 07-quick-reference
 
 Any project following this EDR supports the following actions through the root `Makefile`.
 

package/.xdrs/agentme/edrs/devops/017-tool-execution-and-scripting.md

@@ -59,6 +59,6 @@ Disallowed:
 - [agentme-edr-005](005-monorepo-structure.md) - Monorepo layout and Makefile hierarchy
 - [agentme-edr-006](006-github-pipelines.md) - CI/CD workflows should call Make targets
 - [agentme-edr-008](008-common-targets.md) - Standard target names
-- [agentme-edr-003](../application/003-javascript-project-tooling.md) - JavaScript tooling commands inside Makefiles
-- [agentme-edr-010](../application/010-golang-project-tooling.md) - Go tooling commands inside Makefiles
-- [agentme-edr-014](../application/014-python-project-tooling.md) - Python tooling commands inside Makefiles
+- [agentme-edr-003](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md) - JavaScript tooling commands inside Makefiles
+- [agentme-edr-010](/.xdrs/agentme/edrs/application/010-golang-project-tooling.md) - Go tooling commands inside Makefiles
+- [agentme-edr-014](/.xdrs/agentme/edrs/application/014-python-project-tooling.md) - Python tooling commands inside Makefiles

package/.xdrs/agentme/edrs/devops/skills/002-monorepo-setup/SKILL.md

@@ -13,12 +13,12 @@ metadata:
 
 ## Overview
 
-Creates or extends a monorepo that follows the standard layout from [agentme-edr-005](../../005-monorepo-structure.md):
+Creates or extends a monorepo that follows the standard layout from [agentme-edr-005](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md):
 top-level application folders, independent module roots, sibling example and multi-module test
 areas, Mise-managed tooling, and Makefiles at every level so any contributor can build, lint, and
 test any part of the monorepo with a single, predictable command.
 
-Related EDRs: [agentme-edr-005](../../005-monorepo-structure.md), [agentme-edr-013](../../../governance/013-contributing-guide-requirements.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
+Related EDRs: [agentme-edr-005](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md), [agentme-edr-013](/.xdrs/agentme/edrs/governance/013-contributing-guide-requirements.md), [agentme-edr-016](/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md)
 
 ## Instructions
 

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

@@ -38,5 +38,5 @@ Projects must keep a `CONTRIBUTING.md` file at the repository root. The file mus
 
 ## References
 
-- [agentme-edr-005 - Monorepo structure](../devops/005-monorepo-structure.md)
-- [002-monorepo-setup skill](../devops/skills/002-monorepo-setup/SKILL.md)
+- [agentme-edr-005 - Monorepo structure](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md)
+- [002-monorepo-setup skill](/.xdrs/agentme/edrs/devops/skills/002-monorepo-setup/SKILL.md)

package/.xdrs/agentme/edrs/principles/002-coding-best-practices.md

@@ -17,7 +17,7 @@ What coding practices should be followed across all languages and projects to ke
 
 ### Implementation Details
 
-#### 1. Keep files short — split at 400 lines
+#### 01-keep-files-short
 
 A file must not exceed **400 lines**. When a file grows beyond this limit, split related functions or types into separate, focused modules.
 
@@ -44,7 +44,7 @@ src/
 
 ---
 
-#### 2. Apply the Template Method pattern for large multi-section functions
+#### 02-apply-template-method-pattern
 
 When a function's main logic contains well-defined sections and **any individual section exceeds ~20 lines**, extract each section into its own named function. The outer function becomes an orchestrator that calls the extracted helpers in sequence.
 
@@ -81,7 +81,7 @@ def _persist_order(order, total): ...
 
 ---
 
-#### 3. Keep README, tests, and examples in sync with implementation
+#### 03-keep-readme-tests-and-examples-in-sync
 
 Every change to a public interface, behavior, or configuration option must be reflected in:
 
@@ -93,7 +93,7 @@ Every change to a public interface, behavior, or configuration option must be re
 
 ---
 
-#### 4. Declare types in the file where they are used — unless shared
+#### 04-declare-types-in-file-where-used
 
 If a type (struct, interface, class, typedef, etc.) is used in only **one** file, declare it in that same file. Move a type to a shared module only when it is referenced in two or more files.
 
@@ -101,7 +101,7 @@ If a type (struct, interface, class, typedef, etc.) is used in only **one** file
 
 ---
 
-#### 5. Keep test files next to the files they test
+#### 05-keep-test-files-next-to-source
 
 Where the language ecosystem supports it (e.g. JavaScript/TypeScript, Go, Rust), place test files **beside** the source file they cover and use a consistent naming convention rather than mirroring the source tree in a separate `tests/` folder.
 

package/.xdrs/agentme/edrs/principles/004-unit-test-requirements.md

@@ -17,7 +17,7 @@ What unit testing practices should be followed to ensure tests are meaningful, r
 
 ### Implementation Details
 
-#### 1. MUST have at least one assertion per test
+#### 01-must-have-at-least-one-assertion-per-test
 
 ```typescript
 // bad — no assertion; passes even when code is broken
@@ -32,7 +32,7 @@ it("processes the order and returns a confirmation id", () => {
 
 ---
 
-#### 2. MUST run offline — no external resource dependencies
+#### 02-must-run-offline
 
 Unit tests must not depend on any external resources: no network calls, no running databases, no external APIs, no file system paths outside the repo. Tests must pass with only static code available.
 
@@ -53,7 +53,7 @@ it("fetches user", async () => {
 
 ---
 
-#### 3. MUST maintain at least 80% line/branch coverage, enforced in CI
+#### 03-must-maintain-80-percent-coverage
 
 ```typescript
 // vitest.config.ts
@@ -66,7 +66,7 @@ Builds that miss the threshold must not be merged.
 
 ---
 
-#### 4. SHOULD extract shared setup into a test utility module
+#### 04-should-extract-shared-setup
 
 When setup logic is repeated across two or more test files, centralize it (`src/test-utils/`, `internal/testutil/`, `tests/conftest.py`).
 
@@ -79,7 +79,7 @@ export function makeOrder(overrides: Partial<Order> = {}): Order {
 
 ---
 
-#### 5. SHOULD avoid mocks — prefer real code execution
+#### 05-should-avoid-mocks
 
 Use the lowest-cost alternative that exercises real behavior:
 

package/.xdrs/agentme/edrs/principles/007-project-quality-standards.md

@@ -17,9 +17,9 @@ Every project must meet six minimum quality standards: a Getting Started section
 
 These standards form a non-negotiable baseline. Individual projects may raise the bar but must never fall below it.
 
----
+### Implementation Details
 
-### 1. README MUST have a Getting Started section
+#### 01-readme-must-have-getting-started
 
 `README.md` must include a **Getting Started** section in the first 20 lines with the minimal steps to install and use the project.
 
@@ -48,7 +48,7 @@ myFunction({ input: "value" });
 
 ---
 
-### 2. Unit tests MUST run on every release
+#### 02-unit-tests-must-run-on-every-release
 
 A unit test suite must run automatically before every release. Failing tests must block the release — no silent skips or overrides.
 
@@ -63,9 +63,9 @@ A unit test suite must run automatically before every release. Failing tests mus
 
 ---
 
-### 3. The project MUST comply with all applicable workspace XDRs
+#### 03-project-must-comply-with-xdrs
 
-All XDRs that apply to the project's scope (as listed in [.xdrs/index.md](../../../index.md)) must be followed. A deviation requires a project-local XDR documenting the override.
+All XDRs that apply to the project's scope (as listed in [.xdrs/index.md](/.xdrs/index.md)) must be followed. A deviation requires a project-local XDR documenting the override.
 
 **Requirements:**
 - Review applicable XDRs before any significant implementation
@@ -73,7 +73,7 @@ All XDRs that apply to the project's scope (as listed in [.xdrs/index.md](../../
 
 ---
 
-### 4. The project MUST have linting enforcing code style, formatting, and best practices
+#### 04-project-must-have-linting
 
 Projects larger than 10 files or 200 lines of code must have a linter configured and actively enforced. Lint failures block CI builds.
 
@@ -85,11 +85,11 @@ Projects larger than 10 files or 200 lines of code must have a linter configured
 
 **Exception:** Projects with fewer than 100 lines of code, or whose `README.md` prominently marks them as a **Spike** or **Experiment**, are exempt from this requirement. Such projects must never be deployed to production.
 
-**Reference:** [agentme-edr-003](../application/003-javascript-project-tooling.md) for JavaScript-specific tooling.
+**Reference:** [agentme-edr-003](/.xdrs/agentme/edrs/application/003-javascript-project-tooling.md) for JavaScript-specific tooling.
 
 ---
 
-### 5. The project structure MUST be easily understood by new developers
+#### 05-project-structure-must-be-clear
 
 Directory and file layout must be self-explanatory: source code, tests, configuration, and examples must be clearly separated and named.
 
@@ -114,7 +114,7 @@ Directory and file layout must be self-explanatory: source code, tests, configur
 
 ---
 
-### 6. Libraries and utilities MUST have a runnable examples folder verified on every test run
+#### 06-libraries-must-have-runnable-examples
 
 Projects that are libraries or shared utilities must include an `examples/` directory. Each subdirectory represents a usage scenario and must be independently runnable. Examples are executed as part of `make test`.
 

package/.xdrs/agentme/edrs/principles/009-error-handling.md

@@ -17,7 +17,7 @@ What error handling practices should be followed across all languages and projec
 
 ### Implementation Details
 
-#### 1. Catch exceptions only where they can be properly handled
+#### 01-catch-only-where-handled
 
 Never catch an exception unless the catching site can genuinely recover from it, translate it into a meaningful domain error, or enrich it with context before re-throwing. Do **not** swallow exceptions silently. When suppressing an exception is intentional, always add a comment explaining exactly why, or log it at an appropriate level.
 
@@ -73,7 +73,7 @@ except CacheError:
 
 ---
 
-#### 2. Avoid exposing exceptions as part of public interfaces — return error values instead
+#### 02-avoid-exceptions-in-public-interfaces
 
 At module and service boundaries, prefer returning a value that signals success or failure (e.g., a result type, a discriminated union, or a `(value, error)` tuple as in Go) over throwing exceptions. This forces callers to explicitly acknowledge and handle the error case before using the result.
 
@@ -157,7 +157,7 @@ def fetch_user(user_id: str) -> Ok[User] | Err:
 
 ---
 
-#### 3. Centralise repetitive catch logic into utility helpers
+#### 03-centralise-repetitive-catch-logic
 
 If the same `try/catch` pattern (e.g., logging, classifying HTTP errors, wrapping exceptions) appears in multiple places, extract it into a shared utility. Do not copy-paste catch blocks across the codebase.
 
@@ -209,7 +209,7 @@ def save_order(order: Order): ...
 
 ---
 
-#### 4. Communicate failure clearly at process and service boundaries
+#### 04-communicate-failure-at-boundaries
 
 Every system boundary must signal failure explicitly:
 
@@ -272,7 +272,7 @@ def create_order_endpoint(payload: OrderRequest):
 
 ---
 
-#### 5. Write test cases for error scenarios
+#### 05-write-test-cases-for-error-scenarios
 
 Every module that handles errors must have dedicated test cases that verify the error paths. Do not only test the happy path.
 

package/.xdrs/agentme/edrs/principles/012-continuous-xdr-enrichment.md

@@ -38,7 +38,7 @@ Developers must treat reusable missing guidance discovered during implementation
 
 ## References
 
-- [_core-adr-001](../../../_core/adrs/principles/001-xdrs-core.md)
-- [_core-article-001](../../../_core/adrs/principles/articles/001-xdrs-overview.md)
+- [_core-adr-001](/.xdrs/_core/adrs/principles/001-xdrs-core.md)
+- [_core-article-001](/.xdrs/_core/adrs/principles/articles/001-xdrs-overview.md)
 - [agentme-article-001](articles/001-continuous-xdr-improvement.md)
-- [002-write-xdr skill](../../../../.github/skills/002-write-xdr/SKILL.md)
+- [002-write-xdr skill](/.github/skills/002-write-xdr/SKILL.md)

package/.xdrs/agentme/edrs/principles/016-cross-language-module-structure.md

@@ -19,11 +19,11 @@ Language-specific EDRs may add ecosystem details, but they must not redefine the
 
 ### Implementation Details
 
-#### 1. Every buildable or publishable module MUST own its folder root
+#### 01-module-must-own-folder-root
 
 A module is the smallest independently buildable, testable, or publishable unit. It MUST live in its own folder and that folder MUST contain:
 
-- a `Makefile` following [agentme-edr-008](../devops/008-common-targets.md)
+- a `Makefile` following [agentme-edr-008](/.xdrs/agentme/edrs/devops/008-common-targets.md)
 - a `README.md` for the module itself
 - all configuration files required to build, lint, test, package, or publish that module
 - its generated `dist/` directory when the module produces distributable artifacts
@@ -40,7 +40,7 @@ Example module root:
 └── ... language-specific sources and config ...
 ```
 
-#### 2. Parent folders are aggregation roots, not hidden implementation buckets
+#### 02-parent-folders-are-aggregation-roots
 
 Parent folders such as a repository root, an application folder, or `lib/` may aggregate multiple modules. They may also hold shared consumer examples or multi-module test harnesses.
 
@@ -57,13 +57,13 @@ Recommended aggregation pattern:
 └── tests_benchmark/
 ```
 
-#### 3. Build and publish outputs MUST go to `dist/`
+#### 03-build-outputs-must-go-to-dist
 
 Distributable outputs such as packages, wheels, archives, generated binaries, or packed example inputs MUST be written under the module's `dist/` folder.
 
 `dist/` MUST be gitignored.
 
-#### 4. Persistent tool caches MUST live under `.cache/`
+#### 04-persistent-caches-must-live-under-cache
 
 Tool-generated caches and disposable machine-local state MUST be redirected into the nearest intended `.cache/` folder, either at monorepo level or module level.
 
@@ -79,7 +79,7 @@ If a tool cannot natively choose its cache path, the module `Makefile` MUST wrap
 
 `.cache/` MUST be gitignored.
 
-#### 5. Consumer examples MUST sit outside the module they exercise
+#### 05-consumer-examples-must-sit-outside-module
 
 Examples that demonstrate how to consume a library or reusable module MUST live in a sibling `examples/` folder under the nearest aggregation root, not inside the module folder itself.
 
@@ -98,7 +98,7 @@ examples/
 └── using-mymodule/
 ```
 
-#### 6. Every module README MUST explain both usage and development
+#### 06-module-readme-must-explain-usage-and-development
 
 Each module MUST contain a `README.md` that shows how to use the module as a consumer.
 
@@ -106,7 +106,7 @@ The end of the README MUST also include short developer instructions for that mo
 
 Repository-level READMEs may describe the workspace, but they do not replace the module README.
 
-#### 7. Unit, integration, and benchmark tests use predictable locations
+#### 07-tests-use-predictable-locations
 
 Unit tests SHOULD be co-located with the file they exercise when that is idiomatic and common for the language.
 
@@ -123,11 +123,11 @@ Benchmark tests MUST live in one of these locations:
 - `<module>/tests_benchmark/` for module-specific harnesses or datasets
 - `<parent>/tests_benchmark/` when they cover multiple sibling modules
 
-#### 8. Module Makefiles MUST expose the shared target vocabulary
+#### 08-module-makefiles-must-expose-shared-targets
 
-Every module `Makefile` MUST expose the common target names from [agentme-edr-008](../devops/008-common-targets.md). At minimum, modules MUST provide `build`, `lint`, and `test`, and SHOULD also provide `all`, `clean`, and `lint-fix` when meaningful.
+Every module `Makefile` MUST expose the common target names from [agentme-edr-008](/.xdrs/agentme/edrs/devops/008-common-targets.md). At minimum, modules MUST provide `build`, `lint`, and `test`, and SHOULD also provide `all`, `clean`, and `lint-fix` when meaningful.
 
 ## References
 
-- [agentme-edr-005](../devops/005-monorepo-structure.md) - Monorepo aggregation and delegation rules
-- [agentme-edr-008](../devops/008-common-targets.md) - Shared Makefile target names
+- [agentme-edr-005](/.xdrs/agentme/edrs/devops/005-monorepo-structure.md) - Monorepo aggregation and delegation rules
+- [agentme-edr-008](/.xdrs/agentme/edrs/devops/008-common-targets.md) - Shared Makefile target names

package/.xdrs/agentme/edrs/principles/articles/001-continuous-xdr-improvement.md

@@ -51,7 +51,7 @@ Good opening questions:
 
 ### How should you organize the XDR?
 
-Follow the XDR template from [_core-adr-002](../../../../_core/adrs/principles/002-xdr-standards.md). Keep the document small, explicit, and decision-focused.
+Follow the XDR template from [_core-adr-002](/.xdrs/_core/adrs/principles/002-xdr-standards.md). Keep the document small, explicit, and decision-focused.
 
 Use this checklist:
 
@@ -87,7 +87,7 @@ If the same clarification would likely be needed in another feature, by another
 
 ## References
 
-- [_core-adr-001](../../../../_core/adrs/principles/001-xdrs-core.md) - XDR structure, numbering, and mandatory template
-- [_core-article-001](../../../../_core/adrs/principles/articles/001-xdrs-overview.md) - XDR introduction and general adoption guidance
-- [agentme-edr-012](../012-continuous-xdr-enrichment.md) - Shared-first XDR enrichment policy and 80% coverage target
-- [002-write-xdr skill](../../../../../.github/skills/002-write-xdr/SKILL.md) - Step-by-step procedure for drafting new XDRs
+- [_core-adr-001](/.xdrs/_core/adrs/principles/001-xdrs-core.md) - XDR structure, numbering, and mandatory template
+- [_core-article-001](/.xdrs/_core/adrs/principles/articles/001-xdrs-overview.md) - XDR introduction and general adoption guidance
+- [agentme-edr-012](/.xdrs/agentme/edrs/principles/012-continuous-xdr-enrichment.md) - Shared-first XDR enrichment policy and 80% coverage target
+- [002-write-xdr skill](/.github/skills/002-write-xdr/SKILL.md) - Step-by-step procedure for drafting new XDRs

package/.xdrs/agentme/index.md

@@ -0,0 +1,21 @@
+# agentme Scope Overview
+
+## Overview
+
+The `agentme` scope is a curated library of XDRs and skills encoding best practices for AI coding agents. It covers architectural, engineering, and tooling decisions relevant to AI-assisted software development and is intended for consumption by external projects.
+
+## Content
+
+### What this scope covers
+
+The `agentme` scope provides opinionated, reusable guidance on how to scaffold, build, test, and ship software projects. It targets AI coding agents and human developers who want consistent, high-quality defaults across JavaScript, Go, and Python projects.
+
+All content in this scope is published and consumed by external projects. Changes must be clear, backwards-compatible where possible, and thoroughly reviewed before merging.
+
+### Engineering decisions
+
+The `agentme` EDRs cover project tooling and structure for each supported language, CLI standards, monorepo layout, CI/CD pipelines, and observability. See the full list in the [EDRs Index](edrs/index.md).
+
+## Type Indexes
+
+- [EDRs Index](edrs/index.md) - Engineering decisions for coding best practices and project tooling

package/.xdrs/index.md

@@ -9,8 +9,7 @@ XDRs in scopes listed last override the ones listed first
 ### _core
 
 Decisions about how XDRs work
-[View _core ADRs Index](_core/adrs/index.md)
-[View _core BDRs Index](_core/bdrs/index.md)
+[View _core Scope Index](_core/index.md)
 
 ---
 
@@ -18,7 +17,7 @@ Decisions about how XDRs work
 
 Opiniated set of decisions and skills for common development tasks
 
-[View agentme EDRs Index](agentme/edrs/index.md)
+[View agentme Scope Index](agentme/index.md)
 
 ---
 

package/package.json

@@ -1,10 +1,10 @@
 {
   "name": "agentme",
-  "version": "0.7.3",
+  "version": "0.7.4",
   "description": "",
   "dependencies": {
     "filedist": "^0.26.0",
-    "xdrs-core": "^0.17.0"
+    "xdrs-core": "^0.20.0"
   },
   "bin": "bin/filedist.js",
   "files": [