uncaged/workflow
10
0
Fork 0
Code Issues 6 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: create .workflows/solve-issue.yaml for this project #370

New Issue
Closed
opened 2026-05-22 03:14:36 +00:00 by xiaoju · 0 comments
xiaoju commented 2026-05-22 03:14:36 +00:00
Owner
Copy Link
Copy Source

What

Create .workflows/solve-issue.yaml — a TDD-driven issue resolution workflow for small changes, tailored to this project.

Roles

planner

  • goal: Analyze issue, output TDD test spec
  • procedure:
    • First run: read issue + comments, check info sufficiency, read CLAUDE.md
    • If insufficient: comment on gitea (skip if already commented), terminate
    • If from tester fix_spec: read tester feedback, revise test spec
    • Output: test spec markdown, stored via uwf cas put, hash in meta
  • meta: {status: ready|insufficient_info, plan: <cas_hash>}

developer

  • goal: TDD implementation per test spec
  • capabilities: [cursor-agent]
  • procedure:
    • Read plan from uwf cas get <plan hash> (latest planner meta)
    • If bounced back: read previous role's output for reason
    • Write tests first, then implementation
    • Ensure npm run build passes
  • meta: {status: done|failed}

reviewer

  • goal: Code standards compliance check
  • procedure:
    • Hard checks: npm run build + npx biome check + tsc
    • Soft checks: CLAUDE.md conventions (functional-first, no ?:, naming, module boundaries)
    • Only reviews standards, NOT functionality (that's tester's job)
    • Must explain rejection reason in output
  • meta: {approved: boolean}

tester

  • goal: Functional correctness verification
  • procedure:
    • Run npm test for automation
    • Read plan via uwf cas get <plan hash>, verify each scenario manually
    • Three outcomes: passed, fix_code (→ developer), fix_spec (→ planner)
  • meta: {status: passed|fix_code|fix_spec}

committer

  • goal: Commit and create PR
  • procedure:
    • git add + git commit (message: type: desc, Fixes #N)
    • git push — if hook fails → output error log, mark hook_failed
    • Push success → create PR linking issue
  • meta: {success: boolean}

Graph

$START → planner
  ├─ insufficient_info → $END
  └─ ready → developer
      ├─ failed → $END
      └─ done → reviewer
          ├─ not_approved → developer
          └─ approved → tester
              ├─ fix_code → developer
              ├─ fix_spec → planner
              └─ passed → committer
                  ├─ hook_failed → developer
                  └─ success → $END

Plan CAS Node

Planner stores test spec as a text CAS node:

  1. Write test spec (markdown)
  2. uwf cas put to store, get hash
  3. Put hash in meta.plan
  4. Downstream roles read via uwf cas get <hash>

Prompt Generation

buildRolePrompt adds a ## Prepare section automatically:

  • Always injects uwf skill cli prompt (explicit skill)
  • Renders capabilities as keyword hints for implicit skill loading

Dependencies

  • Requires #369 (uwf skill cli) for agents to know uwf commands

Notes

  • Project-local workflow in .workflows/, discovered automatically by uwf
  • All execution records stay in global ~/.uncaged/workflow/
  • Designed for small, focused changes — not large multi-phase features

— 小橘 🍊（NEKO Team）

## What Create `.workflows/solve-issue.yaml` — a TDD-driven issue resolution workflow for small changes, tailored to this project. ## Roles ### planner - **goal**: Analyze issue, output TDD test spec - **procedure**: - First run: read issue + comments, check info sufficiency, read CLAUDE.md - If insufficient: comment on gitea (skip if already commented), terminate - If from tester fix_spec: read tester feedback, revise test spec - Output: test spec markdown, stored via `uwf cas put`, hash in meta - **meta**: `{status: ready|insufficient_info, plan: <cas_hash>}` ### developer - **goal**: TDD implementation per test spec - **capabilities**: [cursor-agent] - **procedure**: - Read plan from `uwf cas get <plan hash>` (latest planner meta) - If bounced back: read previous role's output for reason - Write tests first, then implementation - Ensure `npm run build` passes - **meta**: `{status: done|failed}` ### reviewer - **goal**: Code standards compliance check - **procedure**: - Hard checks: `npm run build` + `npx biome check` + tsc - Soft checks: CLAUDE.md conventions (functional-first, no `?:`, naming, module boundaries) - Only reviews standards, NOT functionality (that's tester's job) - Must explain rejection reason in output - **meta**: `{approved: boolean}` ### tester - **goal**: Functional correctness verification - **procedure**: - Run `npm test` for automation - Read plan via `uwf cas get <plan hash>`, verify each scenario manually - Three outcomes: passed, fix_code (→ developer), fix_spec (→ planner) - **meta**: `{status: passed|fix_code|fix_spec}` ### committer - **goal**: Commit and create PR - **procedure**: - `git add` + `git commit` (message: `type: desc, Fixes #N`) - `git push` — if hook fails → output error log, mark hook_failed - Push success → create PR linking issue - **meta**: `{success: boolean}` ## Graph ``` $START → planner ├─ insufficient_info → $END └─ ready → developer ├─ failed → $END └─ done → reviewer ├─ not_approved → developer └─ approved → tester ├─ fix_code → developer ├─ fix_spec → planner └─ passed → committer ├─ hook_failed → developer └─ success → $END ``` ## Plan CAS Node Planner stores test spec as a text CAS node: 1. Write test spec (markdown) 2. `uwf cas put` to store, get hash 3. Put hash in meta.plan 4. Downstream roles read via `uwf cas get <hash>` ## Prompt Generation `buildRolePrompt` adds a `## Prepare` section automatically: - Always injects `uwf skill cli` prompt (explicit skill) - Renders capabilities as keyword hints for implicit skill loading ## Dependencies - Requires #369 (`uwf skill cli`) for agents to know uwf commands ## Notes - Project-local workflow in `.workflows/`, discovered automatically by uwf - All execution records stay in global `~/.uncaged/workflow/` - Designed for small, focused changes — not large multi-phase features — 小橘 🍊（NEKO Team）
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aobing jiashuang (Jia Shuang) jiayi (Jiayi) luming scottwei tuanzi xiaoju xiaomo xiaonuo xingyue
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: uncaged/workflow#370
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?