forge

Design option synthesis (Phase 5)

Codebase reality description (Phase 2)

Main entry - 0-stage semantic routing for plugin design

Smart routing wizard for plugin development tasks

Workflow management (Phase 6-7-8)

Use this agent to analyze existing plugin code and describe reality. Examples: <example> Context: Need to understand existing plugin structure user: "Analyze this plugin's current state" assistant: "I'll use the codebase-analyzer to describe what the code actually does" <commentary> Describes factual behavior, not claims from comments or docs </commentary> </example> <example> Context: Before modifying existing plugin user: "What does this hook actually do?" assistant: "Let me analyze the codebase to describe the actual behavior" <commentary> Phase 2 describes reality before any modifications </commentary> </example>

Use this agent to execute confirmed designs after user approval. Examples: <example> Context: User confirmed the workflow user: "Yes, proceed with implementation" assistant: "I'll use the execution-orchestrator to implement the confirmed design" <commentary> STRICT phase - requires explicit user confirmation before any execution </commentary> </example> <example> Context: Ready to create plugin files user: "Go ahead and create the files" assistant: "Executing the confirmed design with scaffolding and implementation" <commentary> Creates files, refactors code, applies hooks/daemon/MCP as designed </commentary> </example>

Use this agent when starting a new plugin design task to normalize user intent. Examples: <example> Context: User wants to create a new plugin feature user: "I want to add validation to my plugin" assistant: "I'll use the input-normalizer agent to understand your requirements" <commentary> Triggers because user intent needs normalization before design can proceed </commentary> </example> <example> Context: Ambiguous plugin request user: "Help me with hooks" assistant: "Let me normalize this request to understand what you need" <commentary> Vague requests need Phase 0 normalization to extract clear problem statement </commentary> </example>

Use this agent to compare user intent against codebase reality. Examples: <example> Context: After analyzing existing plugin code user: "Does this match what I want to build?" assistant: "I'll use the mismatch-evaluator to compare intent vs reality" <commentary> Compares Phase 0 intent with Phase 2 observations to find gaps </commentary> </example> <example> Context: User assumes feature exists but it doesn't user: "I thought there was already a validation hook" assistant: "Let me evaluate the mismatch between your expectation and reality" <commentary> Significant mismatches trigger Phase 4 questioning </commentary> </example>

Use this agent to synthesize design options with trade-offs. Examples: <example> Context: Decision variables collected, ready for design user: "What are my options for implementing this?" assistant: "I'll use the option-synthesizer to propose design alternatives" <commentary> Proposes options with structural placement and trade-offs, not answers </commentary> </example> <example> Context: Multiple valid approaches exist user: "Should I use a hook or an agent?" assistant: "Let me synthesize options with pros and cons for each approach" <commentary> Presents options with schema-informed placement and honest trade-offs </commentary> </example>

Use this agent to collect decision variables using Structured Dialogue Contract. Examples: <example> Context: Significant mismatch found in Phase 3 user: "I need to clarify my requirements" assistant: "I'll use the questioner agent to collect decision variables" <commentary> STRICT phase - must follow Structured Dialogue Contract format </commentary> </example> <example> Context: Ambiguous architectural choice user: "Should this be stateful or stateless?" assistant: "Let me ask structured questions to understand your requirements" <commentary> Collects variables (not preferences) using Problem/Codebase/Evidence/Question format </commentary> </example>

Use this agent to route normalized intent and identify decision axes. Examples: <example> Context: After Phase 0 normalization completes user: "Now figure out what kind of component this should be" assistant: "I'll use the semantic-router to identify decision axes" <commentary> Routes intent through static hints (keywords, paths, configs) to identify axes </commentary> </example> <example> Context: Plugin design with multiple possible approaches user: "Should this be a hook or a command?" assistant: "Let me route this through semantic analysis to identify the decision axes" <commentary> Identifies axes like hook vs command, not the final decision </commentary> </example>

Use this agent to validate plugin schema, structure, and invariants. Examples: <example> Context: After execution completes user: "Validate the plugin I just created" assistant: "I'll use the validator agent to check schema and structure" <commentary> Fixed validation phase - always runs at workflow termination </commentary> </example> <example> Context: Plugin not working as expected user: "Why isn't my plugin loading?" assistant: "Let me validate the schema and structure to find issues" <commentary> Checks plugin.json, marketplace.json, frontmatter, hooks.json schemas </commentary> </example>

Use this agent to create implementation workflows when step order matters. Examples: <example> Context: User selected a design option user: "Create a plan for implementing this" assistant: "I'll use the workflow-manager to create an ordered implementation plan" <commentary> Creates workflows only when step order matters, not for simple tasks </commentary> </example> <example> Context: Complex multi-step implementation user: "What's the order of operations for this?" assistant: "Let me create a workflow proposal for you to confirm" <commentary> Workflows are proposals until user confirmation in Phase 7 </commentary> </example>

Phase transition rules and completion criteria for Forge 9-phase workflow

Complete schema reference for Claude Code plugin development - plugin.json, marketplace.json, frontmatter, and hooks.json. This skill should be used when designing plugins, validating schemas, or understanding component structure.

Structured Dialogue Contract format reference for Forge Phase 4 questioning

Smart routing wizard for plugin development tasks. Routes to appropriate Forge agents via explicit Task(subagent_type="forge:*") pattern. This skill should be used when the /forge command is invoked or when routing decisions need to be made for plugin design, analysis, or validation.

6 hooks across 5 events