Setup development environment from GitHub issue. Invoke when user says "init work on issue
/plugin marketplace add fusupo/muleteer/plugin install muleteer@fusupo-muleteerThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Transform a GitHub issue into a fully-prepared development environment with:
Before beginning, load critical project context:
Read the project's CLAUDE.md to understand:
Get a high-level view of the repository structure to identify affected areas.
Before proceeding with setup, check if work already initialized:
Detect existing scratchpad:
# Look for SCRATCHPAD_{issue_number}.md
ls SCRATCHPAD_*.md 2>/dev/null
If scratchpad exists:
✓ Scratchpad already exists for this issue.
Delegating to work-session skill...
Then invoke:
Skill: work-session
args: "{issue_number}"
STOP here - don't proceed with setup.
If no scratchpad:
Input: Issue reference in format owner/repo#number or just #number (uses current repo)
Examples:
owner/repository#42#42 (assumes current repository)Execute these operations in parallel for faster setup:
Repository Context:
CLAUDE.md for conventionsIssue Details:
Generate branch name (after issue fetched):
{issue-number}-{slugified-title}42-implement-fact-batchingBuild issue context map:
Goal: Understand the issue deeply before writing any code.
Analysis Steps:
Requirements Review:
Codebase Investigation (Delegate to Explore Agent):
For thorough codebase analysis, use the Task tool with subagent_type=Explore:
Task:
subagent_type: Explore
prompt: "Analyze the codebase to understand how to implement {issue summary}.
Find: affected modules, similar implementations, integration points,
and relevant patterns. Focus on: {specific areas from issue}"
description: "Explore codebase for issue #{number}"
The Explore agent will:
When to delegate vs. do directly:
Technical Breakdown:
Dependency Check:
Generate: SCRATCHPAD_{issue_number}.md
Template Structure:
# {Issue Title} - #{issue_number}
## Issue Details
- **Repository:** {owner/repo}
- **GitHub URL:** {issue_url}
- **State:** {open/closed}
- **Labels:** {labels}
- **Milestone:** {milestone if exists}
- **Assignees:** {assignees}
- **Related Issues:** {linked issues if any}
- Depends on: #{issue_numbers}
- Blocks: #{issue_numbers}
- Related: #{issue_numbers}
## Description
{full issue body from GitHub}
## Acceptance Criteria
{extract task list from issue body, or create from description}
- [ ] {criterion 1}
- [ ] {criterion 2}
- [ ] {criterion 3}
## Branch Strategy
- **Base branch:** main (or develop-ts/develop if exists)
- **Feature branch:** {issue_number}-{slugified-title}
- **Current branch:** {git branch --show-current}
## Implementation Checklist
### Setup
- [ ] Fetch latest from base branch
- [ ] Create and checkout feature branch
### Implementation Tasks
{Break down into atomic commits - each should be independently reviewable}
- [ ] {First atomic task with clear scope}
- Files affected: {list}
- Why: {brief rationale}
- [ ] {Second atomic task}
- Files affected: {list}
- Why: {brief rationale}
{Continue with granular breakdown...}
### Quality Checks
- [ ] Run linter/type checker
- [ ] Execute relevant tests
- [ ] Self-review for code quality
- [ ] Verify acceptance criteria met
### Documentation
- [ ] Update relevant README/docs (if applicable)
- [ ] Add inline comments for complex logic (if applicable)
## Technical Notes
### Architecture Considerations
{Any architectural decisions to consider}
{Module boundaries to respect}
{Integration points to handle}
### Implementation Approach
{High-level strategy for solving the problem}
{Why this approach vs alternatives}
### Potential Challenges
{Known complexity areas}
{Technical debt to navigate}
{Performance considerations}
## Questions/Blockers
### Clarifications Needed
{List any unclear requirements}
{Ambiguities in issue description}
### Blocked By
{List any dependencies not yet complete - reference issue numbers}
### Assumptions Made
{Document assumptions if requirements unclear}
### Decisions Made
{Populated during Phase 3.5 Interactive Q&A}
{Format: Q: question → A: decision (rationale)}
## Work Log
{This section fills in during execution via /start-work}
{Each work session adds dated entries}
---
**Generated:** {timestamp}
**By:** Issue Setup Skill
**Source:** {github_issue_url}
Scratchpad Quality Guidelines:
Goal: Resolve any questions or ambiguities before starting implementation.
Trigger: If the scratchpad has items in the "Clarifications Needed" section.
Process:
Check for Outstanding Questions:
Present Questions via AskUserQuestion:
For each clarification needed, use the AskUserQuestion tool to get user input:
AskUserQuestion:
question: "{The specific clarification question}"
header: "Clarify"
options:
- label: "{Option A}"
description: "{What this choice means}"
- label: "{Option B}"
description: "{What this choice means}"
- label: "{Option C}" (if applicable)
description: "{What this choice means}"
multiSelect: false (or true if multiple answers valid)
Guidelines for presenting questions:
Update Scratchpad with Decisions: After collecting all answers, update the scratchpad:
a) Add "Decisions Made" section (if not present) under Questions/Blockers:
### Decisions Made
{Timestamp}
**Q: {Original question}**
**A:** {User's answer/decision}
**Rationale:** {Brief explanation of why, if provided}
b) Remove resolved items from "Clarifications Needed"
c) Update relevant sections if decisions affect:
Confirm Resolution: Display summary of decisions made:
✓ Resolved {N} clarifications:
1. {Question summary} → {Decision}
2. {Question summary} → {Decision}
...
📋 SCRATCHPAD updated with decisions.
Example Interaction:
📋 SCRATCHPAD_42.md has 3 clarifications that need resolution before proceeding.
[AskUserQuestion 1/3]
Question: "Should we keep commands as aliases during the transition to skills?"
Header: "Migration"
Options:
- "Keep as thin wrappers" - Commands remain but delegate to skills
- "Remove immediately" - Clean break, skills only
- "Decide per-command" - Evaluate each command individually
[User selects: "Keep as thin wrappers"]
[AskUserQuestion 2/3]
Question: "How should prime-session be handled?"
Header: "Behavior"
Options:
- "Convert to auto-invoke skill" - Activates when entering new repo
- "Keep as explicit command" - User must invoke manually
- "Remove entirely" - Claude reads CLAUDE.md automatically anyway
[User selects: "Keep as explicit command"]
...
✓ Resolved 3 clarifications:
1. Migration strategy → Keep commands as thin wrappers
2. prime-session behavior → Keep as explicit command
3. ...
📋 SCRATCHPAD_42.md updated with decisions.
Proceeding to branch creation...
Skip Conditions:
Branch Creation:
Detect base branch:
# Check what branches exist
git fetch origin
# Prefer in this order:
# 1. develop-ts (if exists)
# 2. develop (if exists)
# 3. main (default)
git branch -r | grep -E 'origin/(develop-ts|develop|main)'
Create feature branch:
# Generate branch name from issue
# Format: {issue_number}-{slugified-title}
# Example: 42-implement-fact-batching
git branch {issue-number}-{slugified-title} origin/{base-branch}
# Don't checkout yet - let operator decide when to switch
Confirm creation:
git branch --list {branch-name}
Final Output:
Display concise summary:
✓ Issue #{issue_number} analyzed and prepared
📋 SCRATCHPAD_{issue_number}.md created with:
- {X} implementation tasks
- {Y} quality checks
- {Z} decisions made (via Q&A)
🌿 Branch '{issue-number}-{slugified-title}' created from {base-branch}
🔗 GitHub Issue: {issue_url}
🚀 Ready to begin work:
git checkout {branch-name}
# Then start implementation
Note: If clarifications were resolved in Phase 3.5, the scratchpad now contains confirmed decisions rather than open questions. All ambiguities should be resolved before reaching this point.
Component Context:
Contract Context:
If GitHub issue doesn't exist:
If issue lacks description or clear scope:
If feature branch already exists:
If can't access repository:
Flows to:
/start-work {issue_number} - Begin execution from scratchpad/commit - Make atomic commits as checklist progressesReceives context from:
/prime-session - Current development prioritiesBefore Scratchpad Creation: If issue is complex or ambiguous, ask:
After Scratchpad Created: Present for review:
Before Branch Creation: Confirm readiness:
A successful issue setup produces:
✓ Complete context: All issue details captured ✓ Clear plan: Implementation steps are atomic and logical ✓ Identified risks: Challenges flagged upfront ✓ Ready workspace: Branch created, scratchpad prepared ✓ Operator confidence: Developer knows exactly what to build
The scratchpad should be so clear that another developer could pick it up and execute it.
If the issue analysis reveals a complex implementation, suggest entering plan mode:
Triggers for EnterPlanMode:
Suggestion:
This issue appears complex ({reason}). Would you like me to enter
plan mode to design the implementation approach before we proceed?
Version: 1.1.0 Last Updated: 2025-12-31 Maintained By: Muleteer Changelog:
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.