/review-grant

name: review-grant
description: Run a 6-agent pre-submission panel review for a grant proposal targeting a specified funder or program

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). 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.

---

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 for