pm-architect-greenfield

Run business viability assessment including market analysis and Go/No-Go recommendation

Break architecture into epics, tasks, and dependency graph

Decompose a problem brief into structured requirements and user stories

Design system architecture from functional specification and requirements

Run the full greenfield specification pipeline from idea to implementation plan

Create phased implementation plan with sprints, critical path, and risk mitigation

Frame a problem from a raw idea into a structured problem brief

Write a functional specification from requirements

Use this agent when the user asks to "assess the viability", "run a viability analysis", "evaluate market fit", "analyze the business case", "is this project worth building", "do a competitive analysis", "estimate costs and revenue", or needs a VIABILITY_ANALYSIS.md with market analysis, competitive landscape, cost projections, revenue model, and Go/No-Go recommendation. <example> User: Assess the viability of this project for a B2B SaaS invoicing platform Use: Yes — business viability assessment request <commentary>The user wants a complete viability analysis including market sizing, competitive landscape, cost projections, revenue model, and a Go/No-Go recommendation. This is the business-analyst's core deliverable.</commentary> </example> <example> User: Is this project worth building? Give me the business case. Use: Yes — business case evaluation request <commentary>Evaluating whether a project is worth building requires market analysis, cost estimation, and strategic assessment -- all owned by the business-analyst agent.</commentary> </example> <example> User: Design the system components and infrastructure Use: No — architecture design request, route to system-architect <commentary>System component design and infrastructure planning are the system-architect's domain. The business-analyst evaluates business viability, not technical architecture.</commentary> </example> <example> User: Break this into implementation tasks with effort estimates Use: No — task breakdown request, route to task-planner <commentary>Task decomposition and effort estimation are technical planning activities owned by the task-planner. The business-analyst focuses on market, financial, and strategic viability.</commentary> </example>

Use this agent when the user asks to "run the full greenfield pipeline", "create a spec from my idea", "take my idea to implementation plan", "run the complete project setup", "orchestrate a greenfield project", or needs the entire PM pipeline executed end-to-end from idea to handoff bundle. <example> User: Run the full greenfield pipeline for my SaaS invoicing app idea Use: Yes — full pipeline orchestration request <commentary>This requires the lead orchestrator because the user wants the complete pipeline: requirements decomposition, spec writing, architecture design, task breakdown, implementation planning, and business viability — all coordinated into a handoff bundle.</commentary> </example> <example> User: Create a spec from my idea for a mobile fitness tracker Use: Yes — multi-step pipeline starting from idea intake <commentary>Even though the user said "spec", the intent is to go from raw idea through the full pipeline. The lead parses the idea, delegates to requirements-analyst first, then chains through spec-writer and downstream agents.</commentary> </example> <example> User: Just decompose requirements from this problem brief Use: No — single-skill request, route to requirements-analyst <commentary>The user only wants requirements decomposition, not the full pipeline. Route directly to requirements-analyst to avoid unnecessary orchestration overhead.</commentary> </example> <example> User: Assess the viability of this project Use: No — single-skill request, route to business-analyst <commentary>Viability analysis is a standalone concern owned by the business-analyst agent. The lead only coordinates when multiple pipeline stages are needed.</commentary> </example>

Use this agent when the user asks to "decompose requirements", "create requirements from this problem brief", "extract requirements", "break down this idea into stories", "generate user stories", or needs a structured REQUIREMENTS.md with REQ-NNNN requirements and US-NNNN user stories. <example> User: Decompose requirements from this problem brief for my e-commerce platform Use: Yes — requirements decomposition request <commentary>This is a direct match for the requirements-analyst. The user has a problem brief and wants it decomposed into structured requirements and user stories with proper identifiers.</commentary> </example> <example> User: Create requirements for my project idea about a pet adoption marketplace Use: Yes — requirements extraction from raw idea <commentary>Even without a formal problem brief, the requirements-analyst can extract functional areas and decompose them into REQ-NNNN and US-NNNN items from a raw idea description.</commentary> </example> <example> User: Design the system architecture for these requirements Use: No — architecture design request, route to system-architect <commentary>Architecture design is owned by the system-architect agent. The requirements-analyst only decomposes problems into requirements and stories, never designs technical solutions.</commentary> </example> <example> User: Write a functional spec from these requirements Use: No — specification writing request, route to spec-writer <commentary>Turning requirements into a formal functional specification is the spec-writer's domain. The requirements-analyst produces the raw requirements that feed into the spec.</commentary> </example>

Use this agent when the user asks to "write a functional spec", "create a specification document", "turn requirements into a spec", "draft the functional specification", "write the spec from these requirements", or needs a structured FUNCTIONAL_SPEC.md that details system behavior, screen flows, data models, and API contracts. <example> User: Write a functional spec from these requirements for my invoicing platform Use: Yes — specification writing request <commentary>The user has requirements ready and needs them transformed into a detailed functional specification with screen flows, data models, and behavioral contracts. This is the spec-writer's core responsibility.</commentary> </example> <example> User: Create a detailed spec document that covers all the user flows Use: Yes — functional specification generation <commentary>Requesting a spec document with user flows is a direct match. The spec-writer reads upstream REQUIREMENTS.md and produces FUNCTIONAL_SPEC.md with exhaustive behavioral detail.</commentary> </example> <example> User: Gather the requirements first before writing anything Use: No — requirements gathering request, route to requirements-analyst <commentary>The spec-writer requires REQUIREMENTS.md as input. Gathering or decomposing requirements is the requirements-analyst's responsibility. The spec-writer only transforms existing requirements into specifications.</commentary> </example> <example> User: Design the system architecture with component diagrams Use: No — architecture design request, route to system-architect <commentary>Component diagrams and architectural decisions belong to the system-architect. The spec-writer defines what the system does behaviorally, not how it is structured technically.</commentary> </example>

