superlab 0.1.14 → 0.1.16

package/package-assets/shared/skills/lab/references/paper-writing/examples/introduction/technical-challenge-version-3-novel-task.md

@@ -0,0 +1,21 @@
+# Technical Challenge Version 3 (Novel Task)
+
+
+`Version 3: For novel tasks without direct methods, define the challenge directly and decompose it by requirement/challenge points.`
+
+```latex
+% To achieve xx goal, several requirements/challenges must be satisfied.
+%% Example: In this work, our goal is to build a model that captures such object intrinsics from a single image. This problem is challenging for three reasons.
+
+% Describe point 1
+%% Example: First, we only have a single image. This makes our work fundamentally different from existing works on 3D-aware image generation models [8, 9, 27, 28], which typically require a large dataset of thousands of instances for training. In comparison, the single image contains at most a few dozen instances, making the inference problem highly under-constrained.
+
+% Describe point 2
+%% Example: Second, these already limited instances may vary significantly in pixel values. This is because they have different poses and illumination conditions, but neither of these factors are annotated or known. We also cannot resort to existing tools for pose estimation based on structure from motion, such as COLMAP [35], because the appearance variations violate the assumptions of epipolar geometry.
+
+% Describe point 3
+%% Example: Finally, the object intrinsics we aim to infer are probabilistic, not deterministic: no two roses in the natural world are identical, and we want to capture a distribution of their geometry, texture, and material to exploit the underlying multi-view information.
+```
+
+See also:
+1. `references/examples/introduction/novel-task-challenge-decomposition.md`

package/package-assets/shared/skills/lab/references/paper-writing/examples/introduction/version-1-task-then-application.md

@@ -0,0 +1,14 @@
+# Introduction Version 1: Task First, Then Application
+
+
+`Version 1: If the task is relatively niche, introduce the task first, then introduce applications.`
+
+```latex
+% Introduce Task (if the task is very familiar, this part can be skipped)
+%% Example: Object pose estimation aims to estimate object's orientation and translation relative to a canonical frame from a single image.
+[xxx task] targets at recovering/reconstructing/estimating [xxx output] from [xxx input].
+
+% Introduce Application
+%% Example: Accurate pose estimation is essential for a variety of applications such as augmented reality, autonomous driving and robotic manipulation.
+[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].
+```

package/package-assets/shared/skills/lab/references/paper-writing/examples/introduction/version-2-application-first.md

@@ -0,0 +1,10 @@
+# Introduction Version 2: Application First
+
+
+`Version 2: If the task is already familiar to most readers, introduce applications directly.`
+
+```latex
+% Introduce Application
+%% Example: Accurate pose estimation is essential for a variety of applications such as augmented reality, autonomous driving and robotic manipulation.
+[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].
+```

package/package-assets/shared/skills/lab/references/paper-writing/examples/introduction/version-3-general-to-specific-setting.md

@@ -0,0 +1,14 @@
+# Introduction Version 3: General Application -> Specific Setting
+
+
+`Version 3: Introduce applications of the general task first, then introduce the specific task setting. (Personally recommended when the setting is relatively new.)`
+
+```latex
+% Introduce applications of the general task
+%% Example: Accurate pose estimation is essential for a variety of applications such as augmented reality, autonomous driving and robotic manipulation.
+[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].
+
+% Introduce the specific task setting
+%% Example: This paper focuses on the specific setting of recovering the 6DoF pose of an object, i.e., rotation and translation in 3D, from a single RGB image of that object.
+This paper focuses on the specific setting of recovering/reconstructing/estimating [xxx output] from [xxx input].
+```

package/package-assets/shared/skills/lab/references/paper-writing/examples/introduction/version-4-open-with-challenge.md

@@ -0,0 +1,20 @@
+# Introduction Version 4: Open with Application and Challenge
+
+
+`Version 4: If the task is familiar, introduce applications directly and expose the target technical challenge in the opening paragraph via previous methods.`
+
+Expert notes (faithful translation):
+
+1. It is often good if the opening paragraph already states what we want to solve.
+2. But this style requires suitable conditions and is less common.
+3. Usually, several prior-method paragraphs are still needed before the target challenge becomes clear.
+
+```latex
+% Introduce Application
+%% Example 1: Reconstructing 3D scenes from multi-view images is a cornerstone of many applications such as augmented reality, robotics, and autonomous driving.
+%% Example 2: Instance segmentation is the cornerstone of many computer vision tasks, such as video analysis, autonomous driving, and robotic grasping, which require both accuracy and efficiency.
+
+% Use previous methods to expose the target technical challenge
+%% Example 1: Given input images, traditional methods [43, 44, 59] generally estimate the depth map for each image based on the multi-view stereo (MVS) algorithms and then fuse estimated depth maps into 3D models. Although these methods achieve successful reconstruction in most cases, they have difficulty in handling low-textured regions, e.g., floors and walls of indoor scenes, due to the unreliable stereo matching in these regions.
+%% Example 2: Most of the state-of-the-art instance segmentation methods [18, 27, 5, 19] perform pixel-wise segmentation within a bounding box given by an object detector [36], which may be sensitive to the inaccurate bounding box. Moreover, representing an object shape as dense binary pixels generally results in costly post-processing.
+```

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

