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.
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
Intelligently organizes your files and folders across your computer by understanding context, finding duplicates, suggesting better structures, and automating cleanup tasks. Reduces cognitive load and keeps your digital workspace tidy without manual effort.
Generates creative domain name ideas for your project and checks availability across multiple TLDs (.com, .io, .dev, .ai, etc.). Saves hours of brainstorming and manual checking.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Implements Manus-style file-based planning for complex tasks. Creates task_plan.md, findings.md, and progress.md. Use when starting complex multi-step tasks, research projects, or any task requiring >5 tool calls.
Creative research ideation and exploration. Use for open-ended brainstorming sessions, exploring interdisciplinary connections, challenging assumptions, or identifying research gaps. Best for early-stage research planning when you do not have specific observations yet. For formulating testable hypotheses from data use hypothesis-generation.
Comprehensive GitHub project management with swarm-coordinated issue tracking, project board automation, and sprint planning
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
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.