{
  "schema_version": 1,
  "skill_name": "workflow-architect",
  "evals": [
    {
      "id": "active-interview-convergence",
      "prompt": "/workflow-architect — I don't have a formal process for my mornings. Interview me to figure out my actual routine.",
      "expected_output": "Scenario: active interrogation mode. The agent loads skills/interviewer/SKILL.md and guides the user through 8-15 adaptive questions covering entry points, phases, branching signals, tool preferences, loop conditions, exit criteria, and pain points. The interviewer branches its probes on the user's answers, records workflow state under workflow-architect:state:, and converges when phases, branching signals, and tool preferences are stable. On convergence it loads skills/bundle-builder/SKILL.md to synthesize the bundle. The interview stops asking questions once convergence is reached rather than continuing indefinitely.",
      "assertions": [
        "skills/interviewer/SKILL.md is loaded in active mode",
        "The interview asks adaptive questions across entry points, phases, branching signals, tools, loops, exits, and pain points",
        "Probes branch based on the user's answers",
        "Workflow state is persisted under the workflow-architect:state: prefix",
        "Convergence triggers bundle-builder synthesis instead of unbounded questioning"
      ]
    },
    {
      "id": "passive-observation-trigger",
      "prompt": "I've been working in this session for a while. /workflow-architect passive — figure out what I do. (Then the user says 'analyze my process'.)",
      "expected_output": "Scenario: passive observation mode. The agent loads skills/observer/SKILL.md silently and does nothing until the trigger phrase ('analyze my process') appears, then scans the session context and reconstructs the workflow phases, branching signals, and tool preferences from what actually happened. If the session context is too thin (fewer than ~20 substantive turns), the observer recommends switching to active interrogation instead of fabricating a workflow from sparse evidence.",
      "assertions": [
        "skills/observer/SKILL.md is loaded and stays dormant until a trigger phrase",
        "No workflow analysis is produced before the trigger phrase",
        "Session context is scanned only after the trigger",
        "Thin context results in a recommendation to switch to active mode, not fabrication",
        "Workflow state is persisted under the workflow-architect:state: prefix"
      ]
    },
    {
      "id": "bundle-generation-output",
      "prompt": "I finished the interview and we converged on my workflow: morning triage, deep work, and end-of-day review phases. Generate my skills bundle.",
      "expected_output": "Scenario: bundle synthesis. The agent loads skills/bundle-builder/SKILL.md and renders a valid Agent Skills bundle: an umbrella SKILL.md with trigger-oriented description, one sub-skill per phase with its own description and triggers, a manifest mapping skill names to trigger conditions and transition signals, and a Mermaid decision map. The bundle is written to the host skill directory, the umbrella and sub-skills are registered, and the agent verifies the umbrella and at least one sub-skill load. The user is told where it landed, what skills it contains, and a trigger phrase they can use to enter the workflow.",
      "assertions": [
        "skills/bundle-builder/SKILL.md is loaded for synthesis",
        "The output bundle has an umbrella SKILL.md and one sub-skill per workflow phase",
        "The manifest maps skill names to trigger conditions and transition signals",
        "A Mermaid decision map is produced",
        "The umbrella and at least one sub-skill are verified to load",
        "The user is told the output location, skill list, and an entry trigger phrase"
      ]
    },
    {
      "id": "thin-context-degradation",
      "prompt": "/workflow-architect passive — I just started this session and there are only two messages. Tell me my workflow.",
      "expected_output": "Scenario: degraded observation input. The session has far fewer than 20 substantive turns, so the observer does NOT reconstruct a workflow. It explicitly states that observation mode needs more context and recommends switching to active interrogation mode (the 8-15 question interview) to build the workflow model reliably. No workflow bundle is generated from the thin context.",
      "assertions": [
        "No workflow is reconstructed from the thin session context",
        "The limitation (needs ~20+ substantive turns) is stated explicitly",
        "The observer recommends active interrogation mode as the alternative",
        "No bundle is generated from sparse evidence"
      ]
    },
    {
      "id": "kanban-decision-criteria",
      "prompt": "My workflow is a single linear pipeline: triage inbox, draft, edit, publish. Should the generated bundle include a kanban board?",
      "expected_output": "Scenario: kanban inclusion decision. The agent applies the kanban decision criteria from references/kanban-decision-criteria.md: a predictable linear path with clear lane transitions can benefit from a kanban board with WIP limits. For this triage → draft → edit → publish pipeline the board is included, with board slug, phases, and WIP limits in the generated bundle. The decision is explained; a non-linear, context-heavy workflow would omit the board.",
      "assertions": [
        "The kanban decision criteria reference is consulted",
        "The linear triage → draft → edit → publish pipeline is recognized as a kanban candidate",
        "The generated bundle includes a kanban board with phases and WIP limits",
        "The decision rationale is explained to the user"
      ]
    },
    {
      "id": "trigger-condition-quality",
      "prompt": "Generate my workflow bundle. One of my phases is 'deep work' — what should its description look like?",
      "expected_output": "Scenario: trigger-condition authoring. The sub-skill descriptions follow the Agent Skills trigger format: an imperative-verb description that both positively and negatively bounds when the sub-skill loads (e.g., 'load when the user shifts into deep work mode' with a negative boundary for shallow task-switching). The description vocabulary matches how the user actually talks about entering that phase, and the umbrella description carries the broad entry triggers for the bundle. No sub-skill description is a bare phase name with no trigger guidance.",
      "assertions": [
        "Sub-skill descriptions start with an imperative verb and define a positive trigger",
        "Sub-skill descriptions include a negative boundary for when not to load",
        "Trigger vocabulary matches how the user describes entering the phase",
        "No sub-skill description is a bare phase name without trigger guidance"
      ]
    }
  ]
}