@@ -0,0 +1,25 @@
+# Introduction Examples Index
+
+All introduction example cites should point to the local files below.
+
+## A. Task and Application Versions
+
+1. Version 1: `references/examples/introduction/version-1-task-then-application.md`
+2. Version 2: `references/examples/introduction/version-2-application-first.md`
+3. Version 3: `references/examples/introduction/version-3-general-to-specific-setting.md`
+4. Version 4: `references/examples/introduction/version-4-open-with-challenge.md`
+
+## B. Technical Challenge Versions
+
+1. Version 1 (existing task): `references/examples/introduction/technical-challenge-version-1-existing-task.md`
+2. Version 2 (existing task + traditional insight backing): `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
+3. Version 3 (novel task): `references/examples/introduction/technical-challenge-version-3-novel-task.md`
+4. Novel-task decomposition examples: `references/examples/introduction/novel-task-challenge-decomposition.md`
+
+## C. Pipeline-Introduction Versions
+
+1. Version 1: `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
+2. Version 2: `references/examples/introduction/pipeline-version-2-two-contributions.md`
+3. Version 3: `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
+4. Version 4: `references/examples/introduction/pipeline-version-4-observation-driven.md`
+5. Not recommended pattern: `references/examples/introduction/pipeline-not-recommended-abstract-only.md`

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/example-of-the-three-elements.md

@@ -0,0 +1,67 @@
+# Example of the Three Elements
+
+This example uses `%` comments as annotations.  
+Each `% ...` annotation explains the paragraph(s) immediately below it.
+
+```latex
+\begin{quote}
+\textbf{Annotation rule.} In this example, each line starting with \% labels the role of the paragraph(s) directly below it.
+\end{quote}
+
+\begin{itemize}
+\item Module design (data structure)
+\item Motivation of this module
+\item Technical advantages of this module
+\item Module design (forward process)
+\end{itemize}
+
+\subsection{3.1. Structured latent codes}
+
+% Module design: introduce the module's data structure
+To control the spatial locations of latent codes with the human pose, we anchor these latent codes to a deformable human body model (SMPL) [38]. SMPL is a skinned vertex-based model, which is defined as a function of shape parameters, pose parameters, and a rigid transformation relative to the SMPL coordinate system. The function outputs a posed 3D mesh with 6890 vertices. Specifically, we define a set of latent codes \( Z = \{z_1, z_2, ..., z_{6890}\} \) on vertices of the SMPL model. For the frame \( t \), SMPL parameters \( S_t \) are estimated from the multi-view images \( \{I_t^c \mid c = 1, ..., N_c\} \) using [26]. The spatial locations of the latent codes are then transformed based on the human pose \( S_t \) for the density and color regression. Figure 3 shows an example. The dimension of latent code \( z \) is set to 16 in our experiments.
+
+% Technical advantages of this module
+Similar to the local implicit representations [25, 5, 18], the latent codes are used with a neural network to represent the local geometry and appearance of a human. Anchoring these codes to a deformable model enables us to represent a dynamic human. With the dynamic human representation, we establish a latent variable model that maps the same set of latent codes to the implicit fields of density and color at different frames, which naturally integrates observations at different frames.
+
+\subsection{3.2. Code diffusion}
+
+% Motivation of this module
+Figure 3(a) shows the process of code diffusion. The implicit fields assign the density and color to each point in the 3D space, which requires us to query the latent codes at continuous 3D locations. This can be achieved with the trilinear interpolation. However, since the structured latent codes are relatively sparse in the 3D space, directly interpolating the latent codes leads to zero vectors at most 3D points. To solve this problem, we diffuse the latent codes defined on the surface to nearby 3D space.
+
+% Module design: introduce module design by describing the module forward process
+Inspired by [65, 56, 49], we choose the SparseConvNet [21] to efficiently process the structured latent codes, whose architecture is described in Table 1. Specifically, based on the SMPL parameters, we compute the 3D bounding box of the human and divide the box into small voxels with voxel size of \( 5mm \times 5mm \times 5mm \). The latent code of a non-empty voxel is the mean of latent codes of SMPL vertices inside this voxel. SparseConvNet utilizes 3D sparse convolutions to process the input volume and output latent code volumes with \( 2\times, 4\times, 8\times, 16\times \) downsampled sizes. With the convolution and downsampling, the input codes are diffused to nearby space. Following [56], for any point in 3D space, we interpolate the latent codes from multi-scale code volumes of network layers 5, 9, 13, 17, and concatenate them into the final latent code. Since the code diffusion should not be affected by the human position and orientation in the world coordinate system, we transform the code locations to the SMPL coordinate system.
+
+For any point \( \mathbf{x} \) in 3D space, we query its latent code from the latent code volume. Specifically, the point \( \mathbf{x} \) is first transformed to the SMPL coordinate system, which aligns the point and the latent code volume in 3D space. Then, the latent code is computed using the trilinear interpolation. For the SMPL parameters \( S_t \), we denote the latent code at point \( \mathbf{x} \) as \( \psi(\mathbf{x}, Z, S_t) \). The code vector is passed into MLP networks to predict the density and color for point \( \mathbf{x} \).
+
+\subsection{3.3. Density and color regression}
+
+Figure 3(b) overviews the regression of density and color for any point in 3D space. The density and color fields are represented by MLP networks. Details of network architectures are described in the supplementary material.
+
+% Module design: introduce module design by describing the module forward process
+\textbf{Density model.} For the frame \( t \), the volume density at point \( \mathbf{x} \) is predicted as a function of only the latent code \( \psi(\mathbf{x}, Z, S_t) \), which is defined as:
+
+\[
+\sigma_t(\mathbf{x}) = M_{\sigma}(\psi(\mathbf{x}, Z, S_t)),
+\tag{1}
+\]
+
+where \( M_{\sigma} \) represents an MLP network with four layers.
+
+% Module design: introduce the module's data structure
+\textbf{Color model.} Similar to [37, 44], we take both the latent code \( \psi(\mathbf{x}, Z, S_t) \) and the viewing direction \( \mathbf{d} \) as input for the color regression. To model the location-dependent incident light, the color model also takes the spatial location \( \mathbf{x} \) as input. We observe that temporally-varying factors affect the human appearance, such as secondary lighting and self-shadowing. Inspired by the auto-decoder [48], we assign a latent embedding \( \ell_t \) for each video frame \( t \) to encode the temporally-varying factors.
+
+% Module design: introduce module design by describing the module forward process
+Specifically, for the frame \( t \), the color at \( \mathbf{x} \) is predicted as a function of the latent code \( \psi(\mathbf{x}, Z, S_t) \), the viewing direction \( \mathbf{d} \), the spatial location \( \mathbf{x} \), and the latent embedding \( \ell_t \). Following [51, 44], we apply the positional encoding to both the viewing direction \( \mathbf{d} \) and the spatial location \( \mathbf{x} \), which enables better learning of high frequency functions. The color model at frame \( t \) is defined as:
+
+\[
+c_t(\mathbf{x}) = M_c(\psi(\mathbf{x}, Z, S_t), \gamma_d(\mathbf{d}), \gamma_x(\mathbf{x}), \ell_t),
+\tag{2}
+\]
+
+where \( M_c \) represents an MLP network with two layers, and \( \gamma_d \) and \( \gamma_x \) are positional encoding functions for viewing direction and spatial location, respectively. We set the dimension of \( \ell_t \) to 128 in experiments.
+
+\subsection{3.4. Volume rendering}
+
+% Module design: introduce module design by describing the module forward process
+Given a viewpoint, we utilize the classical volume rendering techniques to render the Neural Body into a 2D image. The pixel colors are estimated via the volume rendering integral equation [27] that accumulates volume densities and colors along the corresponding camera ray. In practice, the integral is approximated using numerical quadrature [41, 44]. Given a pixel, we first compute its camera ray \( \mathbf{r} \) using the camera parameters and sample \( N_k \) points \( \{\mathbf{x}_k\}_{k=1}^{N_k} \) along camera ray \( \mathbf{r} \) between near and far bounds. The scene bounds are estimated based on the SMPL model. Then, Neural Body predicts volume densities and colors at these points. For the video frame \( t \), the rendered color \( \hat{C}_t(\mathbf{r}) \) ...
+```

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/method-writing-common-issues-note.md

@@ -0,0 +1,10 @@
+# Method Writing Common Issues (Reference Note)
+
+Original source mentioned in your notes:
+
+1. `Method writing common issues (PDF in your source notes)`
+
+Usage recommendation:
+
+1. Use this reference as a troubleshooting checklist after drafting Method.
+2. Prioritize unclear motivation, broken flow, missing implementation details, and inconsistent terms.

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/module-design-instant-ngp.md

@@ -0,0 +1,55 @@
+# Module Design Example 
+
+This example uses `%` comments as annotations.
+Each `% ...` annotation explains the paragraph(s) immediately below it.
+
+```latex
+\begin{quote}
+\textbf{Annotation rule.} In this example, each line starting with \% labels the role of the paragraph(s) directly below it.
+\end{quote}
+
+\begin{itemize}
+\item Motivation of this module
+\item Module design (data structure)
+\item Module design (forward process)
+\end{itemize}
+
+\section{3 \quad MULTIRESOLUTION HASH ENCODING}
+
+% Motivation of this module
+Given a fully connected neural network \(m(y;\Phi)\), we are interested in an encoding of its inputs \(y=\operatorname{enc}(x;\theta)\) that improves the approximation quality and training speed across a wide range of applications without incurring a notable performance overhead.
+
+% Module design: introduce the module's data structure
+Our neural network not only has trainable weight parameters \(\Phi\), but also trainable encoding parameters \(\theta\). These are arranged into \(L\) levels, each containing up to \(T\) feature vectors with dimensionality \(F\). Typical values for these hyperparameters are shown in Table 1. Figure 3 illustrates the steps performed in our multiresolution hash encoding. Each level (two of which are shown as red and blue in the figure) is independent and conceptually stores feature vectors at the vertices of a grid, the resolution of which is chosen to be a geometric progression between the coarsest and finest resolutions \([N_{\min},N_{\max}]\):
+
+\[
+N_l := \left\lfloor N_{\min}\cdot b^l \right\rfloor, \tag{2}
+\]
+
+\[
+b := \exp\!\left(\frac{\ln N_{\max}-\ln N_{\min}}{L-1}\right). \tag{3}
+\]
+
+\(N_{\max}\) is chosen to match the finest detail in the training data. Due to the large number of levels \(L\), the growth factor is usually small. Our use cases have \(b\in[1.26,2]\).
+
+% Module design: introduce module design by describing the module forward process
+Consider a single level \(l\). The input coordinate \(x\in\mathbb{R}^d\) is scaled by that level's grid resolution before rounding down and up:
+\[
+\lfloor x_l \rfloor := \lfloor x\cdot N_l \rfloor,\quad
+\lceil x_l \rceil := \lceil x\cdot N_l \rceil.
+\]
+
+\(\lfloor x_l \rfloor\) and \(\lceil x_l \rceil\) span a voxel with \(2^d\) integer vertices in \(\mathbb{Z}^d\). We map each corner to an entry in the level's respective feature vector array, which has fixed size of at most \(T\). For coarser levels where a dense grid requires fewer than \(T\) parameters, i.e. \((N_l+1)^d \le T\), this mapping is 1:1. At finer levels, we use a hash function \(h:\mathbb{Z}^d\rightarrow\mathbb{Z}_T\) to index into the array, effectively treating it as a hash table, although there is no explicit collision handling. We rely instead on the gradient-based optimization to store appropriate sparse detail in the array, and the subsequent neural network \(m(y;\Phi)\) for collision resolution. The number of trainable encoding parameters \(\theta\) is therefore \(O(T)\) and bounded by \(T\cdot L\cdot F\), which in our case is always \(T\cdot16\cdot2\) (Table 1).
+
+We use a spatial hash function [Teschner et al. 2003] of the form
+\[
+h(x)=\left(\bigoplus_{i=1}^{d} x_i\pi_i\right)\bmod T, \tag{4}
+\]
+where \(\oplus\) denotes the bit-wise XOR operation and \(\pi_i\) are unique, large prime numbers. Effectively, this formula XORs the results of a per-dimension linear congruential (pseudo-random) permutation [Lehmer 1951], \emph{decorrelating} the effect of the dimensions on the hashed value. Notably, to achieve (pseudo-)independence, only \(d-1\) of the \(d\) dimensions must be permuted, so we choose \(\pi_1:=1\) for better cache coherence, \(\pi_2=2{,}654{,}435{,}761\), and \(\pi_3=805{,}459{,}861\).
+
+Lastly, the feature vectors at each corner are \(d\)-linearly interpolated according to the relative position of \(x\) within its hypercube, i.e. the interpolation weight is \(w_l := x_l-\lfloor x_l \rfloor\).
+
+Recall that this process takes place independently for each of the \(L\) levels. The interpolated feature vectors of each level, as well as auxiliary inputs \(\xi\in\mathbb{R}^E\) (such as the encoded view direction and textures in neural radiance caching), are concatenated to produce \(y\in\mathbb{R}^{LF+E}\), which is the encoded input \(\operatorname{enc}(x;\theta)\) to the MLP \(m(y;\Phi)\).
+
+\textbf{Performance vs. quality.} Choosing the hash table size \(T\) provides a trade-off between performance, memory and quality. Higher values of \(T\) result in higher quality and lower performance. The memory ...
+```

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/module-motivation-patterns.md

@@ -0,0 +1,15 @@
+# Module Motivation Writing Patterns
+
+
+`Module motivation is usually problem-driven: because a problem exists, we design xx to solve it.`
+
+Typical opening sentences:
+
+1. `A remaining problem/challenge is ...`
+2. `However, we ...`
+3. `Previous methods have difficulty in ...`
+
+Usage note:
+
+1. State the specific failure before introducing the module.
+2. Keep motivation independent from implementation details.

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/module-triad-neural-body.md

@@ -0,0 +1,19 @@
+# Module Triad Example (Neural Body)
+
+`Use Neural Body to understand the three elements of a module: design, motivation, and technical advantages.`
+
+Local source references:
+
+1. Annotated figure showing motivation/design/advantages split.
+3. Text-converted annotation notes: `references/examples/method/neural-body-annotated-figure-text.md`
+
+Triad mapping template:
+
+1. Module design: what representation/network is built and how forward process runs.
+2. Motivation: what unresolved challenge requires this module.
+3. Technical advantages: why this module performs better than alternatives.
+
+Direct usage:
+
+1. Read `neural-body-annotated-figure-text.md` to map each paragraph to one triad element.
+2. Rebuild your own Method subsection with the same triad order.

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/neural-body-annotated-figure-text.md

@@ -0,0 +1,66 @@
+# Neural Body Annotated Figure (Text Conversion)
+
+This file converts the annotated Neural Body figure into reusable writing notes.
+
+## Purpose
+
+Use this mapping to understand how one Method section can explicitly separate:
+
+1. Module motivation
+2. Module design (data structure)
+3. Module design (forward process)
+4. Technical advantages
+
+## Block-by-Block Mapping
+
+### Section 3.1: Structured Latent Codes
+
+1. **Module design (data structure)**
+- The paragraph defines structured latent codes anchored to the deformable human model (SMPL).
+- It explains what is constructed (latent codes + their anchor positions + frame-dependent transformation by pose).
+
+2. **Technical advantages**
+- The paragraph explains why this design works better: dynamic-human representation and cross-frame integration of observations.
+- It highlights why anchoring codes to deformable geometry is beneficial.
+
+### Section 3.2: Code Diffusion
+
+1. **Motivation of this module**
+- The paragraph states the remaining problem: direct interpolation of sparse structured codes leads to near-zero vectors at many 3D points.
+- This motivates diffusion from surface codes to nearby 3D space.
+
+2. **Module design (forward process)**
+- The paragraph explains the execution pipeline: build sparse latent volumes, run sparse convolutions, interpolate latent codes at query points, and feed codes to prediction networks.
+- This is a canonical input -> steps -> output module description.
+
+### Section 3.3: Density and Color Regression
+
+1. **Module design (forward process) for density model**
+- The density paragraph defines how density is regressed from latent code and frame condition.
+
+2. **Module design (data structure) for color model**
+- The color paragraph introduces required inputs/embeddings (latent code, view direction, spatial location, temporal embedding).
+
+3. **Module design (forward process) for color model**
+- The next paragraph describes how those inputs are encoded and passed into the color MLP for final color prediction.
+
+### Section 3.4: Volume Rendering
+
+1. **Module design (forward process)**
+- The paragraph describes ray sampling and volume integration to render image outputs from predicted density/color fields.
+
+## Reusable Writing Pattern from This Figure
+
+For each module subsection, follow this order:
+
+1. `Motivation`: state unresolved challenge and technical reason.
+2. `Design-1`: define structure/representation/network.
+3. `Design-2`: describe forward process in execution order.
+4. `Advantage`: explain why this module improves over alternatives.
+
+## Suggested Paragraph Starters
+
+1. Motivation: `A remaining challenge is ...`
+2. Data structure design: `We represent ... with ...`
+3. Forward process: `Given [input], we first ... then ... finally ...`
+4. Technical advantage: `Compared with previous methods, this design ... because ...`

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/overview-template.md

@@ -0,0 +1,30 @@
+# Method Overview Template
+
+
+`Overview usually includes setting, core contribution, optional figure pointer, and subsection map.`
+
+```latex
+% Overview
+% One or two sentences for setting
+%% Example 1: Given a sparse multi-view video of a performer, our task is to generate a free-viewpoint video of the performer.
+%% Example 2: Given an image, the task of pose estimation is to detect objects and estimate their orientations and translations in the 3D space.
+
+% One or two sentences for core contribution
+%% Example 1: We build upon prior work for static scenes [46], to which we add the notion of time, and estimate 3D motion by explicitly modeling forward and backward scene flow as dense 3D vector fields.
+%% Example 2: Inspired by [21, 25], we perform object segmentation by deforming an initial contour to match object boundary.
+%% Example 3: Inspired by recent methods [29, 30, 36], we estimate the object pose using a two-stage pipeline: we first detect 2D object keypoints using CNNs and then compute 6D pose parameters using the PnP algorithm. Our innovation is in a new representation for 2D object keypoints as well as a modified PnP algorithm for pose estimation.
+
+% If pipeline/framework is novel, point to figure
+%% Example: The overview of the proposed model is illustrated in Figure 3.
+
+% Explain what Section 3.1 covers
+%% Example 1: Neural Body starts from a set of structured latent codes attached to the surface of a deformable human model (Section 3.1).
+%% Example 2: In this section, we first describe how to model 3D scenes with MLP maps (Section 3.1).
+
+% Explain what Section 3.2 covers
+%% Example 1: The latent code at any location around the surface can be obtained with a code diffusion process (Section 3.2) and then decoded to density and color values by neural networks (Section 3.3).
+%% Example 2: Then, Section 3.2 discusses how to represent volumetric videos with dynamic MLP maps.
+
+% Explain what Section 3.3 covers
+%% Example 3: Finally, we introduce some strategies to speed up the rendering process (Section 3.3).
+```

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/pre-writing-questions.md

@@ -0,0 +1,17 @@
+# Method Pre-Writing Questions
+
+
+`Before writing Method, answer: (1) what modules exist, and (2) for each module, what is its workflow, why is it needed, and why does it work.`
+
+```text
+Questions:
+(1) What modules are in the method?
+(2) For each module, answer three questions:
+    - What is this module's workflow?
+    - Why do we need this module?
+    - Why does this module work?
+```
+
+Recommended action:
+
+1. Organize answers in a mind map or table before writing paragraphs.

package/package-assets/shared/skills/lab/references/paper-writing/examples/method/section-skeleton.md

@@ -0,0 +1,9 @@
+# Method Section Skeleton
+
+```latex
+\section{Method}
+% Overview
+% Section 3.1
+% Section 3.2
+% Section 3.3
+```

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

@@ -0,0 +1,24 @@
+# Method Examples Index
+
+All method example cites should point to the local files below.
+
+## A. Planning and Writing Workflow
+
+1. Pre-writing questions: `references/examples/method/pre-writing-questions.md`
+
+## B. Module Triad and Module-Level Writing
+
+1. Module triad (Neural Body): `references/examples/method/module-triad-neural-body.md`
+2. Neural Body figure text conversion: `references/examples/method/neural-body-annotated-figure-text.md`
+3. Module design (Instant-NGP): `references/examples/method/module-design-instant-ngp.md`
+4. Module motivation patterns: `references/examples/method/module-motivation-patterns.md`
+
+## C. Section-Level Templates
+
+1. Method section skeleton: `references/examples/method/section-skeleton.md`
+2. Overview template: `references/examples/method/overview-template.md`
+3. Example of the three elements: `references/examples/method/example-of-the-three-elements.md`
+
+## D. Clarity and Troubleshooting
+
+1. Common issues note: `references/examples/method/method-writing-common-issues-note.md`

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

@@ -337,7 +337,13 @@ Why not recommended (writing structure warning):
 
 ## 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`.
