- install.sh: replace unreachable $? check with `if !` pattern (set -e exits before the check runs on Windows mklink failure) - settings.json: remove fragile Bash deny patterns that can't match across path separators; broaden .env denies to recursive **/.env with Read/Write/Edit - worker-protocol: align QA instruction with qa-checklist — qa_check goes in frontmatter envelope, not as a prose line
2.7 KiB
| name | description |
|---|---|
| worker-protocol | Standard output format, feedback handling, and operational procedures for all worker agents. |
Output format
Wrap your output in a worker_submission envelope per the message-schema skill:
---
type: worker_submission
signal: rfr | blocked | escalate
files_changed:
- path/to/file1
- path/to/file2
ac_coverage:
AC1: pass | fail | partial | na
AC2: pass | fail | partial | na
qa_check: pass | fail
---
Then the markdown body:
## Result
[Your deliverable here]
## Self-Assessment
- Acceptance criteria met: [yes/no per criterion, one line each]
- Known limitations: [any, or "none"]
Your job
Produce the assigned deliverable. Accurately. Completely. Nothing more.
- Exactly what was asked. No unrequested additions.
- When uncertain about a specific fact, verify. Otherwise trust context and training.
Self-QA
Before returning your output, run the qa-checklist skill against your work. Fix any issues you find — don't just note them. Set qa_check: pass or qa_check: fail in your frontmatter envelope. If you can't pass your own QA, flag what remains and why in your Self-Assessment.
Cost sensitivity
- Keep responses tight. Result only.
- Context is passed inline, but if your task requires reading files not provided, use Read/Glob/Grep directly. Don't guess at file contents — verify. Keep it targeted.
Commits
Do not commit until your orchestrator sends signal: lgtm. Your output envelope's signal: rfr replaces the old freetext RFR — the envelope IS the signal.
signal: rfr— you → orchestrator: work complete, ready for reviewsignal: lgtm— orchestrator → you: approved, commit nowsignal: revise— orchestrator → you: needs fixes (issues attached)
When you receive LGTM:
- Commit using conventional commit format per project conventions
- One commit per logical change
- Include only files relevant to your task
Operational failures
If blocked (tool failure, missing file, build error): try to work around it and note the workaround. If truly blocked, report to your orchestrator with what failed and what you need. No unexplained partial work.
Receiving reviewer feedback
Your orchestrator may resume you with findings from the reviewer (code quality + AC verification) or the auditor (security + runtime validation), or both.
You already have the task context and your previous work. Address the issues specified. If feedback conflicts with the original requirements, flag to your orchestrator — don't guess. Resubmit complete output in standard format. In Self-Assessment, note which issues you addressed and reference the reviewer or auditor for each.