Ccf Idea Optimizer

CCF Idea Optimizer

Invocation Controls

CCFA Handoff Mode: PARTIAL (Recommended). Follow metadata.ccf_skill_controls.handoff_question_mode and ../ccf-common/references/handoff-modes.md. Use ../ccf-common/references/routing.md to keep idea optimization separate from idea scoring, manuscript writing, paper review, and rebuttal tasks.

Load ../ccf-common/references/task-modes.md before deciding exploratory, quick, or standard mode. Use exploratory mode for rough seeds, repeated direction search, "找方向", "还有没有可做路线", or when the user wants possibility before judgment. Use quick mode for a short idea repair or one local direction note. Use standard mode for mature idea concretization, novelty grounding, or a plan that will feed writing, reviewing, literature search, or experiment design.

If the user says not to use, disable, skip, or avoid a sibling skill, do not invoke or simulate that skill for the rest of the conversation. Use this skill's local fallback instead: compact risk scan, action queue, or next-step note without cross-skill execution.

Do not invent literature, results, baselines, experiments, reviewer reactions, or novelty evidence. Mark unsearched novelty and missing evidence as uncertainty.

Treat rough ideas, unpublished method details, draft abstracts, and experiment plans as private user data. Load ../ccf-common/references/privacy-and-evidence.md before browsing, using private text in a query, or making evidence/provenance claims.

Core Rule

Optimize the research idea before optimizing the writing. Do not inflate novelty, invent related work, invent results, or turn weak ideas into confident claims. Make the idea more CCF-A-ready by sharpening the problem, mechanism, contribution, evidence package, and reviewer-facing risk register. For fuzzy ideas, generate diverse but internally consistent candidate concretizations; prefer timely, elegant, non-stale directions and clearly mark novelty uncertainty until searched. In exploratory mode, do not kill a seed direction just because it is currently weak or crowded: produce at least one plausible rescue route, narrower problem, venue switch, benchmark/evidence route, or "minimum viable research question" before recommending a pivot. Follow the user's requested output shape: idea card, alternatives, roadmap, questions, table, Chinese explanation, or handoff-ready brief.

Mandatory Checklist

In standard mode, complete this checklist before final output. In quick mode, run the local subset only and return a compact status.

1. Target venue, venue family, field, and idea stage are explicit or marked unknown. 2. The raw idea is normalized into problem, gap, root challenge, insight, method, evidence, and limitation. 3. Missing inputs that affect confidence are named: related work, datasets, code, compute, timeline, collaborators, or domain constraints. 4. Novelty is treated as uncertain until grounded against closest known work or a current literature search. 5. The method mechanism is explained, not only named. 6. Innovation type is classified: problem, setting, method, data/benchmark, theory, system, empirical finding, evaluation, or synthesis. 7. The experiment plan tests the central claim and includes baselines, ablations, robustness, and failure analysis as needed by the venue. 8. Reviewer risks are labeled as writing-fixable, design-fixable, evidence-fixable, requires-new-result, venue-mismatch, or likely-pivot. 9. Diverse variants are checked for internal contradictions, mutually incompatible assumptions, and theme drift. 10. Early-stage outputs separate current weakness from development potential; uncertainty is labeled as needs-search, needs-mechanism, or needs-evidence, not as rejection. 11. Any optional module transition to ccf-literature-monitor, ccf-literature-searcher, ccf-idea-reviewer, ccf-experiment-designer, or ccf-paper-writer follows the CCFA handoff mode; if denied or disabled, output a local risk scan or next-step note only.

Load references/idea-intake.md when inputs are incomplete or several idea drafts must be normalized.

Workflow

