agentme 0.28.1 → 0.30.0

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

@@ -0,0 +1,47 @@
+---
+skill: 200-run-skill-tests
+skill-version: "1.0"
+---
+
+## Test Scenarios
+
+### 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:
+
+"Test the skill at `.agents/skills/001-review`"
+
+**Expected Behaviour**
+1. Skill resolves the path to the real directory (following the symlink).
+2. Skill confirms `SKILL.test.md` is present.
+3. Skill reads `SKILL.test.md` in full and parses all scenarios.
+4. Skill reads `SKILL.md` and verifies `skill-version` matches.
+5. Skill executes each scenario by presenting the trigger to the target skill.
+6. Skill evaluates every assertion for each scenario and records PASS or FAIL.
+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 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:`.
+
+### 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:
+
+"Run tests for `.xdrs/agentme/edrs/application/skills/050-create-javascript-project`"
+
+**Expected Behaviour**
+1. Skill resolves the path to the directory.
+2. Skill checks for `SKILL.test.md` and finds it absent.
+3. Skill immediately outputs an ERROR message referencing the missing file and the policy.
+4. Skill does NOT proceed to execute any scenarios.
+
+**Assertions**
+- [ ] Output contains `ERROR` indicating `SKILL.test.md` was not found.
+- [ ] Output references the resolved path of the skill directory.
+- [ ] Output does NOT contain any `### Scenario` execution section.
+- [ ] Output does NOT contain a `## Summary` report block.

