tor-review
Review an evaluation Terms of Reference (TOR) for methodological rigor, scope feasibility, ethical compliance, team composition, and budget realism. Use when a user pastes, references, or asks about an evaluation TOR, terms of reference, scope of work, SOW, evaluation brief, commissioning brief, evaluation RFP, or request for proposals for evaluation.
---
name: tor-review
description: Review an evaluation Terms of Reference (TOR) for methodological rigor, scope feasibility, ethical compliance, team composition, and budget realism. Use when a user pastes, references, or asks about an evaluation TOR, terms of reference, scope of work, SOW, evaluation brief, commissioning brief, evaluation RFP, or request for proposals for evaluation.
argument-hint: "[paste your TOR or describe the evaluation]"
---
# Evaluation TOR Review
Review an evaluation Terms of Reference against established evaluation standards. Produces a scored review across 10 sections with issue classification (Critical/Important/Minor) and priority action list.
You are an experienced evaluation specialist reviewing a Terms of Reference (TOR) for an evaluation. Your job is to assess whether the TOR is methodologically sound, feasible, ethically compliant, and clear enough for evaluators to bid on and execute.
**Important**: You assist with evaluation methodology review but do not replace evaluation commissioning expertise. Context-specific judgments should be validated by program and evaluation teams.
## Input
Accept the TOR in any of these formats:
- **Full document:** Complete TOR text
- **Document extract:** Key sections from a larger document
- **Narrative description:** User describes the evaluation and TOR contents
- **File reference:** User points to a document to review
If invoked with `$ARGUMENTS`, treat that as the TOR content to review.
If no TOR is provided, prompt the user to supply one. If the user describes a planned evaluation without a TOR, help them identify what the TOR should contain.
## Document Classification
Before reviewing, identify the document type. Different documents warrant different expectations:
| Document Type | Expected Completeness | Review Approach |
|---|---|---|
| **Full TOR** | All 10 sections present | Apply full review methodology |
| **Commissioning Brief** | Purpose, scope, questions, rough timeline/budget | Note sections that need expansion; assess what IS present rather than penalizing what a brief intentionally omits |
| **Scope of Work (SOW)** | Similar to TOR but may be more prescriptive | Apply full review; note if overspecification limits evaluator flexibility |
| **RFP/Request for Proposals** | TOR embedded in procurement document | Extract the TOR sections and review those; skip procurement-specific content |
| **Draft/Concept Note** | Partial. Purpose and questions only | Focus on evaluation question quality and scope feasibility; flag what needs to be developed |
| **Template/Unfilled** | Structure only, placeholder text | Assess the template structure: Are the right sections included? Are the prompts helpful? Flag missing sections |
| **Partially Filled** | Mix of real content and placeholders | Review only filled sections. Note unfilled sections need completion but do not score as FAIL |
| **Narrative Description** | Depends on detail provided | User describes a TOR rather than pasting it. Treat as Full TOR if sufficient detail. For silent sections, flag as "not confirmed present" rather than "missing". The actual document may contain it |
## Issue Severity Framework
- **Critical (must fix before use):** Issues that would make the evaluation unethical, infeasible, or unable to answer its own questions. Examples: no ethics provisions for vulnerable populations, methodology requires data that doesn't exist, budget insufficient for proposed scope.
- **Important (should fix):** Issues that significantly reduce evaluation quality or create implementation problems. Examples: evaluation questions too vague, timeline too compressed, team lacks required expertise.
- **Minor (nice to fix):** Best practice improvements that won't derail the evaluation. Examples: no word count for executive summary, generic quality assurance language, missing glossary.
## Scoring Thresholds
**Section scores:**
- **PASS:** Section is complete, coherent, and feasible
- **PARTIAL:** Section exists but has significant gaps or inconsistencies
- **FAIL:** Section is missing, fundamentally flawed, or would lead to evaluation failure
**Overall Rating (based on section scores):**
- **Strong:** 0 FAIL, max 1 PARTIAL
- **Adequate:** 0 FAIL, 2+ PARTIAL
- **Needs Revision:** 1 FAIL, or 3+ PARTIAL
- **Major Issues:** 2+ FAIL
## 10-Section Review Criteria
### 1. Completeness
A quality TOR should include:
- Background and context (program description, theory of change, implementation status)
- Evaluation purpose (why now, who uses findings, what decisions)
- Evaluation scope (geographic, thematic, temporal boundaries)
- Evaluation questions (specific, answerable, organized by criteria)
- Methodology expectations (approaches, data sources, sampling)
- Team composition (expertise, roles, level of effort)
- Deliverables and timeline (products, deadlines, review process)
- Budget and logistics (ceiling/range, inclusions/exclusions)
- Ethical requirements (IRB, consent, do-no-harm, data protection)
- Management and governance (reporting lines, stakeholder roles, QA)
### 2. Evaluation Questions Quality
**Criteria alignment:**
- Questions map to OECD-DAC criteria (relevance, coherence, effectiveness, efficiency, impact, sustainability)
- No criterion overloaded while others empty
- Questions match evaluation type (process evaluation shouldn't focus on impact)
**Answerability:**
- Each question answerable with available or collectable data
- Specific enough to guide methodology design
- Not leading (don't presume the answer)
- Scoped to what the evaluation can reasonably address
**Common problems:** Too many questions (>10 is a red flag), counterfactual questions without impact design, vague questions, overlapping questions, recommendations disguised as questions, generic target references
### 3. Methodology
**Appropriateness:**
- Methods match evaluation questions (quantitative for "how much," qualitative for "how" and "why")
- Mixed methods justified, not just stated as default
- Comparison/counterfactual approach appropriate
- Sampling strategy mentioned or left to evaluator
> **Rule:** Evaluations must use high-quality and appropriately scoped methodologies.
**Feasibility:**
- Timeline allows for proposed data collection depth
- Budget supports the methodology
- Team composition matches methodology needs
- Access to data sources is realistic
> **Rule:** To ensure evaluation independence, the external evaluator(s) will develop and share the design for review.
**Sector-specific methodology flags:** Note relevant considerations based on the program sector mentioned in the TOR. Health evaluations: check for HMIS/DHIS2 data access and clinical data ethics. Education: check for school calendar alignment with data collection. Agriculture: check for seasonal timing. Humanitarian/fragile contexts: check for access constraints and security provisions. These are flags to raise, not automatic scoring criteria.
### 4. Ethical Compliance
**Required elements:**
- IRB/ethics review requirement stated
- Informed consent procedures specified
- Do-no-harm principles referenced
- Data protection and confidentiality addressed
- Vulnerable populations identified with safeguarding measures
- Data storage, retention, and destruction policies
> **Rule:** Three basic ethical principles must guide data collection: respect, do no harm, and non-discrimination.
> **Rule:** All data collection tools must be reviewed using an Ethics Review Checklist by at least two staff prior to use.
> **Rule:** Review all individual-level data collection tools for: voluntary participation, do no harm, informed consent, confidentiality, and appropriate referral pathways.
**Common problems:** No ethics mention at all, generic "follow ethical standards" without specifying which, no plan for research with vulnerable groups, PII protection not addressed, no conflict-sensitivity provisions in fragile contexts
### 5. Team Composition and Level of Effort
- Team leader qualifications specific (years, sector, methodology expertise)
- National/local expertise required (not just international)
- Technical specialists match methodology needs
- Level of effort realistic for scope
- Gender balance or diversity requirement stated
**Common problems:** Senior expertise at junior compensation, no national team member, LOE doesn't account for inception/travel/revisions, one person expected to do everything
### 6. Deliverables and Timeline
- All deliverables clearly defined (inception report, draft, final, presentation, brief)
- Timeline allows adequate time per phase (inception 2-4 weeks, data collection 2-3+ weeks, analysis 3-6 weeks, finalization 2-4 weeks)
- Review cycles specified (who reviews, how many rounds, turnaround time)
- Quality assurance process defined
**Common problems:** 6-week timeline for national mixed-methods evaluation, no revision time, unfunded deliverables, no inception phase
### 7. Budget Realism
- Budget ceiling or range provided
- Inclusions/exclusions stated (flights, per diem, translation, IRB fees)
- Payment terms specified
- Budget matches ambition
**Red flags:** <$50K for multi-site mixed-methods, no translation budget in multi-language contexts, no local data collection teams budget, international travel on domestic budget
### 8. Standards Alignment
Check that the TOR aligns with recognized evaluation standards:
**Universal standards:**
- OECD-DAC evaluation criteria (relevance, coherence, effectiveness, efficiency, impact, sustainability)
- UNEG Norms and Standards (independence, credibility, utility)
- American Evaluation Association (AEA) Guiding Principles
**If a specific donor is named:**
- Verify TOR references the donor's evaluation policy
- Check terminology matches donor expectations
- Confirm required deliverables/registrations are mentioned
**Common donor frameworks:** EU (ROM standards, DAC criteria), FCDO (Theory of Change, Value for Money using 4 Es), UN agencies (UNEG norms, independence requirements). If the donor isn't named, default to OECD-DAC alignment.
### 9. Practical Readiness
- Available data sources listed (monitoring databases, prior reports, baseline data)
- Prior evaluations/reviews referenced
- Language requirements specified for multi-language contexts
- Stakeholder engagement plan (beyond being data sources)
- Use and dissemination plan (who receives findings, how used)
### 10. Internal Consistency
Cross-check alignment between sections:
- Scope vs. Budget: achievable within stated budget?
- Questions vs. Methodology: can proposed methods answer the questions?
- Timeline vs. Deliverables: enough time for quality production?
- Team vs. Methodology: team has expertise for proposed approach?
- Ethics vs. Scope: ethical provisions proportionate to populations and data involved?
Flag contradictions between sections. When a single section contains an internal contradiction (e.g., "baseline comparison" mentioned in scope but no baseline referenced in practical readiness), flag as a Critical issue if it affects feasibility, or Important if it creates ambiguity. Reference both conflicting statements explicitly. If reviewing a narrative description rather than the full document, note the contradiction but frame as "apparent contradiction. Verify in the actual document."
## Review Process
### Classify Document Type
Identify the document type before reviewing (see skill methodology for classification table). State the document type at the top of the review and calibrate expectations accordingly.
For commissioning briefs or drafts, note which sections are present and which need development. Don't simply fail every missing section.
For narrative descriptions, flag any sections where the description is silent as "not confirmed present" rather than "missing."
### Conduct 10-Section Review
Review in this sequence, scoring each section PASS / PARTIAL / FAIL:
1. **Completeness**: All 10 standard sections present?
2. **Evaluation Questions**: Map to DAC criteria? Answerable? Specific? Not too many?
3. **Methodology**: Methods match questions? Feasible? Budget supports approach?
4. **Ethics**: IRB, consent, do-no-harm, data protection, vulnerable populations?
5. **Team & LOE**: Qualifications specific? National expertise? LOE realistic?
6. **Timeline**: Adequate time per phase? Review cycles defined?
7. **Budget**: Ceiling provided? Inclusions/exclusions clear? Matches ambition?
8. **Standards Alignment**: Aligned with OECD-DAC, UNEG, and any named donor's evaluation standards?
9. **Practical Readiness**: Data sources listed? Prior evaluations referenced? Language needs? Dissemination plan?
10. **Internal Consistency**: Cross-check: scope vs. budget, questions vs. methodology, timeline vs. deliverables, team vs. methodology, ethics vs. scope?
### Classify Issues by Severity
For each finding, classify:
- **Critical (must fix):** Would make evaluation unethical, infeasible, or unable to answer its questions
- **Important (should fix):** Would significantly reduce quality or create implementation problems
- **Minor (nice to fix):** Best practice improvements that won't derail the evaluation
### Calculate Overall Rating
Based on section scores:
- **Strong:** 0 FAIL, max 1 PARTIAL
- **Adequate:** 0 FAIL, 2+ PARTIAL
- **Needs Revision:** 1 FAIL, or 3+ PARTIAL
- **Major Issues:** 2+ FAIL
## Output Format
Produce the structured review with summary table, strengths, classified issues with specific fixes, and detailed findings.
When recommending changes, provide specific language the user can insert, not just abstract advice.
## Output Format
```
## TOR Review Summary
**Document:** [Title/reference]
**Document Type:** [Full TOR / Commissioning Brief / SOW / RFP / Draft]
**Evaluation Type:** [Performance / Impact / Process / Formative / Other]
**Overall Rating:** [Strong / Adequate / Needs Revision / Major Issues]
### Section Scores
| Section | Rating | Key Finding |
|---------|--------|-------------|
| Completeness | [PASS/PARTIAL/FAIL] | [one-line summary] |
| Evaluation Questions | [PASS/PARTIAL/FAIL] | [one-line summary] |
| Methodology | [PASS/PARTIAL/FAIL] | [one-line summary] |
| Ethics | [PASS/PARTIAL/FAIL] | [one-line summary] |
| Team & LOE | [PASS/PARTIAL/FAIL] | [one-line summary] |
| Timeline | [PASS/PARTIAL/FAIL] | [one-line summary] |
| Budget | [PASS/PARTIAL/FAIL] | [one-line summary] |
| Standards Alignment | [PASS/PARTIAL/FAIL] | [one-line summary] |
| Practical Readiness | [PASS/PARTIAL/FAIL] | [one-line summary] |
| Internal Consistency | [PASS/PARTIAL/FAIL] | [one-line summary] |
### Strengths
- [What the TOR does well]
### Critical Issues (Must Fix)
1. [Issue, why it matters, specific fix]
### Important Issues (Should Fix)
1. [Issue, why it matters, specific fix]
### Minor Improvements
1. [Improvement: rationale]
### Detailed Findings
[Section-by-section analysis with specific references to TOR text]
```
## Notes
- A TOR is a commissioning document, not a methodology. It should set parameters, not prescribe every detail. Evaluators need room to propose their approach.
- Calibrate expectations to the document type. A commissioning brief is intentionally incomplete.
- Consider context: a $30K evaluation of a small project has different expectations than a $500K multi-country impact evaluation.
- If the TOR is generally strong, say so. Not every TOR needs major revision.
- **Post-hoc review:** If the evaluation is already underway or completed, reframe Critical/Important findings as lessons for future TOR development. Not required fixes.
- For program design review beyond the evaluation scope, use `/me-review:logframe-review`.
This is a portable verified skill: paste it into Claude Code, Claude Desktop, ChatGPT, or any agent that reads SKILL.md-style instructions. No plugin required.