mirror of
https://github.com/magnus919/agent-skills.git
synced 2026-09-19 07:27:04 +03:00
Magnus Hedemark
888eb62ec9
Replaces the lane-based kanban-board.yaml.tmpl with a Hermes-compatible task-dependency model using parent/child task relationships. Changes: - Delete templates/kanban-board.yaml.tmpl (wrong model — Hermes Kanban doesn't have lanes) - Create templates/kanban-board-setup.sh.tmpl — board creation script template - Create templates/kanban-task-blueprints.yaml.tmpl — phase-to-task mapping - Update bundle-builder/SKILL.md Section 6 for new kanban model - Update kanban-decision-criteria.md Implementation section with Hermes task-dependency model and lifecycle rules - Create references/example-output/developer-pipeline-kanban/ — linear build->review->deploy workflow with full kanban board, task blueprints, and usage guide - Cross-reference the two examples (non-kanban developer-triage and kanban-enabled developer-pipeline-kanban) - Update manifest.yaml.tmpl with kanban metadata slot
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:
- Morning triage — check PRs, review overnight activity, prioritize tasks
- Deep work — either building a feature or researching a problem
- Code review — review PRs from teammates
- 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:
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-kanbanexample for a strictly linear workflow that does include kanban.