+This vendored guide should be paired with the local introduction example bank:
+
+- `references/examples/index.md`
+- `references/examples/introduction-examples.md`
+- 1-2 matching files under `references/examples/introduction/`
+
+Use the introduction patterns and sentence skeletons here first, then use the example files to choose a concrete paragraph flow and narrative progression. Reuse structure, not wording.
 
 ## Quick Quality Checklist
 

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

@@ -62,7 +62,11 @@ Definition:
 
 ### Example of the Three Elements
 
-Use the structure above directly. The original example-bank files are not bundled in `superlab`.
+Use the structure above directly, then compare it with the local method example bank:
+
+- `references/examples/index.md`
+- `references/examples/method-examples.md`
+- 1-2 matching files under `references/examples/method/`
 
 ## Method Content Decomposition
 
@@ -163,4 +167,4 @@ flowchart TB
 
 ## Usage Note
 
-This vendored guide keeps the method-writing patterns and checklists but does not bundle the upstream example-bank files. Treat the subsection structures, sentence skeletons, and review questions in this file as the direct working reference.
+This vendored guide should be paired with the local method example bank listed above. Use this file for subsection structure, module-writing checks, and review questions first; then use the example files to choose a concrete presentation pattern. Reuse structure, not wording.

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

@@ -2,11 +2,13 @@
 
 `/lab:write` vendors the paper-writing references directly into `skills/lab/references/paper-writing/`.
 The goal is to keep the upstream writing discipline while removing brittle runtime dependence on a separately installed skill.
