agentme 0.36.0 → 0.37.0

package/.filedist-package.yml

@@ -14,7 +14,7 @@ sets:
 
   - selector:
       files:
-        - .xdrs/agentme/edrs/application/skills/010-select-relevant-xdrs/**
+        - .xdrs/agentme/edrs/application/skills/select-relevant-xdrs/**
     output:
       path: .
       gitignore: false

package/.xdrs/agentme/bdrs/index.md

@@ -14,7 +14,8 @@ Organisational structure, team topology, and strategic alignment concepts.
 
 Project management workflow and structure for development teams.
 
-- [agentme-bdr-401](operations/401-epic-feature-story-planning.md) - **Epic / Feature / User Story planning** — Organize development work as epics, features, and user stories using XDRS initiative documents
+- [agentme-bdr-401](operations/401-plan-epic-feature-story.md) - **Epic / Feature / User Story planning** — Organize development work as epics, features, and user stories using XDRS initiative documents
 - [agentme-bdr-402](operations/402-digital-product-roles.md) - **Digital product roles — organisation & cross-team** — Defines team purpose, workforce allocation, roles overview, and org-level and cross-team roles (PM, Principal Engineer, Solution Architect)
 - [agentme-bdr-403](operations/403-product-team-composition.md) - **Product team composition** — Defines team composition models, squad structure, squad dynamics, and known structural gaps for Product Teams
 - [agentme-bdr-404](operations/404-team-roles-and-specialists.md) - **Digital product roles — team & specialists** — Defines team-level roles (PO, PjM, BA, AI BA, AI Lead, AI Engineer, Tech Lead, engineers) and shared specialist roles
+- [agentme-bdr-405](operations/405-digital-product-roles-raci.md) - **Digital product roles — RACI** — Defines a RACI matrix assigning decision rights across the digital-product lifecycle, from team formation through outcome measurement

package/.xdrs/agentme/bdrs/operations/{401-epic-feature-story-planning.md → 401-plan-epic-feature-story.md}

@@ -131,7 +131,7 @@ A user story that lacks enough detail to begin architecture, planning, or implem
 
 #### 06-refinement-workflow
 
-Stories MUST be refined using the `151-refine-user-story` skill. The skill:
+Stories MUST be refined using the `refine-user-story` skill. The skill:
 - Detects active epic initiative documents and lists pending stories for selection.
 - MUST run a structured 10-phase refinement process including interface/integration spec discovery.
 - MUST write the resulting detail file and update the key task link in the initiative's Milestone.
@@ -156,4 +156,4 @@ Epics SHOULD be connected to one or more Tactical OKRs from `agentme-bdr-002` th
 
 - [`_core-adr-policy-007`](../../../_core/adrs/principles/007-initiative-standards.md) — Initiative document standards: structure, lifecycle, and Milestone template
 - [`agentme-bdr-002`](../principles/002-okr-framework.md) — OKR framework: Tactical OKR definition and epic connection rule
-- [`agentme-edr-skill-151`](../../edrs/principles/skills/151-refine-user-story/SKILL.md) — Refine user story skill: structured refinement workflow that produces output following this policy
+- [`refine-user-story`](../../edrs/principles/skills/refine-user-story/SKILL.md) — Refine user story skill: structured refinement workflow that produces output following this policy

package/.xdrs/agentme/bdrs/operations/402-digital-product-roles.md

@@ -60,6 +60,7 @@ All roles MUST be filled by a person with the required hard skills. Organisation
 | Solution Architect | Cross-team | What |
 | Product Owner (PO) | Team | What / When |
 | Project Manager (PjM) | Team | When / How |
+| Engineering Manager (EM) | Team | Who |
 | Business Analyst (BA) | Team / Squad | What / How |
 | AI Business Analyst (AI BA) | Team / Squad | What / How |
 | AI Lead | Team / Squad | How / When |
@@ -80,12 +81,13 @@ The following roles operate at the organisation level (Group, Company, or Busine
 
 *Purpose*: Own the product direction for the organisation — defining what to build and why — and translate strategic objectives into Tactical OKRs that product teams execute.
 
-*Responsibilities*:
-- Translate Strategic OKRs (set at Group, Company, or Business Unit level) into Tactical OKRs for quarterly execution
-- Prioritise Epics across product teams to maximise contribution to Tactical OKRs
-- Communicate Tactical OKRs and Epic priorities to Product Owners (POs) so teams can execute against them; the PO is the primary recipient of this direction and executes it within the team
-- Maintain visibility into the product portfolio and adjust priorities as market or business conditions change
-- Own the product roadmap and communicate it to stakeholders
+*Accountability*: Tactical OKR translation, epic prioritisation, and business case/ROI justification; Vendor/third-party selection, contract, and SLA negotiation; Tactical OKR fulfillment reporting to the organisation; OKR cycle retrospective, learnings capture, and unfulfilled-OKR review
+
+*Responsibilities*: Strategic OKR fulfillment review (multi-quarter or annual)
+
+*Consulted on*: Workforce planning and capacity allocation; Strategic direction and OKR setting; Epic definition, backlog scoping/acceptance, and ongoing scope change management; Complex or high-risk stakeholder and issue/risk (RAID) management; Service or system deprecation decision; Engineering standards, platforms, and AI-practice governance
+
+*Informed about*: Team health, psychological safety, and retention; Workforce-allocation enforcement (the split defined in `agentme-bdr-402`) and team-building/morale; Cross-team technical emergency declaration and mobilization
 
 *Authority*: The PM owns WHAT the organisation builds at the portfolio level and WHEN Tactical OKRs are set. The PM does NOT own day-to-day team decisions — those remain with each team's Product Owner and Tech Lead. The PM does NOT set engineering practices or platform choices — those are owned by the Principal Engineer.
 
@@ -101,13 +103,9 @@ The following roles operate at the organisation level (Group, Company, or Busine
 
 *Purpose*: Own the HOW across all product teams — engineering practices, tooling standards, platform choices, and AI practices — and synthesise them into a blueprint that leads can apply.
 
-*Responsibilities*:
-- Define and maintain engineering standards across all product teams (coding practices, testing, CI/CD, observability)
-- Select and standardise platforms and tooling used by teams
-- Shape AI engineering practices and the adoption of AI-assisted development
-- Connect architecture decisions, business requirements, and standardised platforms into a coherent engineering blueprint
-- Mentor Tech Leads and AI Leads on standards and practices
-- Connect with Product Manager (PM), Project Manager (PjM), Solution Architects, and team leads to translate, converge, and align the technological landscape, standards, and processes
+*Accountability*: Engineering standards, platforms, and AI-practice governance; Cross-team technical emergency declaration and mobilization
+
+*Consulted on*: Non-functional requirements sign-off (performance, accessibility, availability/reliability, security, privacy-by-design, including third-party assessment); AI model evaluation, safety, and fairness testing; Dependency and license compliance; Ongoing operational governance (cost/FinOps, security review cadence and access audits, DR/business-continuity drills, vendor/SLA performance monitoring)
 
 *Soft skills*: Technical leadership, communication across skill levels, systems thinking, mentoring, cross-team influence — a nexialist connecting engineering, management, architecture, platforms, and product
 
@@ -121,12 +119,9 @@ The following roles operate at the organisation level (Group, Company, or Busine
 
 *Purpose*: Define the architecture for solutions that require new cross-system standards, new platforms, integrations with external systems, or significant security and compliance concerns.
 
-*Responsibilities*:
-- Design architectural solutions for Epics or initiatives that span multiple systems or teams
-- Define new integration patterns, platform adoptions, and cross-system standards when existing standards do not cover the need
-- Produce architectural blueprints that Tech Leads and AI Leads can implement within their teams
-- Assess security, compliance, and risk dimensions of proposed architectures
-- Ensure architectural consistency across product teams within the domain
+*Accountability*: Architecture blueprint (cross-system)
+
+*Consulted on*: Vendor/third-party selection, contract, and SLA negotiation; Epic definition, backlog scoping/acceptance, and ongoing scope change management; Initial compliance/privacy/risk triage, including breach-notification escalation; Cross-team dependency tracking and schedule/milestone reporting; Non-functional requirements sign-off (performance, accessibility, availability/reliability, security, privacy-by-design, including third-party assessment); Cross-team shared-component ownership; Rollback decision authority; Engineering standards, platforms, and AI-practice governance
 
 *Soft skills*: Holistic thinking, stakeholder communication, structured documentation, facilitation, ability to balance pragmatism with rigour
 
@@ -147,3 +142,4 @@ Team-level and specialist roles are defined in [`agentme-bdr-404`](404-team-role
 - [`agentme-bdr-003`](../principles/003-product-delivery-value-flow.md) — Product delivery value flow: end-to-end chain from Strategic OKRs to fulfilled Tactical OKRs
 - [`agentme-bdr-403`](403-product-team-composition.md) — Team composition models, squad dynamics, and known structural gaps
 - [`agentme-bdr-404`](404-team-roles-and-specialists.md) — Team-level roles and specialists: PO, PjM, BA, AI BA, AI Lead, AI Engineer, Tech Lead, engineers, and specialists
+- [`agentme-bdr-405`](405-digital-product-roles-raci.md) — RACI matrix assigning decision rights across the digital-product lifecycle for the roles defined here

package/.xdrs/agentme/bdrs/operations/403-product-team-composition.md

@@ -34,6 +34,7 @@ A team with a bounded product scope and limited AI surface MUST operate as a sim
 | Product Owner | 1 | |
 | Business Analyst or AI BA | 1 | |
 | Tech Lead | 1 | |
+| Engineering Manager | 0–1 | MAY be collapsed into the PO or Tech Lead in small teams |
 | Engineer | 1–2 | Any sub-type from `agentme-bdr-404` (Backend, Frontend, DevOps/Infra, Full Stack) |
 | AI Engineer (if AI work exists) | 0–1 | |
 
@@ -48,6 +49,7 @@ A team with a broad product scope or significant AI surface MUST operate with in
 | Product Owner | 1 | Shared across all squads |
 | Tech Lead | 1 | Shared across all squads |
 | AI Lead | 1 | Shared across all squads |
+| Engineering Manager | 1 | Shared across all squads |
 | Squad | 3 | See squad composition below |
 
 **Squad composition** (per squad):
@@ -100,3 +102,4 @@ Teams MUST be aware of the following structural gaps and MUST apply the recommen
 - [`_core-adr-policy-017`](../../../_core/adrs/principles/017-policy-numbering-ranges.md) — Policy numbering: BDR operations block 401–500
 - [`agentme-bdr-402`](402-digital-product-roles.md) — Digital product roles (org & cross-team): PM, Principal Engineer, and Solution Architect definitions
 - [`agentme-bdr-404`](404-team-roles-and-specialists.md) — Digital product roles (team & specialists): role definitions for all team-level roles and specialists referenced in this policy
+- [`agentme-bdr-405`](405-digital-product-roles-raci.md) — RACI matrix assigning decision rights across the digital-product lifecycle, including role-collapsing rules for Simple teams

package/.xdrs/agentme/bdrs/operations/404-team-roles-and-specialists.md

@@ -1,6 +1,6 @@
 ---
 name: agentme-bdr-policy-404-digital-product-roles-team-specialists
-description: Defines team-level roles and specialist roles — Product Owner, Project Manager, Business Analyst, AI Business Analyst, AI Lead, AI Engineer, Tech Lead, Backend Engineer, Frontend Engineer, DevOps/Infra Engineer, Full Stack Engineer, and shared specialists. Use when staffing, onboarding, or assigning responsibilities within a product team.
+description: Defines team-level roles and specialist roles — Product Owner, Project Manager, Engineering Manager, Business Analyst, AI Business Analyst, AI Lead, AI Engineer, Tech Lead, Backend Engineer, Frontend Engineer, DevOps/Infra Engineer, Full Stack Engineer, and shared specialists. Use when staffing, onboarding, or assigning responsibilities within a product team.
 apply-to: All roles that belong to or support a product team
 valid-from: 2026-08-30
 ---
@@ -29,13 +29,11 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Own the product vision for the team's scope, define sprint goals, and ensure team priorities align with broader OKRs.
 
-*Responsibilities*:
-- Define and maintain the product vision for the team
-- Set sprint goals and prioritise the team backlog
-- Align team-level OKRs with Product Manager direction and execute against Tactical OKRs set by the PM
-- Define and track Operational OKRs for the team's day-to-day execution, when applicable
-- Accept or reject completed work against acceptance criteria
-- Communicate product direction to stakeholders and team members
+*Accountability*: Workforce-allocation enforcement (the split defined in `agentme-bdr-402`) and team-building/morale; Epic definition, backlog scoping/acceptance, and ongoing scope change management; Initial compliance/privacy/risk triage, including breach-notification escalation; UX and interaction design; Production readiness and go-live approval; Release/rollout communication and user-facing documentation, including deprecation and sunset notices; Service or system deprecation decision; Team-level outcome measurement (Operational OKRs)
+
+*Consulted on*: Vendor/third-party selection, contract, and SLA negotiation; Complex or high-risk stakeholder and issue/risk (RAID) management; Business metrics instrumentation and tracking
+
+*Informed about*: Tactical OKR translation, epic prioritisation, and business case/ROI justification
 
 *Shared across squads*: Yes — the PO connects to all squads in the team.
 
@@ -51,12 +49,9 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Own stakeholder management, reporting, and cross-team coordination. Proactively unblock the team by connecting priorities and people across organisational boundaries.
 
-*Responsibilities*:
-- Manage relationships with external stakeholders and report on progress
-- Identify and resolve cross-team dependencies and scheduling conflicts before they block delivery
-- Coordinate cross-squad dependencies within the team
-- Track risks, assumptions, issues, and dependencies (RAID)
-- Facilitate communication between the team and external parties
+*Accountability*: Cross-team dependency tracking and schedule/milestone reporting; Complex or high-risk stakeholder and issue/risk (RAID) management
+
+*Consulted on*: Rollback decision authority; Cross-team technical emergency declaration and mobilization; Engineering standards, platforms, and AI-practice governance
 
 *Authority*: No authority over technical or product decisions. Facilitates and connects; does not override PO or Tech Lead decisions.
 
@@ -68,16 +63,33 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 ---
 
+**Engineering Manager (EM)**
+
+*Purpose*: Own the people and workforce dimension of the team — hiring, career growth, and team health — so the team has the right people, growing in the right direction, at sustainable capacity.
+
+*Accountability*: Hiring, onboarding, and offboarding; Performance management, career growth, and compensation/promotion; Workforce planning and capacity allocation; Team health, psychological safety, and retention; On-call scheduling and compensation
+
+*Consulted on*: Workforce-allocation enforcement (the split defined in `agentme-bdr-402`) and team-building/morale
+
+*Disambiguation*: Unlike the Tech Lead, the Engineering Manager does not own technical direction or code mentoring — only people/HR accountability. Unlike the PjM, the Engineering Manager has no delivery-coordination or stakeholder-facing responsibility — only people authority.
+
+*Shared across squads*: Yes — the Engineering Manager connects to all squads in the team, at the same granularity as the PO, Tech Lead, and AI Lead. In smaller organisations, one Engineering Manager MAY cover multiple teams.
+
+*Soft skills*: Empathy, active listening, coaching, conflict resolution, negotiation, organisational awareness
+
+*Hard skills*: Performance management frameworks, compensation benchmarking, hiring and interviewing, workforce capacity planning, on-call rotation management
+
+*Common activities*: 1:1s, hiring interviews and debriefs, performance and promotion cycles, capacity planning sessions, onboarding/offboarding, on-call schedule management
+
+---
+
 **Business Analyst (BA)**
 
 *Purpose*: Understand what needs to be built and translate business problems into clear, implementable requirements for non-AI features and processes.
 
-*Responsibilities*:
-- Research business problems through stakeholder interviews, process observation, and analysis — focusing on changes to processes and systems that contribute to Tactical OKR objectives
-- Model as-is and design to-be business processes
-- Define system requirements at requirement level: data inputs/outputs, business rules, human interactions, and external dependencies
-- Write user stories and acceptance criteria at a level implementable within a few days
-- Support engineers during implementation by clarifying requirements
+*Accountability*: Requirements and user stories (non-AI); Business metrics instrumentation and tracking
+
+*Consulted on*: Feature or model implementation, including migration, cutover, and legacy decommissioning build work
 
 *Squad assignment*: Ideally one BA per squad, working ahead on upcoming features while available for in-sprint requirement clarification. May move between squads when demand shifts (self-organised with PO awareness).
 
@@ -93,20 +105,15 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Define what needs to be built for AI-powered solutions by translating business needs into clear, implementable AI requirements — covering workflows, agents, models, integrations, controls, and test criteria.
 
-*Responsibilities*:
-- Research business problems through analysis, stakeholder interviews, and process discovery
-- Design target business processes, AI workflows, agents, models, and required system integrations
-- Identify AI opportunities, risks, controls, and regulatory requirements
-- Define data inputs, outputs, business rules, human interactions, and external dependencies for AI systems
-- Specify which models, agents, and workflows need to be implemented, and the detailed input/output of all internal and external systems involved
-- Create detailed user stories and acceptance criteria that engineers can implement within a few days
-- Define test and evaluation requirements for AI systems
+*Accountability*: AI opportunity discovery; Requirements and user stories (AI)
+
+*Consulted on*: Feature or model implementation, including migration, cutover, and legacy decommissioning build work; AI model evaluation, safety, and fairness testing
 
 *Research boundary*: The AI BA researches business problems, requirements, and AI opportunities before implementation begins. The AI Engineer researches technical approaches, model selection, data characteristics, and evaluation methods during implementation. These boundaries must not blur.
 
 *Squad assignment*: Same mobility rules as BA. AI BA and BA may exchange squad positions depending on which phase the squad is in and whether AI or non-AI features dominate.
 
-*Accountability*: The AI BA owns WHAT is required — business requirements, AI workflows, data definitions, controls, and acceptance criteria. Engineering teams own HOW the solution is implemented, including architecture, technology choices, infrastructure, security, and deployment.
+*Authority*: The AI BA owns WHAT is required — business requirements, AI workflows, data definitions, controls, and acceptance criteria. Engineering teams own HOW the solution is implemented, including architecture, technology choices, infrastructure, security, and deployment.
 
 *Deliverables*: Business and AI requirements, process and workflow designs, AI agent and model specifications, integration and data requirements, risk and control assessments, test and evaluation requirements for AI systems, epics, features, and user stories
 
@@ -122,13 +129,11 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Own the technical design of AI implementations within the team — architectures, platforms, implementation order, and output quality standards — and develop AI engineers through mentoring and pairing.
 
-*Responsibilities*:
-- Design the technical architecture for tests, models, agents, and workflows
-- Define implementation platforms and tooling for AI development
-- Sequence AI implementation work and define quality and monitoring standards for AI outputs
-- Refine user stories related to AI development with sufficient technical detail
-- Mentor AI Engineers through pairing, code review, and knowledge sharing
-- Co-design integrated features with Tech Lead (tiebreaker on AI component decisions)
+*Accountability*: Technical refinement (AI); Non-functional requirements sign-off (AI); Feature or model implementation, including migration, cutover, and legacy decommissioning build work (AI); Code or model review (AI); Independent QA and test execution (AI); AI model evaluation, safety, and fairness testing; Production monitoring, alerting, incident response, and post-incident review, including proactive remediation of disclosed vulnerabilities (AI)
+
+*Responsibilities*: Hiring, onboarding, and offboarding (technical ramp-up portion)
+
+*Consulted on*: Cross-team dependency tracking and schedule/milestone reporting (AI); Production readiness and go-live approval; Cross-team technical emergency declaration and mobilization; Engineering standards, platforms, and AI-practice governance
 
 *Shared across squads*: Yes — the AI Lead connects to all squads in the team.
 
@@ -144,12 +149,7 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Implement AI components — tests, models, agents, and workflows — according to the technical design provided by the AI Lead.
 
-*Responsibilities*:
-- Implement models, agents, and AI workflows to specification
-- Build evaluations (evals), regression tests, and datasets for AI systems
-- Research technical approaches, model selection, data characteristics, and evaluation methods during implementation (not business requirements — that is AI BA scope)
-- Perform data analysis to support model development and evaluation
-- Raise technical blockers and edge cases to the AI Lead
+*Responsibilities*: Feature or model implementation, including migration, cutover, and legacy decommissioning build work; AI model evaluation, safety, and fairness testing
 
 *Soft skills*: Curiosity, structured problem-solving, willingness to experiment and discard, attention to evaluation rigour
 
@@ -163,15 +163,11 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Own the technical design of non-AI implementations — services, choreographers, web pages, app pages, CI/CD, monitoring, and incident procedures — and develop engineers through mentoring and pairing.
 
-*Responsibilities*:
-- Design technical architecture for services, choreographers, web pages, and mobile app pages
-- Define monitoring, alerting, and Change Management procedures integrated with CI/CD
-- Define and maintain Incident Management procedures
-- Sequence engineering implementation work
-- Refine user stories related to engineering with sufficient technical detail
-- Mentor Engineers through pairing, code review, and knowledge sharing
-- Co-design integrated features with AI Lead (tiebreaker on system boundary decisions)
-- Escalate to Solution Architect when an Epic requires new cross-system standards or integrations; escalate to Principal Engineer when new engineering standards are needed
+*Accountability*: Technical refinement (non-AI); Non-functional requirements sign-off (non-AI); Cross-team shared-component ownership; Feature or model implementation, including migration, cutover, and legacy decommissioning build work (non-AI); Code or model review (non-AI); Independent QA and test execution (non-AI); Dependency and license compliance; CI/CD pipeline and deployment automation; Rollback decision authority; Production monitoring, alerting, incident response, and post-incident review, including proactive remediation of disclosed vulnerabilities (non-AI); Ongoing operational governance (cost/FinOps, security review cadence and access audits, DR/business-continuity drills, vendor/SLA performance monitoring)
+
+*Responsibilities*: Hiring, onboarding, and offboarding (technical ramp-up portion); Workforce-allocation enforcement (the split defined in `agentme-bdr-402`) and team-building/morale
+
+*Consulted on*: Cross-team dependency tracking and schedule/milestone reporting (non-AI); Production readiness and go-live approval; Cross-team technical emergency declaration and mobilization; Business metrics instrumentation and tracking; Architecture blueprint (cross-system); Engineering standards, platforms, and AI-practice governance
 
 *Shared across squads*: Yes — the Tech Lead connects to all squads in the team.
 
@@ -187,12 +183,7 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Implement server-side software components — APIs, business workflows, batch processes, event-driven integrations, and database access layers.
 
-*Responsibilities*:
-- Design and implement RESTful and event-driven APIs
-- Build business logic, workflows, and batch processing components
-- Develop database access layers and manage schema migrations
-- Implement integrations with external systems and third-party services
-- Support incident investigation for backend services
+*Responsibilities*: Feature or model implementation, including migration, cutover, and legacy decommissioning build work; Business metrics instrumentation and tracking
 
 *Hard skills*: Backend languages (Java, Go, Python, Node.js, or equivalent), API design, SQL and NoSQL databases, event-driven systems, containerisation
 
@@ -204,12 +195,7 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Implement user-facing software components — web applications, mobile apps, and UI interactions.
 
-*Responsibilities*:
-- Build web pages, single-page applications, and responsive UI components
-- Implement mobile app screens and navigation flows (where applicable)
-- Integrate frontend with backend APIs and services
-- Ensure accessibility, performance, and cross-browser or cross-platform compatibility
-- Collaborate with UX Designers on interaction and visual design implementation
+*Responsibilities*: Feature or model implementation, including migration, cutover, and legacy decommissioning build work; Business metrics instrumentation and tracking
 
 *Hard skills*: HTML/CSS, modern frontend frameworks (React, Vue, Angular, or equivalent), mobile development (React Native, Flutter, or equivalent where applicable), API integration, browser and mobile performance tooling
 
@@ -221,12 +207,9 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Own the delivery pipeline and cloud infrastructure that enables teams to ship and run software reliably — covering both CI/CD automation and cloud provisioning.
 
-*Responsibilities*:
-- Build and maintain CI/CD pipelines, deployment automation, and release procedures including blue/green deployments and automated rollouts
-- Design and provision cloud infrastructure using templates and infrastructure-as-code blueprints
-- Manage networking, connectivity, certificates, and platform-level security controls
-- Define validation scripts and deployment checks that gate production releases
-- Monitor infrastructure health and respond to platform-level incidents
+*Responsibilities*: CI/CD pipeline and deployment automation; Ongoing operational governance (cost/FinOps, security review cadence and access audits, DR/business-continuity drills, vendor/SLA performance monitoring)
+
+*Consulted on*: Production readiness and go-live approval
 
 *Hard skills*: CI/CD tooling (GitHub Actions, GitLab CI, or equivalent), cloud platforms (AWS, Azure, GCP, or equivalent), infrastructure-as-code (Terraform, Pulumi, or equivalent), containerisation and orchestration (Docker, Kubernetes), networking fundamentals
 
@@ -238,12 +221,7 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 *Purpose*: Implement non-AI software components across the full stack — APIs, workflows, web pages, mobile apps, CI/CD pipelines, database access, and event-based flows. Suited to teams and contexts where frontend and backend work are tightly coupled or where a generalist profile is preferred over specialisation.
 
-*Responsibilities*:
-- Implement services, APIs, database access layers, event-based flows, and non-AI workflows
-- Build and maintain CI/CD pipelines
-- Implement web pages, mobile app screens, and frontend components
-- Write and maintain scripts and automation for platform and operational needs
-- Support AI Engineers with software engineering knowledge gaps (e.g., API integration, data pipelines, infrastructure)
+*Responsibilities*: Feature or model implementation, including migration, cutover, and legacy decommissioning build work; Business metrics instrumentation and tracking
 
 *Soft skills*: Breadth of technical knowledge, pragmatism, collaborative problem-solving, ownership of delivered quality
 
@@ -255,13 +233,13 @@ The following roles MUST belong to a product team. Some roles are shared across
 
 Specialists are professionals with focused domain expertise who contribute to specific phases of product delivery. They MAY be shared across multiple product teams or embedded within a specific team when the scope or duration of work justifies it. Teams SHOULD plan specialist involvement proactively — engaging them ahead of the phases where their input is needed rather than reactively.
 
-| Specialist | Purpose | Typical engagement |
-|---|---|---|
-| UX Designer | Design user interactions, information architecture, and visual language for user-facing features | Embedded for user-facing feature phases; shared otherwise |
-| Tester / QA Specialist | Define test strategies, execute exploratory and structured testing, and validate acceptance criteria beyond automated test coverage | Embedded during high-complexity delivery phases; shared for periodic quality reviews |
-| Communication Specialist | Author internal and external communications, release announcements, and user-facing documentation | Shared; engaged at release and major milestone points |
-| Journalist / Technical Writer | Produce structured content — user guides, API documentation, internal knowledge bases | Shared or embedded when documentation volume is significant |
-| Business SME (Subject Matter Expert) | Validate requirements and processes against business domain knowledge; bridge between business stakeholders and product teams | Shared; engaged during requirements and validation phases |
+| Specialist | Purpose | Typical engagement | RACI (`agentme-bdr-405`) |
+|---|---|---|---|
+| UX Designer | Design user interactions, information architecture, and visual language for user-facing features | Embedded for user-facing feature phases; shared otherwise | Responsible: UX and interaction design |
+| Tester / QA Specialist | Define test strategies, execute exploratory and structured testing, and validate acceptance criteria beyond automated test coverage | Embedded during high-complexity delivery phases; shared for periodic quality reviews | Responsible: Independent QA and test execution; AI model evaluation, safety, and fairness testing |
+| Communication Specialist | Author internal and external communications, release announcements, and user-facing documentation | Shared; engaged at release and major milestone points | Responsible: Release/rollout communication and user-facing documentation, including deprecation and sunset notices |
+| Journalist / Technical Writer | Produce structured content — user guides, API documentation, internal knowledge bases | Shared or embedded when documentation volume is significant | Responsible: Release/rollout communication and user-facing documentation, including deprecation and sunset notices |
+| Business SME (Subject Matter Expert) | Validate requirements and processes against business domain knowledge; bridge between business stakeholders and product teams | Shared; engaged during requirements and validation phases | Consulted: Initial compliance/privacy/risk triage, including breach-notification escalation; Requirements and user stories |
 
 ## References
 
@@ -272,3 +250,4 @@ Specialists are professionals with focused domain expertise who contribute to sp
 - [`agentme-bdr-003`](../principles/003-product-delivery-value-flow.md) — Product delivery value flow: end-to-end chain from Strategic OKRs to fulfilled Tactical OKRs
 - [`agentme-bdr-402`](402-digital-product-roles.md) — Digital product roles (org & cross-team): PM, Principal Engineer, Solution Architect, and team structure context
 - [`agentme-bdr-403`](403-product-team-composition.md) — Team composition models, squad dynamics, and known structural gaps
+- [`agentme-bdr-405`](405-digital-product-roles-raci.md) — RACI matrix assigning decision rights across the digital-product lifecycle for the roles defined here

package/.xdrs/agentme/bdrs/operations/405-digital-product-roles-raci.md

@@ -0,0 +1,131 @@
+---
+name: agentme-bdr-policy-405-digital-product-roles-raci
+description: Defines a RACI (Responsible, Accountable, Consulted, Informed) matrix assigning decision rights across the digital-product lifecycle, from team formation through outcome measurement. Use when clarifying who owns a decision, resolving accountability ambiguity, or tracing root cause after a delivery or business-outcome failure.
+apply-to: All digital product teams and the roles defined in agentme-bdr-402, agentme-bdr-403, and agentme-bdr-404
+valid-from: 2026-09-18
+---
+
+# agentme-bdr-policy-405: Digital product roles — RACI
+
+## Context and Problem Statement
+
+`agentme-bdr-401` through `agentme-bdr-404` define roles, team composition, and organisational structure, but no policy assigns explicit decision rights across the product lifecycle. Activities such as workforce planning, vendor selection, and on-call ownership have no named Accountable owner, leaving ambiguity during execution and when tracing failure to its cause.
+
+Question: Who is Accountable, Responsible, Consulted, and Informed for each activity across the digital-product lifecycle, from team formation to outcome measurement?
+
+## Decision Outcome
+
+**A RACI matrix covering the full digital-product lifecycle, with exactly one Accountable role per activity**
+
+Activities are grouped into six lifecycle stages, ordered as they occur end to end:
+
+| Lifecycle group | Activities | Main Accountable role(s) |
+|---|---|---|
+| Team formation & enablement | 5 | Engineering Manager (4), Product Owner (1) |
+| Discover | 8 | Product Manager (3), Product Owner (2), Project Manager (2), AI Business Analyst (1) |
+| Design | 7 | Tech Lead / AI Lead (3), Product Owner (1), Solution Architect (1), designated Tech Lead (1), Principal Engineer (1) |
+| Implement | 5 | Tech Lead / AI Lead (4), AI Lead (1) |
+| Deliver | 4 | Tech Lead (2), Product Owner (2) |
+| Operate | 10 | Product Manager (3), Product Owner (3), Tech Lead / AI Lead (2), Engineering Manager (1), Principal Engineer (1) |
+
+The single RACI matrix in rule `10-raci-activity-matrix` below gives the full per-activity Responsible, Accountable, Consulted, and Informed assignments.
+
+### Details
+
+#### 01-raci-definitions
+
+Accountable (A) MUST ensure an activity is done and done correctly, answering for its success or failure; exactly one role holds it per activity — e.g., the Tech Lead is Accountable for code review quality. Responsible (R) performs the task, under the Accountable role's direction and normally in a tight, continuous communication loop with it — e.g., Engineers are Responsible for implementation under the Tech Lead. Consulted (C) MUST participate in the design or decision process before it is finalised, typically a cross-team or org-level role with broad hands-on experience — e.g., the Solution Architect is Consulted on cross-system architecture. Informed (I) MUST receive the resulting reports or information to act on when needed, without shaping the decision; Informed MAY extend to business stakeholders outside this roster (Sales, Finance, executives) even when untracked as a column — e.g., the PM is Informed of production incidents that affect business KPIs.
+
+#### 02-exactly-one-accountable-per-activity
+
+Each activity in this policy MUST have exactly one Accountable role — never zero, never more than one. When an existing decision elsewhere in this scope assigns joint accountability to two roles for one activity, it MUST be split into two separate activities, each with its own single Accountable role, as this policy does with `agentme-bdr-003`'s outcome-measurement stage (split into Team-level outcome measurement, Accountable: PO, and Tactical OKR fulfillment reporting, Accountable: PM; see rule `10-raci-activity-matrix`).
+
+#### 03-accountable-role-must-ensure-communication
+
+The Accountable role for an activity MUST ensure its decision or outcome is actively communicated to, and confirmed understood by, that activity's Responsible, Consulted, and Informed roles — especially across time-zone, distributed, or vendor boundaries where asynchronous handoffs are common. A decision that is correct but not effectively communicated to the people executing it MUST be treated as an accountability failure of the Accountable role. Any role SHOULD escalate suspected misalignment rather than silently proceed on possibly outdated information.
+
+#### 04-accountability-network-and-root-cause-tracing
+
+Activities are interdependent: the Accountable role for a failing activity MAY itself depend on another Accountable role's output from an earlier activity. When reviewing a failure — for example, poor business results traced to poor software quality traced to disorganised engineering work — reviewers MUST trace the chain through each activity's Accountable role until reaching the true root cause, rather than stopping at the first or most visible role. Root-cause tracing MUST exclude external or market factors (e.g., recession, competitor action, seasonality) that no role in this roster controls; when a shortfall is due to an irreducible external factor, the Accountable role must actively manage, escalate, or re-scope the risk, not prevent it.
+
+#### 05-role-collapsing-and-conditional-activities
+
+One person MAY hold more than one role concurrently — for example, the same person acting as PO and Tech Lead in a Simple team per `agentme-bdr-403`. The RACI assignment still attaches to the role, not the individual, and each accountability MUST be reasoned about separately even when one person holds both. On small projects without a dedicated PjM, the PjM's activities in this policy MUST collapse onto the PO by default. An activity MUST only be applied when its triggering condition is present (e.g., cross-team scope, AI involvement, or regulatory/vendor context); rigor of execution SHOULD scale with risk rather than with project size alone.
+
+#### 06-accountable-is-not-necessarily-the-executor
+
+The Accountable role MUST ensure an activity happens correctly, but is not required to personally execute it. For example, in a two-person team the Tech Lead remains Accountable for code review occurring even when the reviewer, by necessity, is a peer without the Tech Lead title.
+
+#### 07-scope-boundary
+
+This matrix MUST only be used for activities delivered as a digital-product or feature change. A business objective achieved partly or wholly through non-digital-product levers — marketing, pricing, sales incentives, or partnerships — MUST have its accountability owned outside this role roster entirely. Formal regulatory or legal sign-off in a regulated environment likewise sits outside this roster: the Solution Architect and PO remain Accountable for designing to, and including, known compliance requirements, but the approval authority itself (Compliance Officer, Legal, Risk) MUST be Consulted before milestones and Informed of changes, and MUST NOT be treated as an Accountable column in this matrix. The same boundary applies to vendor contract signing and legal terms following the PM's vendor-selection activity in rule `10-raci-activity-matrix`.
+
+#### 08-multi-team-application
+
+Activities MUST be applied per contributing team so that exactly one Accountable role exists per activity even when a Strategic Objective spans many teams: each team's PO remains Accountable for its own epic slice, the PM MUST be the single aggregation point for Tactical OKR fulfillment across teams, and the PjM (or PO, per rule `05-role-collapsing-and-conditional-activities`) MUST be the single cross-team dependency coordinator.
+
+#### 09-role-abbreviations
+
+Activities below use the roles defined in `agentme-bdr-402` and `agentme-bdr-404`: PM (Product Manager), PO (Product Owner), PjM (Project Manager), EM (Engineering Manager), BA (Business Analyst), AI BA (AI Business Analyst). Engineers MUST be read as one grouped column spanning the Backend, Frontend, and Full Stack Engineer sub-types defined in `agentme-bdr-404`; DevOps/Infra Engineer and AI Engineer remain distinct columns. Specialists MUST be read as one grouped column spanning the UX Designer, Tester/QA, Communication, Technical Writer, and Business SME specialist roles defined in `agentme-bdr-404`.
+
+#### 10-raci-activity-matrix
+
+Every activity MUST have exactly one Accountable role, per rule `02-exactly-one-accountable-per-activity`. The matrix below assigns Responsible, Accountable, Consulted, and Informed roles to all 39 activities, ordered top-to-bottom by the natural workflow across the six lifecycle groups: team formation & enablement, Discover, Design, Implement, Deliver, and Operate.
+
+| Group | Activity | PM | PO | PjM | EM | BA | AI BA | Solution Architect | Tech Lead | AI Lead | Principal Engineer | Engineers | AI Engineer | DevOps/Infra Engineer | Specialists |
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+| Team formation & enablement | Hiring, onboarding, and offboarding | | | | A | | | | R | R | | | | | |
+| Team formation & enablement | Performance management, career growth, and compensation/promotion | | | | A | | | | | | | | | | |
+| Team formation & enablement | Workforce planning and capacity allocation | C | | | A | | | | | | | | | | |
+| Team formation & enablement | Team health, psychological safety, and retention | I | | | A | | | | | | | | | | |
+| Team formation & enablement | Workforce-allocation enforcement (the split defined in `agentme-bdr-402`) and team-building/morale | I | A | | C | | | | R | | | | | | |
+| Discover | Strategic direction and OKR setting¹ | C | | | | | | | | | | | | | |
+| Discover | Tactical OKR translation, epic prioritisation, and business case/ROI justification | A | I | | | | | | | | | | | | |
+| Discover | Vendor/third-party selection, contract, and SLA negotiation | A | C | | | | | C | | | | | | | |
+| Discover | Epic definition, backlog scoping/acceptance, and ongoing scope change management | C | A | | | | | C | | | | | | | |
+| Discover | Initial compliance/privacy/risk triage, including breach-notification escalation | | A | | | | | C | | | | | | | C (Business SME) |
+| Discover | AI opportunity discovery | | | | | | A | | | | | | | | |
+| Discover | Cross-team dependency tracking and schedule/milestone reporting² | | | A | | | | C | | | | | | | |
+| Discover | Complex or high-risk stakeholder and issue/risk (RAID) management | C | C | A | | | | | | | | | | | |
+| Design | Requirements and user stories | | | | | A (non-AI) | A (AI) | | | | | | | | C (Business SME) |
+| Design | Architecture blueprint (cross-system) | | | | | | | A | C | | | | | | |
+| Design | Technical refinement | | | | | | | | A (non-AI) | A (AI) | | | | | |
+| Design | UX and interaction design | | A | | | | | | | | | | | | R (UX Designer) |
+| Design | Non-functional requirements sign-off (performance, accessibility, availability/reliability, security, privacy-by-design, including third-party assessment) | | | | | | | C | A (non-AI) | A (AI) | C | | | | |
+| Design | Cross-team shared-component ownership³ | | | | | | | C | A | | | | | | |
+| Design | Engineering standards, platforms, and AI-practice governance | C | | C | | | | C | C | C | A | | | | |
+| Implement | Feature or model implementation, including migration, cutover, and legacy decommissioning build work | | | | | C | C | | A (non-AI) | A (AI) | | R | R | | |
+| Implement | Code or model review | | | | | | | | A (non-AI) | A (AI) | | | | | |
+| Implement | Independent QA and test execution | | | | | | | | A (non-AI) | A (AI) | | | | | R (Tester/QA) |
+| Implement | AI model evaluation, safety, and fairness testing | | | | | | C | | | A | C | | R | | R (Tester/QA) |
+| Implement | Dependency and license compliance | | | | | | | | A | | C | | | | |
+| Deliver | CI/CD pipeline and deployment automation | | | | | | | | A | | | | | R | |
+| Deliver | Production readiness and go-live approval | | A | | | | | | C | C | | | | C | |
+| Deliver | Rollback decision authority | | | C | | | | C | A | | | | | | |
+| Deliver | Release/rollout communication and user-facing documentation, including deprecation and sunset notices | | A | | | | | | | | | | | | R (Communication/Technical Writer) |
+| Operate | Production monitoring, alerting, incident response, and post-incident review, including proactive remediation of disclosed vulnerabilities | | | | | | | | A (non-AI) | A (AI) | | | | | |
+| Operate | Cross-team technical emergency declaration and mobilization | I | | C | | | | | C | C | A | | | | |
+| Operate | On-call scheduling and compensation | | | | A | | | | | | | | | | |
+| Operate | Ongoing operational governance (cost/FinOps, security review cadence and access audits, DR/business-continuity drills, vendor/SLA performance monitoring) | | | | | | | | A | | C | | | R | |
+| Operate | Service or system deprecation decision | C | A | | | | | | | | | | | | |
+| Operate | Business metrics instrumentation and tracking | | C | | | A | | | C | | | R | | | |
+| Operate | Team-level outcome measurement (Operational OKRs) | | A | | | | | | | | | | | | |
+| Operate | Tactical OKR fulfillment reporting to the organisation | A | | | | | | | | | | | | | |
+| Operate | Strategic OKR fulfillment review (multi-quarter or annual)⁴ | R | | | | | | | | | | | | | |
+| Operate | OKR cycle retrospective, learnings capture, and unfulfilled-OKR review | A | | | | | | | | | | | | | |
+
+¹ Accountable: Group/Company/Business Unit leadership, outside this role roster (see rule `07-scope-boundary`). ² Also Consulted: each contributing team's Tech Lead (non-AI) / AI Lead (AI). ³ Accountable: the shared/platform team's Tech Lead if one exists, otherwise one contributing team's Tech Lead designated by the Solution Architect; other contributing teams' Tech Leads are Informed. ⁴ Accountable: Group/Company/Business Unit leadership, outside this role roster; PM is Responsible for aggregating Tactical OKR results upward.
+
+Tech Lead and AI Lead are Responsible for the technical-ramp-up portion of onboarding; Tech Lead is also Responsible for flagging and protecting technical-debt/operational time on the workforce-allocation-enforcement row. Tech Lead and AI Lead also consult each other on shared (non-AI)/(AI) integration points. Specialist columns (R) apply only when that specialist is engaged on the initiative, per rule `05-role-collapsing-and-conditional-activities`; when not engaged, the Accountable role executes the activity directly.
+
+#### 11-role-description-must-mirror-the-matrix
+
+Each role's Accountability, Responsibilities, Consulted on, and Informed about fields in `agentme-bdr-402` or `agentme-bdr-404` MUST list the same activity names — footnote markers excluded, `(non-AI)`/`(AI)` qualifiers included — as that role's A/R/C/I assignments in rule `10-raci-activity-matrix`. This applies only to roles with a column per rule `09-role-abbreviations`, excluding the Squad Lead (`agentme-bdr-403`, no column) and unnamed Specialists cells. Matrix changes and matching role-field changes MUST ship together; reviewers MUST reject one without the other.
+
+## References
+
+- [`agentme-bdr-401`](401-plan-epic-feature-story.md) — Epic / Feature / User Story planning: structure referenced by the epic-definition activity
+- [`agentme-bdr-402`](402-digital-product-roles.md) — Digital product roles (org & cross-team): PM, Principal Engineer, Solution Architect, and the workforce-allocation split
+- [`agentme-bdr-403`](403-product-team-composition.md) — Team composition models and known structural gaps, including role-collapsing in Simple teams
+- [`agentme-bdr-404`](404-team-roles-and-specialists.md) — Full role definitions for all roles referenced in this matrix, including the Engineering Manager
+- [`agentme-bdr-003`](../principles/003-product-delivery-value-flow.md) — Product delivery value flow: the value chain stages this matrix assigns accountability across

package/.xdrs/agentme/bdrs/principles/002-okr-framework.md

@@ -71,4 +71,4 @@ Operational OKRs track day-to-day execution and business-as-usual (BAU) stabilit
 ## References
 
 - [`agentme-bdr-001`](001-company-organizational-levels.md) — Company organisational levels: Group, Company, and Business Unit definitions
-- [`agentme-bdr-401`](../operations/401-epic-feature-story-planning.md) — Epic / Feature / User Story planning: epic structure and OKR connection rule
+- [`agentme-bdr-401`](../operations/401-plan-epic-feature-story.md) — Epic / Feature / User Story planning: epic structure and OKR connection rule

package/.xdrs/agentme/bdrs/principles/003-product-delivery-value-flow.md

@@ -53,7 +53,7 @@ The delivery value chain consists of the following ordered stages. Each stage MU
 
 **Stage 8 — Production**: Deployments reach production. The product team monitors outcomes against the acceptance criteria defined in User Stories and the Key Results of the Tactical OKRs.
 
-**Stage 9 — Outcome measurement**: The PO and PM review measurable production outcomes against the Tactical OKR Key Results. When Key Results are met, the Tactical OKR is considered fulfilled. Learnings from the cycle inform the next Strategic OKR planning round, closing the feedback loop.
+**Stage 9 — Outcome measurement**: The PO and PM review measurable production outcomes against the Tactical OKR Key Results. When Key Results are met, the Tactical OKR is considered fulfilled. Learnings from the cycle inform the next Strategic OKR planning round, closing the feedback loop. See `agentme-bdr-405` for the accountability split between the PO (team-level outcome measurement) and PM (Tactical OKR fulfillment reporting) at this stage.
 
 #### 03-parallel-support-roles
 
@@ -85,6 +85,7 @@ An unfulfilled Tactical OKR at cycle end MUST be explicitly reviewed — either
 
 - [`agentme-bdr-001`](001-company-organizational-levels.md) — Company organisational levels: Group, Company, and Business Unit definitions
 - [`agentme-bdr-002`](002-okr-framework.md) — OKR framework: Strategic, Tactical, and Operational OKR definitions and rules
-- [`agentme-bdr-401`](../operations/401-epic-feature-story-planning.md) — Epic / Feature / User Story planning: structure and OKR connection rules
+- [`agentme-bdr-401`](../operations/401-plan-epic-feature-story.md) — Epic / Feature / User Story planning: structure and OKR connection rules
 - [`agentme-bdr-402`](../operations/402-digital-product-roles.md) — Digital product roles (org & cross-team): PM, Principal Engineer, and Solution Architect definitions
 - [`agentme-bdr-404`](../operations/404-team-roles-and-specialists.md) — Digital product roles (team & specialists): full role definitions for all team-level roles and specialists referenced in this policy
+- [`agentme-bdr-405`](../operations/405-digital-product-roles-raci.md) — RACI matrix assigning decision rights across the value chain, including the Stage 9 PO/PM accountability split

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

@@ -156,5 +156,5 @@ The examples folder MUST exist for any libraries and utilities that are publishe
 
 - [agentme-edr-122](122-unit-test-requirements.md) — Coverage and unit-test baseline
 - [agentme-edr-126](126-pragmatic-hexagonal-architecture.md) — Internal adapter/application layer separation for applications
-- [050-create-javascript-project](skills/050-create-javascript-project/SKILL.md) — scaffolds a new project following this structure
+- [create-javascript-project](skills/create-javascript-project/SKILL.md) — scaffolds a new project following this structure
 

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

@@ -179,4 +179,4 @@ Use the standard library `flag` package for CLI flags. Each `adapters/cli/<featu
 ## References
 
 - [agentme-edr-126](126-pragmatic-hexagonal-architecture.md) — Defines the adapter/application separation that this layout follows
-- [051-create-golang-project](skills/051-create-golang-project/SKILL.md) — scaffolds a new Go project following this structure
+- [create-golang-project](skills/create-golang-project/SKILL.md) — scaffolds a new Go project following this structure

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

@@ -212,4 +212,4 @@ The root `Makefile` MUST remain the only contract for CI and contributors, in li
 - [agentme-edr-122](122-unit-test-requirements.md) - Coverage and unit-test baseline
 - [agentme-edr-501](../governance/501-project-quality-standards.md) - Examples and quality requirements
 - [agentme-edr-303](../platform/303-common-targets.md) - Standard Makefile target names
-- [052-create-python-project](skills/052-create-python-project/SKILL.md) - Scaffold a project following this EDR
+- [create-python-project](skills/create-python-project/SKILL.md) - Scaffold a project following this EDR

package/.xdrs/agentme/edrs/application/127-external-system-adapter-skills.md

@@ -90,4 +90,6 @@ Adapter skills for a given system benefit from layering so that knowledge at eac
 
 The depth of the hierarchy is discretionary. A simple system may need only a base skill. Complex systems benefit from the full three-layer structure. Higher-level skills SHOULD activate their lower-level dependencies explicitly at the start of their instructions.
 
+As this layered hierarchy grows across many systems, a scope MAY optionally prefix skill folder and `name:` values with a number that encodes category and risk (for example, grouping read-only skills below write skills, and single-system skills below multi-system ones), so skills sort and group at a glance. This is never required — skills default to a plain descriptive name with no numeric prefix — and MUST only be adopted for a new skill after asking the human whether it should be numbered. `agentme`'s own skills intentionally do not use numbering.
+
 When creating adapter skills for a new system, document the chosen integration approach (rule 01) in the skill's frontmatter description, follow the `-connector` naming convention (rule 06) for the base skill, and populate the `## Known Issues` section (rule 07) as experience accumulates. All system-specific adapter skills SHOULD be placed in the `_local` scope of the consuming project.