bluetemberg-rules-docs 0.2.0

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.
@@ -0,0 +1,29 @@
1
+ ---
2
+ description: Keep documentation in sync with every user-facing change.
3
+ scope: "**"
4
+ ---
5
+
6
+ # Docs parity
7
+
8
+ A PR that changes behavior without updating docs is not done.
9
+
10
+ ## What counts as user-facing
11
+
12
+ - New or removed CLI flags, commands, or options
13
+ - Changes to user-facing workflows (new prompts, removed choices, changed defaults)
14
+ - New or removed public APIs, config options, or schema fields
15
+ - Changes to output behavior or generated artifacts
16
+
17
+ ## Required behavior
18
+
19
+ When any of the above change:
20
+
21
+ 1. Update `README.md` if the change affects setup, usage, or the feature overview.
22
+ 2. Update the relevant documentation page if one covers the changed area.
23
+ 3. Include the doc update in the same commit as the code change — not a follow-up.
24
+
25
+ ## When NOT required
26
+
27
+ - Internal refactors with no behavior change (renaming a variable, extracting a function)
28
+ - Test-only changes
29
+ - Dependency bumps with no API change
@@ -0,0 +1,19 @@
1
+ ---
2
+ description: Use Mermaid diagrams instead of ASCII art.
3
+ scope: "**"
4
+ ---
5
+
6
+ # Mermaid diagrams
7
+
8
+ Prefer Mermaid over ASCII art for all diagrams in documentation.
9
+
10
+ ## When to use
11
+
12
+ - Architecture and flow diagrams in `docs/wiki/`
13
+ - Any diagram that shows relationships, sequences, or data flow
14
+
15
+ ## Patterns
16
+
17
+ - Use `flowchart TD` or `flowchart LR` for flow/architecture diagrams
18
+ - Use `sequenceDiagram` for request/response flows
19
+ - Use `classDiagram` for type relationships
@@ -0,0 +1,13 @@
1
+ ---
2
+ description: Run diagnostics and formatter after editing code files.
3
+ scope: "**"
4
+ ---
5
+
6
+ # Post-edit diagnostics
7
+
8
+ After each code edit, run file-scoped diagnostics for edited files.
9
+
10
+ - Run the project formatter on edited files (e.g. `prettier --write`).
11
+ - Treat diagnostics findings from edited files as required follow-up before unrelated work.
12
+ - Preserve file scope by default; do not broaden to whole-project scans unless asked.
13
+ - If multiple files were edited, check each edited file explicitly.
package/package.json ADDED
@@ -0,0 +1,20 @@
1
+ {
2
+ "name": "bluetemberg-rules-docs",
3
+ "version": "0.2.0",
4
+ "description": "Documentation and diagnostics rules for Bluetemberg — docs parity, post-edit diagnostics, Mermaid diagrams.",
5
+ "keywords": [
6
+ "bluetemberg-pack",
7
+ "rules",
8
+ "docs",
9
+ "diagnostics"
10
+ ],
11
+ "author": "Prototyp Digital",
12
+ "license": "MIT",
13
+ "repository": {
14
+ "type": "git",
15
+ "url": "https://github.com/prototypdigital/bluetemberg-packs.git"
16
+ },
17
+ "files": [
18
+ "llm/"
19
+ ]
20
+ }