+It also vendors the upstream example bank for the sections that currently have curated examples, so drafting can reuse concrete structure rather than only abstract guidance.
 
 ## Role Split
 
 - `lab` controls stage boundaries, evidence discipline, and durable artifacts.
 - the vendored paper-writing references control section structure, paragraph logic, and reviewer-facing polish.
+- the vendored example bank controls example-driven structure selection for `abstract`, `introduction`, and `method`.
 - `/lab:write` links evidence-backed research outputs to paper-ready text.
 
 ## Required Shared Constraints
@@ -33,6 +35,30 @@ The goal is to keep the upstream writing discipline while removing brittle runti
 - `paper-writing/paper-review.md`
 - `paper-writing/does-my-writing-flow-source.md`
 
+## Vendored Example Bank
+
+- `paper-writing/examples/index.md`
+- `paper-writing/examples/abstract-examples.md`
+- `paper-writing/examples/introduction-examples.md`
+- `paper-writing/examples/method-examples.md`
+- `paper-writing/examples/abstract/*`
+- `paper-writing/examples/introduction/*`
+- `paper-writing/examples/method/*`
+
+## Write-Time Rule
+
+For `abstract`, `introduction`, and `method`:
+
+1. read the section guide first
+2. read the matching examples index
+3. read 1-2 concrete example files that match the intended structure
+4. reuse structure and sentence logic without copying wording
+
+For `related work`, `experiments`, and `conclusion`:
+
+1. use the section guide directly
+2. do not invent non-existent example-bank files
+
 ## Attribution
 
 These references are adapted from:

