xdrs-core 0.43.1 → 0.45.0

package/.xdrs/_core/adrs/index.md

@@ -24,6 +24,7 @@ Foundational standards, principles, and guidelines.
 - [_core-adr-policy-016](principles/016-policy-subjects.md) - **Policy Subjects** — Allowed subjects per type (ADR/BDR/EDR), descriptions, examples, and disambiguation tiebreakers
 - [_core-adr-policy-017](principles/017-policy-numbering-ranges.md) - **Policy numbering ranges** — Subject-based 100-number block ranges for policy numbering and the freeze-reference exemption
 - [_core-adr-policy-018](principles/018-external-path-symlinks.md) - **External path symlinks** — How to make XDRS files accessible from paths outside the .xdrs/ root using symlinks
+- [_core-adr-policy-019](principles/019-compiled-scope-type.md) - **compiled scope type** — Defines the `compiled` scope type: scopes whose policies are compiled from external authoritative sources with strict source traceability and no invented content
 
 ## Skills
 
@@ -37,6 +38,7 @@ Step-by-step procedural guides for humans and AI agents.
 - [006-write-plan](principles/skills/006-write-plan/SKILL.md) - **Write Plan** — create a new plan document
 - [007-write-presentation](principles/skills/007-write-presentation/SKILL.md) - **Write Presentation** — create Marp slide presentations for XDRS documents
 - [008-write-xdrs-doc](principles/skills/008-write-xdrs-doc/SKILL.md) - **Write XDRS Doc** — router skill; infers document type and delegates to the appropriate authoring skill
+- [009-compile-scope](principles/skills/009-compile-scope/SKILL.md) - **Compile Scope** — compiles or updates a `compiled`-type scope from its configured external sources
 
 ## Articles
 

package/.xdrs/_core/adrs/principles/001-xdrs-standards.md

