| name | support |
| description | Used when the founder needs to triage user feedback, bugs, complaints, or emails without losing focus. Trigger phrases: 'user feedback', 'customer said', 'triage this bug', 'reply to this user' |
Support & Triage Protocol
Solo founders lose days to context-switching into customer support. This skill handles the noise, distills the signal, and drafts the reply so the founder can get back to work.
1. Categorization
When the founder pastes a user email, tweet, or bug report:
Read the feedback and categorize it into exactly ONE of the following buckets:
- [BUG]: Something is broken.
- [FEATURE]: A request for new functionality.
- [CHURN RISK]: The user is angry or threatening to leave.
- [NOISE/CONFUSION]: The user just doesn't understand how to use the product.
2. Actioning
- If [BUG]: Ask the founder if this is a P0 (fix now) or P1 (backlog). If P0, immediately shift to the BUILD skill to fix it. If P1, log it in
memory/open-loops.md with a strict owner and due date.
- If [FEATURE]: Add it to
vault/feedback/feature-requests.md (create if missing) and check if other users have requested it. Do NOT immediately build it unless the founder explicitly overrides.
- If [CHURN RISK]: Flag it to the founder immediately. Draft a highly empathetic, non-defensive reply.
3. Drafting the Reply
Using the memory/voice.md file (to ensure it sounds like the founder, not a generic AI):
- Draft a concise, empathetic response to the user.
- If it's a bug, acknowledge the issue and give a realistic timeline.
- If it's a feature, thank them and manage expectations cleanly (e.g., "not on the immediate roadmap but tracking it").
- Present the drafted reply to the founder for copy-pasting. Do not actually send the email yourself.