superlab 0.1.7 → 0.1.8

package/package-assets/shared/{templates → lab/.managed/templates}/proposal.md

@@ -3,7 +3,7 @@
 ## Lab Change
 
 - Change id:
-- Target path: `.superlab/changes/<change-id>/proposal.md`
+- Target path: `.lab/changes/<change-id>/proposal.md`
 
 ## Scope
 

package/package-assets/shared/{templates → lab/.managed/templates}/spec.md

@@ -3,7 +3,7 @@
 ## Lab Change
 
 - Change id:
-- Target path: `.superlab/changes/<change-id>/spec.md`
+- Target path: `.lab/changes/<change-id>/spec.md`
 
 ## Requirements
 
@@ -15,7 +15,7 @@
 ## Acceptance
 
 - Idea artifact written
-- Lab change artifacts written in `.superlab/changes/<change-id>/`
+- Lab change artifacts written in `.lab/changes/<change-id>/`
 - Validation run executed
 - Iteration reports generated
 - Final report generated

package/package-assets/shared/{templates → lab/.managed/templates}/tasks.md

@@ -1,9 +1,9 @@
 # Tasks
 
 - [ ] Identify the approved lab change id.
-- [ ] Create `.superlab/changes/<change-id>/`.
+- [ ] Create `.lab/changes/<change-id>/`.
 - [ ] Write the idea artifact.
-- [ ] Convert the idea into `.superlab/changes/<change-id>/proposal.md`, `.superlab/changes/<change-id>/design.md`, `.superlab/changes/<change-id>/spec.md`, and `.superlab/changes/<change-id>/tasks.md`.
+- [ ] Convert the idea into `.lab/changes/<change-id>/proposal.md`, `.lab/changes/<change-id>/design.md`, `.lab/changes/<change-id>/spec.md`, and `.lab/changes/<change-id>/tasks.md`.
 - [ ] Run the first validation experiment.
 - [ ] Normalize and validate the evaluation summary.
 - [ ] Execute bounded iteration rounds.

package/package-assets/shared/{templates → lab/.managed/templates}/write-iteration.md

@@ -8,6 +8,7 @@
 
 ## Inputs
 
+- Framing artifact used:
 - Report artifacts used:
 - Normalized summaries used:
 - Reviewer notes used:

package/package-assets/shared/lab/changes/README.md

@@ -0,0 +1,10 @@
+# `.lab/changes`
+
+Each approved `/lab:spec` change lives in one directory:
+
+- `.lab/changes/<change-id>/proposal.md`
+- `.lab/changes/<change-id>/design.md`
+- `.lab/changes/<change-id>/spec.md`
+- `.lab/changes/<change-id>/tasks.md`
+
+This keeps spec artifacts grouped under `lab` instead of depending on external directory conventions.

package/package-assets/shared/lab/config/workflow.json

@@ -0,0 +1,6 @@
+{
+  "workflow_language": "en",
+  "paper_language": "en",
+  "paper_format": "latex",
+  "deliverables_root": "docs/research"
+}

package/package-assets/shared/lab/context/next-action.md

@@ -0,0 +1,19 @@
+# Next Action
+
+## Immediate Step
+
+- Action:
+- Success signal:
+
+## If Success
+
+- Next action:
+
+## If Failure
+
+- Fallback action:
+
+## Human Decision Needed
+
+- Question:
+- Why it blocks progress:

package/package-assets/shared/lab/context/session-brief.md

@@ -0,0 +1,30 @@
+# Session Brief
+
+## Active Stage
+
+- Stage:
+
+## Mission
+
+One sentence describing the active research mission.
+
+## Best Current Path
+
+- Approved direction:
+- Why this is the active path:
+
+## Main Risk
+
+- Risk:
+- Evidence gap:
+
+## Read First
+
+1. `.lab/context/mission.md`
+2. `.lab/context/state.md`
+3. `.lab/context/evidence-index.md`
+
+## Do Not Change Silently
+
+- Frozen boundary:
+- Approval gate:

package/package-assets/shared/lab/context/summary.md

