xdrs-core 0.24.1 → 0.26.0

package/.xdrs/_core/adrs/principles/skills/003-write-skill/SKILL.md

@@ -1,7 +1,7 @@
 ---
-name: 003-write-skill
+name: _core-adr-skill-003-write-skill
 description: >
-  Creates a new skill package following XDR skill standards: determines type, scope, subject, and number;
+  Creates a new skill package following XDRS skill standards: determines type, scope, subject, and number;
   then writes a focused SKILL.md with correct frontmatter, phased instructions, examples, and edge cases.
   Activate this skill when the user asks to create, add, or write a new skill, agent skill, or SKILL.md file.
 metadata:
@@ -11,7 +11,7 @@ metadata:
 
 ## Overview
 
-Guides the creation of a well-structured skill package by following `_core-adr-003` skill standards, consulting `xdr-standards` for every core element definition, checking existing skills to avoid duplication, and producing a complete SKILL.md ready to activate in VS Code.
+Guides the creation of a well-structured skill package by following `_core-adr-policy-003` skill standards, consulting `xdrs-core` for every core element definition, checking existing skills to avoid duplication, and producing a complete SKILL.md ready to activate in VS Code.
 
 ## Instructions
 
@@ -38,21 +38,21 @@ Quick test:
 **Scope** — use `_local` unless the user explicitly names another scope.
 - If the user names a scope other than `_local`, check the workspace root `.filedist` file. If any file under `.xdrs/[scope]/` appears in `.filedist`, the scope is external and new documents MUST NOT be created there. Inform the user and ask them to choose a non-external scope.
 
-**Subject** — pick the most specific match for the chosen type (required list per type is in `_core-adr-001`):
+**Subject** — pick the most specific match for the chosen type (required list per type is in `_core-adr-policy-001`):
 - ADR subjects: `principles`, `application`, `data`, `integration`, `platform`, `controls`, `operations`
 - BDR subjects: `principles`, `marketing`, `product`, `controls`, `operations`, `organization`, `finance`, `sustainability`
 - EDR subjects: `principles`, `application`, `infra`, `observability`, `devops`, `governance`
 
 **Skill number** — scan `.xdrs/[scope]/[type]/[subject]/skills/` for the highest existing number and increment by 1. Never reuse numbers from deleted skills.
 
-**Skill name** — `[number]-[short-kebab-case-description]`, max 64 characters total.
+**Skill name** — `[scope]-[type]-skill-[number]-[short-kebab-case-description]`, max 64 characters total. The directory name is `[number]-[short-kebab-case-description]`.
 
-### Phase 3: Research Existing Skills and Related XDRs
+### Phase 3: Research Existing Skills and Related Policies
 
 1. List `.xdrs/[scope]/[type]/[subject]/skills/` for existing skills. If one already covers the goal, extend or reference it instead of creating a duplicate.
-2. Read all XDRs relevant to the skill's domain to collect rules and cross-references.
-3. Evaluate XDR metadata before operationalizing those rules. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether the decision fits the intended task context, and the decision text defines any remaining boundaries. Keep out-of-window or out-of-scope XDRs as background only.
-4. Decide whether the skill is merely guidance or is being referenced by an XDR as a mandatory procedure. Do not encode policy in the skill unless it comes from a referenced XDR.
+2. Read all Policies relevant to the skill's domain to collect rules and cross-references.
+3. Evaluate Policy metadata before operationalizing those rules. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether the decision fits the intended task context, and the decision text defines any remaining boundaries. Keep out-of-window or out-of-scope Policies as background only.
+4. Decide whether the skill is merely guidance or is being referenced by a Policy as a mandatory procedure. Do not encode policy in the skill unless it comes from a referenced Policy.
 
 ### Phase 4: Write the SKILL.md
 
@@ -60,7 +60,7 @@ Use the mandatory agentskills format:
 
 ```
 ---
-name: [number]-[skill-name]
+name: [scope]-[type]-skill-[number]-[skill-name]
 description: >
   [What the skill does AND exactly when an agent should activate it. Max 1024 chars.]
 metadata:
@@ -87,7 +87,7 @@ metadata:
 
 ## References
 
-[Links to related XDRs and skills.]
+[Links to related Policies and skills.]
 ```
 
 Rules:
@@ -95,9 +95,9 @@ Rules:
 - The `description` field must state both *what* the skill does and *when* to activate it.
 - Keep the skill task-oriented. It should have a clear starting trigger and a concrete ending result.
 - Mention tools or prerequisites when they are required to complete the task reliably.
-- Do not duplicate content from referenced XDRs — link instead.
-- Do not present the skill itself as policy; mandatory behavior must come from referenced XDRs or other policy artifacts.
-- When the skill depends on XDRs, make the activation logic and instructions consistent with the XDR metadata so the skill does not operationalize inactive or out-of-scope decisions.
+- Do not duplicate content from referenced Policies — link instead.
+- Do not present the skill itself as policy; mandatory behavior must come from referenced Policies or other policy artifacts.
+- When the skill depends on Policies, make the activation logic and instructions consistent with the Policy metadata so the skill does not operationalize inactive or out-of-scope decisions.
 - Prefer plain Markdown, tables, Mermaid.js (sequence, state, activity, entity diagrams), or ASCII art for simple structure, flow, layout, or relationship indications.
 - If `SKILL.md` genuinely needs local images or supporting files, store them in `.xdrs/[scope]/[type]/[subject]/skills/[number]-[skill-name]/.assets/` and link them using a same-folder relative path (e.g., `.assets/image.png`).
 - Use relative paths for all links; never use absolute paths starting with `/`.
