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.
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.
/plugin marketplace add troykelly/claude-skills/plugin install issue-driven-development@troykelly-skillsThis skill is limited to using the following tools:
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.
# 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" "Type" "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
echo "Project board ready: $GITHUB_PROJECT_NUM"
If gate fails:
Skill: project-board-enforcement
Before scoping, understand the request:
| 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.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.