A structured context folder (ICM format) that you load into an AI assistant to guide it in turning a working software project into a structurally complete NSF SBIR/STTR Project Pitch (four fields, within character limits, ASCII-safe for the portal), plus scaffolds for the supporting documents a full proposal needs.
Built for the kind of builder who has shipped something real and now has to convince NSF it is research, not a product.
NSF SBIR funds unsolved research, and pitches that read like "we built a tool" commonly get declined. The skill of relocating the research question underneath working code — and writing it inside NSF's unforgiving four fields — is non-obvious and easy to get wrong. Pitchwright encodes that skill so it is repeatable.
brief.md— the client brief this specialist was built to solve (read first).identity.md— who the specialist is and the belief that drives it.rules.md— the hard operating constraints (limits, framing, honesty, scope, process).examples.md— worked before/after reframes from a real pitch draft.workflow.md— the operator pipeline you run (Stages 0-10) that turns a project into a pitch.reference/— the knowledge base:01-nsf-pitch-fields-and-limits.md— the four fields, exact limits, process, deadlines, eligibility.02-framing-playbook.md— the Research-vs-Product test, the 8-point rubric, the measurement-science reframe.03-common-rejections.md— why pitches die, and the antidote to each.04-supporting-docs-map.md— the five full-proposal documents and what each must do.05-character-and-portal-checklist.md— counting, ASCII-safing, and paste discipline.
Feed the specialist this folder, then your project. It runs workflow.md — a 10-stage pipeline with a gate at each step. The pipeline starts with a four-question intake:
- The project — what did you build, and what works today (tests, demo, validation)?
- The hard part — what is genuinely unsolved? What could fail? What is unmeasured, undecidable, or uncalibrated?
- The buyer — who has urgent, mandated pain, and why now?
- The team — who's executing, and what's the honest gap?
Then it produces:
- The four pitch fields, each framed as research, each verified under its limit with a buffer.
- An ASCII-safe, paste-ready version.
- Scaffolds for the five supporting documents.
- A short list of off-page actions only you can do (named advisor, customer evidence, registrations).
Pitchwright is deliberately narrow: it produces one artifact (an NSF SBIR/STTR Project Pitch) for one kind of project (one with genuine R&D in it). Narrow beats broad — a specialist that does one thing well is worth more than a tool that does a whole profession vaguely.
That said, the reasoning engine underneath — reframing "we built a tool" into "here is the unsolved, measurable research question," then defending it honestly — transfers to any research-grant or R&D-justification context. NSF is the sharp implementation, not the ceiling. Strip every NSF reference out and the Stage 1-8 logic still teaches a builder to think like a researcher.
If your draft could be summarized as "we built X," it is not done. It is done when it reads as "here is the unsolved question, here is how we will measure whether we solved it, and here is the working evidence that the rest is feasible."
Pitchwright is built on researched NSF Project Pitch criteria — the four fields and their character limits, the review emphasis on research over productization, and the over- and under-scoping patterns applicants most commonly fall into — captured in the reference/ knowledge base and distilled from drafting a complete pitch package (the pitch plus five supporting documents) with that methodology. It shapes a pitch to those criteria; whether the pitch is invited is NSF's call. Reusable for any software project; not legal or financial advice, and not affiliated with NSF.