@@ -0,0 +1,21 @@
+# Research Summary
+
+## Current Direction
+
+Summarize the current approved research direction in 5-10 lines.
+
+## Strongest Evidence
+
+- Claim:
+- Supporting artifact:
+- Caveat:
+
+## Largest Risk
+
+- Risk:
+- Why it matters:
+
+## Current Gap
+
+- Missing evidence:
+- Missing artifact:

package/package-assets/shared/lab/context/terminology-lock.md

@@ -0,0 +1,27 @@
+# Approved Paper-Facing Terms
+
+Record the currently approved naming and wording that later stages should reuse consistently.
+
+## Approved Terms
+
+- Paper title:
+- Method name:
+- Short name or acronym:
+- Module names:
+- Contribution bullets:
+
+## Allowed Variants
+
+- Acceptable shorter forms:
+- Acceptable section-level aliases:
+
+## Forbidden Terms
+
+- Terms to avoid:
+- Claims to avoid:
+
+## Source Audit
+
+- Recent academic papers reviewed:
+- Primary sources reviewed:
+- Why the approved wording is acceptable:

package/package-assets/shared/lab/system/core.md

@@ -0,0 +1,41 @@
+# Lab System Core
+
+This project uses `.lab/` as the durable research workflow root.
+
+## Default Read Order
+
+For a new AI session, read these files in order:
+
+1. `.lab/context/session-brief.md`
+2. `.lab/context/mission.md`
+3. `.lab/context/state.md`
+4. `.lab/context/evidence-index.md`
+
+Only expand to additional context when the brief points to it.
+
+## Workflow Boundaries
+
+- `.lab/context/` holds durable project research state.
+- `.lab/changes/`, `.lab/iterations/`, and `.lab/writing/` hold workflow control artifacts.
+- `.lab/.managed/` holds tool-managed templates and scripts.
+- Deliverables belong under the configured `deliverables_root`, not inside `.lab/context/`.
+
+## Task Routing
+
+Use `/lab:*` only for research workflow tasks:
+
+- idea development
+- specification
+- experiment execution
+- bounded iteration
+- reviewer-style critique
+- final reporting
+- paper drafting
+
+Do not force `/lab:*` onto unrelated engineering tasks.
+
+## State Discipline
+
+- Treat `.lab/context/*` as durable project state.
+- Do not silently overwrite context files.
+- Keep sourced evidence separate from generated hypotheses.

package/package-assets/shared/skills/lab/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lab
-description: Strict research workflow for idea development, lab change specification, small-scale experiment execution, bounded iteration, reviewer-grade critique, final reporting, and paper-writing.
+description: Strict research workflow for idea development, framing, lab change specification, small-scale experiment execution, bounded iteration, reviewer-grade critique, final reporting, and paper-writing.
 ---
 
 # /lab Skill
@@ -9,16 +9,17 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 
 ## Global Rules
 
-- Keep idea generation, specification, execution, review, and reporting as separate stages.
+- Keep idea generation, framing, specification, execution, review, and reporting as separate stages.
 - Keep paper writing separate from experiment execution and reporting.
+- When the user explicitly invokes `/lab:<stage>`, execute that stage against the provided target instead of replying with a recommendation for another `/lab` stage.
 - Start each stage with a concise user-facing summary before writing artifacts.
 - After that summary, decide whether immediate artifact creation is useful; if yes, write the artifact and then report the output path plus next step.
 - When a missing assumption would materially change the stage outcome, ask one clarifying question at a time.
 - When there are multiple viable paths, present 2-3 approaches with trade-offs and a recommendation before converging.
 - When a stage materially sets downstream direction, keep an explicit approval gate before proceeding.
 - Write durable artifacts to disk instead of leaving key decisions only in chat.
