xdrs-core 0.44.0 → 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

@@ -90,8 +90,10 @@ ADR and EDR share the same six technical subject names (see [`_core-adr-policy-0
     - `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/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
 
@@ -84,7 +82,7 @@ A scope-type definition policy MAY declare a parent scope type by including a ru
 
 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.
 
 #### 11-def-scope-type-must-be-structured
 
@@ -120,7 +118,7 @@ Creating a local meta-policy is optional. It SHOULD be created when a scope has
 
 #### 18-local-content
 
-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). 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 26-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).
 
 #### 19-local-must-be-structured
 
@@ -142,14 +140,14 @@ Tools and agents MUST apply the policies of all scopes listed in a scope's `foll
 
 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 26-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).
 
 #### 23-application-local
 
@@ -167,8 +165,6 @@ When multiple governance layers define a rule with the same rule number, the lat
 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 26-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.
 
 #### 25-ordering-custom-types
@@ -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/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.

package/.xdrs/_core/adrs/principles/skills/001-review/SKILL.md

@@ -30,13 +30,15 @@ Performs a structured review of code changes or files against the Policies in th
    - Check `valid-from:` first. If a date is present and has not yet been reached, the decision SHOULD be adopted for new implementations but is not enforced during reviews.
    - Check `apply-to:` second. Keep only Policies whose stated scope fits the files, systems, or workflows under review.
    - Check the decision text itself last for additional boundaries or exceptions that metadata does not encode.
-2. **Prerequisites gate — MUST complete before any review work:** For each scope containing files under review, read its `index.md` frontmatter and check for a `follows` field. `_core` Policies always apply to all scopes. Perform ALL of the following checks before proceeding; if ANY check fails, output a FAIL result immediately and do not continue the review:
+2. **Prerequisites gate — MUST complete before any review work:** For each scope containing files under review, read its `index.md` frontmatter and check for `follows` and `extends` fields. `_core` Policies always apply to all scopes. Perform ALL of the following checks before proceeding; if ANY check fails, output a FAIL result immediately and do not continue the review:
    - **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 its index is unreadable, output: `FAIL — Review cannot proceed: scope \`[scope-name]\` is listed in \`follows\` but its policies are not present in the workspace. Install it before reviewing, as compliance with its governance 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 its index is unreadable, output: `FAIL — Review cannot proceed: scope \`[scope-name]\` is listed in \`extends\` but its policies are not present in the workspace. Install it before reviewing, as inherited policies cannot be verified.`
    - **Local meta-policies:** Scan the 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 — Review cannot proceed: local meta-policy \`[filename]\` exists in scope \`[scope-name]\` but could not be read. Without it, full compliance cannot be verified.` Zero matches is valid — absence of local meta-policies is not an error.
    - **Rationale:** A review that silently omits mandatory governance layers produces false PASS results. Every governance layer declared by the scope MUST be loaded and applied; if any layer is inaccessible, the review result is unreliable and MUST be rejected.
    - **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 — Review 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 reviewing.`
    - Once all prerequisites pass, load the `follows` scopes' Policies and apply them as mandatory governance. Last-listed scope in `follows` takes precedence when the same topic is addressed by multiple scopes.
    - **Scope-type standards (application):** For each declared scope-type (single or comma-separated list), resolve its full ancestor chain (see `_core-adr-policy-010` rule 22): load the primary `{scope-type}-scope-type.md`, load all companion files (`{scope-type}-scope-type-{qualifier}.md`) alphabetically, then follow `NN-parent-scope-type` rules transitively until no more parents are declared. Stop on cycles. Concatenate all resolved chains in declaration order and deduplicate keeping first occurrence. Apply all policies from the deduplicated list as mandatory conventions. Then run conflict detection using the shared module at `.xdrs/_core/adrs/principles/skills/.assets/conflict-detection.md` across all loaded governance layers. See `_core-adr-policy-010` rules 22, 24, and 26 for the full application model.
+   - **Extends chain loading (policy documents only):** If the scope declares `extends:` entries (and the extends check above passed), load the inherited policy documents depth-first (see `_core-adr-policy-010` rule 33). For each extends entry in declaration order, recursively resolve that scope's own `extends:` chain, then append its policies. Deduplicate keeping first occurrence. The reviewing scope's own policies take precedence over all inherited policies. Apply the resolved extended policy set as additional context during the review — inherited policies MUST be evaluated for compliance just as if they were authored in this scope.
    - **Local meta-policies (policy documents only):** Apply all found local meta-policy files as mandatory conventions when reviewing policy documents in the scope. Local meta-policies take highest precedence in the chain. See `_core-adr-policy-010` rules 23, 24, and 26.
 3. Filter relevance based on file types, domains, and architectural patterns in scope.
 
@@ -47,6 +49,10 @@ Performs a structured review of code changes or files against the Policies in th
    - Classify as ERROR (mandatory) or WARNING (advisory).
    - Include: location, description, Policy reference (file + line), suggestion.
    - **Normative language check (Policy documents only):** For every Policy document in scope, verify that normative statements use uppercase BCP 14 keywords as required by `_core-adr-policy-001`. Flag as ERROR when a lowercase `must`, `must not`, `always`, or `never` is used in a normative requirement context (Details or Decision Outcome sections). Flag as WARNING when lowercase `should`, `should not`, `recommended`, `advised`, `may`, `possibly`, or `optionally` appear in a normative or permissive context where the uppercase form is expected. Context sections and question statements are exempt.
+   - **Extends chain conflict check:** If the reviewed scope has an `extends:` field, check for undeclared semantic conflicts in the following combinations (use AI judgment; report as ERROR citing `[_core-adr-policy-010.34-extends-conflict-declaration]` for each undeclared conflict found):
+     - Between the reviewing scope's own policies and policies from any extended scope (where the same topic is addressed differently and no `## Conflicts` section declares the override).
+     - Between two or more extended scopes that address the same topic differently without documented resolution.
+     - Between extended scopes' policies and the policies of **all scopes that appear after the reviewed scope in the root index** (those scopes have higher root-index precedence and silently override the inherited policy set for non-extends consumers; if no `## Conflicts` section exists in the later-listed scope's policy to acknowledge the inherited policy it overrides, flag as ERROR).
 2. Reduce false positives:
    - Evaluate ERROR findings for mandatory language in the Policy ("must", "always", "never", "required", "mandatory"). Drop or downgrade to WARNING if the language is advisory ("should", "recommended", "advised").
    - Remove findings unrelated to actual changes.

