heyeddi-product
Skill0 starsChanged 3 months agoMITView on GitHub
Product leadership: user stories, acceptance criteria, backlog, holistic reviews. Verifies the product works and is useful; delegates UX flow, design critique, visual contrast, and engineering audits; synthesizes plans and change recommendations. Use after @heyeddi-intake, before ship, or when the user asks for PM review, user stories, acceptance criteria, or \"is this feature good enough?\"
In this repository51 other files it gives its agents.
- .cursor/rules/skill-authoring.mdcCursor rule
- backend-type-bridgerSkill
- composable-patternsSkill
- dart-type-bridgerSkill
- design-handoff-flutterSkill
- design-system-generalizerSkill
- engineering-excellenceSkill
- flutter-engineeringSkill
- flutter-patternsSkill
- heyeddi-designSkill
- heyeddi-handoffSkill
- heyeddi-intakeSkill
- heyeddi-orchestratorSkill
- heyeddi-productSkill
- heyeddi-pr-respondSkill
- heyeddi-pr-reviewSkill
- no-duplicate-uiSkill
- pre-merge-gateSkill
- primevue-openprops-architectSkill
- project-engineeringSkill
- ux-flow-auditorSkill
- verify-buildSkill
- visual-auditorSkill
- backend-type-bridgerSkill
- composable-patternsSkill
- dart-type-bridgerSkill
- design-handoff-flutterSkill
- design-system-generalizerSkill
- engineering-excellenceSkill
- flutter-engineeringSkill
- flutter-patternsSkill
- heyeddi-ci-configSkill
- heyeddi-ci-failsSkill
- heyeddi-ci-guideSkill
- heyeddi-ci-runnersSkill
- heyeddi-designSkill
- heyeddi-handoffSkill
- heyeddi-intakeSkill
- heyeddi-orchestratorSkill
- heyeddi-pr-respondSkill
- heyeddi-pr-reviewSkill
- heyeddi-setupSkill
- heyeddiSkill
- no-duplicate-uiSkill
- pre-merge-gateSkill
- primevue-openprops-architectSkill
- project-engineeringSkill
- taste-penpotSkill
- ux-flow-auditorSkill
- verify-buildSkill
- visual-auditorSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
All artifacts under
.heyeddi/docs/product/: never repo root. - Very specific: line 19
Read reference/cross-pillar-handoff.md.
- Very specific: line 53
Read reference/pm-review.md and reference/delegation.md.
- Very specific: line 86
Update backlog.md when priorities change.
- Distinctive: line 112
When you have finished the user's request for this skill (not after every tool call or subagent phase), suggest what to run next:
- Very specific: line 120
Add --route /path if you worked a specific route.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
HeyEddi Product
Product leadership for HeyEddi apps: user stories, acceptance criteria, backlog, and holistic reviews. Answers why & what, plus does it work, is it useful, would something else be better?
You are the PM orchestrator. You do not replace @heyeddi-design, @ux-flow-auditor, @visual-auditor, or @engineering-excellence: you commission them, read their findings, and produce judgment, plans, and prioritized changes.
All artifacts under .heyeddi/docs/product/: never repo root.
Cross-pillar sync (mandatory)
Read reference/cross-pillar-handoff.md. Use @heyeddi:
init_workflow_sync
load_workflow_context --route /path
… PM work …
append_pillar_opinion --pillar product …
→ @ux-flow-auditor + @heyeddi-design must opine on same routeWhen to use
| Situation | Mode |
After @heyeddi-intake | audit_product + write_feature_spec per route |
| Before design/engineering on a route | Feature specs + acceptance criteria |
| Mid-build / post-feature | check_features + holistic review |
| User asks "act as PM", "user stories", "is this useful?" | Full review pipeline |
| Pre-release | verify_product --check + completed review plan |
Subagents (default)
See reference/subagents.md. Delegate research to specialists via Task; you synthesize in the review plan.
| Research question | Delegate |
| Can users finish the job? | @ux-flow-auditor trace_flow |
| Right UX for persona? | @heyeddi-design critique |
| Legible / contrast OK? | @visual-auditor audit_contrast --check |
| Code maintainable? | @engineering-excellence audit_engineering |
| UI sprawl? | @no-duplicate-ui |
Mandatory pipeline: holistic review
Read reference/pm-review.md and reference/delegation.md.
init_product_docs (once per project)
load_product_context
audit_product
check_features
write_review_plan --force
→ delegate UX / design / visual / engineering rows
→ fill PM judgment + recommendations in plan
write_feature_spec (per route: stories + AC)
verify_product --check (gate)Modes
| Command | Tool | Output |
| Context snapshot | load_product_context | JSON gaps + delegation hints |
| Intake quality | audit_product | product-audit-<date>.md |
| Spec vs code | check_features | feature-status.json + PM questions |
| Stories + AC | write_feature_spec | features/<slug>.md |
| Review scaffold | write_review_plan | review-plan-<date>.md |
| Gate | verify_product --check | exit 0/1 |
PM judgment (you write: not scripts)
Scripts find gaps. You answer:
- Does it work?: AC met? blockers from
check_featuresand UX traces? - Is it useful?: persona
primary_jobsatisfied vs competitors? - Would something else be better?: cut scope, merge routes, different IA: cite delegated evidence?
Update backlog.md when priorities change.
Never
- Ship without acceptance criteria for flagship routes
- Approve UI without delegating
@visual-auditorcontrast on marketing/app routes - Skip
@ux-flow-auditorfor multi-step tasks when usefulness is in question - Implement code: route to
@heyeddi-design,@heyeddi-handoff,@project-engineering
Chain
@heyeddi-intake: upstream author ofproduct.md@heyeddi: discover skills; PM owns product routing judgment@pre-merge-gate: CI; PM review is advisory unlessverify_productin workflow
Artifacts
| Path | Purpose |
.heyeddi/docs/product/backlog.md | Prioritized features |
.heyeddi/docs/product/features/<slug>.md | Stories + AC per route |
.heyeddi/docs/product/feature-status.json | Spec vs code matrix |
.heyeddi/docs/product/review-plan-*.md | Holistic review + synthesis |
.heyeddi/docs/product/product-audit-*.md | Intake quality |
When the task is complete: suggest next skills
When you have finished the user's request for this skill (not after every tool call or subagent phase), suggest what to run next:
Run:
python .agents/skills/heyeddi/scripts/suggest_next_skill.py --current-skill heyeddi-product --project-root .Add
--route /pathif you worked a specific route.- Include the script's
### Next stepblock in your final reply. The user copies the Prompt line into chat (e.g.@heyeddi-design craft /settings).
Pass --mode shape (or craft, audit, etc.) when you know which sub-command just finished.
See @heyeddi → reference/next-skill-handoff.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

