# Developer Triage Workflow — Example Output

This directory is a **worked example** of what workflow-architect produces.
It represents a fictional developer whose typical day follows this pattern:

1. **Morning triage** — check PRs, review overnight activity, prioritize tasks
2. **Deep work** — either building a feature or researching a problem
3. **Code review** — review PRs from teammates
4. **Session wrap** — summarize progress, file issues, save state

This example is included as documentation. It is not a functional skill
bundle — it demonstrates the output format. A real bundle would have live
skill files ready for agent loading.

## Contents

| File | Purpose |
|------|---------|
| `manifest.yaml` | Maps skills to trigger conditions |
| `skills/morning-triage.md` | First-phase workflow skill |
| `skills/deep-work.md` | Workflow skill for focused building mode |
| `skills/pr-review.md` | Workflow skill for code review mode |
| `skills/session-wrap.md` | End-of-session workflow skill |
| `decision-map.md` | Mermaid flowchart of the workflow |

## What was this generated from?

This bundle was generated by workflow-architect in **active interrogation**
mode with the following state:

```yaml
entry_points:
  - "Check open PRs assigned to me"
  - "Review overnight notifications"

phases:
  - name: "Morning Triage"
    description: "Reviewing overnight activity, checking PRs, prioritizing"
    typical_tools: [gh, git, browser, project board]
    typical_openers: ["what's new", "check PRs", "review", "status"]
  - name: "Deep Work"
    description: "Focused building or research on a single task"
    typical_tools: [editor, terminal, git, docs]
    typical_openers: ["build", "implement", "research", "write"]
  - name: "Code Review"
    description: "Reviewing and approving PRs from teammates"
    typical_tools: [gh, browser, editor]
    typical_openers: ["review this", "check my PR", "approve"]
  - name: "Session Wrap"
    description: "Summarizing progress, filing follow-ups, saving state"
    typical_tools: [notes, issue tracker, git]
    typical_openers: ["wrap", "done", "save", "summarize"]

branching:
  - signal: "Pending PRs assigned to me"
    leads_to: "Triage → Review first, then deep work"
  - signal: "No pending items"
    leads_to: "Pick from kanban backlog or start something new"

kanban: false  # Workflow has emergent branching; kanban adds marginal value
```

> **No kanban in this example.** This workflow has emergent branching
> (what you do depends on whether PRs are pending), so workflow-architect
> correctly decided not to include a kanban board. See the
> `developer-pipeline-kanban` example for a strictly linear workflow that
> does include kanban.