Use this agent when the user asks to "design the architecture", "create a system architecture", "design the technical architecture", "create component diagrams", "plan the tech stack", "design data flows", or needs an ARCHITECTURE.md with component diagrams, technology decisions, data flow diagrams, and infrastructure design. <example> User: Design the architecture for this spec of my real-time chat application Use: Yes — architecture design request <commentary>The user has a functional spec and needs a technical architecture designed. This involves component decomposition, tech stack selection, data flow design, and Mermaid diagrams -- all core system-architect responsibilities.</commentary> </example> <example> User: Create component diagrams and plan the tech stack for my project Use: Yes — architecture artifacts request <commentary>Component diagrams and tech stack planning are direct outputs of the architecture skill. The system-architect reads the functional spec and translates behavioral requirements into structural design.</commentary> </example> <example> User: Break this into tasks and estimate the work Use: No — task breakdown request, route to task-planner <commentary>Breaking architecture into implementable tasks is the task-planner's job. The system-architect designs the what and how of the system structure, not the work breakdown.</commentary> </example> <example> User: Write the functional specification for this feature Use: No — specification writing request, route to spec-writer <commentary>Functional specifications define behavioral contracts. The system-architect consumes specs as input but does not produce them. Route to spec-writer.</commentary> </example>

Use this agent when the user asks to "break the architecture into tasks", "create an implementation plan", "decompose work items", "plan the implementation phases", "create a task breakdown", "estimate the work", or needs TASKS.md with TASK-NNNN items and IMPLEMENTATION_PLAN.md with phased delivery and RISK-NNNN risk items. <example> User: Break the architecture into tasks and plan implementation for my chat app Use: Yes — task breakdown and implementation planning request <commentary>The user wants both task decomposition and an implementation plan. The task-planner reads the architecture, creates TASK-NNNN items, groups them into phases, identifies RISK-NNNN items, and produces both TASKS.md and IMPLEMENTATION_PLAN.md.</commentary> </example> <example> User: Create a phased implementation plan with risk assessment Use: Yes — implementation planning with risk identification <commentary>Phased planning and risk assessment are core task-planner outputs. The agent reads upstream architecture and requirements to produce a realistic, risk-aware delivery plan.</commentary> </example> <example> User: Assess the market viability of this project Use: No — business viability request, route to business-analyst <commentary>Market viability, competitive analysis, and Go/No-Go decisions are the business-analyst's domain. The task-planner focuses on technical work breakdown and delivery planning, not business assessment.</commentary> </example> <example> User: Design the system components and tech stack Use: No — architecture design request, route to system-architect <commentary>Component design and technology selection are the system-architect's responsibility. The task-planner consumes architecture as input but does not create it.</commentary> </example>

This skill should be used when the user asks to "design the architecture", "create a system design", "define components", "design system interfaces", "create a component diagram", "plan the technology stack", "design data flow", or needs to transform a functional specification and requirements into a language-agnostic architecture document with component diagrams, data flow sequences, interfaces, and scalability considerations.

This skill should be used when the user asks to "assess viability", "analyze the business case", "estimate project costs", "model revenue", "evaluate market opportunity", "do a competitive analysis", "create a go/no-go recommendation", or needs to transform a problem brief and requirements into a business viability analysis with market sizing, competitive landscape, cost estimates, revenue models, and a go/no-go recommendation. This is an optional pipeline step that can be skipped with the --skip-viability flag.

This skill should be used when the user asks to "create an implementation plan", "plan sprints", "define project phases", "identify the critical path", "assess project risks", "create a rollout plan", "define milestones", or needs to transform a task breakdown and architecture into a phased implementation plan with sprint assignments, critical path analysis, risk mitigation strategies, and definition of done.

This skill should be used when the user asks to "frame a problem", "define a project idea", "create a problem brief", "scope a new project", "analyze a project concept", or needs to convert a raw idea into a structured problem statement with target users, success metrics, constraints, and non-goals.

This skill should be used when the user asks to "decompose requirements", "break down a problem into requirements", "create user stories", "define functional requirements", "define non-functional requirements", "write requirements from a problem brief", or needs to transform a structured problem brief into categorized, prioritized requirements with user stories and NFRs.

This skill should be used when the user asks to "write a spec", "create a functional specification", "define feature specs", "document user flows", "define business rules", "design data models", "define API contracts", or needs to transform requirements into detailed feature specifications with user flows, business rules, edge cases, data models, and API contracts.

This skill should be used when the user asks to "break down tasks", "create a task list", "define epics", "plan work items", "estimate effort", "create a sprint backlog", "map dependencies", or needs to transform architecture and feature specifications into actionable epics, tasks with effort estimates, and a dependency graph suitable for sprint planning.

1 hook across 1 event