xdrs-core 0.2.18 → 0.3.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -5,9 +5,9 @@
5
5
  We need a consistent way to capture decisions that scales across scopes and subjects, remains easy to navigate, and works well with AI agents.
6
6
 
7
7
  Decision Records can be of different kinds, depending on the nature of the decision:
8
- - ADR (Architectural Decision Record): captures architectural and technical decisions
9
- - BDR (Business Decision Record): captures business process and strategy decisions
10
- - EDR (Engineering Decision Record): captures engineering workflow and tooling decisions
8
+ - BDR (Business Decision Record): Captures business process, product features, procedures and strategic decisions. Examples: business rules, product policies, customer service, business workflow, control frameworks for regulators for finance, product procedures and manuals, KYC requirements, business requirements in general
9
+ - ADR (Architectural Decision Record): Wider architectural and technical decisions. Examples: how big topics relate to each other, system contexts, overview without realy deciding on details, integration patterns, overarching topics, corporate wide practices, corporate systems, external and internal partners etc
10
+ - EDR (Engineering Decision Record): captures engineering details about how to implement things. Examples: specific tools and libraries selection, framework usage, best practices on coding, testing, quality, project structure, pipelines etc
11
11
 
12
12
  Collectively, these are referred to as XDRs.
13
13
 
@@ -67,9 +67,9 @@ All XDRs MUST follow this template
67
67
  ## Context and Problem Statement
68
68
 
69
69
  [Describe the context, background, or need that led to this decision.
70
- What is the problem we are trying to solve? Who is being impacted? (~4 lines)
70
+ What is the problem we are trying to solve? Who is being impacted? (<3 lines)
71
71
 
72
- In the end, state explicitly the question that needs to be answered. E.g: "Which platform should I use when implementing an AI agent?"]
72
+ Question: In the end, state explicitly the question that needs to be answered. E.g: "Which platform should I use when implementing an AI agent?"]
73
73
 
74
74
  ## Decision Outcome
75
75
 
@@ -0,0 +1,109 @@
1
+ ---
2
+ name: 002-write-xdr
3
+ description: >
4
+ Creates a new XDR (Decision Record) interactively: selects type, scope, subject, and writes a focused, conflict-checked decision document.
5
+ Activate this skill when the user asks to create, add, or write a new XDR, ADR, BDR, or EDR.
6
+ metadata:
7
+ author: flaviostutz
8
+ version: "1.0"
9
+ ---
10
+
11
+ ## Overview
12
+
13
+ Guides the creation of a well-structured XDR by following the standards in `_core-adr-001`, researching existing records for conflicts, and iterating until the document is concise and decision-focused.
14
+
15
+ ## Instructions
16
+
17
+ ### Phase 1: Understand the Decision
18
+
19
+ 1. Read `.xdrs/index.md` to discover all active scopes and their canonical indexes.
20
+ 2. Read `.xdrs/_core/adrs/principles/001-xdr-standards.md` in full to internalize structure rules, mandatory language, and the XDR template.
21
+ 3. Ask the user (or infer from context) the topic of the decision. Do NOT proceed to Phase 2 without a clear topic.
22
+
23
+ ### Phase 2: Select Type, Scope, and Subject
24
+
25
+ **Type** — choose exactly one based on the nature of the decision:
26
+ - **BDR**: business process, product policy, strategic rule, operational procedure
27
+ - **ADR**: system context, integration pattern, overarching architectural choice
28
+ - **EDR**: specific tool/library, coding practice, testing strategy, project structure
29
+
30
+ **Scope** — use `_local` unless the user explicitly names another scope.
31
+
32
+ **Subject** — pick one from the allowed list for the chosen type (from `001-xdr-standards`):
33
+ - ADR: `principles`, `application`, `data`, `integration`, `platform`, `controls`, `operations`
34
+ - BDR: `principles`, `marketing`, `product`, `controls`, `operations`, `organization`, `finance`, `sustainability`
35
+ - EDR: `principles`, `application`, `infra`, `ai`, `observability`, `devops`, `governance`
36
+
37
+ **XDR ID** — format: `[scope]-[type]-[next available number]`
38
+ - Scan `.xdrs/[scope]/[type]/` for the highest existing number in that scope+type and increment by 1.
39
+ - Never reuse numbers from deleted XDRs.
40
+
41
+ ### Phase 3: Choose the Title
42
+
43
+ Choose a title that clearly states the question this XDR answers, not the answer itself. The title should let a reader know at a glance what decision scope this record covers.
44
+
45
+ - Good: "Package manager for Node.js projects", "Phone marketing procedures", "Integration patterns for systems connectivity"
46
+ - Avoid: "Use pnpm", "We chose pnpm", or overly vague titles like "Tooling decisions"
47
+
48
+ ### Phase 4: Research Related XDRs
49
+
50
+ 1. Read all existing XDRs relevant to the topic across all scopes listed in `.xdrs/index.md`.
51
+ 2. Identify decisions that already address the topic (full or partial overlap).
52
+ 3. Note decisions that might conflict with the intended outcome.
53
+ 4. Collect XDR IDs and file paths for cross-references.
54
+
55
+ ### Phase 5: Write the First Draft
56
+
57
+ Use the mandatory template from `001-xdr-standards`:
58
+
59
+ ```
60
+ # [scope]-[type]-[number]: [Short Title]
61
+
62
+ ## Context and Problem Statement
63
+ [4 lines max: background, who is impacted, and the explicit question being answered]
64
+
65
+ ## Decision Outcome
66
+
67
+ **[Chosen Option Title]**
68
+ [One sentence: what is the decision]
69
+
70
+ ### Implementation Details
71
+ [Rules, specifics, examples — under 100 lines]
72
+
73
+ ## Considered Options (if meaningful options exist)
74
+
75
+ ## Conflicts (mandatory if conflicts found in Phase 3)
76
+
77
+ ## References (optional)
78
+ ```
79
+
80
+ Mandatory rules to apply while drafting:
81
+ - Use mandatory language ("must", "always", "never") only for hard requirements; use advisory language ("should", "recommended") for guidance.
82
+ - Do not duplicate content already in referenced XDRs — link instead.
83
+ - No emojis. Lowercase filenames.
84
+ - Target under 100 lines total; 200 lines max for complex decisions.
85
+
86
+ ### Phase 6: Review the Draft
87
+
88
+ Check every item before finalizing:
89
+
90
+ 1. **Length**: Is it under 100 lines? Trim verbose explanations. Move detailed skills to a separate file and link.
91
+ 2. **Originality**: Does every sentence add value that cannot be found in a generic web search? Remove obvious advice. Keep only the project-specific decision.
92
+ 3. **Clarity**: Is the chosen option unambiguous? Is the "why" clear in one reading?
93
+ 4. **Conflicts section**: Is it present and filled if Phase 3 found any conflicts?
94
+ 5. **Index entries**: Will the new XDR be added to `[scope]/[type]/index.md` and `.xdrs/index.md`?
95
+
96
+ If any check fails, revise and re-run this phase before proceeding.
97
+
98
+ ### Phase 7: Write Files
99
+
100
+ 1. Create the XDR file at `.xdrs/[scope]/[type]/[subject]/[number]-[short-title].md`.
101
+ 2. Add an entry to `.xdrs/[scope]/[type]/index.md` (create the file if it does not exist).
102
+ 3. Add or verify the scope entry in `.xdrs/index.md`.
103
+
104
+ ### Constraints
105
+
106
+ - MUST follow the XDR template from `001-xdr-standards` exactly.
107
+ - MUST NOT add personal opinions or general best-practice content not tied to a decision.
108
+ - MUST NOT create an XDR that duplicates a decision already captured in another XDR — extend or reference instead.
109
+ - MUST keep scope `_local` unless the user explicitly states otherwise.
package/AGENTS.md CHANGED
@@ -13,9 +13,12 @@
13
13
  - Analyse your work against the XDRs and ensure implementation decisions follow guidelines and patterns
