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,8 @@
+---
+kind: policy
+description: Public workflow resources are procedural artifacts, not prompt fragments or dogfood policy
+model_invokation: true
+user_invocable: true
+last_sources: []
+---
+Builtin workflow resources live under `resources/workflows` and should contain public, product-generic procedure. Project dogfood details such as repository-specific Git worktree, cargo, nix, merge, and cleanup policy belong in workspace workflows or explicit launch context. Workspace workflow records override builtin workflow resources by slug, and provenance should remain visible.
@@ -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.