Triaging Intake Requests Into GitHub

Markdown
---
name: triaging-intake-requests-into-github
description: Converts incoming requests from scattered channels (voice, email, Telegram) into organized, estimated, budgeted, and assigned GitHub issues. Use when a new client/stakeholder request arrives and needs to be checked against existing work, scoped for effort, allocated a budget, and assigned to the right person before work begins.
---

Quick Start

When a request comes in, don't jump straight to creating a GitHub issue. Run it through this funnel first:

1. **Isolate** — split multi-topic requests (e.g. one email with 5 asks) into distinct, atomic tasks.
2. **Check for overlap** — search GitHub (open + in-progress) and Wethod for anything related already planned.
3. **Estimate effort** — rough size (S/M/L or hours) before anything else.
4. **Budget** — if billable, define budget allocation now, not after assignment.
5. **Assign** — match to person/team based on availability + prior knowledge of that project, prioritizing whoever already touched it.
6. **Create the GitHub issue** with all of the above baked in, then let the assignee own status updates and PR.

Progress:
- [ ] Isolate individual tasks from raw request
- [ ] Check GitHub/Wethod for existing/related work
- [ ] Estimate effort
- [ ] Define budget allocation (if invoiceable)
- [ ] Assign based on availability + project familiarity
- [ ] Create GitHub issue with estimate, budget, assignee
- [ ] Set client update checkpoint

Workflow

**1. Capture & Isolate**
Requests arrive via voice, email, or Telegram — unstructured and often bundled. First pass: extract every distinct actionable item. One email thread = potentially N tasks. Don't create the issue yet; just list candidate tasks (even in a scratch note) before touching GitHub.

**2. De-duplicate against current work**
For each isolated task, check:
- GitHub: open issues, in-progress, backlog/todo
- Kaneo: overview of what's running across projects

If it overlaps with something planned, merge/link instead of creating a duplicate — add it as a comment or sub-task on the existing issue.

**3. Scope the effort**
Give a rough effort size before anyone is assigned. This protects the budget step from being a guess, and prevents assigning someone before you know if it's a 1-hour fix or a 2-day feature.

**4. Budget (if billable)**
Only for invoiceable requests. Define the allocation based on the effort estimate. Do this *before* assignment so the assignee inherits a clear budget ceiling, not an open-ended ask.

**5. Assign**
Priority order:
1. Someone with direct prior experience on that specific project/codebase
2. Someone available within the needed timeframe
3. Fallback: whoever has the closest adjacent knowledge

**6. Create the GitHub issue**
Issue should contain, at minimum:
- Original request context (source channel + raw ask, summarized)
- Effort estimate
- Budget allocation (if applicable)
- Assignee
- Link to any related/parent issue

**7. Hand off ownership**
Once assigned, the developer owns:
- Updating task status
- Opening the PR when done

PM owns:
- Reviewing/merging the PR (or ensuring it's reviewed)
- Keeping the client updated in parallel — don't wait for task completion to communicate progress

Examples

**Example 1:**
Input: A client emails with "can you update the homepage banner, fix the broken contact form, and also add a newsletter signup to the footer" — three asks in one email.
Output: Three separate GitHub issues created:
- "Update homepage banner" — S effort, no budget needed (maintenance retainer), assigned to dev who built the homepage
- "Fix broken contact form" — S effort, flagged as bug/priority, assigned to whoever is available first
- "Add newsletter signup to footer" — M effort, budget allocated (new feature), assigned to dev with footer/forms experience
Each issue references the original email as context. Client gets one reply confirming all three are logged, with rough timelines.

**Example 2:**
Input: Telegram message: "hey can you also add dark mode to the dashboard" arrives while a related "redesign dashboard UI" issue is already in progress.
Output: No new standalone issue. Comment added to the existing "redesign dashboard UI" issue noting the dark mode ask, effort re-estimated to include it, budget adjusted if billable, same assignee (already has context) notified of scope change.

Best Practices

- **Never skip the duplicate check.** Fragmentation across Wethod/Kaneo/GitHub means the same request can quietly get built twice if you don't look first.
- **Estimate before you assign.** Assigning first biases the estimate (people anchor to who's "free" rather than what's actually needed).
- **Budget before assignment, not after.** Otherwise the assignee has no ceiling to work against.
- **Prioritize continuity.** Assigning to someone who already knows the project beats assigning to whoever is simply free — saves ramp-up time and reduces errors.
- **Decouple client updates from task completion.** Communicate proactively while work is in progress, don't let silence be the default.
- **Push status ownership down.** Developers update their own task status and open their own PRs — the PM reviews/merges, doesn't chase.
- **Keep one source of truth for "what's in flight."** Even with multiple tools, GitHub should be the canonical task list; Wethod/Kaneo are for planning/overview layered on top.

Common Pitfalls

- Creating a GitHub issue straight from a raw, multi-ask email instead of isolating tasks first — leads to messy, unscoped issues.
- Skipping the "check existing work" step and duplicating effort already planned or in progress.
- Assigning based purely on availability and ignoring prior project knowledge — causes rework and slower delivery.
- Defining budget after assignment, leading to scope creep with no ceiling.
- Letting client communication lag behind actual task status — clients should never have to ask "any update?"
- Treating every tool as equally authoritative — without a clear "GitHub is the task source of truth" rule, status drifts across systems.