package/.xdrs/_core/adrs/principles/skills/002-write-policy/SKILL.md

@@ -14,16 +14,10 @@ Guides the creation of a well-structured Policy by following the standards in `_
 
 ## Instructions
 
-### Phase 0: Prerequisites Gate — MUST complete before writing
+### Phase 0: Scope Placement and Prerequisites Gate — MUST complete before writing
 
-Identify the target scope from the user's request; use `_local` if none is specified. Read the 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.`
-- **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 policy 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).
+1. Run the scope placement analysis from the shared module at `.xdrs/_core/adrs/principles/skills/.assets/scope-placement.md` to determine and confirm the target scope.
+2. Once the scope is confirmed, run the prerequisites gate from the shared module at `.xdrs/_core/adrs/principles/skills/.assets/prerequisites-gate.md`. Substitute `[DOCUMENT TYPE]` with `policy`.
 
 ### Phase 1: Understand the Decision
 
@@ -45,10 +39,7 @@ Consult `001-xdrs-standards` while making each choice in this phase. The summari
 - **ADR**: system context, integration pattern, overarching architectural choice
 - **EDR**: specific tool/library, coding practice, testing strategy, project structure
 
-**Scope** — use `_local` unless the user explicitly names another scope.
-- If the user names a scope other than `_local`, 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.
-
-**Subject** — MUST read `_core-adr-policy-016` ([016-policy-subjects.md](../../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 of the subject list — always read the policy and select the subject that best matches the decision topic according to its definitions.
+**Scope** — confirmed in Phase 0. Follow the external-scope validation and subject selection guidance in `.xdrs/_core/adrs/principles/skills/.assets/scope-selection.md`.
 
 When type, scope, or subject cannot be confidently inferred, ask the user a clarifying question before proceeding. Ask one question at a time and wait for the answer; follow up if the response introduces new ambiguity.
 
@@ -67,7 +58,7 @@ Choose a title that clearly states the question this Policy answers, not the ans
 
 ### Phase 4: Research Related Policies
 
-1. Read all existing Policies relevant to the topic across all scopes listed in the Policy root `index.md`.
+1. Read all existing Policies relevant to the topic across all scopes listed in the Policy root `index.md`. **Additionally**, if the target scope declares an `extends:` field in its `index.md`, resolve its full `extends:` chain depth-first (see `_core-adr-policy-010` rule 33) and treat all policy documents from those extended scopes as if they were authored in the target scope — they MUST be included in the research and conflict check just like policies written directly in the scope.
 2. Evaluate Policy metadata before treating any decision as a current constraint. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether it fits the current topic, and the decision text defines any remaining boundaries. Treat out-of-window or out-of-scope Policies as background only when assessing overlaps and conflicts.
 3. Identify decisions that already address the topic (full or partial overlap).
 4. Note decisions that might conflict with the intended outcome.
@@ -169,9 +160,7 @@ Check every item before finalizing:
 5. **Redundancy**: Is the Policy the primary source for the decision itself, with related documents linked instead of duplicated wherever possible?
 6. **Conflicts section**: Is it present and filled if Phase 3 found any conflicts?
 7. **Index entries**: Will the new Policy be added to `[scope]/[type]/index.md` and the Policy root `index.md`?
-8. **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.
+8. **Meta-policy compliance**: Run the shared module at `.xdrs/_core/adrs/principles/skills/.assets/meta-policy-compliance.md`. Substitute `[DOCUMENT]` with `policy`.
 
 If any check fails, revise and re-run this phase before proceeding.
 
@@ -186,12 +175,7 @@ If any check fails, revise and re-run this phase before proceeding.
 
 ### Phase 9: Verify Package structure with Lint
 
-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.
+Follow the lint verification steps in `.xdrs/_core/adrs/principles/skills/.assets/lint-verification.md`.
 
 ### Constraints
 

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

@@ -15,16 +15,10 @@ Guides the creation of a well-structured skill package by following `_core-adr-p
 
 ## Instructions
 
-### Phase 0: Prerequisites Gate — MUST complete before writing
+### Phase 0: Scope Placement and Prerequisites Gate — MUST complete before writing
 
-Identify the target scope from the user's request; use `_local` if none is specified. Read the 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.`
-- **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 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).
+1. Run the scope placement analysis from the shared module at `.xdrs/_core/adrs/principles/skills/.assets/scope-placement.md` to determine and confirm the target scope.
+2. Once the scope is confirmed, run the prerequisites gate from the shared module at `.xdrs/_core/adrs/principles/skills/.assets/prerequisites-gate.md`. Substitute `[DOCUMENT TYPE]` with `skill`.
 
 ### Phase 1: Understand the Skill Goal
 
@@ -46,10 +40,9 @@ Quick test:
 - "How to evaluate or decide on architecture?" → ADR
 - "How to execute a business process or policy?" → BDR
 
-**Scope** — use `_local` unless the user explicitly names another scope.
-- If the user names a scope other than `_local`, 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.
+**Scope** — confirmed in Phase 0. Follow the external-scope validation in `.xdrs/_core/adrs/principles/skills/.assets/scope-selection.md`.
 
-**Subject** — MUST read `_core-adr-policy-016` ([016-policy-subjects.md](../../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 of the subject list — always read the policy and select the most specific subject that matches the skill's activity domain.
+**Subject** — follow the subject selection guidance in `.xdrs/_core/adrs/principles/skills/.assets/scope-selection.md`.
 
 **Skill number** — scan `.xdrs/[scope]/[type]/[subject]/skills/` for the highest existing number and increment by 1. Never reuse numbers from deleted skills.
 
@@ -120,7 +113,7 @@ Before writing files, verify:
 3. **Length**: Under 6500 words? Trim verbose explanations.
 4. **Duplication**: Does this overlap an existing skill? If yes, revise.
 5. **References**: Are all related XDRs and skills linked, including the cases where the skill operationalizes multiple XDRs?
-6. **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, 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 skill's activation criteria, phase structure, and content satisfy any requirements from those Policies. Last-listed scope in `follows` takes precedence.
+6. **Meta-policy compliance**: Run the shared module at `.xdrs/_core/adrs/principles/skills/.assets/meta-policy-compliance.md`. Substitute `[DOCUMENT]` with `skill`.
 
 If any check fails, revise before continuing.
 
@@ -136,11 +129,7 @@ If any check fails, revise before continuing.
 
 ### Phase 7: Verify with Lint
 
-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.
+Follow the lint verification steps in `.xdrs/_core/adrs/principles/skills/.assets/lint-verification.md`.
 
 ### Constraints