-- Use `.superlab/config/workflow.json` as the global contract for workflow language, paper language, and paper format.
-- Use `.superlab/context/`` as the shared project state for both Codex and Claude entrypoints.
+- Use `.lab/config/workflow.json` as the global contract for workflow language, paper language, and paper format.
+- Use `.lab/context/` as the shared project state for both Codex and Claude entrypoints.
 - Workflow artifacts should follow the installed workflow language.
 - Final paper output should default to LaTeX, and its manuscript language should be decided separately from the workflow language.
 - Separate sourced facts from model-generated hypotheses.
@@ -29,7 +30,7 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 ### `/lab:idea`
 
 - Search relevant literature, baselines, datasets, and evaluation metrics before proposing a plan.
-- Read `.superlab/context/`mission.md` and `.superlab/context/`open-questions.md` before drafting.
+- Read `.lab/context/mission.md` and `.lab/context/open-questions.md` before drafting.
 - Ask one clarifying question at a time when critical ambiguity remains.
 - State the problem, the failure case, and why the problem matters before proposing solutions.
 - Classify the idea by contribution category and breakthrough level.
@@ -39,27 +40,41 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - Produce 2-3 candidate approaches with trade-offs before recommending one.
 - Critique the idea before converging on it.
 - Keep an explicit approval gate before `/lab:spec`.
-- Write idea artifacts with the template in `.superlab/templates/idea.md`.
-- Update `.superlab/context/`mission.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`open-questions.md` after convergence.
+- Write idea artifacts with the template in `.lab/.managed/templates/idea.md`.
+- Update `.lab/context/mission.md`, `.lab/context/decisions.md`, and `.lab/context/open-questions.md` after convergence.
 - Do not implement code in this stage.
 
+### `/lab:framing`
+
+- Use this stage for paper-facing naming and wording decisions, not for new experimental claims.
+- Read `.lab/config/workflow.json`, `.lab/context/mission.md`, `.lab/context/decisions.md`, and `.lab/context/evidence-index.md` before drafting.
+- Audit method name, module names, paper title, and contribution bullets together as one framing pack.
+- Distinguish canonical field terms from new labels; prefer canonical object names whenever possible.
+- State whether each proposed term is standard, adapted, or newly coined.
+- Reject names that hide the object being calibrated, estimated, ranked, or predicted.
+- Avoid acronym-first naming and names that sound like implementation patches or marketing language.
+- Produce 2-3 candidate framing packs with trade-offs before recommending one.
+- Write the durable framing artifact with `.lab/.managed/templates/framing.md`.
+- Update `.lab/writing/framing.md`, `.lab/context/decisions.md`, and `.lab/context/state.md` after convergence.
+- Keep an explicit approval gate before `/lab:write`.
+
 ### `/lab:spec`
 
-- Read `.superlab/config/workflow.json` before drafting the change.
-- Read `.superlab/context/`mission.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`state.md` before drafting the change.
-- Use `.superlab/changes/<change-id>/` as the canonical lab change directory.
-- Convert the approved idea into lab change artifacts using `.superlab/templates/proposal.md`, `.superlab/templates/design.md`, `.superlab/templates/spec.md`, and `.superlab/templates/tasks.md`.
-- Update `.superlab/context/`state.md` and `.superlab/context/`decisions.md` after freezing the spec.
+- Read `.lab/config/workflow.json` before drafting the change.
+- Read `.lab/context/mission.md`, `.lab/context/decisions.md`, and `.lab/context/state.md` before drafting the change.
+- Use `.lab/changes/<change-id>/` as the canonical lab change directory.
+- Convert the approved idea into lab change artifacts using `.lab/.managed/templates/proposal.md`, `.lab/.managed/templates/design.md`, `.lab/.managed/templates/spec.md`, and `.lab/.managed/templates/tasks.md`.
+- Update `.lab/context/state.md` and `.lab/context/decisions.md` after freezing the spec.
 - Do not skip task definition.
 
 ### `/lab:run`
 
 - Start with the smallest meaningful experiment.
-- Read `.superlab/context/`mission.md` and `.superlab/context/`state.md` before choosing the run.
-- Register the run with `.superlab/scripts/register_run.py`.
-- Normalize the result with `.superlab/scripts/eval_report.py`.
-- Validate normalized output with `.superlab/scripts/validate_results.py`.
-- Update `.superlab/context/`state.md` and `.superlab/context/`evidence-index.md` after the run.
+- Read `.lab/context/mission.md` and `.lab/context/state.md` before choosing the run.
+- Register the run with `.lab/.managed/scripts/register_run.py`.
+- Normalize the result with `.lab/.managed/scripts/eval_report.py`.
+- Validate normalized output with `.lab/.managed/scripts/validate_results.py`.
+- Update `.lab/context/state.md` and `.lab/context/evidence-index.md` after the run.
 
 ### `/lab:iterate`
 
@@ -73,40 +88,41 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
   - maximum iteration count
 - Only change implementation hypotheses within the loop.
 - Require a normalized evaluation report each round.
-- Read `.superlab/context/`mission.md`, `.superlab/context/`state.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`evidence-index.md` at the start of each round.
+- Read `.lab/context/mission.md`, `.lab/context/state.md`, `.lab/context/decisions.md`, and `.lab/context/evidence-index.md` at the start of each round.
 - Switch to diagnostic mode if risk increases for two consecutive rounds.