package/package-assets/shared/skills/lab/stages/auto.md

@@ -38,6 +38,7 @@
 - Treat `/lab:auto` as an orchestration layer, not a replacement for existing `/lab:*` stages.
 - Treat `.lab/context/eval-protocol.md` as the source of truth for paper-facing metrics, metric glossary, table plan, gates, and structured experiment ladders.
 - Treat the evaluation protocol as source-backed, not imagination-backed: metric definitions, baseline behavior, comparison implementations, and deviations must come from recorded sources before they are used in gates or promotions.
+- Treat paper-template selection as an explicit write-time gate, not as a silent fallback, when the loop is about to create `.tex` deliverables for the first time.
 - The contract must declare `Autonomy level` and `Approval status`, and execution starts only when approval is explicitly set to `approved`.
 - The contract must also declare a concrete terminal goal:
   - `rounds`
@@ -65,7 +66,7 @@
 - Enforce stage contracts, not just exit codes:
   - `run` and `iterate` must change persistent outputs under `results_root`
   - `review` must update canonical review context
-  - `report` must produce `<deliverables_root>/report.md`
+  - `report` must produce `<deliverables_root>/report.md` and `<deliverables_root>/main-tables.md`
   - `write` must produce LaTeX output under `<deliverables_root>/paper/`
 - Treat promotion as incomplete unless it writes back to `data-decisions.md`, `decisions.md`, `state.md`, and `session-brief.md`.
 - Do not stop or promote on the basis of a metric or comparison claim whose source-backed definition is missing from the approved evaluation protocol.