# Kanban Decision Criteria

When to include a kanban board definition in the generated bundle — and when
not to.

---

## The Principle

Kanban adds value when work flows through a **predictable, repeatable
sequence of states** where **limiting work-in-progress** and **visualizing
flow** produces actionable insight.

Kanban subtracts value when work is **emergent, exploratory, or reactive** —
situations where the states are unpredictable and WIP limits don't apply
because there's nothing to limit.

---

## Kanban-Appropriate Signals

Include a kanban board when the interview reveals:

### 1. Linear Phase Structure

The user describes their workflow as a sequence:
> "I always start with triage, then pick something to build, then review
> it, then ship it."

**Translation:** A → B → C → D structure. Each phase has a clear entry and
exit. Phases don't overlap or loop.

### 2. Explicit Hand-Offs

The user mentions waiting on others or passing work between people:
> "After I finish my part, it goes to review. Sometimes it sits there for
> a day."

**Translation:** There are queues. Work accumulates between phases. Visualizing
the queue helps manage flow.

### 3. Multiple Concurrent Items

The user tracks more than one active thing:
> "I usually have 3-4 things in progress at various stages."

**Translation:** WIP limits are meaningful. Without a board, the user may
not realize they're overcommitted.

### 4. Status as a Common Question

The user asks "where is X" or "what's the status of Y":
> "People keep asking me where their PRs are in the review queue."

**Translation:** The workflow lacks visibility. A board provides it.

### 5. Fixed Completion Criteria

Each phase has a clear "done" condition:
> "It's in review until someone approves it, then it's done."

**Translation:** Lane transitions are unambiguous. Nobody argues about
whether something is "in review" or "in progress."

---

## Kanban-Inappropriate Signals

Do NOT include a kanban board when the interview reveals:

### 1. Emergent Session Shape

Each session looks different depending on context:
> "It really depends on what happened overnight. Sometimes I'm debugging,
> sometimes I'm building, sometimes I'm just researching."

**Translation:** The workflow is too context-dependent for lanes to be stable.

### 2. Single-Item Focus

The user works on one thing at a time to completion:
> "I pick one thing and don't stop until it's done."

**Translation:** There's nothing to limit or prioritize on a board. A
simple task list is more appropriate.

### 3. Exploratory / Creative Work

The process is discovery-driven:
> "I start researching something and see where it leads. I don't know
> what I'll find until I find it."

**Translation:** The phases are emergent. Forcing a kanban structure would
add friction, not clarity.

### 4. Reactive / Event-Driven

Work is driven by external events, not planned:
> "I respond to alerts, requests, and fires. I don't really plan my
> sessions."

**Translation:** Kanban boards assume some level of planned workflow.
Reactive work needs a ticketing system, not a board.

### 5. No Clear "Done"

The user can't describe what completion looks like for each phase:
> "I know I'm done when it feels right."

**Translation:** If transitions are subjective, lanes become ambiguous.
The board will need constant reinterpretation.

---

## Decision Flowchart

