القائمة
Use when evaluation metrics, protocol, datasets, or splits have been confirmed in the research plan — enforces immutability of locked evaluation components without explicit user authorization
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 | metric-lock |
| description | Use when evaluation metrics, protocol, datasets, or splits have been confirmed in the research plan — enforces immutability of locked evaluation components without explicit user authorization |
Changing evaluation metrics after confirmation is not optimization — it is goalpost-moving. This skill activates after plan freeze (G2) and remains in effect until project end.
Core principle: Locked means locked. No silent modifications.
Violating the letter of this rule is violating the spirit of this rule.
EVALUATION METRICS, ONCE CONFIRMED, ARE IMMUTABLE WITHOUT USER PERMISSION
After G2 plan freeze, the following are immutable:
Secondary/supplementary metrics may be added for additional analysis. They cannot replace primary metrics and cannot be used to override primary metric conclusions.
IF you believe a locked item must change:
1. EXPLAIN: What exactly needs to change?
2. JUSTIFY: Why is the current version flawed?
3. PROVE: Show evidence the locked version is defective (not just suboptimal)
4. WAIT: User decides — not you
5. LOG: Record old value, new value, reason in change_log
Skip any step = unauthorized modification = academic misconduct
| Excuse | Reality |
|---|---|
| "This metric isn't quite right" | You argued for it in Phase 3. To change, go through the change request process. |
| "A different metric shows better results" | That's exactly why changing is forbidden. |
| "The community now prefers X" | If true, convince the user. Don't change silently. |
| "Just adding a supplementary metric" | Adding secondary is fine. Replacing primary is not. |
| "The baseline used a different metric" | Adapt the baseline, don't change your protocol. |
| "It's a minor adjustment" | Minor adjustments to locked items require user approval. Always. |
| "The metric has a known limitation" | All metrics do. Document the limitation; don't swap the metric. |
Locked item + no user approval = do not touch
Unauthorized modification of evaluation components is academic misconduct. No exceptions.