14
14
  - Fix any issues
15
15
 
16
- 4. **Do not perform git operations unless explicitelly asked**
16
+ 4. **Document decisions as XDRs when appropriate**
17
+ - Check if what is being performed shouldn't be documented as an XDR in _local scope (because the decision has potential to be reused in the future or the topic is complex and would benefit from a document for clarity). Create or update existing documents accordingly.
18
+
19
+ 5. **Do not perform git operations unless explicitelly asked**
17
20
  - The developer should be in control of possible destructive operations on the workspace
18
21
 
19
- Check for additional instructions on [AGENTS-LOCAL.md](AGENTS-LOCAL.md).
22
+ Check for additional instructions on [AGENTS.local.md](AGENTS.local.md).
20
23
 
21
24
  **This AGENTS.md file was created with xdrs-core and shouldn't be changed**
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "xdrs-core",
3
- "version": "0.2.18",
3
+ "version": "0.3.1",
4
4
  "description": "A standard way to organize Decision Records (XDRs) across scopes, subjects, and teams so that AI agents can reliably query and follow them.",
5
5
  "repository": {
6
6
  "type": "git",
@@ -20,12 +20,11 @@
20
20
  "bin/npmdata.js"
21
21
  ],
22
22
  "dependencies": {
23
- "npmdata": "^0.16.0"
23
+ "npmdata": "^0.18.12"
24
24
  },
25
25
  "npmdata": {
26
26
  "sets": [
27
27
  {
28
- "package": "xdrs-core",
29
28
  "selector": {
30
29
  "files": [
31
30
  "AGENTS.md",
@@ -47,7 +46,6 @@
47
46
  }
48
47
  },
49
48
  {
50
- "package": "xdrs-core",
51
49
  "selector": {
52
50
  "files": [
53
51
  ".xdrs/index.md"
@@ -56,7 +54,7 @@
56
54
  "output": {
57
55
  "path": ".",
58
56
  "gitignore": false,
59
- "unmanaged": true,
57
+ "managed": false,
60
58
  "keepExisting": true
61
59
  }
62
60
  }