superlab 0.1.0 → 0.1.1

package/README.md

@@ -85,7 +85,6 @@ This language setting only affects installed command and skill text shown to the
 - Python 3.10+
 - Git
 - OpenSpec CLI installed and available as `openspec-cn`
-- For `/lab:write`: install the companion `research-paper-writing` skill from `Research-Paper-Writing-Skills`
 
 Check the dependency with:
 
@@ -93,10 +92,7 @@ Check the dependency with:
 bash .superlab/scripts/check_openspec.sh
 ```
 
-`/lab:write` expects the companion skill at one of these locations:
-
-- Codex: `~/.codex/skills/research-paper-writing/`
-- Claude project: `.claude/skills/research-paper-writing/`
+`/lab:write` ships with vendored paper-writing references under the installed `lab` skill, so it does not depend on an extra runtime skill installation.
 
 ## Command Set
 
@@ -107,7 +103,7 @@ bash .superlab/scripts/check_openspec.sh
 - `/lab:review` audits documents and results in reviewer mode.
 - `/lab:report` produces the final report from accumulated artifacts.
 - `/lab:write` converts stable report artifacts into paper sections through small writing rounds.
-  It reads the exact upstream section references from the companion `research-paper-writing` skill.
+  It reads vendored section references derived from `Research-Paper-Writing-Skills`.
 
 See the source command docs in [commands/codex/lab.md](/Users/zhouhao119/coding/write/commands/codex/lab.md) and [commands/claude/lab.md](/Users/zhouhao119/coding/write/commands/claude/lab.md). The npm package installs real command assets from `package-assets/`.
 
@@ -141,6 +137,7 @@ See the source command docs in [commands/codex/lab.md](/Users/zhouhao119/coding/
 ## Helper Scripts
 
 - `scripts/check_openspec.sh` checks whether OpenSpec CLI is available.
+- `scripts/openspec_change.sh` wraps common OpenSpec change commands for instructions, status, and validation.
 - `scripts/register_run.py` records run metadata in a JSON registry.
 - `scripts/eval_report.py` normalizes metrics into a comparable summary.
 - `scripts/summarize_iterations.py` rolls multiple iteration summaries into one file.
@@ -157,4 +154,4 @@ See the source command docs in [commands/codex/lab.md](/Users/zhouhao119/coding/
 
 ## Attribution
 
-`superlab` is OpenSpec-compatible and borrows workflow discipline ideas from OpenSpec, superpowers, and Ralph Wiggum style bounded iteration. It is an independent workflow package, not an official OpenSpec project.
+`superlab` is OpenSpec-compatible and borrows workflow discipline ideas from OpenSpec, superpowers, and Ralph Wiggum style bounded iteration. Its vendored writing references are adapted from `Research-Paper-Writing-Skills`. It is an independent workflow package, not an official OpenSpec project.

package/README.zh-CN.md

@@ -83,7 +83,6 @@ superlab init --lang en
 - Python 3.10+
 - Git
 - OpenSpec CLI，并且命令名为 `openspec-cn`
-- `/lab:write` 还依赖 `Research-Paper-Writing-Skills` 提供的 companion `research-paper-writing` skill
 
 检查 OpenSpec CLI：
 
@@ -91,10 +90,7 @@ superlab init --lang en
 bash .superlab/scripts/check_openspec.sh
 ```
 
-`/lab:write` 预期 companion skill 位于：
-
-- Codex: `~/.codex/skills/research-paper-writing/`
-- Claude 项目: `.claude/skills/research-paper-writing/`
+`/lab:write` 自带 vendored 的 paper-writing 章节参考，不再依赖额外安装一个运行时写作 skill。
 
 ## 命令集合
 
@@ -105,7 +101,7 @@ bash .superlab/scripts/check_openspec.sh
 - `/lab:review` 以审稿人模式检查方法、对照、公平性、泄漏和统计问题。
 - `/lab:report` 根据累积工件生成最终实验报告。
 - `/lab:write` 把稳定的 report 工件转成论文 section，并按小步方式逐轮修改。
-  它会直接读取 companion `research-paper-writing` skill 里的原始章节参考。
+  它会读取随 `lab` 一起安装的 vendored 章节参考，这些参考来源于 `Research-Paper-Writing-Skills`。
 
 ## 使用流程
 