```
Interview reveals workflow structure:

Is there a clear A → B → C → D sequence?
├── YES → Can the user name each phase's entry and exit?
│   ├── YES → Does the user have multiple concurrent items?
│   │   ├── YES → KANBAN. High-value fit.
│   │   └── NO  → Is there a queue or hand-off between phases?
│   │       ├── YES → KANBAN. Still valuable for flow visibility.
│   │       └── NO  → Kanban adds marginal value. Check user interest.
│   └── NO  → Is the ambiguity in exit criteria only?
│       ├── YES → Kanban with softer lane boundaries. Defer to user.
│       └── NO  → Kanban inappropriate. Use phase skills only.
└── NO → Is the workflow reactive or event-driven?
    ├── YES → Kanban inappropriate. Use phase skills only.
    └── NO → Is the user interested in a board anyway?
        ├── YES → Generate lightweight kanban. Flag the limitation.
        └── NO  → Kanban inappropriate. Phase skills only.
```

---

## Implementation

When kanban is appropriate, the bundle includes a `kanban/` directory with
three files.

### Board setup (kanban/board-setup.sh)

An executable shell script that creates the board:

```bash
#!/usr/bin/env bash
set -euo pipefail

hermes kanban boards create my-workflow \
  --name "My Workflow" \
  --description "Generated by workflow-architect" \
  --switch
```

The user reviews and runs this. It does not create tasks — just the board
container.

### Task blueprints (kanban/task-blueprints.yaml)

Maps each workflow phase to a kanban task template. Phases are ordered
sequentially; each phase's task depends on the previous one:

```yaml
board_slug: my-workflow
archetype: build-review-deploy

blueprints:
  - phase: build
    title_template: "Build: {{feature}}"
    skill: my-workflow/build
    default_priority: 3
    initial_status: todo
    body: |
      # Build Phase
      Load skill: skill_view(name='my-workflow/build')
      Definition of done: code written, tests passing, local build succeeds.
      On completion: create a "Review" task with --parent pointing to this task.

  - phase: review
    title_template: "Review: {{feature}}"
    skill: my-workflow/review
    default_priority: 2
    initial_status: ready
    body: |
      # Review Phase
      Load skill: skill_view(name='my-workflow/review')
      Definition of done: review complete, changes approved or requested.
      On approval: create a "Deploy" task with --parent pointing to this task.

  - phase: deploy
    title_template: "Deploy: {{feature}}"
    skill: my-workflow/deploy
    default_priority: 1
    initial_status: ready
    body: |
      # Deploy Phase
      Load skill: skill_view(name='my-workflow/deploy')
      Definition of done: change is live and verified. Terminal phase.
```

The dependency chain works through Hermes Kanban's built-in parent/child
task relationship. When Build (no parent) is `done`, Review (parent=Build)
auto-promotes from `todo` to `ready`. The dispatcher picks it up on the
next tick.

### Lifecycle rules

| Phase | Initial status | Dependency | Auto-promotes when |
|-------|---------------|------------|-------------------|
| First | `todo` | None | User creates task manually |
| Middle | `todo` | Previous phase task | Previous phase is `done` |
| Last | `todo` | Previous phase task | Previous phase is `done` |

- **Concurrent items:** Users can create multiple first-phase tasks for
  parallel work items. Each spawns its own dependency chain.
- **Blocked tasks:** Any task can be manually moved to `blocked` status.
  The dispatcher respects this and won't spawn blocked tasks.
- **Priority:** First phase gets highest priority (3), last phase gets
  lowest (1). Tasks within a phase inherit the blueprint's default priority.

# Trigger Condition Patterns

This reference documents the canonical patterns for writing trigger conditions
in the output bundle's sub-skills. The bundle-builder uses these patterns when
generating each sub-skill's `description` field and "When to use" section.

Trigger conditions tell the agent loader *when* to activate a skill. The more
precise the trigger, the less friction the user experiences.

---

## Trigger Categories

### 1. Keyword-Based

The most common pattern. The skill activates when the user mentions specific
terms. Multiple keywords expand recall.

**Pattern:**
```yaml
description: >-
  Use when the user mentions [keyword], [keyword], or [keyword]. Also
  use when [context description].
```

**Examples:**
- "Use when the user says PR, review, approve, merge, or changes requested."
- "Use when the user mentions debug, bug, broken, error, traceback, or crash."
- "Use when the user says draft, article, write, publish, or blog post."

**Best practices:**
- Include 3-7 keywords — enough to trigger reliably, few enough to stay focused
- Lead with the most specific keyword first
- Use synonyms and common alternates (e.g., "debug" and "fix" for troubleshooting)

---

### 2. Context-Based

