xiaoju
7a19ceca89
- evaluate() reads $status instead of status, defaults to _ when missing - Update all YAML examples and .workflows to use $status - Update cli-workflow resolveEvaluateArgs to use $status - 10 moderator tests pass including new default _ test - Single-exit roles no longer need to declare status field Phase 1 of #499 (closes #500)
93 lines
4.2 KiB
YAML
93 lines
4.2 KiB
YAML
name: "solve-issue"
|
|
description: "End-to-end issue resolution"
|
|
roles:
|
|
planner:
|
|
description: "Creates implementation plan"
|
|
goal: "You are a planning agent. You analyze issues and create implementation plans grounded in the actual codebase."
|
|
capabilities:
|
|
- issue-analysis
|
|
- planning
|
|
- file-read
|
|
- shell
|
|
procedure: |
|
|
1. Locate the code repository:
|
|
- Check if the current working directory is the repo (look for package.json, .git, etc.)
|
|
- If the task mentions a repo URL, clone it first.
|
|
- If this is a new project, create the repo and note the path.
|
|
2. Explore the codebase — read the relevant source files mentioned in the issue. Understand the current architecture, types, and conventions (check CLAUDE.md, CONTRIBUTING.md, .cursor/rules/).
|
|
3. Identify which files need changes and what the changes should be, with specific code references.
|
|
4. Output the plan with:
|
|
- `repoPath`: absolute path to the repository root
|
|
- `plan`: detailed implementation plan with file paths and code references
|
|
- `steps`: concrete action items for the developer
|
|
output: |
|
|
Provide repoPath, plan summary, and steps in the frontmatter.
|
|
The plan MUST reference actual file paths and code structures you found by reading the source.
|
|
Do NOT guess — if you haven't read a file, read it before referencing it.
|
|
frontmatter:
|
|
type: object
|
|
properties:
|
|
$status:
|
|
enum: ["_"]
|
|
repoPath:
|
|
type: string
|
|
plan:
|
|
type: string
|
|
required: [$status, repoPath, plan]
|
|
developer:
|
|
description: "Implements code changes"
|
|
goal: "You are a developer agent. You implement code changes according to plans."
|
|
capabilities:
|
|
- file-edit
|
|
- shell
|
|
- testing
|
|
procedure: |
|
|
1. Read the planner's output to get the repoPath and implementation plan.
|
|
2. cd to the repoPath before making any changes.
|
|
3. Create a feature branch from the default branch.
|
|
4. Implement the plan — write code, tests, and ensure existing tests pass.
|
|
5. Run the project's lint/check command (e.g. `bun run check`, `npm run lint`) and fix ALL errors before proceeding. Build and lint must pass cleanly.
|
|
6. Commit your changes with a descriptive message referencing the issue.
|
|
output: "List all files changed and provide a summary of the implementation."
|
|
frontmatter:
|
|
type: object
|
|
properties:
|
|
$status:
|
|
enum: ["_"]
|
|
filesChanged:
|
|
type: array
|
|
items:
|
|
type: string
|
|
summary:
|
|
type: string
|
|
required: [$status, filesChanged, summary]
|
|
reviewer:
|
|
description: "Reviews code changes"
|
|
goal: "You are a code reviewer. You review implementations for correctness and quality."
|
|
capabilities:
|
|
- code-review
|
|
- static-analysis
|
|
procedure: |
|
|
1. Run hard checks first — build (`bun run build` or equivalent) and lint (`bunx biome check .` or equivalent) MUST pass with zero errors. If they fail, reject immediately.
|
|
2. Then review code quality: correctness, edge cases, naming, project conventions (CLAUDE.md), and test coverage.
|
|
3. Only reject for hard check failures or genuine correctness/security issues. Style suggestions alone should not block approval.
|
|
output: "Approve or reject with detailed comments explaining your decision."
|
|
frontmatter:
|
|
type: object
|
|
properties:
|
|
$status:
|
|
enum: ["approved", "rejected"]
|
|
comments:
|
|
type: string
|
|
required: [$status, comments]
|
|
graph:
|
|
$START:
|
|
_: { role: "planner", prompt: "Analyze the issue described in the task and produce a detailed implementation plan." }
|
|
planner:
|
|
_: { role: "developer", prompt: "Implement the plan from the planner. Write code, tests, and ensure existing tests pass." }
|
|
developer:
|
|
_: { role: "reviewer", prompt: "Review the developer's implementation against the plan for correctness and quality." }
|
|
reviewer:
|
|
approved: { role: "$END", prompt: "The review passed. Complete the workflow." }
|
|
rejected: { role: "developer", prompt: "The reviewer rejected your implementation. Read their feedback and fix the issues: {{{comments}}}" }
|