@windyroad/architect 0.2.0-preview.70 → 0.3.0-preview.72
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.
package/package.json
CHANGED
|
@@ -0,0 +1,91 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: wr-architect:review-design
|
|
3
|
+
description: On-demand architecture compliance review. Checks staged changes and recent commits against existing ADRs in docs/decisions/. Use before editing architecture-bearing files or before a release.
|
|
4
|
+
allowed-tools: Read, Glob, Grep, Bash, AskUserQuestion, Skill
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Architecture Compliance Review Skill
|
|
8
|
+
|
|
9
|
+
Run an architecture compliance review on demand — outside the pre-tool-use hook gate. Reviews staged changes and recent commits against the project's ADRs in `docs/decisions/`.
|
|
10
|
+
|
|
11
|
+
This skill is **read-only**. It does not commit, push, or modify files.
|
|
12
|
+
|
|
13
|
+
## When to use
|
|
14
|
+
|
|
15
|
+
- Pre-flight before a release or client handover: confirm no ADR violations crept in
|
|
16
|
+
- After a large refactor: verify the new structure still complies with decisions
|
|
17
|
+
- When proposing a structural change: get a review before editing architecture-bearing files
|
|
18
|
+
- Any time the hook gate is not convenient: e.g., planning mode, exploratory spikes
|
|
19
|
+
|
|
20
|
+
## Steps
|
|
21
|
+
|
|
22
|
+
### 1. Parse arguments
|
|
23
|
+
|
|
24
|
+
Read `$ARGUMENTS` for an explicit review scope (e.g., "review my changes to the auth module", "check the new API routes", "pre-release review"). If a scope is provided, use it. If empty, proceed to auto-detection.
|
|
25
|
+
|
|
26
|
+
### 2. Auto-detect context
|
|
27
|
+
|
|
28
|
+
Run the following to establish what needs reviewing:
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
# Staged changes
|
|
32
|
+
git diff --cached --stat
|
|
33
|
+
|
|
34
|
+
# Recent commits not yet pushed
|
|
35
|
+
git log origin/$(git rev-parse --abbrev-ref HEAD)..HEAD --oneline 2>/dev/null || git log HEAD -5 --oneline
|
|
36
|
+
|
|
37
|
+
# Changed files
|
|
38
|
+
git diff --cached --name-only
|
|
39
|
+
git diff --name-only HEAD
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
Summarise:
|
|
43
|
+
- Files staged or recently committed
|
|
44
|
+
- Whether the changes are architectural (source code, config, schema, tooling) vs purely documentary
|
|
45
|
+
|
|
46
|
+
### 3. Resolve ambiguity
|
|
47
|
+
|
|
48
|
+
If there are no staged changes and no recent unpushed commits, use `AskUserQuestion` to ask:
|
|
49
|
+
|
|
50
|
+
> "I don't see any staged or unpushed changes. What would you like me to review?
|
|
51
|
+
> (a) A specific set of files — please name them
|
|
52
|
+
> (b) All changes since the last tag
|
|
53
|
+
> (c) A planned change you'd like to describe
|
|
54
|
+
> (d) Cancel"
|
|
55
|
+
|
|
56
|
+
Do not ask if there is an obvious set of changed files.
|
|
57
|
+
|
|
58
|
+
### 4. Construct the assessment prompt
|
|
59
|
+
|
|
60
|
+
Build a self-contained prompt for the architect subagent that includes:
|
|
61
|
+
- The list of changed/staged files
|
|
62
|
+
- The git diff summary (stat output)
|
|
63
|
+
- Any explicit scope from the user
|
|
64
|
+
- The request: "Review these proposed changes against the project's ADRs. Flag any violations, gaps that need a new ADR, or compliance questions."
|
|
65
|
+
|
|
66
|
+
### 5. Delegate to wr-architect:agent
|
|
67
|
+
|
|
68
|
+
Invoke the architect subagent via the `Skill` tool:
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
subagent_type: wr-architect:agent
|
|
72
|
+
prompt: <constructed review prompt from step 4>
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
Wait for the subagent to complete.
|
|
76
|
+
|
|
77
|
+
### 6. Present results
|
|
78
|
+
|
|
79
|
+
Present the full compliance report to the user. The architect subagent will report:
|
|
80
|
+
- PASS: no violations found
|
|
81
|
+
- FLAGGED: specific violations or compliance questions with ADR references
|
|
82
|
+
- NEW ADR NEEDED: decisions that should be recorded before proceeding
|
|
83
|
+
|
|
84
|
+
If violations are flagged, use `AskUserQuestion` to ask how the user wants to proceed:
|
|
85
|
+
- (a) Address the violations before continuing
|
|
86
|
+
- (b) Proceed with a documented exception
|
|
87
|
+
- (c) Draft a new or amended ADR to legitimise the approach
|
|
88
|
+
|
|
89
|
+
Do not make the decision unilaterally — per ADR-013 Rule 1, architectural risk decisions are the user's.
|
|
90
|
+
|
|
91
|
+
$ARGUMENTS
|