The skill activates based on session state, not just user messages.

**Pattern:**
```yaml
description: >-
  [Bare description of when it applies, since context-based triggers are
  agent-determined rather than keyword-driven.]
```

**Examples:**
- "Load this at the start of every first session of the day. It runs the
  morning intake routine."
- "Load this after a tool failure or error. It handles the diagnostics protocol."
- "Load this when a session has been running for 30+ minutes. It suggests a
  wrap-up routine."

**Best practices:**
- Context-based triggers are harder to specify in the Agent Skills format
  (which relies on `description` keywords). Document the context signal
  in the skill's "When to use" section.
- Pair with keyword triggers as fallback: "Use when the user says 'wrap up'
  or when the session has been running for 30+ minutes."

---

### 3. Signal-Based

The skill activates on behavioral patterns, not explicit keywords.

**Pattern:**
```yaml
description: >-
  Use when the user [behavior description]. Activates on [signal type].
```

**Examples:**
- "Use when the user switches tools or context rapidly (3+ distinct requests
  in 5 turns). Helps re-center after context switching."
- "Use when the user pauses for 60+ seconds mid-response. Offers to recap or
  re-establish focus."
- "Use when the user types a `/` command. Handles command dispatch."

**Best practices:**
- Signal-based triggers are the most fragile — they depend on the agent
  detecting patterns in real time
- Document the signal clearly in the body so the agent recognizes it
- Prefer keyword or context triggers when possible

---

### 4. Time-Based

The skill activates on a schedule, not in response to user input.

**Pattern (for cron/scheduled skills):**
```yaml
description: >-
  Cron skill. Runs [schedule] to [purpose]. Use when setting up recurring
  tasks or automated workflows.
```

**Examples:**
- "Runs every morning at 9am. Generates a daily standup summary from the
  previous day's work."
- "Runs every Friday at 5pm. Prompts the user to wrap up open items for the
  week."
- "Runs once per hour during active sessions. Checks for stalled work and
  suggests unblocking actions."

**Best practices:**
- Time-based triggers belong in the skill body, not the description
- The description should still support keyword activation (user might say
  "set up my daily standup")
- Cron scheduling is agent-specific — note compatibility requirements

---

## Writing Trigger Descriptions

Each generated sub-skill's `description` field should follow this formula:

```
Use when [who] [does what] [under what conditions].
[Optional: what the skill provides.]
```

**Examples:**
- "Use when the user starts their morning routine — checking notifications,
  reviewing overnight updates, or prioritizing tasks."
- "Use when the user shifts into building mode — writing code, drafting
  content, or designing. Provides focused work support."
- "Use when the user is wrapping up a session — summarizing decisions,
  filing issues, or saving state for next time."

### Keywords to Include

Pull from the phase's `typical_openers` and `typical_tools` discovered during
the interview:

- **Entry openers:** "check," "review," "what's new," "status," "start"
- **Build openers:** "build," "write," "create," "implement," "design"
- **Review openers:** "review," "look at," "check this," "approve"
- **Wrap openers:** "wrap," "done," "save," "summarize," "ship"

---

## Trigger Condition Manifest Format

The output bundle's `manifest.yaml` maps skills to their trigger conditions:

```yaml
# manifest.yaml
bundle_name: my-workflow
generated: 2026-05-29
archetype: morning-triage-deep-work

skills:
  - name: morning-triage
    file: skills/morning-triage.md
    trigger:
      type: keyword
      keywords: [check, review, overnight, what's new, start, morning]
      description: >-
        Loads when the user opens with status checks,
        review requests, or morning intake language.

  - name: deep-work
    file: skills/deep-work.md
    trigger:
      type: keyword+context
      keywords: [build, write, create, implement, focus]
      context: After morning triage is complete or user skips
                directly to a specific task
      description: >-
        Loads when the user shifts into building or creating mode,
        either after triage or as the session opener.

  - name: wrap
    file: skills/wrap.md
    trigger:
      type: keyword
      keywords: [wrap, done, save, close, ship, summarize]
      description: >-
        Loads when the user signals session completion or wraps up work.
```

Each trigger can have `type` one of: `keyword`, `context`, `signal`, `time`,
or a compound type like `keyword+context`.

# Workflow Archetypes Library

Common workflow patterns for convergence detection and question seeding.
The interviewer and observer match the user's answers against these archetypes
to accelerate convergence.

