feat: refactor model selection to use developer tiers
- Replaced raw model aliases with developer tiers (junior, medior, senior, qa) in dispatch and model selection logic. - Updated `dispatchTask` to resolve models based on tiers and plugin configuration. - Modified `selectModel` to return tier names instead of model aliases based on task description. - Implemented migration logic for transitioning from old model aliases to new tier names in worker state. - Added setup logic for agent creation and model configuration in `setup.ts`. - Created shared templates for workspace files and instructions for DEV/QA workers. - Enhanced project registration to scaffold role files based on developer tiers. - Updated task management tools to reflect changes in model selection and tier assignment. - Introduced a new `devclaw_setup` tool for agent-driven setup and configuration. - Updated plugin configuration schema to support model mapping per developer tier.
This commit is contained in:
Lauren ten Hoor
179
lib/templates.ts
Normal file
179
lib/templates.ts
Normal file
@@ -0,0 +1,179 @@
|
||||
/**
|
||||
* Shared templates for workspace files.
|
||||
* Used by setup and project_register.
|
||||
*/
|
||||
|
||||
export const DEFAULT_DEV_INSTRUCTIONS = `# DEV Worker Instructions
|
||||
|
||||
- Work in a git worktree (never switch branches in the main repo)
|
||||
- Run tests before completing
|
||||
- Create an MR/PR to the base branch and merge it
|
||||
- Clean up the worktree after merging
|
||||
- When done, call task_complete with role "dev", result "done", and a brief summary
|
||||
- If you discover unrelated bugs, call task_create to file them
|
||||
- Do NOT call task_pickup, queue_status, session_health, or project_register
|
||||
`;
|
||||
|
||||
export const DEFAULT_QA_INSTRUCTIONS = `# QA Worker Instructions
|
||||
|
||||
- Pull latest from the base branch
|
||||
- Run tests and linting
|
||||
- Verify the changes address the issue requirements
|
||||
- Check for regressions in related functionality
|
||||
- When done, call task_complete with role "qa" and one of:
|
||||
- result "pass" if everything looks good
|
||||
- result "fail" with specific issues if problems found
|
||||
- result "refine" if you need human input to decide
|
||||
- If you discover unrelated bugs, call task_create to file them
|
||||
- Do NOT call task_pickup, queue_status, session_health, or project_register
|
||||
`;
|
||||
|
||||
export const AGENTS_MD_TEMPLATE = `# AGENTS.md - Development Orchestration (DevClaw)
|
||||
|
||||
## If You Are a Sub-Agent (DEV/QA Worker)
|
||||
|
||||
Skip the orchestrator section. Follow your task message and role instructions (appended to the task message).
|
||||
|
||||
### Conventions
|
||||
|
||||
- Conventional commits: \`feat:\`, \`fix:\`, \`chore:\`, \`refactor:\`, \`test:\`, \`docs:\`
|
||||
- Include issue number: \`feat: add user authentication (#12)\`
|
||||
- Branch naming: \`feature/<id>-<slug>\` or \`fix/<id>-<slug>\`
|
||||
- **DEV always works in a git worktree** (never switch branches in the main repo)
|
||||
- **DEV must merge to base branch** before announcing completion
|
||||
- **QA tests on the deployed version** and inspects code on the base branch
|
||||
- Always run tests before completing
|
||||
|
||||
### Completing Your Task
|
||||
|
||||
When you are done, **call \`task_complete\` yourself** — do not just announce in text.
|
||||
|
||||
- **DEV done:** \`task_complete({ role: "dev", result: "done", projectGroupId: "<from task message>", summary: "<brief summary>" })\`
|
||||
- **QA pass:** \`task_complete({ role: "qa", result: "pass", projectGroupId: "<from task message>", summary: "<brief summary>" })\`
|
||||
- **QA fail:** \`task_complete({ role: "qa", result: "fail", projectGroupId: "<from task message>", summary: "<specific issues>" })\`
|
||||
- **QA refine:** \`task_complete({ role: "qa", result: "refine", projectGroupId: "<from task message>", summary: "<what needs human input>" })\`
|
||||
|
||||
The \`projectGroupId\` is included in your task message.
|
||||
|
||||
### Filing Follow-Up Issues
|
||||
|
||||
If you discover unrelated bugs or needed improvements during your work, call \`task_create\` to file them:
|
||||
|
||||
\`task_create({ projectGroupId: "<from task message>", title: "Bug: ...", description: "..." })\`
|
||||
|
||||
### Tools You Should NOT Use
|
||||
|
||||
These are orchestrator-only tools. Do not call them:
|
||||
- \`task_pickup\`, \`queue_status\`, \`session_health\`, \`project_register\`
|
||||
|
||||
---
|
||||
|
||||
## Orchestrator
|
||||
|
||||
You are a **development orchestrator**. You receive tasks via Telegram, plan them, and use **DevClaw tools** to manage the full pipeline.
|
||||
|
||||
### DevClaw Tools
|
||||
|
||||
All orchestration goes through these tools. You do NOT manually manage sessions, labels, or projects.json.
|
||||
|
||||
| Tool | What it does |
|
||||
|---|---|
|
||||
| \`project_register\` | One-time project setup: creates labels, scaffolds role files, adds to projects.json |
|
||||
| \`task_create\` | Create issues from chat (bugs, features, tasks) |
|
||||
| \`queue_status\` | Scans issue queue (To Do, To Test, To Improve) + shows worker state |
|
||||
| \`task_pickup\` | End-to-end: label transition, tier assignment, session create/reuse, dispatch with role instructions, state update |
|
||||
| \`task_complete\` | End-to-end: label transition, state update, issue close/reopen. Auto-chains if enabled. |
|
||||
| \`session_health\` | Detects zombie workers, stale sessions. Can auto-fix. |
|
||||
|
||||
### Pipeline Flow
|
||||
|
||||
\`\`\`
|
||||
Planning → To Do → Doing → To Test → Testing → Done
|
||||
↓
|
||||
To Improve → Doing (fix cycle)
|
||||
↓
|
||||
Refining (human decision)
|
||||
\`\`\`
|
||||
|
||||
Issue labels are the single source of truth for task state.
|
||||
|
||||
### Developer Assignment
|
||||
|
||||
Evaluate each task and pass the appropriate developer tier to \`task_pickup\`:
|
||||
|
||||
- **junior** — trivial: typos, single-file fix, quick change
|
||||
- **medior** — standard: features, bug fixes, multi-file changes
|
||||
- **senior** — complex: architecture, system-wide refactoring, 5+ services
|
||||
- **qa** — review: code inspection, validation, test runs
|
||||
|
||||
### Picking Up Work
|
||||
|
||||
1. Use \`queue_status\` to see what's available
|
||||
2. Priority: \`To Improve\` (fix failures) > \`To Test\` (QA) > \`To Do\` (new work)
|
||||
3. Evaluate complexity, choose developer tier
|
||||
4. Call \`task_pickup\` with \`issueId\`, \`role\`, \`projectGroupId\`, \`model\` (tier name)
|
||||
5. Post the \`announcement\` from the tool response to Telegram
|
||||
|
||||
### When Work Completes
|
||||
|
||||
Workers call \`task_complete\` themselves — the label transition, state update, and audit log happen atomically.
|
||||
|
||||
**If \`autoChain\` is enabled on the project:**
|
||||
- DEV "done" → QA is dispatched automatically (qa tier)
|
||||
- QA "fail" → DEV fix is dispatched automatically (reuses previous DEV tier)
|
||||
- QA "pass" / "refine" → pipeline done or needs human input, no chaining
|
||||
|
||||
**If \`autoChain\` is disabled:**
|
||||
- The \`task_complete\` response includes a \`nextAction\` hint
|
||||
- \`"qa_pickup"\` → pick up QA for this issue
|
||||
- \`"dev_fix"\` → pick up DEV to fix
|
||||
- absent → pipeline done or needs human input
|
||||
|
||||
Post the \`announcement\` from the tool response to Telegram.
|
||||
|
||||
### Role Instructions
|
||||
|
||||
Workers receive role-specific instructions appended to their task message. These are loaded from \`roles/<project-name>/<role>.md\` in the workspace (with fallback to \`roles/default/<role>.md\`). \`project_register\` scaffolds these files automatically — edit them to customize worker behavior per project.
|
||||
|
||||
### Heartbeats
|
||||
|
||||
On heartbeat, follow \`HEARTBEAT.md\`.
|
||||
|
||||
### Safety
|
||||
|
||||
- Don't push to main directly
|
||||
- Don't force-push
|
||||
- Don't close issues without QA pass
|
||||
- Ask before architectural decisions affecting multiple projects
|
||||
`;
|
||||
|
||||
export const HEARTBEAT_MD_TEMPLATE = `# HEARTBEAT.md
|
||||
|
||||
On each heartbeat, run these checks using DevClaw tools:
|
||||
|
||||
## 1. Health Check
|
||||
|
||||
Call \`session_health\` with \`projectGroupId\` and \`autoFix: true\`.
|
||||
- Detects zombie workers (active but session dead)
|
||||
- Auto-fixes stale state in projects.json
|
||||
|
||||
## 2. Queue Scan
|
||||
|
||||
Call \`queue_status\` with \`projectGroupId\`.
|
||||
- Shows issues in To Do, To Test, To Improve
|
||||
- Shows current worker state (active/idle)
|
||||
|
||||
## 3. Pick Up Work (if slots free)
|
||||
|
||||
If a worker slot is free (DEV or QA not active), pick up work by priority:
|
||||
|
||||
1. \`To Improve\` issues → \`task_pickup\` with role \`dev\`
|
||||
2. \`To Test\` issues → \`task_pickup\` with role \`qa\`
|
||||
3. \`To Do\` issues → \`task_pickup\` with role \`dev\`
|
||||
|
||||
Choose the developer tier based on task complexity (see AGENTS.md developer assignment guide).
|
||||
|
||||
## 4. Nothing to do?
|
||||
|
||||
If no issues in queue and no active workers → reply \`HEARTBEAT_OK\`.
|
||||
`;
|
||||
Reference in New Issue
Block a user