feedback
Walk through structured feedback and submit it as a GitHub Issue on the Acumen repo.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Walk through structured feedback and submit it as a GitHub Issue on the Acumen repo.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Scope a single product increment end-to-end — context, spec, implementation, wireframes, and engineering considerations. Use when a feature or bet needs a shippable document before building — typically the option chosen out of /workshop's divergence. Leads to /critique-product.
Print a quick-reference cheatsheet of all Acumen skills, organized by layer.
Pull latest code from main, summarize recent changes in product-friendly terms, and report .acumen/ context health (what exists, what's fresh, what's stale, what's missing). Preserves all .acumen/ context files.
Evaluate and validate a PM artifact — score for rigor, test riskiest assumptions, and decide if it's ready to ship. Use when reviewing a PRD, spec, increment, strategy, or roadmap.
Find what's broken and what's underexploited — problems AND opportunities — grounded in data, value delivery per persona, and current features. The entry point to ideation; hands sharp problems and opportunities to /workshop.
One-time setup that gathers product context for your project and saves it to .acumen.md. Run once to establish persistent product guidelines.
| name | feedback |
| description | Walk through structured feedback and submit it as a GitHub Issue on the Acumen repo. |
| user-invocable | true |
Collect structured feedback from the user and submit it as a GitHub Issue on the Acumen repository (VGrss/Acumen).
Ask the user to pick one:
Ask: "What's the problem?"
Guide the user to describe what happened or what's missing. Be specific — ask follow-up questions if the description is vague. A good problem statement names the trigger ("when I run /diagnose…"), the observed behavior, and the expected behavior.
Ask: "Who does this affect and how?"
Guide the user to articulate:
Ask: "Do you have a solution in mind? (optional, feel free to skip)"
If the user has an idea, capture it. If not, move on — good feedback describes the problem well, not necessarily the fix.
Format the feedback as a preview and show it to the user:
## Category
{category}
## Problem
{problem description}
## Impact
{impact description}
## Suggested solution
{solution or "None provided"}
Ask the user to confirm or edit before submitting.
Use the GitHub CLI to create an Issue with a label matching the category:
gh issue create \
--repo VGrss/Acumen \
--label "{category label}" \
--title "{concise title derived from the problem}" \
--body "{formatted body}"
Use these labels based on category:
bugenhancementfeedbackThe body should follow this template:
## Problem
{problem description}
## Impact
{impact description}
## Suggested solution
{solution or "_None provided — feedback only._"}
---
_Submitted via `/feedback`_
Return the Issue URL to the user.
Be conversational but efficient. Each step is one question — don't dump all questions at once. Guide the user through the flow one step at a time, like a short interview.