-- Write round reports with `.superlab/templates/iteration-report.md`.
-- Update `.superlab/context/`state.md`, `.superlab/context/`decisions.md`, `.superlab/context/`evidence-index.md`, and `.superlab/context/`open-questions.md` each round as needed.
+- Write round reports with `.lab/.managed/templates/iteration-report.md`.
+- Update `.lab/context/state.md`, `.lab/context/decisions.md`, `.lab/context/evidence-index.md`, and `.lab/context/open-questions.md` each round as needed.
 - Stop at threshold success or iteration cap, and record blockers plus next-best actions when the campaign ends without success.
 
 ### `/lab:review`
 
 - Work in reviewer mode, not implementation mode.
-- Read `.superlab/context/`mission.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`evidence-index.md` before reviewing.
+- Read `.lab/context/mission.md`, `.lab/context/decisions.md`, and `.lab/context/evidence-index.md` before reviewing.
 - Start with a concise summary of what is being reviewed and the top review question.
 - Prioritize methodology, fairness, leakage, statistics, ablations, and claim discipline.
 - Output findings first, then fatal flaws, then fix priority, then residual risks.
-- Use `.superlab/templates/review-checklist.md`.
-- Write durable review conclusions back to `.superlab/context/`state.md` or `.superlab/context/`open-questions.md` when they affect later stages.
+- Use `.lab/.managed/templates/review-checklist.md`.
+- Write durable review conclusions back to `.lab/context/state.md` or `.lab/context/open-questions.md` when they affect later stages.
 
 ### `/lab:report`
 
 - Summarize all validated iteration summaries.
-- Read `.superlab/context/`mission.md`, `.superlab/context/`state.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`evidence-index.md` before drafting.
-- Aggregate them with `.superlab/scripts/summarize_iterations.py`.
-- Write the final document with `.superlab/templates/final-report.md`.
+- Read `.lab/context/mission.md`, `.lab/context/state.md`, `.lab/context/decisions.md`, and `.lab/context/evidence-index.md` before drafting.
+- Aggregate them with `.lab/.managed/scripts/summarize_iterations.py`.
+- Write the final document with `.lab/.managed/templates/final-report.md`.
 - Keep failed attempts and limitations visible.
-- Update `.superlab/context/`state.md` and `.superlab/context/`evidence-index.md` with report-level handoff notes.
+- Update `.lab/context/state.md` and `.lab/context/evidence-index.md` with report-level handoff notes.
 
 ### `/lab:write`
 
 - Start only after `report` artifacts are stable enough to support paper claims.
-- Read `.superlab/config/workflow.json` before drafting and enforce its `paper_language` and `paper_format`.
-- Read `.superlab/context/`mission.md`, `.superlab/context/`decisions.md`, and `.superlab/context/`evidence-index.md` before drafting.
+- Start only after an approved framing artifact exists at `.lab/writing/framing.md`.
+- Read `.lab/config/workflow.json` before drafting and enforce its `paper_language` and `paper_format`.
+- Read `.lab/context/mission.md`, `.lab/context/decisions.md`, and `.lab/context/evidence-index.md` before drafting.
 - Write one paper section or one explicit subproblem per round.
 - Bind each claim to evidence from `report`, iteration reports, or normalized summaries.