@@ -106,4 +107,11 @@
   - allowed modifications
 - Then ask at most one clarifying question if a blocking field is still missing.
 - If `.lab/config/workflow.json` sets the workflow language to Chinese, write summaries, options, checklist items, task labels, and progress updates in Chinese unless a file path, code identifier, or literal metric name must remain unchanged.
+- When the loop reaches `report`, apply the same workflow-language rule to `report.md` and the managed `main-tables.md` artifact.
+- When the loop is about to enter `write` and `paper_template_root` is empty:
+  - if `paper_template_decision` is `unconfirmed`, ask one explicit question: continue with the default scaffold or attach a template directory first
+  - if the user chooses the default scaffold, persist `paper_template_decision: default-scaffold`
+  - if the user chooses a template, stop the loop and route to `superlab paper attach-template --path <dir>`
+  - if the current write target is a final manuscript export, `paper_template_decision` is `default-scaffold`, and `paper_template_final_reminder_acknowledged` is `false`, ask one final reminder question before finalizing
+  - if the user confirms staying on the default scaffold at that final reminder, persist `paper_template_final_reminder_acknowledged: true`
 - While the real experiment process is still alive, emit only a progress update and keep waiting. Do not present a terminal summary for that rung until the process exits or the rung hits an explicit stop boundary.

