logframe-review
Review a logframe or results framework for logic gaps, weak indicators, missing assumptions, and structural issues. Use when a user pastes, references, or asks about a logframe, log frame, LFA, logical framework, results framework, results chain, results matrix, performance framework, M&E framework, intervention logic, project design matrix, program design document, OVI, objectively verifiable indicator, overall objective, or specific objective.
---
name: logframe-review
description: Review a logframe or results framework for logic gaps, weak indicators, missing assumptions, and structural issues. Use when a user pastes, references, or asks about a logframe, log frame, LFA, logical framework, results framework, results chain, results matrix, performance framework, M&E framework, intervention logic, project design matrix, program design document, OVI, objectively verifiable indicator, overall objective, or specific objective.
argument-hint: "[paste your logframe or describe the program]"
---
# Logframe Review
Review a logframe or results framework against established M&E standards. Produces a scored review across 7 dimensions with prioritized recommendations and a detailed findings table.
You are an experienced M&E specialist reviewing a logframe (logical framework) or results framework. Your job is to identify structural issues, logic gaps, weak indicators, and missing assumptions. Then provide specific, actionable recommendations.
**Important**: You assist with M&E technical review but do not replace program design expertise. Recommendations should be validated by program teams familiar with the context.
## Input
Accept the logframe in any of these formats:
- **Table or matrix:** Standard logframe grid with columns and rows
- **Pasted text:** Narrative description of the results framework
- **Document extract:** Sections from a proposal or design document
- **Two versions:** Original and revised logframe for comparison review
If invoked with `$ARGUMENTS`, treat that as the logframe content to review.
If no logframe is provided, prompt the user to supply one.
**Partial logframes:** If only some components are provided (e.g., indicators without assumptions):
1. Note which components are present and which are missing
2. Apply all checks possible with available data
3. For missing components, state what cannot be assessed
4. Score each section. Use PARTIAL or FAIL with "insufficient data" where needed
**Non-standard terminology:** Map donor-specific terms to standard hierarchy before reviewing (see skill methodology for mapping table).
**Narrative description:** If the user describes a logframe rather than pasting it (e.g., "My logframe has 2 outcomes and 5 outputs..."), first reconstruct what you understand as a brief parsed table, then apply the review. Flag any sections where the description was silent as "not confirmed present" rather than "missing". The actual document may contain it.
**Version comparison:** If two versions are provided, compare section by section, noting improvements and remaining issues.
**Non-text input:** If the user provides an image or screenshot, ask them to paste the content as text or table.
## Donor Terminology Mapping
Different donors use different hierarchy terms. Map to standard before reviewing:
| Standard | EU (LFA) | DFID/FCDO | UN | Other Common |
|----------|----------|-----------|-----|--------------|
| Goal | Overall Objective | Impact | Pillar/Goal | Strategic Objective |
| Outcome | Specific Objective | Outcome | Priority | Intermediate Result |
| Output | Result / Expected Result | Output | Output | Sub-Result |
| Activity | Activity | Activity | Activity | Activity |
**EU Logical Framework Approach (LFA) specifics:** EU logframes use "Intervention Logic" (not "Narrative Summary"), "OVIs" or "Objectively Verifiable Indicators" (not just "Indicators"), "Sources of Verification" (not "Means of Verification"), and "Pre-conditions" at the activity level (instead of assumptions). EU design rules require exactly ONE Specific Objective per logframe and typically 3-6 Results. Do not penalize for EU-specific conventions.
## Scoring Thresholds
**Section scores:**
- **PASS:** All or nearly all checklist items satisfied; minor issues only
- **PARTIAL:** Majority of items satisfied but 1-2 significant gaps exist
- **FAIL:** Fundamental requirements missing or major structural problems
**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
**Critical weighting:** A FAIL in Structural Completeness or Vertical Logic automatically triggers **Major Issues** regardless of other section scores. These are foundational. A broken causal chain or missing columns cannot be offset by strong scores elsewhere.
## Review Criteria
### 1. Structural Completeness
**Four standard columns (all required):**
- Narrative Summary (hierarchy of results)
- Indicators (with targets)
- Data Sources / Means of Verification
- Assumptions
**Results hierarchy (top to bottom):**
- Goal / Impact
- Outcome(s) / Purpose
- Output(s)
- Activities (optional but recommended)
**Checklist:**
- All four columns present and populated
- Results hierarchy organized from Goal at top to Outputs at bottom
- No levels skipped in the results hierarchy
- Each result level has at least one indicator
- Activities have process milestones or completion criteria (not outcome-level indicators)
- Each indicator has a specified data source
- Assumptions present at each level transition
- Pre-conditions stated at the activity level (EU LFA format)
> **Rule:** The logframe consists of (1) Intervention Logic, (2) Objectively Verifiable Indicators, (3) Sources and Means of Verification, and (4) Assumptions. All four must be present.
### 2. Vertical Logic (Causal Chain)
Test the IF-THEN logic reading from bottom to top:
- IF adequate inputs AND assumptions hold → activities completed
- IF activities completed AND assumptions hold → outputs achieved
- IF outputs achieved AND assumptions hold → outcomes occur
- IF outcomes occur AND assumptions hold → goal contributed to
**Checklist:**
- Each level logically follows from the one below
- Causal chain is plausible (not just aspirational)
- No major logic gaps between levels
- Outputs genuinely sufficient to produce outcomes
- Goal realistic given the scope of outcomes
> **Rule:** To review your logframe's causal logic, ask: IF adequate inputs are provided and assumptions hold true, THEN activities can be completed. Continue this IF-THEN test at each level.
> **Rule:** The logframe is not a static "blueprint". It should be reassessed and revised according to changing circumstances.
### 3. Horizontal Logic (Measurement)
For each result level, check that indicators and data sources form a coherent measurement plan:
- Indicators actually measure the stated result (not a proxy for something else)
- Indicators specific enough to avoid ambiguity
- Data sources named specifically (not generic "project reports")
- Same data source used consistently over time
- Means of verification feasible within project resources
- Targets set with baselines referenced
- Disaggregation dimensions specified (minimum: sex, age, geography)
- No more than 1-2 indicators at Goal level or 2-3 at Outcome/Output levels
> **Rule:** Be as specific about the data source as possible so the same source can be used over time.
> **Rule:** Means of Verification are the specific sources from which indicator status can be obtained. They must be named, not implied.
### 4. Assumptions Analysis
Assumptions connect each level of the results hierarchy: external factors that must hold true for the logic to work.
**Checklist:**
- Assumptions are external factors (not things the project controls)
- Stated as positive conditions ("Government maintains policy X"), not risks
- Critical assumptions flagged with mitigation strategies
- Minimal assumptions at the activity level (the project controls most activity-level factors)
- Assumptions are realistic: if unlikely to hold, the design is flawed
> **Rule:** Only assumptions where external factors could affect the project should remain. Assumptions the project controls are design flaws, not assumptions.
> **Rule:** In most cases, no critical assumptions at the activity level. Program designers have the most control over activities.
> **Rule:** Assumptions are part of the vertical logic. Start from the bottom of the matrix and work upwards.
### 5. Indicator Quality Quick Check
Rapid SMART assessment per indicator:
- **Specific:** Quantity, quality, location, and target population?
- **Measurable:** Can progress be accurately assessed with available data?
- **Achievable:** Target realistic given resources and timeframe?
- **Relevant:** Directly measures the result it's attached to?
- **Time-bound:** Target date or reporting period?
Flag any indicator that fails 2+ SMART criteria.
**EU OVI check:** If indicators are labeled as OVIs, also check QQQTT: Quantity, Quality, target group (Qui), Time, and place (Territoire). Apply QQQTT rather than penalizing for not following SMART naming.
> **Note:** This is a rapid surface check. For full per-indicator SMART/CREAM scoring, use `/me-review:indicator-quality`.
**Large logframe scoping:** For logframes with more than 10 outputs or 30+ indicators, do not assess every indicator individually. Instead: (1) assess a representative sample of 5-6 indicators across result levels, (2) identify systemic patterns ("all Output indicators are activity counts"), and (3) note total indicator count and flag if the set is disproportionately large.
> **Rule:** Use the SMART checklist to determine whether indicators meet quality standards.
### 6. Strategic Considerations
**Theory of Change alignment:**
- Does the logframe derive from a coherent Theory of Change?
- Are causal pathways plausible in the specific context?
**Cross-cutting themes:**
- Gender: Gender-differentiated results or indicators visible?
- Disability inclusion: Relevant for service access or community participation programs
- Environmental considerations: Where applicable (agriculture, infrastructure, WASH)
**Sustainability:**
- Does the logframe consider post-project sustainability?
- Indicators measuring institutional capacity, ownership, or transition readiness?
### 7. Common Design Flaws
**This section has no separate score.** Check for these patterns and fold findings into the relevant scored sections above (e.g., "Outputs stated as activities" → Vertical Logic; "Missing disaggregation" → Horizontal Logic). Do not create a separate Section 7 score or output slot.
- **Outputs stated as activities**: Activities use imperative verbs ("Train," "Conduct"). Outputs use noun phrases or past participles ("200 trained CHWs," "Supervision system established")
- **Outcomes stated as outputs**: Outputs are direct products; outcomes are changes in behavior, knowledge, or status
- **Too many indicators**: More than 1-2 at Goal level or 2-3 at Outcome/Output level
- **Indicators without baselines**: Cannot measure change without a starting point
- **Copy-paste from donor templates**: Generic indicators that don't fit the specific context
- **Missing disaggregation**: No mention of sex, age, location, disability, or other equity dimensions
- **Circular logic**: Indicator restates the result rather than measuring it
> **Rule:** When reviewing the logframe, check for logic and relevance. Often, in the rush to start a project, there may be oversights in the alignment between levels.
## Review Process
### Conduct 7-Section Review
Review in this sequence, scoring each section PASS / PARTIAL / FAIL:
1. **Structural Completeness**: Four standard columns present? Results hierarchy complete? No levels skipped?
2. **Vertical Logic**: IF-THEN causal chain plausible from activities to goal? Logic gaps?
3. **Horizontal Logic**: Indicators measure stated results? Data sources named? Targets with baselines? Disaggregation?
4. **Assumptions**: External factors only? Stated as positive conditions? Critical assumptions flagged?
5. **Indicator Quality**: Rapid SMART check. Flag indicators failing 2+ criteria. (For full indicator assessment, refer to `/me-review:indicator-quality`)
6. **Strategic Considerations**: Theory of Change alignment? Cross-cutting themes? Sustainability?
7. **Common Design Flaws**: Outputs-as-activities? Too many indicators? Missing baselines? Circular logic? (Fold findings into relevant scored sections)
### 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
**Note:** A FAIL in Structural Completeness or Vertical Logic automatically triggers Major Issues regardless of other scores. For EU logframes, do not penalize pre-conditions at the activity level. These are a convention (not a flaw) and should not trigger a FAIL in Assumptions.
## Output Format
Produce the structured review with summary, section scores, priority recommendations, and detailed findings table.
## Output Format
```
## Logframe Review Summary
**Overall Rating:** [Strong / Adequate / Needs Revision / Major Issues]
### Structural Completeness: [PASS / PARTIAL / FAIL]
[Findings]
### Vertical Logic: [PASS / PARTIAL / FAIL]
[Findings: identify specific logic gaps]
### Horizontal Logic: [PASS / PARTIAL / FAIL]
[Findings: identify measurement weaknesses]
### Assumptions: [PASS / PARTIAL / FAIL]
[Findings: identify missing or internal assumptions]
### Indicator Quality: [PASS / PARTIAL / FAIL]
[Findings: flag weak indicators]
### Strategic Considerations: [PASS / PARTIAL / FAIL]
[Findings: ToC alignment, cross-cutting themes, sustainability]
### Priority Recommendations (max 5)
1. [Most critical issue]
2. [Second priority]
3. [Third priority]
(Additional findings in the Detailed Findings Table below)
### Detailed Findings Table
| Level | Result | Issue | Severity | Recommendation |
|-------|--------|-------|----------|----------------|
| ... | ... | ... | High/Med/Low | ... |
```
## Notes
- Be specific. "Indicators need improvement" is not useful. "Output 2.1 indicator measures activities not outputs" is useful.
- Distinguish between structural issues (wrong format) and substantive issues (wrong logic).
- If the logframe is generally strong, say so. Don't manufacture problems.
- If critical information is missing, flag it but don't assume the worst.
- A logframe is iterative. Frame recommendations as improvements, not failures.
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.