-- Write planning artifacts with `.superlab/templates/paper-plan.md`, `.superlab/templates/paper-section.md`, and `.superlab/templates/write-iteration.md`.
-- Write final manuscript artifacts with `.superlab/templates/paper.tex` and `.superlab/templates/paper-section.tex`.
+- Write planning artifacts with `.lab/.managed/templates/paper-plan.md`, `.lab/.managed/templates/paper-section.md`, and `.lab/.managed/templates/write-iteration.md`.
+- Write final manuscript artifacts with `.lab/.managed/templates/paper.tex` and `.lab/.managed/templates/paper-section.tex`.
 - Use the vendored paper-writing references under `skills/lab/references/paper-writing/`.
 - Load only the current section guide, plus `paper-review.md` and `does-my-writing-flow-source.md`.
 - Build a compact mini-outline before prose.
@@ -116,20 +132,21 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - Before finalizing a round, append and answer the five-dimension self-review checklist and revise unresolved items.
 - Apply paper-writing discipline without changing experimental truth.
 - If the evidence is insufficient, stop and route back to `review` or `iterate`.
-- Update `.superlab/context/`state.md` and `.superlab/context/`evidence-index.md` when section-level claim status changes.
+- Update `.lab/context/state.md` and `.lab/context/evidence-index.md` when section-level claim status changes.
 
 ## Hard Gates
 
 - No implementation before `/lab:spec`.
 - No unconstrained iteration. Every `/lab:iterate` campaign must declare done criteria and `max_iterations`.
 - No final report without validated normalized results.
-- No paper-writing round without stable report artifacts, evidence links, and LaTeX manuscript output.
+- No paper-writing round without stable report artifacts, an approved framing artifact, evidence links, and LaTeX manuscript output.
 
 ## References
 
 - Workflow summary: `.codex/skills/lab/references/workflow.md` or `.claude/skills/lab/references/workflow.md`
 - Brainstorming integration: `.codex/skills/lab/references/brainstorming-integration.md` or `.claude/skills/lab/references/brainstorming-integration.md`
 - Idea stage guide: `.codex/skills/lab/stages/idea.md` or `.claude/skills/lab/stages/idea.md`
+- Framing stage guide: `.codex/skills/lab/stages/framing.md` or `.claude/skills/lab/stages/framing.md`
 - Spec stage guide: `.codex/skills/lab/stages/spec.md` or `.claude/skills/lab/stages/spec.md`
 - Run stage guide: `.codex/skills/lab/stages/run.md` or `.claude/skills/lab/stages/run.md`
 - Iterate stage guide: `.codex/skills/lab/stages/iterate.md` or `.claude/skills/lab/stages/iterate.md`
@@ -139,7 +156,7 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - Paper-writing integration: `.codex/skills/lab/references/paper-writing-integration.md` or `.claude/skills/lab/references/paper-writing-integration.md`
 - Vendored paper-writing references: `.codex/skills/lab/references/paper-writing/{abstract,introduction,related-work,method,experiments,conclusion,paper-review,does-my-writing-flow-source}.md` or `.claude/skills/lab/references/paper-writing/{abstract,introduction,related-work,method,experiments,conclusion,paper-review,does-my-writing-flow-source}.md`
 - Command adapters: the installed `/lab:*` command assets