package/package-assets/shared/skills/lab/stages/report.md

@@ -3,8 +3,10 @@
 ## Required Output
 
 - method overview
+- selected metrics summary
 - experiment setup
 - validated main results
+- managed main tables artifact under `<deliverables_root>/main-tables.md`
 - ablations
 - failed attempts
 - limitations
@@ -31,13 +33,15 @@
 - Tie every major claim to recorded summaries or iteration artifacts.
 - Structure tables, gates, and main claims against the approved evaluation protocol.
 - Do not restate metric definitions, baseline behavior, or comparison implementations from memory; use the approved evaluation protocol and its recorded sources.
+- Carry the approved `Primary metrics`, `Secondary metrics`, and `Required terminal evidence` into both the report and the managed main-tables artifact.
 - If the report depends on a deviation from an original metric or implementation, state that deviation explicitly instead of smoothing it over.
+- If `.lab/config/workflow.json` sets the workflow language to Chinese, write `report.md` and `<deliverables_root>/main-tables.md` in Chinese unless a file path, code identifier, or literal metric name must remain unchanged.
 - Prefer conservative interpretation over marketing language.
 - Leave a clear handoff path into `/lab:write` with evidence links that section drafts can cite.
 
 ## Interaction Contract
 
-- Start with a concise summary of the campaign outcome, strongest supported claim, and biggest reporting risk.
+- Start with a concise summary of the campaign outcome, the selected primary and secondary metrics, the strongest supported claim, and the biggest reporting risk.
 - If a missing assumption would change report interpretation, ask one clarifying question at a time.
 - If there are multiple defensible report framings, present 2-3 approaches with trade-offs and recommend the most evidence-faithful framing before writing.
 - Keep an approval gate when the reporting frame would materially affect what the paper later claims.

