Skip to content

feat(aidd-pm): add wireframe skill and renumber spec to 05#252

Open
alexsoyes wants to merge 8 commits into
mainfrom
worktree-sleepy-waddling-rocket
Open

feat(aidd-pm): add wireframe skill and renumber spec to 05#252
alexsoyes wants to merge 8 commits into
mainfrom
worktree-sleepy-waddling-rocket

Conversation

@alexsoyes

@alexsoyes alexsoyes commented Jun 7, 2026

Copy link
Copy Markdown
Contributor

🎯 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 from aidd_docs/ when one exists). Sits between the PRD and the spec in the PM pipeline.

🛠️ How it works

  • Placement by concern (docs/ARCHITECTURE.md): a wireframe is a read-only Knowledge artifact, so it lives in aidd-pm next to the PRD, not in aidd-refine and not as UI code.
  • Pipeline order over churn: inserted at 04, so 04-spec is renumbered to 05-spec (every hard reference updated; per-plugin CATALOG.md and README counts are hook-generated).
  • Mirrors 03-prd: single action, template-driven, validated before save under aidd_docs/tasks/. Output is Markdown + Mermaid only.
  • No document required: gathers optional context from aidd_docs/ (or the existing screens on a legacy project), then clarifies the screen inventory with the user before drawing anything.
  • Challenge without coupling: instead of invoking another plugin's agent, it ships a reviewer checklist and defers validation to the caller, the exact 05-spec pattern.

🧪 How to verify

  • git grep -n "04-spec" returns nothing outside CHANGELOG.md.
  • Generate a wireframe :)

✅ I certify

  • I self-reviewed this PR.

alexsoyes and others added 2 commits June 7, 2026 13:54
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>
@alexsoyes alexsoyes force-pushed the worktree-sleepy-waddling-rocket branch from 7fc1d24 to 2e50793 Compare June 7, 2026 12:13
alexsoyes and others added 2 commits June 7, 2026 14:27
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>
Comment thread plugins/aidd-pm/skills/04-wireframe/actions/01-wireframe.md Outdated
alexsoyes and others added 4 commits June 7, 2026 14:38
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>
@alexsoyes alexsoyes added the enhancement New feature or request label Jun 7, 2026
@alexsoyes

Copy link
Copy Markdown
Contributor Author

@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 ?

@alexsoyes alexsoyes marked this pull request as ready for review June 7, 2026 13:04
@alexsoyes alexsoyes requested a review from a team as a code owner June 7, 2026 13:04
## Outputs
```yaml
wireframe_path: aidd_docs/tasks/<yyyy_mm>/<yyyy_mm_dd>-<feature_name>-wireframe.md

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non pour moi les WF sont éphémères ils vont vites diverger du front, tu penses pas @blafourcade ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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é ?

@blafourcade

Copy link
Copy Markdown
Contributor

@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 ?

@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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants