guild-plan

Convert approved specs and team YAML into per-specialist lane plans.

6|Updated Apr 24, 2026

Search Tags:#workflow #dispatch #spec #plan #team #guild #lane

Ready to run

npx skills add https://github.com/lookatitude/guild --skill guild-plan

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: guild-plan
Source: https://github.com/lookatitude/guild/tree/main/skills/meta/plan
Command: npx skills add https://github.com/lookatitude/guild --skill guild-plan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Converts an approved spec and team configuration into a structured per-specialist lane plan that drives parallel work and clear handoffs in the Guild lifecycle.

Core Features & Use Cases

Generates one lane per specialist from the composed team (.guild/team/<slug>.yaml) and the approved spec (.guild/spec/<slug>.md).
Produces the plan at .guild/plan/<slug>.md with task-id, owner, depends-on, scope, success-criteria, and autonomy-policy.
Supports both subagent and agent-team backends, aligning execution with guild:execute-plan.
Serves as the critical handoff between team composition and context assembly in the Guild workflow.

Quick Start

Run the plan workflow after you have a guild team and an approved spec to emit the lane-oriented plan.

Frequently Asked Questions about guild-plan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I convert an approved spec into a parallel execution plan for a specialist team?▼

To convert an approved spec into a parallel execution plan, you map the team configuration into a structured per-specialist lane plan. This generates a markdown file with task-id, owner, dependencies, and success criteria to drive clear handoffs.

What is a lane-by-lane plan in a multi-agent workflow?▼

A lane-by-lane plan is a structured execution document that assigns a specific specialist lane to each task within a composed team. It wires dependencies between lanes to enable parallel work and clear handoffs during context assembly.

How do I generate per-specialist task dependencies from a team configuration file?▼

You generate per-specialist task dependencies by processing the composed team YAML alongside the approved spec. The workflow creates a plan file that explicitly wires the depends-on relationships for each specialist lane.

Can I use subagent and agent-team backends with the same generated lane plan?▼

Yes, the generated lane plan supports both subagent and agent-team backends. It aligns execution by producing a structured plan file that defines scope and autonomy-policy for each specialist before context assembly.

When do I need to generate a lane plan in the guild workflow lifecycle?▼

You need to generate a lane plan after team composition produces the team YAML and an approved spec exists. It serves as the critical handoff step before context assembly, ensuring parallel work is properly scoped and wired.

What fields are included in a per-specialist lane plan file?▼

A per-specialist lane plan file includes fields such as task-id, owner, depends-on, scope, success-criteria, and autonomy-policy. These fields ensure each specialist lane has clear boundaries and defined execution parameters.