Paper Case Study

• Case writing must preserve the approved method name, module names, symbols, metrics, baseline naming, and core terminology from the linked methodology.
• Methodology provides hard constraints only. It does NOT define the case structure and does NOT justify result claims by itself.

4. Figure-grounded result generation is mandatory.

• Every substantive result paragraph must bind to at least one explicit figure/table id in the current case evidence package.
• No explicit figure/table id -> no substantive result prose.
• If needed, narrow the subsection to setup notes, observation notes, or placeholder-only output.

5. Do not infer case results from methodology, reference papers, or domain common sense. Result claims must come from current-case evidence only.

6. If figure, caption, table, and user note conflict, do not resolve by guessing. Mark the conflict explicitly in CaseSpec and TODO/VERIFY.

7. RESULT_PENDING mode must never sound like completed experimentation.

8. Domain scope: AI4Science / geotechnical engineering case-study writing only. If outside scope, explicitly decline.

9. Humanizer is ask-first. Ask user before any de-AI rewrite of case prose. Never auto-apply humanizer pass. Keep all technical content, evidence bindings, and claim tags unchanged during humanizer pass.

10. CN-EN alignment is mandatory in bilingual mode: same section numbers, figure/table references, numerical values, symbols, and claim scope. CN and EN drafts must be structurally mirrored.

11. Reference cases provide structure only. They must not provide current-case result content, numbers, rankings, or justifications.

12. Methodology provides hard constraints only. It must not be used as result justification.

13. Own-style transfer must stay abstraction-first.

• Extract style traits from multiple own cases before drafting.
• Never paraphrase from a selected reference passage.
• The model must abstract style features from own cases before drafting; it must never paraphrase from a selected reference passage.

14. Anti-copy rules apply to body text and headings.

• Do not reuse a reference sentence verbatim.
• Do not reuse recognizable sentence molds with only entity substitution.
• Do not splice multiple short phrases from the same reference paragraph.
• Do not clone paragraph skeletons or subsection heading sequences.
• Do not let one own paper dominate the generated voice.

2) Canonical Terms

Use these terms consistently across this skill and companion assets:

• CaseSpec: the single source of truth for case-study planning and drafting
• Methodology Lock: the hard-constraint layer inherited from the linked methodology
• Heading Plan: the confirmed heading set generated after CaseSpec
• assets/reference_cases/*.txt: the only runtime reference corpus source of truth
• RESULT_READY / RESULT_PENDING: the two hard writing branches
• figure-grounded: result generation strictly bound to figure/table evidence
• primary pattern / fallback patterns: the planning anchor plus optional local overlays
• strict_image_grounding: when enabled, result claims may use only the current case evidence package (figure, table, caption, user note) and not external inference sources
• shared assets loaded: audit note used when sibling shared assets are reused
• [SHARED_ASSET_MISSING]: audit note used when a non-fatal shared asset is absent
• style abstraction summary: internal summary of own-style traits expressed as abstract tags only, never quoted phrasing
• STYLE_MATCH_WITHOUT_COPY: audit dimension checking own-style match without lexical or structural reuse
• [STYLE_COPY_RISK]: audit marker for reference-like wording or structure reuse

3) Runtime Assets (Read only what is needed)

3.0 Calibration scope (explicit phase split)

This skill uses two different evidence scopes:

• Rule-refinement / skill-update phase (maintainer workflow): MUST calibrate case-structure rules using all available case-study samples in assets/reference_cases/*.txt.
• Runtime generation phase (user request handling): MUST stay lightweight and retrieve only the most relevant case papers first (default top 2-3; expand when the case pattern is ambiguous), together with 1-3 additional case papers for pattern diversity. Ownership/source type is inferred from filename tags such as own and other, not directory split.

Hard rule: CaseSpec structure must be driven mainly by case-study samples in assets/reference_cases/*.txt, not by methodology text.

Observed corpus tendency (current repository calibration):

• Many case texts follow: engineering background -> data/monitoring setup -> experiment implementation -> result analysis.
• A second common shape is: application overview -> data preparation -> comparison/prediction/risk-result blocks.
• A third common shape is: experimental settings -> performance comparison -> error distribution / real curves / condition-wise analysis.
• Therefore, runtime selection MUST be pattern-based, not template-fixed.

Dependency classes:

Fatal runtime dependencies:

• linked methodology or equivalent approved lock source
• this skill assets:
  • assets/casespec_template.md
  • assets/case_patterns.yml
  • assets/case_outline.md
  • assets/figure_result_rules.md
  • assets/error_log.md
  • assets/memory/hard_memory.json
  • assets/memory/soft_memory.json

Non-fatal shared dependencies from sibling paper-methodology:

• style_profile.md
• error_log.md
• memory/hard_memory.json
• memory/soft_memory.json
• term_glossary.yml
• notation.md

Fallback order for shared dependencies:

1. Shared sibling asset first
2. Local fallback asset second
3. Missing-but-nonfatal third with [SHARED_ASSET_MISSING]

Always attempt to read shared assets first. If any shared assets load, record shared assets loaded in planning or audit notes.

Local fallback assets:

• assets/local_term_glossary.yml
• assets/local_notation.md

Read on-demand from this skill:

• assets/testing_suggestion_rules.md
• assets/case_heading_style_profile.md
• assets/case_heading_patterns.yml
• assets/reference_cases/*.txt

Runtime evidence split:

• assets/reference_cases/*.txt = primary source for case structure and result progression
• linked methodology = hard constraints only
• current-case figures/tables/captions/user notes = auditable evidence package for result claims

Reference corpus role split:

• own references = primary style source
  • Use only for extracting technical voice, information density, heading granularity, paragraph-function organization, explanation intensity, and discussion restraint.
  • Never use as current-case content source.
  • Never use as wording donor.
• other references = secondary boundary source
  • Use to prevent overfitting to one own paper.
  • Use to check structure boundaries and expression diversity boundaries.
  • Never override own-style priority.
  • Never act as wording donor.

Runtime style priority:

• style calibration priority is own > other
• other references may widen the style family boundary, but must not pull the output back to a generic SCI template voice

Shared-dependency fallback rules:

• Missing term_glossary.yml or notation.md must not block case drafting.
• Use local fallback when present.
• If a non-fatal shared asset has no local equivalent, continue and log [SHARED_ASSET_MISSING].
• No silent failure is allowed for missing shared assets.

4) 3-Phase Workflow

Phase A: GATHER

Goal: collect constraints, evidence, and writing-pattern cues before drafting.

A1. Parse user input and collect case materials:

• linked methodology text or MethodSpec
• project/site background
• monitoring/data/setup notes
• evaluation protocol notes
• figures, captions, tables
• user numeric annotations and caveats

A2. Extract Methodology Lock from the linked methodology:

• method name
• module names
• symbols / notation
• metrics
• baseline naming
• term constraints
• prohibited drift items

A3. Detect result branch:

• RESULT_READY: user has completed testing and provides usable figures/tables/ captions/notes
• RESULT_PENDING: user has not completed testing or evidence is insufficient for substantive result writing

A4. Read updated references:

• retrieve top relevant case papers first from assets/reference_cases/*.txt
• infer source type from file naming (*-own-*, *-other-*) when useful for weighting style calibration and boundary diversity
• prioritize own references when extracting style traits
• use other references only as boundary checks against single-paper mimicry or narrow heading cloning
• prioritize references whose heading logic matches the current evidence shape:
  • project/site-first input -> engineering-application-first
  • benchmark table / comparison curve input -> benchmark-comparison-first
  • module-removal table input -> ablation-first
  • interval / risk / quantile evidence -> uncertainty-risk-first
  • warning / monitoring-priority / decision evidence -> deployment-decision-first

A5. Build initial evidence map for each figure/table:

• figure/table id
• caption
• visible observations
• user-provided numeric evidence
• allowed claims
• disallowed claims
• numeric gaps
• evidence source type (directly visible, caption-only, user-note-only, mixed-evidence)
• conflict status

A5.1 Detect evidence-package conflicts:

• If figure/caption/user note disagree, mark [CONFLICT].
• If caption and user note disagree, do not arbitrate.
• If only user numeric notes exist and no image body is available, numeric claims may be drafted only as non-direct evidence and must never be labeled [Directly visible].

A5.2 Build style abstraction summary before drafting decisions:

• Read multiple relevant own references first.
• Extract only abstract style traits such as:
  • heading style
  • paragraph function distribution
  • sentence compactness
  • evidence-to-interpretation ratio
  • tone descriptors
  • common transition types
  • discussion restraint level
• Use other references only to keep the style family from collapsing into one single own-paper realization.
• Do not copy or store reference sentences, continuous phrases, or paragraph outlines in the summary.

A6. Trigger user-question node when needed:

• If Methodology Lock is missing and cannot be inferred safely, ask for the approved methodology or equivalent source.
• If RESULT_READY is claimed but no usable figure/table evidence exists, recommend switching to RESULT_PENDING or placeholder-only output.

Hard rule: If result evidence is insufficient for a requested claim, do not move to substantive result drafting for that claim. Mark it as [Not claimable yet].

Phase B: PLAN (CaseSpec gate)

Goal: create a single source of truth for case drafting.

B0. Select case pattern before writing CaseSpec.

• Match the task to one primary pattern from assets/case_patterns.yml.
• Record short rationale and 1-2 fallback patterns.
• Pattern selection is adaptive and case-driven. Do not force a single invariant result order across all case studies.
• When available, cite 2-4 closest reference cases whose heading progression supports the selected pattern.

Anti-single-mapping rule:

• A selected primary pattern is a planning anchor, not a full-template lock.
• If the evidence package is hybrid (e.g. project background + benchmark table + ablation table + interval figure), preserve one primary pattern but borrow local section logic from fallback patterns.
• Do not flatten a mixed case into one rigid storyline just because one pattern appears most common in the corpus.
• Do not mirror any single reference case from start to end.

B0.1 Produce internal style abstraction summary before Heading Plan.

• Summarize own-style traits as abstract labels only.
• Do not include quoted lines, near-quotes, or reusable sentence frames.
• Use this summary as the only style input to heading generation and drafting.

B1. Build section plan from base skeleton + selected case-pattern overlay.

• Use assets/case_outline.md as base skeleton.
• Apply selected pattern overlay to adjust ordering and emphasis.
• Keep result progression consistent with available evidence.
• Preserve the corpus-backed tendency that background/setup usually precedes result analysis unless the evidence package is strongly comparison-first.
• If multiple evidence blocks have different dominant shapes, allow hybrid planning at subsection level:
  • engineering background block may remain application-first
  • main benchmark block may become comparison-first
  • ablation block may borrow ablation-first ordering
  • uncertainty / risk block may borrow uncertainty-risk-first ordering
• The final section plan must be coherent, but it does not need to be a pure single-pattern tree.

B2. Produce CaseSpec with these sections:

1. Metadata
2. Methodology Linkage / Methodology Lock
3. Case Background / Engineering Context
4. Data / Monitoring / Site / Scenario Setup
5. Experimental / Evaluation Protocol
6. Comparison / Baseline Plan
7. Result Status
8. Result Evidence Map
9. Claim Boundary
10. Heading Plan
11. Conflicts / Gaps / TODO / VERIFY

B3. For each hard-fact field in Sections 2-9 of the CaseSpec, include:

• Source: specific origin (e.g. "user notes", "approved methodology", "Figure 4 caption", "Table 3", "[TBD]")
• Confidence: OK or NEEDS_VERIFY

B3.1 Evidence sufficiency gate:

• For each planned result subsection, explicitly mark:
  • READY_TO_WRITE
  • PLACEHOLDER_ONLY
  • NOT_CLAIMABLE_YET
• For each planned result subsection, explicitly record:
  • bound figure/table ids
  • visible observations
  • allowed claims
  • disallowed claims
  • numeric gap status
  • evidence source type
• If evidence is weak, narrow the section scope instead of inflating prose.
• If a subsection is imported from a fallback pattern, mark that relationship in planning notes so the hybrid logic remains auditable.

B3.1.1 Strict grounding switch:

• strict_image_grounding: ON | OFF must be recorded in CaseSpec metadata.
• When ON, result claims must come only from the current case evidence package.
• Methodology, reference cases, and common sense cannot fill evidence gaps.
• Caption and table evidence remain valid because they are part of the current case evidence package.

B3.2 Local-refinement CaseSpec delta rule:

• In local mode, explicitly mark UNCHANGED vs UPDATED for each target-linked CaseSpec field.
• Non-target fields remain unchanged unless minimal linked repair is required.

B4. Present CaseSpec and enforce confirmation gate. Proceed to Heading Plan only if user replies equivalent to CONFIRM/OK/proceed.

Hard rule: No Heading Plan or body drafting is allowed before this gate is satisfied, except when explicit skip-gate exception is present in user instruction.

Skip-gate exception only when user explicitly says phrases such as:

• skip confirmation
• skip CaseSpec confirmation
• 直接生成
• 跳过确认

Phase B2: PLAN-B — Heading Plan (after CaseSpec confirmation)

Goal: produce a concrete, reviewable set of section/subsection headings before any body text is drafted.

B5. Load heading naming assets (on-demand):

• assets/case_heading_style_profile.md
• assets/case_heading_patterns.yml
• retrieve 2-5 case papers most relevant to the selected case pattern and technical domain

B6. Generate Heading Plan:

• Use CaseSpec + selected case pattern + case heading naming rules.
• Use the style abstraction summary, not reference wording, to calibrate the heading family.
• Produce a numbered list of proposed section and subsection titles.
• For key result sections where ambiguity is high, provide 2-3 alternative heading candidates with brief rationale.
• If RESULT_PENDING, headings must use planned/pending wording instead of completed-result wording.
• RESULT_PENDING headings must avoid completed-result phrasing such as performance improvement, superiority, or outperforms.
• Prefer heading families already observed in the corpus when appropriate:
  • background / project overview / engineering background
  • data acquisition / dataset collection / monitoring layout
  • experiment implementation / experimental design / experimental settings
  • result analysis / performance comparison / results and discussion

Heading anti-rigidity rules:

• Do not map each pattern to one fixed heading label.
• Do not force all result blocks into a generic heading such as Results and discussion.
• When two heading families both fit, provide alternatives instead of silently choosing a single canonical wording.
• Allow a Heading Plan to mix compatible families when that better reflects the actual evidence package and the closest reference cases.
• Before finalizing headings, check whether the plan looks like a mechanical clone of one template; if yes, diversify using corpus-backed alternatives.
• Heading imitation is allowed only at the level of stylistic family, not lexical reuse or sequence cloning.
• Do not copy an own heading with one or two nouns replaced.
• Do not lightly synonym-swap a reference heading and treat it as new.
• Do not clone the same heading sequence from a single own paper.

B7. Present Heading Plan and enforce heading confirmation gate. Proceed to Phase C only if user replies equivalent to CONFIRM/OK/proceed.

Hard rule: No body drafting is allowed before heading confirmation is satisfied, except when explicit skip-heading exception is present in user instruction.

Skip-heading exception only when user explicitly says:

• skip heading confirmation / 跳过标题确认
• generate directly / 直接生成
• use default headings / 使用默认标题
• no heading review needed / 标题无需审核

Phase C: WRITE_AUDIT

Goal: draft case text from the confirmed CaseSpec, under the confirmed Heading Plan, then run compact audit. In bilingual mode, produce CN and EN drafts with structural mirroring.

Branch A: RESULT_READY

C1. Draft Chinese case-study text from CaseSpec.

• Follow shared style_profile.md when available; otherwise keep the local case style conservative, compact, and reference-shaped without blocking execution
• Apply own-style transfer through the style abstraction summary only.
• Do not use any reference passage as a phrasing source.
• Dense paragraphs, formal register
• Full-width Chinese punctuation
• Keep standard technical terms in English where appropriate (GAN, GCN, RMSE, etc.)
• Body text must follow the locked heading hierarchy exactly. Do not rename, reorder, or silently drop approved headings. If a heading becomes technically inappropriate during drafting, flag it as HEADING MISMATCH in TODO/VERIFY instead of changing it.

C1.1 Draft result subsections only from bound figure/table evidence.

• Every result paragraph must bind to at least one figure/table id.
• Do not write precise numbers unless they are visible in a table/caption or explicitly supplied by the user.
• If a subsection lacks explicit figure/table ids in CaseSpec, do not write substantive result prose for that subsection.
• If numeric evidence comes from user notes without visible image support, keep it labeled as non-direct evidence.
• Use claim tags internally to control scope:
  • [Directly visible]
  • [Numeric from user]
  • [Interpretive / cautious]
  • [Not claimable yet]

C1.2 Draft engineering interpretation / validation only within evidence boundary.

• Discussion may explain only displayed evidence.
• Do not introduce new result dimensions not shown in the current case assets.
• Under strict_image_grounding: ON, do not justify any claim from methodology, reference cases, or general expectations.

C1.3 Anti-copy drafting constraints:

• Never reuse a full sentence from any reference case.
• Never reuse a recognizable sentence mold with only method/site/metric swapping.
• Never reconstruct a paragraph by preserving the same step order from a reference paragraph.
• Never assemble a paragraph by stitching multiple short phrases from one reference paragraph.
• Keep the text in the same style family as own cases, but with independent wording and paragraph realization.

C2. Draft English case-study text (bilingual mode).

• Mirror CN structure exactly: same section numbers, figure/table references, numerical values, symbols, and claim scope.
• Present tense for result description.
• Prefer objective subject style ("this study" / "this paper" / "the proposed framework") over first-person, unless user explicitly requests otherwise.
• Same heading-hierarchy constraint as C1: body text must follow the locked heading plan.

C2.1 CN-EN alignment rules:

• Same sections, same evidence bindings, same claim tags per paragraph.
• Every numerical value in CN must appear identically in EN.
• Every figure/table reference in CN must appear identically in EN.
• If CN uses a term variant, EN must use the mapped equivalent from shared term_glossary.yml, local fallback glossary, or memory/hard_memory.json.

C3. Ask humanizer question (do not auto-apply):

• "English version is ready. Apply de-AI humanizer pass?"
• If user agrees, apply inlined de-AI constraints:
  1. Keep all technical content unchanged (numbers/symbols/equations/references/ evidence bindings/claim tags)
  2. Remove filler/promotional/mechanical connectors
  3. Preserve evidence-grounded voice and technical precision characteristic of own papers
  4. Keep text if already natural (return pass verdict)

C3.1 Optional refinement operations (ask-first, never auto-apply):

• Expand: +5 to +15 words, add only evidence-supported implicit logic.
• Compress: -5 to -15 words, keep all technical facts unchanged.
• Polish: improve clarity/coherence/grammar, keep terminology/references fixed.

All refinement operations require explicit user confirmation before execution.

Humanizer role boundary:

• Humanizer is not the main style-transfer mechanism.
• Base drafting must already reflect own-style calibration.
• Humanizer may only do a light final polish after drafting and must not become a hidden paraphrase layer over reference text.

C3.2 Evidence-result logic check (before delivery):

• Check only critical evidence-logic issues:
  • Evidence without interpretation: figure/table referenced but no claim follows
  • Interpretation without evidence: claim made but no figure/table binding
  • Trend claim without figure: trend described but no supporting visualization
  • Comparison claim without baseline evidence: superiority/inferiority stated but baseline result not grounded in evidence
  • Engineering implication without shown result: practical recommendation made but the result it depends on is not presented in current case
  • Step jump: result progression skips intermediate analysis that evidence supports
• Do not report style-only issues in this pass.
• Keep this check lightweight and repair-oriented (no verbose reviewer critique).

C3.3 Logic-enrichment pass (inlined, targeted; before audit):

• Purpose: make supportable implicit evidence reasoning explicit and improve local continuity between result blocks.
• This is NOT generic expansion and NOT a style rewrite.
• Operate only on logic gaps detected in C3.2 and only when evidence exists in CaseSpec evidence map and/or user-provided figures/tables/notes.
• Allowed enrichments:
  1. Add purpose sentence connecting evidence to engineering context
  2. Add compact observation -> interpretation -> implication chain
  3. Add explicit transition clause to the next result block
  4. Add one-line figure/table role explanation tied to the analysis flow
• Hard constraints:
  • No new results, numbers, trends, baselines, or conclusions.
  • Keep all values/symbols/references unchanged.
  • Preserve own-paper style: precise, technical, compact, non-tutorial.
  • If source support is insufficient, keep original text and add TODO/VERIFY rather than guessing.

Branch B: RESULT_PENDING

C4. Draft only:

• case background (CN, and EN if bilingual mode)
• case setup (CN, and EN if bilingual mode)
• evaluation/testing suggestions
• expected figure/table checklist
• result placeholders / TBD slots

C5. RESULT_PENDING hard prohibitions:

• no completed-result tone
• no benchmark superiority claims
• no ablation findings written as completed facts
• no fabricated numbers or trends
• no completed-result headings such as performance improvement, superiority, or outperforms

Section-level refinement mode (overlay; keep 3-phase workflow)

Trigger this mode when user explicitly requests local refinement and provides:

• target section/subsection identifier
• existing section text
• added notes and/or new figures/tables/captions
• operation type: rewrite | correct | results-from-figures-only

R1. Scope lock:

• Treat this as local update, not case-section rewrite.
• Preserve all non-target sections by default.

R2. Phase A behavior in local mode:

• Extract only target-related facts and target-related evidence.
• Re-check only target-related Methodology Lock and evidence conflicts.

R3. Phase B behavior in local mode:

• Update only CaseSpec fields linked to the target subsection.
• Refresh Source and Confidence for every updated hard-fact field.

R4. Phase C behavior in local mode:

• Rewrite only the target subsection.
• Keep other sections unchanged unless minimal term/symbol/figure-reference repair is required.

R5. Explicit prohibitions in local mode:

• No full-section rewrite unless user explicitly requests it.
• No unsourced result expansion.
• No claim beyond target-bound evidence.

Heading-only and heading-refinement modes (overlay; keep 3-phase workflow)

H1. Heading-plan-only mode:

• Run Phase A and Phase B through Heading Plan.
• Stop after Heading Plan delivery. Do not enter Phase C.
• Output: CaseSpec + Heading Plan only.

H2. Heading-refinement mode:

• Re-evaluate existing headings against CaseSpec, selected pattern, and heading naming rules.
• Produce updated Heading Plan with change annotations (KEPT / RENAMED / ADDED / REMOVED / REORDERED).
• Do NOT rewrite body text.

H3. Lock-headings-and-draft mode:

• Use the locked headings as the structural skeleton for Phase C.
• Body text must follow the locked heading structure exactly.

Audit (must run before delivery)

Run compact 10-pass audit:

1. Methodology-lock consistency
2. Figure/table binding completeness
3. No hallucinated results
4. Claim-tag correctness
5. Conflict logging completeness
6. RESULT_PENDING safety
7. Traceability completeness
8. Heading-body alignment
9. Error-log compliance (no repeated mistakes from assets/error_log.md)
10. STYLE_MATCH_WITHOUT_COPY

C4.2 Lightweight logic continuity check (post-enrichment, mandatory):

• Verify no unresolved evidence-logic gaps remain (per C3.2 categories).
• Verify each result paragraph has stated evidence binding and interpretation.
• Verify fixes from C3.3 remain source-grounded (no unsourced inserted claim).
• Report only PASS/FLAG/FAIL with short repair notes.

Additional planning-flexibility audit checks:

• Pattern-fit audit: selected primary pattern matches dominant evidence shape
• Hybrid-need audit: if the evidence package is mixed, fallback logic is used where needed instead of being ignored
• Anti-clone audit: final Heading Plan is not a start-to-end copy of one single reference case or one single template family

STYLE_MATCH_WITHOUT_COPY audit:

• PASS only when the draft matches the own-style family in technical tone, information density, paragraph-function discipline, and heading granularity without reference-like wording.
• FLAG or FAIL if any of the following appears:
  • lexical reuse from a reference case
  • sentence-mold reuse with light substitution
  • paragraph skeleton reuse
  • heading clone or heading-order clone
  • single-paper mimicry
  • pseudo-original rewriting that only swaps variable, site, or metric names
• If triggered, mark [STYLE_COPY_RISK] and do not pass final audit.

Additional local-mode checks:

• Scope integrity
• Figure-reference integrity after local edit
• No unsourced result inserted by local edit
• CN-EN alignment for updated scope (bilingual mode)
• Non-target fields remain UNCHANGED unless minimal linked repair is required

Fix FAIL items before delivery. Put unresolved items in TODO/VERIFY.

Pre-delivery Gate Checklist (mandatory)

• Gate G1: Phase A completed (constraints, evidence, conflict scan)
• Gate G2: CaseSpec produced
• Gate G3: CaseSpec confirmation satisfied OR explicit skip-gate instruction found
• Gate G3.1: Heading Plan produced and confirmed OR explicit skip-heading instruction found
• Gate G4: Case text drafted under evidence boundary (and CN/EN mirrored if bilingual mode)
• Gate G5: 10-pass audit executed

If any gate is false, stop and repair before final output.

5) CaseSpec Template

Use the full template in: assets/casespec_template.md

Key structural rules:

• CaseSpec is the single source of truth for case drafting.
• Methodology Lock is embedded in CaseSpec but does not dominate case structure.
• Result Evidence Map and Claim Boundary are mandatory.
• Blank Source on any hard-fact field in Sections 2-9 = audit FAIL.
• Every planned result subsection must carry its own evidence-binding record.

6) Output Contract

Deliver in this order (full-case-study mode):

1. CaseSpec
2. Heading Plan
3. Case-study draft (Chinese, if bilingual mode)
4. Case-study draft (English, if bilingual mode; otherwise single-language draft)
5. TODO/VERIFY + Audit summary

Case-plan-only mode: deliver items 1-2 only. Results-from-figures-only mode: deliver only the bound result subsections plus TODO/VERIFY + Audit summary. Result-refine-local mode: deliver updated CaseSpec delta + updated target subsection only. Result-pending-suggestion-only mode: deliver CaseSpec + Heading Plan + testing suggestions + figure/table checklist + placeholders only.

If placeholders are used, TODO/VERIFY must explicitly list user actions needed to replace each placeholder.

Audit summary format:

CONSISTENCY AUDIT SUMMARY

Methodology-lock: PASS/FLAG/FAIL Figure-binding: PASS/FLAG/FAIL Result hallucination: PASS/FLAG/FAIL Claim-boundary: PASS/FLAG/FAIL Conflict logging: PASS/FLAG/FAIL Result-pending safety: PASS/FLAG/FAIL (or N/A) Traceability: PASS/FLAG/FAIL Heading-body: PASS/FLAG/FAIL (or N/A) Error-log compliance: PASS/FLAG/FAIL Style-match-without-copy: PASS/FLAG/FAIL

7) Revision Policy

Small revision (<3 paragraphs, no structure change): revise directly.

Result-local refinement (default local update):

• If user requests a target result subsection update, perform local revision by default and keep non-target sections unchanged.
• If newly added evidence forces case-level structure changes (global renumbering, reordered result blocks, cross-section dependency expansion), escalate to Large revision and present Revision Plan first.

Large revision (>=3 paragraphs or structure change): present a Revision Plan first, then wait for user approval.

Revision Plan format:

REVISION PLAN

Trigger: ... Changes:

1. ...
2. ... Preserved:

• ... Evidence impact:
• ... Alignment impact (bilingual):
• ... Risks:
• ...

8) Style Transfer and Anti-Copy Notes

• Write in the user's case style family, but never by rephrasing the user's original case text.
• Reference case papers are for style abstraction and structure calibration, not content copying or passage paraphrase.
• Own references are primary style sources; other references are boundary sources.
• Allowed transfer targets are only:
  • rhetorical function
  • technical tone
  • information density
  • heading granularity
  • explanation intensity
  • case-writing voice
• Disallowed transfer targets are:
  • wording reuse
  • sentence-mold reuse
  • paragraph skeleton reuse
  • heading clone
  • single-paper mimicry
• The current corpus already contains multiple usable case archetypes; runtime generation should leverage those archetypes explicitly instead of treating all case writing as generic "results and discussion".
• Pattern selection should be stable but not brittle:
  • stable enough to avoid random structure drift
  • flexible enough to support hybrid section plans when evidence demands it
• The planner should prefer the smallest sufficient structural adaptation rather than global remapping of the whole case section.
• The flat naming convention inside reference_cases already preserves source type (own / other), so no directory split is required.
• Root-level reference_papers/ is documentation-only and must not contain duplicate runtime samples.
• Keep prompts compact; avoid loading non-essential assets.

9) Runtime Efficiency Rules

• Prefer targeted lookup over full-file loading.
• Retrieve only top relevant case references in runtime generation.
• Do not mirror specific wording from any reference paper.
• If no usable case references exist yet, run the workflow with placeholders and explicitly recommend adding more files to assets/reference_cases.

10) Default Clarification Templates

Template A (missing Methodology Lock):

1. Missing lock items: ...
2. Recommended default: provide approved methodology / MethodSpec / fixed terms
3. Impact: if provided now, CaseSpec and all headings/result wording will align

Template B (insufficient result evidence):

1. Missing evidence: ...
2. Recommended default: switch to RESULT_PENDING or keep result sections as placeholders
3. Impact: if figures/tables are added now, result subsections can be drafted

Template C (evidence conflict found):

1. Conflict: Figure/Table says X, caption/user note says Y
2. Default policy: keep conservative wording and log [CONFLICT]
3. Please confirm whether one source should override the others

11) Do / Don't

Do:

• use CaseSpec as the only drafting source
• lock terms and modules to methodology
• bind every result paragraph to evidence
• keep claims conservative under weak evidence

Don't:

• infer results from methodology
• borrow typical conclusions from references
• invent precise improvements or rankings
• write RESULT_PENDING as if experiments were already complete

12) Upstream Alignment (external repos)

This skill explicitly incorporates writing constraints from:

• https://github.com/Leey21/awesome-ai-research-writing
• https://github.com/Orchestra-Research/AI-Research-SKILLs/tree/main/20-ml-paper-writing

Adopted principles:

• Avoid AI-flavored filler and promotional language in case prose.
• Prefer natural paragraph flow over list-heavy output in final case text.
• Use present tense for result description by default.
• Treat citation reliability as critical: unverifiable references must remain explicit placeholders instead of guessed entries.
• Be proactive in drafting, but enforce hard gates (CaseSpec confirmation, Heading Plan confirmation, pre-delivery checklist) to prevent step skipping.
• Evidence-grounded writing: every claim must trace to figure/table/user evidence, not to domain common sense or reference paper conclusions.

Scope note:

• This skill remains case-study-only (AI4Science / geotechnical engineering), while inheriting the above writing and citation safety practices.