baldart 5.6.0 → 5.8.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/CHANGELOG.md +98 -0
- package/VERSION +1 -1
- package/framework/.claude/agents/prd-card-writer.md +23 -0
- package/framework/.claude/skills/capture/CHANGELOG.md +4 -0
- package/framework/.claude/skills/capture/SKILL.md +2 -1
- package/framework/.claude/skills/design-sync/CHANGELOG.md +4 -0
- package/framework/.claude/skills/design-sync/SKILL.md +2 -1
- package/framework/.claude/skills/ds-edit/CHANGELOG.md +5 -0
- package/framework/.claude/skills/ds-edit/SKILL.md +9 -10
- package/framework/.claude/skills/ds-handoff/CHANGELOG.md +5 -0
- package/framework/.claude/skills/ds-handoff/SKILL.md +3 -2
- package/framework/.claude/skills/ds-new/CHANGELOG.md +4 -0
- package/framework/.claude/skills/ds-new/SKILL.md +2 -1
- package/framework/.claude/skills/ds-render/CHANGELOG.md +4 -0
- package/framework/.claude/skills/ds-render/SKILL.md +2 -1
- package/framework/.claude/skills/e2e-review/CHANGELOG.md +4 -0
- package/framework/.claude/skills/e2e-review/SKILL.md +2 -1
- package/framework/.claude/skills/gamification-design/CHANGELOG.md +4 -0
- package/framework/.claude/skills/gamification-design/SKILL.md +2 -1
- package/framework/.claude/skills/graph-align/CHANGELOG.md +4 -0
- package/framework/.claude/skills/graph-align/SKILL.md +2 -1
- package/framework/.claude/skills/i18n/CHANGELOG.md +4 -0
- package/framework/.claude/skills/i18n/SKILL.md +2 -1
- package/framework/.claude/skills/motion-design/CHANGELOG.md +4 -0
- package/framework/.claude/skills/motion-design/SKILL.md +2 -1
- package/framework/.claude/skills/new/CHANGELOG.md +19 -0
- package/framework/.claude/skills/new/SKILL.md +2 -1
- package/framework/.claude/skills/new/references/final-review.md +36 -1
- package/framework/.claude/skills/new2/CHANGELOG.md +15 -0
- package/framework/.claude/skills/new2/SKILL.md +2 -1
- package/framework/.claude/skills/prd/CHANGELOG.md +32 -0
- package/framework/.claude/skills/prd/SKILL.md +2 -1
- package/framework/.claude/skills/prd/assets/epic-template.yml +6 -0
- package/framework/.claude/skills/prd/references/backlog-phase.md +36 -0
- package/framework/.claude/skills/prd/references/validation-phase.md +30 -0
- package/framework/.claude/skills/prd-add/CHANGELOG.md +4 -0
- package/framework/.claude/skills/prd-add/SKILL.md +2 -1
- package/framework/.claude/skills/skill-creator/references/skill-structure.md +31 -2
- package/framework/.claude/skills/skill-creator/scripts/quick_validate.py +25 -3
- package/framework/.claude/skills/ui-design/CHANGELOG.md +4 -0
- package/framework/.claude/skills/ui-design/SKILL.md +2 -1
- package/framework/.claude/skills/ui-implement/CHANGELOG.md +4 -0
- package/framework/.claude/skills/ui-implement/SKILL.md +2 -1
- package/framework/.claude/workflows/new2.js +24 -3
- package/framework/agents/card-schema.md +50 -0
- package/package.json +1 -1
- package/src/commands/configure.js +9 -2
- package/src/commands/doctor.js +65 -0
- package/src/utils/skill-gate.js +139 -0
- package/src/utils/symlinks.js +72 -7
package/CHANGELOG.md
CHANGED
|
@@ -5,6 +5,104 @@ All notable changes to BALDART will be documented in this file.
|
|
|
5
5
|
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
|
|
6
6
|
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
7
7
|
|
|
8
|
+
## [5.8.0] - 2026-07-06
|
|
9
|
+
|
|
10
|
+
**Suggested launch plan at the end of `/prd` — waves with a NAME, persisted on the epic card.**
|
|
11
|
+
`/prd` used to close with a progress bar and a bare summary (PRD path, card IDs, branch, PR/SHA)
|
|
12
|
+
but never told you **how to launch `/new`** — one run or several waves, where the boundaries are,
|
|
13
|
+
which engine. You had to reason it out by hand. Now every `/prd` run ends with a mandatory
|
|
14
|
+
**"🚀 Piano di implementazione suggerito"** section, and the plan is **persisted on the epic
|
|
15
|
+
card** so `/new`/`/new2` can, at the end of a subset run, remind you which waves remain to close
|
|
16
|
+
the epic — each wave carries a short, memorable **name** ("Wave 1 · Fondamenta server").
|
|
17
|
+
|
|
18
|
+
The design was hardened by a two-reviewer adversarial pass that refuted the obvious v1
|
|
19
|
+
(a separate `implementation_plan` block, an `engine` field on the card, a new reference module,
|
|
20
|
+
the mechanical card-writer computing the heuristic). The shipped shape:
|
|
21
|
+
|
|
22
|
+
- **Drift-free persistence — no new block, no new module.** The wave partition is three OPTIONAL
|
|
23
|
+
sub-keys (`wave` / `wave_name` / `wave_rationale`) on the EXISTING `execution_strategy.groups[]`
|
|
24
|
+
entries — the single card-ID partition already consumed by `/new` for parallelism. No parallel
|
|
25
|
+
`waves[]` array re-listing card IDs (that would drift). Because they are sub-keys of an
|
|
26
|
+
already-`R` field, the baseline validator never sees them: **no new field-state-matrix row, no
|
|
27
|
+
migration of legacy epics**. Schema SSOT: `framework/agents/card-schema.md`.
|
|
28
|
+
- **Compute-by-orchestrator / persist-by-writer** (the `provenance.planning_session` split):
|
|
29
|
+
the `/prd` orchestrator (opus/high) computes the single-run-vs-waves judgment + names + rationale
|
|
30
|
+
— it needs the discovery context (migration-early, `review_profile: deep` pressure, server↔UI
|
|
31
|
+
cut) the mechanical `prd-card-writer` never holds — and persists it with a targeted Edit on the
|
|
32
|
+
epic card. The card-writer emits the keys ONLY when handed them; else it omits them (explicit
|
|
33
|
+
else branch → no fabrication). Single-run is the default (no wave tags).
|
|
34
|
+
- **Engine + hard rules are render-time, never persisted.** The `/new` vs `/new2` recommendation
|
|
35
|
+
is computed at render and is **runtime-aware** — `/new2` needs the Workflow tool and is
|
|
36
|
+
Claude-only, so on Codex the plan recommends `/new` only. A durable, cross-tool artifact must
|
|
37
|
+
not carry a runtime-capability recommendation a Codex consumer cannot execute.
|
|
38
|
+
- **`/new` + `/new2` remaining-waves.** `/new`'s Step F.6 "Prossimi Passi" and `/new2`'s
|
|
39
|
+
`buildReport()` "Epic goal" render the remaining waves BY NAME (fallback to the flat card list
|
|
40
|
+
when the epic has no wave tags — no regression). `/new2` runs fs-less, so the `wave_name` is
|
|
41
|
+
threaded through `cardGraph` (new `waveName` node field derived by the preflight agent).
|
|
42
|
+
- Project-specific between-wave cautions (migration/deploy gate, compile check, stash) stay in
|
|
43
|
+
`.baldart/overlays/prd.md` and are surfaced at render-time — no stack names in the base.
|
|
44
|
+
|
|
45
|
+
No new `baldart.config.yml` key (rides on the existing `execution_strategy` + `features.*`) → the
|
|
46
|
+
schema-change propagation rule does NOT apply. **Codex parity: portable** (runtime-neutral field;
|
|
47
|
+
engine computed at render-time; `/new2` remaining-waves via `cardGraph`).
|
|
48
|
+
|
|
49
|
+
Skills bumped: `prd` 1.6.1→1.7.0, `new` 2.3.1→2.4.0, `new2` 1.8.1→1.9.0.
|
|
50
|
+
|
|
51
|
+
## [5.7.0] - 2026-07-06
|
|
52
|
+
|
|
53
|
+
**Feature-gated skill linking — stop wasting Codex's 2% skill-description budget.** Codex
|
|
54
|
+
reserves ~2% of its context window for skill descriptions; BALDART's ~40 skills alone
|
|
55
|
+
already exceed it (~6.5k tokens), so Codex warns *"Skill descriptions were shortened to fit
|
|
56
|
+
the 2% skills context budget"* and truncates them (degrading skill routing). Until now the
|
|
57
|
+
installer linked EVERY framework skill into a consumer — including ones whose gating
|
|
58
|
+
`features.*` flag is OFF (e.g. the `ds-*` cluster, `i18n`, `graph-align`, `e2e-review`),
|
|
59
|
+
which then merely refuse at runtime: dead weight on the budget. Now a skill is linked only
|
|
60
|
+
when its declared feature is enabled, trimming ~2.5k tokens (~40%) on a typical project
|
|
61
|
+
without design-system/i18n/code-graph/e2e.
|
|
62
|
+
|
|
63
|
+
- **`requires_feature` frontmatter (SSOT) + `src/utils/skill-gate.js`**: an OPTIONAL
|
|
64
|
+
`requires_feature: has_x` (string or list = AND) on a skill's `SKILL.md`. Makes
|
|
65
|
+
machine-readable a dependency the skills already declared in prose (their "Project
|
|
66
|
+
Context" header) — no second SSOT, same pattern as `version:`/`effort:`. `resolveSkillGate`
|
|
67
|
+
reads `features.*` **directly** from `baldart.config.yml` (NOT `agent-slots.resolveAgentFlags`,
|
|
68
|
+
which omits `has_prd_workflow`/`has_e2e_review`) and **fails open** globally (config
|
|
69
|
+
absent/unreadable → link everything) and per-skill (malformed frontmatter → link that skill).
|
|
70
|
+
- **Applied to BOTH runtimes from one code path** (`mergeSkills` in `src/utils/symlinks.js`):
|
|
71
|
+
the gate is shared SEMANTICS (which skills are relevant), not runtime mechanics, so Claude
|
|
72
|
+
(`.claude/skills/`) and Codex (`.agents/skills/`) stay identical by construction. Adds the
|
|
73
|
+
**prune** direction — a feature flipped off (or a fail-open first install) now removes stale
|
|
74
|
+
framework symlinks, never touching a user skill dir or a user-override symlink pointing
|
|
75
|
+
elsewhere.
|
|
76
|
+
- **17 skills gated**: `has_design_system` → ui-design, ui-implement, ds-new, ds-edit,
|
|
77
|
+
ds-render, design-sync, ds-handoff, motion-design, gamification-design · `has_i18n` → i18n ·
|
|
78
|
+
`has_code_graph` → graph-align · `has_e2e_review` → e2e-review · `has_prd_workflow` → prd,
|
|
79
|
+
prd-add · `has_backlog` → new, new2 · `has_wiki_overlay` → capture. The five bootstrap
|
|
80
|
+
skills (`design-system-init`, `i18n-adopt`, `graphify-bootstrap`, `lsp-bootstrap`,
|
|
81
|
+
`toolchain-bootstrap`) stay ALWAYS-linked so a feature can always be turned on — then
|
|
82
|
+
`configure`/`update` re-merge and the cluster appears.
|
|
83
|
+
- **Lifecycle wiring**: `configure` now re-runs `mergeSkills` after writing config (first
|
|
84
|
+
install linked fail-open before the config existed — this is what actually prunes);
|
|
85
|
+
`update` already re-merges (prune committed via `BALDART_MANAGED_PATTERNS`); `doctor` gains
|
|
86
|
+
a non-blocking `reconcile-skills` advisory when a gated-off skill is still linked, and its
|
|
87
|
+
skill sample-probe no longer samples gatable skills (`prd`/`capture`). `skill-creator`:
|
|
88
|
+
`quick_validate.py` allow-lists `requires_feature` (it previously HARD-FAILED on unknown
|
|
89
|
+
keys) + soft-warns unknown flags; `references/skill-structure.md` documents the field.
|
|
90
|
+
`new2.js` binding-gate now guards on `has_design_system`.
|
|
91
|
+
- **Behaviour change for Claude consumers**: a skill whose feature is off now *disappears*
|
|
92
|
+
from `.claude/skills/` instead of appearing and refusing at runtime. Mitigated: bootstraps
|
|
93
|
+
stay visible, and re-enabling the feature (then any merge) brings the cluster back.
|
|
94
|
+
- **Rider — two skill descriptions made `quick_validate`-clean** (pre-existing failures, both
|
|
95
|
+
among the heaviest so this also shrinks the Codex budget): `ds-edit` description trimmed
|
|
96
|
+
1080→1014 chars (was over the 1024 max), `ds-handoff` angle-bracket placeholder
|
|
97
|
+
(`<screens-or-feature>`) rephrased bracket-free — no trigger phrases lost.
|
|
98
|
+
- Verified: unit-level gate partitioning (design_system-off/backlog-on → 15 gated off, `new`
|
|
99
|
+
linked, bootstrap present), YAML validity of all 17 frontmatters, `quick_validate` PASS.
|
|
100
|
+
- **No new `baldart.config.yml` key** (consumes existing `features.*`) → the schema-change
|
|
101
|
+
propagation rule does NOT apply; it is skill-frontmatter metadata like `version`/`effort`.
|
|
102
|
+
- **Codex parity: portable** — single semantic filter, both runtimes, install-time only;
|
|
103
|
+
`requires_feature` is ignored by both skill loaders (they read only name+description, as
|
|
104
|
+
they already do for `version`/`effort`).
|
|
105
|
+
|
|
8
106
|
## [5.6.0] - 2026-07-04
|
|
9
107
|
|
|
10
108
|
**Outcome-integrity wave (FEAT-0068 post-mortem — mayo, 72.78M token, DONE falso).** Il
|
package/VERSION
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
5.
|
|
1
|
+
5.8.0
|
|
@@ -754,6 +754,29 @@ The consumer (`new/SKILL.md`) reads `execution_strategy.groups[].level` and
|
|
|
754
754
|
`.cards`. Use these exact keys — `groups`/`level`, not the legacy
|
|
755
755
|
`parallel_groups`/`group`.
|
|
756
756
|
|
|
757
|
+
**Launch-wave sub-fields (`wave` / `wave_name` / `wave_rationale`) — write ONLY if handed to you.**
|
|
758
|
+
The `/prd` orchestrator may pass a launch-wave partition (a run-sequencing judgment it computes
|
|
759
|
+
AFTER you return the Parallel Execution Map — it needs discovery context you do not hold). When
|
|
760
|
+
and only when the orchestrator hands you these values, add them as optional sub-keys on the
|
|
761
|
+
matching `groups[]` entries:
|
|
762
|
+
|
|
763
|
+
```yaml
|
|
764
|
+
groups:
|
|
765
|
+
- level: 0
|
|
766
|
+
cards: [FEAT-XXXX-01]
|
|
767
|
+
description: "Foundation/scaffold"
|
|
768
|
+
wave: 1 # only if passed
|
|
769
|
+
wave_name: "Fondamenta server" # only if passed
|
|
770
|
+
wave_rationale: "…" # only if passed
|
|
771
|
+
```
|
|
772
|
+
|
|
773
|
+
If the orchestrator does NOT hand you a wave partition, **OMIT all three keys** — do NOT invent a
|
|
774
|
+
wave grouping, a name, or a rationale (a launch judgment fabricated from the card graph alone is
|
|
775
|
+
worse than absent; single-run epics legitimately carry no wave tags). This is the same
|
|
776
|
+
compute-by-orchestrator / persist-by-writer split as `provenance.planning_session`. Schema + the
|
|
777
|
+
render-time derivation live in [`framework/agents/card-schema.md`](../../agents/card-schema.md)
|
|
778
|
+
§ "`execution_strategy.groups[].wave*`".
|
|
779
|
+
|
|
757
780
|
## Output Format
|
|
758
781
|
|
|
759
782
|
**Self-validation BEFORE returning (v5.6.0 — you own your domain's deterministic hygiene).**
|
|
@@ -2,6 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.0.1 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_wiki_overlay` frontmatter — this skill is now linked into a consumer only when `features.has_wiki_overlay` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
|
|
5
9
|
## 1.0.0 — 2026-07-01
|
|
6
10
|
|
|
7
11
|
- Baseline: versioning per-skill introdotto al framework v4.82.0.
|
|
@@ -2,7 +2,8 @@
|
|
|
2
2
|
name: capture
|
|
3
3
|
effort: medium
|
|
4
4
|
description: Distilla una sintesi cross-document della conversazione recente in una synthesis page riusabile del wiki overlay (path da `paths.wiki_dir`/syntheses/ in `baldart.config.yml`). Usare quando l'utente invoca `/capture`, dice "capture synthesis", "salva sintesi", "distilla conversazione", "save this as wiki", "questa conversazione in wiki", o quando chiede di trasformare un ragionamento cross-document appena fatto in una pagina stabile. Due modalità — manual (sempre funzionante) e proactive (conditional sui candidati in `.claude/capture-queue/`). Implementa il loop query→wiki file-back di Karpathy.
|
|
5
|
-
version: 1.0.
|
|
5
|
+
version: 1.0.1
|
|
6
|
+
requires_feature: has_wiki_overlay
|
|
6
7
|
---
|
|
7
8
|
|
|
8
9
|
# /capture — Synthesis Capture Skill
|
|
@@ -2,6 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.0.1 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_design_system` frontmatter — this skill is now linked into a consumer only when `features.has_design_system` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
|
|
5
9
|
## 1.0.0 — 2026-07-01
|
|
6
10
|
|
|
7
11
|
- Baseline: versioning per-skill introdotto al framework v4.82.0.
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: design-sync
|
|
3
3
|
effort: high
|
|
4
|
-
version: 1.0.
|
|
4
|
+
version: 1.0.1
|
|
5
|
+
requires_feature: has_design_system
|
|
5
6
|
description: >
|
|
6
7
|
Keep the in-repo design system (the SSOT) and its Claude Design satellite
|
|
7
8
|
"mirror" project in sync — the code→design half of the closed loop. Three modes:
|
|
@@ -2,6 +2,11 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.1.1 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_design_system` frontmatter — this skill is now linked into a consumer only when `features.has_design_system` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
- **Description trimmed to pass `quick_validate`**: the `description` was 1080 chars (over the 1024 max); compressed to 1014 without losing any trigger phrase. Also shrinks the Codex skill-description budget.
|
|
9
|
+
|
|
5
10
|
## 1.1.0 — 2026-07-02
|
|
6
11
|
|
|
7
12
|
- **P1 locate hardening.** Reso esplicito che lo step P1 è un lookup deterministico
|
|
@@ -1,23 +1,22 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ds-edit
|
|
3
3
|
effort: medium
|
|
4
|
-
version: 1.1.
|
|
4
|
+
version: 1.1.1
|
|
5
|
+
requires_feature: has_design_system
|
|
5
6
|
description: >
|
|
6
7
|
Update ONE existing canonical design-system element correctly — the deliberate
|
|
7
8
|
edit twin of /ds-new. Classifies the change (resync the spec to changed source /
|
|
8
|
-
extend with a
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
framework/templates/component-spec.template.md filled if a spec is missing),
|
|
9
|
+
extend with a variant or prop / breaking change + migration / re-govern the
|
|
10
|
+
closed-set role) and runs it end to end: apply the source change (via ui-expert),
|
|
11
|
+
regenerate the spec via the serializer (HEAD from source, agentic + prose
|
|
12
|
+
PRESERVED, the canonical component-spec template filled if a spec is missing),
|
|
13
13
|
re-govern if needed, verify. A THIN orchestrator — delegates every rule to the
|
|
14
14
|
existing SSOTs, never hand-writes a spec HEAD. Use when the user says /ds-edit,
|
|
15
15
|
"aggiorna un componente", "modifica una primitive", "aggiungi una variante",
|
|
16
16
|
"estendi il componente", "resync dello spec", "breaking change su un
|
|
17
|
-
componente", or when `/prd` confirms a REUSE+VARIANT extension. The
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
features.has_design_system.
|
|
17
|
+
componente", or when `/prd` confirms a REUSE+VARIANT extension. The mechanical
|
|
18
|
+
doc-resync after a code change is ALREADY automatic (`DS_COMPONENT_STALE` gate)
|
|
19
|
+
— this skill is for the DELIBERATE change. Gated on features.has_design_system.
|
|
21
20
|
---
|
|
22
21
|
|
|
23
22
|
# DS Edit — update one existing canonical element
|
|
@@ -2,6 +2,11 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.2.1 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_design_system` frontmatter — this skill is now linked into a consumer only when `features.has_design_system` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
- **Description made `quick_validate`-clean**: removed the angle-bracket placeholder (`<screens-or-feature>`) the validator rejects, rephrased bracket-free without losing the standalone-invocation trigger.
|
|
9
|
+
|
|
5
10
|
## 1.2.0 — 2026-07-02
|
|
6
11
|
|
|
7
12
|
- **Analysis-profile contract (framework v4.94.0)**: the standalone screen-resolution probe passes `PROFILE=ui` to `codebase-architect` per `framework/agents/analysis-profiles.md`. The Step 3 field-extraction retrieval order is unchanged.
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ds-handoff
|
|
3
3
|
effort: medium
|
|
4
|
-
version: 1.2.
|
|
4
|
+
version: 1.2.1
|
|
5
|
+
requires_feature: has_design_system
|
|
5
6
|
description: >
|
|
6
7
|
Produce a FIELD-LEVEL, 1:1, interaction-complete handoff brief for Claude Design
|
|
7
8
|
— every screen's real fields (label, control type, required, validation, default,
|
|
@@ -9,7 +10,7 @@ description: >
|
|
|
9
10
|
data schemas (Zod / TS types / form schemas) via a coverage gate that BLOCKS prompt
|
|
10
11
|
emission when a backed screen's fields are unverified. The single SSOT for the
|
|
11
12
|
Claude Design handoff prompt: `/prd` Step 3.0 Branch B delegates here; usable
|
|
12
|
-
standalone via `/ds-handoff
|
|
13
|
+
standalone via `/ds-handoff` with a screen list or feature. A THIN orchestrator — cites
|
|
13
14
|
`design-system-protocol.md` (Functional Traceability Gate, Reference Tables) and
|
|
14
15
|
reads `mockup_analysis` as input, never duplicating their rules; reuses existing
|
|
15
16
|
retrieval (code-graph / LSP / codebase-architect / Grep) rather than shipping a
|
|
@@ -2,6 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.1.1 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_design_system` frontmatter — this skill is now linked into a consumer only when `features.has_design_system` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
|
|
5
9
|
## 1.1.0 — 2026-07-02
|
|
6
10
|
|
|
7
11
|
- **Reuse-first hardening.** Reso esplicito che lo step 1 reuse-first resta il
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ds-new
|
|
3
3
|
effort: medium
|
|
4
|
-
version: 1.1.
|
|
4
|
+
version: 1.1.1
|
|
5
|
+
requires_feature: has_design_system
|
|
5
6
|
description: >
|
|
6
7
|
Create ONE canonical design-system element — a component OR a token — end to
|
|
7
8
|
end with the full discipline: reuse-first research, (optional) scaffold, then
|
|
@@ -2,6 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.0.1 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_design_system` frontmatter — this skill is now linked into a consumer only when `features.has_design_system` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
|
|
5
9
|
## 1.0.0 — 2026-07-01
|
|
6
10
|
|
|
7
11
|
- Baseline: versioning per-skill introdotto al framework v4.82.0.
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: ds-render
|
|
3
3
|
effort: medium
|
|
4
|
-
version: 1.0.
|
|
4
|
+
version: 1.0.1
|
|
5
|
+
requires_feature: has_design_system
|
|
5
6
|
description: >
|
|
6
7
|
Render the design-system primitives in ISOLATION (one component × variant at a
|
|
7
8
|
time) and capture a PNG per entry — the render harness BALDART never had (today
|
|
@@ -2,6 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.3.2 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_e2e_review` frontmatter — this skill is now linked into a consumer only when `features.has_e2e_review` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
|
|
5
9
|
## 1.3.1 — 2026-07-03
|
|
6
10
|
|
|
7
11
|
- Boundary pointer: "Not a design generator" ora punta solo a `ui-design`
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: e2e-review
|
|
3
3
|
effort: medium
|
|
4
|
-
version: 1.3.
|
|
4
|
+
version: 1.3.2
|
|
5
|
+
requires_feature: has_e2e_review
|
|
5
6
|
description: >
|
|
6
7
|
Deterministic, BLOCKING end-to-end review run after a feature is implemented.
|
|
7
8
|
Combines functional E2E (Playwright spec written by `coder`, executed via
|
|
@@ -2,6 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.0.2 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_design_system` frontmatter — this skill is now linked into a consumer only when `features.has_design_system` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
|
|
5
9
|
## 1.0.1 — 2026-07-03
|
|
6
10
|
|
|
7
11
|
- Related Skills: `ui-ux-pro-max` (superseded) sostituito con `ui-design` v2
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: gamification-design
|
|
3
3
|
effort: medium
|
|
4
|
-
version: 1.0.
|
|
4
|
+
version: 1.0.2
|
|
5
|
+
requires_feature: has_design_system
|
|
5
6
|
description: Use when designing or analyzing points systems, reward loops, progression mechanics, engagement features, or loyalty programs. Triggers include "points system," "rewards design," "progression," "engagement loop," "battle pass," "loyalty mechanics," "gamification," or "retention hooks." For B2C customer-facing features in this codebase, this skill invokes the hyper-gamification-designer agent.
|
|
6
7
|
---
|
|
7
8
|
|
|
@@ -2,6 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.0.1 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_code_graph` frontmatter — this skill is now linked into a consumer only when `features.has_code_graph` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
|
|
5
9
|
## 1.0.0 — 2026-07-01
|
|
6
10
|
|
|
7
11
|
- Baseline: versioning per-skill introdotto al framework v4.82.0.
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: graph-align
|
|
3
3
|
effort: medium
|
|
4
|
-
version: 1.0.
|
|
4
|
+
version: 1.0.1
|
|
5
|
+
requires_feature: has_code_graph
|
|
5
6
|
description: >
|
|
6
7
|
On-demand documentation alignment via the Graphify code knowledge graph.
|
|
7
8
|
Rebuilds the graph offline (graphify update .), then cross-checks graph
|
|
@@ -2,6 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.0.1 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_i18n` frontmatter — this skill is now linked into a consumer only when `features.has_i18n` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
|
|
5
9
|
## 1.0.0 — 2026-07-01
|
|
6
10
|
|
|
7
11
|
- Baseline: versioning per-skill introdotto al framework v4.82.0.
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: i18n
|
|
3
3
|
effort: medium
|
|
4
|
-
version: 1.0.
|
|
4
|
+
version: 1.0.1
|
|
5
|
+
requires_feature: has_i18n
|
|
5
6
|
description: >
|
|
6
7
|
On-demand internationalization audit + context-aware translation. Audits the
|
|
7
8
|
i18n context registry against the t() calls and native locale files (drift
|
|
@@ -2,6 +2,10 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.0.1 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Feature-gate**: added `requires_feature: has_design_system` frontmatter — this skill is now linked into a consumer only when `features.has_design_system` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
8
|
+
|
|
5
9
|
## 1.0.0 — 2026-07-01
|
|
6
10
|
|
|
7
11
|
- Baseline: versioning per-skill introdotto al framework v4.82.0.
|
|
@@ -2,6 +2,25 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 2.4.0 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Prossime wave per NOME nel messaggio finale.** Il Step F.6 "Prossimi Passi"
|
|
8
|
+
(`references/final-review.md`) ora è **wave-aware**: legge la partizione di lancio persistita
|
|
9
|
+
da `/prd` sull'epic card (sotto-campi opzionali `wave` / `wave_name` su
|
|
10
|
+
`execution_strategy.groups[]`) e, quando presente, mostra le **wave rimanenti per nome**
|
|
11
|
+
("Prossime wave: **Wave 2 · Superfici UI**") invece della sola lista card piatta — così, dopo
|
|
12
|
+
aver implementato un subset (es. `/new FEAT-0069-01..06`), il riepilogo dice cosa resta per
|
|
13
|
+
chiudere l'epic senza doverlo ricordare. Engine della prossima wave suggerito runtime-aware
|
|
14
|
+
(Codex → solo `/new`). Richiede un Read esplicito dell'epic card a F.6 (non è in contesto:
|
|
15
|
+
letto solo transitoriamente in Phase 0). **Fallback grazioso** alla lista card piatta quando
|
|
16
|
+
l'epic non ha tag wave (single-run / legacy) → nessuna regressione. Schema SSOT:
|
|
17
|
+
`framework/agents/card-schema.md` § `execution_strategy.groups[].wave*`.
|
|
18
|
+
- Codex parity: portable (il campo è runtime-neutral; l'engine è calcolato a render-time).
|
|
19
|
+
|
|
20
|
+
## 2.3.1 — 2026-07-06
|
|
21
|
+
|
|
22
|
+
- **Feature-gate**: added `requires_feature: has_backlog` frontmatter — this skill is now linked into a consumer only when `features.has_backlog` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
23
|
+
|
|
5
24
|
## 2.3.0 — 2026-07-04 (FEAT-0068 post-mortem: integrità dell'esito)
|
|
6
25
|
|
|
7
26
|
- **Chiusura epic: solo in merge phase, predicato esteso** — `commit.md` c-bis RITIRATO
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: new
|
|
3
3
|
effort: medium
|
|
4
|
-
version: 2.
|
|
4
|
+
version: 2.4.0
|
|
5
|
+
requires_feature: has_backlog
|
|
5
6
|
description: >
|
|
6
7
|
Orchestrate a team of specialized agents to implement one or more backlog cards
|
|
7
8
|
end-to-end inside a dedicated worktree, with code review, doc review, QA, and
|
|
@@ -439,7 +439,42 @@ that is a **gate violation**: log it as
|
|
|
439
439
|
| xargs grep -L "status: DONE"
|
|
440
440
|
```
|
|
441
441
|
|
|
442
|
-
|
|
442
|
+
**Wave-aware next steps (v5.8.0).** `/prd` may have persisted a **launch-wave partition** on the
|
|
443
|
+
epic card — optional `wave` / `wave_name` sub-keys on `execution_strategy.groups[]` (schema:
|
|
444
|
+
`framework/agents/card-schema.md` § "`execution_strategy.groups[].wave*`"). The epic card is NOT
|
|
445
|
+
in context here (it was read only transiently in Phase 0) — so **Read the epic card now**
|
|
446
|
+
(`${paths.backlog_dir}/<EPIC-ID>.yml`) to fetch the wave tags. Then:
|
|
447
|
+
- **If wave tags exist:** map each remaining not-DONE card to its `wave_name` (via the group whose
|
|
448
|
+
`.cards` contains it), and render the **remaining WAVES by name** instead of a flat card list — a
|
|
449
|
+
wave is "rimanente" when ≥1 of its cards is not-DONE. This keeps the thread across runs: the user
|
|
450
|
+
recognises "Wave 2 · Superfici UI" from the `/prd` plan. Suggest the engine for the NEXT wave
|
|
451
|
+
runtime-aware (Claude → `/new2` for a high-volume wave, else `/new`; Codex → `/new` only —
|
|
452
|
+
`/new2` is Claude-only).
|
|
453
|
+
- **If NO wave tags** (legacy epic / single-run): render the flat "Card rimanenti nell'epic" table
|
|
454
|
+
exactly as before (backwards-compat, no regression).
|
|
455
|
+
|
|
456
|
+
Present the section — WAVE-AWARE form (when wave tags exist):
|
|
457
|
+
|
|
458
|
+
```
|
|
459
|
+
## Prossimi Passi
|
|
460
|
+
|
|
461
|
+
### Prossime wave da sviluppare
|
|
462
|
+
| Wave | Nome | Card rimanenti | Engine suggerito |
|
|
463
|
+
|------|------|----------------|------------------|
|
|
464
|
+
| 2 | Superfici UI & closer | FEAT-XXXX-07…13 | /new2 |
|
|
465
|
+
|
|
466
|
+
### Lancio prossima wave (copia e incolla)
|
|
467
|
+
```
|
|
468
|
+
/new2 FEAT-XXXX-07-FEAT-XXXX-13
|
|
469
|
+
```
|
|
470
|
+
|
|
471
|
+
### Card completate in questa sessione
|
|
472
|
+
| Card | Titolo | Commit |
|
|
473
|
+
|------|--------|--------|
|
|
474
|
+
| FEAT-XXXX-01 | [title] | abc1234 |
|
|
475
|
+
```
|
|
476
|
+
|
|
477
|
+
FLAT form (no wave tags — unchanged):
|
|
443
478
|
|
|
444
479
|
```
|
|
445
480
|
## Prossimi Passi
|
|
@@ -2,6 +2,21 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.9.0 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Prossime wave per NOME nel report finale (parità con `/new`).** `buildReport()` (`new2.js`)
|
|
8
|
+
ora, per ogni epic APERTA nella sezione "Epic goal", elenca le **wave rimanenti per nome**
|
|
9
|
+
dalla partizione di lancio persistita da `/prd` sull'epic. Poiché il workflow gira senza
|
|
10
|
+
accesso al filesystem, il `wave_name` è **portato via `cardGraph`** (nuovo campo `waveName`
|
|
11
|
+
sul nodo — l'agente preflight lo deriva dai `execution_strategy.groups[]` dell'epic). Scope
|
|
12
|
+
onesto: visibili solo le wave le cui card sono NEL BATCH (le wave interamente fuori dal batch
|
|
13
|
+
non sono caricate). `''` quando l'epic non ha tag wave (single-run / legacy) → nessuna riga.
|
|
14
|
+
- Codex parity: portable (il campo è runtime-neutral).
|
|
15
|
+
|
|
16
|
+
## 1.8.1 — 2026-07-06
|
|
17
|
+
|
|
18
|
+
- **Feature-gate**: added `requires_feature: has_backlog` frontmatter — this skill is now linked into a consumer only when `features.has_backlog` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
19
|
+
|
|
5
20
|
## 1.8.0 — 2026-07-04 (FEAT-0068 post-mortem: integrità dell'esito + igiene git)
|
|
6
21
|
|
|
7
22
|
- **`new2.js`**: step 4b (chiusura epic) RIMOSSO dal commit agent — la chiusura vive
|
|
@@ -2,6 +2,38 @@
|
|
|
2
2
|
|
|
3
3
|
Formato: [Keep a Changelog](https://keepachangelog.com/) · [SemVer](https://semver.org/).
|
|
4
4
|
|
|
5
|
+
## 1.7.0 — 2026-07-06
|
|
6
|
+
|
|
7
|
+
- **Piano di implementazione suggerito nel messaggio finale (sempre).** Il run di `/prd` ora
|
|
8
|
+
chiude con una sezione **"🚀 Piano di implementazione suggerito"** che dice come lanciare
|
|
9
|
+
`/new` — unica run vs **wave con NOME**, confini, engine (`/new` vs `/new2`) — invece di
|
|
10
|
+
lasciare all'utente il compito di ricavarla a mano. La logica del piano è **persistita
|
|
11
|
+
sull'epic card** così `/new`/`/new2` a fine run possono ricordare quali wave restano.
|
|
12
|
+
- **Persistenza drift-free:** nessun blocco nuovo — sotto-campi OPZIONALI `wave` / `wave_name`
|
|
13
|
+
/ `wave_rationale` sui `groups[]` esistenti di `execution_strategy` (unica partizione di
|
|
14
|
+
card-ID; niente `waves[]` parallelo che drifta). Sono sotto-chiavi di un campo già `R` →
|
|
15
|
+
il baseline validator non le vede, **nessuna riga nuova nella field-state matrix**, epic
|
|
16
|
+
legacy invariate. Schema SSOT: `framework/agents/card-schema.md`.
|
|
17
|
+
- **Compute-by-orchestrator / persist-by-writer** (stesso split di `provenance.planning_session`):
|
|
18
|
+
l'**orchestratore `/prd`** calcola la partizione wave + nomi + rationale (giudizio di lancio
|
|
19
|
+
che serve il contesto di discovery — migration-early, pressione review `deep`, taglio
|
|
20
|
+
server/UI) e la persiste con un Edit mirato sull'epic card; il `prd-card-writer` scrive i
|
|
21
|
+
sotto-campi **solo se gli vengono passati**, altrimenti li omette (ramo else esplicito →
|
|
22
|
+
niente fabbricazione). Single-run resta il default: nessun tag wave.
|
|
23
|
+
- **Engine + hard-rule = render-time, non persistiti.** La scelta `/new` vs `/new2` è calcolata
|
|
24
|
+
a render ed è runtime-aware (Codex → solo `/new`, `/new2` è Claude-only) — un artefatto
|
|
25
|
+
cross-tool durabile non porta una raccomandazione che un consumer Codex non può eseguire.
|
|
26
|
+
- **Base generico + overlay:** cautele project-specific tra-wave (migration/deploy gate, compile
|
|
27
|
+
check, stash) restano in `.baldart/overlays/prd.md`, innestate a render-time.
|
|
28
|
+
- File: `references/backlog-phase.md` (compute+persist), `references/validation-phase.md`
|
|
29
|
+
(render), `assets/epic-template.yml` (chiavi commentate), `framework/agents/card-schema.md`
|
|
30
|
+
(schema), `framework/.claude/agents/prd-card-writer.md` (omit-if-not-passed).
|
|
31
|
+
- Codex parity: portable (campo runtime-neutral; engine calcolato a render-time).
|
|
32
|
+
|
|
33
|
+
## 1.6.1 — 2026-07-06
|
|
34
|
+
|
|
35
|
+
- **Feature-gate**: added `requires_feature: has_prd_workflow` frontmatter — this skill is now linked into a consumer only when `features.has_prd_workflow` is enabled (it already refused at runtime otherwise). Trims Codex's ~2% skill-description budget on projects without the feature. Install-time gate, portable across Claude + Codex.
|
|
36
|
+
|
|
5
37
|
## 1.6.0 — 2026-07-04 (FEAT-0068 post-mortem: il root cause era qui)
|
|
6
38
|
|
|
7
39
|
- **ISA "UI ROLE FAMILY (registry-first)"** (`discovery-phase.md` Dimension 9, gated su
|
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: prd
|
|
3
3
|
effort: high
|
|
4
|
-
version: 1.
|
|
4
|
+
version: 1.7.0
|
|
5
|
+
requires_feature: has_prd_workflow
|
|
5
6
|
description: "Structured PRD creation skill. Use when the user says /prd, 'crea un prd', 'nuova funzionalita', 'pianifica feature', or wants to plan a new feature end-to-end. Also handles /prd-add, 'aggiungi requisito', 'serve anche', 'manca un endpoint' for change requests on active PRD sessions — runs ICIAS impact analysis to determine which phases need SKIP/PATCH/REDO. Produces PRD + UI design + backlog cards, all validated and committed. Multi-turn conversation: asks questions, waits for answers, iterates through discovery, design, spec writing, card creation, and validation phases."
|
|
6
7
|
---
|
|
7
8
|
|
|
@@ -135,6 +135,12 @@ execution_strategy:
|
|
|
135
135
|
- level: 0
|
|
136
136
|
cards: [{{FEAT-XXXX-01}}]
|
|
137
137
|
rationale: "{{foundation / first dependency layer}}"
|
|
138
|
+
# Optional launch-wave tags — written by the /prd ORCHESTRATOR only (not the card-writer),
|
|
139
|
+
# and only when the epic is launched across multiple /new runs. Omit entirely for
|
|
140
|
+
# single-run epics. Schema: agents/card-schema.md § execution_strategy.groups[].wave*
|
|
141
|
+
# wave: 1
|
|
142
|
+
# wave_name: "{{Fondamenta server}}"
|
|
143
|
+
# wave_rationale: "{{migration + config + resolver + enforcement server}}"
|
|
138
144
|
- level: 1
|
|
139
145
|
cards: [{{FEAT-XXXX-02}}, {{FEAT-XXXX-03}}]
|
|
140
146
|
rationale: "{{parallel after L0}}"
|