1. Identify the target venue, track, field, idea maturity, user's decision goal, constraints, and available evidence. If no venue is named, assume a generic CCF-A target and label the assumption. 2. Map the target to a CCF-A family. Use ../ccf-common/references/ccf-a-venue-map.md for shared venue-family routing; then load references/venue-idea-adapters.md for idea-stage priorities. 3. Ground novelty and timeliness. If the user asks for current prior art, latest trends, frontiers, non-stale ideas, recent similar papers, competitor tracking, or venue-specific policy, follow CCFA handoff mode before using ccf-literature-monitor for recent-paper/competitor signals or ccf-literature-searcher for deep related-work search. If searching directly, browse primary sources: official venue pages, papers, proceedings, arXiv pages, project pages, and credible scholar sources. Mark unsearched novelty as uncertain. Treat close prior work as a differentiation problem first; treat it as a dead end only when the same problem, mechanism, evidence path, and venue claim are already covered. 4. Normalize the raw idea. Load references/idea-intake.md and produce an idea card with task, audience, gap, root challenge, insight, method, expected evidence, and constraints. 5. For fuzzy or underdetermined ideas, load references/frontier-ideation.md and produce 3-5 candidate concretizations with high diversity across problem angle, mechanism, evidence type, and venue fit. Randomness is allowed in exploration, but final candidates must be coherent and non-conflicting. 6. Sharpen the problem and method. Load references/problem-method-blueprint.md; convert vague motivation into a decision-relevant problem and convert method names into mechanisms, assumptions, failure modes, and alternatives. 7. Shape the innovation. Decide the strongest honest contribution type and remove unsupported or diluted claims. 8. Design the minimum convincing evidence package. Load references/experiment-design.md; specify datasets, baselines, ablations, metrics, stress tests, efficiency, user study, proof, or systems evaluation as required by the venue family. Follow CCFA handoff mode before using ccf-experiment-designer for a full experiment plan. 9. Run an internal development pass. In exploratory mode, use a coach-like viability scan: what can be saved, what must be narrowed, what evidence would decide, and what the next interaction should ask. Follow the CCFA handoff mode before using ccf-idea-reviewer as an optional scoring module; use it only when the user explicitly wants scoring, ranking, investment triage, or strict novelty judgment. If it is denied or disabled, perform a compact multi-expert risk scan focused only on problem and method. 10. Produce an optimized idea plan, rescue/pivot options, and a writing-readiness note. Follow the CCFA handoff mode before offering the viable plan to ccf-paper-writer; if writing is denied or not confirmed, stop at the idea plan.

Adaptive Output Contracts

Return the requested artifact first. If the user asks for options, give options. If they ask for a concise idea card, do not force a full review-style report. Use the following defaults when the user asks for a standard idea-optimization output.

For one idea, return:

Target venue and assumptions:
Mode and development stance:
Raw idea diagnosis:
Optimized idea card:
Candidate concretizations:
Problem statement:
Core insight:
Method blueprint:
Innovation claims:
Experiment plan:
Closest-work / novelty unknowns:
Reviewer-risk register:
Rescue routes and suggested pivots:
Optional next-module decision:
Checklist status:

For multiple idea drafts, return:

Venue lens:
Normalized idea table:
Best development candidate:
Why it is the best current route:
Idea-specific upgrades:
Risks by idea:
Recommended next iteration:

Reference Files

Load only what is needed:

• references/idea-intake.md: Use for incomplete, messy, or multi-candidate idea drafts.
• references/frontier-ideation.md: Use for fuzzy idea concretization, high-diversity exploration, non-stale direction checks, and coherence filters.
• references/problem-method-blueprint.md: Use when sharpening the problem, insight, mechanism, contribution type, and failure modes.
• references/venue-idea-adapters.md: Use after mapping a target to a CCF-A family.
• references/experiment-design.md: Use when designing baselines, ablations, evidence packages, and acceptance-oriented experiments.
• references/research-taste.md: Use when the user asks what makes research good, elegant, timely, or likely to survive top-conference review.
• references/source-notes.md: Use when provenance, source basis, or current-policy checks matter.

If the user's request is only to score an idea without optimizing it, follow the CCFA handoff mode before switching to ccf-idea-reviewer unless the user explicitly named it. If the user's request is mainly to monitor recent papers or competitors, route to ccf-literature-monitor; if it is mainly to search related literature deeply, route to ccf-literature-searcher. If the user already has a manuscript draft, follow the CCFA handoff mode before switching to ccf-paper-writer or ccf-paper-reviewer; if not confirmed, provide only a brief scope note.

Experiment Design

Use this file when turning an optimized idea into a minimum convincing evidence package for a CCF-A submission.

