@tacuchi/agent-workflow-cli 15.1.0 → 16.0.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.
- package/package.json +1 -1
- package/skills/w/README.md +14 -14
- package/skills/w/SKILL.md +96 -75
- package/skills/w/artifacts/README.md +6 -6
- package/skills/w/artifacts/artifacts-core/SESSION.md +1 -7
- package/skills/w/artifacts/artifacts-core/TASKS.md +1 -1
- package/skills/w/artifacts/artifacts-exec/TECHNICAL-NOTE.md +9 -54
- package/skills/w/artifacts/artifacts-research/CONCLUSIONS.md +1 -1
- package/skills/w/commands/README.md +22 -22
- package/skills/w/commands/export-diagrams.md +9 -9
- package/skills/w/commands/export-manuals.md +9 -9
- package/skills/w/commands/export-reports.md +9 -9
- package/skills/w/commands/export-scripts.md +9 -9
- package/skills/w/commands/fix-git.md +12 -12
- package/skills/w/commands/plan-exec.md +19 -19
- package/skills/w/commands/plan-new.md +18 -18
- package/skills/w/commands/plan-refine.md +22 -22
- package/skills/w/commands/quick.md +16 -16
- package/skills/w/commands/spec-new.md +35 -34
- package/skills/w/commands/spec-refine.md +16 -16
- package/skills/w/commands/status.md +18 -16
- package/skills/w/commands/workspace-init.md +14 -14
- package/skills/w/exports/README.md +5 -5
- package/skills/w/exports/export-diagrams/SKILL.md +58 -58
- package/skills/w/exports/export-manuals/SKILL.md +61 -61
- package/skills/w/exports/export-reports/SKILL.md +51 -51
- package/skills/w/exports/export-scripts/SKILL.md +60 -60
- package/skills/w/harness/SKILL.md +48 -47
- package/skills/w/loops/CHASSIS.md +104 -97
- package/skills/w/loops/CODE-POLICIES.md +21 -21
- package/skills/w/loops/README.md +30 -29
- package/skills/w/loops/plan-exec-loop/SKILL.md +77 -80
- package/skills/w/loops/plan-new-loop/SKILL.md +88 -58
- package/skills/w/loops/plan-refine-loop/SKILL.md +69 -45
- package/skills/w/loops/quick-loop/SKILL.md +79 -79
- package/skills/w/loops/spec-refine-loop/SKILL.md +93 -97
- package/skills/w/roles/README.md +2 -2
- package/skills/w/roles/diagrams/SKILL.md +50 -47
- package/skills/w/roles/git/SKILL.md +58 -58
- package/skills/w/roles/research/SKILL.md +65 -62
- package/skills/w/roles/sql/SKILL.md +59 -55
- package/skills/w/roles/ui-spec/SKILL.md +60 -74
|
@@ -1,178 +1,174 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: spec-refine-loop
|
|
3
3
|
description: >-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
decisions + Q&A traceability al spec — la marca de refinado que plan-new
|
|
12
|
-
detecta. Lo arranca /w:spec-refine (o la escalación en vivo desde
|
|
13
|
-
quick-loop); reanudable vía CHECKPOINT y re-corrible a demanda. Invocar cuando haya que refinar/desambiguar una especificación
|
|
14
|
-
antes de planificar.
|
|
4
|
+
Refines a draft spec (docs/specs/NNN-spec-<slug>.md) by editing it IN PLACE
|
|
5
|
+
until it is unambiguous. Heir of the chassis (loops/CHASSIS.md). Deltas:
|
|
6
|
+
spec gap taxonomy, analyze gate, ## UI spec section via the ui-design
|
|
7
|
+
capability, and adds Refinement decisions + Q&A traceability — the refined
|
|
8
|
+
mark plan-new detects. Started by /w:spec-refine (or the live escalation
|
|
9
|
+
from quick-loop); resumable via CHECKPOINT and re-runnable on demand.
|
|
10
|
+
Invoke to refine/disambiguate a specification before planning.
|
|
15
11
|
---
|
|
16
12
|
|
|
17
13
|
# spec-refine-loop
|
|
18
14
|
|
|
19
|
-
> **Heir**
|
|
15
|
+
> **Heir** of the common chassis — **only** the SPEC deltas live here. The engine is never repeated.
|
|
20
16
|
|
|
21
17
|
## Inherits
|
|
22
18
|
|
|
23
|
-
|
|
19
|
+
Read **[`../CHASSIS.md`](../CHASSIS.md)** — the loop's **full engine** — **always before** these deltas. *(If `../` does not resolve: `CHASSIS.md` next to this file — global layout rule, chassis § Reference resolution.)*
|
|
24
20
|
|
|
25
21
|
## Flow
|
|
26
22
|
SPEC
|
|
27
23
|
|
|
28
24
|
## Layer
|
|
29
|
-
2 —
|
|
25
|
+
2 — the AI runs it end to end (gap-driven). The user does not drive the cycle; they only answer content questions and steer the lifecycle via the `flow` control.
|
|
30
26
|
|
|
31
27
|
## Started by
|
|
32
|
-
`/w:spec-refine` — **
|
|
28
|
+
`/w:spec-refine` — **resumable**. Detects prior state (via CHECKPOINT) and starts accordingly (see *Compact / resume — SPEC keys*).
|
|
33
29
|
|
|
34
|
-
|
|
30
|
+
It is also started by the **live escalation from `quick-loop`** (entry gate or mid-loop — see [`../quick-loop/SKILL.md`](../quick-loop/SKILL.md) § *QUICK delta*): quick materializes the draft (`spec-new` procedure) and **loads this loop** over that spec — same semantics as if the user had run `/w:spec-refine`.
|
|
35
31
|
|
|
36
32
|
## Reads
|
|
37
|
-
- `docs/specs/NNN-spec*.md` (glob —
|
|
33
|
+
- `docs/specs/NNN-spec*.md` (glob — locates the spec by number; also catches the legacy `NNN-spec.md`), **or** the exact path passed as the command argument. **Always the spec itself**: this loop edits it in place; there is no separate "refined" file.
|
|
38
34
|
|
|
39
35
|
## Writes
|
|
40
|
-
|
|
36
|
+
Updates `docs/specs/NNN-spec-<slug>.md` **in place** (when the user picks `Guardar especificación refinada`): completes sections and **adds** `## Refinement decisions` + `## Q&A traceability`, closing `Open questions` as they get resolved. Since it overwrites an existing doc, it asks the user's **confirmation**.
|
|
41
37
|
|
|
42
|
-
> **
|
|
38
|
+
> **Boundary invariant:** this loop writes **only** into `docs/specs`. It never graduates/exports other artifacts to `docs/` — that is separate `export-*` work (chassis § *docs/ boundary*).
|
|
43
39
|
|
|
44
|
-
## Internal sessions —
|
|
40
|
+
## Internal sessions — SPEC instance
|
|
45
41
|
|
|
46
|
-
|
|
42
|
+
Full doctrine in the chassis (§ *Internal sessions* + *Numbering*). This loop's instance:
|
|
47
43
|
|
|
48
44
|
| Session | When | Artifacts | Role |
|
|
49
45
|
|---|---|---|---|
|
|
50
|
-
| **refine session** `NNN-<slug>-spec-refine/` |
|
|
46
|
+
| **refine session** `NNN-<slug>-spec-refine/` | when the loop starts (or resumes) | `SESSION.md` · `CHECKPOINT.md` (· `BACKLOG.md` only if something is deferred) | Owns the run. Type = `refine`; descriptor `<slug>-spec-refine` (the `<slug>` comes from the input spec). |
|
|
51
47
|
|
|
52
|
-
> **Origin
|
|
48
|
+
> **Origin on escalation:** when the run is born from quick-loop's live escalation, the session's `## Origin` records "escalated from `/w:quick`" + the origin quick session if it exists (its `DECISION`/`SCRIPTS.sql` are referenceable context — never migrated).
|
|
53
49
|
|
|
54
|
-
> **Compat (legacy):** workspaces
|
|
50
|
+
> **Compat (legacy):** old workspaces may hold `NNN-spec.md` / `NNN-spec-refined.md` and separate `*-research-*` sessions — historical, left as-is. The `NNN-spec*.md` glob still finds the base spec, and re-running spec-refine edits it in place from then on.
|
|
55
51
|
|
|
56
52
|
## Composes
|
|
57
53
|
|
|
58
|
-
|
|
54
|
+
The **UI unspecified** gap (when the requirement involves UI; see *Gap taxonomy*) is resolved by **composing** the **`ui-design`** capability (built-in default `ui-spec`; rebindable via `.workflow/skills.toml`): it authors the UI spec natively (structure, vocabulary, Markdown format). It is a third gap-resolution mode (next to *research* and *human*): the loop contributes iteration/Q&A (design system, theme, variants, disambiguation) **via the same structured-choice**, and integrates the result as the spec's `## UI spec` section.
|
|
59
55
|
|
|
60
|
-
> **
|
|
56
|
+
> **Two levels of the same capability:** here (SPEC) it produces `## UI spec` — the UI's *what*, coarse grain; in PLAN the plan loops produce **per-screen design SPECs** derived from that section (see [`SPEC.md`](../../artifacts/artifacts-design/SPEC.md)).
|
|
61
57
|
|
|
62
|
-
|
|
58
|
+
Other transversal capabilities the engine always uses: `research` (**inline** — chassis § *Research*), `sql` (DB rule inside research — chassis). All resolved by config; `off` → the loop continues without the capability and, if it was needed, says so or asks. The spec's **prose** follows the **ambient** writing conventions (the host auto-applies an installed writing skill if present), not a composed role.
|
|
63
59
|
|
|
64
|
-
> **
|
|
60
|
+
> **Ambient conventions (not roles):** code/testing/writing standards and `creating-tools` are standalone skills the host auto-discovers by `description` — the workflow neither binds nor depends on them. Full doctrine: [../../roles/README.md](../../roles/README.md).
|
|
65
61
|
|
|
66
|
-
## Deliverable schema (
|
|
62
|
+
## Deliverable schema (the spec, edited in place)
|
|
67
63
|
|
|
68
|
-
|
|
64
|
+
The spec is completed **in place**: the draft's sections get **completed** + two new ones are **added** (`Refinement decisions`, `Q&A traceability`). NO separate file is created.
|
|
69
65
|
|
|
70
66
|
```markdown
|
|
71
67
|
# Spec NNN — <slug>
|
|
72
68
|
|
|
73
|
-
>
|
|
69
|
+
> Refined in place by spec-refine-loop
|
|
74
70
|
|
|
75
|
-
## Origin (opt. —
|
|
76
|
-
## Requirement (
|
|
77
|
-
## Context (
|
|
78
|
-
## Scope (In / Out
|
|
79
|
-
## Acceptance criteria (
|
|
80
|
-
## Assumptions (
|
|
71
|
+
## Origin (opt. — preserved from the draft)
|
|
72
|
+
## Requirement (sharpened, unambiguous)
|
|
73
|
+
## Context (complete)
|
|
74
|
+
## Scope (clear In / Out)
|
|
75
|
+
## Acceptance criteria (testable, - [ ]; EARS / Given-When-Then style recommended)
|
|
76
|
+
## Assumptions (declared)
|
|
81
77
|
|
|
82
|
-
## UI spec (opt. —
|
|
83
|
-
|
|
78
|
+
## UI spec (opt. — if UI is involved; via the ui-design capability / ui-spec skill)
|
|
79
|
+
Structured Markdown description (screens → regions/components). See [`ui-spec`](../../roles/ui-spec/SKILL.md).
|
|
84
80
|
|
|
85
|
-
## Refinement decisions ← NEW (
|
|
86
|
-
|
|
87
|
-
(
|
|
81
|
+
## Refinement decisions ← NEW (ADDED)
|
|
82
|
+
What was defined while refining and why. Includes what inline research
|
|
83
|
+
resolved (with a reference to the session's CONCLUSIONS).
|
|
88
84
|
|
|
89
|
-
## Q&A traceability ← NEW (
|
|
90
|
-
|
|
85
|
+
## Q&A traceability ← NEW (ADDED)
|
|
86
|
+
Every doubt asked to the human + the chosen answer.
|
|
91
87
|
|
|
92
|
-
## Open questions (
|
|
88
|
+
## Open questions (ideally "None"; whatever remains is deferred)
|
|
93
89
|
```
|
|
94
90
|
|
|
95
|
-
> **
|
|
91
|
+
> **Refined mark (contract with PLAN):** the presence of `## Refinement decisions` + `## Q&A traceability` distinguishes a refined spec from a draft — plan-new detects it this way, NOT by filename; without those 2 sections plan-new soft-suggests spec-refine.
|
|
96
92
|
|
|
97
|
-
> **Acceptance criteria =
|
|
93
|
+
> **Acceptance criteria = static testable criteria** (the "what"): plan-exec validates them, but progress is tracked in the PLAN (its Tasks), never by ticking these `- [ ]` in the spec; the spec never mutates by execution, only by a re-refine.
|
|
98
94
|
|
|
99
95
|
## Gap taxonomy (= weak sections of the schema)
|
|
100
96
|
|
|
101
|
-
`detect_gaps(work)`
|
|
97
|
+
`detect_gaps(work)` looks for these signals; each has a resolver:
|
|
102
98
|
|
|
103
99
|
| Gap | Signal | Resolved by |
|
|
104
100
|
|---|---|---|
|
|
105
|
-
|
|
|
106
|
-
|
|
|
107
|
-
|
|
|
108
|
-
|
|
|
109
|
-
| Open questions
|
|
110
|
-
|
|
|
111
|
-
|
|
|
112
|
-
| UI
|
|
101
|
+
| Vague requirement | the what/why is ambiguous | **human** |
|
|
102
|
+
| Incomplete context | systems/components unidentified | **research** |
|
|
103
|
+
| Blurry scope | `Out` missing, or In/Out overlap | **human** |
|
|
104
|
+
| Untestable criteria | acceptance not verifiable | **human** (derive + confirm) |
|
|
105
|
+
| Open questions pending | explicit doubts | by nature |
|
|
106
|
+
| Hidden assumptions | the spec assumes unstated things | **research** validates / **human** confirms |
|
|
107
|
+
| Internal contradiction | sections contradict each other | **human** |
|
|
108
|
+
| UI unspecified *(if it applies)* | the requirement involves UI but `## UI spec` is missing | **`ui-design` capability** |
|
|
113
109
|
|
|
114
110
|
## Sequence
|
|
115
111
|
|
|
116
112
|
```
|
|
117
113
|
spec-refine-loop(spec):
|
|
118
|
-
input = glob(NNN-spec*.md) |
|
|
119
|
-
refine_session = create_or_resume("<slug>-spec-refine") # <slug>
|
|
120
|
-
seed SESSION.Success criteria = acceptance criteria +
|
|
121
|
-
work = read(input) (+
|
|
122
|
-
attempts = {}
|
|
114
|
+
input = glob(NNN-spec*.md) | argument (path) # always the spec itself (in place)
|
|
115
|
+
refine_session = create_or_resume("<slug>-spec-refine") # <slug> from the input spec; CLI prepends global NNN; resume locates by descriptor/origin
|
|
116
|
+
seed SESSION.Success criteria = acceptance criteria + analyze-gate checklist # verification-first: BEFORE iterating
|
|
117
|
+
work = read(input) (+ apply checkpoint progress if resuming)
|
|
118
|
+
attempts = {} # anti re-fire per gap
|
|
123
119
|
repeat:
|
|
124
|
-
gaps = detect_gaps(work)
|
|
120
|
+
gaps = detect_gaps(work) minus the "exhausted" gaps
|
|
125
121
|
if gaps == ∅: break
|
|
126
122
|
batch = top ≤3 gaps ; pending_human = []
|
|
127
|
-
seed CHECKPOINT.Pending/Next = batch (refine_session) #
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
123
|
+
seed CHECKPOINT.Pending/Next = batch (refine_session) # BEFORE: seed the intent (artifact-first)
|
|
124
|
+
for each gap in batch:
|
|
125
|
+
if gap = UI (requirement involves UI, ## UI spec missing):
|
|
126
|
+
compose ui-design → author ## UI spec # design-system/theme via structured-choice (counts in the batch)
|
|
131
127
|
work = integrate(work, ui) # → ## UI spec
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
res = research_inline(gap) #
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
128
|
+
else if factual(gap) and attempts[gap] < MAX:
|
|
129
|
+
if it needs DB and >1 MCP without default → queue "MCP choice" in pending_human
|
|
130
|
+
res = research_inline(gap) # in the current session: ANALYSIS-FILE → CONCLUSIONS (+read-only SCRIPTS.sql)
|
|
131
|
+
if res.conclusive: work = integrate(work, res) # → Refinement decisions
|
|
132
|
+
else: attempts[gap]++ ; if attempts[gap] >= MAX → pending_human.push(gap)
|
|
133
|
+
else:
|
|
138
134
|
pending_human.push(gap)
|
|
139
|
-
update CHECKPOINT (refine_session) #
|
|
140
|
-
|
|
141
|
-
ans = structured_choice(
|
|
135
|
+
update CHECKPOINT (refine_session) # AFTER: Pending→Completed, at every gap boundary (chassis § artifact-first cycle)
|
|
136
|
+
if pending_human not empty:
|
|
137
|
+
ans = structured_choice(content: pending_human (≤3), flow: [Compactar, Cerrar])
|
|
142
138
|
switch(flow):
|
|
143
|
-
Compactar → write CHECKPOINT (refine_session) ;
|
|
139
|
+
Compactar → write CHECKPOINT (refine_session) ; compact(harness) ; continue
|
|
144
140
|
Cerrar → goto finalize
|
|
145
141
|
work = integrate(work, ans) # → Q&A traceability / Open questions
|
|
146
|
-
#
|
|
147
|
-
issues = analyze(work) #
|
|
148
|
-
|
|
149
|
-
ans = structured_choice(
|
|
142
|
+
# no material gaps → analyze gate = Success criteria green (read-only) before offering Guardar:
|
|
143
|
+
issues = analyze(work) # criteria trace to the Requirement · no contradictions · coherent Scope · Open questions closed/deferred
|
|
144
|
+
if issues: gaps += issues ; continue # findings come back into the loop as gaps
|
|
145
|
+
ans = structured_choice(content: [Guardar refinada, Preguntar algo más],
|
|
150
146
|
flow: [Compactar, Cerrar])
|
|
151
|
-
Guardar
|
|
147
|
+
Guardar → edit_in_place_with_confirm(spec) # completes sections + inserts UI spec/Refinement decisions/Q&A ; goto finalize
|
|
152
148
|
Preguntar algo más → continue
|
|
153
|
-
flow Compactar/Cerrar →
|
|
149
|
+
flow Compactar/Cerrar → handle the same way
|
|
154
150
|
finalize:
|
|
155
|
-
write CHECKPOINT (refine_session) #
|
|
156
|
-
|
|
157
|
-
|
|
151
|
+
write CHECKPOINT (refine_session) # always persisted
|
|
152
|
+
if deferred/follow-ups exist → write/update BACKLOG (reason + deferred Open questions)
|
|
153
|
+
close refine_session ; report
|
|
158
154
|
```
|
|
159
155
|
|
|
160
|
-
## Compact / resume —
|
|
156
|
+
## Compact / resume — SPEC keys
|
|
161
157
|
|
|
162
|
-
|
|
158
|
+
Full mechanism (3 cases, `Compactar`, re-run on demand with `--reopen`) in the chassis (§ *Compact / resume*). SPEC keys:
|
|
163
159
|
|
|
164
|
-
-
|
|
165
|
-
-
|
|
160
|
+
- The **prior-work mark** is the presence of `## Refinement decisions` + `## Q&A traceability` in the spec (the *refined mark*, see *Deliverable schema*).
|
|
161
|
+
- Re-refining on demand is a **first-class operation** while the flow stays in SPEC (new requirements, scope changes, after re-reading the spec): it always reads the **spec itself**, incremental re-refinement; on `Guardar`, edits in place with confirmation.
|
|
166
162
|
|
|
167
163
|
## Convergence / exit
|
|
168
164
|
|
|
169
|
-
- **
|
|
170
|
-
- `Guardar` → `edit_in_place_with_confirm(spec)`
|
|
171
|
-
- `Cerrar` → `finalize`
|
|
165
|
+
- **No material gaps** → **analyze gate** (read-only) = **`Success criteria` green** (*verification-first*; the SPEC instance of the chassis convergence gate): every acceptance criterion traces to the `Requirement`, no internal contradictions, coherent `Scope` In/Out, `Open questions` closed or explicitly deferred. Whatever fails **comes back as a gap**; if it passes → offer `Guardar especificación refinada`.
|
|
166
|
+
- `Guardar` → `edit_in_place_with_confirm(spec)` and `finalize`.
|
|
167
|
+
- `Cerrar` → the chassis `finalize` (always persists `CHECKPOINT`; `BACKLOG` **only if** something is deferred — here: close reason + deferred `Open questions`).
|
|
172
168
|
|
|
173
|
-
## Integration (
|
|
169
|
+
## Integration (where each resolution lands)
|
|
174
170
|
|
|
175
|
-
-
|
|
176
|
-
-
|
|
177
|
-
-
|
|
178
|
-
- **
|
|
171
|
+
- Resolved via **inline research** → the spec's `## Refinement decisions` (+ ref to the session's `CONCLUSIONS`).
|
|
172
|
+
- Resolved via **human** → the spec's `## Q&A traceability`.
|
|
173
|
+
- Resolved via the **`ui-design` capability** (UI gap) → the spec's `## UI spec` section.
|
|
174
|
+
- **Inconclusive or unresolved research** → the spec's `## Open questions` (deferred) + the refine session's `BACKLOG.md` (only if something is deferred).
|
package/skills/w/roles/README.md
CHANGED
|
@@ -23,9 +23,9 @@ All 6 roles, their built-in defaults, their tier, and which loops/exports compos
|
|
|
23
23
|
- `must` — core to almost every session; built-in always active unless explicitly `off`.
|
|
24
24
|
- `should` — loaded on-demand; active by default but lower priority to override.
|
|
25
25
|
|
|
26
|
-
> **
|
|
26
|
+
> **Ambient conventions (not roles).** Code, testing and writing standards **and tool authoring** (`creating-tools`, which writes `docs/tools`) are **not workflow roles** and are never bound: they are **standalone skills the host auto-discovers by `description`** and applies when relevant. The workflow is **indifferent** (it neither reads nor looks for them). Useful families live in marketplace plugins (`dev-conventions`, `tool-builder`), but the workflow does **not depend** on them.
|
|
27
27
|
>
|
|
28
|
-
> **
|
|
28
|
+
> **The closing review is not a role either** (deliberate decision — a `conventions`/`rules`/`review` role was evaluated and discarded): the pre-commit **closing review gate** of `plan-exec-loop`/`quick-loop` is a **loop step**; the loop creates the **moment** and the installed ambient conventions fill it. A role that "points at the marketplace skills" would re-couple what this extraction decoupled.
|
|
29
29
|
|
|
30
30
|
---
|
|
31
31
|
|
|
@@ -1,49 +1,51 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: diagrams
|
|
3
3
|
description: >
|
|
4
|
-
|
|
5
|
-
Component): Mermaid C4
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
4
|
+
Architecture and system diagram authoring with C4 notation (Context, Container,
|
|
5
|
+
Component): native Mermaid C4 (default) or Structurizr DSL. Composed by export-diagrams
|
|
6
|
+
to produce the content of docs/diagrams/. Selects the engine from the export's
|
|
7
|
+
`--engine` flag (Mermaid default; `c4`/Structurizr DSL opt-in). Includes a mermaid.ink
|
|
8
|
+
link per Mermaid block for preview without a local renderer.
|
|
9
9
|
---
|
|
10
10
|
|
|
11
11
|
# diagrams — Diagram authoring capability
|
|
12
12
|
|
|
13
13
|
## Role
|
|
14
14
|
|
|
15
|
-
`diagrams` —
|
|
15
|
+
`diagrams` — built-in default implementation. Rebindable to another skill (third-party or `off`) in `.workflow/skills.toml`.
|
|
16
16
|
|
|
17
17
|
## Purpose
|
|
18
18
|
|
|
19
|
-
|
|
19
|
+
Author architecture diagrams with C4 notation (Levels 1-3) using the engine the export configures via `--engine`. It produces renderable source (Mermaid / DSL) — **it does not render visually**; the reader renders with their tools. Covers the default engine (native embedded Mermaid C4) and the opt-in `c4` (Structurizr DSL, formal C4).
|
|
20
20
|
|
|
21
21
|
## Composed by
|
|
22
22
|
|
|
23
|
-
| Export |
|
|
23
|
+
| Export | When it composes it |
|
|
24
24
|
|---|---|
|
|
25
|
-
| `export-diagrams` |
|
|
25
|
+
| `export-diagrams` | to generate the content of `docs/diagrams/NNN-*/` |
|
|
26
26
|
|
|
27
|
-
|
|
27
|
+
Any loop may also compose it to produce an inline diagram during execution (rare; the primary case is `export-diagrams`).
|
|
28
28
|
|
|
29
29
|
## Knowledge
|
|
30
30
|
|
|
31
31
|
### Engine matrix
|
|
32
32
|
|
|
33
|
-
|
|
33
|
+
The export picks the engine with `--engine mermaid|c4` (default `mermaid`):
|
|
34
34
|
|
|
35
|
-
| `--engine` |
|
|
35
|
+
| `--engine` | Engine | Files produced | When to pick it |
|
|
36
36
|
|---|---|---|---|
|
|
37
|
-
| `mermaid` (default) | Mermaid C4
|
|
38
|
-
| `c4` | Structurizr DSL | `workspace.dsl` + Mermaid
|
|
37
|
+
| `mermaid` (default) | Native Mermaid C4 | only `.md` with Mermaid blocks | Embedded render, no separate DSL; GitHub/GitLab render it inline |
|
|
38
|
+
| `c4` | Structurizr DSL | `workspace.dsl` + auxiliary Mermaid embedded in `.md` | Formal technical dossier; external tooling (structurizr.com, structurizr-lite) |
|
|
39
39
|
|
|
40
|
-
**
|
|
40
|
+
**Canonical rule**: `export-diagrams` uses **Mermaid** by default (`--engine mermaid`) — embedded render, no external tooling. `--engine c4` produces Structurizr DSL (formal C4, separates model from views) for the technical dossier.
|
|
41
41
|
|
|
42
42
|
### C4 model — levels
|
|
43
43
|
|
|
44
|
+
Diagram titles/labels are user-facing content → author them in the user's language (Spanish in the templates below).
|
|
45
|
+
|
|
44
46
|
#### Level 1: Context (C4Context)
|
|
45
47
|
|
|
46
|
-
|
|
48
|
+
The system as a single box + actors + neighbor systems. Business perspective.
|
|
47
49
|
|
|
48
50
|
```mermaid
|
|
49
51
|
C4Context
|
|
@@ -57,7 +59,7 @@ C4Context
|
|
|
57
59
|
|
|
58
60
|
#### Level 2: Container (C4Container)
|
|
59
61
|
|
|
60
|
-
|
|
62
|
+
Applications, services, data stores composing the system. One source declared in `WORKSPACE` = one container.
|
|
61
63
|
|
|
62
64
|
```mermaid
|
|
63
65
|
C4Container
|
|
@@ -76,7 +78,7 @@ C4Container
|
|
|
76
78
|
|
|
77
79
|
#### Level 3: Component (C4Component)
|
|
78
80
|
|
|
79
|
-
|
|
81
|
+
Relevant internal modules of one container. Only for containers with enough internal complexity. One diagram per container; the rest are omitted.
|
|
80
82
|
|
|
81
83
|
```mermaid
|
|
82
84
|
C4Component
|
|
@@ -88,7 +90,7 @@ C4Component
|
|
|
88
90
|
Rel(compA, compB, "<interaccion>")
|
|
89
91
|
```
|
|
90
92
|
|
|
91
|
-
|
|
93
|
+
If no container justifies C4 Component → omit the section with the inline note `_(Sin contenedores con complejidad interna suficiente para C4 Component.)_`.
|
|
92
94
|
|
|
93
95
|
### Structurizr DSL template
|
|
94
96
|
|
|
@@ -126,7 +128,7 @@ workspace "<PRODUCTO>" "<descripcion>" {
|
|
|
126
128
|
autoLayout
|
|
127
129
|
}
|
|
128
130
|
|
|
129
|
-
//
|
|
131
|
+
// One view per container with relevant C4 Component:
|
|
130
132
|
component svcA "SvcA-Components" {
|
|
131
133
|
include *
|
|
132
134
|
autoLayout
|
|
@@ -137,11 +139,11 @@ workspace "<PRODUCTO>" "<descripcion>" {
|
|
|
137
139
|
}
|
|
138
140
|
```
|
|
139
141
|
|
|
140
|
-
|
|
142
|
+
Free online render: [structurizr.com/dsl](https://structurizr.com/dsl) or structurizr-lite (Docker).
|
|
141
143
|
|
|
142
|
-
### PlantUML C4-stdlib template (
|
|
144
|
+
### PlantUML C4-stdlib template (extra engine, outside the current contract)
|
|
143
145
|
|
|
144
|
-
>
|
|
146
|
+
> The current `export-diagrams` contract exposes only `--engine mermaid|c4` (it produces no `.puml`). This template remains as a **reference** for a rebound/custom export that wants to emit PlantUML.
|
|
145
147
|
|
|
146
148
|
```plantuml
|
|
147
149
|
@startuml arquitectura
|
|
@@ -163,11 +165,11 @@ SHOW_LEGEND()
|
|
|
163
165
|
@enduml
|
|
164
166
|
```
|
|
165
167
|
|
|
166
|
-
Render: [plantuml.com](https://plantuml.com)
|
|
168
|
+
Render: [plantuml.com](https://plantuml.com) or a local `plantuml.jar`.
|
|
167
169
|
|
|
168
|
-
### Mermaid
|
|
170
|
+
### Auxiliary Mermaid (under `--engine c4`)
|
|
169
171
|
|
|
170
|
-
|
|
172
|
+
With `--engine c4`, the `.md` file also includes a Mermaid block derived from the DSL as an **offline fallback** (readers without access to structurizr.com/dsl can read it directly):
|
|
171
173
|
|
|
172
174
|
```
|
|
173
175
|
```mermaid
|
|
@@ -175,14 +177,14 @@ C4Context
|
|
|
175
177
|
title ...
|
|
176
178
|
```
|
|
177
179
|
|
|
178
|
-
>
|
|
180
|
+
> See the rendered diagram: <https://mermaid.ink/img/BASE64>
|
|
179
181
|
```
|
|
180
182
|
|
|
181
|
-
|
|
183
|
+
`BASE64` is the plain Mermaid code encoded as URL-safe base64 (RFC 4648 §5; alphabet `A-Z a-z 0-9 - _`). **Every Mermaid block carries its own link** immediately after the closing fence.
|
|
182
184
|
|
|
183
185
|
### Sequence diagrams (opt-in)
|
|
184
186
|
|
|
185
|
-
|
|
187
|
+
For critical integration flows (not structural C4), a Mermaid `sequenceDiagram` complements the C4 Container:
|
|
186
188
|
|
|
187
189
|
```mermaid
|
|
188
190
|
sequenceDiagram
|
|
@@ -195,11 +197,11 @@ sequenceDiagram
|
|
|
195
197
|
SvcA-->>Dev: 201 Created
|
|
196
198
|
```
|
|
197
199
|
|
|
198
|
-
|
|
200
|
+
Only when it adds real clarity — never add sequence diagrams by default.
|
|
199
201
|
|
|
200
|
-
### Entity-Relationship (
|
|
202
|
+
### Entity-Relationship (data model)
|
|
201
203
|
|
|
202
|
-
|
|
204
|
+
When `export-diagrams` includes `--scope data` and an MCP is configured:
|
|
203
205
|
|
|
204
206
|
```mermaid
|
|
205
207
|
erDiagram
|
|
@@ -215,35 +217,36 @@ erDiagram
|
|
|
215
217
|
}
|
|
216
218
|
```
|
|
217
219
|
|
|
218
|
-
|
|
220
|
+
Read-only MCP: `\d <table>` + `SELECT count(*)` for magnitude (apply the cost guard: see the `research` or `sql` skill).
|
|
219
221
|
|
|
220
222
|
### Output file structure
|
|
221
223
|
|
|
222
224
|
```
|
|
223
225
|
docs/diagrams/NNN-export-diagrams-YYYY-MM-DD/
|
|
224
|
-
├── README.md #
|
|
225
|
-
├── diagrams.md #
|
|
226
|
-
└── workspace.dsl #
|
|
226
|
+
├── README.md # index + how-to-read + engines used
|
|
227
|
+
├── diagrams.md # main document with C4 + Mermaid (+ mermaid.ink links)
|
|
228
|
+
└── workspace.dsl # only with --engine c4 (Structurizr)
|
|
227
229
|
```
|
|
228
230
|
|
|
229
231
|
### Render rules
|
|
230
232
|
|
|
231
|
-
1.
|
|
232
|
-
2.
|
|
233
|
-
3. C4Component
|
|
234
|
-
4. Sequence
|
|
235
|
-
5.
|
|
236
|
-
6.
|
|
233
|
+
1. No word cap — completeness > concision for technical documentation.
|
|
234
|
+
2. The main diagram (at least C4Context + C4Container) is mandatory; without them the output is not valid.
|
|
235
|
+
3. C4Component only when the container justifies it.
|
|
236
|
+
4. Sequence and erDiagram are optional; only when they add real clarity.
|
|
237
|
+
5. Every `mermaid` block carries the `mermaid.ink` link as an inline blockquote.
|
|
238
|
+
6. `{{PLACEHOLDER}}` placeholders always replaced — never leave unfilled markers.
|
|
237
239
|
|
|
238
240
|
## Output
|
|
239
241
|
|
|
240
|
-
|
|
242
|
+
Produces under `docs/diagrams/NNN-export-diagrams-YYYY-MM-DD/`:
|
|
243
|
+
|
|
241
244
|
- `README.md`
|
|
242
|
-
- `diagrams.md` (
|
|
243
|
-
- `workspace.dsl` (
|
|
245
|
+
- `diagrams.md` (always)
|
|
246
|
+
- `workspace.dsl` (with `--engine c4`)
|
|
244
247
|
|
|
245
|
-
|
|
248
|
+
Writes only `docs/diagrams/` (invariants #1 and #2: only `export-*` graduates to `docs/`; this skill is composed by `export-diagrams`).
|
|
246
249
|
|
|
247
250
|
## Source
|
|
248
251
|
|
|
249
|
-
|
|
252
|
+
Rationale and history: design (`docs/referencias/workflow-roles/diagrams.md`).
|