Plan competition ideas

Plan competition ideas from analysis

Purpose

Turn verified contest constraints and team assets into differentiated, testable idea plans. Develop evidence before polished prose. Recommend the strongest preparation direction and alternatives without deciding participation.

Boundary

Own:

• divergent problem frames and idea candidates;
• target user, situation, unmet job, root cause, and current workaround;
• intervention mechanism, core value, differentiation, and adoption path;
• rubric alignment and team-fit reasoning;
• critical assumptions, evidence plan, MVP, prototype, pilot, KPI, and risks;
• primary concept and backup concept with reasons.

Do not:

• re-research settled contest rules unless a conflict appears;
• draft the final official proposal by default;
• add AI, maps, RAG, dashboards, communities, rewards, or platforms without causal need;
• predict winning probability;
• use GO, CONDITIONAL GO, or NO-GO labels.

Use $analyze-competition-deeply first when official requirements or organizer intent are unknown. Hand the selected plan to $review-competition-proposals after drafting.

Start with a blind pass

Identify 2–3 overlooked constraints before generating ideas. Typical blind spots include lack of direct user evidence, unavailable data, operator workload, duplicate prior work, unsafe automation, a buyer different from the user, or an MVP that cannot prove the promised effect.

If a missing answer would materially change the ideas, ask at most three concise questions. Otherwise declare assumptions and continue.

Required workflow

1. Validate the handoff

Read the contest-analysis handoff, official rubric, team profile, existing ideas, available evidence, and time. Separate:

• confirmed constraint;
• confirmed team asset;
• unverified assumption;
• missing evidence;
• preference or non-negotiable choice.

If a prior analysis claim lacks a source, do not treat it as fact. Preserve unresolved organizer questions.

2. Define the search space before ideas

Build 3–7 distinct problem frames. Vary the cause or decision gap, not just the name or feature set.

For each frame specify:

target → situation → current behavior → friction/loss → direct cause → structural cause → unresolved decision/action

Use lived or operational evidence and scale evidence separately. Do not turn a broad statistic into proof of a specific user need.

3. Generate candidate mechanisms

For each promising frame propose a causal mechanism:

resource/input → intervention → direct output → changed behavior/operation → measurable outcome

Generate different mechanism families where relevant, such as information redesign, process change, incentive, matching, prevention, accessibility, optimization, shared infrastructure, or policy rule. Technology is a means, not the idea.

4. Create one-page idea cards

Use references/idea-design-protocol.md. Every card must include:

• one-sentence definition;
• user, operator, buyer or approving authority;
• problem scene and root cause;
• current alternative and exact gap;
• mechanism and user/operation flow;
• decisive outcome;
• core, support, and roadmap scope;
• required data, permissions, partners, and technology;
• evidence held and evidence missing;
• strongest counterargument;
• critical assumptions and fastest tests;
• rubric contribution and team-fit reason.

5. Compare without false precision

Use the official rubric where available. Add planning dimensions only when useful: need evidence, differentiation, data access, technical proof, operational owner, testability, accessibility/safety, team fit, time, and page explainability.

For every score or rank provide:

• evidence basis;
• confidence level;
• uncertainty or missing proof;
• what evidence could change the ranking.

Do not convert diagnostic scores into award probabilities. Do not reject participation. Classify concepts as:

• 우선 발전안;
• 보완 후 경쟁안;
• 백업안;
• 통합·재설계 소재.

6. Stress-test the leading concepts

Use at least five independent perspectives:

• contest and policy fit;
• user or beneficiary;
• data and evidence;
• technology, accessibility, privacy, and safety;
• operation, budget, adoption, and maintenance.

For each objection provide objection → evidence → consequence → mitigation → residual risk.

7. Select a primary concept and preserve a backup

Recommend a primary concept because it best matches the rubric, available evidence, team assets, and time. State why it is preferred and what remains unproved. Preserve one materially different backup concept.

If the leading concept is weak, redesign its target, mechanism, scope, or proof plan. Do not stop at a participation verdict.

8. Design validation before prose

Build a critical-assumption register using references/evidence-and-assumption-standard.md. Prioritize assumptions that can collapse the idea:

• user need;
• data and permission;
• causal mechanism;
• technical feasibility;
• operator adoption;
• cost and sustainability;
• legal, privacy, accessibility, safety, and ethics.

For each assumption define the fastest honest test, sample, metric, pass/fail learning threshold, owner, duration, and fallback. A test threshold guides redesign; it is not a participation verdict.

Do not invent precise sample sizes, improvement percentages, budgets, accuracy targets, or time reductions. Use a number only when it has a stated basis such as an observed baseline, safety limit, official requirement, prior study, resource capacity, or minimum meaningful change. Otherwise provide the metric and threshold-setting method with [기준 설정 필요]. If a small formative sample is proposed for usability learning, label it as a planning range and state that it cannot support population or performance claims.

9. Scope the MVP and evidence prototype

The prototype must prove the riskiest promise, not maximize screen count.

Separate:

• build and test now;
• mock up only;
• roadmap after data or partnership;
• explicitly excluded.

Include baseline, test scenario, expected evidence, failure cases, and what the result cannot prove.

10. Produce the master plan and handoff

Write the selected idea as:

• problem definition;
• core insight;
• value and mechanism;
• user/operation flow;
• differentiation;
• evidence status;
• MVP and validation;
• execution roles, schedule, budget ranges, risks, fallback;
• KPI and scale conditions;
• official-form mapping.

Use references/handoff-schema.md so the proposal writer or review skill can continue without reconstructing decisions.

Evidence language

Tag material claims as [공식 사실], [현장 근거], [팀 분석], [검증 결과], [가정], [추론], [목표], or [계획]. Attach source, date, unit, method, limitation, and claim use.

Every recommendation must show 근거, 이유, 불확실성, and 다음 검증.

Output contract

Return, at minimum:

1. inherited constraints and blind spots;
2. problem-frame portfolio;
3. candidate idea cards;
4. rubric/evidence comparison with confidence;
5. adversarial objections and responses;
6. primary concept, backup concept, and selection reasons;
7. critical-assumption and evidence plan;
8. MVP/prototype/pilot brief;
9. master idea plan;
10. handoff block.

Scale the number of candidates to time and user request. Do not inflate features to make ideas look innovative.

References

• Read references/idea-design-protocol.md before generating candidates.
• Read references/evidence-and-assumption-standard.md before ranking or validation design.
• Use references/handoff-schema.md for the selected plan.
• Use references/question-bank.md when the user asks how to provide better input.