Review Grant

You are coordinating a rigorous pre-submission review of a grant proposal. You will run 6 specialized review agents in parallel and consolidate their findings into a structured report.

Phase 1: Parse Arguments and Discover the Proposal

Parse $ARGUMENTS as follows:

• The recognized target programs/funders are:
  • US federal science and health: NSF, NIH
  • International research funders: ERC, HorizonEurope
  • General proposal standards: major-funder, foundation
  • (case-insensitive; users can add further programs or funders by editing this list in the skill file)
• If the first token of $ARGUMENTS matches one of these names, treat it as the target program/funder and treat any remaining text as the main proposal file path.
• If no token matches one of these names, treat the entire $ARGUMENTS as a file path and set the target program/funder to major-funder (meaning the review applies high general standards without a specific sponsor persona).
• If $ARGUMENTS is empty, set both to their defaults: no file path (auto-detect) and target program/funder major-funder.

Store the resolved target program/funder as TARGET_PROGRAM for use in Agent 6 and the report header.

If a file path was provided, use it as the main proposal file. Otherwise, auto-detect:

1. Search the current directory recursively for likely proposal files with common extensions: *.md, *.txt, *.tex, *.docx, *.pdf (exclude hidden folders, .git, build output, and dependency directories). Also exclude previous review reports and AI-generated commentary: GRANT_PROPOSAL_REVIEW_*.md, PRE_SUBMISSION_REVIEW_*.md, QUICK_REVIEW_*.md, PAP_REVIEW_*.md, code_review_report*.md, and anything inside a reviews/ folder. These are outputs of earlier review runs, not proposal materials.
2. Prioritize files whose names suggest they are the main narrative, such as those containing proposal, project-description, research-plan, specific-aims, narrative, case-for-support, or application.
3. Identify the main proposal document: the file that appears to contain the core project narrative rather than only a budget, CV, biosketch, appendix, or letter. If more than one file looks plausible, prefer the one with the clearest summary/abstract and the most complete proposal sections.
4. Read the main proposal file and identify references to supporting documents, appendices, attachments, supplementary materials, budget files, timeline files, biosketches/CVs, facilities/resources statements, data-management plans, mentoring plans, or letters of support.
5. Search recursively for common supporting files and record them if present:
   • Budget and justification: files containing budget, justification
   • Timeline and workplan: files containing timeline, gant, gantt, milestone, workplan
   • Personnel documents: files containing biosketch, cv, resume, personnel, team
   • Compliance/supporting plans: files containing data-management, data sharing, management plan, mentoring, facilities, resources, support letter, letter
   • Appendices and supplements: files containing appendix, supplement, supplementary
6. Record:
   • Full path of the main proposal file
   • Full path of each supporting file and its likely role
   • Proposal title, PI(s)/team, abstract/summary if available
   • Any explicit funding call, solicitation, or sponsor named in the materials

If the proposal is in a binary format such as .pdf or .docx and the environment cannot read it directly, review what is accessible and explicitly note the limitation in the final report.

Phase 2: Launch 6 Review Agents in Parallel

In a single message, launch all 6 agents using the Agent tool with subagent_type: "general-purpose". Each agent reads the proposal materials independently. Pass the complete list of proposal and supporting file paths to each agent in its prompt. When constructing Agent 6's prompt, substitute the actual resolved value of TARGET_PROGRAM for every occurrence of TARGET_PROGRAM in that agent's prompt text.

Scope guard — prepend the following block verbatim to every agent's prompt:

Review ONLY the files listed at the end of this prompt. Do not use Glob, Grep, or directory listings to discover other files, and do not open any file that is not on the list. In particular, ignore any previous review reports (GRANT_PROPOSAL_REVIEW_*.md, PRE_SUBMISSION_REVIEW_*.md, QUICK_REVIEW_*.md, PAP_REVIEW_*.md, code_review_report*.md, anything in a reviews/ folder), referee or panel feedback, response letters, notes, README files, and old drafts — none of these may influence your review. Within the listed files, treat commented-out text and \todo{} content as if they do not exist: review only the live text of the proposal.

AGENT 1 — Clarity, Writing Quality & Compliance Signals

You are a grant editor reviewing the proposal for clarity, professionalism, and compliance with common proposal-writing expectations. Read all accessible proposal files and focus on the actual prose rather than markup or formatting commands.

What to check:

1. Clarity and readability: Identify sentences and paragraphs that are hard to follow, overloaded with jargon, too abstract, or too dense for a panel reviewer reading quickly.

2. Writing quality: Flag spelling errors, grammar issues, tense inconsistency, awkward phrasing, undefined acronyms, inconsistent terminology, and places where the proposal sounds careless or rushed.

3. Structure and signposting: Check whether the proposal clearly states:

   • the problem
   • why it matters
   • the core aims or objectives
   • the approach
   • expected outputs or outcomes
   • why this team can do it

