// Default reviewer criteria for the with_review tool. Generic quality bar — accuracy, intent-match, no hallucinations, clarity. Use as the criteria.skill argument when calling with_review without a domain-specific reviewer skill.
Day-of-week rotating proactive sweep — Mon=connections / Tue=routines / Wed=skills / Thu=memories / Fri=findings / Sat=cross-cutting / Sun=weekly summary. Forces outward scan instead of inward thrash. Routine-only; load this skill into a daily routine that fires AssistantAgent. Adapted from goanna's caretaker.
Use when an agent has had N consecutive quiet runs with nothing to do. Pivots to bounded inward consolidation (promote findings, refresh memory, audit asks) anchored in own data — NOT generic news summarisation. Adapted from goanna's reverie cycle. Routine-only; loaded by the routine that detects the quiet condition.
Use to track open questions you owe the user (asks) and time-bounded commitments you owe yourself (tasks). Write OPEN entries when you commit; promote to CLOSED when answered/done. Survives session compaction. Adapted from goanna's asks.md/tasks.md pattern.
Reviewer criteria for AI-generated code via with_review. Checks for security issues (injection, auth bypass, secret leakage), correctness, and project conventions. Use as criteria.skill when generating code that touches data, auth, or external systems.
Reviewer criteria for outbound email drafts via with_review. Checks tone-recipient match, professionalism, no AI tells, no placeholder leakage. Use as criteria.skill argument when reviewing email drafts before send.
Reviewer criteria for AI-generated summaries via with_review. Checks faithfulness to source, no hallucinated facts, appropriate length, key points preserved. Use as criteria.skill when summarising articles, documents, transcripts, or batch-task outputs.
| name | review-output |
| description | Default reviewer criteria for the with_review tool. Generic quality bar — accuracy, intent-match, no hallucinations, clarity. Use as the criteria.skill argument when calling with_review without a domain-specific reviewer skill. |
Use these criteria when reviewing the worker's draft. Issue exactly one verdict per iteration:
Accuracy — every factual claim is grounded in the provided context or independently verifiable. No invented stats, dates, names, URLs, or quotes. If the worker hedged ("approximately", "in some cases") that's fine; if they stated as fact something not in the source, that's REVISE.
Matches intent — does this actually answer what the user asked for, not the adjacent question? An email asking for a refund should request a refund, not apologise. A code review should flag bugs, not document the code.
Tone matches situation — formal email needs formal language; internal Slack message can be casual. Look for tone mismatches that would jar the recipient.
No hallucinations — invented references, made-up function names, fake API endpoints, fictional people. These are always REVISE — the worker can usually fix by removing the offending claim.
Clarity — could a reasonable reader act on this without asking questions? Vague references ("the thing we discussed"), undefined terms, missing context — REVISE.
Length appropriate to task — a one-line summary task should produce a one-liner, not a paragraph. A detailed report should not be three sentences. Both directions are REVISE.
Respond with ONE LINE in this exact shape:
VERDICT: APPROVE — passes all checks
VERDICT: REVISE — second paragraph claims 23% growth but source says 18%
VERDICT: REJECT — answered "what's our pricing" instead of "draft a thank-you email"
The em-dash (—) or hyphen (-) is the parser delimiter — use either.