feat(aidd-pm): add wireframe skill and renumber spec to 05#252
feat(aidd-pm): add wireframe skill and renumber spec to 05#252alexsoyes wants to merge 8 commits into
Conversation
Add aidd-pm:04-wireframe, a low-fidelity wireframe skill (screen inventory, ASCII layouts, Mermaid navigation flow) that turns a PRD or feature description into a read-only artifact saved under aidd_docs/tasks/. Stays in the Knowledge layer: no executable UI code. Insert it at its logical pipeline position (prd -> wireframe -> spec), renumbering 04-spec to 05-spec across plugin.json, READMEs, routing test fixtures, the project-init asset docs and their aidd_docs mirrors, UPGRADE.md and the hand-maintained docs/CATALOG.md. Per-plugin CATALOG.md and README counts were regenerated by the pre-commit hooks. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
Promote PRD reading to a first-class step and reuse the PRD feature_name so the wireframe sits next to it. Add a Clarify step that proposes a screen inventory and screen types for the user to confirm or challenge before any layout is drawn, plus optional platform and screen_types inputs. Add assets/wireframe-validator.yml mirroring the spec-validator pattern: the skill does not self-validate; a caller spawns a reviewer with the checklist. This gives a dedicated critique without coupling aidd-pm to another plugin's agents (orthogonality rule). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
7fc1d24 to
2e50793
Compare
Drop prd_path as an input. The action auto-loads a related PRD or user stories from aidd_docs/ when they exist, but a document is never a precondition: with nothing found, screens are derived from the feature description and the clarify dialogue. Updates SKILL, action contract, validator, and README accordingly. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
…iendly Broaden the context-gathering step beyond aidd_docs lookup: the skill is callable at any stage and, on a legacy project with no product docs, takes cues from the existing screens the user points to. Clarify this in SKILL, action, and README. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
Copy the template into aidd_docs/tasks/ as its own step, then fill that copy in place, instead of drafting then saving. Keeps scaffold and fill distinct. Updates the action process and tests, SKILL rules, and README. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
The action auto-loads a PRD or user stories from aidd_docs/ at runtime, so 'External data' must list it instead of None. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
Each fact now has one canonical home: the template owns the section list (action Outputs and README stop re-enumerating it), the SKILL owns the rules (action drops the repeated self-validate note), and the validator owns the quality criteria (Test drops the bullets that restated them). Trims the PRD-optional and scaffold-vs-fill wording that was repeated across SKILL, action, and README. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: alexsoyes <contact.alexsoyes@gmail.com>
|
@blafourcade tu veux qu'on se fasse quoi comme cycle de review ? Genre j'ai plein de modifs à faire ça va te prendre 1 an de tout review, on merge ça dans des releases qu'on teste ? |
| ## Outputs | ||
| ```yaml | ||
| wireframe_path: aidd_docs/tasks/<yyyy_mm>/<yyyy_mm_dd>-<feature_name>-wireframe.md |
There was a problem hiding this comment.
Je me posais la question de tout mettre ici Vs un dossier specs ou même dissocier entre pm et dev
On va avoir énormément de fichier petit à petit et les specs wireframe peuvent devenir de la documentation aussi @alexsoyes
There was a problem hiding this comment.
Non pour moi les WF sont éphémères ils vont vites diverger du front, tu penses pas @blafourcade ?
There was a problem hiding this comment.
Oui mais ça reste une spec en soit et tu peux avoir le même formalisme de dossier par mois etc. Ca permet de séparer un peu la partie Product de l'implementation de dev. Ce dossier va devenir un four tout entre plan review etc
| ## Process | ||
| 1. **Gather context**. Load a related PRD or user stories from `aidd_docs/` when present; otherwise work from `feature_description`. Optional, never a precondition. |
There was a problem hiding this comment.
Pourquoi ne pas séparer en actions plus petit et par responsabilité pour obtenir des input output et test beaucoup plus précis et logique dans l'enchaînement ? @alexsoyes
There was a problem hiding this comment.
Je sais pas si c'est nécessaire... en vrai possible mais est-ce qu'on en a vraiment besoin ? 🤷♂️
Pour le coup je saurais pas jauger la bonne pratique
There was a problem hiding this comment.
J'ai encouragé dans ce sens en formation pour avoir des actions scopé avec input output test précis pour justement s'assurer que l'IA fait chaque petite action bien et chainé ?
@alexsoyes poir le début je te propose de faire des pr assez petite comme celle la pour valider la vision ensemble. Ensuite on accélère vu qu'on aura pris en compte nos retours et logiques. Qu'en penses-tu ? |
🎯 What & why
Adds
aidd-pm:04-wireframe: turns a feature into a low-fidelity wireframe (screens, ASCII layouts, Mermaid flow). Callable at any stage, no PRD required (auto-loaded fromaidd_docs/when one exists). Sits between the PRD and the spec in the PM pipeline.🛠️ How it works
aidd-pmnext to the PRD, not inaidd-refineand not as UI code.04, so04-specis renumbered to05-spec(every hard reference updated; per-pluginCATALOG.mdand README counts are hook-generated).03-prd: single action, template-driven, validated before save underaidd_docs/tasks/. Output is Markdown + Mermaid only.aidd_docs/(or the existing screens on a legacy project), then clarifies the screen inventory with the user before drawing anything.05-specpattern.🧪 How to verify
git grep -n "04-spec"returns nothing outsideCHANGELOG.md.✅ I certify