Project Sync Workflow
Use this workflow when you have new experiment results in the code repo or a code worktree and want to record them in the paper's
.
This is a manual, human-triggered workflow — run it whenever you want to checkpoint results into the paper.
Pair this skill with
when the logged result should update evidence, claims, risks, actions, or paper status.
Step 1 — Locate the Project
// turbo
Auto-detect the project structure. Run:
bash
# Find the git root of the current repo
git rev-parse --show-toplevel 2>/dev/null
# Check if we're in code/ or paper/ and find sibling
ls "$(git rev-parse --show-toplevel)/../"
Determine:
- - the code repo root or active code worktree root
- - the paper repo root
- - the project control root, if present
In a project-init project,
and
are component repos under the project control root, and code worktrees usually live under
. If the paper repo cannot be inferred, ask the user:
"Where is the paper repo? Please provide its path."
Step 2 — Gather New Results
Ask the user in a single message:
- Date: What date are these experiments? (default: today's date, YYYY-MM-DD)
- Short title: A brief label for this experiment batch (e.g. "Baseline on CIFAR-10", "Ablation: remove attention layer")
- Setup: What method variant / config / dataset was used?
- Results: What are the key numbers? (paste metrics, accuracy, loss, etc.)
- Observation: What do the results mean? What worked, what didn't?
- Next: What follow-up experiment is planned?
Optionally, also check if there are existing result files to pull from:
bash
# Stable code-side evidence
find "$CODE_ROOT/docs/results" "$CODE_ROOT/docs/reports" "$CODE_ROOT/docs/runs" -maxdepth 2 -type f 2>/dev/null | sort | tail -20
# Raw or ignored outputs, if present
find "$CODE_ROOT/outputs" "$CODE_ROOT/logs" "$CODE_ROOT/checkpoints" -maxdepth 2 -type f 2>/dev/null | sort | tail -20
If relevant result summaries or reports exist, read them and pre-fill the answers for the user to confirm. Treat raw logs as supporting material, not paper-facing evidence, unless the user confirms the numbers.
Step 3 — Preview the Entry
Compose and display the LaTeX entry for the user to review:
latex
\subsection*{<DATE> — <SHORT TITLE>}
\textbf{Setup:} <setup>\\
\textbf{Result:} <results>\\
\textbf{Observation:} <observation>\\
\textbf{Next:} <next>
Ask: "Does this look correct? Should I add it to the paper?"
Wait for confirmation.
Step 4 — Insert into daily_experiments.tex
// turbo
Read the current contents of
$PAPER_ROOT/sections/daily_experiments.tex
.
Insert the new entry at the top (below the comment header), so the log is in reverse chronological order (newest first).
After inserting, show the user the updated top of the file to confirm it looks right.
Step 5 — Commit to Paper Repo (optional)
Ask: "要把这条实验记录提交到 paper repo 的 Git 吗？(Y/n)"
If yes:
bash
git -C "$PAPER_ROOT" add sections/daily_experiments.tex
git -C "$PAPER_ROOT" commit -m "exp: add <DATE> — <SHORT TITLE>"
If no, inform the user the file is saved and can be committed later.
Step 6 — Confirm
Report:
Experiment logged:
Date: <DATE>
Title: <SHORT TITLE>
File: <PAPER_ROOT>/sections/daily_experiments.tex
To view all logged experiments:
cat <PAPER_ROOT>/sections/daily_experiments.tex
Step 7 — Update Project Memory When Present
If the parent project has
, update:
- : add the logged result as an or link it to an existing
- : mark affected claims as supported, weakened, or still unsupported
- : add or close risks exposed by the result
- : add the next experiment/report/writing action from the log entry
paper/.agent/paper-status.md
sections/daily_experiments.tex
- or
<code-worktree>/.agent/worktree-status.md
Treat the daily experiment log as evidence only if the numbers are source-linked or user-confirmed. Otherwise mark certainty as
or
.