nicepkg/work-intake
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.
npx skills add https://github.com/nicepkg/ai-workflow --skill work-intake
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."
┌─────────────────────────────────────────────────────────────────────┐
│ 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
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:
Skill: project-board-enforcement
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/pagesOnly ask the user for information that is still missing after reviewing the repo.
| 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 |
| 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 |
Evaluate the request against these criteria:
| 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+ |
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
**Assessment:** This is a trivial request (single deliverable, no unknowns).
**Next step:** Creating a single issue using `issue-prerequisite`.
Route to: issue-prerequisite
**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
**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)
**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
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]"
]
}])
Request: "Make the login page button a little lighter."
Intake:
→ Route to issue-prerequisite
Request: "Add dark mode to the application."
Intake:
→ Route to epic-management
Request: "Add the ability for users to log in by clicking on a popup in their phone."
Intake:
→ Route to initiative-architecture
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) |
No matter how massive the request:
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)
Skill: project-board-enforcement
Gate: Cannot proceed to any downstream skill without project board readiness verified.
Take nicepkg/work-intake from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.