@@ -75,7 +75,7 @@ ADR and EDR share the same six technical subject names (see [`_core-adr-policy-0
   - **Types:** `adrs`, `bdrs`, `edrs`
   - there can exist sufixes to the standard scope names (e.g: `business-x-mobileapp`, `business-y-servicedesk`)
   - The `-core` suffix designates a scope as the meta governance layer for a domain. See `_core-adr-policy-011` for the `core` scope type definition.
-  - **Scope types:** Every scope MUST declare its type via a `scope-type` field in its `index.md` YAML frontmatter. A `scope-type` value is valid when a `{scope-type}-scope-type` policy exists in the `principles` subject of any `core`-type scope in the workspace. Multiple types MAY be declared using a comma-separated list (e.g., `scope-type: compiled, internal-docs`); each element MUST be valid independently. See `_core-adr-policy-010` rules 05 and 05b for the full multi-type grammar. Custom scope-type names MUST NOT start with `_`. The five built-in scope types and their definitions are:
+  - **Scope types:** Every scope MUST declare its type via a `scope-type` field in its `index.md` YAML frontmatter. A `scope-type` value is valid when a `{scope-type}-scope-type` policy exists in the `principles` subject of any `core`-type scope in the workspace. Multiple types MAY be declared using a comma-separated list (e.g., `scope-type: compiled, internal-docs`); each element MUST be valid independently. See `_core-adr-policy-010` rules 06 and 07 for the full multi-type grammar. Custom scope-type names MUST NOT start with `_`. The five built-in scope types and their definitions are:
     - `core` — see [`_core-adr-policy-011`](011-core-scope-type.md)
     - `reference` — see [`_core-adr-policy-012`](012-reference-scope-type.md)
     - `platform` — see [`_core-adr-policy-013`](013-platform-scope-type.md)
@@ -86,12 +86,14 @@ ADR and EDR share the same six technical subject names (see [`_core-adr-policy-0
   - **Scope index frontmatter fields:** Every scope's `index.md` MUST include the following YAML frontmatter. Fields match the Policy frontmatter standard (`_core-adr-policy-002`) in purpose, adjusted for scope-level semantics:
     - `name` (required): The scope identifier, MUST exactly match the scope directory name (e.g., `myteam`, `cloud-platform-aws`). Used by tools to verify scope identity.
     - `description` (required): Short overview of what this scope covers and who the intended audience is. Used by AI agents for discovery and relevance matching. Max 40 words.
-    - `scope-type` (required): Scope classification type. MAY be a comma-separated list of types (e.g., `scope-type: compiled, internal-docs`). Each element MUST match a `{scope-type}-scope-type` policy in any `core`-type scope's `principles/` directory. See `_core-adr-policy-010` rules 05 and 05b for the full multi-type grammar and `_core-adr-policy-011`, `012`–`015` for built-in type definitions.
+    - `scope-type` (required): Scope classification type. MAY be a comma-separated list of types (e.g., `scope-type: compiled, internal-docs`). Each element MUST match a `{scope-type}-scope-type` policy in any `core`-type scope's `principles/` directory. See `_core-adr-policy-010` rules 06 and 07 for the full multi-type grammar and `_core-adr-policy-011`, `012`–`015` for built-in type definitions.
     - `apply-to` (required): Declares in which contexts — teams, systems, codebases, or environments — the decisions in this scope are relevant. Max 30 words.
     - `valid-from` (required): ISO date (YYYY-MM-DD) from which this scope became active.
     - `metadata` (optional): Arbitrary key-value map for additional scope metadata.
-    - `follows` (optional): Core scope names whose Policies apply as mandatory conventions to this scope, beyond `_core`. Last-listed takes precedence on conflicts (e.g., `follows: myarea-core, shared-standards`).
-    - `related-scopes` (optional): Scope names of parent, sibling, or child scopes. Use when structural links help verify policy correctness across related scopes.
+    - `follows` (optional): Core scope names whose Policies apply as mandatory governance conventions to this scope, beyond `_core`. Last-listed takes precedence on conflicts (e.g., `follows: myarea-core, shared-standards`). All referenced scopes MUST exist in the workspace; if any is absent, READ/WRITE/REVIEW operations MUST fail.
+    - `extends` (optional): Scope names whose **policy documents** (decision records only — not skills, articles, research, or plans) are inherited by this scope as if they were authored here. Any scope type except `_local` and `_core` may be referenced. Last-listed extended scope takes precedence on conflicts; the extending scope's own policies always take highest precedence. Depth-first transitive resolution applies: if A extends [B, C] and B extends [D], the effective precedence order is D < B < C < A. `extends:` and `follows:` MUST reference disjoint scope sets. All referenced scopes MUST exist in the workspace; if any is absent, READ/WRITE/REVIEW operations MUST fail. When an extending scope's policy overrides an inherited policy on the same topic, a `## Conflicts` section MUST document the override. Scopes referenced only via `extends:` chains (not entry scopes in the root index) are exempt from the root index link requirement. See `_core-adr-policy-010` Section D (rules 27–35) for full normative rules.
+    - `license` (optional): SPDX identifier for the scope's content license.
+    - `metadata` (optional): Arbitrary key-value map for additional scope metadata.
 - **Subjects:** The subject folder MUST be chosen per [`_core-adr-policy-016`](016-policy-subjects.md), which defines allowed subjects, full descriptions, examples, and disambiguation tiebreakers.
 - **Policy numbering:** Numbers MUST be assigned within the subject-based block ranges defined in [`_core-adr-policy-017`](017-policy-numbering-ranges.md). Use the lowest available number within the block for the chosen subject. See [`_core-adr-policy-002-policy-standards.01-freeze-reference-exemption`](002-policy-standards.md) for exemptions.
 - MUST NOT use emojis

package/.xdrs/_core/adrs/principles/002-policy-standards.md

@@ -76,7 +76,7 @@ Policy documents are the authoritative source of truth for their scope, type, an
 - Each policy rule and rule block MUST be unambiguous: it MUST be possible to clearly follow, check, and discuss it without requiring additional interpretation.
 - When the decision defines strong policies or rules that SHOULD be stated explicitly as stable rule blocks, or when other documents, skills, or agents need to cite those rules individually by identifier, the Policy MUST follow the extension [_core-adr-policy-008 - Policy structured standards](008-policy-structured-standards.md) instead of using plain bullet lists for those rules.
 - Conflict handling applies to Policy documents:
-  - For cross-scope and cross-scope-type overrides, document the decision conflict in the Policy `## Conflicts` section of the Policy that overrides another scope or scope-type policy. Local meta-policies (`NNN-core.md` and companion files) and scope-type definition policies MAY include a `## Conflicts` section for this purpose. See `_core-adr-policy-010` rule 19-conflict-declarations for the required structure.
+  - For cross-scope and cross-scope-type overrides, document the decision conflict in the Policy `## Conflicts` section of the Policy that overrides another scope or scope-type policy. Local meta-policies (`NNN-core.md` and companion files) and scope-type definition policies MAY include a `## Conflicts` section for this purpose. See `_core-adr-policy-010` rule 26-conflict-declarations for the required structure.
   - **Within-scope conflicts:** Policies within the same type+scope MUST NOT conflict. If two Policies appear to conflict, one SHOULD be updated, removed, or the conflict resolved through a new Policy.
 - When research exists for a decision, the Policy SHOULD mention the related research documents after the `## Considered Options` list.
 - MUST NOT use emojis in contents.

package/.xdrs/_core/adrs/principles/010-scope-governance.md

@@ -15,15 +15,13 @@ XDRS provides three mechanisms that govern what content belongs in a scope and h
 2. **`follows:` declarations**: a scope explicitly declares that it follows the standards of a named `core`-type scope.
 3. **Scope-local standards**: a policy inside a scope that defines content rules specific to that one scope.
 
-Without a clear definition of how these mechanisms are authored and how they interact, tools, agents, and authors cannot reliably determine which standards apply when adding or reviewing content in a scope.
-
 ## Decision Outcome
 
 **Define scope types as policies, local meta-policies as `core`-named policies in `principles/`, and a clear precedence chain for governance application.**
 
 All scope types — both the five built-in types and any custom types — are defined using the same convention: a `{scope-type}-scope-type` policy in a `core`-type scope. Scope-local standards (called _local meta-policies_) are optional policies whose filename title starts with `core` and which are placed in the `principles` subject of the scope. Multiple local meta-policy files are allowed, each distinguished by an optional qualifier. Tools and agents apply all applicable standards in a defined order.
 
-> **Choosing between a local meta-policy and a `-core` sibling scope**: use a local meta-policy (Section B) when the standards apply only to one scope and do not need to be shared. Use a separate `-core` sibling scope (see `_core-adr-policy-011`) when the meta governance needs to be shared with or distributed to other teams, or when it governs a family of scopes sharing the same prefix.
+> **Choosing between a local meta-policy and a `-core` sibling scope**: use a local meta-policy when the standards apply only to one scope. Use a `-core` sibling scope (see `_core-adr-policy-011`) when the governance needs to be shared or governs a family of scopes.
 
 ### Details
 
@@ -39,18 +37,18 @@ The policy `name` field MUST end with `{scope-type}-scope-type` (e.g., `security
 
 Note: this naming applies to the **policy name** only, not to any scope directory name. It is distinct from the `-core` scope-name suffix convention defined in `_core-adr-policy-011`.
 
-#### 02b-def-companion-files
+#### 03-def-companion-files
 
 A scope-type definition MAY be split across multiple policy files. The primary file MUST follow rule 02 above. Each additional companion file MUST be named `NNN-{scope-type}-scope-type-{qualifier}.md` (e.g., `012-business-area-scope-type-writing-style.md`), where `{qualifier}` is a short lowercase kebab-case descriptor. All companion files MUST be placed in the **same** `[type]/principles/` directory as the primary file within the same scope. A companion file MUST NOT exist without a corresponding primary file in the same scope and type folder. Tools and agents MUST apply all companion files for a scope-type as additional mandatory conventions alongside the primary.
 
-#### 03-def-required-content
+#### 04-def-required-content
 
 A scope-type definition policy MUST define:
 
 - The scope type name (the value that instances declare in their `scope-type:` field).
 - When to use this scope type and what kinds of scopes SHOULD declare it.
 
-#### 04-def-preferred-content
+#### 05-def-preferred-content
 
 A scope-type definition policy SHOULD define:
 
@@ -59,74 +57,74 @@ A scope-type definition policy SHOULD define:
 - What content SHOULD NOT be placed in scopes of this type.
 - Special instructions on how to organise or write content in scopes of this type.
 
-#### 05-def-instance-declaration
+#### 06-def-instance-declaration
 
 A scope that is an instance of one or more scope types MUST declare `scope-type` in its `index.md` frontmatter. Two formats are valid:
 
 - **Single type**: `scope-type: business-area`
 - **Multiple types** (comma-separated): `scope-type: compiled, internal-docs, auditable`
 
-When multiple scope types are declared, all rules from all declared types (and their parent chains) apply simultaneously to documents in the scope. A document MUST satisfy the requirements of every applicable type. When two types define a rule with the same rule number but different content, the conflict MUST be declared in a `## Conflicts` section of the overriding scope-type policy (see Section C rule 19-conflict-declarations). An undeclared conflict makes a document impossible to satisfy and MUST be resolved before authoring begins.
+When multiple scope types are declared, all rules from all declared types (and their parent chains) apply simultaneously to documents in the scope. A document MUST satisfy the requirements of every applicable type. When two types define a rule with the same rule number but different content, the conflict MUST be declared in a `## Conflicts` section of the overriding scope-type policy (see Section C rule 26-conflict-declarations). An undeclared conflict makes a document impossible to satisfy and MUST be resolved before authoring begins.
 
-#### 05b-def-multi-type-validation
+#### 07-def-multi-type-validation
 
-A comma-separated `scope-type` list MUST NOT have empty elements. Each element MUST satisfy the same constraints as a single `scope-type` value (rules 06 and 08). Duplicate values within the same list are NOT allowed.
+A comma-separated `scope-type` list MUST NOT have empty elements. Each element MUST satisfy the same constraints as a single `scope-type` value (rules 08 and 10). Duplicate values within the same list are NOT allowed.
 
-#### 06-def-no-underscore-prefix
+#### 08-def-no-underscore-prefix
 
 Custom scope-type names MUST NOT start with `_`. The `_` prefix is reserved for built-in scope types defined in `_core` (currently only `_local`).
 
-#### 07-def-parent-scope-type
+#### 09-def-parent-scope-type
 
-A scope-type definition policy MAY declare a parent scope type by including a rule titled `NN-parent-scope-type` in its `### Details` section. The body of that rule MUST reference the parent scope-type name in backticks (e.g., "Instances of this scope type inherit all rules from the `standard` scope type."). This rule MUST appear only in the **primary** file (rule 02), not in a companion file (rule 02b). Tools and agents MUST resolve the full parent chain transitively. Child scope-type standards override parent standards on any conflict.
+A scope-type definition policy MAY declare a parent scope type by including a rule titled `NN-parent-scope-type` in its `### Details` section. The body of that rule MUST reference the parent scope-type name in backticks (e.g., "Instances of this scope type inherit all rules from the `standard` scope type."). This rule MUST appear only in the **primary** file (rule 02), not in a companion file (rule 03). Tools and agents MUST resolve the full parent chain transitively. Child scope-type standards override parent standards on any conflict.
 
-#### 08-def-valid-iff-policy-exists
+#### 10-def-valid-iff-policy-exists
 
 A `scope-type` value in a scope `index.md` is valid if and only if a policy file whose name ends with `{scope-type}-scope-type` exists in the `principles` subject of any `core`-type scope in the workspace. Tools (such as `xdrs-core lint`) MUST enforce this for every element when `scope-type` is an array.
 
-When a scope declares a `scope-type` (single or array) but any corresponding `{scope-type}-scope-type.md` policy is absent from the workspace, the scope MUST be treated as READ-ONLY by all tools and agents: content in it MUST NOT be added, changed, or removed, and its content MUST NOT be reviewed. Tools and agents MUST surface the read-only status to the user and MUST NOT propose or apply any changes until the scope-type governance is installed.
+When a scope declares a `scope-type` but any corresponding `{scope-type}-scope-type.md` policy is absent from the workspace, the scope MUST be treated as READ-ONLY: content MUST NOT be added, changed, removed, or reviewed. Tools MUST surface the read-only status and MUST NOT apply changes until the scope-type governance is installed.
 
-#### 08b-def-scope-type-must-be-structured
+#### 11-def-scope-type-must-be-structured
 
-All `{scope-type}-scope-type.md` policies (primary and companion files) MUST follow the structured format defined in `_core-adr-policy-008`: the policy MUST contain a `### Details` section and at least one `#### NN-rulename` rule block within it. This makes individual scope-type rules machine-readable, individually citable, and detectable for conflict analysis. Tools MUST enforce this and report an error using code `_core-adr-policy-010-scope-governance.08b-def-scope-type-must-be-structured`.
+All `{scope-type}-scope-type.md` policies (primary and companion files) MUST follow the structured format defined in `_core-adr-policy-008`: the policy MUST contain a `### Details` section and at least one `#### NN-rulename` rule block within it. This makes individual scope-type rules machine-readable, individually citable, and detectable for conflict analysis. Tools MUST enforce this and report an error using code `_core-adr-policy-010-scope-governance.11-def-scope-type-must-be-structured`.
 
-#### 08c-def-core-scope-policies-must-be-structured
+#### 12-def-core-scope-policies-must-be-structured
 
-All policy files in a `core`-type scope (a scope whose `index.md` declares `scope-type: core`) MUST follow the structured format defined in `_core-adr-policy-008` (see rule 08b). This requirement applies to ALL policies in the scope, not only scope-type definitions or local meta-policies. The `_core` scope itself is exempt from this requirement until its existing policies are migrated. Tools MUST enforce this for all non-exempt core-type scopes and report an error using code `_core-adr-policy-010-scope-governance.08c-def-core-scope-policies-must-be-structured`.
+All policy files in a `core`-type scope (a scope whose `index.md` declares `scope-type: core`) MUST follow the structured format defined in `_core-adr-policy-008` (see rule 11). This requirement applies to ALL policies in the scope, not only scope-type definitions or local meta-policies. The `_core` scope itself is exempt from this requirement until its existing policies are migrated. Tools MUST enforce this for all non-exempt core-type scopes and report an error using code `_core-adr-policy-010-scope-governance.12-def-core-scope-policies-must-be-structured`.
 
 ---
 
 **Section B — Local meta-policies**
 
-#### 09-local-naming
+#### 13-local-naming
 
-The word `core` as a hyphen-delimited segment in a policy filename title is reserved for local meta-policies. A local meta-policy is identified by its filename title starting with `core`: either `NNN-core.md` (primary, no qualifier) or `NNN-core-{qualifier}.md` (companion, where `{qualifier}` is a short lowercase kebab-case descriptor). A policy filename title MUST NOT use `core` as a word segment unless it is a valid local meta-policy (see rule 10). Scope-type definition files (`NNN-{scope-type}-scope-type.md`) are exempt from this restriction even when their title begins with `core`.
+The word `core` as a hyphen-delimited segment in a policy filename title is reserved for local meta-policies. A local meta-policy is identified by its filename title starting with `core`: either `NNN-core.md` (primary, no qualifier) or `NNN-core-{qualifier}.md` (companion, where `{qualifier}` is a short lowercase kebab-case descriptor). A policy filename title MUST NOT use `core` as a word segment unless it is a valid local meta-policy (see rule 14). Scope-type definition files (`NNN-{scope-type}-scope-type.md`) are exempt from this restriction even when their title begins with `core`.
 
-#### 10-local-placement
+#### 14-local-placement
 
 Local meta-policy files MUST be placed in the `principles` subject of any type folder within the scope they govern (e.g., `my-team/adrs/principles/001-core.md`). They apply implicitly to that scope — no declaration in `index.md` is required. Local meta-policies MUST NOT be placed in any other subject folder; a file whose title starts with `core` in a non-`principles` subject is a lint error.
 
-#### 10b-local-primary-required
+#### 15-local-primary-required
 
 A companion local meta-policy (`NNN-core-{qualifier}.md`) MUST NOT exist in a type folder unless a primary local meta-policy (`NNN-core.md`) also exists in the **same** type folder. Tools MUST enforce this constraint.
 
-#### 10c-local-unique-qualifier
+#### 16-local-unique-qualifier
 
 Each qualifier (including the blank qualifier of the primary) MUST be unique across all type folders within the same scope. For example, a scope MUST NOT have both `adrs/principles/001-core.md` and `bdrs/principles/001-core.md` — the blank qualifier would appear twice.
 
-#### 11-local-optional
+#### 17-local-optional
 
 Creating a local meta-policy is optional. It SHOULD be created when a scope has specific structural, authoring, or content constraints that differ from `_core` defaults or the scope's declared scope-type standards.
 
-#### 12-local-content
+#### 18-local-content
 
-A local meta-policy SHOULD define the same kinds of instructions as a scope-type definition policy (rules 03–04 above): naming conventions for content in the scope, allowed content, forbidden content, and organisation rules. These instructions apply only to policy documents authored in this one scope; they do not govern non-policy artifacts (skills, articles, plans, research). Local meta-policies and their companion files MAY include a `## Conflicts` section to declare that one of their rules overrides a conflicting rule from a scope-type policy or `follows:` scope policy (see Section C rule 19-conflict-declarations).
+A local meta-policy SHOULD define the same kinds of instructions as a scope-type definition policy (rules 04–05 above): naming conventions for content in the scope, allowed content, forbidden content, and organisation rules. These instructions apply only to policy documents authored in this one scope; they do not govern non-policy artifacts (skills, articles, plans, research).
 
-#### 12b-local-must-be-structured
+#### 19-local-must-be-structured
 
-All local meta-policy files (`NNN-core.md` and `NNN-core-{qualifier}.md`) MUST follow the structured format defined in `_core-adr-policy-008` (see rule 08b). Tools MUST enforce this and report an error using code `_core-adr-policy-010-scope-governance.12b-local-must-be-structured`.
+All local meta-policy files (`NNN-core.md` and `NNN-core-{qualifier}.md`) MUST follow the structured format defined in `_core-adr-policy-008` (see rule 11). Tools MUST enforce this and report an error using code `_core-adr-policy-010-scope-governance.19-local-must-be-structured`.
 
-#### 13-local-mandatory-when-present
+#### 20-local-mandatory-when-present
 
 When one or more local meta-policies exist in a scope, tools and agents MUST load and apply ALL of them as mandatory conventions when authoring or reviewing **policy documents** in that scope. If any found local meta-policy file is unreadable, tools MUST halt and report an error before proceeding.
 
@@ -134,24 +132,24 @@ When one or more local meta-policies exist in a scope, tools and agents MUST loa
 
 **Section C — Governance application and precedence**
 
-#### 14-application-follows
+#### 21-application-follows
 
 Tools and agents MUST apply the policies of all scopes listed in a scope's `follows:` frontmatter as mandatory conventions, in addition to `_core`. When the same topic is addressed by multiple `follows:` scopes, the last-listed scope MUST take precedence on conflicts.
 
-#### 15-application-scope-type
+#### 22-application-scope-type
 
 When adding or reviewing content in a scope, tools and agents MUST:
 
-1. Read the scope's `scope-type` from its `index.md`. Normalise the value to a list: split on commas and trim whitespace; a single value with no comma becomes a one-element list.
+1. Read the scope's `scope-type` from its `index.md`. Normalise to a list: split on commas and trim whitespace.
 2. For each declared type in list order, resolve its full ancestor chain:
-   a. Search the `[type]/principles/` directories of all `core`-type scopes in the workspace for the `{scope-type}-scope-type.md` primary file.
-   b. If found, load the primary and all companion files (`{scope-type}-scope-type-{qualifier}.md`) from the **same directory**. Companions are loaded in alphabetical order by qualifier.
-   c. If the primary contains a rule titled `NN-parent-scope-type`, extract the parent type name (backtick-quoted identifier in the rule body) and repeat steps a–c for the parent. Continue until no more parents are declared. Detect and stop on cycles.
-3. Concatenate all resolved ancestor chains in declaration order to form a single flat list (e.g., for `scope-type: [reference, platform]` where `reference → standard` and `platform → core`: `[standard, reference, core, platform]`).
-4. Deduplicate the flat list keeping the **first occurrence** of each type (preserves the ancestor semantics of whichever type introduced the parent earliest).
-5. Apply all policies from the deduplicated list as mandatory conventions. Later entries in the list override earlier entries when the same rule number appears with different content, provided the override is declared (see rule 19-conflict-declarations).
+   a. Search `[type]/principles/` directories of all `core`-type scopes for the `{scope-type}-scope-type.md` primary file.
+   b. If found, load the primary and all companion files (`{scope-type}-scope-type-{qualifier}.md`) from the **same directory**, in alphabetical qualifier order.
+   c. If the primary contains a rule titled `NN-parent-scope-type`, extract the parent type name and repeat steps a–c. Detect and stop on cycles.
+3. Concatenate all resolved ancestor chains in declaration order to form a flat list (e.g., `scope-type: [reference, platform]` where `reference → standard`, `platform → core`: `[standard, reference, core, platform]`).
+4. Deduplicate keeping the **first occurrence** of each type.
+5. Apply all policies from the deduplicated list as mandatory conventions. Later entries override earlier entries on same rule number conflicts (see rule 26-conflict-declarations).
 
-#### 16-application-local
+#### 23-application-local
 
 When adding or reviewing **policy documents** in a scope, tools and agents MUST:
 
@@ -159,23 +157,21 @@ When adding or reviewing **policy documents** in a scope, tools and agents MUST:
 2. If any are found, read and apply ALL of them as mandatory conventions. If a found file is unreadable, halt with an error before proceeding.
 3. If none are found, continue without error — absence of local meta-policies is valid.
 
-#### 17-precedence
+#### 24-precedence
 
 When multiple governance layers define a rule with the same rule number, the later entry in the following ordered chain takes precedence (lowest to highest):
 
-1. All scope-types in the deduplicated ancestor chain (rule 15), in chain order — earlier entries are overridden by later entries.
+1. All scope-types in the deduplicated ancestor chain (rule 22), in chain order — earlier entries are overridden by later entries.
 2. `follows:` scope policies (applied in `follows:` list order; last-listed scope wins among themselves).
 3. Local meta-policies (`NNN-core.md` and companions in alphabetical qualifier order).
 
-In all cases, an override is valid only if the overriding policy contains a `## Conflicts` section that explicitly declares the conflict with the overridden rule (see rule 19-conflict-declarations). A conflict that is not declared MUST be surfaced as an error by tools and agents; the content cannot be validated until the conflict is resolved.
-
 All of the above are subordinate to `_core` structural rules, which MUST NOT be overridden.
 
-#### 18-ordering-custom-types
+#### 25-ordering-custom-types
 
 Custom-type scopes SHOULD be placed in the `standard` position in the root `index.md` ordering (i.e., after `platform` scopes and before `_local`).
 
-#### 19-conflict-declarations
+#### 26-conflict-declarations
 
 When a policy (scope-type definition, local meta-policy, or companion) overrides a rule defined by a lower-precedence policy in the governance chain, the overriding policy MUST include a `## Conflicts` section that declares:
 
@@ -183,9 +179,61 @@ When a policy (scope-type definition, local meta-policy, or companion) overrides
 - The policy file where the original rule is defined.
 - A short explanation of why the override is required for this scope or type.
 
-A `## Conflicts` section MAY also document cross-scope-type incompatibilities for informational purposes — cases where two declared scope types define the same rule number differently and the content author needs to know which definition wins. Tools and agents MUST detect undeclared conflicts at review time (rules with the same number defined differently in the loaded chain) and surface them as errors. Semantic conflict detection (two rules with different numbers that are logically incompatible) is the responsibility of the authoring agent, not the lint tool.
+A `## Conflicts` section MAY also document cross-scope-type incompatibilities for informational purposes. Tools and agents MUST detect undeclared conflicts at review time and surface them as errors. Semantic conflict detection is the responsibility of the authoring agent, not the lint tool.
 
 ## References
 
 - [_core-adr-policy-011 - core scope type](011-core-scope-type.md) — defines the `core` scope type and when to use a `-core` sibling scope vs. a scope-local policy
-- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — scope structure, `follows:` field definition, scope index frontmatter fields
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — scope structure, `follows:` and `extends:` field definitions, scope index frontmatter fields
+
+---
+
+**Section D — Scope extends**
+
+#### 27-extends-declaration
+
+A scope MAY declare an `extends:` field in its `index.md` YAML frontmatter. The value MUST be a single scope name or a comma-separated list (YAML list format also valid). The field causes all **policy documents** (decision records only — skills, articles, research, and plans are NOT inherited) from the listed scopes to be treated as if authored in the extending scope. Valid for all scope types.
+
+#### 28-extends-disjoint
+
+The `extends:` field and the `follows:` field MUST reference disjoint sets of scope names. The same scope MUST NOT appear in both fields. Tools MUST enforce this and report an error using code `_core-adr-policy-010.28-extends-disjoint`.
+
+#### 29-extends-reserved-scopes
+
+A scope `extends:` declaration MUST NOT reference the reserved scope names `_local` or `_core` by name. `_local` is workspace-only and non-distributable; `_core` policies are always applied implicitly to every scope and extending them would be redundant. Tools MUST enforce this and report an error using code `_core-adr-policy-010.29-extends-reserved-scopes`.
+
+#### 30-extends-no-self
+
+A scope `extends:` declaration MUST NOT reference the declaring scope itself. Tools MUST enforce this and report an error using code `_core-adr-policy-010.30-extends-no-self`.
+
+#### 31-extends-no-cycle
+
+`extends:` declarations MUST NOT form circular chains (e.g., scope A extends B, B extends A). Tools MUST detect such cycles across the full workspace and report an error using code `_core-adr-policy-010.31-extends-no-cycle`, identifying the cycle.
+
+#### 32-extends-mandatory-presence
+
+Every scope listed in a scope's `extends:` field MUST exist in the workspace with an accessible `index.md`. If any referenced scope is absent or its `index.md` cannot be read, all READ, WRITE, and REVIEW operations on the extending scope MUST fail immediately. Tools MUST surface a clear message naming the missing scope and citing code `_core-adr-policy-010.32-extends-mandatory-presence`.
+
+#### 33-extends-content-precedence
+
+When loading the effective policy set for a scope, tools and agents MUST resolve the full `extends:` chain depth-first and apply the following content precedence (lowest to highest):
+
+1. Transitively extended scopes, in depth-first order, deduplicated keeping first occurrence. For A extends [B, C] where B itself extends [D]: resolved order is D < B < C.
+2. The extending scope's own policy documents (always take highest precedence and override all inherited policies).
+
+Deduplication: if the same scope name appears more than once in the depth-first traversal, keep only the first occurrence. When a scope's policy overrides an inherited policy on the same topic, the overriding policy MUST include a `## Conflicts` section (see rule 34).
+
+Note: the `extends:` content-precedence chain is independent of Section C rule 24. `extends:` determines which policy documents are in scope; rule 24 determines which authoring rules apply.
+
+#### 34-extends-conflict-declaration
+
+When an extending scope's own policy addresses the same topic as a policy in an extended scope, or when two extended scopes address the same topic differently, the higher-precedence policy MUST include a `## Conflicts` section that:
+
+- Names the conflicting policy (scope and policy ID) being overridden or superseded.
+- Explains why the override or difference exists.
+
+An undeclared semantic conflict between policies from the `extends:` chain MUST be surfaced as an error during review (see `_core-adr-policy-010.34-extends-conflict-declaration`).
+
+#### 35-extends-index
+
+Scopes referenced only via `extends:` chains and not linked in the root `index.md` are **exempt** from the "root index must link all scopes" requirement. These scopes form the building-block layer; the root index lists only entry scopes. If a scope is both referenced via `extends:` AND linked in the root index, tools SHOULD warn of ambiguous dual precedence (the root index ordering governs for consumers that do not interpret `extends:` declarations), using warning code `_core-adr-policy-010.35-extends-index`.

package/.xdrs/_core/adrs/principles/018-external-path-symlinks.md

@@ -19,7 +19,7 @@ How should XDRS files be made accessible from paths outside the `.xdrs/` root wi
 
 **Symlinks from external paths to the canonical `.xdrs/` location**
 
-When a file or directory inside `.xdrs/` needs to be reachable from an external path, a symlink MUST be created at the external path pointing to the canonical `.xdrs/` location. The canonical file always lives inside `.xdrs/`. Copying is never acceptable.
+When a file or directory inside `.xdrs/` needs to be reachable from an external path, a symlink MUST be created at the external path pointing to the canonical `.xdrs/` location. The canonical file MUST remain inside `.xdrs/`. Files MUST NOT be copied to external paths.
 
 **Example:** `.agents/skills/001-review` (symlink) → `.xdrs/_core/adrs/principles/skills/001-review/`
 

package/.xdrs/_core/adrs/principles/019-compiled-scope-type.md

@@ -0,0 +1,117 @@
+---
+name: _core-adr-policy-019-compiled-scope-type
+description: Defines the `compiled` scope type — scopes whose policies are compiled strictly from external authoritative sources (web pages, git repositories, or local folders). All content must trace back to source; no invented content is permitted. The type may be combined with other scope types. Use when declaring a compiled-type scope, authoring content in a compiled scope, or configuring the compilation process.
+apply-to: All XDRS scope authors declaring compiled-type scopes; tools or agents compiling or reviewing compiled scopes
+valid-from: 2026-08-03
+---
+
+# _core-adr-policy-019: compiled scope type
+
+## Context and Problem Statement
+
+Some XDRS scopes exist to provide structured policy representations of external authoritative sources — industry standards, regulatory frameworks, vendor documentation, or reference materials published on the web, in git repositories, or in local folders. The content of these scopes must remain strictly faithful to the source: editorial additions, invented rules, and inferences beyond what the source states are not permitted.
+
+These scopes differ structurally from `reference`, `platform`, and `standard` scopes: they are defined by a systematic compilation process, require source traceability in every policy, and must document any inconsistencies found in the source rather than silently correcting them.
+
+How should a scope that exists solely as a compiled representation of external sources be identified and governed?
+
+## Decision Outcome
+
+**Declare `scope-type: compiled` for any scope whose policies are compiled directly from one or more external sources, where all content must trace back to the source and no invention is permitted.**
+
+### Details
+
+#### 01-scope-type-name
+
+The scope type defined by this policy is `compiled`. A scope MUST declare it by setting `scope-type: compiled` in its `index.md` YAML frontmatter. The `compiled` type MAY be combined with one or more other scope types using a comma-separated list (e.g., `scope-type: compiled, reference`).
+
+#### 02-when-to-use
+
+Use `scope-type: compiled` when the scope holds policies that are directly compiled from external authoritative sources and where the primary governance constraint is source fidelity, not editorial judgment. Examples include:
+
+- Policies compiled from industry standards (e.g., OWASP Top 10, NIST guidelines, ISO 27001 controls).
+- Policies compiled from vendor documentation, product specifications, or API contracts.
+- Policies compiled from regulatory texts, compliance frameworks, or legal documents.
+- Policies compiled from internal reference documents published in another repository or folder.
+
+`scope-type: compiled` MUST NOT be used for scopes that contain policies authored from scratch, derived from general knowledge, or editorially synthesised without a direct external source.
+
+#### 03-naming-convention
+
+`compiled`-type scopes have no required naming pattern. Any valid scope name MAY be used. When `compiled` is combined with another type (e.g., `scope-type: compiled, reference`), the naming convention of the non-`compiled` type MUST apply.
+
+#### 04-structured-format-required
+
+All policies in a `compiled` scope MUST use the structured policy format defined in `_core-adr-policy-008`. Every claim or rule originating from the source MUST be expressed as an individually referenceable numbered rule block.
+
+#### 05-source-traceability
+
+Every policy claim, rule body, and normative statement in a `compiled` scope MUST be traceable to at least one external source. Content MUST NOT be invented, inferred beyond what the source states, or filled in to cover gaps. Where the source is ambiguous or contradictory, the ambiguity or contradiction MUST be transcribed faithfully and documented as an inconsistency per rule 08.
+
+XDRS structural frontmatter fields (`name`, `description`, `apply-to`, `valid-from`) are explicitly exempt from this rule. These fields are generated from source text by the compilation process and are not considered invented content.
+
+#### 06-source-types
+
+Sources for a compiled scope MAY be specified as:
+
+- A web URL pointing to a publicly accessible page or document.
+- A git repository URL (e.g., `git@github.com:org/repo.git` or `https://github.com/org/repo.git`) pointing to a repository containing the source content.
+- A local folder path relative to the workspace root.
+
+When multiple source entries point to the same content (e.g., a web page and its git mirror), all MAY be listed so that the compilation process can use whichever source is accessible. The preference order for fetching is: git URL first, then local folder, then web URL.
+
+#### 07-compilation-meta-policy
+
+Before any compilation begins, at least one local meta-policy file named `NNN-core.md` MUST exist in a `[type]/principles/` directory of the target scope (e.g., `adrs/principles/001-core.md`). Compilation tools and agents MUST scan all type folders (`adrs`, `bdrs`, `edrs`) for such meta-policy files; each meta-policy governs compilation for its own type folder.
+
+The meta-policy MUST contain the following sections:
+
+- `## Sources` — one bullet per source using the format `- [web] https://...`, `- [git] git@...`, or `- [local] ./path`. Each source entry MAY include an inline description after the URL.
+- `## Selectors` — describes which portions of the fetched source to include or exclude, expressed as document sections, filename patterns, topics, or other criteria.
+
+The meta-policy MAY also contain:
+
+- `## Fetch Procedures` — special instructions for fetching the source (authentication, crawl depth, pagination, format conversion, etc.).
+- `## Compilation Notes` — guidance on how to structure or categorise the compiled content.
+- `## Review Notes` — guidance for reviewers verifying compiled content against the source.
+
+#### 08-inconsistencies-policy
+
+If the source contains inconsistencies, contradictions, errors, or gaps that cannot be faithfully transcribed as a valid policy, the compiled scope MUST document them in a dedicated policy file at `[type]/principles/NNN-inconsistencies-from-source.md`. Each inconsistency MUST reference the source file path and the affected compiled policy. Inconsistencies MUST NOT be silently corrected, omitted, or worked around.
+
+#### 09-ordering
+
+There is no fixed position for `compiled`-type scopes in the root `index.md`. When `compiled` is combined with another type, the ordering convention of the non-`compiled` type governs placement. When declared standalone, a `compiled` scope MAY appear at any position before `_local`.
+
+#### 10-source-section
+
+Every compiled policy MUST include a `## Source` section placed after the `## References` section (or after `## Decision Outcome` when no `## References` section is present). The section MUST list the relative file path(s) of the source document(s) used to produce the policy as plain text. Paths MUST NOT be written as markdown links, because the source files exist only inside a temporary local directory that is created during the compilation or review process.
+
+Example:
+
+```
+## Source
+
+- source-1/standards/owasp-top-10-2021/A01-broken-access-control.md
+- source-2/docs/security-controls.html
+```
+
+#### 11-compilation-notes
+
+Rule bodies in compiled policies SHOULD include `**compilation-note:**` inline markers when the mapping from source to rule is not obvious — for example: indirect references, conclusions drawn from multiple source sections, or interpretations that required judgment. Direct literal transcriptions of a single source statement do not require a marker. Review and update processes MUST consult these notes and re-fetch the source before making changes to compiled rules.
+
+Example:
+
+```
+#### 03-access-control-must-enforce-least-privilege
+
+All access control implementations MUST enforce the principle of least privilege.
+**compilation-note:** derived from OWASP A01:2021 "How to Prevent", bullet 3 — "Deny by default".
+```
+
+## References
+
+- [_core-adr-policy-008 - Policy structured standards](008-policy-structured-standards.md) — numbered rule format required for all policies in compiled scopes
+- [_core-adr-policy-010 - Scope governance](010-scope-governance.md) — scope-type definition convention and local meta-policy mechanism
+- [_core-adr-policy-002 - Policy standards](002-policy-standards.md) — policy document format and frontmatter requirements
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — scope structure and `scope-type` field definition

package/.xdrs/_core/adrs/principles/skills/.assets/lint-verification.md

@@ -0,0 +1,12 @@
+# XDRS Lint Verification
+
+This module is shared across all XDRS writing skills. Run these steps after all files have been written.
+
+---
+
+1. Run the CLI lint utility from the repository root:
+   ```
+   npx -y xdrs-core@latest lint
+   ```
+2. Fix all reported errors before considering the task complete.
+3. Review warnings; fix straightforward ones and note intentional deviations explicitly.

package/.xdrs/_core/adrs/principles/skills/.assets/meta-policy-compliance.md

@@ -0,0 +1,12 @@
+# XDRS Meta-Policy Compliance Check
+
+This module is shared across XDRS writing skills. Read and execute every check during the final review of a document.
+
+Substitute `[DOCUMENT]` with the appropriate noun for the calling skill: `policy`, `skill`, `article`, `research`, or `plan`.
+
+---
+
+**Meta-policy compliance**: Check the target scope's `index.md` for a `follows` frontmatter field. `_core` Policies always apply to all scopes. If `follows` lists additional core scope names (e.g., `follows: [myarea-core]`), verify that each listed scope directory exists in the workspace (e.g., `.xdrs/[scope-name]/index.md`). If any listed scope is missing, STOP immediately and tell the user: "Scope `[scope-name]` is listed in `follows` but not found in the workspace. Install it before proceeding." Once all `follows` scopes are confirmed present, verify the [DOCUMENT] satisfies all requirements from those Policies. Scopes are applied in order; last-listed scope in `follows` takes precedence when the same topic is covered by multiple scopes.
+
+- **Scope-type standards:** Read the target scope's `scope-type`. Normalise the value to a list: split on commas and trim whitespace (`scope-type: typeA, typeB` becomes `[typeA, typeB]`). For **each** type in the list, search the `[type]/principles/` directories of all `core`-type scopes for a file ending in `{scope-type}-scope-type.md`. If found, also load all companion files (`{scope-type}-scope-type-{qualifier}.md`) from the **same directory** and apply their rules as additional requirements. Resolve any `NN-parent-scope-type` rule transitively from the primary file. See `_core-adr-policy-010` rules 22 and 24.
+- **Scope-local standards:** Scan the target scope's own `[type]/principles/` directories for all files whose filename title starts with `core` (i.e., `NNN-core.md` or `NNN-core-{qualifier}.md`), excluding scope-type definition files (whose title ends with `-scope-type`). If any are found, apply ALL of them as mandatory requirements; they override scope-type standards on conflict. See `_core-adr-policy-010` rules 23 and 24.

package/.xdrs/_core/adrs/principles/skills/.assets/prerequisites-gate.md

@@ -0,0 +1,19 @@
+# XDRS Prerequisites Gate
+
+This module is shared across all XDRS writing skills. Read these instructions in full and execute every check before proceeding with any authoring task.
+
+Substitute `[DOCUMENT TYPE]` with the appropriate noun for the calling skill: `policy`, `skill`, `article`, `research`, `plan`, `presentation`, or `document`.
+
+---
+
+Read the confirmed scope's `index.md` frontmatter and perform ALL of the following checks. If ANY check fails, output a FAIL result immediately and do not proceed:
+
+- **Follows scopes:** If the scope declares `follows:` entries (e.g., `follows: myarea-core, shared-standards`), verify that each listed scope directory exists in the workspace AND contains an accessible `index.md` (e.g., `.xdrs/[scope-name]/index.md`). If any listed scope is missing or unreadable, output: `FAIL — Cannot proceed: scope \`[scope-name]\` is listed in \`follows\` but its policies are not present in the workspace. Install it before authoring documents in this scope, as the governance constraints cannot be verified.`
+- **Extends scopes:** If the scope declares `extends:` entries, verify that each listed scope directory exists in the workspace AND contains an accessible `index.md`. If any listed scope is missing or unreadable, output: `FAIL — Cannot proceed: scope \`[scope-name]\` is listed in \`extends\` but its policies are not present in the workspace. Install it before authoring documents in this scope, as inherited policies cannot be verified.`
+- **Local meta-policies:** Scan the target scope's `[type]/principles/` directories for all files whose filename title starts with `core` (i.e., `NNN-core.md` or `NNN-core-{qualifier}.md`), excluding scope-type definition files. If any are found but cannot be read, output: `FAIL — Cannot proceed: local meta-policy \`[filename]\` exists in scope \`[scope-name]\` but could not be read. Without it, the [DOCUMENT TYPE] cannot be authored in full compliance with the scope's governance.` Zero matches is valid.
+- **Scope-type:** Read the scope's `scope-type` from its `index.md`. Normalise the value to a list: split on commas and trim whitespace (`scope-type: typeA, typeB` becomes `[typeA, typeB]`). For **each** type in the list, search the `[type]/principles/` directories of all `core`-type scopes in the workspace for a file whose name ends with `{scope-type}-scope-type.md`. If the scope declares any `scope-type` elements but no matching file is found for ANY of them, output: `FAIL — Cannot proceed: scope \`[scope-name]\` declares \`scope-type: [scope-type]\` but no \`[scope-type]-scope-type.md\` policy exists in any \`core\`-type scope in the workspace. The scope is READ-ONLY; install the scope-type governance before authoring documents in this scope.`
+- **Rationale:** Authoring a document without all mandatory governance layers loaded risks producing content that silently violates scope policies. Every governance layer MUST be present before writing begins.
+
+Once all prerequisites pass, load ALL scope-type governance (see `_core-adr-policy-010` rule 22): for each declared type, resolve its full ancestor chain (primary, companions alphabetically, parent chain). Deduplicate keeping first occurrence. Then run conflict detection using the shared module at `.xdrs/_core/adrs/principles/skills/.assets/conflict-detection.md` across all loaded governance layers. Halt if undeclared structural conflicts are found (see `_core-adr-policy-010` rules 24 and 26).
+
+If the scope declares `extends:` entries (and the extends check above passed), load the inherited **policy documents** (decision records only — not skills, articles, research, or plans) from the full `extends:` chain using depth-first resolution (see `_core-adr-policy-010` rule 33): for each extends entry in declaration order, recursively resolve that scope's own `extends:` chain, then append the scope's own policies. Deduplicate keeping first occurrence. The extending scope's own policies always take precedence over all inherited ones. Apply the resolved policy set as additional context when authoring or reviewing [DOCUMENT TYPE] documents in this scope.

package/.xdrs/_core/adrs/principles/skills/.assets/scope-placement.md

@@ -0,0 +1,47 @@
+# XDRS Scope Placement Analysis
+
+This module is shared across XDRS writing skills. Run this analysis **before** the prerequisites gate to determine and confirm the target scope for the document being authored.
+
+---
+
+## Step A — Check User-Stated Scope
+
+If the user explicitly named a target scope in their request, note it as the proposed scope and proceed to Step C for validation. Do not skip validation even when a scope is stated — the content must match the scope's purpose.
+
+If no scope was stated, proceed to Step B.
+
+## Step B — Analyze Content Nature
+
+Determine the appropriate scope-type by matching the content being authored to one of the types below. A scope may declare multiple types (`scope-type: typeA, typeB`); a scope is a candidate if ANY of its declared types match.
+
+| Content nature | Scope-type | Reference policy |
+|---|---|---|
+| Authoring standards, writing templates, or governance rules intended to be shared across **multiple related scopes** | `core` | ADR-011 |
+| Industry standards, compliance frameworks, reference architectures, or canonical blueprints to be adopted or adapted | `reference` | ADR-012 |
+| Live services, active shared platforms, or existing infrastructure that can be consumed directly | `platform` | ADR-013 |
+| Business area, product line, team, or general architectural/engineering decision | `standard` | ADR-014 |
+
+**Special case — local meta-policy**: If the content is governance or authoring standards that apply to **only one** target scope (not shared across multiple), the correct placement is a **local meta-policy file** (`NNN-core.md`) inside that scope's `[type]/principles/` directory, NOT a new scope. Recommend this option clearly and ask the user to confirm before continuing.
+
+## Step C — Enumerate and Rank Workspace Scopes
+
+1. Read `.xdrs/index.md` to list all declared scopes.
+2. For each scope whose `scope-type` matches the type identified in Step A or B (match if ANY of a scope's declared types fit), read its `index.md` and assess the following signals, in order of weight:
+   - **Primary**: Does `apply-to` or `description` describe a domain that covers this content?
+   - **Secondary**: Does the scope's `follows:` chain declare a governance relationship relevant to this content area?
+   - **Tertiary**: Does the scope contain local meta-policies (`NNN-core.md` files in `[type]/principles/`) that indicate it already governs this type of content?
+3. Rank all matching scopes from most to least relevant. Select the highest-ranked scope as the recommendation.
+4. If `_local` is the only scope in the workspace, recommend it as the default.
+
+## Step D — Handle Mismatches and Gaps
+
+- **Mismatch (user-stated scope)**: If the proposed scope from Step A has a `scope-type` that does not match the content nature identified in Step B, explain the mismatch with a clear rationale and ask the user to confirm the choice or select an alternative scope.
+- **No existing scope fits**: Recommend creating a new scope and provide naming guidance per scope-type:
+  - `core`: name MUST contain `core`; `-core` suffix preferred (e.g., `myarea-core`)
+  - `reference`: `{domain}-ref-{name}` pattern (e.g., `security-ref-iso27001`)
+  - `platform`: `{domain}-plat-{name}` pattern (e.g., `infra-plat-aws`)
+  - `standard`: any valid lowercase scope name (no special pattern required)
+
+## Step E — Confirm with User
+
+Present the recommended scope (or the proposed scope from Step A with any mismatch notes) and confirm with the user before proceeding to the prerequisites gate. Once confirmed, the scope is locked for the rest of the authoring workflow.

package/.xdrs/_core/adrs/principles/skills/.assets/scope-selection.md

@@ -0,0 +1,25 @@
+# XDRS Scope and Type Selection
+
+This module is shared across XDRS writing skills. Read and apply these instructions when selecting scope and type for a new document.
+
+---
+
+## Scope
+
+The scope was determined and confirmed in Phase 0 (scope placement analysis). Carry it forward. As a final safety check, verify the scope is not external:
+
+- Check the workspace root `.filedist.lock` file. If any file under `.xdrs/[scope]/` appears in `.filedist.lock`, 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
+
+Choose exactly one based on the nature of the decision:
+
+- **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
+
+When type cannot be confidently inferred, ask the user a clarifying question before proceeding. Ask one question at a time and wait for the answer.
+
+## Subject
+
+MUST read `_core-adr-policy-016` (`.xdrs/_core/adrs/principles/016-policy-subjects.md`) in full before choosing. That document defines all allowed subjects per type with full descriptions, examples, and disambiguation tiebreakers. Do not rely on summaries or prior knowledge — always read the policy and select the subject that best matches the topic according to its definitions.