Each archetype includes:
- **Signature signals** — opening messages, tool choices, and patterns
- **Typical phases** — the stages this workflow tends to follow
- **Common branching points** — decisions that determine direction
- **Exit patterns** — how sessions naturally end in this archetype
- **Kanban affinity** — whether this workflow tends to benefit from kanban

---

## Morning Triage

### Signals
- First session of the day
- Opens with status checks, dashboards, task lists
- Asks "what's pending," "any updates," "what's new"
- References multiple threads or projects in the first 2-3 messages

### Typical Phases
1. **Inbox sweep** — check notifications, email, task assignments
2. **Prioritization** — decide what's urgent vs important
3. **Stale item handling** — clear or defer leftover tasks
4. **Deep work setup** — commit to a focus area for the day

### Branching Points
- Overdue items → firefighting mode vs defer and focus
- Urgent request from collaborator → context switch
- "Everything's quiet" → proactive work, backlog grooming

### Exit Patterns
- Natural pause after clearing the inbox
- Transition to a specific task ("ok, now I'm going to work on X")
- Explicit hand-off to deep work mode

### Kanban Affinity
High — this is the most kanban-compatible pattern. Phases are sequential
and easy to map to board lanes.

---

## Deep Work Sprint

### Signals
- Opens with a specific goal or deliverable
- Requests focused, single-threaded work
- Resists interruptions or context switches
- Uses language like "no distractions," "lock in," "just this"

### Typical Phases
1. **Setup** — gather context, relevant files, open issues
2. **Build / Write** — the main work, often in bursts
3. **Test / Review** — check output, catch errors
4. **Polish / Ship** — final pass, commit, deliver

### Branching Points
- Encounter unexpected complexity → research/downtool vs push through
- Test failure → debug loop vs return to building
- Interruption → context switch vs defer

### Exit Patterns
- Natural completion of the deliverable
- Exhaustion / diminishing returns ("I need a break")
- External interruption that breaks flow

### Kanban Affinity
Medium — kanban works for the phases but deep work is often non-linear
(research → build → research → build). Use simple lanes, no WIP.

---

## Bug Hunt / Debugging

### Signals
- Opens with error messages, stack traces, or "this is broken"
- Shares logs, reproduction steps, or screenshots
- References specific files, lines of code, or symptoms
- Uses language like "why does," "this shouldn't," "it worked before"

### Typical Phases
1. **Reproduce** — confirm the bug exists and find the trigger
2. **Narrow** — isolate the root cause through elimination
3. **Fix** — apply and verify the correction
4. **Test** — ensure fix doesn't break adjacent behavior

### Branching Points
- Cannot reproduce → ask for more context vs move on
- Root cause found → fix directly vs file issue for later
- Fix breaks something else → rollback vs iterative fix

