work-intake

name	work-intake
description	Entry point for ALL work requests - triages scope from trivial to massive, asks clarifying questions, and routes to appropriate planning skills. Use this when receiving any new work request.

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  ] && [  !=  ]; 
     GH_PROJECT_OWNER=
     
  


 [ -z  ]; 
  REMOTE_URL=$(git remote get-url origin 2>/dev/null || )
  OWNER_CANDIDATE=$(  | sed -E )
   [ -n  ] && [  !=  ]; 
     GH_PROJECT_OWNER=
     
  



 [ -z  ]; 
   
   
   1


 [ -z  ]; 
   
   
   1



 ! gh project view  --owner  --format json > /dev/null 2>&1; 
   
   
   1



FIELDS=$(gh project field-list  --owner  --format json | jq -r )

 required   ; 
   !   | grep -q ; 
     
     
  

 !   | grep -q  && !   | grep -q ; 
   
   


 

If gate fails:

1. Configure missing environment variables
2. Create project board if needed
3. Add required fields (Status, Type, Priority)
4. 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:

1. Acknowledge the goal - "I understand you want X"
2. Explain the process - "This will require structured planning"
3. Begin investigation - Start with what we don't know
4. Document everything - Every decision, every finding
5. 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.