Review competition proposals

Review competition plans and proposals

Purpose

Audit a draft as an independent reviewer, then convert findings into evidence-backed revisions. Protect official form compliance and factual honesty before improving style.

Boundary

Own:

• compliance, rubric coverage, argument, evidence, causality, differentiation, execution, risks, writing, visuals, and final-file QA;
• claim-to-source verification and implementation-state consistency;
• section-level keep, revise, move, delete, or add decisions;
• prioritized revision map and selected rewrites when requested;
• comparison between versions and change reasons.

Do not:

• silently invent missing facts, results, partners, budgets, or performance;
• rewrite the whole document when the user asked only for diagnosis;
• treat a mechanical checker as a quality verdict;
• predict award probability;
• use GO, CONDITIONAL GO, or NO-GO labels.

If no draft exists, use $plan-competition-ideas. If requirements are unknown, use $analyze-competition-deeply first.

Choose the review mode

• Diagnostic: identify strengths, decisive weaknesses, evidence gaps, and revision priorities.
• Rubric audit: map every official criterion to draft evidence and score only against official weights.
• Evidence audit: verify material claims, numbers, citations, status, and causal reach.
• Structure edit: redesign form fields, page logic, paragraph flow, and visuals.
• Rewrite: revise only requested sections after the audit.
• Submission audit: inspect requirements, privacy, rights, consistency, links, rendering, and final files without adding ideas.
• Version comparison: show what changed, why, evidence gained/lost, and residual risk.

Use the smallest mode that satisfies the request.

Start with a blind pass

Before editing, identify 2–3 overlooked issues likely to dominate the result: an official-form omission, evidence that does not support the claim, an untested causal step, a partner or data dependency, unsafe automation, or a rendering problem.

If essential material is missing, ask at most three concise questions. Otherwise state the missing material and continue with a bounded review.

Required workflow

1. Freeze the review baseline

Record draft filename/version/date and collect:

• official notice, rubric, FAQ, and fixed form;
• idea-plan handoff and decision log if available;
• cited sources and raw analysis;
• prototype, code, screenshots, tests, and implementation-state list;
• team, schedule, budget, partner, and submission information.

Never mix content from older drafts without identifying the source version.

2. Lock official compliance

Compare the draft against official requirements before judging prose:

• eligibility and team information;
• headings and order;
• page, byte, character, and file limits;
• required checkboxes, signatures, attachments, links, and demonstrations;
• anonymity, 개인정보, copyright, portrait, licenses, duplicate awards, and conflicts;
• filename, channel, deadline, timezone, and post-selection obligations.

Classify each item as confirmed compliant, missing, conflict, cannot verify, or organizer confirmation required. A likely disqualifier is a submission blocker, not merely a style issue.

3. Reconstruct the argument

Write the draft's actual chain without improving it:

target/situation → problem → cause/current gap → intervention → direct output → behavior/operation change → outcome → measurement

Flag missing, circular, or unsupported arrows. Distinguish a clear story from a proven mechanism.

4. Audit claims and sources

Use references/review-protocol.md. For every material claim record:

• exact draft claim;
• evidence status;
• cited source and original passage or data;
• whether the source directly supports the scope, unit, date, population, and causality;
• limitation and safe wording;
• keep, qualify, replace, verify, or delete.

Do not accept a citation merely because it is present. A broad statistic cannot prove a narrow user behavior. An association cannot prove causality. A vendor page cannot prove independent performance.

5. Audit implementation truth

Separate:

• operating or piloted;
• tested prototype;
• partial implementation;
• reproducible analysis;
• interactive mock-up;
• static design;
• planned integration;
• future roadmap.

Check document, screens, code, links, and tests for agreement. Do not call API discovery integration or mock-ups implementation.

6. Audit rubric and form coverage

For every official criterion provide:

• draft location;
• claim made;
• evidence strength;
• likely reviewer objection;
• revision and reason;
• space or visual needed.

Use official weights only. If a diagnostic score is useful, label it as current evidence coverage, not an official prediction. Never derive award probability.

7. Run independent red-team passes

Use these lenses as relevant:

• contest/organizer and policy fit;
• user/customer/beneficiary;
• data, research, and evidence;
• technology, AI, accessibility, privacy, and safety;
• operation, budget, adoption, maintenance, and business;
• editing, visual hierarchy, and first-read comprehension.

Each lens must state:

strongest objection → supporting evidence → consequence → minimum revision → residual risk

8. Build a prioritized revision map

Use four levels:

• 제출 차단: official omission, unverifiable requirement, rights/privacy issue, broken file, or material falsehood;
• 중대 수정: problem-mechanism-proof or execution weakness that affects multiple criteria;
• 중요 보완: evidence, differentiation, KPI, scope, or readability improvement;
• 편집 수정: terminology, repetition, grammar, caption, spacing, and visual polish.

For every revision provide location → original issue → evidence → reason → exact action → expected benefit → residual risk.

9. Rewrite only with authority

If the user requests rewriting:

• preserve official headings and limits;
• use only verified facts and clearly tagged assumptions, targets, and plans;
• keep a change log with original, revised, and reason;
• leave [출처 필요], [검증 필요], or [기관 확인 필요] rather than fabricating;
• do not add features merely to sound innovative.

10. Run final-file QA

Use references/submission-checklist.md. Inspect the exported PDF or actual upload file, not only the editable source. Verify page count, clipping, font size, links, QR codes, image resolution, metadata, 개인정보, anonymity, file name, and version.

The mechanical checker scripts/proposal_lint.py is a warning system only. Review every flag manually and report false positives.

Output contract

A diagnostic normally returns:

1. concise overall assessment and decisive blind spots;
2. review scope and missing materials;
3. official-form and rubric matrix;
4. reconstructed argument and broken links;
5. claim-source and implementation-state audit;
6. section-level keep/revise/move/delete/add table;
7. independent red-team findings;
8. prioritized revision map;
9. evidence and organizer questions;
10. submission-readiness blockers and final checklist.

Do not use participation verdicts. If the draft is weak, state whether it needs evidence strengthening, structural redesign, or final editing and explain why.

References and tools

• Read references/review-protocol.md before a deep or final review.
• Read references/submission-checklist.md before final-file QA.
• Use references/question-bank.md when the user asks how to provide better input.
• Run scripts/proposal_lint.py only as a supplementary warning check.