package/package-assets/shared/skills/lab/stages/write.md

@@ -13,6 +13,8 @@
 
 - `.lab/config/workflow.json`
 - `paper_template_root` from `.lab/config/workflow.json`
+- `paper_template_decision` from `.lab/config/workflow.json`
+- `paper_template_final_reminder_acknowledged` from `.lab/config/workflow.json`
 
 ## Context Read Set
 
@@ -38,6 +40,12 @@ Load the exact vendored file that matches the current target:
 - experiments -> `skills/lab/references/paper-writing/experiments.md`
 - conclusion -> `skills/lab/references/paper-writing/conclusion.md`
 
+When the current target has a bundled example bank, load the examples index and 1-2 concrete example files that match the intended structure:
+
+- abstract -> `skills/lab/references/paper-writing/examples/index.md`, `skills/lab/references/paper-writing/examples/abstract-examples.md`, plus one matching file under `skills/lab/references/paper-writing/examples/abstract/`
+- introduction -> `skills/lab/references/paper-writing/examples/index.md`, `skills/lab/references/paper-writing/examples/introduction-examples.md`, plus 1-2 matching files under `skills/lab/references/paper-writing/examples/introduction/`
+- method -> `skills/lab/references/paper-writing/examples/index.md`, `skills/lab/references/paper-writing/examples/method-examples.md`, plus 1-2 matching files under `skills/lab/references/paper-writing/examples/method/`
+
 Run these on every round:
 
 - section flow check -> `skills/lab/references/paper-writing/does-my-writing-flow-source.md`
@@ -49,8 +57,15 @@ Run these on every round:
 - LaTeX is the required manuscript output format.
 - If `paper_template_root` is configured, inspect that template directory before drafting and align the manuscript structure to it.
 - Treat attached template directories as user-owned and potentially modified. Do not rewrite template files unless the user explicitly asks.
-- If no paper template is configured, use the default LaTeX scaffold under the deliverable paper directory.
+- If no paper template is configured and `paper_template_decision` is `unconfirmed`, ask one explicit question before the first `.tex` drafting round: continue with the default LaTeX scaffold, or attach a template directory first.
+- If the user chooses the default scaffold, persist that choice in `.lab/config/workflow.json` by setting `paper_template_decision` to `default-scaffold`.
+- If the user chooses to attach a template, stop the drafting loop and route to `superlab paper attach-template --path <dir>` instead of silently falling back.
+- If `paper_template_decision` is `default-scaffold`, use the managed default LaTeX scaffold under the deliverable paper directory.
+- If the current round is a final manuscript export or final-draft pass, `paper_template_root` is still empty, `paper_template_decision` is `default-scaffold`, and `paper_template_final_reminder_acknowledged` is `false`, ask one final reminder question about switching to a template before finalizing.
+- If the user confirms staying on the default scaffold at that final reminder, persist `paper_template_final_reminder_acknowledged: true`.
 - Load only the current section guide. Do not load every section guide at once.
+- Reuse example-bank structure, paragraph roles, and sentence logic when examples are bundled, but never copy wording verbatim.
+- Treat example cites and example file names as writing references, not as evidence for the current paper.
 - Build a compact mini-outline before prose.
 - For each subsection, explicitly include motivation, design, and technical advantage when applicable.
 - Avoid a writing style that reads like incremental patching of a naive baseline.