For a full experiment plan, dataset/baseline search, benchmark protocol, or result-fill table, use ccf-experiment-designer through the CCFA handoff mode. This file is the local lightweight evidence planner for idea optimization.

Evidence Principle

Design experiments to answer the reviewer question, "Does the evidence test the central claim?" Do not add experiments for volume. Every experiment should defend novelty, soundness, significance, generalization, efficiency, or scope.

Experiment Matrix

For each major claim, create:

Claim:
Evidence needed:
Dataset / benchmark / workload / proof / study:
Baselines:
Metrics:
Ablations:
Stress or robustness tests:
Failure analysis:
Expected reviewer concern answered:

Baseline Rules

• Include the strongest close prior work when feasible.
• Separate reproduced baselines, reported numbers, and incompatible settings.
• Explain why any missing baseline cannot be run.
• Avoid unfair adaptation, extra data, or hidden tuning advantages.
• Add simple baselines that test whether the core mechanism is necessary.

Ablation Rules

Use ablations to test mechanism, not only performance drops:

• Remove each core component.
• Replace the proposed component with a plausible generic alternative.
• Vary the key hyperparameter or threshold.
• Show when the method fails.
• Include qualitative or diagnostic evidence when numeric metrics hide behavior.

Venue-Specific Evidence

• ML/AI: ablations, seeds/statistics, data splits, robustness, compute, scaling, and diagnostic analysis.
• CV: visual comparisons, per-category or hard-case analysis, fair image/video settings, and failure cases.
• NLP: data quality, annotation agreement, leakage checks, human or automatic evaluation validity, and error taxonomy.
• DB/KDD/IR: scale, latency, memory, throughput, ranking metrics, workload realism, and deployment constraints.
• Systems: end-to-end evaluation, microbenchmarks, overhead, sensitivity, resource use, and operational failure cases.
• Security: threat model tests, bypass attempts, adaptive attacks, guarantees, responsible disclosure, and limitations.
• HCI: participant recruitment, tasks, measures, statistics, qualitative coding, ethics, and claim scope.
• Theory: theorem statement, proof sketch, examples, relation to known results, and limits of assumptions.

Minimum Convincing Package

The minimum package should include:

1. Main result against close baselines. 2. Mechanism ablation or proof of why the method works. 3. Robustness, generalization, or stress test. 4. Limitation or failure analysis. 5. Reproducibility details sufficient for audit.

If this package cannot be built under the user's constraints, recommend narrowing the claim, changing venue, or pivoting the idea.

Frontier Ideation

Use this file when the user provides a fuzzy, broad, or stale-prone idea and wants it concretized or optimized.

Exploration Rule

Generate diverse candidates first, then filter. High randomness is allowed during exploration, but final suggestions must be coherent, feasible, and aligned with the user's theme.

Do not claim frontier novelty unless a current literature search supports it. If no search is performed, label novelty as unsearched.

Do not collapse the search space too early. In exploratory work, keep at least three kinds of options when possible: a conservative repair of the user's seed, a narrower high-precision problem, and a more ambitious reframing. If all candidates look weak, identify the best salvageable ingredient before recommending a pivot.

Candidate Axes

Vary 3-5 axes:

Problem angle:
Root bottleneck:
Target user/community:
Method mechanism:
Data or benchmark:
Evidence type:
Venue family:
Main risk:

Useful variation patterns:

• Same problem, simpler mechanism.
• Same method family, sharper problem.
• New benchmark/protocol instead of new model.
• System/tool contribution instead of only algorithmic contribution.
• Theory/analysis contribution that explains an empirical pattern.
• Human-centered or deployment constraint that changes the problem.
• Negative result or diagnostic paper when SOTA chasing is crowded.

Non-Stale Check

Ask or search:

• What did top venues publish in the last 12-24 months?
• What datasets or baselines have become standard?
• What failure mode is still not well measured?
• What assumption do recent papers share?
• What result would still be useful if headline performance gains are small?

If current search is not available, state:

Novelty status: unsearched; needs ccf-literature-searcher before strong novelty claims.

Coherence Audit

Revise candidates before rejecting them. A candidate should be rejected only after naming the smallest plausible repair and explaining why it fails. Watch for:

