From 8ddada5879e418cd17890e45375e3da2f03300d6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=B0=8F=E6=A9=98?= Date: Sat, 6 Jun 2026 10:56:28 +0000 Subject: [PATCH] =?UTF-8?q?chore:=20clean=20up=20workflow=20YAML=20?= =?UTF-8?q?=E2=80=94=20bun=E2=86=92pnpm,=20enum=E2=86=92const,=20deduplica?= =?UTF-8?q?te?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - solve-issue.yaml: bunβ†’pnpm (5 refs), examples/ is now canonical - Delete redundant workflows/solve-issue.yaml and .workflows/solve-issue.yaml - analyze-topic.yaml + eval-simple.yaml: enumβ†’const for $status - Archive normalize-bun-monorepo.yaml and e2e-walkthrough.yaml to legacy-packages/ Closes #137 小橘 🍊 --- .workflows/solve-issue.yaml | 247 ------------- examples/analyze-topic.yaml | 2 +- examples/eval-simple.yaml | 3 +- examples/solve-issue.yaml | 14 +- .../workflows}/e2e-walkthrough.yaml | 0 .../workflows}/normalize-bun-monorepo.yaml | 0 workflows/solve-issue.yaml | 329 ------------------ 7 files changed, 9 insertions(+), 586 deletions(-) delete mode 100644 .workflows/solve-issue.yaml rename {.workflows => legacy-packages/workflows}/e2e-walkthrough.yaml (100%) rename {workflows => legacy-packages/workflows}/normalize-bun-monorepo.yaml (100%) delete mode 100644 workflows/solve-issue.yaml diff --git a/.workflows/solve-issue.yaml b/.workflows/solve-issue.yaml deleted file mode 100644 index 9433f91..0000000 --- a/.workflows/solve-issue.yaml +++ /dev/null @@ -1,247 +0,0 @@ -name: "solve-issue" -description: "TDD-driven issue resolution for small, focused changes. Loop protection relies on engine maxRounds." -roles: - planner: - description: "Analyzes issue and outputs a TDD test spec" - goal: "You are a planning agent. You analyze Gitea issues and produce a TDD test specification that downstream roles will implement and verify." - capabilities: - - issue-analysis - - planning - procedure: | - On first run (no previous steps): - 1. Read the issue and all comments from Gitea using `tea issues -r ` - 2. Look for project conventions files (CLAUDE.md, CONTRIBUTING.md, .cursor/rules/) in the repo - 3. Assess whether the issue has enough information to produce a test spec - 4. If insufficient info: comment on the issue via `echo "..." | tea comment -r ` (skip if you already commented), then output $status=insufficient_info - 5. If sufficient: produce a detailed TDD test spec in markdown covering all scenarios - - On subsequent runs (bounced back by tester with fix_spec): - 1. Read the tester's output from the previous step to understand what's wrong with the spec - 2. Revise the test spec accordingly - - After producing the test spec: - 1. The test spec is stored in CAS automatically by the uwf pipeline (agents do not need to call `ocas put` directly) - 2. Put the plan hash in frontmatter.plan (required when $status=ready) - 3. Set repoPath to the absolute path of the repository root - - IMPORTANT: Extract the repo remote (owner/repo) from git: - ```bash - git remote get-url origin | sed 's|.*[:/]\([^/]*/[^.]*\).*|\1|' - ``` - Store the result as repoRemote in your frontmatter output so downstream roles can use it for tea/API calls. - output: "Output a brief summary of the test spec. Set $status to ready (with plan hash and repoPath) or insufficient_info." - frontmatter: - oneOf: - - properties: - $status: { const: "ready" } - plan: { type: string } - repoPath: { type: string } - repoRemote: { type: string } - required: [$status, plan, repoPath, repoRemote] - - properties: - $status: { const: "insufficient_info" } - reason: { type: string } - required: [$status, reason] - developer: - description: "TDD implementation per test spec" - goal: "You are a developer agent. You implement code changes following TDD β€” write tests first, then implementation." - capabilities: - - coding - procedure: | - IMPORTANT: Always work in a git worktree, NEVER modify the main working directory directly. - The repo path and other details are provided in your task prompt. - - Before starting any work, set up an isolated worktree: - 1. cd into the repo path provided in your task prompt - 2. `git fetch origin` to get latest refs - 3. First time (no existing branch): - - `git worktree add .worktrees/fix/- -b fix/- origin/main` - - `cd .worktrees/fix/- && bun install` - 4. If bounced back from reviewer or tester (branch already exists): - - cd into the existing worktree under `.worktrees/fix/-` - - `git fetch origin && git rebase origin/main` - 5. ALL subsequent work must happen inside the worktree directory. - - Then implement TDD: - 6. Read the test spec from CAS: `ocas get ` (find the hash from the planner's output in your task prompt) - 7. If bounced back from reviewer or tester: read the previous role's feedback in your task prompt - 8. Write tests first based on the spec - 9. Implement the code to make tests pass - 10. Ensure `bun run build` passes with no errors - 11. Run `bun test` to verify all tests pass - - If tests fail on first run: - * Read the test output carefully for missing imports or setup issues - * Check if you're running tests from the correct working directory (package root vs workspace root) - * Fix the immediate issue and rerun ONCE - * If tests still fail after 2 attempts: check the test spec for ambiguities - * If stuck after 3 test cycles: set $status=failed with detailed error report rather than continuing blind retries - 12. MANDATORY VERIFICATION before reporting done: - - Run `git branch --show-current` and confirm branch name matches expected - - Run `git status` and verify changed files exist - - Run `ls -la ` to verify they exist on disk - - If ANY verification fails: retry the implementation, do NOT report done - - If you cannot complete the implementation (e.g. the issue is too complex, blocked by external factors, - or repeated attempts fail), set $status=failed with a reason. - output: "List all files changed and provide a summary. Set $status to done (with branch/worktree), or failed (with reason)." - frontmatter: - oneOf: - - properties: - $status: { const: "done" } - branch: { type: string } - worktree: { type: string } - repoRemote: { type: string } - required: [$status, branch, worktree] - - properties: - $status: { const: "failed" } - reason: { type: string } - required: [$status, reason] - reviewer: - description: "Code standards compliance check" - goal: "You are a code reviewer. You verify code standards compliance β€” NOT functionality (that's the tester's job)." - capabilities: - - code-review - - static-analysis - procedure: | - The worktree path is provided in your task prompt. cd into it first. - - CRITICAL: You MUST execute every verification command below. Do NOT report results without running the actual commands. Do NOT rely on prior context or assumptions. - - Before reviewing, verify the worktree and branch exist: - 0. Run `cd && pwd` to confirm the path is accessible - - If the cd fails: the worktree truly doesn't exist, reject with that reason - - If the cd succeeds: proceed with step 1 below - 1. Run `git branch --show-current` β€” confirm the branch name references the issue number being worked on - 2. If the branch doesn't correspond to the issue, flag it in your output and reject - - Then perform code review: - Hard checks (must all pass): - 3. `bun run build` β€” no build errors - 4. `bunx biome check` β€” no lint violations - 5. TypeScript strict mode β€” no type errors - - Soft checks (review against project conventions if CLAUDE.md / .cursor/rules exist): - - Naming conventions, module boundaries, code style - - No `console.log` in production code - - No dynamic imports in production code - - Only review standards compliance. Do NOT test functionality. - If rejecting, you MUST explain the specific reason in your output. - output: "Explain your decision with specific file/line references. Set $status to approved (with branch/worktree) or rejected (with comments)." - frontmatter: - oneOf: - - properties: - $status: { const: "approved" } - branch: { type: string } - worktree: { type: string } - repoRemote: { type: string } - required: [$status, branch, worktree] - - properties: - $status: { const: "rejected" } - comments: { type: string } - worktree: { type: string } - repoRemote: { type: string } - required: [$status, comments, worktree] - tester: - description: "Functional correctness verification" - goal: "You are a tester agent. You verify that the implementation correctly satisfies every scenario in the test spec." - capabilities: - - testing - procedure: | - The worktree path is provided in your task prompt. cd into it first. - - 1. Run `bun test` for automated test verification - 2. Read the test spec from CAS: `ocas get ` (find the hash from the planner step in the thread history) - 3. Verify each scenario in the spec is covered and passing - 4. Determine outcome: - - passed: all scenarios verified, tests pass - - fix_code: tests fail or implementation doesn't match spec β†’ send back to developer - - fix_spec: the spec itself is wrong or incomplete β†’ send back to planner - output: "Report test results per scenario. Set $status to passed (with branch/worktree), fix_code (with report), or fix_spec (with report)." - frontmatter: - oneOf: - - properties: - $status: { const: "passed" } - branch: { type: string } - worktree: { type: string } - repoRemote: { type: string } - required: [$status, branch, worktree] - - properties: - $status: { const: "fix_code" } - report: { type: string } - repoRemote: { type: string } - worktree: { type: string } - branch: { type: string } - required: [$status, report] - - properties: - $status: { const: "fix_spec" } - report: { type: string } - repoRemote: { type: string } - worktree: { type: string } - branch: { type: string } - required: [$status, report] - committer: - description: "Commits and creates PR" - goal: "You are a committer agent. You create a clean commit and push a PR linking the original issue." - capabilities: [] - procedure: | - The worktree path, branch name, and repo remote (owner/repo) are provided in your task prompt. - cd into the worktree first. - - Note: You inherit the developer's worktree and branch. Do NOT create a new branch. - 1. Check `git status` β€” if working tree is clean and branch is ahead of origin, skip to step 3 (push). - 2. If there are unstaged/uncommitted changes: `git add -A` then `git commit -m "type: description\n\nFixes #N"` - 3. Push the branch: `git push -u origin ` - 4. **Verify push succeeded** β€” run `git ls-remote origin ` and confirm it prints a commit hash. - - If no output or push failed: capture the error, mark hook_failed - 5. Create a PR using the Gitea API (do NOT use `tea pr create` β€” it fails in worktrees): - ```bash - GITEA_TOKEN=$(cfg get GITEA_TOKEN) - curl -s -X POST -H "Authorization: token $GITEA_TOKEN" -H "Content-Type: application/json" \ - "https://git.shazhou.work/api/v1/repos///pulls" \ - -d '{"title":"...","body":"...","head":"","base":"main"}' - ``` - - The repo remote (owner/repo format, e.g. "shazhou/united-workforce") is given in your task prompt β€” use it directly. - - PR body must include: What / Why / Changes / Ref sections, with `Fixes #N` in Ref - 6. **Verify PR was created** β€” parse the curl response JSON: it must contain a `"number"` field. Print the PR URL. - - If curl returns an error or no number field: capture the response, mark hook_failed - 7. After PR creation, clean up the worktree: - - cd to the repo root (parent of .worktrees) - - `git worktree remove ` - output: "Include PR URL on success or error log on failure. Set $status to committed (with prUrl) or hook_failed (with error)." - frontmatter: - oneOf: - - properties: - $status: { const: "committed" } - prUrl: { type: string } - repoRemote: { type: string } - worktree: { type: string } - branch: { type: string } - required: [$status, prUrl] - - properties: - $status: { const: "hook_failed" } - error: { type: string } - repoRemote: { type: string } - worktree: { type: string } - branch: { type: string } - required: [$status, error] -graph: - $START: - new: { role: "planner", prompt: "Analyze the issue and produce an implementation plan." } - resume: { role: "planner", prompt: "Review the previous run output and continue the work." } - planner: - insufficient_info: { role: "$SUSPEND", prompt: "δΏ‘ζ―δΈθΆ³οΌŒιœ€θ¦θ‘₯ε……οΌš{{{reason}}}" } - ready: { role: "developer", prompt: "Implement the TDD test spec (CAS hash: {{{plan}}}) in repo {{{repoPath}}}. Repo remote: {{{repoRemote}}}." } - developer: - done: { role: "reviewer", prompt: "Review branch {{{branch}}} at {{{worktree}}} for code standards compliance. Repo remote: {{{repoRemote}}}." } - failed: { role: "$END", prompt: "Developer failed: {{{reason}}}. Ending workflow." } - reviewer: - rejected: { role: "developer", prompt: "Reviewer rejected: {{{comments}}}. Fix the issues in repo {{{worktree}}}. Repo remote: {{{repoRemote}}}." } - approved: { role: "tester", prompt: "Review passed. Run tests on branch {{{branch}}} at {{{worktree}}}. Repo remote: {{{repoRemote}}}." } - tester: - fix_code: { role: "developer", prompt: "Tests found code issues: {{{report}}}. Fix and re-submit. Worktree: {{{worktree}}}. Repo remote: {{{repoRemote}}}." } - fix_spec: { role: "planner", prompt: "Tests found spec issues: {{{report}}}. Revise the test spec. Repo remote: {{{repoRemote}}}." } - passed: { role: "committer", prompt: "All tests passed. Commit and push branch {{{branch}}} from {{{worktree}}}. Repo remote (owner/repo): {{{repoRemote}}}." } - committer: - hook_failed: { role: "developer", prompt: "Push hook failed: {{{error}}}. Fix and re-submit. Worktree: {{{worktree}}}. Repo remote: {{{repoRemote}}}." } - committed: { role: "$END", prompt: "PR created: {{{prUrl}}}. Workflow complete." } diff --git a/examples/analyze-topic.yaml b/examples/analyze-topic.yaml index 661c747..22b7e5f 100644 --- a/examples/analyze-topic.yaml +++ b/examples/analyze-topic.yaml @@ -23,7 +23,7 @@ roles: type: object properties: $status: - enum: ["done"] + const: done thesis: type: string keyPoints: diff --git a/examples/eval-simple.yaml b/examples/eval-simple.yaml index 60fcc3a..9af37b4 100644 --- a/examples/eval-simple.yaml +++ b/examples/eval-simple.yaml @@ -18,8 +18,7 @@ roles: type: object properties: $status: - type: string - enum: [done] + const: done summary: type: string required: [$status, summary] diff --git a/examples/solve-issue.yaml b/examples/solve-issue.yaml index 9ca6c06..d817656 100644 --- a/examples/solve-issue.yaml +++ b/examples/solve-issue.yaml @@ -1,5 +1,5 @@ name: "solve-issue" -description: "TDD-driven issue resolution for small, focused changes. Loop protection relies on engine maxRounds." +description: "TDD-driven issue resolution for small, focused changes. Loop protection relies on engine maxRounds. Uses pnpm." roles: planner: description: "Analyzes issue and outputs a TDD test spec" @@ -80,7 +80,7 @@ roles: 2. `git fetch origin` to get latest refs 3. First time (no existing branch): - `git worktree add .worktrees/fix/- -b fix/- origin/main` - - `cd .worktrees/fix/- && bun install` + - `cd .worktrees/fix/- && pnpm install` 4. If continuing on existing branch (prompt says "Continue work on existing branch" or provides a worktree path): - cd directly into the worktree path provided in the prompt - `git fetch origin && git rebase origin/main` @@ -95,8 +95,8 @@ roles: 7. If bounced back from reviewer or tester: read the previous role's feedback in your task prompt 8. Write tests first based on the spec 9. Implement the code to make tests pass - 10. Ensure `bun run build` passes with no errors - 11. Run `bun test` to verify all tests pass + 10. Ensure `pnpm run build` passes with no errors + 11. Run `pnpm test` to verify all tests pass If you cannot complete the implementation (e.g. the issue is too complex, blocked by external factors, or repeated attempts fail), set $status=failed with a reason. @@ -127,8 +127,8 @@ roles: Then perform code review: Hard checks (must all pass): - 3. `bun run build` β€” no build errors - 4. `bunx biome check` β€” no lint violations + 3. `pnpm run build` β€” no build errors + 4. `pnpm run check` β€” no lint violations 5. TypeScript strict mode β€” no type errors Soft checks (review against project conventions if CLAUDE.md / .cursor/rules exist): @@ -159,7 +159,7 @@ roles: procedure: | The worktree path is provided in your task prompt. cd into it first. - 1. Run `bun test` for automated test verification + 1. Run `pnpm test` for automated test verification 2. Read the test spec from CAS: `ocas get ` (find the hash from the planner step in the thread history) 3. Verify each scenario in the spec is covered and passing 4. Determine outcome: diff --git a/.workflows/e2e-walkthrough.yaml b/legacy-packages/workflows/e2e-walkthrough.yaml similarity index 100% rename from .workflows/e2e-walkthrough.yaml rename to legacy-packages/workflows/e2e-walkthrough.yaml diff --git a/workflows/normalize-bun-monorepo.yaml b/legacy-packages/workflows/normalize-bun-monorepo.yaml similarity index 100% rename from workflows/normalize-bun-monorepo.yaml rename to legacy-packages/workflows/normalize-bun-monorepo.yaml diff --git a/workflows/solve-issue.yaml b/workflows/solve-issue.yaml deleted file mode 100644 index 3276510..0000000 --- a/workflows/solve-issue.yaml +++ /dev/null @@ -1,329 +0,0 @@ -name: solve-issue -description: TDD-driven issue resolution adapted for the workflow monorepo with bun + vitest -roles: - planner: - description: Analyzes issue and outputs a TDD test spec - goal: You are a planning agent. You analyze Gitea issues and produce a TDD test specification that downstream roles will implement and verify. - capabilities: - - issue-analysis - - planning - procedure: 'On first run (no previous steps): - - 1. Read the issue and all comments from Gitea using `tea issues -r ` - - 2. Look for project conventions files (CLAUDE.md, CONTRIBUTING.md) in the repo - - 3. Assess whether the issue has enough information to produce a test spec - - 4. If insufficient info: comment on the issue via `echo "..." | tea comment -r ` (skip if you already commented), then output $status=insufficient_info - - 5. If sufficient: produce a detailed TDD test spec in markdown covering all scenarios - - - On subsequent runs (bounced back by tester with fix_spec): - - 1. Read the tester''s output from the previous step to understand what''s wrong with the spec - - 2. Revise the test spec accordingly - - - After producing the test spec: - - 1. The test spec is stored in CAS automatically by the uwf pipeline (agents do not need to call `ocas put` directly) - - 2. Put the hash in frontmatter.plan (required when $status=ready) - - 3. Set repoPath to the absolute path of the repository root - - - - IMPORTANT: Extract the repo remote (owner/repo) from git: - - ```bash - - git remote get-url origin | sed ''s|.*[:/]\([^/]*/[^.]*\).*|\1|'' - - ``` - - Store the result as repoRemote in your frontmatter output so downstream roles can use it for tea/API calls.' - output: Output a brief summary of the test spec. Set $status to ready (with plan hash and repoPath) or insufficient_info. - frontmatter: - oneOf: - - properties: - $status: - const: ready - plan: - type: string - repoPath: - type: string - repoRemote: - type: string - required: - - $status - - plan - - repoPath - - properties: - $status: - const: insufficient_info - reason: - type: string - required: - - $status - - reason - developer: - description: TDD implementation per test spec - goal: You are a developer agent. You implement code changes following TDD β€” write tests first, then implementation. - capabilities: - - coding - procedure: "IMPORTANT: Always work in a git worktree, NEVER modify the main working directory directly.\nThe repo path and other details are provided in your task prompt.\n\nBefore starting any work,\ - \ set up an isolated worktree:\n1. cd into the repo path provided in your task prompt\n2. `git fetch origin` to get latest refs\n3. First time (no existing branch):\n - `git worktree add .worktrees/fix/-\ - \ -b fix/- origin/main`\n - `cd .worktrees/fix/- && bun install`\n4. If bounced back from reviewer or tester (branch already exists):\n - cd\ - \ into the existing worktree under `.worktrees/fix/-`\n - `git fetch origin && git rebase origin/main`\n5. ALL subsequent work must happen inside the worktree directory.\n\ - \nThen implement TDD:\n6. Read the test spec from CAS: `ocas get ` (find the hash from the planner's output in your task prompt)\n7. If bounced back from reviewer or tester: read the\ - \ previous role's feedback in your task prompt\n8. Write tests first based on the spec (use vitest)\n9. Implement the code to make tests pass\n10. Ensure `bun run build` passes with no errors\n11.\ - \ Run `bun test` to verify all tests pass\n\nIf you cannot complete the implementation (e.g. the issue is too complex, blocked by external factors,\nor repeated attempts fail), set $status=failed\ - \ with a reason.\n" - output: List all files changed and provide a summary. Set $status to done (with branch/worktree), or failed (with reason). - frontmatter: - oneOf: - - properties: - $status: - const: done - branch: - type: string - worktree: - type: string - repoRemote: - type: string - required: - - $status - - branch - - worktree - - properties: - $status: - const: failed - reason: - type: string - repoRemote: - type: string - required: - - $status - - reason - reviewer: - description: Code standards compliance check - goal: You are a code reviewer. You verify code standards compliance β€” NOT functionality (that's the tester's job). - capabilities: - - code-review - - static-analysis - procedure: 'The worktree path is provided in your task prompt. cd into it first. - - - Before reviewing, verify the git branch: - - 1. Run `git branch --show-current` β€” confirm the branch name references the issue number being worked on - - 2. If the branch doesn''t correspond to the issue, flag it in your output and reject - - - Then perform code review: - - Hard checks (must all pass): - - 3. `bun run build` β€” no build errors - - 4. `bunx biome check` β€” no lint violations - - 5. TypeScript strict mode β€” no type errors - - - Soft checks (review against project conventions from CLAUDE.md): - - - Functional-first: functions + types, no classes (except for errors or third-party requirements) - - - Named exports only, no default exports - - - No optional properties (use `T | null` instead of `?:`) - - - Folder module discipline: index.ts only re-exports, types in types.ts - - - Crockford Base32 log tags (8-char, unique per call site) - - - No `console.log` in production code (use createLogger from @united-workforce/util) - - - No dynamic imports in production code - - - Only review standards compliance. Do NOT test functionality. - - If rejecting, you MUST explain the specific reason in your output. - - ' - output: Explain your decision with specific file/line references. Set $status to approved (with branch/worktree) or rejected (with comments). - frontmatter: - oneOf: - - properties: - $status: - const: approved - branch: - type: string - worktree: - type: string - repoRemote: - type: string - required: - - $status - - branch - - worktree - - properties: - $status: - const: rejected - comments: - type: string - worktree: - type: string - repoRemote: - type: string - required: - - $status - - comments - - worktree - tester: - description: Functional correctness verification - goal: You are a tester agent. You verify that the implementation correctly satisfies every scenario in the test spec. - capabilities: - - testing - procedure: "The worktree path is provided in your task prompt. cd into it first.\n\n1. Run `bun test` for automated test verification\n2. Read the test spec from CAS: `ocas get ` (find\ - \ the hash from the planner step in the thread history)\n3. Verify each scenario in the spec is covered and passing\n4. Determine outcome:\n - passed: all scenarios verified, tests pass\n - fix_code:\ - \ tests fail or implementation doesn't match spec β†’ send back to developer\n - fix_spec: the spec itself is wrong or incomplete β†’ send back to planner\n" - output: Report test results per scenario. Set $status to passed (with branch/worktree), fix_code (with report), or fix_spec (with report). - frontmatter: - oneOf: - - properties: - $status: - const: passed - branch: - type: string - worktree: - type: string - repoRemote: - type: string - required: - - $status - - branch - - worktree - - properties: - $status: - const: fix_code - report: - type: string - repoRemote: - type: string - worktree: - type: string - branch: - type: string - required: - - $status - - report - - properties: - $status: - const: fix_spec - report: - type: string - repoRemote: - type: string - worktree: - type: string - branch: - type: string - required: - - $status - - report - committer: - description: Commits and creates PR - goal: You are a committer agent. You create a clean commit and push a PR linking the original issue. - capabilities: [] - procedure: "The worktree path, branch name, and repo remote (owner/repo) are provided in your task prompt.\ncd into the worktree first.\n\nNote: You inherit the developer's worktree and branch. Do NOT\ - \ create a new branch.\n1. Stage all changes: `git add -A`\n2. Commit with a descriptive message referencing the issue: `git commit -m \"type: description\\n\\nFixes #N\"`\n3. Push the branch: `git\ - \ push -u origin `\n4. **Verify push succeeded** β€” run `git ls-remote origin ` and confirm it prints a commit hash.\n - If no output or push failed: capture the error, mark hook_failed\n\ - 5. Create a PR using the Gitea API (do NOT use `tea pr create` β€” it fails in worktrees):\n ```bash\n GITEA_TOKEN=$(cfg get GITEA_TOKEN)\n curl -s -X POST -H \"Authorization: token $GITEA_TOKEN\" -H \"Content-Type: application/json\" \\\n\ - \ \"https://git.shazhou.work/api/v1/repos///pulls\" \\\n -d '{\"title\":\"...\",\"body\":\"...\",\"head\":\"\",\"base\":\"main\"}'\n ```\n - The repo remote (owner/repo format, e.g. \"shazhou/united-workforce\") is given in your task prompt β€” use it directly.\n\ - \ - PR body must include: What / Why / Changes / Ref sections, with `Fixes #N` in Ref\n6. **Verify PR was created** β€” parse the curl response JSON: it must contain a `\"number\"` field. Print the PR URL.\n\ - \ - If curl returns an error or no number field: capture the response, mark hook_failed\n7. After PR creation, clean up the worktree:\n - cd to the repo root (parent of .worktrees)\n - `git worktree remove `" - output: Include PR URL on success or error log on failure. Set $status to committed (with prUrl) or hook_failed (with error). - frontmatter: - oneOf: - - properties: - $status: - const: committed - prUrl: - type: string - repoRemote: - type: string - worktree: - type: string - branch: - type: string - required: - - $status - - prUrl - - properties: - $status: - const: hook_failed - error: - type: string - repoRemote: - type: string - worktree: - type: string - branch: - type: string - required: - - $status - - error -graph: - $START: - new: - role: planner - prompt: Analyze the issue and produce an implementation plan. - resume: - role: planner - prompt: Review the previous run output and continue the work. - planner: - insufficient_info: - role: $SUSPEND - prompt: "δΏ‘ζ―δΈθΆ³οΌŒιœ€θ¦θ‘₯ε……οΌš{{{reason}}}" - ready: - role: developer - prompt: 'Implement the TDD test spec (CAS hash: {{{plan}}}) in repo {{{repoPath}}}. Repo remote: {{{repoRemote}}}.' - developer: - done: - role: reviewer - prompt: 'Review branch {{{branch}}} at {{{worktree}}} for code standards compliance. Repo remote: {{{repoRemote}}}.' - failed: - role: $END - prompt: 'Developer failed: {{{reason}}}. Ending workflow.' - reviewer: - rejected: - role: developer - prompt: 'Reviewer rejected: {{{comments}}}. Fix the issues in repo {{{worktree}}}. Repo remote: {{{repoRemote}}}.' - approved: - role: tester - prompt: 'Review passed. Run tests on branch {{{branch}}} at {{{worktree}}}. Repo remote: {{{repoRemote}}}.' - tester: - fix_code: - role: developer - prompt: 'Tests found code issues: {{{report}}}. Fix and re-submit. Worktree: {{{worktree}}}. Repo remote: {{{repoRemote}}}.' - fix_spec: - role: planner - prompt: 'Tests found spec issues: {{{report}}}. Revise the test spec. Repo remote: {{{repoRemote}}}.' - passed: - role: committer - prompt: 'All tests passed. Commit and push branch {{{branch}}} from {{{worktree}}}. Repo remote (owner/repo): {{{repoRemote}}}.' - committer: - hook_failed: - role: developer - prompt: 'Push hook failed: {{{error}}}. Fix and re-submit. Worktree: {{{worktree}}}. Repo remote: {{{repoRemote}}}.' - committed: - role: $END - prompt: 'PR created: {{{prUrl}}}. Workflow complete.'