Task implementation skill for spec-driven workflows. Reads specifications, identifies next actionable tasks, and creates detailed execution plans. Use when ready to implement a task from an existing spec - bridges the gap between planning and coding. TRIGGER when: user explicitly asks to implement, continue work, or pick up the next task from a spec (e.g., "what's next", "continue", "implement"). Never call mcp task/spec tools directly for task workflow operations. DO NOT TRIGGER when: a <command-name> tag is present in the current turn (skill already loaded), called from a subagent, or model decides on its own that implementation should start.
npx claudepluginhub foundry-works/claude-foundryThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/agent-delegation.mdreferences/autonomous-mode.mdreferences/checklist.mdreferences/context-gathering.mdreferences/context-structure.mdreferences/journaling.mdreferences/parallel-mode.mdreferences/progress-tracking.mdreferences/research-workflow.mdreferences/session-management.mdreferences/spec-lifecycle.mdreferences/subagent-patterns.mdreferences/task-lifecycle.mdreferences/troubleshooting.mdreferences/verification.md
[x?]=decision ·(GATE)=user approval ·→=sequence ·↻=loop ·§=section ref
- **Entry** → LoadConfig → `environment action="get-config" sections=["autonomy","git"]` → Merge config
- [unattended?] → Skip user gates
- Task selection → [selection mode?]
- [interactive?] → SelectTask
- [recommend?] → `task action="prepare"` → ShowRecommendation
- [browse?] → `task action="query"` → (GATE: task selection)
- Type dispatch → [type?]
- [verify?] → §VerifyWorkflow
- [task?] → DeepDive
- `task action="prepare"` → ExtractContext
- DraftPlan → (GATE: approve plan)
- [approved] → PreImpl
- [changes] → ↻ back to DraftPlan
- [defer] → **Exit**
- PreImpl → LSP analysis → Explore subagent
- `task action="update-status" status="in_progress"` → **Implement**
- PostImpl → `task action="complete"` → Journal (auto)
- [success?] → SurfaceNext → `task action="prepare"` → ShowNextTask → (GATE: continue?)
- [yes] → ↻ back to SelectTask
- [else] → **Exit**
- [blocked?] → HandleBlocker → `task action="block"` → (GATE: alternatives)
- [add-dep?] → `task action="add-dependency"`
- [add-requirement?] → `task action="add-requirement"`
- [resolve] → ↻ back to **Implement**
- [skip] → SurfaceNext
- [batch execution?] → §BatchExecution (agent decides based on task characteristics)
§VerifyWorkflow → see references/verification.md
§BatchExecution flow:
- **Entry** → `task action="prepare-batch"` → IdentifyEligible
- [conflicts?] → ExcludeConflicting
- `task action="start-batch"` → SpawnSubagents
- For each subagent → Task(general-purpose, run_in_background=true)
- TaskOutput(block=true) → CollectResults
- `task action="complete-batch"` → AggregateResults
- [failures?] → HandlePartialFailure
- [more batches?] → ↻ back to prepare-batch
- [else] → **Exit**
Flow notation: see dev_docs/flow-notation.md
This skill interacts solely with the Foundry MCP server (foundry-mcp). Tools use the router+action pattern: mcp__plugin_foundry_foundry-mcp__<router> with action="<action>".
| Router | Key Actions |
|---|---|
task | prepare, query, info, start, complete, update-status, block, unblock, add-dependency, add-requirement, session, session-step, session-events, fix-verification-types, gate-waiver, prepare-batch, start-batch, complete-batch, reset-batch |
research | node-status, node-execute, node-record, node-findings |
journal | add, list |
lifecycle | activate, move, complete |
spec | find, list |
journal | add, list |
environment | get-config |
Critical Rules:
Execution behavior is driven by the autonomy posture configured in foundry-mcp.toml, not by command flags. The posture determines how the skill interacts with users and makes decisions.
Config Loading: At entry, call the environment tool to read configuration. Returns autonomy (posture, security, session defaults) and git (commit cadence, auto_push) sections. If no autonomy config is present, defaults to supervised posture with strict gates.
| Posture | User Prompts | Task Selection | Plan Approval | Continue Gate |
|---|---|---|---|---|
unattended | Skipped | Auto (recommended) | Auto (use generated plan) | Auto-continue |
supervised (default) | AskUserQuestion | User chooses | User approves | User confirms |
debug | AskUserQuestion | User chooses | User approves | User confirms |
Limits are sourced from autonomy.session_defaults rather than hardcoded values:
| Setting | Effect | Default |
|---|---|---|
max_tasks_per_session | Task count before checkpoint pause | 100 |
max_consecutive_errors | Error threshold before pause | 3 |
stop_on_phase_completion | Pause at phase boundaries | false |
auto_retry_fidelity_gate | Auto-retry failed fidelity reviews | false |
max_fidelity_review_cycles_per_phase | Cap on fidelity retry loops | 3 |
Use your best judgment on whether to delegate tasks to subagents and whether to parallelize. Consider:
The batch MCP actions (prepare-batch, start-batch, complete-batch, reset-batch) are available tools — use them when the task characteristics warrant it.
Batch execution details: references/parallel-mode.md Subagent patterns: references/subagent-patterns.md
When autonomy.posture.profile is "unattended", the skill executes tasks continuously without user prompts.
Key behaviors:
task action="prepare"Session tracking: Uses canonical task action="session" with commands: start, status, pause, resume, end. Step orchestration via task action="session-step" with commands: next, report, replay, heartbeat.
Full documentation: references/autonomous-mode.md Session management: references/session-management.md
At entry, IMMEDIATELY call the environment tool before any other action:
mcp__plugin_foundry_foundry-mcp__environment action="get-config" sections='["autonomy", "git"]'
This returns:
autonomy section: posture profile, security settings (role, lock bypass, gate waiver), session defaults (task limits, error thresholds, fidelity cycles)git section: commit_cadence, auto_pushDefaults when no autonomy config present: posture profile = null (supervised behavior), role = "maintainer", gate_policy = "strict", safe limits (100 tasks, 3 errors, 3 fidelity cycles).
Why mandatory: Without this call, the skill cannot determine the correct posture for user interaction gates and session limits.
The skill only interacts with specs via MCP tools:
mcp__plugin_foundry_foundry-mcp__task action="prepare"mcp__plugin_foundry_foundry-mcp__task action="info"mcp__plugin_foundry_foundry-mcp__spec action="find"mcp__plugin_foundry_foundry-mcp__task action="query"Direct JSON access (Read(), cat, jq, grep, etc.) is prohibited.
Gate key decisions with AskUserQuestion (when posture is supervised or debug):
When posture is unattended: All gates above are skipped. The skill auto-selects recommended tasks, uses generated plans, and auto-continues. See references/autonomous-mode.md.
Anti-Pattern: Never use text-based numbered lists. Always use AskUserQuestion for structured choices (in supervised/debug posture).
This skill must NEVER invoke itself or Skill(foundry-implement). The only valid callers are:
If you find yourself about to call Skill(foundry-implement) from within this skill, STOP and proceed with the workflow instead. The skill handles the complete task lifecycle - there is no need to re-invoke it.
For detailed context gathering patterns, see
references/context-gathering.mdFor agent delegation patterns (when to use foundry-spec), seereferences/agent-delegation.md
Execute one task at a time with explicit user approval.
Assumption: The active spec has been identified (either via skill auto-discovery or passed during invocation).
mcp__plugin_foundry_foundry-mcp__task action="prepare" -> surface task id, file, complexity, blockersmcp__plugin_foundry_foundry-mcp__task action="query" -> present shortlist via AskUserQuestionAfter selecting a task, check its type to determine the workflow path.
Check task type from the task action="prepare" response or via mcp__plugin_foundry_foundry-mcp__task action="info":
| Task Type | Workflow Path |
|---|---|
type: "verify" | Go to Verification Task Workflow |
type: "research" | Go to Research Node Workflow |
type: "task" (default) | Continue to Deep Dive & Plan Approval |
CRITICAL: Verification and research tasks must NOT go through the implementation workflow. They require MCP tool invocation, not code changes.
Note: This section is for type: "task" only. Verification tasks (type: "verify") use the Verification Task Workflow.
Invoke mcp__plugin_foundry_foundry-mcp__task action="prepare" with the target spec_id. The response contains:
task_data: title, metadata, instructionsdependencies: blocking status (can_start, blocked_by list)context: previous sibling, parent task, phase, sibling files, journal, dependenciesTreat context as the authoritative source. Only fall back to mcp__plugin_foundry_foundry-mcp__task action="info" when the spec explicitly requires absent data.
For context field details and JSON structure, see
references/context-structure.md
Draft execution plan:
context.sibling_filescontext.parent_taskcontext.phasecontext.previous_sibling.summary for continuityPresent plan via AskUserQuestion:
Before implementing, use Claude Code's built-in subagents for efficient codebase exploration:
| Scenario | Subagent | Thoroughness |
|---|---|---|
| Find related files/patterns | Explore | medium |
| Understand unfamiliar code areas | Explore | very thorough |
| Complex multi-file investigation | general-purpose | N/A |
Example invocation:
Use the Explore agent (medium thoroughness) to find:
- Existing implementations of similar patterns
- Test files for the target module
- Related documentation that may need updates
Benefits of subagent exploration:
For more subagent patterns including delegation guidance, see
references/subagent-patterns.md
Before implementing, use LSP tools to verify dependencies and preview impact:
goToDefinition on symbols the task modifiesfindReferences to identify all affected files and call sitesBefore implementing, check context.parent_task.children for sibling verify tasks to determine appropriate verification scope:
| Phase Has Verify Task? | Implementation Task Should |
|---|---|
| Yes (e.g., "Run tests") | Defer formal testing to verify task. Only do basic checks: imports work, no syntax errors, code compiles |
| No | Run tests as part of implementation (include results in journal) |
Detection: Look for siblings with type: "verify" in the task action="prepare" response's context.parent_task.children array.
Rationale: When the spec author created a verify task, they intended testing to be a separate tracked step. Respect this structure by deferring formal test execution to the verify task.
Include in plan: State verification scope in the execution plan presented for approval (e.g., "Basic verification only - full tests handled by verify-1-1").
Before coding:
mcp__plugin_foundry_foundry-mcp__task action="update-status" spec_id={spec-id} task_id={task-id} status="in_progress" note="context"
During implementation:
After implementation:
Mark task complete using the atomic complete action (updates status AND journals automatically):
mcp__plugin_foundry_foundry-mcp__task action="complete" spec_id={spec-id} task_id={task-id} completion_note="Summary of what was accomplished, tests run, verification performed"
This atomically:
completedProactively add journal entries when you encounter:
mcp__plugin_foundry_foundry-mcp__journal action="add" spec_id={spec-id} title="[Type] description" content="Details"
Do NOT prompt the user. Silently capture and continue working.
Context Awareness: The context-monitor hook fires when context exceeds 85%. The remaining ~15% is sufficient headroom to finish your current task at full quality. Do not rush, skip steps, or reduce quality in response to this warning. After completing the current task normally, do not start a new task -- instead recommend /clear then foundry-implement.
Surface next recommendation:
mcp__plugin_foundry_foundry-mcp__task action="prepare" spec_id={spec-id}
MANDATORY: Continuation Gate
After surfacing the next task:
AskUserQuestion:
/clear then foundry-implementThis gate ensures supervised users control the workflow pace while unattended execution proceeds autonomously within safety limits.
For post-implementation checklist, see
references/checklist.md
Verification Scoping)in_progressmcp__plugin_foundry_foundry-mcp__task action="block"AskUserQuestionWhen you discover a missing dependency or new requirement during implementation, record it without leaving the task context:
# Discovered that this task needs another task completed first
mcp__plugin_foundry_foundry-mcp__task action="add-dependency" spec_id={spec-id} task_id={task-id} depends_on={dependency-task-id}
# Discovered a new acceptance requirement (e.g., from testing)
mcp__plugin_foundry_foundry-mcp__task action="add-requirement" spec_id={spec-id} task_id={task-id} requirement="Description of discovered requirement"
Use Cases:
mcp__plugin_foundry_foundry-mcp__task action="unblock" spec_id={spec-id} task_id={task-id} resolution="Brief description"
MUST provide journal content describing:
Verification Scoping):
Example (with sibling verify task - deferred testing):
mcp__plugin_foundry_foundry-mcp__task action="complete" spec_id="my-spec-001" task_id="task-1-2" completion_note="Implemented phase-add-bulk handler. Basic verification: imports work, no syntax errors. Full test run deferred to verify-1-1. Created src/tools/authoring.py handler (200 lines)."
Example (without sibling verify task - full testing):
mcp__plugin_foundry_foundry-mcp__task action="complete" spec_id="my-spec-001" task_id="task-2-3" completion_note="Implemented JWT auth middleware with PKCE flow. All 12 unit tests passing. Manual verification: login flow works in dev environment. Created src/middleware/auth.ts (180 lines) and tests/middleware/auth.spec.ts (45 tests)."
Entry: Routed here from Task Type Dispatch when task has type: "verify"
CRITICAL: Read references/verification.md before proceeding. Contains mandatory skill dispatch rules.
Entry: Routed here from Task Type Dispatch when task has type: "research"
Research nodes use AI-powered workflows (chat, consensus, thinkdeep, ideate, deep-research) to investigate questions, gather perspectives, or generate ideas before or during implementation.
Key actions:
research action="node-status"research action="node-execute"research action="node-record"research action="node-findings"Blocking modes:
hard: Research must complete before dependents can startsoft (default): Informational - dependents can proceednone: Research never blocksCRITICAL: Read references/research-workflow.md before proceeding. Contains required command syntax and recording parameters.
For comprehensive documentation including:
Task Execution:
references/context-gathering.mdreferences/agent-delegation.mdreferences/context-structure.mdreferences/subagent-patterns.mdreferences/checklist.mdreferences/verification.mdreferences/research-workflow.mdreferences/note.mdTask Lifecycle:
references/task-lifecycle.mdreferences/progress-tracking.mdreferences/journaling.mdreferences/spec-lifecycle.mdGeneral:
references/troubleshooting.mdActivates when the user asks about AI prompts, needs prompt templates, wants to search for prompts, or mentions prompts.chat. Use for discovering, retrieving, and improving prompts.
Search, retrieve, and install Agent Skills from the prompts.chat registry using MCP tools. Use when the user asks to find skills, browse skill catalogs, install a skill for Claude, or extend Claude's capabilities with reusable AI agent components.
This skill should be used when the user wants to "create a skill", "add a skill to plugin", "write a new skill", "improve skill description", "organize skill content", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.