@@ -123,7 +123,7 @@ If any check fails, revise before continuing.
    mkdir -p .github/skills/[number]-[skill-name]
    ln -s ../../.xdrs/[scope]/[type]/[subject]/skills/[number]-[skill-name] .github/skills/[number]-[skill-name]
    ```
-3. Evaluate whether the scope index at `.xdrs/[scope]/index.md` should be updated to reflect the new skill. If the scope index does not exist, create it following article standards and the scope index rules in `_core-adr-001`.
+3. Evaluate whether the scope index at `.xdrs/[scope]/index.md` should be updated to reflect the new skill. If the scope index does not exist, create it following article standards and the scope index rules in `_core-adr-policy-001`.
 
 ### Constraints
 
@@ -158,6 +158,6 @@ If any check fails, revise before continuing.
 
 ## References
 
-- [_core-adr-003 - Skill standards](../../003-skill-standards.md)
-- [_core-adr-001 - XDRs core](../../001-xdrs-core.md)
-- [002-write-xdr skill](../002-write-xdr/SKILL.md)
+- [_core-adr-policy-003 - Skill standards](../../003-skill-standards.md)
+- [_core-adr-policy-001 - XDRs core](../../001-xdrs-core.md)
+- [002-write-policy skill](../002-write-policy/SKILL.md)

package/.xdrs/_core/adrs/principles/skills/004-write-article/SKILL.md

@@ -1,7 +1,7 @@
 ---
-name: 004-write-article
+name: _core-adr-skill-004-write-article
 description: >
-   Creates a new article document following XDR article standards: selects scope, type, subject, and number; then writes a focused synthetic text that combines and links multiple XDRs, Research documents, and Skills around a topic. Activate this skill when the user asks to create, add, or write a new article, guide, or overview document within an XDR project.
+   Creates a new article document following XDRS article standards: selects scope, type, subject, and number; then writes a focused synthetic text that combines and links multiple Policies, Research documents, and Skills around a topic. Activate this skill when the user asks to create, add, or write a new article, guide, or overview document within an XDRS project.
 metadata:
   author: flaviostutz
   version: "1.0"
@@ -9,7 +9,7 @@ metadata:
 
 ## Overview
 
-Guides the creation of a well-structured article by following `_core-adr-004`, consulting `xdr-standards` for every core element definition, researching the XDRs, Research documents, and Skills to synthesize, and producing a concise document that serves as a navigable view without duplicating decision content.
+Guides the creation of a well-structured article by following `_core-adr-policy-004`, consulting `policy-standards` for every core element definition, researching the Policies, Research documents, and Skills to synthesize, and producing a concise document that serves as a navigable view without duplicating decision content.
 
 ## Instructions
 
@@ -20,11 +20,11 @@ Before reading any standards, ask the user clarifying questions to gather the in
 Mandatory questions (ask only if not already provided by the user):
 - **Topic**: What is the article about? (skip if the user already stated it)
 - **Audience**: Who is the intended reader? (e.g., new developers, product managers, external contributors) MUST always be asked explicitly; never infer from context.
-- **Scope**: Which XDR scope should contain the article? (default is `_local`; confirm or ask only if context is ambiguous)
+- **Scope**: Which XDRS scope should contain the article? (default is `_local`; confirm or ask only if context is ambiguous)
 
 Optional questions (ask only when genuinely unclear):
 - **Type**: Should the article primarily synthesize ADRs, BDRs, or EDRs? Ask only when the topic spans multiple types.
-- **Existing XDRs**: Are there specific Decision Records or Skills you want the article to reference or synthesize?
+- **Existing XDRS elements**: Are there specific Policies or Skills you want the article to reference or synthesize?
 
 Do NOT proceed to Phase 1 until you have at minimum a clear **topic** and **audience**.
 
@@ -43,13 +43,13 @@ Consult `001-xdrs-core` while making each choice in this phase. The summaries be
 **Scope** — use `_local` unless the user explicitly names another scope.
 - If the user names a scope other than `_local`, check the workspace root `.filedist` file. If any file under `.xdrs/[scope]/` appears in `.filedist`, the scope is external and new documents MUST NOT be created there. Inform the user and ask them to choose a non-external scope.
 
-**Type** — match the type of the XDRs the article primarily synthesizes (`adrs`, `bdrs`, or `edrs`).
-If the topic spans multiple types, use `adrs`. Use the same rules as `002-write-xdr` Phase 2:
+**Type** — match the type of the XDRS elements the article primarily synthesizes (`adrs`, `bdrs`, or `edrs`).
+If the topic spans multiple types, use `adrs`. Use the same rules as `002-write-policy` Phase 2:
 - **BDR**: business process, product policy, strategic rule, operational procedure
 - **ADR**: system context, integration pattern, overarching architectural choice
 - **EDR**: specific tool/library, coding practice, testing strategy, project structure, pipelines
 
-**Subject** — pick the subject that best matches the article's topic (required list per type is in `_core-adr-001`).
+**Subject** — pick the subject that best matches the article's topic (required list per type is in `_core-adr-policy-001`).
 If the article spans more than one subject, place it in `principles`.
 
 ### Phase 3: Assign a Number and Name
@@ -60,19 +60,19 @@ If the article spans more than one subject, place it in `principles`.
    - Good: `onboarding-guide`, `checkout-flow-overview`, `api-design-principles`
    - Avoid: `summary`, `notes`, `misc`
 
-### Phase 4: Research XDRs and Skills to Synthesize
+### Phase 4: Research Policies and Skills to Synthesize
 
-1. Read all XDRs, Research documents, and Skills relevant to the article topic across all scopes listed in the XDR root `index.md`.
-2. Evaluate XDR metadata before synthesizing guidance. All documents present in the collection are considered active. Use `valid-from:` to determine the convergence date for adoption, `apply-to:` to determine whether the decision fits the audience or context being discussed, and the decision text itself for any remaining applicability boundaries.
+1. Read all Policies, Research documents, and Skills relevant to the article topic across all scopes listed in the Policy root `index.md`.
+2. Evaluate Policy metadata before synthesizing guidance. All documents present in the collection are considered active. Use `valid-from:` to determine the convergence date for adoption, `apply-to:` to determine whether the decision fits the audience or context being discussed, and the decision text itself for any remaining applicability boundaries.
 3. Identify the key points a reader needs to understand the topic end-to-end.
-4. Collect XDR IDs and file paths for cross-references. Never copy decision text verbatim; link to it.
+4. Collect Policy IDs and file paths for cross-references. Never copy decision text verbatim; link to it.
 
 ### Phase 5: Write the Article
 
 Use the mandatory template from `004-article-standards`:
 
 ```
