agentme 0.7.3 → 0.7.5

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

@@ -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

@@ -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/devops/005-monorepo-structure.md

@@ -18,9 +18,9 @@ What monorepo structure, naming conventions, tooling, and build standards should
 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).
 
-### 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,7 +57,7 @@ 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.
@@ -66,13 +66,13 @@ Module folder responsibilities, artifact locations, and test-folder conventions
 - **MUST** keep build outputs under `dist/` and persistent caches under `.cache/`, following [agentme-edr-016](../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.
 

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/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,7 +63,7 @@ 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.
 
@@ -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.
 
@@ -89,7 +89,7 @@ Projects larger than 10 files or 200 lines of code must have a linter configured
 
 ---
 
-### 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/016-cross-language-module-structure.md

@@ -19,7 +19,7 @@ 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:
 
@@ -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,7 +123,7 @@ 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.
 

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.5",
   "description": "",
   "dependencies": {
     "filedist": "^0.26.0",
-    "xdrs-core": "^0.17.0"
+    "xdrs-core": "^0.21.0"
   },
   "bin": "bin/filedist.js",
   "files": [