• The method requires data the setting cannot provide.
• The benchmark does not test the claimed mechanism.
• The contribution tries to be method, dataset, system, theory, and application all at once.
• The venue audience mismatch is severe.
• The core insight is only a renamed component.
• Two modules optimize incompatible objectives.

Rescue Patterns

Use these before declaring a direction stale or too weak:

• Narrow the target setting until the bottleneck is measurable.
• Replace "new model" novelty with a benchmark, protocol, diagnostic, or analysis contribution.
• Keep the problem but simplify the mechanism.
• Keep the method family but change the claim from SOTA improvement to failure-mode explanation, robustness, cost, or deployment constraint.
• Switch venue family when the idea is valuable but not a main-track fit for the named venue.
• Turn a crowded positive-result idea into a negative-result or measurement paper if that would teach the community something.

Output Pattern

Exploration breadth:
Candidate idea cards:
Best candidate:
Why it is coherent:
Why it may be timely:
Novelty status:
Evidence package:
Risks:
Rescue / narrowing options:
Next question for the user:

Idea Intake

Use this file when the idea is rough, underspecified, scattered across several bullets, or when multiple idea drafts must be compared.

Intake Fields

Collect or infer:

Target venue / family:
Field and subfield:
Track or paper type:
Raw idea:
Problem owner / audience:
Closest known work:
Available data / code / compute:
Expected method ingredients:
Expected evidence:
Deadline and resource constraints:
Non-goals:

For fuzzy ideas, also collect or infer:

Seed direction:
What should stay fixed:
What may vary:
Desired novelty risk: conservative / balanced / exploratory
Preferred method taste: simple / elegant / theoretical / system-building / empirical / interdisciplinary
Fields to avoid:

If a field is unknown, infer it from the method and venue names. If the target venue is unknown, assume a generic CCF-A target and mark venue-specific advice as lower confidence.

Normalized Idea Card

Convert every idea into this structure before optimizing:

Task:
Gap:
Root challenge:
Core insight:
Proposed mechanism:
Contribution type:
Expected evidence:
Why now:
Main risk:
Best venue fit:

Hard rule: if the root challenge is only "existing methods perform poorly", refine it into a technical, scientific, empirical, human-centered, or systems bottleneck.

For fuzzy ideas, produce several normalized cards before choosing one. Do not collapse the search space too early.

For early directions, attach a development label instead of a verdict:

• seed: interesting but still missing problem, mechanism, or evidence.
• salvageable: weak in current form, but a clear narrowing or reframing exists.
• needs-search: promising enough to search before judging novelty.
• needs-mechanism: problem may matter, but the mechanism is not yet credible.
• near-pivot: keep only one ingredient unless the user can supply hidden evidence or constraints.

Missing-Input Labels

Use these labels instead of guessing:

• needs-literature-search: closest work is unknown or likely fast-moving.
• needs-frontier-grounding: the idea may be stale or crowded and needs current paper search.
• needs-feasibility-check: data, compute, implementation complexity, or timeline is unclear.
• needs-domain-constraint: the real-world setting, threat model, user group, or workload is underspecified.
• needs-evidence-design: the paper claim is clearer than the experiment plan.
• needs-venue-selection: the idea may be good, but the audience is not yet obvious.

Multi-Idea Intake

For several drafts, normalize all ideas first, then compare optimization routes. Do not optimize the first idea prematurely. Prioritize optimizer attention by:

1. Strongest problem-method fit. 2. Most defensible novelty after likely prior art. 3. Best evidence feasibility. 4. Best CCF-A venue fit. 5. Lowest serious-risk count after one realistic iteration.

Do not produce numeric scores, investment recommendations, winner labels, or strict rankings here. Prefer "best development route" and "backup route" over "winner/loser" language. If the user explicitly asks to score, rank, select, or strictly review ideas, route to ccf-idea-reviewer.

Problem And Method Blueprint

Use this file when converting a rough direction into a CCF-A-ready problem and method plan.

Problem Sharpening

A strong problem statement should answer:

What is the task or phenomenon?
Who in the venue community cares?
What gap remains after the strongest prior work?
Why is the gap hard rather than merely unattempted?
What would become possible if it were solved?
What scope boundary prevents overclaiming?