-# [scope]-article-[number]: [Short Title]
+# [scope]-[type]-article-[number]: [Short Title]
 
 ## Overview
 
@@ -80,34 +80,34 @@ Use the mandatory template from `004-article-standards`:
 
 ## Content
 
-[Synthetic text combining and explaining the topic. Use links to Decision Records, Research documents, and Skills
+[Synthetic text combining and explaining the topic. Use links to Policies, Research documents, and Skills
 when referencing information from those documents. Keep under 1950 words total.]
 
 ## References
 
-- [XDR id or Skill name](relative/path/to/file.md) - Brief description of relevance
+- [Policy id or Skill name](relative/path/to/file.md) - Brief description of relevance
 ```
 
 Rules to apply while drafting:
 
 - Write for the stated audience; avoid jargon unexplained elsewhere.
-- Every factual claim must link back to the authoritative XDR or Skill.
-- If the article advises readers what to do, clearly separate active/applicable XDRs from background, historical, or out-of-scope ones.
+- Every factual claim must link back to the authoritative Policy or Skill.
+- If the article advises readers what to do, clearly separate active/applicable Policies from background, historical, or out-of-scope ones.
 - Never reproduce decision text verbatim; summarize and link.
 - Prefer plain Markdown, tables, Mermaid.js (sequence, state, activity, entity diagrams), or ASCII art for simple structure, flow, layout, or relationship indications.
 - If the article genuinely needs local images or supporting files, store them in `.xdrs/[scope]/[type]/[subject]/articles/.assets/` and link them using a same-folder relative path (e.g., `.assets/image.png`).
 - Use relative paths for all links; never use absolute paths starting with `/`.
-- Keep the article under 1950 words; move detailed content to XDRs or Skills.
+- Keep the article under 1950 words; move detailed content to Policies or Skills.
 - Use lowercase file names. Never use emojis.
-- If a conflict exists between the article and a Decision Record, note it and defer to the XDR.
+- If a conflict exists between the article and a Policy, note it and defer to the Policy.
 
 ### Phase 6: Place and Register
 
 1. Save the file at `.xdrs/[scope]/[type]/[subject]/articles/[number]-[short-title].md`.
 2. Add a link to the article in the canonical index for that scope+type (`.xdrs/[scope]/[type]/index.md`).
-3. Add back-references in the XDRs, Research documents, and Skills that the article synthesizes, under their `## References`
+3. Add back-references in the Policies, Research documents, and Skills that the article synthesizes, under their `## References`
    section.
-4. Evaluate whether the scope index at `.xdrs/[scope]/index.md` should be updated to reflect the new article. If the scope index does not exist, create it following article standards and the scope index rules in `_core-adr-001`.
+4. Evaluate whether the scope index at `.xdrs/[scope]/index.md` should be updated to reflect the new article. If the scope index does not exist, create it following article standards and the scope index rules in `_core-adr-policy-001`.
 
 ## Examples
 
@@ -118,20 +118,20 @@ Rules to apply while drafting:
 2. Topic: how skills work. Audience: developers new to the project.
 3. Scope: `_local`, type: `adrs`, subject: `principles`.
 4. Scan `.xdrs/_local/adrs/principles/articles/` — no articles exist → number is `001`.
-5. Research `_core-adr-003`, `_core-adr-006`, and the existing skill SKILL.md files.
+5. Research `_core-adr-policy-003`, `_core-adr-policy-006`, and the existing skill SKILL.md files.
 6. Write `.xdrs/_local/adrs/principles/articles/001-skills-overview.md` following the template, linking
-   to `_core-adr-003` and the individual skill files.
+   to `_core-adr-policy-003` and the individual skill files.
 7. Update `.xdrs/_local/adrs/index.md` with a link to the new article.
-8. Add a reference to the article in `_core-adr-003` under `## References`.
+8. Add a reference to the article in `_core-adr-policy-003` under `## References`.
 
 ## Edge Cases
 
-- **Article vs. XDR confusion** — if the user asks for a document that makes a decision, write an XDR
-  (use the `002-write-xdr` skill), not an article.
+- **Article vs. Policy confusion** — if the user asks for a document that makes a decision, write a Policy
+  (use the `002-write-policy` skill), not an article.
 - **Cross-subject topic** — place the article in `principles`, not in any single subject folder.
 - **No existing articles folder** — create it; it is optional in the folder layout.
-- **Conflicting information found** — note the conflict in the article and always defer to the XDR.
-- **Article would exceed 1950 words** — move detailed content to a new Research, Skill, or XDR and link back.
+- **Conflicting information found** — note the conflict in the article and always defer to the Policy.
+- **Article would exceed 1950 words** — move detailed content to a new Research, Skill, or Policy and link back.
 
 ## Constraints
 
@@ -139,10 +139,10 @@ Rules to apply while drafting:
 - MUST follow the article template and placement rules from `004-article-standards`.
 - MUST keep scope `_local` unless the user explicitly states otherwise.
 - MUST NOT create documents in external scopes (scopes whose files appear in the workspace root `.filedist`).
-- MUST defer to active and applicable XDRs when article synthesis conflicts with them.
+- MUST defer to active and applicable Policies when article synthesis conflicts with them.
 
 ## References
 
-- [_core-adr-004 - Article standards](../../004-article-standards.md)
-- [_core-adr-006 - Research standards](../../006-research-standards.md)
-- [_core-adr-001 - XDRs core](../../001-xdrs-core.md)
+- [_core-adr-policy-004 - Article standards](../../004-article-standards.md)
+- [_core-adr-policy-006 - Research standards](../../006-research-standards.md)
+- [_core-adr-policy-001 - XDRS core](../../001-xdrs-core.md)

package/.xdrs/_core/adrs/principles/skills/005-write-research/SKILL.md

@@ -1,7 +1,7 @@
 ---
-name: 005-write-research
+name: _core-adr-skill-005-write-research
 description: >
-  Creates a new research document following XDR research standards: selects scope, type, subject, and number;
+  Creates a new research document following XDRS research standards: selects scope, type, subject, and number;
   then writes an IMRAD-based study with enough evidence and method detail to stand on its own as a technical paper.
   Activate this skill when the user asks to create, add, or write a research document that backs a decision.
 metadata:
@@ -11,7 +11,7 @@ metadata:
 
 ## Overview
 
-Guides the creation of a well-structured research document by following `_core-adr-006`, consulting `xdr-standards` for every core element definition, checking related XDRs and existing research to avoid duplication, and producing an IMRAD-based study that reads as a standalone technical paper. Treat each section goal in the research template as an acceptance criterion, not as optional wording. Do not assume missing direction, evidence, or intended follow-up; ask the user explicitly before proceeding when those points are not already concrete.
+Guides the creation of a well-structured research document by following `_core-adr-policy-006`, consulting `xdrs-core` for every core element definition, checking related Policies and existing research to avoid duplication, and producing an IMRAD-based study that reads as a standalone technical paper. Treat each section goal in the research template as an acceptance criterion, not as optional wording. Do not assume missing direction, evidence, or intended follow-up; ask the user explicitly before proceeding when those points are not already concrete.
 
 This skill is interactive by design. Ask clarifying questions to the user at each phase where direction, evidence, or scope is unclear. Ask sequentially — one focused set of questions at a time — and wait for the user's answers before advancing to the next phase. Never front-load all questions at once if not all are yet relevant.
 
@@ -23,7 +23,7 @@ This skill is interactive by design. Ask clarifying questions to the user at eac
 2. Read `.xdrs/_core/adrs/principles/001-xdrs-core.md` in full before defining the research document's core elements. Treat it as the canonical source for how to choose and write type, scope, subject, numbering expectations, naming constraints, and folder placement.
 3. Ask the user to confirm the intended direction of the research before planning the document: what decision, question, or option space the study should support, what boundaries or exclusions apply, and what kind of outcome they expect. Wait for the answers before proceeding.
 4. Ask the user what evidence already exists and what evidence-gathering methods are acceptable if the current evidence is incomplete. Do not invent facts, sources, or confidence that the user did not provide. Wait for the answers before proceeding.
-5. Ask the user what the proposed next step is after the research, such as writing a new XDR, updating an existing XDR, informing a discussion, or documenting trade-offs for later. Use that answer to shape the framing without turning the research into the final decision. Wait for the answers before proceeding.
+5. Ask the user what the proposed next step is after the research, such as writing/updating an existing Policy, informing a discussion, or documenting trade-offs for later. Use that answer to shape the framing without turning the research into the final decision. Wait for the answers before proceeding.
 6. Identify the problem or question being explored, the relevant system or domain context, the likely technical audience, and why the subject matters in practice.
 7. Internalize the goal of each required section before drafting: `Abstract` gives a quick technical reader the question, method, main result, and takeaway, `Introduction` frames the investigated problem and context, `Methods` makes the important parts reproducible, `Results` records raw findings with minimal interpretation, `Discussion` interprets the findings, `Conclusion` summarizes the practical takeaway and boundaries, and `References` makes sources traceable.
 8. Collect the main constraints, known facts, important experiences, gaps, and assumptions that belong in the introduction.
@@ -38,19 +38,19 @@ Consult `001-xdrs-core` while making each choice in this phase. The summaries be
 **Scope** — use `_local` unless the user explicitly names another scope.
 - If the user names a scope other than `_local`, check the workspace root `.filedist` file. If any file under `.xdrs/[scope]/` appears in `.filedist`, the scope is external and new documents MUST NOT be created there. Inform the user and ask them to choose a non-external scope.
 
-**Type** — match the type of decision this research supports (`adrs`, `bdrs`, or `edrs`). Use the same rules as `002-write-xdr` Phase 2:
+**Type** — match the type of decision this research supports (`adrs`, `bdrs`, or `edrs`). Use the same rules as `002-write-policy` Phase 2:
 - **BDR**: business process, product policy, strategic rule, operational procedure
 - **ADR**: system context, integration pattern, overarching architectural choice
 - **EDR**: specific tool/library, coding practice, testing strategy, project structure, pipelines
 
-**Subject** — pick the most specific subject that matches the problem domain (required list per type is in `_core-adr-001`).
+**Subject** — pick the most specific subject that matches the problem domain (required list per type is in `_core-adr-policy-001`).
 
 **Research number** — scan `.xdrs/[scope]/[type]/[subject]/researches/` for the highest existing number and increment by 1. Never reuse numbers from deleted research documents.
 
 ### Phase 3: Research Existing Artifacts
 
-1. Read relevant XDRs across all scopes listed in the XDR root `index.md`.
-2. Evaluate XDR metadata before treating any decision as current context. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether the decision fits the intended task context, and the decision text defines any remaining boundaries. Keep out-of-window or out-of-scope XDRs as background only.
+1. Read relevant Policies across all scopes listed in the Policy root `index.md`.
+2. Evaluate Policy metadata before treating any decision as current context. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether the decision fits the intended task context, and the decision text defines any remaining boundaries. Keep out-of-window or out-of-scope Policies as background only.
 3. Read existing research documents in the same or overlapping subjects to avoid duplicating the same study.
 4. Read related skills or articles if they contain context, implementation limits, or terminology that must be reflected.
 5. Collect links that should appear in the final `## References` section.
@@ -88,7 +88,7 @@ If the results contain competing interpretations or the intended audience for th
 Use the mandatory template from `006-research-standards`:
 
 ```markdown
-# [scope]-research-[number]: [Short Title]
+# [scope]-[type]-research-[number]: [Short Title]
 
 ## Abstract
 
@@ -123,16 +123,16 @@ Use figures, tables, or bullets when useful. If multiple options solve the same
 
 [A list of all cited literature, websites, tutorials, documentation, discussions, and related artifacts. Goal: make all cited sources and supporting artifacts traceable.]
 
-- [Related XDR or artifact](relative/path.md) - Why it matters
-- [Another related XDR if this research informed multiple decisions](relative/path.md) - Why it matters
+- [Related Policy or artifact](relative/path.md) - Why it matters
+- [Another related Policy if this research informed multiple decisions](relative/path.md) - Why it matters
 ```
 
 Rules:
 - Treat the goal sentence of each section as a hard check on what belongs in that section.
 - Focus on exploring and evidencing the problem space; do not turn the document into the final decision.
-- Write as a standalone technical paper for readers who do not know the XDR process.
+- Write as a standalone technical paper for readers who do not know the XDRS process.
 - Keep mentions of future ADRs, decision lifecycle, repository process, or artifact management out of the body unless they are materially necessary to understand the research question.
-- Keep traceability to related XDRs, skills, articles, discussions, and external sources primarily in `## References`.
+- Keep traceability to related Policies, skills, articles, discussions, and external sources primarily in `## References`.
 - Use good-enough evidence. Experienced professional judgment is allowed, but the conclusions still need support that other colleagues can inspect and learn from.
 - Ensure the methods and test conditions are reproducible enough for an experienced professional to rerun or evolve the critical parts later.
 - Prefer plain Markdown, tables, Mermaid.js (sequence, state, activity, entity diagrams), bullet points, or ASCII art for simple explanations and comparisons, especially in the introduction and results.
@@ -150,7 +150,7 @@ Before the final review, verify each section against its specific goal:
 4. **Results goal**: Are the findings concrete and minimally interpreted, with comparisons and pros/cons when multiple options exist?
 5. **Discussion goal**: Does it interpret the findings rather than repeat the results?
 6. **Conclusion goal**: Does it summarize the main findings, practical takeaway, applicability boundaries, and open questions without introducing new evidence?
-7. **References goal**: Are cited sources and related artifacts traceable, including related XDRs, skills, articles, and research where relevant?
+7. **References goal**: Are cited sources and related artifacts traceable, including related Policies, skills, articles, and research where relevant?
 
 If any section fails its goal, revise that section before continuing.
 
@@ -236,7 +236,7 @@ Before writing files, verify:
 4. **Evidence quality**: Are the results concrete enough to support the discussion and conclusion?
 5. **Standalone focus**: Does the text read as a technical paper rather than commentary about future ADRs, repository process, or artifact management?
 6. **Ratio fit**: Does the document stay within section word limits and pass the Python ratio check, or does the introduction explicitly justify the deviation?
-7. **References**: Are all related XDRs, research docs, skills, articles, and external sources linked when relevant?
+7. **References**: Are all related Policies, research docs, skills, articles, and external sources linked when relevant?
 
 If any check fails, revise before continuing.
 
@@ -244,34 +244,34 @@ If any check fails, revise before continuing.
 
 1. Create the research file at `.xdrs/[scope]/[type]/[subject]/researches/[number]-[short-title].md`.
 2. Add an entry to `.xdrs/[scope]/[type]/index.md`.
-3. Add back-references from the related XDR, article, or skill when the relationship is important for discovery.
-4. Evaluate whether the scope index at `.xdrs/[scope]/index.md` should be updated to reflect the new research. If the scope index does not exist, create it following article standards and the scope index rules in `_core-adr-001`.
+3. Add back-references from the related Policy, article, or skill when the relationship is important for discovery.
+4. Evaluate whether the scope index at `.xdrs/[scope]/index.md` should be updated to reflect the new research. If the scope index does not exist, create it following article standards and the scope index rules in `_core-adr-policy-001`.
 
 ## Examples
 
-**Input**: "Create research comparing package distribution options for our XDR scopes"
+**Input**: "Create research comparing package distribution options for our Policy scopes"
 
 **Expected actions:**
 1. Read `006-research-standards.md`.
 2. Choose type `adrs` and subject `principles`.
 3. Scan `.xdrs/_local/adrs/principles/researches/` for the next number.
-4. Read related XDRs about packaging and versioning.
+4. Read related Policies about packaging and versioning.
 5. Write an IMRAD-based research document comparing options such as npm package, git submodule, and copy-paste distribution, with the comparison grounded in methods and results.
-6. Add references to the resulting XDR if a decision is later created.
+6. Add references to the resulting Policy if a decision is later created.
 
 ## Edge Cases
 
-- If the user is really asking for a final decision, write an XDR instead of research.
+- If the user is really asking for a final decision, write a Policy instead of research.
 - If only one viable option exists, still explain what was evaluated, what was ruled out, or what constraints removed the alternatives.
 - If the document grows too large, split independent problem threads into separate research files unless the introduction explicitly justifies a longer study.
-- If the supported decision does not exist yet, reference the decision topic or planned XDR title in the introduction and conclusion.
+- If the supported decision does not exist yet, reference the decision topic or planned Policy title in the introduction and conclusion.
 - If the user's direction, evidence base, or intended next step is vague, ask follow-up questions and wait for clarification instead of choosing a path yourself.
 
 ## References
 
-- [_core-adr-006 - Research standards](../../006-research-standards.md)
-- [_core-adr-001 - XDRs core](../../001-xdrs-core.md)
-- [002-write-xdr skill](../002-write-xdr/SKILL.md)
+- [_core-adr-policy-006 - Research standards](../../006-research-standards.md)
+- [_core-adr-policy-001 - XDRS core](../../001-xdrs-core.md)
+- [002-write-policy skill](../002-write-policy/SKILL.md)
 
 ## Constraints
 

package/.xdrs/_core/adrs/principles/skills/006-write-plan/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: 006-write-plan
+name: _core-adr-skill-006-write-plan
 description: >
-  Creates a new plan document following XDR plan standards: selects scope, type, subject, and number;
+  Creates a new plan document following XDRS plan standards: selects scope, type, subject, and number;
   then writes a focused execution plan with problem context, proposed solution, approach, milestones, and deliverables.
-  Activate this skill when the user asks to create, add, or write a plan, project plan, or execution plan within an XDR project.
+  Activate this skill when the user asks to create, add, or write a plan, project plan, or execution plan within an XDRS project.
 metadata:
   author: flaviostutz
   version: "1.0"
@@ -11,7 +11,7 @@ metadata:
 
 ## Overview
 
-Guides the creation of a well-structured plan document by following `_core-adr-007`, consulting `xdr-standards` for every core element definition, researching related XDRs and existing plans, and producing a focused execution document that connects to the decisions, research, and skills it relates to.
+Guides the creation of a well-structured plan document by following `_core-adr-policy-007`, consulting `xdrs-core` for every core element definition, researching related Policies and existing plans, and producing a focused execution document that connects to the decisions, research, and skills it relates to.
 
 ## Instructions
 
@@ -35,12 +35,12 @@ Consult `001-xdrs-core` while making each choice in this phase. The summaries be
 **Scope** — use `_local` unless the user explicitly names another scope.
 - If the user names a scope other than `_local`, check the workspace root `.filedist` file. If any file under `.xdrs/[scope]/` appears in `.filedist`, the scope is external and new documents MUST NOT be created there. Inform the user and ask them to choose a non-external scope.
 
-**Type** — match the type of the XDRs the plan primarily implements or relates to (`adrs`, `bdrs`, or `edrs`).
+**Type** — match the type of the Policies the plan primarily implements or relates to (`adrs`, `bdrs`, or `edrs`).
 - **BDR**: business process, product policy, strategic rule, operational procedure
 - **ADR**: system context, integration pattern, overarching architectural choice
 - **EDR**: specific tool/library, coding practice, testing strategy, project structure, pipelines
 
-**Subject** — pick the subject that best matches the plan's topic (required list per type is in `_core-adr-001`). If the plan spans more than one subject, place it in `principles`.
+**Subject** — pick the subject that best matches the plan's topic (required list per type is in `_core-adr-policy-001`). If the plan spans more than one subject, place it in `principles`.
 
 ### Phase 3: Assign a Number and Name
 
@@ -52,8 +52,8 @@ Consult `001-xdrs-core` while making each choice in this phase. The summaries be
 
 ### Phase 4: Research Related Artifacts
 
-1. Read all XDRs, Research documents, Skills, and existing Plans relevant to the plan topic across all scopes listed in the XDR root `index.md`.
-2. Evaluate XDR metadata before treating any decision as current context. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether the decision fits the intended context, and the decision text defines any remaining boundaries.
+1. Read all Policies, Research documents, Skills, and existing Plans relevant to the plan topic across all scopes listed in the Policy root `index.md`.
+2. Evaluate Policy metadata before treating any decision as current context. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether the decision fits the intended context, and the decision text defines any remaining boundaries.
 3. Identify Decisions that this plan implements, Research that informs the planning, and any existing Plans that overlap.
 4. Collect artifact IDs and file paths for cross-references.
 
@@ -62,7 +62,7 @@ Consult `001-xdrs-core` while making each choice in this phase. The summaries be
 Use the mandatory template from `007-plan-standards`:
 
 ```markdown
-# [scope]-plan-[number]: [Short Title]
+# [scope]-[type]-plan-[number]: [Short Title]
 
 ## Executive Summary
 
@@ -104,7 +104,7 @@ Expected end date: YYYY-MM-DD
 
 ## References
 
-- [Related XDR or artifact](relative/path.md) - Brief description of relevance
+- [Related Policy or artifact](relative/path.md) - Brief description of relevance
 ```
 
 Rules to apply while drafting:
@@ -123,8 +123,8 @@ Rules to apply while drafting:
 
 1. Save the file at `.xdrs/[scope]/[type]/[subject]/plans/[number]-[short-title].md`.
 2. Add a link to the plan in the canonical index for that scope+type (`.xdrs/[scope]/[type]/index.md`).
-3. Add back-references in the XDRs, Research documents, and Skills that the plan relates to, under their `## References` section.
-4. Evaluate whether the scope index at `.xdrs/[scope]/index.md` should be updated to reflect the new plan. If the scope index does not exist, create it following article standards and the scope index rules in `_core-adr-001`.
+3. Add back-references in the Policies, Research documents, and Skills that the plan relates to, under their `## References` section.
+4. Evaluate whether the scope index at `.xdrs/[scope]/index.md` should be updated to reflect the new plan. If the scope index does not exist, create it following article standards and the scope index rules in `_core-adr-policy-001`.
 
 ### Phase 7: Verify with Lint
 
@@ -142,7 +142,7 @@ Rules to apply while drafting:
 1. Read `007-plan-standards.md`.
 2. Topic: API v2 migration. Scope: `_local`.
 3. Type: `adrs` (architectural). Subject: `integration` or `application`.
-4. Research related XDRs about API design and integration patterns.
+4. Research related Policies about API design and integration patterns.
 5. Draft the plan with clear problem, solution, milestones, and expected end date.
 6. Save, register in canonical index, and lint.
 
@@ -151,13 +151,13 @@ Rules to apply while drafting:
 - If a plan is too large (more than 2 years), split it into multiple smaller plans. Each plan should be independently actionable and produce its own deliverables.
 - If a plan spawns sub-plans during implementation, each sub-plan is a separate plan document in the appropriate subject folder. Link them in the References section.
 - If a plan is fully implemented, delete it and confirm that all lasting outputs (Decisions, Skills, Articles, etc.) are properly linked and indexed.
-- If the user asks for a plan that is really just a decision, guide them to create an XDR instead.
+- If the user asks for a plan that is really just a decision, guide them to create a Policy instead.
 
 ## References
 
-- [_core-adr-001 - XDRs core](../../001-xdrs-core.md)
-- [_core-adr-007 - Plan standards](../../007-plan-standards.md)
-- [_core-adr-002 - XDR standards](../../002-xdr-standards.md)
+- [_core-adr-policy-001 - XDRS core](../../001-xdrs-core.md)
+- [_core-adr-policy-007 - Plan standards](../../007-plan-standards.md)
+- [_core-adr-policy-002 - Policy standards](../../002-policy-standards.md)
 
 ## Constraints
 

package/.xdrs/_core/adrs/principles/skills/007-write-presentation/SKILL.md

@@ -1,8 +1,8 @@
 ---
-name: 007-write-presentation
+name: _core-adr-skill-007-write-presentation
 description: >
-  Creates a Marp slide presentation for an existing XDR document (decision, research, article, or plan).
-  Activate this skill when the user asks to create slides, a presentation, or a slide deck for an XDR document.
+  Creates a Marp slide presentation for an existing XDRS document (policy, research, article, or plan).
+  Activate this skill when the user asks to create slides, a presentation, or a slide deck for an XDRS document.
 metadata:
   author: flaviostutz
   version: "1.0"
@@ -10,7 +10,7 @@ metadata:
 
 ## Overview
 
-Guides the creation of a Marp Markdown slide presentation that supports an existing XDR document. The skill ensures the slides follow presentation standards (`_core-adr-009`), are correctly placed in the `.assets/` folder, and maintain bidirectional links with the parent document.
+Guides the creation of a Marp Markdown slide presentation that supports an existing XDRS document. The skill ensures the slides follow presentation standards (`_core-adr-policy-009`), are correctly placed in the `.assets/` folder, and maintain bidirectional links with the parent document.
 
 ## Instructions
 
@@ -18,7 +18,7 @@ Guides the creation of a Marp Markdown slide presentation that supports an exist
 
 1. Read `.xdrs/_core/adrs/principles/009-presentation-standards.md` in full to internalize all presentation rules.
 2. Read `.xdrs/_core/adrs/principles/001-xdrs-core.md` for `.assets/` placement rules and general framework structure.
-3. Identify the parent document (decision, research, article, or plan) that the slides will support. The parent document must already exist. If no parent document exists, inform the user that slides cannot be standalone and suggest creating the parent document first.
+3. Identify the parent document (policy, research, article, or plan) that the slides will support. The parent document must already exist. If no parent document exists, inform the user that slides cannot be standalone and suggest creating the parent document first.
 4. If the user wants slides covering content from multiple documents, check whether an article already exists that synthesizes those documents. If not, suggest creating an article first (using the 004-write-article skill) and then creating slides for that article.
 
 ### Phase 2: Define the Presentation Scope
@@ -108,13 +108,13 @@ Rules:
 
 ### Phase 6: Update the Parent Document
 
-1. Add a link to the slide file in the parent document. Place it in the `## References` section or, for XDRs, in the most appropriate section.
+1. Add a link to the slide file in the parent document. Place it in the `## References` section or, for Policies, in the most appropriate section.
 2. Use a descriptive link text such as "Presentation slides" pointing to the slide file in `.assets/`.
 
 ### Phase 7: Write Files
 
 1. Create the slide file at the correct `.assets/` location:
-   - XDRs: `[xdrs-root]/[scope]/[type]/[subject]/.assets/[slide-file].md`
+   - Policies: `[xdrs-root]/[scope]/[type]/[subject]/.assets/[slide-file].md`
    - Articles: `[xdrs-root]/[scope]/[type]/[subject]/articles/.assets/[slide-file].md`
    - Research: `[xdrs-root]/[scope]/[type]/[subject]/researches/.assets/[slide-file].md`
    - Skills: `[xdrs-root]/[scope]/[type]/[subject]/skills/[number]-[skill-name]/.assets/[slide-file].md`
@@ -132,7 +132,7 @@ Rules:
 
 ### Constraints
 
-- MUST follow presentation standards from `_core-adr-009` exactly.
+- MUST follow presentation standards from `_core-adr-policy-009` exactly.
 - MUST NOT create slides without an existing parent document.
 - MUST NOT create standalone slides that reference multiple documents without an article as the parent.
 - MUST maintain bidirectional links between slides and parent document.
@@ -144,7 +144,7 @@ Rules:
 ## Examples
 
 **Input**: "Create slides for our naming conventions decision"
-- Locate the parent XDR (e.g. `003-naming-conventions.md`)
+- Locate the parent Policy (e.g. `003-naming-conventions.md`)
 - Ask: "Who is the target audience for these slides?"
 - Create: `.assets/003-naming-conventions-slides.md`
 - Update: Add link in `003-naming-conventions.md`
@@ -152,7 +152,7 @@ Rules:
 **Input**: "Create an executive presentation covering our security and data decisions"
 - Check if an article synthesizing security + data decisions exists
 - If not, suggest creating the article first
-- Create slides for the article, not the individual XDRs
+- Create slides for the article, not the individual Policies
 
 ## Edge Cases
 
@@ -163,7 +163,7 @@ Rules:
 
 ## References
 
-- [_core-adr-009 - Presentation standards](../../009-presentation-standards.md)
-- [_core-adr-001 - XDRs core](../../001-xdrs-core.md)
-- [_core-adr-004 - Article standards](../../004-article-standards.md)
-- [_core-adr-003 - Skill standards](../../003-skill-standards.md)
+- [_core-adr-policy-009 - Presentation standards](../../009-presentation-standards.md)
+- [_core-adr-policy-001 - XDRS core](../../001-xdrs-core.md)
+- [_core-adr-policy-004 - Article standards](../../004-article-standards.md)
+- [_core-adr-policy-003 - Skill standards](../../003-skill-standards.md)