-- Shared workflow config: `.superlab/config/workflow.json`
-- Shared project context: `.superlab/context/`{mission,state,decisions,evidence-index,open-questions}.md`
-- Templates: `.superlab/templates/`
-- Scripts: `.superlab/scripts/`
+- Shared workflow config: `.lab/config/workflow.json`
+- Shared project context: `.lab/context/{mission,state,decisions,evidence-index,open-questions}.md`
+- Templates: `.lab/.managed/templates/`
+- Scripts: `.lab/.managed/scripts/`

package/package-assets/shared/skills/lab/references/paper-writing/abstract.md

@@ -36,10 +36,6 @@ Introduce the technical challenge, then use one to two sentences to present the
 3. The technical term must be easy to understand; readers should not feel a jump.
 4. This ability is very important for writing a good abstract.
 
-Version 1 local cite:
-
-1. `references/examples/abstract/template-a.md`
-
 ## Version 2: Challenge -> Insight -> Contribution
 
 Introduce the technical challenge, then use one to two sentences to present the insight for solving the challenge, and then one sentence to present the technical contribution that implements this insight.
@@ -61,10 +57,6 @@ Introduce the technical challenge, then use one to two sentences to present the
 4. The technical term must be easy to understand; do not create a jump in reading.
 5. This ability is very important for writing a good abstract.
 
-Version 2 local cite:
-
-1. `references/examples/abstract/template-b.md`
-
 ## Version 3: Multiple Contributions
 
 Version 3: When there are multiple technical contributions, describe each contribution together with its technical advantage.
@@ -83,16 +75,9 @@ Version 3: When there are multiple technical contributions, describe each contri
 1. When there are multiple technical contributions, describe each contribution together with its technical advantage.
 2. The ability to express "contribution + advantage" in one sentence is very important for writing a good abstract.
 
-Version 3 local cite:
-
-1. `references/examples/abstract/template-c.md`
-
-## Example Bank
+## Usage Note
 
-1. `references/examples/abstract-examples.md`
-2. `references/examples/abstract/template-a.md`
-3. `references/examples/abstract/template-b.md`
-4. `references/examples/abstract/template-c.md`
+This vendored guide is intentionally self-contained. The original example-bank files are not bundled in `superlab`, so use the structures and checklists in this document directly rather than chasing external example paths.
 
 ## Abstract Quality Checklist
 

package/package-assets/shared/skills/lab/references/paper-writing/introduction.md

@@ -91,10 +91,6 @@ Sentence skeleton:
 1. `[xxx task] targets at recovering/reconstructing/estimating [xxx output] from [xxx input].`
 2. `[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].`
 
-Local cite:
-
-1. `references/examples/introduction/version-1-task-then-application.md`
-
 ### Version 2
 
 `Version 2: If the task is already familiar to most readers, introduce applications directly.`
@@ -109,10 +105,6 @@ Sentence skeleton:
 
 1. `[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].`
 
-Local cite:
-
-1. `references/examples/introduction/version-2-application-first.md`
-
 ### Version 3
 
 `Version 3: Introduce applications of the general task first, then introduce the specific task setting. (Personally recommended when the setting is relatively new.)`
@@ -128,10 +120,6 @@ Sentence skeleton:
 1. `[general task] has a variety of applications such as [xxx], [xxx], and [xxx].`
 2. `This paper focuses on the specific setting of recovering/reconstructing/estimating [xxx output] from [xxx input].`
 
-Local cite:
-
-1. `references/examples/introduction/version-3-general-to-specific-setting.md`
-
 ### Version 4
 
 `Version 4: If the task is familiar, introduce applications directly and expose the target technical challenge in the opening paragraph via previous methods (failure cases / target metric improvements).`
@@ -156,10 +144,6 @@ Expert note:
 3. Typical Version 4 flow: Part 1 (task + application and directly expose challenge via previous methods 1) -> Part 2 (previous methods 2 try to solve it but still fail) -> Part 3 (our method).
 4. More common general flow: Part 1 (task + application) -> Part 2 (previous methods 1 + limitation) -> Part 3 (previous methods 2 + limitation; here the target challenge emerges) -> Part 4 (our method).
 
-Local cite:
-
-1. `references/examples/introduction/version-4-open-with-challenge.md`
-
 ## Part B: Introduce Technical Challenge for Previous Methods (Very Important)
 
 Purpose:
@@ -200,10 +184,6 @@ Sentence skeleton:
 3. `Recently, ... methods ... However, they ... because ...`
 4. `To overcome this challenge, ... methods ... However, they ... because ...`
 
-Local cite:
-
-1. `references/examples/introduction/technical-challenge-version-1-existing-task.md`
-
 ### Technical-Challenge Version 2 (existing task + our insight seen in traditional methods)
 
 `Version 2: For existing tasks, when our insight has historical roots in traditional methods, use that line as conceptual backing and then show why new methods still fail.`
@@ -223,10 +203,6 @@ Sentence skeleton:
 3. `However, these methods still ... because ...`
 4. `To overcome this challenge, newer methods ... However, they ... because ...`
 
-Local cite:
-
-1. `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
-
 ### Technical-Challenge Version 3 (novel task, no direct methods)
 
 `Version 3: For novel tasks without direct prior methods, define the challenge directly and decompose it into several concrete challenge points.`