Good CCF-A problems tend to have at least one of these properties:

• They expose a bottleneck that strong prior work cannot handle.
• They define a new setting that changes the technical requirements.
• They reveal a mismatch between common assumptions and real use.
• They connect two areas in a way that creates a new capability or question.
• They make a hidden evaluation gap measurable.

Method Mechanism

Translate method labels into mechanisms:

Input and output:
Key representation:
Main operation:
Optimization or inference objective:
Why the mechanism should address the root challenge:
Assumptions:
Failure modes:
Alternative designs rejected:

If the method is a combination of known components, identify the non-obvious interaction. If no interaction exists, the idea is likely an engineering assembly and needs a sharper contribution or a stronger benchmark/evidence story.

Coherence Filter

Before presenting an optimized idea, check:

• The problem setting and method assumptions are compatible.
• The proposed evidence can actually test the central claim.
• The contribution type matches the evidence type.
• The target venue audience would care about the problem, not only the technique.
• No module requires data, supervision, deployment access, or theoretical assumptions that conflict with another module.
• The idea does not rely on mutually exclusive claims such as "training-free" and "requires large fine-tuning" unless the distinction is scoped.

Innovation Types

Classify the strongest honest contribution:

• New problem or setting.
• New method or architecture.
• New objective, inference procedure, or theoretical result.
• New dataset, benchmark, workload, or protocol.
• New system design or deployment insight.
• New empirical finding or diagnostic analysis.
• New synthesis that resolves a known tension.

Avoid claiming all types. Pick the top one or two and make the evidence package serve them.

Elegance Checks

An elegant idea usually has:

• One central insight that explains the method.
• A method whose parts are necessary, not decorative.
• A simple claim that can be tested directly.
• A failure mode that is understandable.
• A result that would teach the community something even if SOTA gains are modest.
• A design that removes a bottleneck or reveals a simpler formulation, not merely a longer pipeline.

Fatal Idea Risks

Mark these early:

• The novelty collapses under a likely close paper.
• The problem is too narrow for the target venue.
• The method is a known trick with new terminology.
• The central claim cannot be tested with available resources.
• The evidence would require a dataset, proof, or system that cannot be built in time.
• The idea depends on hidden assumptions reviewers will reject.

Research Taste

Use this file when the user asks what kind of research is good, elegant, important, or more likely to survive CCF-A review.

Good Research Signals

Strong research usually has:

• An important problem, not only a popular technique.
• A precise gap against strong prior work.
• A simple insight that changes how the problem is attacked.
• A method whose mechanism is inspectable.
• Evidence that tests the claim rather than decorating it.
• Honest scope and limitations.
• A result that would still teach something if the headline number were smaller.

Heilmeier-Style Questions

Adapt these questions during idea optimization:

What are you trying to do?
How is it done today?
What is new in your approach?
Who cares, and why?
What are the risks?
How much will it cost or require?
How will progress and success be measured?

NSF-Style Merit

Use intellectual merit as the core idea test:

• Does the idea advance knowledge, capability, method, data, theory, system design, or evaluation?
• Are the team, resources, and approach credible?
• Are the claims grounded in evidence that can be produced?

Use broader impact only when it is real and venue-relevant. Do not add vague societal claims to compensate for weak technical contribution.

Hamming-Style Taste

Prefer ideas that touch important problems and where the user's current position gives them a credible angle. A technically perfect solution to an unimportant problem is unlikely to survive elite review. A difficult important problem needs a narrowed, attackable entry point.

Paper-Story Taste

Borrow the writing lesson from strong paper-writing advice: the idea should be explainable as one story:

problem -> gap -> challenge -> insight -> method -> evidence -> limitation

If this story cannot be stated before drafting, the manuscript will likely become a list of components and experiments.

Acceptance-Oriented Taste

CCF-A acceptance is not just "novel plus works". The idea should reduce reviewer uncertainty:

• Why this problem?
• Why this method?
• Why now?
• Why should I believe it?
• Why this venue?
• What would fail if the central assumption is false?

If the answer to any question is missing, optimize the idea before polishing text.

