Run competition workflow

Run the full competition workflow

Purpose

Coordinate the entire path from official-rule analysis through evidence-led narrative idea planning to proposal review. Select only the stages required by the user's materials, preserve reasons and sources across handoffs, and keep the existing Korean and English aliases for compatibility.

Visible Korean commands

Interpret these Korean expressions as user-facing commands:

Order	Korean command	Compatible alias	Specialist skill	Role
auto	공모전	-	this skill	inspect the current state and continue analysis → planning → review in one request
1	공모전1	공모전분석	$analyze-competition-deeply	combine source lock, rules, rubric, organizer, winners, constraints, and evidence needs
2	공모전2	공모전기획	$plan-competition-ideas	combine problem discovery, prior-art checks, idea selection, validation, MVP, and narrative proposal planning
3	공모전3	공모전검토, 보고서검토	$review-competition-proposals	combine red-team review, factual correction, revision, and final submission QA

Treat the number as a memorable stage label, not as a separate substep. The user does not need to type a command. Infer the same route from the request and attachments.

Start with a blind pass

Before starting a new full workflow:

• inspect every supplied official document, idea note, prior handoff, draft, prototype, source, and deadline;
• identify 2–3 overlooked questions that could materially change the work, such as the target user, available first-party evidence, actual data access, implementation state, operator, deadline, or exception handling;
• ask at most three concise questions when the answers are unavailable and consequential;
• do not repeat questions already answered by the files or conversation;
• state bounded assumptions and continue when missing information does not block useful work.

Route by evidence state

Read references/routing-protocol.md when the request is ambiguous or spans stages.

Use the minimum complete route:

1. If official requirements are not verified, apply $analyze-competition-deeply first.
2. If a verified CONTEST_ANALYSIS_HANDOFF exists but the problem and intervention are not settled, apply $plan-competition-ideas.
3. If a proposal draft or final file exists, apply $review-competition-proposals; first recover missing official constraints or idea logic only when the review depends on them.
4. If all stages are requested through 공모전, execute all feasible stages in the same task and preserve both handoff blocks. Pause only for a missing input that would materially change the result or for an external action requiring new authority.
5. Do not redo a completed stage unless the official rules, source evidence, idea scope, or draft has materially changed.
6. If 공모전2 or 공모전3 is called without a usable prerequisite, state the missing prerequisite and recover it inside the same task when the supplied materials permit. Do not silently invent it.

Reopen analysis when a new notice, correction, form, rubric, FAQ, primary source, or material contradiction changes the search space. Reopen planning when a current service, technical precedent, contest precedent, patent, failed collapse condition, unavailable permission, or operator constraint changes differentiation or execution. Record the trigger instead of silently replacing the earlier conclusion.

Full workflow

1. Analyze

Apply the analysis specialist. Separate confirmed facts, sourced inferences, unknowns, and organizer questions. End with CONTEST_ANALYSIS_HANDOFF.

2. Plan

Apply the planning specialist. Generate ideas from different causes and mechanisms, run concept-lock and prior-art gates, register collapse conditions, test both claim and system attack surfaces, define a bounded MVP, and write the selected idea in the required narrative proposal structure. End with IDEA_PLAN_HANDOFF.

3. Review

Apply the review specialist. Audit and, when authorized, revise compliance, evidence, causal logic, implementation truth, risks, writing, and the actual submission file. Prioritize submission blockers, major revisions, important improvements, and editing fixes.

Shared rules

• Treat official notices, corrections, FAQs, rubrics, and fixed forms as the highest authority.
• Attach a source or validation plan to every decisive claim.
• Distinguish official fact, team analysis, assumption, target, and future plan.
• Treat official examples as non-exhaustive unless the notice says otherwise; do not profile reviewer personality beyond sourced institutional evidence.
• Separate current services, technical precedents, prior contest ideas, and patent or rights questions.
• Use 확인 범위 내 미발견 for negative searches and record scope, date, and access failures.
• Separate problem existence, demand, technical feasibility, operational adoption, and effect evidence.
• State one to three collapse conditions for the leading concept and preserve a materially different backup.
• Audit both claim/evidence fragility and system/operation misuse, privacy, safety, and failure paths.
• Do not turn unsupported numbers into precise targets; use [기준 설정 필요].
• Distinguish user need, technical feasibility, operational feasibility, and effect evidence.
• Keep implementation-complete, partial implementation, analysis, mockup, and plan separate.
• Record why scope, claims, features, or wording changed.
• Never use a participation verdict or a synthetic award probability.

Output contract

For a full-process request, return:

1. current stage and supplied evidence;
2. decisive blind spots and any interview answers or assumptions;
3. completed analysis summary and CONTEST_ANALYSIS_HANDOFF;
4. concept-lock status, prior-art coverage, collapse conditions, idea comparison, validation priorities, MVP, the narrative idea proposal, and IDEA_PLAN_HANDOFF;
5. proposal review findings, dual attack-surface risks, and revision priorities when a draft exists;
6. next concrete work items, owners or required inputs, unresolved official questions, and stage-reopen triggers;
7. a short evidence-driven decision log explaining major changes.