@@ -131,6 +127,7 @@ bash .superlab/scripts/check_openspec.sh
 - `skills/lab/` 是仓库开发时使用的共享 workflow 定义。
 - `templates/` 是研究工件模板。
 - `scripts/` 是运行登记、评估汇总和结果校验脚本。
+- 其中 `scripts/openspec_change.sh` 对 `instructions/status/validate` 做了一个最小 OpenSpec wrapper。
 - `tests/` 是脚本与安装器测试。
 - `examples/` 是最小端到端示例。
 - `docs/release.md` 是发布到 npm 的操作说明。
@@ -139,4 +136,4 @@ bash .superlab/scripts/check_openspec.sh
 
 ## 致谢
 
-`superlab` 兼容 OpenSpec，并借鉴了 OpenSpec、superpowers 和 Ralph Wiggum 的流程纪律。它是一个独立的开源工作流包，不是 OpenSpec 官方项目。
+`superlab` 兼容 OpenSpec，并借鉴了 OpenSpec、superpowers 和 Ralph Wiggum 的流程纪律。随包提供的写作参考改编自 `Research-Paper-Writing-Skills`。它是一个独立的开源工作流包，不是 OpenSpec 官方项目。

package/lib/i18n.cjs

@@ -26,12 +26,12 @@ const ZH_CONTENT = {
   [path.join(".codex", "prompts", "lab-idea.md")]: codexPrompt(
     "在进入规格前调研并打磨论文或实验想法",
     "idea 或 research problem",
-    "使用已安装的 `lab` 技能：`.codex/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:idea` 阶段。它必须先调研相关文献、数据集、指标和 baseline，再进行批评与收敛，不得在此阶段直接实现代码。"
+    "使用已安装的 `lab` 技能：`.codex/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:idea` 阶段。它必须先用清晰简洁的话定义问题与失败场景，说明现有方法哪里不够、我们的想法为何更好，再做 idea classification、contribution category、breakthrough level 的归类，并收束出至少三个一眼就有意义的点，最后保留进入 `/lab:spec` 前的 approval gate。"
   ),
   [path.join(".codex", "prompts", "lab-spec.md")]: codexPrompt(
     "把已批准的 idea 转成 OpenSpec spec-driven 工件",
     "approved idea context",
-    "使用已安装的 `lab` 技能：`.codex/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:spec` 阶段。它必须要求 OpenSpec CLI、生成 proposal/design/spec/tasks，并在规格完成前禁止进入实现。"
+    "使用已安装的 `lab` 技能：`.codex/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:spec` 阶段。它必须要求 OpenSpec CLI、围绕 active change 生成 proposal/design/spec/tasks，并运行 instructions/status/validate 后才能算完成。"
   ),
   [path.join(".codex", "prompts", "lab-run.md")]: codexPrompt(
     "执行最小可行实验并标准化输出",
@@ -41,7 +41,7 @@ const ZH_CONTENT = {
   [path.join(".codex", "prompts", "lab-iterate.md")]: codexPrompt(
     "在固定成功标准下执行有边界的实验迭代",
     "iteration mission",
-    "使用已安装的 `lab` 技能：`.codex/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:iterate` 阶段。它必须冻结 mission、只做小步改动、每轮生成评估和 iteration report，并在达标或到上限时停止。"
+    "使用已安装的 `lab` 技能：`.codex/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:iterate` 阶段。它必须冻结 mission、声明 completion_promise、只做小步改动、每轮生成评估和 iteration report；若风险连续两轮升高则切 diagnostic mode，并在失败结束时记录 blockers 与 next actions。"
   ),
   [path.join(".codex", "prompts", "lab-review.md")]: codexPrompt(
     "以审稿人模式审查研究方案或结果",
@@ -56,19 +56,19 @@ const ZH_CONTENT = {
   [path.join(".codex", "prompts", "lab-write.md")]: codexPrompt(
     "把验证过的研究工件转成论文 section，并按小步方式修订",
     "section or writing target",
-    "使用已安装的 `lab` 技能：`.codex/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:write` 阶段。它必须先读取 companion `research-paper-writing` 技能中与当前 section 对应的参考文件，并结合 `paper-review.md` 与 `does-my-writing-flow-source.md` 后，再只修改一个 section。"
+    "使用已安装的 `lab` 技能：`.codex/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:write` 阶段。它必须先读取 `.codex/skills/lab/references/paper-writing/` 下与当前 section 对应的参考文件，并结合 `paper-review.md` 与 `does-my-writing-flow-source.md`，先写 mini-outline，再只修改一个 section。"
   ),
   [path.join(".claude", "commands", "lab", "idea.md")]: claudeCommand(
     "LAB: Idea",
     "在进入规格前调研并打磨论文或实验想法",
     "workflow, research, idea",
-    "使用已安装的 `lab` 技能：`.claude/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:idea` 阶段。它必须先调研相关文献、数据集、指标和 baseline，再进行批评与收敛，不得在此阶段直接实现代码。"
+    "使用已安装的 `lab` 技能：`.claude/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:idea` 阶段。它必须先用清晰简洁的话定义问题与失败场景，说明现有方法哪里不够、我们的想法为何更好，再做 idea classification、contribution category、breakthrough level 的归类，并收束出至少三个一眼就有意义的点，最后保留进入 `/lab:spec` 前的 approval gate。"
   ),
   [path.join(".claude", "commands", "lab", "spec.md")]: claudeCommand(
     "LAB: Spec",
     "把已批准的 idea 转成 OpenSpec spec-driven 工件",
     "workflow, research, spec",
-    "使用已安装的 `lab` 技能：`.claude/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:spec` 阶段。它必须要求 OpenSpec CLI、生成 proposal/design/spec/tasks，并在规格完成前禁止进入实现。"
+    "使用已安装的 `lab` 技能：`.claude/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:spec` 阶段。它必须要求 OpenSpec CLI、围绕 active change 生成 proposal/design/spec/tasks，并运行 instructions/status/validate 后才能算完成。"
   ),
   [path.join(".claude", "commands", "lab", "run.md")]: claudeCommand(
     "LAB: Run",
@@ -80,7 +80,7 @@ const ZH_CONTENT = {
     "LAB: Iterate",
     "在固定成功标准下执行有边界的实验迭代",
     "workflow, research, iterate",
-    "使用已安装的 `lab` 技能：`.claude/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:iterate` 阶段。它必须冻结 mission、只做小步改动、每轮生成评估和 iteration report，并在达标或到上限时停止。"
+    "使用已安装的 `lab` 技能：`.claude/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:iterate` 阶段。它必须冻结 mission、声明 completion_promise、只做小步改动、每轮生成评估和 iteration report；若风险连续两轮升高则切 diagnostic mode，并在失败结束时记录 blockers 与 next actions。"
   ),
   [path.join(".claude", "commands", "lab", "review.md")]: claudeCommand(
     "LAB: Review",
@@ -98,7 +98,7 @@ const ZH_CONTENT = {
     "LAB: Write",
     "把验证过的研究工件转成论文 section，并按小步方式修订",
     "workflow, research, writing",
-    "使用已安装的 `lab` 技能：`.claude/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:write` 阶段。它必须先读取 companion `research-paper-writing` 技能中与当前 section 对应的参考文件，并结合 `paper-review.md` 与 `does-my-writing-flow-source.md` 后，再只修改一个 section。"
+    "使用已安装的 `lab` 技能：`.claude/skills/lab/SKILL.md`。\n\n本命令运行 `/lab:write` 阶段。它必须先读取 `.claude/skills/lab/references/paper-writing/` 下与当前 section 对应的参考文件，并结合 `paper-review.md` 与 `does-my-writing-flow-source.md`，先写 mini-outline，再只修改一个 section。"
   ),
 };
 
@@ -121,6 +121,11 @@ description: 严格研究工作流，覆盖 idea、spec、run、iterate、review
 - 关键决策必须落盘，不能只留在聊天里。
 - 区分“来源事实”和“模型假设”。
 - 保留失败实验、失败想法和局限性。
+- \`/lab:write\` 使用内置 vendored paper-writing references，不依赖外部写作 skill 路径。
+- \`/lab:idea\` 需要 candidate approaches 和 approval gate。
+- \`/lab:idea\` 还需要 problem/failure case、idea classification、contribution category、breakthrough level。
+- \`/lab:idea\` 还需要 existing methods 对照、why ours is different、three meaningful points。
+- \`/lab:iterate\` 需要 completion_promise 与失败退出记录。
 `,
   [path.join(".codex", "skills", "lab", "stages", "write.md")]:
 `# \`/lab:write\` 阶段指南
@@ -131,23 +136,34 @@ description: 严格研究工作流，覆盖 idea、spec、run、iterate、review
 - iteration reports
 - normalized summaries
 - reviewer notes（如有）
-- 当前 section 对应的 companion \`research-paper-writing\` 参考文件
+- \`skills/lab/references/paper-writing/\` 下 vendored 的章节参考文件
 
-## Companion References
+## Required References
 
 按当前目标加载精确章节文件：
 
-- abstract -> \`research-paper-writing/references/abstract.md\`
-- introduction -> \`research-paper-writing/references/introduction.md\`
-- related work -> \`research-paper-writing/references/related-work.md\`
-- method -> \`research-paper-writing/references/method.md\`
-- experiments -> \`research-paper-writing/references/experiments.md\`
-- conclusion -> \`research-paper-writing/references/conclusion.md\`
+- abstract -> \`skills/lab/references/paper-writing/abstract.md\`
+- introduction -> \`skills/lab/references/paper-writing/introduction.md\`
+- related work -> \`skills/lab/references/paper-writing/related-work.md\`
+- method -> \`skills/lab/references/paper-writing/method.md\`
+- experiments -> \`skills/lab/references/paper-writing/experiments.md\`
+- conclusion -> \`skills/lab/references/paper-writing/conclusion.md\`
 
 每轮还必须运行：
 
-- flow check -> \`research-paper-writing/references/does-my-writing-flow-source.md\`
-- reviewer pass -> \`research-paper-writing/references/paper-review.md\`
+- flow check -> \`skills/lab/references/paper-writing/does-my-writing-flow-source.md\`
+- reviewer pass -> \`skills/lab/references/paper-writing/paper-review.md\`
+
+## Small-Step Writing Rules
+
+- 每轮只改一个 section 或一个边界清晰的小节。
+- 只加载当前 section guide，不要一次加载所有章节参考。
+- 先写 mini-outline，再写 prose。
+- 每个 subsection 在适用时必须显式交代 motivation、design、technical advantage。
+- 避免写成“在一个 naive baseline 上不断打补丁”的叙述风格。
+- 全文术语保持一致。
+- 若 claim 没有结果支撑，必须削弱或删除。
+- 每轮结束前都要补五维自评并处理未解决问题。
 `,
 };
 

package/package-assets/claude/commands/lab/write.md

@@ -7,4 +7,4 @@ tags: [workflow, research, writing]
 
 Use the installed `lab` skill at `.claude/skills/lab/SKILL.md`.
 
-This command runs the `/lab:write` stage. It must read the matching section reference from the companion `research-paper-writing` skill, plus `paper-review.md` and `does-my-writing-flow-source.md`, before revising one section.
+This command runs the `/lab:write` stage. It must read the matching section reference from `.claude/skills/lab/references/paper-writing/`, plus `paper-review.md` and `does-my-writing-flow-source.md`, build a mini-outline, and then revise only one section.

package/package-assets/codex/prompts/lab-write.md

@@ -5,4 +5,4 @@ argument-hint: section or writing target
 
 Use the installed `lab` skill at `.codex/skills/lab/SKILL.md`.
 
-This command runs the `/lab:write` stage. It must read the matching section reference from the companion `research-paper-writing` skill, plus `paper-review.md` and `does-my-writing-flow-source.md`, before revising one section.
+This command runs the `/lab:write` stage. It must read the matching section reference from `.codex/skills/lab/references/paper-writing/`, plus `paper-review.md` and `does-my-writing-flow-source.md`, build a mini-outline, and then revise only one section.

package/package-assets/shared/scripts/openspec_change.sh

@@ -0,0 +1,50 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+if ! command -v openspec-cn >/dev/null 2>&1; then
+  echo "OpenSpec CLI not found. Install and expose 'openspec-cn' before using this helper." >&2
+  exit 1
+fi
+
+if [[ $# -lt 2 ]]; then
+  echo "Usage:" >&2
+  echo "  openspec_change.sh instructions <artifact> <change-id>" >&2
+  echo "  openspec_change.sh status <change-id>" >&2
+  echo "  openspec_change.sh validate <change-id>" >&2
+  exit 2
+fi
+
+subcommand="$1"
+shift
+
+case "$subcommand" in
+  instructions)
+    if [[ $# -ne 2 ]]; then
+      echo "Usage: openspec_change.sh instructions <artifact> <change-id>" >&2
+      exit 2
+    fi
+    artifact="$1"
+    change_id="$2"
+    exec openspec-cn instructions "$artifact" --change "$change_id"
+    ;;
+  status)
+    if [[ $# -ne 1 ]]; then
+      echo "Usage: openspec_change.sh status <change-id>" >&2
+      exit 2
+    fi
+    change_id="$1"
+    exec openspec-cn status --change "$change_id"
+    ;;
+  validate)
+    if [[ $# -ne 1 ]]; then
+      echo "Usage: openspec_change.sh validate <change-id>" >&2
+      exit 2
+    fi
+    change_id="$1"
+    exec openspec-cn validate "$change_id"
+    ;;
+  *)
+    echo "Unsupported subcommand: $subcommand" >&2
+    exit 2
+    ;;
+esac

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

@@ -21,14 +21,24 @@ 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.
+- State the problem, the failure case, and why the problem matters before proposing solutions.
+- Classify the idea by contribution category and breakthrough level.
+- Compare against existing methods explicitly and state why the idea should be better.
 - Distinguish sourced evidence from generated innovation claims.
+- End with three meaningful points that are clear, short, and easy to scan.
+- 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`.
 - Do not implement code in this stage.
 
 ### `/lab:spec`
 
 - Require `bash scripts/check_openspec.sh`.
+- Use OpenSpec CLI as the execution path, not just as naming inspiration:
+  - initialize OpenSpec if the project is not initialized yet
+  - identify or create the active change
+  - use `openspec-cn instructions`, `openspec-cn status`, and `openspec-cn validate` while drafting and applying the spec
 - Convert the approved idea into OpenSpec `spec-driven` artifacts using `.superlab/templates/proposal.md`, `.superlab/templates/design.md`, `.superlab/templates/spec.md`, and `.superlab/templates/tasks.md`.
 - Do not skip task definition.
 
@@ -47,11 +57,13 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
   - primary metric
   - success threshold
   - verification commands
+  - completion_promise
   - maximum iteration count
 - Only change implementation hypotheses within the loop.
 - Require a normalized evaluation report each round.
+- Switch to diagnostic mode if risk increases for two consecutive rounds.
 - Write round reports with `.superlab/templates/iteration-report.md`.
-- Stop at threshold success or iteration cap.
+- Stop at threshold success or iteration cap, and record blockers plus next-best actions when the campaign ends without success.
 
 ### `/lab:review`
 
@@ -72,7 +84,13 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - Write one paper section or one explicit subproblem per round.
 - Bind each claim to evidence from `report`, iteration reports, or normalized summaries.
 - Write paper artifacts with `.superlab/templates/paper-plan.md`, `.superlab/templates/paper-section.md`, and `.superlab/templates/write-iteration.md`.
-- Use the companion `research-paper-writing` skill references for the current section and required review passes.
+- 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.
+- For each subsection, explicitly cover motivation, design, and technical advantage when applicable.
+- Keep terminology stable across rounds and sections.
+- If a claim is not supported by evidence, weaken or remove it.
+- 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`.
 
@@ -94,7 +112,7 @@ Use this skill when the user invokes `/lab:*` or asks for the structured researc
 - Report stage guide: `.codex/skills/lab/stages/report.md` or `.claude/skills/lab/stages/report.md`
 - Write stage guide: `.codex/skills/lab/stages/write.md` or `.claude/skills/lab/stages/write.md`
 - Paper-writing integration: `.codex/skills/lab/references/paper-writing-integration.md` or `.claude/skills/lab/references/paper-writing-integration.md`
-- Companion references: `research-paper-writing/references/{abstract,introduction,related-work,method,experiments,conclusion,paper-review,does-my-writing-flow-source}.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
 - Templates: `.superlab/templates/`
 - Scripts: `.superlab/scripts/`

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

@@ -0,0 +1,102 @@
+# Abstract Writing Guide
+
+## Goal
+
+Write a strong abstract by doing three things repeatedly:
+
+1. Think through the abstract logic first.
+2. Follow one template (Version 1/2/3 below).
+3. Revise the abstract many times.
+
+## Pre-Writing Questions (Important)
+
+Answer these before writing:
+
+1. What technical problem do we solve, and why is there no well-established solution? (important)
+2. What is our technical contribution?
+3. Why can our method work in essence?
+4. What technical advantage and new insight do we provide? (important)
+
+## Version 1: Challenge -> Contribution
+
+Introduce the technical challenge, then use one to two sentences to present the technical contribution that solves the challenge.
+
+### Structure
+
+1. Task.
+2. Technical challenge for previous methods.
+3. One to two sentences introducing the technical contribution for solving the challenge.
+4. Benefits of the technical contribution.
+5. Experiment summary.
+
+### Expert Notes
+
+1. Discuss previous work around the technical challenge that we actually solve.
+2. For the contribution sentence(s), usually mention the technical term/name only; do not explain every detailed step.
+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.
+
+### Structure
+
+1. Task.
+2. Technical challenge for previous methods.
+3. One sentence introducing the insight for solving the challenge.
+4. One to two sentences introducing the technical contribution that implements the insight.
+5. Benefits of technical novelty.
+6. Experiment summary.
+
+### Expert Notes
+
+1. Discuss previous work around the technical challenge that we actually solve.
+2. Introduce the insight in one clear sentence.
+3. For the implementation sentence(s), usually mention the technical term/name only; do not explain every detailed step.
+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.
+
+### Structure
+
+1. Task.
+2. If needed, one contrast sentence about prior methods.
+3. Contribution sentence 1 + technical advantage.
+4. Contribution sentence 2 + technical advantage.
+5. Contribution sentence 3 + technical advantage.
+6. Experiment summary.
+
+### Expert Notes
+
+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
+
+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`
+
+## Abstract Quality Checklist
+
+1. Can a reader identify task, challenge, insight/contribution, and results in one pass?
+2. Are all major claims supported by experiments?
+3. Are technical names self-contained and readable?
+4. Is there any sentence that mixes too many messages?

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

@@ -0,0 +1,35 @@
+# Conclusion Writing Guide
+
+## Goal
+
+Close the paper with clear takeaways and credible limitations.
+
+## Structure
+
+1. Restate solved problem and core technical idea.
+2. Summarize strongest evidence from experiments.
+3. State practical impact or new insight.
+4. Add limitation paragraph.
+5. End with concrete future direction.
+
+## Limitation Guidance
+
+Prefer limitations tied to task goal/setting boundaries, for example:
+
+1. Data regime limitation (e.g., only short sequences).
+2. Assumption limitation (e.g., controlled viewpoints only).
+3. Deployment scope limitation (e.g., specific sensor setup).
+
+Avoid framing conclusion around fixable implementation flaws unless they critically define your method's scope.
+
+## Distinguish Limitation Types
+
+1. Technical defect: underperforms strong baselines on key metrics or causes unacceptable tradeoff.
+2. Scope limitation: bounded by current task setting and still competitive vs. current SOTA.
+
+## Template
+
+1. This paper addresses [problem] by proposing [method].
+2. The key idea is [core insight], which enables [main benefit].
+3. Experiments show [main gains] across [datasets/settings].
+4. A current limitation is [scope boundary], and extending to [future setting] is an important next step.

package/package-assets/shared/skills/lab/references/paper-writing/does-my-writing-flow-source.md

@@ -0,0 +1,45 @@
+# Does My Writing Flow? 
+
+Note: This file stores the source content extracted from the PDF, with light formatting cleanup for Markdown readability.
+
+## Original Content
+
+### Does My Writing Flow?
+
+One of the most frequent questions writers ask themselves or others is "does my writing flow?" Other variations of this question include "does this make sense?" and "can you understand what I am saying?" The term flow is a vague term that writers use when describing some concern of clarity, coherence, or conciseness. However vague this term may be, writers know it is a very important concern about their work. If you find yourself concerned about the flow of your writing, then here are some strategies to improve it.
+
+1. Pretend you are the reader of your paper.
+
+   - Often when we write, our work makes sense to us because we are the ones who create it. However, at a certain point in the writing process, our writing may become unclear even to us. When we as authors begin to lose sight of our paper's train of thought, other readers are sure to be confused as well.
+   - By looking at your paper from the perspective of a reader, you are checking and making sure your writing is clear to someone who might not be as informed of the paper's topic as you are.
+   - Some questions you might ask to place yourself in the reader's shoes are:
+     1. Would my classmates be able to understand the level of vocabulary I am using?
+     2. How do my body paragraphs connect back to my thesis, and is the connection easy to see?
+     3. Would someone not in my class understand what I am trying to say?
+2. Reverse-outlining
+
+   - Outlining is not only a great pre-writing exercise, but it also can serve as a great post-writing tool. Reverse-outlining means just what it sounds like. It breaks down an already written essay into its basic parts (such as thesis statement, topic-sentences, and the points of proof/explanation used within your body paragraphs), and it allows a writer to see how well topic sentences and paragraphs fit into an essay.
+   - Here is how to reverse outline:
+     1. Write down the thesis statement.
+     2. Write down each topic sentence of each body paragraph.
+     3. Also write down the main points of evidence or explanation used within your body paragraphs.
+     4. Check every topic sentence and make sure it is clearly related to a part of your thesis statement.
+     5. Check all points of proof/explanation and make sure they pertain to the topic of the paragraph and provide adequate support.
+     6. If there is a topic sentence that does not clearly relate to the thesis statement, then either revise it and its supporting points of proof/explanation or take it out entirely.
+   - If it is easy to write a reverse outline, then it's a good sign that your paper is well-organized. If you have a hard time creating a reverse outline, then your thesis statement and topic-sentences might be unclear.
+3. Add headings and sections to your paper.
+
+   - If you are not up to making a complete outline (or if you are not very good at outlining - lots of people aren't), then no need to feel bad. You can add headings and sections to your paper. This method achieves a similar effect to reverse outlining.
+   - By splitting a paper into sections and sub-sections with headings, the paper is telling the reader what each part is all about.
+   - For most papers, headings are not necessary. However, you can still make use of them as a tool for drafting and revision. By adding headers to the different sections of a paper, you can easily begin to see the main parts of your paper and how they work together.
+4. Use transitions or "flow" keywords.
+
+   - Using appropriate transition words improves the flow of your paper. These words act as guide posts, indicating the relationship between thoughts, sentences, or paragraphs. You can always make your essay flow better by adding appropriate transitional words and phrases.
+   - Transitional words and phrases:
+     - To show causes and effects: accordingly, as a result, because, consequently, hence, so, then, therefore, thus
+     - To show comparison: also, in the same way, likewise, similarly
+     - To show contrasts or exceptions: although, but, even though, however, in contrast, instead, nevertheless, nonetheless, on the contrary, on the one hand ... on the other hand, still, yet
+     - To show examples: even, for example, for instance, indeed, in fact, of course, such as
+     - To show place or position: above, adjacent to, below, beyond, finally, furthermore, last, moreover, next, too
+     - To show time: after, as soon as, at first, at the same time, before, eventually, finally, immediately, later, meanwhile, next, simultaneously, so far, soon, then, thereafter
+     - To signal a summary or conclusion: as a result, as we have seen, finally, in a word, in any event, in brief, in conclusion, in other words, in short, in the end, in a final analysis, on the whole, therefore, thus, to summarize

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

@@ -0,0 +1,102 @@
+# Experiments Writing Guide
+
+## Goal
+
+Convince reviewers with complete evidence on effectiveness, causality, and practical value.
+
+## Three Core Questions
+
+1. Is the method better than strong baselines?
+   - Run comparison experiments against strong and recent baselines.
+   - Report standard metrics on the main benchmark(s).
+   - Include SOTA or strongest public methods, not only weak baselines.
+   - Keep protocol fair (same data split, preprocessing, and evaluation settings).
+2. Which modules/design choices make the gain?
+   - Run ablation studies for each key module/design choice.
+   - Use remove/replace/disable variants and report delta to full model.
+   - Include component interaction ablations when modules are coupled.
+3. How far can the method generalize under harder settings?
+   - Run demos/evaluations on harder or out-of-distribution settings.
+   - Add stress-test scenarios (more complex scenes, rarer cases, noisier inputs, or stricter constraints).
+   - Report both gains and failure modes to show realistic boundaries.
+
+## Experiment Planning
+
+```mermaid
+flowchart TB
+    A["Key Paper Claims"] --> B["What Contributions Are Claimed?"]
+    B --> C1["Contribution 1"]
+    B --> C2["Contribution 2"]
+    B --> C3["Contribution 3"]
+    C1 --> D1["Validation Experiment 1"]
+    C2 --> D2["Validation Experiment 2"]
+    C3 --> D3["Validation Experiment 3"]
+
+    E["Method Pipeline Figure"] --> F["What Modules and Parameters Matter?"]
+    F --> G1["Technical Module 1"]
+    F --> G2["Technical Module 2"]
+    F --> G3["Key Parameter 1"]
+    F --> G4["Key Parameter 2"]
+    G1 --> H1["Ablation Study 1"]
+    G2 --> H2["Ablation Study 2"]
+    G3 --> H3["Ablation Study 3"]
+    G4 --> H4["Ablation Study 4"]
+```
+
+## Experiment Section Decomposition
+
+```mermaid
+flowchart TB
+    S1["Experimental Setup"] --> S2["Validation Experiment 1"]
+    S2 --> S3["Validation Experiment 2"]
+    S3 --> S4["Ablation Studies"]
+```
+
+## Figure/Table Writing Rules
+
+`Good tables are part of experiment communication quality, not decoration.`
+
+1. Figure captions and table captions are equally important in the writing quality of Experiments.
+
+### Hard rules
+
+1. Put caption above the table.
+2. Avoid vertical lines (`|`) in tabular columns.
+3. Do not use double rules or dense `\hline` stacks.
+4. Use `booktabs` style (`\toprule`, `\midrule`, `\bottomrule`) for clean structure.
+5. Use as few horizontal rules as possible; lines should separate groups, not every row.
+6. Highlight key numbers (best/second-best or target rows) with subtle color emphasis.
+
+### Readability rules from review practice
+
+1. Label metric direction in column headers (for example `PSNR ↑`, `LPIPS ↓`).
+2. Add units when needed so values are interpretable without guessing.
+3. Align text columns left; keep numeric columns consistently aligned.
+4. Keep numeric precision consistent (same decimal places within a metric column).
+5. Group multi-dataset or multi-setting results using `\multicolumn` + `\cmidrule`, not vertical separators.
+6. One table, one message: do not mix unrelated results in a single table.
+7. If rows represent different attributes/ablations, encode that explicitly in row names or attribute columns.
+8. Keep caption focused on setting/protocol/notation, not long discussion.
+9. If there is little detail to explain, use one concise sentence to summarize the main result.
+10. For single-column figures/tables in two-column papers, prefer placing them in the right column when layout allows, so readers can enter the page from the left-top text without breaking reading flow.
+
+### Minimal LaTeX checklist
+
+1. Add packages in preamble: `\usepackage{booktabs}`, `\usepackage{colortbl,xcolor}` (and optionally `\usepackage{siunitx}` for decimal alignment).
+2. Replace `\hline`-heavy style with `\toprule/\midrule/\bottomrule`.
+3. Put `\caption{...}` before `\label{...}` and keep caption above.
+4. Use restrained highlighting; never color too many cells.
+
+## Recommended Ablation Package
+
+1. One core ablation table for all major contributions.
+2. Several focused mini-ablations for module-level design choices.
+3. Matching qualitative visual results for each important ablation.
+
+## Experimental Rigor Checklist
+
+1. Are baselines recent and relevant?
+2. Are metrics sufficient and standard for this task?
+3. Is ablation tied to every key design claim?
+4. Are claims in Abstract/Introduction supported by reported numbers?
+5. Are limitations of evaluation scope explicitly stated?