Work Intake
Overview
Every work request flows through intake. This skill determines scope, gathers requirements, and routes to the appropriate workflow.
Core principle: No work is too small to track, no work is too large to decompose.
Announce at start: "I'm using work-intake to understand and scope this request before beginning."
The Intake Flow
┌─────────────────────────────────────────────────────────────────────┐
│ REQUEST RECEIVED │
└─────────────────────────────┬───────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────┐
│ STEP 0: PROJECT BOARD READINESS (GATE) │
│ Is GITHUB_PROJECT_NUM set? │
│ Is project board accessible? │
│ Are required fields configured? │
└─────────────────────────────┬───────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────┐
│ CLARIFYING QUESTIONS │
│ What is the user trying to achieve? │
│ What does success look like? │
│ What constraints exist? │
└─────────────────────────────┬───────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────┐
│ SCOPE ASSESSMENT │
│ How much investigation is needed? │
│ How many deliverables? │
│ How many unknowns? │
└─────────────────────────────┬───────────────────────────────────────┘
│
┌───────────────┼───────────────┬───────────────┐
▼ ▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│TRIVIAL │ │ SMALL │ │ LARGE │ │ MASSIVE │
│ │ │ │ │ │ │ │
│1 issue │ │1-3 issues│ │1 epic │ │Initiative│
│no unkn.│ │few unkn. │ │research │ │multi-epic│
└───┬────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │ │
▼ ▼ ▼ ▼
issue-prerequisite issue-prerequisite epic-management initiative-
+ project-board- + decomposition + research spikes architecture
enforcement + project-board- + project-board- + project-board-
enforcement enforcement enforcement
Step 0: Project Board Readiness (GATE)
Before any work intake, verify project board infrastructure is ready.
This is a gate. Do not proceed to clarifying questions until this passes.
# Derive defaults from GITHUB_PROJECT if provided
if [ -z "$GITHUB_PROJECT_NUM" ] && [ -n "$GITHUB_PROJECT" ]; then
NUM_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#.*/projects/([0-9]+).*#\1#')
if [ -n "$NUM_CANDIDATE" ] && [ "$NUM_CANDIDATE" != "$GITHUB_PROJECT" ]; then
export GITHUB_PROJECT_NUM="$NUM_CANDIDATE"
echo "Derived GITHUB_PROJECT_NUM=$GITHUB_PROJECT_NUM from GITHUB_PROJECT"
fi
fi
if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_OWNER" ]; then
export GH_PROJECT_OWNER="$GITHUB_OWNER"
echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_OWNER"
fi
if [ -z "$GH_PROJECT_OWNER" ] && [ -n "$GITHUB_PROJECT" ]; then
OWNER_CANDIDATE=$(echo "$GITHUB_PROJECT" | sed -E 's#https://github.com/(orgs|users)/([^/]+)/projects/[0-9]+#\2#')
if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$GITHUB_PROJECT" ]; then
export GH_PROJECT_OWNER="$OWNER_CANDIDATE"
echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from GITHUB_PROJECT"
fi
fi
if [ -z "$GH_PROJECT_OWNER" ]; then
REMOTE_URL=$(git remote get-url origin 2>/dev/null || true)
OWNER_CANDIDATE=$(echo "$REMOTE_URL" | sed -E 's#(git@|https://)github.com[:/]+([^/]+)/[^/]+(\.git)?#\2#')
if [ -n "$OWNER_CANDIDATE" ] && [ "$OWNER_CANDIDATE" != "$REMOTE_URL" ]; then
export GH_PROJECT_OWNER="$OWNER_CANDIDATE"
echo "Derived GH_PROJECT_OWNER=$GH_PROJECT_OWNER from git remote"
fi
fi
# Verify environment variables are set
if [ -z "$GITHUB_PROJECT_NUM" ]; then
echo "BLOCKED: GITHUB_PROJECT_NUM not set"
echo "Set with: export GITHUB_PROJECT_NUM=<number>"
exit 1
fi
if [ -z "$GH_PROJECT_OWNER" ]; then
echo "BLOCKED: GH_PROJECT_OWNER not set"
echo "Set with: export GH_PROJECT_OWNER=@me # or org name"
exit 1
fi
# Verify project is accessible
if ! gh project view "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json > /dev/null 2>&1; then
echo "BLOCKED: Cannot access project $GITHUB_PROJECT_NUM"
echo "Verify project exists and you have access"
exit 1
fi
# Verify required fields exist
FIELDS=$(gh project field-list "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json | jq -r '.fields[].name')
for required in "Status" "Priority"; do
if ! echo "$FIELDS" | grep -q "^$required$"; then
echo "WARNING: Required field '$required' not found in project"
echo "Consider adding this field for full tracking support"
fi
done
if ! echo "$FIELDS" | grep -q "^Type$" && ! echo "$FIELDS" | grep -q "^Issue Type$"; then
echo "WARNING: Required field 'Type' (or 'Issue Type') not found in project"
echo "Consider adding this field for full tracking support"
fi
echo "Project board ready: $GITHUB_PROJECT_NUM"
If gate fails:
- Configure missing environment variables
- Create project board if needed
- Add required fields (Status, Type, Priority)
- Re-run readiness check
Skill: project-board-enforcement
Step 1: Clarifying Questions
Before scoping, understand the request.
Do not ask questions that can be answered from the repo. First inspect:
README.md,FEATURES.md,BRANDING.md,docs/, Storybook, and existing routes/pages- Existing GitHub issues and project board items
Only ask the user for information that is still missing after reviewing the repo.
Essential Questions
| Question | Purpose | |----------|---------| | "What are you trying to achieve?" | Understand the goal, not just the task | | "What does success look like?" | Define acceptance criteria | | "Who/what is affected?" | Identify scope of impact | | "Are there constraints I should know about?" | Time, tech, compatibility | | "Is this part of something larger?" | Link to existing initiatives |
Discovery Questions (for unclear requests)
| Question | Reveals | |----------|---------| | "Can you walk me through how this would be used?" | User journey, edge cases | | "What exists today?" | Starting point, migration needs | | "What have you already tried?" | Failed approaches, constraints | | "Is there prior art or examples?" | Design direction |
Step 2: Scope Assessment
Evaluate the request against these criteria:
Scope Matrix
| Factor | Trivial | Small | Large | Massive | |--------|---------|-------|-------|---------| | Unknowns | None | Few, answerable | Many, need research | Extensive, need spikes | | Deliverables | 1 thing | 2-5 things | 6-20 things | 20+ things | | Code areas | 1-2 files | 3-10 files | 10+ files | Multiple systems | | Dependencies | None | Internal only | External services | New infrastructure | | Duration | < 1 session | 1-3 sessions | 1-2 weeks | Weeks to months | | Criteria | 1-2 | 3-5 | 6-15 | 15+ |
Scope Decision
IF unknowns == none AND deliverables <= 2:
→ TRIVIAL: Use issue-prerequisite directly
IF unknowns == few AND deliverables <= 5:
→ SMALL: Use issue-prerequisite, maybe issue-decomposition
IF unknowns == many OR deliverables > 5:
→ LARGE: Use epic-management with research spikes
IF unknowns == extensive OR deliverables > 20 OR new_infrastructure:
→ MASSIVE: Use initiative-architecture
Step 3: Route to Appropriate Workflow
Trivial Scope
**Assessment:** This is a trivial request (single deliverable, no unknowns).
**Next step:** Creating a single issue using `issue-prerequisite`.
Route to: issue-prerequisite
Small Scope
**Assessment:** This is a small request (few deliverables, minimal unknowns).
**Plan:**
1. Create parent issue for the request
2. If needed, decompose into 2-3 sub-issues
3. Begin implementation
**Next step:** Creating issue structure using `issue-prerequisite`.
Route to: issue-prerequisite → maybe issue-decomposition
Large Scope
**Assessment:** This is a large request requiring structured planning.
**Unknowns identified:**
- [ ] Unknown 1 - needs investigation
- [ ] Unknown 2 - needs research spike
**High-level deliverables:**
1. Deliverable A
2. Deliverable B
...
**Next step:** Creating epic structure using `epic-management`.
Route to: epic-management (which will create research spikes as needed)
Massive Scope
**Assessment:** This is a massive request requiring full initiative architecture.
**Why massive:**
- [Reason: extensive unknowns / new infrastructure / multi-system / etc.]
**Initial unknowns:**
- [ ] Does X exist?
- [ ] How does Y work?
- [ ] What are constraints of Z?
**Potential scope:**
- Multiple epics likely
- New capabilities needed
- Significant research required
**Next step:** Beginning initiative architecture using `initiative-architecture`.
Route to: initiative-architecture
Resumability Checkpoint
Before routing, document the intake in memory:
# Store intake assessment
mcp__memory__create_entities([{
"name": "Intake-[DATE]-[SHORT_DESC]",
"entityType": "WorkIntake",
"observations": [
"Request: [Original request]",
"Scope: [Trivial/Small/Large/Massive]",
"Unknowns: [List]",
"Route: [Target skill]",
"Status: [Routing/In Progress/Complete]"
]
}])
Examples
Example: Trivial
Request: "Make the login page button a little lighter."
Intake:
- Goal: Adjust button color
- Success: Button is lighter
- Unknowns: None (CSS change)
- Deliverables: 1 (color change)
- Scope: TRIVIAL
→ Route to issue-prerequisite
Example: Large
Request: "Add dark mode to the application."
Intake:
- Goal: Theme switching capability
- Success: Users can toggle dark/light mode
- Unknowns:
- Current theming approach?
- Component library support?
- Persistence mechanism?
- Deliverables: ~10 (theme tokens, components, toggle, persistence, etc.)
- Scope: LARGE
→ Route to epic-management
Example: Massive
Request: "Add the ability for users to log in by clicking on a popup in their phone."
Intake:
- Goal: Mobile push notification login
- Success: User receives push, taps, logged in
- Unknowns:
- Is there a mobile app? → Research spike
- Push notification infrastructure? → Research spike
- Authentication flow design? → Research spike
- Security requirements? → Research spike
- Deliverables: 30+ (app work, backend, auth, notifications, etc.)
- Scope: MASSIVE
→ Route to initiative-architecture
Red Flags That Indicate Larger Scope
Watch for these phrases that suggest the request is larger than it appears:
| Phrase | Likely Scope | |--------|--------------| | "Just add..." + new capability | Large (new capability = infrastructure) | | "Users should be able to..." | Large (user-facing = full stack) | | "Integrate with..." | Large (external = API, auth, error handling) | | "Like [other product]..." | Massive (feature parity = extensive) | | "Mobile/app/notification" | Massive (unless app exists) | | "Real-time/sync/live" | Large (infrastructure) |
Never Turn Away Work
No matter how massive the request:
- Acknowledge the goal - "I understand you want X"
- Explain the process - "This will require structured planning"
- Begin investigation - Start with what we don't know
- Document everything - Every decision, every finding
- Break it down - Until we have tractable pieces
The path from "massive request" to "implementation" is:
Massive Request
→ Initiative Architecture (document unknowns, create research spikes)
→ Research Spikes (answer unknowns)
→ Epic Structure (group deliverables)
→ Issue Decomposition (create tractable tasks)
→ Implementation (one issue at a time)
Checklist
- [ ] Project board readiness verified (Step 0 gate passed)
- [ ] GITHUB_PROJECT_NUM and GH_PROJECT_OWNER set
- [ ] Asked clarifying questions
- [ ] Understood the goal (not just the task)
- [ ] Identified unknowns
- [ ] Counted deliverables
- [ ] Assessed scope (Trivial/Small/Large/Massive)
- [ ] Documented intake in memory
- [ ] Routed to appropriate skill (with project-board-enforcement)
Skill: project-board-enforcement
Gate: Cannot proceed to any downstream skill without project board readiness verified.