proposal-revise
Skill479 starsChanged 22 days agoMITView on GitHub
Apply reviewer or collaborator feedback to an existing proposal while maintaining its voice and project context.
In this repository21 other files it gives its agents.
- aniket-meSkill
- announcement-digestSkill
- checkinSkill
- deep-researchSkill
- dr-synthesizeSkill
- goals-reviewSkill
- morning-briefSkill
- post-meetingSkill
- pre-meeting-briefSkill
- proposal-writeSkill
- schedule-querySkill
- setup-project-managementSkill
- tax-guideSkill
- tips-curateSkill
- tips-integrateSkill
- tips-scoutSkill
- todo-addSkill
- todo-queueSkill
- todo-reviewSkill
- triage-inboxSkill
- weekly-reviewSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. About 0 are common, 19 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈19
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
If you maintain a voice pack:
- Distinctive: line 29
If not found, the skill warns and continues with general academic voice rules.
- Distinctive: line 35
Look for the draft in this order:
- Distinctive: line 38
If not found: "Usage: /proposal-revise <draft-path> [feedback]"
- Distinctive: line 40
Read the full draft. Parse the revision notes section (if present) to understand what inputs were used, what's already been addressed, and …
- Distinctive: line 46
After finding the draft, identify the funder (from draft filename, header, or content):
- Very specific: line 48
Check for a donor profile at ~/.claude-assistant/donors/[funder-slug].md
- Distinctive: line 49
If found: Read it. Display "What They Value" and "What to Avoid" to the user.
- Very specific: line 65
Comments file (
comments:path): Read the file. Accept any format — numbered list, free-form notes, bullet points, section annotations. - Very specific: line 67
Formal reviewer comments (
reviewer:path): Read the file and categorize each comment: - Distinctive: line 89
Funder conflict flagging: When processing any feedback (inline, file, or reviewer), if a suggestion conflicts with the donor profile's …
- Distinctive: line 105
No throat-clearing or hedging without reason
- Distinctive: line 110
Don't rewrite sections that aren't commented on (no scope creep)
- Distinctive: line 111
If a comment requires new content, write it in voice
- Distinctive: line 112
If a comment contradicts the voice pack (e.g., "add more hedging"), follow the comment but flag it
- Distinctive: line 113
If filling a PLACEHOLDER, remove the marker and replace with real content
- Distinctive: line 114
If a comment is ambiguous, make your best interpretation and note it in the change summary
- Very specific: line 118
Backup first: Before overwriting, copy the current draft to [filename].bak.
- Distinctive: line 180
If draft not found: Check the default draft directory for alternatives, suggest closest match
- Distinctive: line 181
If voice pack not found: Continue with general voice rules
- Distinctive: line 182
If feedback is empty: Ask user to clarify
- Distinctive: line 183
If draft has no revision notes: Create from scratch
- Distinctive: line 184
If donor profile not found: Continue without funder-conflict flagging
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Revise Proposal
v2.4 — Renamed from revise-proposal; noun-first grouping. Adds donor profile lookup and funder-conflict flagging during revision. v2.x — Reviewer-comment categorization, voice-pack enforcement, automatic backup before save
Apply reviewer, collaborator, or self-review comments to an existing proposal draft while maintaining voice consistency. Use when applying feedback to a proposal draft.
Overview
This skill takes an existing proposal draft and feedback (dictated, typed, or from a file), applies the changes, and outputs an updated draft with a change summary. Designed for iterative revision — by you, collaborators, or co-PIs.
The key value is the collaborator handoff: A team member reads the draft, dictates or types all their feedback in one pass, and Claude extracts the actionable items and applies them. No one has to edit markdown directly.
Pre-approved tools: Google Workspace MCP and filesystem reads. Call them directly — no Task agents.
Voice Pack (Optional)
If you maintain a voice pack:
@~/.claude-assistant/voice/PROPOSAL_VOICE.md
@~/.claude-assistant/voice/PROPOSAL_EXAMPLES.mdIf not found, the skill warns and continues with general academic voice rules.
Instructions
Step 1: Find the Draft
Look for the draft in this order:
- Path provided in
$ARGUMENTS(first positional argument) - Most recent
*_Draft.mdin05_Submissions/Grants/— confirm with user: "Found [filename]. Use this? [Y/n]" - If not found: "Usage: /proposal-revise
<draft-path>[feedback]"
Read the full draft. Parse the revision notes section (if present) to understand what inputs were used, what's already been addressed, and what placeholders remain.
Also read .claude/CLAUDE.md for project config.
Step 1.5: Donor Profile Lookup
After finding the draft, identify the funder (from draft filename, header, or content):
- Check for a donor profile at
~/.claude-assistant/donors/[funder-slug].md - If found: Read it. Display "What They Value" and "What to Avoid" to the user. These inform revision decisions — especially when feedback conflicts with funder priorities.
- If not found: Note: "No donor profile for [funder]. Proceeding without funder-specific guidance."
Step 2: Collect Feedback
Feedback can come from any combination of these sources:
Inline (dictated/typed). The user provides comments directly after the command or in conversation. Dictated comments may be conversational — extract the actionable feedback. This is the most common workflow.
Example:
/proposal-revise 05_Submissions/Grants/Draft.md
Tighten the intro. The power calc section needs the new numbers.
Cut 200 words from methodology. Budget section needs cost-per-unit breakdowns.Comments file (comments:path). Read the file. Accept any format — numbered list, free-form notes, bullet points, section annotations.
Formal reviewer comments (reviewer:path). Read the file and categorize each comment:
- MUST ADDRESS — factual errors, missing required content, fundamental concerns
- SHOULD ADDRESS — suggestions that improve the proposal
- CONSIDER — stylistic preferences or minor points
- DISAGREE — note the disagreement and reason; flag for user decision
Show the categorization and wait for confirmation before applying:
Reviewer Comment Analysis:
MUST ADDRESS (N):
1. [Comment] → Plan: [how to address]
SHOULD ADDRESS (N):
1. [Comment] → Plan: [how to address]
DISAGREE (N):
1. [Comment] → Reason: [why]
Proceed? [Y/n/edit]Funder conflict flagging: When processing any feedback (inline, file, or reviewer), if a suggestion conflicts with the donor profile's "What They Value" or "What to Avoid," flag it:
"Note: This suggestion may conflict with [funder]'s preference for [X from donor profile]. Applying as requested, but flagging for review."
Note: The categorization and confirmation gate apply ONLY to formal reviewer comments (reviewer:path). For inline feedback and comments files, proceed directly to revisions.
Step 3: Apply Revisions
For each piece of feedback:
- Locate the relevant section
- Revise the text to address the comment
- Maintain voice — every revision follows the voice pack:
- Short sentences, active voice
- Numbers over adjectives
- Claims-first topic sentences
- No throat-clearing or hedging without reason
- Preserve structure — don't reorganize sections unless asked
- Track changes — keep a running list of what changed and why
Rules:
- Don't rewrite sections that aren't commented on (no scope creep)
- If a comment requires new content, write it in voice
- If a comment contradicts the voice pack (e.g., "add more hedging"), follow the comment but flag it
- If filling a PLACEHOLDER, remove the marker and replace with real content
- If a comment is ambiguous, make your best interpretation and note it in the change summary
Step 4: Backup, Save, and Report
Backup first. Before overwriting, copy the current draft to [filename].bak.
Save the updated draft to the same path. Update the revision notes:
---
## Revision Notes
**Draft created:** [original date]
**Last revised:** [today] by `/proposal-revise`
**Revision round:** [increment]
**Changes this round:**
- [Brief list of major changes]
**Funder conflicts flagged:**
- [Any suggestions that conflicted with the donor profile, with notes]
**Gaps / placeholders:**
- [Updated list]Report:
Draft updated: [filepath]
Backup saved: [filepath].bak
Changes made:
1. Section [X]: [What changed] — Reason: [comment ref]
...
Word count: [before] -> [after] ([+/- change])
Funder conflicts flagged: [count, if any]
Next steps:
1. Review changes in the draft
2. [If placeholders remain] Fill in: [list]
3. Run /review-writing for voice consistency checkArguments
$ARGUMENTS:
- Draft file path (first positional argument)
comments:path— file with commentsreviewer:path— formal reviewer comments (triggers categorization)nodiff— skip the change summary
Examples
# Self-review
/proposal-revise 05_Submissions/Grants/Draft.md
Tighten the intro. Cut 200 words from methodology.
# Collaborator feedback from file
/proposal-revise Draft.md comments:~/Downloads/feedback.txt
# Formal reviewer comments
/proposal-revise Draft.md reviewer:~/Downloads/reviews.pdfError Handling
- If draft not found: Check the default draft directory for alternatives, suggest closest match
- If voice pack not found: Continue with general voice rules
- If feedback is empty: Ask user to clarify
- If draft has no revision notes: Create from scratch
- If donor profile not found: Continue without funder-conflict flagging
Customization Points
To set up this skill for your workflow:
- Voice pack location: The
@~/.claude-assistant/voice/references point to writing style files. Create your own voice pack with sentence length preferences, hedging rules, and formatting conventions, or remove these lines to use general academic voice. - Default draft directory (Step 1): The default search path
05_Submissions/Grants/is one folder naming convention. Change this to match your own proposal directory — e.g.,~/Research/Proposals/or~/Grants/Active/. - Donor profiles (Step 1.5): The
~/.claude-assistant/donors/directory is optional. If you maintain funder profiles, update the path to match your structure. If not, the skill continues without funder-specific guidance. - Example paths in the Examples section also reference the default draft directory — update them to match your own structure.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