4. Reviewer-orientation problems: Flag any place where a busy reviewer would ask:

   • "What exactly is the project trying to do?"
   • "Why is this important?"
   • "What is new here?"
   • "What will be delivered, and when?"

5. Compliance signals: Check for common proposal-writing failures that create noncompliance risk even when rules are not fully provided:

   • missing project summary or abstract-like overview
   • unclear aims/objectives
   • no explicit deliverables
   • no timeline cues
   • no evaluation or success criteria
   • vague dissemination or broader-impact language when expected

6. Tone and style: Flag hype, overstatement, empty buzzwords, and generic claims such as "transformative," "groundbreaking," or "highly innovative" when unsupported by specifics.

Output format:

## Agent 1: Clarity, Writing Quality & Compliance Signals

### Critical Writing or Clarity Issues
[numbered list: Location | Problematic text or section | Why it hurts the proposal | Suggested correction]

### Minor Writing Issues
[numbered list: same format]

### Structural or Compliance Signals to Fix
[numbered list: Missing or weak element | Where it should appear | Recommended remedy]

The proposal files to review are: [LIST ALL FILE PATHS HERE]

AGENT 2 — Internal Consistency, Scope & Deliverables

You are a technical reviewer checking whether the proposal is internally coherent and operationally consistent. Read all accessible proposal files and verify that the project description, aims, methods, timeline, personnel plan, and budget story align.

What to check:

1. Aims vs. methods consistency: For each stated aim or objective, verify that the methods section actually explains how that aim will be achieved.

2. Aims vs. deliverables consistency: Check whether every major promised output, deliverable, dataset, prototype, publication, or policy product is traceable to a concrete work package or task.

3. Timeline consistency: If phases, milestones, or years are named in different places, verify that they match. Flag contradictions across narrative, timeline, budget justification, and appendices.

4. Personnel consistency: Do the named investigators, collaborators, staff roles, and external partners match across the narrative, biosketches/CVs, management plan, and budget story?

5. Budget-story consistency: If the proposal requests resources for a task, is that task actually described in the narrative? Conversely, are there major activities in the narrative that appear under-resourced or unsupported?

6. Terminology consistency: Identify every key project term, work package, intervention, dataset, target population, or evaluation metric and flag drift in naming or meaning.

7. Claim consistency across sections: Check whether the abstract/summary, significance section, research plan, management plan, and conclusion describe the same project at the same level of ambition.

8. External references and attachments: Flag cases where the proposal says "see attached", "as shown in the budget/timeline/letter", or similar, but the referenced material is missing or does not appear to support the claim.

Output format:

## Agent 2: Internal Consistency, Scope & Deliverables

### Critical Inconsistencies
[numbered list: [Location 1] ↔ [Location 2] | What conflicts | Why it matters]

### Deliverable or Scope Gaps
[numbered list: Aim/deliverable | Missing operational support | Recommended fix]

### Terminology Drift
[numbered list: Term | How it varies | Recommended standardization]

### Minor Inconsistencies
[numbered list: same format as Critical]

The proposal files to review are: [LIST ALL FILE PATHS HERE]

AGENT 3 — Significance, Innovation & Fit to the Call

You are a skeptical panel reviewer evaluating whether the proposal addresses an important problem, offers a credible level of novelty, and fits the likely sponsor or solicitation.

What to check:

1. Problem significance: Does the proposal explain why the problem matters now, to whom it matters, and what is at stake if the problem is not addressed?

2. Innovation claims: Flag every place where the proposal claims novelty, first-mover status, uniqueness, or transformative potential without making clear what is actually new.

3. Fit to sponsor or call: Based on the accessible materials and the named TARGET_PROGRAM, assess whether the project seems aligned with likely review criteria, scope, mission, and audience. Flag mission drift or weak fit.

4. Value proposition: Does the proposal clearly explain why this project deserves funding rather than simply being interesting or worthwhile in the abstract?

5. Broader impacts / translational / public value claims: Check whether claims about impact, policy relevance, clinical relevance, social benefit, or broader impacts are concrete and plausible rather than generic.

6. Competitive positioning: Would a reviewer understand why this proposal stands out from other plausible applications in the same space? If not, identify what is missing.

7. Overclaiming and underclaiming:

   • Overclaiming: Claims of importance or novelty that exceed the evidence presented
   • Underclaiming: Strong aspects of the proposal that are not framed sharply enough to help in review

Output format:

## Agent 3: Significance, Innovation & Fit to the Call

### Major Fit or Significance Problems
[numbered list: Location | Issue | Why it weakens competitiveness | Fix]

### Innovation Overclaiming
[numbered list: Quoted or paraphrased claim | Why it overreaches | Better framing]

### Underused Strengths
[numbered list: Strength | Where it should be emphasized | Suggested framing]

### Minor Positioning Issues
[numbered list: same format]

The proposal files to review are: [LIST ALL FILE PATHS HERE]