Menu
Walk through structured feedback and submit it as a GitHub Issue on the Acumen repo.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
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.
Based on SOC occupation classification
| 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.