### Exit Patterns
- Bug fixed and verified
- Filed as a tracked issue for later resolution
- Punted (can't reproduce, insufficient context)

### Kanban Affinity
Low — bug hunting is inherently non-linear and exploratory.
Lane-based tracking adds friction, not clarity.

---

## Research Synthesis

### Signals
- Opens with a topic question, not a task
- Requests information gathering, analysis, or comparison
- Asks "what do we know about X" or "research Y"
- References papers, articles, documentation

### Typical Phases
1. **Scoping** — define what you're trying to learn
2. **Gathering** — collect sources, clip, extract
3. **Synthesis** — connect findings, identify patterns
4. **Capture** — write summary, vault notes, or article

### Branching Points
- Found conflicting sources → need to reconcile vs present both
- Scope creep → broaden vs narrow
- Serendipitous find → follow the thread vs save for later

### Exit Patterns
- A written deliverable (note, article, summary)
- Key question answered
- Decided the topic doesn't warrant deeper investigation

### Kanban Affinity
Low — research is emergent. The process is real but each session
looks different. Kanban doesn't add value.

---

## Creative Drafting

### Signals
- Opens with a concept, not a question
- Uses language like "what if," "imagine," "draft something"
- References style, tone, audience
- Iterates on output rather than analyzing it

### Typical Phases
1. **Inspiration** — gather references, mood, constraints
2. **Draft** — produce the first version
3. **Edit** — refine, restructure, tighten
4. **Polish** — final pass, formatting, delivery

### Branching Points
- Blocked on direction → try a different angle vs take a break
- First draft is weak → revise vs start fresh
- User dislikes direction → pivot vs push through

### Exit Patterns
- A finished piece (article, script, design)
- Published or delivered to destination
- Saved as draft for later

### Kanban Affinity
Medium — phases are sequential but the loop (draft → edit → draft) is
common. Kanban with "Draft" and "Polish" lanes works if WIP limit is 1
(items shouldn't pile up in Draft).

---

## Kanban Pipeline

### Signals
- Opens with "what's on the board," "move this task," "status"
- References specific task IDs, lanes, or tickets
- Asks about progress, blockers, or next steps
- Uses language like "ready for review," "in progress," "done"

### Typical Phases
1. **Inbox / Triage** — new items, assign, prioritize
2. **In Progress** — active work
3. **Review** — code review, approval, feedback
4. **Done** — completed, verified

### Branching Points
- Item rejected in review → return to In Progress vs discard
- Blocked → flag vs work around
- Priority change → reprioritize board vs continue

### Exit Patterns
- Board is up to date
- All items in appropriate lanes
- Next items are queued and ready

### Kanban Affinity
Very High — this workflow already uses kanban. The bundle should
include board definitions and lane rules.

---

## Firefighting / Incident Response

### Signals
- Urgent language ("this is down," "blocked," "critical")
- References production, users, or live systems
- Short, direct messages — no preamble
- Multiple rapid iterations

### Typical Phases
1. **Triage** — assess severity, declare incident
2. **Response** — stabilize, mitigate, restore
3. **Root cause** — investigate what happened
4. **Remediation** — permanent fix
5. **Post-mortem** — document what was learned

### Branching Points
- Cannot reproduce → different analysis path
- Fix requires deploy → expedited vs standard
- Incident is actually nothing → stand down

### Exit Patterns
- Service restored
- Fix applied and verified
- Post-mortem written

### Kanban Affinity
Low-to-medium — incident response has a clear process but it's
too time-sensitive for kanban tracking. Post-mortem tracking can
use kanban.

---

## On-Call Rotation

### Signals
- Opens with status checks, alerts, or monitoring dashboards
- References pagers, escalations, or rotation schedules
- Shifts between long idle periods and high-intensity bursts

### Typical Phases
1. **Handover** — review what happened since last shift
2. **Monitoring** — watch dashboards, wait for alerts
3. **Response** — handle incidents as they arise
4. **Documentation** — log what happened for next shift

### Branching Points
- Alert → respond vs acknowledge (no action needed)
- Escalation → handle vs pass to senior
- Quiet period → proactive work vs rest

### Exit Patterns
- Shift end — handover written and delivered
- All active incidents resolved or escalated

### Kanban Affinity
Low — on-call is reactive and event-driven. Kanban doesn't help
with incident frequency.

---

## Cross-Archetype Matching

A user's workflow may blend multiple archetypes. Common combinations:

| Combination | What it looks like |
|-------------|-------------------|
| Triage → Deep Work | Checks tasks, then settles into building |
| Bug Hunt → Kanban | Debugs, then tracks the fix on a board |
| Research → Creative Draft | Gathers sources, then writes from them |
| Firefighting → Post-mortem | Responds, then documents learnings |
| Morning Triage → Firefighting | Starts calm, shifts to urgent response |

When matching, note the primary archetype and list secondary blends.
The bundle should reflect the workflow as it actually flows, not force-fit
a single archetype.

---

## Archetype Summary Table

| Archetype | Kanban Fit | Bundle Bias |
|-----------|------------|-------------|
| Morning Triage | High | Clear phases, predictable transitions |
| Deep Work Sprint | Medium | Phase-based with loop allowance |
| Bug Hunt | Low | Tooling and diagnostics, not process |
| Research Synthesis | Low | Reference management, not phases |
| Creative Drafting | Medium | WIP limit of 1 on Draft lane |
| Kanban Pipeline | Very High | Full board definition |
| Firefighting | Low–Medium | Post-mortem tracking only |
| On-Call | Low | Handover documentation |

---
name: {{PHASE_NAME}}
description: >-
  {{TRIGGER_DESCRIPTION}}
license: MIT
compatibility: Compatible with any agent supporting the Agent Skills format
metadata:
  tags: [workflow, generated]
  spec-version: "1.0"
---

# {{PHASE_NAME}}

This skill is part of the **{{BUNDLE_NAME}}** bundle, generated by
workflow-architect on {{GENERATION_DATE}}.

## When to Use

{{WHEN_TO_USE}}

## What to Do

{{WHAT_TO_DO}}

## Transition Signals

This phase typically ends when:

{{TRANSITION_SIGNALS}}

## What to Tell the User

During this phase, communicate with the user in this style:

{{COMMUNICATION_GUIDANCE}}