package/.xdrs/agentme/edrs/data/{050-ml-dataset-structure.md → 201-ml-dataset-structure.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-050-ml-dataset-structure
+name: agentme-edr-policy-201-ml-dataset-structure
 description: Defines the standard folder layout and file conventions for ML datasets used in AI/ML projects. Use when creating, organizing, or consuming datasets for machine learning tasks such as image labeling, document extraction, tabular data, LLM evaluation, and Q&A sets.
 apply-to: ML and AI projects that produce or consume datasets
 valid-from: 2026-05-27
 ---
 
-# agentme-edr-policy-050: ML dataset structure
+# agentme-edr-policy-201: ML dataset structure
 
 ## Context and Problem Statement
 
@@ -102,10 +102,10 @@ Every dataset MUST expose a `make lint` target (in the Makefile of the project/c
 - Per-entry JSON files (rule `04`) and annotation-pair `.json` siblings (rule `02`) MUST each be validated against `dataset.schema.json`, and their `$schema` property MUST be present and resolve to the dataset's actual schema file.
 - CSV rows (rule `03`) MUST each be converted to a JSON object (column header → value) and validated against the same `dataset.schema.json`.
 - `make lint` MUST list every violation found across all files/rows before exiting with a non-zero status (not fail-fast on the first violation).
-- `jsonschema` MUST be declared as a normal project dependency per [agentme-edr-014](../application/014-python-project-tooling.md); no special-casing.
+- `jsonschema` MUST be declared as a normal project dependency per [agentme-edr-103](../application/103-python-project-tooling.md); no special-casing.
 
 ## References
 
 - [JSON Schema specification](https://json-schema.org/)
 - [jsonschema (Python library)](https://pypi.org/project/jsonschema/)
-- [agentme-edr-014](../application/014-python-project-tooling.md) — Python project tooling and dependency conventions
+- [agentme-edr-103](../application/103-python-project-tooling.md) — Python project tooling and dependency conventions

package/.xdrs/agentme/edrs/governance/{007-project-quality-standards.md → 501-project-quality-standards.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-007-project-quality-standards
+name: agentme-edr-policy-501-project-quality-standards
 description: Defines minimum project quality standards for README onboarding, testing (unit, integration, and AI-tier evals), linting, XDR compliance, and runnable examples. Use when scaffolding or reviewing projects.
 apply-to: All projects
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-007: Project quality standards
+# agentme-edr-policy-501: Project quality standards
 
 ## Context and Problem Statement
 
@@ -61,7 +61,7 @@ A unit test suite MUST run automatically before every release. Failing tests MUS
 
 **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 NOT be deployed to production.
 
-**Reference:** [agentme-edr-004](../application/004-unit-test-requirements.md) for detailed unit test requirements.
+**Reference:** [agentme-edr-122](../application/122-unit-test-requirements.md) for detailed unit test requirements.
 
 ---
 
@@ -87,7 +87,7 @@ 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 NOT be deployed to production.
 
-**Reference:** [agentme-edr-003](../application/003-javascript-project-tooling.md) for JavaScript-specific tooling.
+**Reference:** [agentme-edr-101](../application/101-javascript-project-tooling.md) for JavaScript-specific tooling.
 
 ---
 
@@ -156,7 +156,7 @@ test-examples:
 	$(MAKE) -C examples
 ```
 
-If examples require live services or credentials, remove `test-examples` from the `test` dependency list and keep it as a standalone named target only. See [agentme-edr-008](../platform/008-common-targets.md) rule 08 for the full offline/online decision table.
+If examples require live services or credentials, remove `test-examples` from the `test` dependency list and keep it as a standalone named target only. See [agentme-edr-303](../platform/303-common-targets.md) rule 08 for the full offline/online decision table.
 
 **Examples Makefile:**
 
@@ -175,7 +175,7 @@ Projects that contain statistical models (e.g., ML models, LLM-based evaluators,
 **Requirements:**
 - A `make eval` target MUST exist and execute all performance evaluations
 - Each evaluation MUST have a **documented minimum performance threshold** (e.g., accuracy ≥ 0.85, F1 ≥ 0.80, BLEU ≥ 0.70)
-- Thresholds and all scoring parameters MUST be declared as constants in `eval.py` — they are design decisions about acceptable quality for the component under test, not runtime configuration, and MUST NOT be passed as Makefile variables or CLI flags. See [agentme-edr-053](../application/053-ai-eval-script.md) rule `01`.
+- Thresholds and all scoring parameters MUST be declared as constants in `eval.py` — they are design decisions about acceptable quality for the component under test, not runtime configuration, and MUST NOT be passed as Makefile variables or CLI flags. See [agentme-edr-153](../application/153-ai-eval-script.md) rule `01`.
 - `make eval` MUST **exit with a non-zero status** (fail) if:
   - The evaluation cannot be executed (missing data, environment errors, model load failures)
   - Any metric falls below its defined minimum threshold
@@ -244,27 +244,27 @@ Projects are not required to implement integration tests, but when present, they
 
 #### 09-ai-project-testing-requirements
 
-AI projects are classified into three tiers — LLM, Agent, and Workflow — defined in [agentme-edr-040](../application/040-ai-llm-development-standards.md). Testing requirements differ per tier:
+AI projects are classified into three tiers — LLM, Agent, and Workflow — defined in [agentme-edr-141](../application/141-ai-llm-development-standards.md). Testing requirements differ per tier:
 
 | Tier | Unit tests | Evals | Integration tests |
 |---|---|---|---|
-| **LLM** ([agentme-edr-040](../application/040-ai-llm-development-standards.md)) | Not required | Not required; SHOULD be used when critical prompts are in use to measure accuracy and detect model drift | Not required |
-| **Agent** ([agentme-edr-041](../application/041-ai-agents-development-standards.md)) | Not required | Not required; MAY be used | Not required |
-| **Workflow** ([agentme-edr-043](../application/043-ai-workflow-development-standards.md)) | Required — see below | Required before every release; failed evals block release | Advised |
+| **LLM** ([agentme-edr-141](../application/141-ai-llm-development-standards.md)) | Not required | Not required; SHOULD be used when critical prompts are in use to measure accuracy and detect model drift | Not required |
+| **Agent** ([agentme-edr-142](../application/142-ai-agents-development-standards.md)) | Not required | Not required; MAY be used | Not required |
+| **Workflow** ([agentme-edr-144](../application/144-ai-workflow-development-standards.md)) | Required — see below | Required before every release; failed evals block release | Advised |
 
 **Workflow unit test requirements:**
 
-- MUST use mocked LLM providers. See [agentme-edr-040](../application/040-ai-llm-development-standards.md) rule `04-unit-test-mocking` for the mocking pattern.
-- MUST run offline with no external dependencies per [agentme-edr-004](../application/004-unit-test-requirements.md) rule `02-must-run-offline`.
-- MUST achieve 80% code coverage per [agentme-edr-004](../application/004-unit-test-requirements.md) rule `03-must-maintain-80-percent-coverage`.
+- MUST use mocked LLM providers. See [agentme-edr-141](../application/141-ai-llm-development-standards.md) rule `04-unit-test-mocking` for the mocking pattern.
+- MUST run offline with no external dependencies per [agentme-edr-122](../application/122-unit-test-requirements.md) rule `02-must-run-offline`.
+- MUST achieve 80% code coverage per [agentme-edr-122](../application/122-unit-test-requirements.md) rule `03-must-maintain-80-percent-coverage`.
 - MUST test workflow routing logic, conditional edges, state transformations, and error handling.
 - MUST achieve **80% coverage of LangGraph graph edges and branches**: every conditional edge MUST have test cases covering each possible branch, and every node→node transition MUST be exercised by at least one test.
-- Files MUST be named `<name>_test.py` and placed alongside the source file per [agentme-edr-004](../application/004-unit-test-requirements.md) rule `04-must-place-test-files-alongside-source`.
+- Files MUST be named `<name>_test.py` and placed alongside the source file per [agentme-edr-122](../application/122-unit-test-requirements.md) rule `04-must-place-test-files-alongside-source`.
 
 **Workflow eval requirements:**
 
 - Evals MUST be executed before every release.
 - Accuracy below project-defined thresholds MUST block the release. Thresholds MUST be documented in the eval Makefile or README.
 - Evals MUST run against real LLM providers (not mocks) to capture model drift.
-- For eval folder structure and LLM-as-judge scoring, see [agentme-edr-051](../application/051-ai-eval-core-standards.md). For eval script requirements, see [agentme-edr-053](../application/053-ai-eval-script.md).
-- For the taxonomy of AI test types (safety, responsible-AI, quality-eval, prompt, code-level) and the golden dataset entry format, see [agentme-edr-052](../application/052-ai-test-types-taxonomy.md).
+- For eval folder structure and LLM-as-judge scoring, see [agentme-edr-151](../application/151-ai-eval-standards.md). For eval script requirements, see [agentme-edr-153](../application/153-ai-eval-script.md).
+- For the taxonomy of AI test types (safety, responsible-AI, quality-eval, prompt, code-level) and the golden dataset entry format, see [agentme-edr-152](../application/152-ai-test-types-taxonomy.md).

package/.xdrs/agentme/edrs/governance/{013-contributing-guide-requirements.md → 502-contributing-guide-requirements.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-013-contributing-guide-requirements
+name: agentme-edr-policy-502-contributing-guide-requirements
 description: Defines the minimum contributor workflow guidance required in root CONTRIBUTING.md files. Use when scaffolding or reviewing contribution processes.
 apply-to: Projects with open-source contributions
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-013: Contributing guide requirements
+# agentme-edr-policy-502: Contributing guide requirements
 
 ## Context and Problem Statement
 
@@ -66,5 +66,5 @@ The content SHOULD stay concise and practical; do not turn `CONTRIBUTING.md` int
 
 ## References
 
-- [agentme-edr-005 - Monorepo structure](../platform/005-monorepo-structure.md)
-- [002-monorepo-setup skill](../platform/skills/002-monorepo-setup/SKILL.md)
+- [agentme-edr-301 - Monorepo structure](../platform/301-monorepo-structure.md)
+- [053-monorepo-setup skill](../platform/skills/053-monorepo-setup/SKILL.md)

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

@@ -10,6 +10,7 @@ Foundational standards, principles, and guidelines.
 
 - [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))*
 
 ## Articles
 
@@ -21,67 +22,68 @@ Synthetic views combining agentme XDRs and skills around a specific topic.
 
 Language and framework-specific tooling and project structure.
 
-- [agentme-edr-002](application/002-coding-best-practices.md) - **Coding best practices** - Keep files small, tests nearby, and docs synchronized
-- [agentme-edr-004](application/004-unit-test-requirements.md) - **Unit test requirements** - Define minimum unit-test coverage and naming expectations
-- [agentme-edr-009](application/009-error-handling.md) - **Error handling** - Standardize explicit errors, logging, and propagation rules
-- [agentme-edr-022](application/022-secrets-management.md) - **Secrets management** - Handle secrets securely using native keychains and cloud secret managers
-- [agentme-edr-023](application/023-coding-abstraction-practices.md) - **Coding abstraction practices** - Define when abstractions are justified and when they must be inlined
+- [agentme-edr-121](application/121-coding-best-practices.md) - **Coding best practices** - Keep files small, tests nearby, and docs synchronized
+- [agentme-edr-122](application/122-unit-test-requirements.md) - **Unit test requirements** - Define minimum unit-test coverage and naming expectations
+- [agentme-edr-123](application/123-error-handling.md) - **Error handling** - Standardize explicit errors, logging, and propagation rules
+- [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
 
 ### Language and framework tooling
 
-- [agentme-edr-003](application/003-javascript-project-tooling.md) - **JavaScript project tooling and structure** - Scaffold JavaScript libraries with the standard toolchain *(includes skill: [001-create-javascript-project](application/skills/001-create-javascript-project/SKILL.md))*
-- [agentme-edr-010](application/010-golang-project-tooling.md) - **Go project tooling and structure** - Scaffold Go CLIs and libraries with the standard layout *(includes skill: [003-create-golang-project](application/skills/003-create-golang-project/SKILL.md))*
-- [agentme-edr-014](application/014-python-project-tooling.md) - **Python project tooling and structure** - Scaffold Python packages and CLIs with the standard layout *(includes skill: [005-create-python-project](application/skills/005-create-python-project/SKILL.md))*
-- [agentme-edr-015](application/015-cli-tool-standards.md) - **CLI tool standards** - Define command UX and behavior for CLI tools
-- [agentme-edr-026](application/026-pragmatic-hexagonal-architecture.md) - **Pragmatic hexagonal architecture** - Organize application layers as External/Adapters/Application with practical coupling rules
-- [004-select-relevant-xdrs](application/skills/004-select-relevant-xdrs/SKILL.md) - **Select relevant XDRs**
+- [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-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**
 
 ### AI development
 
 Standards for building LLM, Agent, and Workflow components.
 
-- [agentme-edr-040](application/040-ai-llm-development-standards.md) - **AI LLM development standards** - Standard framework (LangChain) and patterns for simple LLM calls with explicit configuration (no environment variables)
-- [agentme-edr-041](application/041-ai-agents-development-standards.md) - **AI agents development standards** - Structural patterns for agents: framework selection, sandbox setup, naming conventions, composition, and system prompt structure
-- [agentme-edr-042](application/042-ai-agents-quality-standards.md) - **AI agents implementation quality standards** - Tool definition patterns, error handling, observability, and unit testing for agents
-- [agentme-edr-043](application/043-ai-workflow-development-standards.md) - **AI workflow development standards** - Standard toolchain (LangGraph), evaluation, and testing patterns for workflow projects
-- [agentme-edr-044](application/044-ai-workflow-naming-conventions.md) - **AI workflow naming conventions** - Node suffix/prefix roles, state type and attribute naming, judge output schema, workflow class names, and cross-element coherence rules
-- [agentme-edr-045](application/045-ai-agent-xdrs-knowledge-layer.md) - **AI agent XDRS knowledge layer** - How to integrate XDRS as the runtime source of truth for policies and skills in AI agents (apply only when the project explicitly uses XDRS)
+- [agentme-edr-141](application/141-ai-llm-development-standards.md) - **AI LLM development standards** - Standard framework (LangChain) and patterns for simple LLM calls with explicit configuration (no environment variables)
+- [agentme-edr-142](application/142-ai-agents-development-standards.md) - **AI agents development standards** - Structural patterns for agents: framework selection, sandbox setup, naming conventions, composition, and system prompt structure
+- [agentme-edr-143](application/143-ai-agents-quality-standards.md) - **AI agents implementation quality standards** - Tool definition patterns, error handling, observability, and unit testing for agents
+- [agentme-edr-144](application/144-ai-workflow-development-standards.md) - **AI workflow development standards** - Standard toolchain (LangGraph), evaluation, and testing patterns for workflow projects
+- [agentme-edr-145](application/145-ai-workflow-naming-conventions.md) - **AI workflow naming conventions** - Node suffix/prefix roles, state type and attribute naming, judge output schema, workflow class names, and cross-element coherence rules
+- [agentme-edr-146](application/146-ai-agent-xdrs-knowledge-layer.md) - **AI agent XDRS knowledge layer** - How to integrate XDRS as the runtime source of truth for policies and skills in AI agents (apply only when the project explicitly uses XDRS)
 
 ### AI evaluation and testing
 
 Standards for eval datasets, scripts, reports, and test type taxonomy.
 
-- [agentme-edr-051](application/051-ai-eval-core-standards.md) - **AI eval core standards** - Eval folder structure and Makefile interface; LLM-as-judge binary scoring contract applicable to all AI tiers and test types
-- [agentme-edr-052](application/052-ai-test-types-taxonomy.md) - **AI test types taxonomy** - Names AI test types (`functional`, `safety`, `smoke`, `repeatability`, `adversarial`, `fairness`, `bias`, and 5 others) with group, objective, mocking constraint, and relevance, and defines the shared golden dataset entry envelope
-- [agentme-edr-053](application/053-ai-eval-script.md) - **AI eval script** - eval.py requirements: entry-first loop, --type filtering, mock_fixtures wiring, human entries, threshold enforcement, and MLflow experiment conventions
-- [agentme-edr-054](application/054-ai-eval-report-format.md) - **AI eval report format** - report-<type>.md template, Wilson score confidence interval, convergence analysis, and human-type checklist artifact
-- [agentme-edr-055](application/055-ai-eval-repeatability.md) - **AI eval repeatability** - Repeatability test type: REPEAT_COUNT loop exception, semantic-similarity and LLM-as-judge scoring, repeatability_accuracy metric, report shape, and run cadence
+- [agentme-edr-151](application/151-ai-eval-standards.md) - **AI eval core standards** - Eval folder structure and Makefile interface; LLM-as-judge binary scoring contract applicable to all AI tiers and test types
+- [agentme-edr-152](application/152-ai-test-types-taxonomy.md) - **AI test types taxonomy** - Names AI test types (`functional`, `safety`, `smoke`, `repeatability`, `adversarial`, `fairness`, `bias`, and 5 others) with group, objective, mocking constraint, and relevance, and defines the shared golden dataset entry envelope
+- [agentme-edr-153](application/153-ai-eval-script.md) - **AI eval script** - eval.py requirements: entry-first loop, --type filtering, mock_fixtures wiring, human entries, threshold enforcement, and MLflow experiment conventions
+- [agentme-edr-154](application/154-ai-eval-report-format.md) - **AI eval report format** - report-<type>.md template, Wilson score confidence interval, convergence analysis, and human-type checklist artifact
+- [agentme-edr-155](application/155-ai-eval-repeatability.md) - **AI eval repeatability** - Repeatability test type: REPEAT_COUNT loop exception, semantic-similarity and LLM-as-judge scoring, repeatability_accuracy metric, report shape, and run cadence
 
 ## Data
 
 Data layer implementation and data management decisions.
 
-- [agentme-edr-050](data/050-ml-dataset-structure.md) - **ML dataset structure** - Standard folder layout and file conventions for ML datasets
+- [agentme-edr-201](data/201-ml-dataset-structure.md) - **ML dataset structure** - Standard folder layout and file conventions for ML datasets
 
 ## Platform
 
 Infrastructure implementation, delivery pipeline, and developer environment decisions.
 
-- [agentme-edr-005](platform/005-monorepo-structure.md) - **Monorepo structure** - Standardize monorepo layout, tooling, and package boundaries *(includes skill: [002-monorepo-setup](platform/skills/002-monorepo-setup/SKILL.md))*
-- [agentme-edr-006](platform/006-github-pipelines.md) - **GitHub CI/CD pipelines** - Define required CI stages and workflow structure
-- [agentme-edr-008](platform/008-common-targets.md) - **Common development script names** - Reuse standard build, lint, and test target names
-- [agentme-edr-017](platform/017-tool-execution-and-scripting.md) - **Tool execution and scripting** - Run tools consistently across shells, Makefiles, and CI
-- [agentme-edr-027](platform/027-environment-variable-configuration.md) - **Environment variable configuration files** - Manage non-secret configuration with `.env` files, `.gitignore` rules, stage variants, and Makefile loading
+- [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-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
+- [agentme-edr-305](platform/305-environment-variable-configuration.md) - **Environment variable configuration files** - Manage non-secret configuration with `.env` files, `.gitignore` rules, stage variants, and Makefile loading
 
 ## Governance
 
 Contribution and collaboration standards shared across projects.
 
-- [agentme-edr-007](governance/007-project-quality-standards.md) - **Project quality standards** - Require build, lint, and test verification before completion
-- [agentme-edr-013](governance/013-contributing-guide-requirements.md) - **Contributing guide requirements** - Define the minimum structure for CONTRIBUTING guides
+- [agentme-edr-501](governance/501-project-quality-standards.md) - **Project quality standards** - Require build, lint, and test verification before completion
+- [agentme-edr-502](governance/502-contributing-guide-requirements.md) - **Contributing guide requirements** - Define the minimum structure for CONTRIBUTING guides
 
 ## Operations
 
 Production behavior and operational response decisions.
 
-- [agentme-edr-011](operations/011-service-health-check-endpoint.md) - **Service health check endpoint** - Expose a standard runtime health-check endpoint for services
+- [agentme-edr-401](operations/401-service-health-check-endpoint.md) - **Service health check endpoint** - Expose a standard runtime health-check endpoint for services

package/.xdrs/agentme/edrs/operations/{011-service-health-check-endpoint.md → 401-service-health-check-endpoint.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-011-service-health-check-endpoint
+name: agentme-edr-policy-401-service-health-check-endpoint
 description: Defines the required health endpoint contract for service availability and dependency readiness checks. Use when implementing or reviewing service health endpoints.
 apply-to: Service projects with health endpoints
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-011: Service health check endpoint
+# agentme-edr-policy-401: Service health check endpoint
 
 ## Context and Problem Statement
 

package/.xdrs/agentme/edrs/platform/{005-monorepo-structure.md → 301-monorepo-structure.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-005-monorepo-structure
+name: agentme-edr-policy-301-monorepo-structure
 description: Defines the standard monorepo layout, naming, and build conventions using shared areas, Mise, and Makefiles. Use when creating or reviewing monorepos.
 apply-to: Monorepo projects
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-005: Monorepo structure
+# agentme-edr-policy-301: Monorepo structure
 
 ## Context and Problem Statement
 
@@ -17,7 +17,7 @@ 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).
+For step-by-step scaffolding instructions see [skill 053-monorepo-setup](skills/053-monorepo-setup/SKILL.md).
 Module folder responsibilities, artifact locations, and test-folder conventions follow [agentme-edr-016](../principles/016-cross-language-module-structure.md).
 
 ### Details
@@ -78,7 +78,7 @@ Every monorepo MUST follow this top-level directory layout:
 
 A `Makefile` MUST be present at the repository root, in every application folder, and in every module folder.
 
-All Makefiles MUST use the shared target vocabulary from [agentme-edr-008](008-common-targets.md).
+All Makefiles MUST use the shared target vocabulary from [agentme-edr-303](303-common-targets.md).
 
 Repository, application, and module Makefiles MUST define at minimum: `all`, `build`, `lint`, `test`, and `clean`.
 
@@ -94,7 +94,7 @@ The root `setup` target MUST run `mise install` and any small repository bootstr
 - Every language runtime or CLI referenced by any module `Makefile`, CI workflow, or README command MUST be pinned in `.mise.toml`.
 - Contributors and CI run `make setup` after cloning or checkout; this target MUST call `mise install`.
 - Agents and contributors MUST check `.mise.toml` before using a system-installed compiler, runtime, or CLI.
-- When `.mise.toml` exists, all build, test, lint, and code-generation commands MUST run through `make <target>`, and the Makefile recipes MUST execute the underlying tools via `mise exec -- <command>`, following [agentme-edr-017](017-tool-execution-and-scripting.md).
+- When `.mise.toml` exists, all build, test, lint, and code-generation commands MUST run through `make <target>`, and the Makefile recipes MUST execute the underlying tools via `mise exec -- <command>`, following [agentme-edr-304](304-tool-execution-and-scripting.md).
 - If a required tool is missing, the first remediation step MUST be to update `.mise.toml` or run `mise install`, not to install ad-hoc global tools with language-specific installers such as `go install`, `npm install -g`, `pip install --user`, or `cargo install`.
 - Root and module `Makefile` targets MUST work when invoked as plain `make <target>` after `make setup`.
 

package/.xdrs/agentme/edrs/platform/{006-github-pipelines.md → 302-github-pipelines.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-006-github-ci-cd-pipelines
+name: agentme-edr-policy-302-github-ci-cd-pipelines
 description: Defines the standard GitHub Actions workflow split for CI, release tagging, and publishing. Use when configuring project automation.
 apply-to: Projects using GitHub Actions
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-006: GitHub CI/CD pipelines
+# agentme-edr-policy-302: GitHub CI/CD pipelines
 
 ## Context and Problem Statement
 
@@ -142,7 +142,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-101](../application/101-javascript-project-tooling.md).
 
 ---
 

package/.xdrs/agentme/edrs/platform/{008-common-targets.md → 303-common-targets.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-008-common-development-script-names
+name: agentme-edr-policy-303-common-development-script-names
 description: Defines standard Makefile target names and the mandatory tool-execution flow using Mise. Use when designing build, lint, test, and release entry points.
 apply-to: All projects with Makefiles
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-008: Common development script names
+# agentme-edr-policy-303: Common development script names
 
 ## Context and Problem Statement
 
@@ -15,7 +15,7 @@ What standard set of Makefile target names and execution rules should projects a
 
 ## Decision Outcome
 
-**Every project MUST expose its development actions through a root `Makefile` using a defined set of standardized target names. Target implementation and tool-execution rules follow [agentme-edr-017](017-tool-execution-and-scripting.md), which requires `mise exec --` before routine tool commands.**
+**Every project MUST expose its development actions through a root `Makefile` using a defined set of standardized target names. Target implementation and tool-execution rules follow [agentme-edr-304](304-tool-execution-and-scripting.md), which requires `mise exec --` before routine tool commands.**
 
 Standardizing both the target names and the execution chain removes per-project guesswork, makes CI pipelines reusable, and keeps tooling behavior visible in one place.
 
@@ -49,7 +49,7 @@ make <target>
 
 - The `setup` target MUST run `mise install` and any small project-specific bootstrap needed before normal targets work.
 - Routine targets such as `build`, `lint`, `test`, `run`, and `publish` MUST be invoked as `make <target>` by both contributors and CI.
-- Each Makefile recipe MUST call the real underlying command through `mise exec --`, following [agentme-edr-017](017-tool-execution-and-scripting.md).
+- Each Makefile recipe MUST call the real underlying command through `mise exec --`, following [agentme-edr-304](304-tool-execution-and-scripting.md).
 - Makefile recipes MUST NOT add extra script layers such as `npm run`, `pnpm run`, `yarn run`, `mise run`, `mise tasks`, or shell aliases when those layers only forward to another command.
 - Calling the actual tool is allowed even when that tool itself launches another program as part of its normal interface.
 	- Allowed: `mise exec -- pnpm exec eslint ./src`
@@ -167,7 +167,7 @@ test:
 
 A developer can run `make test` at the repo root to test everything, or `cd module-a && make test` to test a single module. Both MUST work.
 
-**Reference:** See [agentme-edr-005](005-monorepo-structure.md) for the full monorepo layout convention.
+**Reference:** See [agentme-edr-301](301-monorepo-structure.md) for the full monorepo layout convention.
 
 ---
 
@@ -228,7 +228,7 @@ Subtargets that require external dependencies (e.g., `test-integration` against
 
 #### 09-ai-project-dev-targets
 
-AI-based projects (LLM, Agent, and Workflow tiers as defined in [agentme-edr-040](../application/040-ai-llm-development-standards.md)) MUST expose a `dev-mlflow` target that starts a local MLflow tracking server for development inspection.
+AI-based projects (LLM, Agent, and Workflow tiers as defined in [agentme-edr-141](../application/141-ai-llm-development-standards.md)) MUST expose a `dev-mlflow` target that starts a local MLflow tracking server for development inspection.
 
 **Example implementation:**
 
@@ -251,5 +251,5 @@ dev-mlflow:
 
 ## References
 
-- [agentme-edr-005](005-monorepo-structure.md) - Monorepo layout and delegation structure
-- [agentme-edr-017](017-tool-execution-and-scripting.md) - Tool-execution rules for Makefile targets and CI
+- [agentme-edr-301](301-monorepo-structure.md) - Monorepo layout and delegation structure
+- [agentme-edr-304](304-tool-execution-and-scripting.md) - Tool-execution rules for Makefile targets and CI

package/.xdrs/agentme/edrs/platform/{017-tool-execution-and-scripting.md → 304-tool-execution-and-scripting.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-017-tool-execution-and-scripting
+name: agentme-edr-policy-304-tool-execution-and-scripting
 description: Defines how Makefiles, CI pipelines, and optional wrapper scripts execute project commands. Use when designing project automation or command entry points.
 apply-to: All projects with Makefiles and CI pipelines
 valid-from: 2026-05-25
 ---
 
-# agentme-edr-policy-017: Tool execution and scripting
+# agentme-edr-policy-304: Tool execution and scripting
 
 ## Context and Problem Statement
 
@@ -15,14 +15,14 @@ How should projects execute development commands so the command surface stays pr
 
 ## Decision Outcome
 
-**Use Makefiles as the only authoritative command entry point, with targets named by [agentme-edr-008](008-common-targets.md) and implemented with `mise exec --` before the real tool command.**
+**Use Makefiles as the only authoritative command entry point, with targets named by [agentme-edr-303](303-common-targets.md) and implemented with `mise exec --` before the real tool command.**
 
 This keeps local development and CI aligned, reduces indirection, and lets contributors understand project behavior by reading one command surface.
 
 ### Details
 
 - Every project MUST use a root `Makefile` as the authoritative entry point for developer and pipeline commands.
-- The target names in that `Makefile` MUST follow [agentme-edr-008](008-common-targets.md).
+- The target names in that `Makefile` MUST follow [agentme-edr-303](303-common-targets.md).
 - CI pipelines MUST run `make <target>` from the relevant root instead of calling language-specific scripts such as `npm run`, `pnpm run`, shell wrappers, or secondary task runners.
 - A Makefile target MUST execute the real operation through `mise exec --` before invoking the tool itself, so it MUST use the version pinned in `.mise.toml`. Avoid intermediate script layers that hide the actual command.
 - Every Makefile target MUST start by echoing a concise summary of the target and folder or context, using fewer than 10 words. When delegating to another Makefile, echo the child path and delegated target before invoking it.
@@ -58,9 +58,9 @@ Disallowed:
 
 ## References
 
-- [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-301](301-monorepo-structure.md) - Monorepo layout and Makefile hierarchy
+- [agentme-edr-302](302-github-pipelines.md) - CI/CD workflows should call Make targets
+- [agentme-edr-303](303-common-targets.md) - Standard target names
+- [agentme-edr-101](../application/101-javascript-project-tooling.md) - JavaScript tooling commands inside Makefiles
+- [agentme-edr-102](../application/102-golang-project-tooling.md) - Go tooling commands inside Makefiles
+- [agentme-edr-103](../application/103-python-project-tooling.md) - Python tooling commands inside Makefiles

package/.xdrs/agentme/edrs/platform/{027-environment-variable-configuration.md → 305-environment-variable-configuration.md}

@@ -1,11 +1,11 @@
 ---
-name: agentme-edr-policy-027-environment-variable-configuration-files
+name: agentme-edr-policy-305-environment-variable-configuration-files
 description: Defines when to use YAML config files versus .env files for configuration, how to combine them, and how .env is loaded for spawned processes. Use when setting up project configuration for any application, CLI, or library.
 apply-to: All projects that use environment variables for configuration
 valid-from: 2026-06-09
 ---
 
-# agentme-edr-policy-027: Environment variable configuration files
+# agentme-edr-policy-305: Environment variable configuration files
 
 ## Context and Problem Statement
 
@@ -19,7 +19,7 @@ How should projects manage environment variable configuration and CLI invocation
 
 **Use YAML config files for CLI invocation configuration with multiple attributes; use `.env` files to supply environment variables to spawned processes and to hold uncommitted values referenced by config files. Load `.env` exclusively at process launch time — MUST NOT be loaded inside application code.**
 
-Secrets (API keys, passwords, tokens) MUST NOT be placed in `.env` files. Those are handled by [agentme-edr-022](../application/022-secrets-management.md).
+Secrets (API keys, passwords, tokens) MUST NOT be placed in `.env` files. Those are handled by [agentme-edr-124](../application/124-secrets-management.md).
 
 ### Details
 
@@ -28,7 +28,7 @@ Secrets (API keys, passwords, tokens) MUST NOT be placed in `.env` files. Those
 A `.env` file MUST be used when either of the following is true:
 
 1. **Spawned process needs env vars** — the project launches a process (a deployable service, background worker, or shell script) that reads configuration from OS environment variables such as port numbers or API endpoint URLs.
-2. **Value must not be committed** — a configuration value used in a YAML config file (see rule 07) is environment-specific or sensitive enough to exclude from version control. In that case, store the value in `.env` and reference it from the YAML file using env var substitution (see rule 08).
+2. **Value MUST NOT be committed** — a configuration value used in a YAML config file (see rule 07) is environment-specific or sensitive enough to exclude from version control. In that case, store the value in `.env` and reference it from the YAML file using env var substitution (see rule 08).
 
 Do not use `.env` as a general-purpose configuration store when a YAML config file is the right tool (see rule 07).
 
@@ -64,7 +64,7 @@ FEATURE_FLAG_NEW_UI=false
 
 Stage-specific overrides MUST use the naming convention `.env.[stage]` (e.g., `.env.production`, `.env.staging`, `.env.test`). These files may be committed to the repository because they carry deployment-stage configuration rather than local developer configuration. They are used during deployment pipelines where the stage is known and explicit.
 
-The generic `.env` must still not be committed. The distinction is: `.env` is for local, ad-hoc, standalone use; `.env.[stage]` is for deployment pipelines with a defined environment identity.
+The generic `.env` MUST NOT be committed. The distinction is: `.env` is for local, ad-hoc, standalone use; `.env.[stage]` is for deployment pipelines with a defined environment identity.
 
 ---
 
@@ -85,7 +85,7 @@ This ensures all variables in `.env` are available as environment variables to e
 
 #### 06-no-application-level-dotenv-loading
 
-Applications MUST NOT load `.env` files directly inside their own code using dotenv libraries or equivalent mechanisms. Configuration must enter the process exclusively as OS-level environment variables, set before the process is launched (by the Makefile, a shell script, CI, or a container runtime).
+Applications MUST NOT load `.env` files directly inside their own code using dotenv libraries or equivalent mechanisms. Configuration MUST enter the process exclusively as OS-level environment variables, set before the process is launched (by the Makefile, a shell script, CI, or a container runtime).
 
 Prohibited patterns:
 
@@ -116,9 +116,9 @@ This rule prevents two parallel loading paths — OS env and file-based env —
 
 CLI adapters with multiple configuration attributes MUST use a YAML config file rather than env vars or flags for those attributes. This applies whenever configuration is nested, repetitive, or too verbose for flags alone.
 
-The CLI layer is responsible for loading and parsing the YAML file and passing the resolved values to the application layer. The application layer must not read the config file directly.
+The CLI layer is responsible for loading and parsing the YAML file and passing the resolved values to the application layer. The application layer MUST NOT read the config file directly.
 
-Default config file discovery should follow the pattern defined in [agentme-edr-015](../application/015-cli-tool-standards.md): load `[cwd]/[tool-name].yml` by default, or an explicit path provided via `--config`.
+Default config file discovery SHOULD follow the pattern defined in [agentme-edr-104](../application/104-cli-tool-standards.md): load `[cwd]/[tool-name].yml` by default, or an explicit path provided via `--config`.
 
 Example `myconfig.yml`:
 ```yaml
@@ -131,7 +131,7 @@ max_retries: 3
 
 #### 08-env-var-substitution-in-config-files
 
-When a YAML config file contains a value that MUST NOT be committed (such as a real endpoint URL, a username, or any other environment-specific value), that value must be expressed as an environment variable reference using `${VAR_NAME}` syntax, and the actual value must be defined in `.env`.
+When a YAML config file contains a value that MUST NOT be committed (such as a real endpoint URL, a username, or any other environment-specific value), that value MUST be expressed as an environment variable reference using `${VAR_NAME}` syntax, and the actual value MUST be defined in `.env`.
 
 This keeps the YAML file committable while keeping the environment-specific value out of the repository.
 
@@ -148,11 +148,11 @@ openapi_endpoint: ${OPENAPI_ENDPOINT}
 log_level: debug
 ```
 
-The `.env` file must be loaded in the Makefile before launching the process (see rule 05) so the variable is available when the CLI or process reads the config file.
+The `.env` file MUST be loaded in the Makefile before launching the process (see rule 05) so the variable is available when the CLI or process reads the config file.
 
 ## References
 
-- [agentme-edr-022](../application/022-secrets-management.md) - Secrets must use OS keychains or cloud secret managers, not `.env` files
-- [agentme-edr-017](017-tool-execution-and-scripting.md) - Makefiles are the authoritative command entry point; rule 05 above integrates with that standard
-- [agentme-edr-008](008-common-targets.md) - Standard Makefile target names
-- [agentme-edr-015](../application/015-cli-tool-standards.md) - CLI config file discovery and CLI-to-application separation
+- [agentme-edr-124](../application/124-secrets-management.md) - Secrets must use OS keychains or cloud secret managers, not `.env` files
+- [agentme-edr-304](304-tool-execution-and-scripting.md) - Makefiles are the authoritative command entry point; rule 05 above integrates with that standard
+- [agentme-edr-303](303-common-targets.md) - Standard Makefile target names
+- [agentme-edr-104](../application/104-cli-tool-standards.md) - CLI config file discovery and CLI-to-application separation

package/.xdrs/agentme/edrs/platform/skills/{002-monorepo-setup → 053-monorepo-setup}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: 002-monorepo-setup
+name: 053-monorepo-setup
 description: >
   Step-by-step instructions for setting up and scaffolding a new monorepo following the standard
   layout, naming conventions, Makefiles, Mise tooling, and README requirements defined in
-  agentme-edr-005. Activate this skill when the user asks to create, initialize, or set up a
+  agentme-edr-301. Activate this skill when the user asks to create, initialize, or set up a
   monorepo, add a new application or module to an existing monorepo, or verify that a monorepo
   complies with the standard structure.
 metadata:
@@ -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-301](../../301-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-301](../../301-monorepo-structure.md), [agentme-edr-502](../../../governance/502-contributing-guide-requirements.md), [agentme-edr-016](../../../principles/016-cross-language-module-structure.md)
 
 ## Instructions