feat: add builtin workflow resources

2026-06-11 17:44:42 +09:00
parent bf5b5bef48
commit 2418ad330e
6 changed files with 252 additions and 60 deletions
@@ -0,0 +1,11 @@
+---
+description: Public sibling coder/reviewer workflow
+model_invokation: false
+user_invocable: true
+requires: [workflow-resource-boundary]
+---
+# Multi-agent Workflow
+
+Use sibling implementation and review roles for a bounded Ticket. The Orchestrator owns intent, acceptance boundaries, blocker decisions, final merge-completion authority, and cleanup. The coder implements within delegated scope; the reviewer checks the recorded Ticket intent and acceptance criteria rather than unrecorded preferences.
+
+Produce a merge-ready dossier with Ticket id, branch/worktree, commits, implementation summary, reviewer verdict, validation evidence, residual risks, dirty state, and any remaining human decision needs.
@@ -0,0 +1,11 @@
+---
+description: Public Ticket intake requirements-sync workflow
+model_invokation: true
+user_invocable: true
+requires: [workflow-resource-boundary]
+---
+# Ticket Intake Workflow
+
+Clarify a user request until it can be represented as a concrete Ticket. Preserve user intent, write bounded requirements and acceptance criteria, and avoid creating duplicate or umbrella Tickets when a more concrete Ticket is appropriate.
+
+Do not perform implementation side effects. If an existing Ticket is refined, make scope/readiness changes explicit and keep broad changes as drafts until user agreement is clear.
@@ -0,0 +1,11 @@
+---
+description: Public Ticket orchestrator routing workflow
+model_invokation: true
+user_invocable: true
+requires: [workflow-resource-boundary]
+---
+# Ticket Orchestrator Routing Workflow
+
+Read the Ticket, relation metadata, orchestration-plan records, and relevant workspace state before deciding the next action. Treat `queued -> inprogress` as the implementation acceptance marker and record it before worktree creation, role Pod spawn, or other implementation side effects.
+
+Classify the Ticket as planning return, blocked, spike, implementation-ready, review-needed, close-ready, or noop. If implementation-ready, record an IntentPacket with binding decisions, implementation latitude, acceptance criteria, escalation conditions, validation, and reviewer focus.