@@ -245,10 +221,6 @@ Sentence skeleton:
 3. `Second, ...`
 4. `Finally, ...`
 
-Local cite:
-
-1. `references/examples/introduction/technical-challenge-version-3-novel-task.md`
-
 ## Part C: Introduce Our Pipeline for Solving the Challenge
 
 Key questions before writing:
@@ -287,10 +259,6 @@ Sentence skeleton:
 5. `In contrast to previous methods, ...`
 6. `Another advantage of the proposed method is that ...`
 
-Local cite:
-
-1. `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
-
 ### Pipeline Version 2
 
 `Version 2: Two contributions, and one teaser figure to present the basic idea.`
@@ -313,10 +281,6 @@ Sentence skeleton:
 6. `However, ...` (remaining challenge)
 7. `Specifically, ...` (contribution 2)
 
-Local cite:
-
-1. `references/examples/introduction/pipeline-version-2-two-contributions.md`
-
 ### Pipeline Version 3
 
 `Version 3: Build on a prior pipeline and introduce one new module, with a teaser figure for the basic idea.`
@@ -337,10 +301,6 @@ Sentence skeleton:
 4. `Considering that ..., we introduce ...`
 5. `In contrast to ..., our module ...`
 
-Local cite:
-
-1. `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
-
 ### Pipeline Version 4
 
 `Version 4: Contribution comes from one important observation. Introduce key innovation first, then a listener-friendly observation as motivation, then method details, then benefits.`
@@ -359,10 +319,6 @@ Sentence skeleton:
 3. `Considering that ..., we ...`
 4. `This leads to ... and achieves ...`
 
-Local cite:
-
-1. `references/examples/introduction/pipeline-version-4-observation-driven.md`
-
 ### Not Recommended Writing
 
 `Not recommended: If the method is simple, do not hide concrete method design in Introduction and only describe abstract insights to make the work look novel.`
@@ -379,25 +335,9 @@ Why not recommended (writing structure warning):
 2. Introducing many new terms without mechanism-level explanation creates a novelty illusion.
 3. Reviewers may interpret this as shallow or incremental work.
 
-Local cite:
-
-1. `references/examples/introduction/pipeline-not-recommended-abstract-only.md`
-
-## Example Bank
-
-1. `references/examples/introduction-examples.md`
-2. `references/examples/introduction/version-1-task-then-application.md`
-3. `references/examples/introduction/version-2-application-first.md`
-4. `references/examples/introduction/version-3-general-to-specific-setting.md`
-5. `references/examples/introduction/version-4-open-with-challenge.md`
-6. `references/examples/introduction/technical-challenge-version-1-existing-task.md`
-7. `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
-8. `references/examples/introduction/technical-challenge-version-3-novel-task.md`
-9. `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
-10. `references/examples/introduction/pipeline-version-2-two-contributions.md`
-11. `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
-12. `references/examples/introduction/pipeline-version-4-observation-driven.md`
-13. `references/examples/introduction/pipeline-not-recommended-abstract-only.md`
+## Usage Note
+
+This vendored guide keeps the introduction patterns but omits the original example-bank files. Treat the templates and sentence skeletons here as the canonical reference inside `superlab`.
 
 ## Quick Quality Checklist