Content
78%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
Highly actionable content with concrete, flag-level commands and domain knowledge Claude genuinely lacks, organized into a clear five-step workflow. The main weaknesses are duplicated boundary/purpose text across sections and a progressive-disclosure chain that is broken in practice: the body points to scripts, references, and an assets template that are not present in the bundle.
Suggestions
Ship the referenced bundle files (scripts/program_budget_planner.py, burn_runway_tracker.py, capex_vs_opex_router.py, the three references/*.md canon docs, and assets/rd_program_budget_template.md) or remove/deweight the paths so no reference in the body dangles.
Deduplicate the boundary content: the intro paragraph, '## Purpose', and '## Distinct from' table all restate the finance/financial-analysis and research/grants distinctions already in the description — keep one (the table) and trim the rest.
Move the five-question 'Forcing-question library' (with its per-question canon citations) into a reference file linked from a short section, keeping SKILL.md as a lean overview.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly dense, domain-specific guidance Claude would not already know (MTDC-exempt categories, trailing vs lifetime-average burn, NICRA confirmation), e.g. 'Applying F&A to the full base. Capital equipment, large subaward portions, and certain categories are MTDC-exempt.' But there is noticeable duplication: the intro paragraph and '## Distinct from' table both restate the description's boundary content, and '## Purpose' overlaps '## When to use' — matching the 4 anchor (minor over-explanation that could be trimmed) rather than 5, where every token would earn its place. | 4 / 5 |
Actionability | Fully executable, copy-paste-ready commands with real flags cover the common cases: 'program_budget_planner.py --input program.json --profile {pharma-rd|biotech|medtech|deep-tech|software-rd|university-lab} --fa-rate <negotiated rate>', 'burn_runway_tracker.py --input ledger.json --threshold-months 6', 'capex_vs_opex_router.py --sample --standard ifrs', plus onboarding ('python3 scripts/onboard.py --show') and the sample invocations in '## Quick examples'. Matches the 5 anchor; not 4 because the --sample runs alone give a working end-to-end demonstration without user-supplied inputs. | 5 / 5 |
Workflow Clarity | The five-step workflow (lay out program → build budget → track burn/runway → route treatment → assemble review) gives a concrete command and expected output for each step, and the closing 'Walk depth-first. Lock 1-2 before opening 3-5' adds sequencing discipline. Validation is only implicit ('warns you to confirm it is a negotiated NICRA, not a guess' in Assumptions) — no explicit checkpoints or error-recovery loops inside the workflow, which fits the 4 anchor (clear sequence, minor validation gaps) rather than 5. The destructive/batch cap of 3 does not apply since this is non-destructive analysis. | 4 / 5 |
Progressive Disclosure | The in-document structure is good and references are clearly signaled one level deep ('references/rd_program_finance_canon.md — IAS 38 (research vs development); ASC 730 + ASC 985-20...'), but scoring against the actual bundle: no references/, scripts/, or assets/ directories exist, so every referenced path — the three scripts, three reference docs, and assets/rd_program_budget_template.md — is dangling and unverifiable. Combined with inline content that belongs in reference files (the five-question 'Forcing-question library' with canon citations), this fits the 3 anchor (some structure, but organization compromised) better than 4, where references would mostly resolve. | 3 / 5 |
Total | 16 / 20 Passed |