Frontier And Staleness Taste

For fast-moving topics, a good idea should survive a current related-work scan. Treat these as warnings:

• The idea is a direct extension of a crowded benchmark trend with no new bottleneck.
• The method is "add LLM/VLM/diffusion/agent" without a mechanism tied to the problem.
• The claimed gap is likely solved by recent workshop, arXiv, OpenReview, or proceedings papers.
• The evidence package would only show small leaderboard gains without explaining why.
• The idea depends on an obsolete dataset, baseline, threat model, workload, or user scenario.

Prefer directions that:

• expose a new measurable failure mode,
• simplify an overcomplicated paradigm,
• connect a strong method to a neglected but important constraint,
• create a benchmark/protocol that changes what can be measured,
• turn an empirical observation into a mechanism, theorem, or system design.

Source Notes

Use this file when the user asks why the idea-optimization workflow is structured this way, asks for provenance, or needs current official policy checks.

Shared Registry

The authoritative CCFA source inventory is:

../ccf-common/references/source-registry.yaml

Do not duplicate long URL lists in this skill. Add or update public source records in the shared registry, then run:

python ..\ccf-common\scripts\check_sources.py

Idea-Optimizer Use Rules

• Use official venue pages for current review forms, policies, tracks, anonymity, artifacts, ethics, and page limits.
• Use papers, proceedings, official project pages, and credible scholar pages for literature grounding.
• Do not treat source lists as proof of novelty. Novelty requires checking the specific idea against close work.
• Treat unsearched prior art as uncertainty, not as novelty.
• Avoid copying source wording. Extract evaluation structure, problem-framing questions, and research-taste signals only.
• Follow ../ccf-common/references/privacy-and-evidence.md before using private idea text in any search query.

Venue Idea Adapters

Use this file after mapping the target to a CCF-A venue family. It adapts idea-stage optimization, not final writing.

Universal CCF-A Idea Priorities

Make these visible before writing:

• A problem the venue community recognizes as important.
• A gap against strong current work.
• A mechanism that explains why the proposed method should work.
• An evidence package that can test the central claim.
• A contribution type that matches the venue's taste.

AI / ML: NeurIPS, ICML, ICLR, AAAI

Prioritize conceptual insight, learning mechanism, rigorous empirical validation, ablations, and scope. A good idea should explain what is learned about models, optimization, data, representations, agents, evaluation, or reasoning. Avoid pure leaderboard chasing without diagnostic value.

CV / Vision: CVPR, ICCV, ECCV

Prioritize visual task importance, fair baselines, visual evidence, ablations, failure cases, dataset or protocol credibility, and generalization. A strong idea often combines a clear visual bottleneck with an inspectable mechanism.

NLP / ACL-Family

Prioritize task validity, language/data quality, annotation or evaluation soundness, strong baselines, analysis, replicability, and responsible use. Watch for benchmark overfitting, dataset leakage, and vague human-facing utility.

DB / KDD / IR / WWW

Prioritize realistic workload, scale, metrics, ranking or retrieval validity, efficiency, deployment relevance, and user or system utility. The idea should make clear why the proposed method matters under real data and constraints.

Systems / Networks / Architecture

Prioritize real bottlenecks, implementation credibility, end-to-end evaluation, operational constraints, and comparison with practical baselines. A good idea often wins because the design resolves a tension between performance, reliability, cost, or deployability.

Security

Prioritize threat model, assumptions, guarantees, bypass analysis, responsible disclosure, and ethics. A strong idea must make the attacker/defender setting precise before method details become meaningful.

HCI / UbiComp

Prioritize research question, user population, study design, analysis method, ecological validity, ethics, and claim scope. A strong idea links a human-centered question to a method that can actually answer it.

Theory / PL / Formal Methods

Prioritize formal problem statement, assumptions, theorem novelty, proof strategy, relation to known barriers, and conceptual clarity. Evidence may be proof, complexity, semantics, or formal guarantee rather than experiments.

Graphics / Multimedia / Visualization

Prioritize perceptual quality, user-facing utility, visual fidelity, comparative evidence, efficiency, and clear task framing. Avoid ideas that are only aesthetic demos without a technical or evaluative claim.