Menü
Use when scope expansion is detected at any phase — enforces focus by quantifying risk and requiring explicit user approval before scope changes
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Use when designing the evaluation protocol for a method development project — locks primary metrics, datasets, seeds, statistical tests, and baseline list into an immutable contract
Use when G2 (plan freeze) and G3 (execution readiness) gates have passed — handles all implementation, baseline reproduction, experimentation, and iteration for both Type M and Type D projects; this is Phase 4
Use when research direction is validated (G1 passed) and the project needs method design, analysis framework, evaluation protocol, or story line — this is Phase 3 and must complete before any code or experiments
Reusable protocol for multi-agent discussions that iterate until convergence. Used by results-integration (Phase 5) and paper-writing (Phase 6) to ensure discussions actually resolve issues rather than just noting them.
Use when and ONLY when the user explicitly requests paper writing and G4 (write-ready) gate has passed — handles LaTeX structure, senior-level writing, reference verification, and iterative refinement
Use when Phase 1 (research-direction-exploration) is complete and G1 gate has passed — subjects the research problem to adversarial defense-style questioning, classifies project intent, re-evaluates venue target, and produces a final feasibility ruling before any method design begins
| name | scope-control |
| description | Use when scope expansion is detected at any phase — enforces focus by quantifying risk and requiring explicit user approval before scope changes |
A focused paper with 1–2 strong contributions beats a scattered paper with 5 weak ones. This skill can trigger at ANY phase when scope expansion is detected.
Core principle: Focus is a feature. Scope creep is a bug.
Violating the letter of this rule is violating the spirit of this rule.
Any ONE of these activates this skill:
When triggered, the agent MUST execute all four steps in order:
1. WARN: "Current scope may be too large for [target venue] as a single paper."
2. QUANTIFY: "Current experiment plan requires ~X GPU-hours. Budget is Y. Excess: Z%."
or "There are N contribution points. A focused paper typically has 1-2."
3. PROPOSE: Reduction options, prioritized:
a) Core contribution to keep
b) Items to defer to future work
c) Items to cut entirely
4. PRESENT: User decides. Agent cannot decide scope reduction on its own.
Skip any step = scope creep enabled = paper quality at risk
| Excuse | Reality |
|---|---|
| "We can fit it all in" | Page limits exist. Reviewers penalize unfocused papers. |
| "Each piece is small" | Small pieces compound into confusion. |
| "We already did the work" | Sunk cost. Extra work that dilutes the paper hurts more than helps. |
| "The reviewer might ask for it" | Anticipate reviewers, but don't preemptively answer every possible question. |
More contributions ≠ better paper
Focused contribution + strong evidence = acceptance
Detect expansion. Quantify risk. Propose cuts. Let the user decide.