weekly-digests
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseWeekly Digests
每周摘要
Produce a serial, multi-chapter narrative digest of a project's complete claude-mem history. Differs from (one long report) — this generates one digest per ISO week, with each subagent reading the prior week's carry-forward block so the story stays coherent.
timeline-reportThe chapter count equals the number of ISO weeks the timeline covers. A project with 2 weeks of data produces 2 chapters; one with 30 weeks produces 30. There is no fixed length — count the weeks first, then drive the pipeline off that count.
生成项目完整claude-mem历史的系列多章节叙事摘要。与(单份长报告)不同——此功能会为每ISO周生成一份摘要,每个子代理都会读取前一周的结转块,确保故事连贯性。
timeline-report章节数量等于时间线覆盖的ISO周数。拥有2周数据的项目会生成2个章节;拥有30周数据的项目则生成30个章节。章节长度不固定——先统计周数,再以此驱动流程。
When to Use
使用场景
Trigger when the user asks for:
- "Weekly digests"
- "Week-by-week story"
- "Serial timeline"
- "Story chapters of [project]"
- "Run a digest for each week"
- "Continue the story week by week"
If the user wants a single sweeping report, use instead. This skill is for serial chapter format.
timeline-report当用户提出以下需求时触发:
- "每周摘要"
- "每周故事"
- "系列时间线"
- "[项目]的故事章节"
- "为每周生成一份摘要"
- "逐周延续故事"
如果用户想要一份完整的综述报告,请改用。此技能专为系列章节格式设计。
timeline-reportPrerequisites
前置条件
- claude-mem worker running
- Project has at least one ISO week of observations (the pipeline degenerates gracefully — even N=1 works)
- A clean output directory the user is comfortable writing into
Resolve the worker port (do this once, reuse ):
$WORKER_PORTbash
WORKER_PORT="${CLAUDE_MEM_WORKER_PORT:-$(node -e "const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}" 2>/dev/null)}"- claude-mem worker正在运行
- 项目至少有一周的ISO周观测数据(流程会优雅降级——即使只有1周数据也能运行)
- 有一个用户可写入的干净输出目录
解析worker端口(只需执行一次,复用):
$WORKER_PORTbash
WORKER_PORT="${CLAUDE_MEM_WORKER_PORT:-$(node -e "const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}" 2>/dev/null)}"Workflow
工作流程
Step 1: Determine the Project Name
步骤1:确定项目名称
Same worktree-detection pattern as . In a worktree, the data source is the parent project:
timeline-reportbash
git_dir=$(git rev-parse --git-dir 2>/dev/null)
git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
if [ "$git_dir" != "$git_common_dir" ]; then
parent_project=$(basename "$(dirname "$git_common_dir")")
else
parent_project=$(basename "$PWD")
fi
echo "$parent_project"采用与相同的工作树检测模式。在工作树中,数据源为父项目:
timeline-reportbash
git_dir=$(git rev-parse --git-dir 2>/dev/null)
git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
if [ "$git_dir" != "$git_common_dir" ]; then
parent_project=$(basename "$(dirname "$git_common_dir")")
else
parent_project=$(basename "$PWD")
fi
echo "$parent_project"Step 2: Fetch the Full Timeline and Save It
步骤2:获取完整时间线并保存
bash
mkdir -p .scratch
curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true" \
> .scratch/cm-timeline.md
wc -l .scratch/cm-timeline.mdSanity-check: confirm the file is non-empty and has the expected structure (preamble, then date headers like , then numeric observation lines and session boundary lines ).
### Mon DD, YYYY<id> <time> <emoji> <title>S<n> <prompt> (Mon DD at HH:MMpm)bash
mkdir -p .scratch
curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true" \
> .scratch/cm-timeline.md
wc -l .scratch/cm-timeline.md完整性检查:确认文件非空且符合预期结构(前言,然后是格式的日期标题,接着是数字观测行和会话边界行)。
### Mon DD, YYYY<id> <time> <emoji> <title>S<n> <prompt> (Mon DD at HH:MMpm)Step 3: Split the Timeline Into Per-ISO-Week Files
步骤3:将时间线拆分为按ISO周划分的文件
Write a Python script to that:
.scratch/split-timeline.py- Parses date headers ().
### Mon DD, YYYY - Groups days into ISO weeks via (Monday-start).
date.isocalendar() - Emits one file per week to , preserving each day's section verbatim.
docs/timeline-weeks/<YYYY>-W<NN>-<MonDD>-to-<MonDD>.md - Runs a dual-pass sanity check: total observations distributed must equal the count in the source file.
Output structure (filenames illustrative):
docs/timeline-weeks/
README.md # weekly index table
YYYY-W<NN>-MonDD-to-MonDD.md # one per ISO week the timeline covers
...Each weekly file should preserve the original daily sections verbatim. Do not paraphrase at this stage — the digest agents need raw fidelity.
Count the resulting files before launching the pipeline. That count is and drives every subsequent step. Empty weeks (zero observations between active weeks) should be skipped — the pipeline only operates on weeks that have content.
TOTAL编写Python脚本到,实现以下功能:
.scratch/split-timeline.py- 解析日期标题()。
### Mon DD, YYYY - 通过将日期分组为ISO周(周一为一周起始)。
date.isocalendar() - 为每周生成一个文件,保存到,完整保留每日内容。
docs/timeline-weeks/<YYYY>-W<NN>-<MonDD>-to-<MonDD>.md - 执行双重检查:拆分后所有观测数据的总数必须与源文件中的数量一致。
输出结构(文件名仅为示例):
docs/timeline-weeks/
README.md # 每周索引表
YYYY-W<NN>-MonDD-to-MonDD.md # 时间线覆盖的每ISO周对应一个文件
...每个周文件应完整保留原始每日内容。此阶段请勿改写——摘要代理需要原始数据的准确性。
在启动流程前统计生成的文件数量。该数量即为,将驱动后续所有步骤。空周(活跃周之间无观测数据的周)应跳过——流程仅处理有内容的周。
TOTALStep 4: Build the Weekly Index README
步骤4:生成每周索引README
Write with a markdown table: Week | Dates | Observations | Sessions | File. This becomes the operator's roadmap and helps the agents understand pacing (peak weeks vs trough weeks).
docs/timeline-weeks/README.md编写,包含一个Markdown表格:Week | Dates | Observations | Sessions | File。这将作为操作者的路线图,帮助代理了解节奏(高峰周 vs 低谷周)。
docs/timeline-weeks/README.mdStep 5: Run the Consecutive Subagent Pipeline
步骤5:运行连续子代理流程
Critical: subagents run sequentially, NOT in parallel. Each agent receives the prior agent's carry-forward block. This is the entire point of the skill — without it you have N disjoint summaries; with it you have an N-chapter serial narrative.
Create the output directory:
bash
mkdir -p docs/timeline-weeks/digestsFor each week, in chronological order, dispatch a Task subagent (general-purpose) with this prompt template. Wait for each agent to complete before launching the next. Capture the carry-forward block from the result and inject it as into the next prompt.
STORY_SO_FAR关键:子代理需按顺序运行,而非并行。每个代理都会接收前一个代理的结转块。这是此技能的核心——没有它,你得到的是N个独立的摘要;有了它,你得到的是N章连贯的系列叙事。
创建输出目录:
bash
mkdir -p docs/timeline-weeks/digests按时间顺序为每个周分配一个通用任务子代理,使用以下提示模板。等待每个代理完成后再启动下一个。捕获结果中的结转块,并将其作为注入到下一个提示中。
STORY_SO_FARSubagent Prompt Template
子代理提示模板
You are writing chapter {N} of {TOTAL} in a serial week-by-week digest of the {PROJECT} project's development history. Chapters 1 through {N-1} are written. {SPECIAL_NOTE: e.g. "This is the LARGEST week", "This is the TROUGH", "This is the FINAL chapter", "This is the ONLY chapter — both first AND final week"}.
**Source file (read in full):**
{ABSOLUTE_PATH_TO_WEEK_FILE}
**Output digest file (write):**
{ABSOLUTE_PATH_TO_DIGEST_FILE}
**Format key for the source file:**
- Numeric lines like `1 7:59p 🔵 Save hook file is empty` are observations (ID, time, type-emoji, title)
- `S##` lines are session boundaries (the user prompt that started the session)
- Emoji legend: 🎯session 🔴bugfix 🟣feature 🔄refactor ✅change 🔵discovery ⚖️decision 🚨security_alert 🔐security_note
**Story so far (carry-forward from Week {N-1}):**
{STORY_SO_FAR_BLOCK_OR_EMPTY_FOR_WEEK_1}
**Your digest must include:**
1. **Title line** — `# Week {N} ({WEEK_LABEL}): {DATE_RANGE} — [your chosen subtitle]`
2. **One-line tagline** — what this week is about, in plain English
3. **Narrative section** ({BUDGET}) — tell the story. Resolve threads from prior weeks where the data shows resolution. Introduce new arcs. Use specific observation details.
4. **Threads continued / opened / resolved** sections
5. **Cliffhanger / What's next**
6. **Carry-forward block** at the very bottom, fenced as ```carry-forward ... ``` — structured handoff for the next week's agent.
**CARRY-FORWARD DISCIPLINE:**
- Cap at ~350 words.
- AGGRESSIVELY PRUNE: drop arcs that didn't surface this week unless they're actively unresolved cliffhangers.
- Drop cast members absent 2+ weeks unless load-bearing for the long arc.
- Quality over completeness. The next agent inherits what you mention; mention judiciously.
Required carry-forward sub-sections:
- **Active arcs** — ongoing themes/projects the next agent should watch for
- **Cast** — notable named systems/people/tools (continuing + new)
- **Unresolved** — open questions or unfinished work
- **Tone notes** — how the story is being told (voice, perspective, register evolution)
**Tone rules:**
- Third-person narrator, sharp, observational. Not twee.
- AI is "Claude"; human is "{USER_FIRST_NAME}".
- Treat codebase components as characters — whatever the project's recurring named systems are (e.g. a worker, a queue, a process manager, a recurring bug, a flaky migration). Don't import names from another project; use what shows up in this project's observations.
- Don't manufacture drama. Name what's there.
- Track the user's prompt-register evolution week by week (frustration markers, escalation language, shifts in tone).
- Note meta-recursion if the project is reflexive about its own behavior (e.g. a tool that documents its own work, an AI agent debugging itself, a system that catches its own regressions).
- Watch for new villains or co-stars and name them.
- For trough/silent weeks: silence IS the story. Don't pad. Name what didn't happen.
- For surge weeks (>2,000 obs): pick 4-7 spine arcs and tell them well. Don't catalog.
**Important:** Do NOT speculate beyond what's in the source file.
After writing the file, return:
1. Path of the file you wrote
2. The carry-forward block verbatim
3. One-sentence summary of the week你正在撰写{PROJECT}项目开发历史系列每周摘要的第{N}章,共{TOTAL}章。第1至{N-1}章已完成。{SPECIAL_NOTE: 例如 "这是数据量最大的一周"、"这是低谷期"、"这是最后一章"、"这是唯一的章节——既是第一周也是最后一周"}。
**源文件(请完整阅读):**
{ABSOLUTE_PATH_TO_WEEK_FILE}
**输出摘要文件(请写入):**
{ABSOLUTE_PATH_TO_DIGEST_FILE}
**源文件格式说明:**
- 类似`1 7:59p 🔵 Save hook file is empty`的数字行是观测记录(ID、时间、类型表情、标题)
- `S##`行是会话边界(启动会话的用户提示)
- 表情图例:🎯session 🔴bugfix 🟣feature 🔄refactor ✅change 🔵discovery ⚖️decision 🚨security_alert 🔐security_note
**故事进展(来自第{N-1}周的结转内容):**
{STORY_SO_FAR_BLOCK_OR_EMPTY_FOR_WEEK_1}
**你的摘要必须包含:**
1. **标题行** — `# 第{N}周(W##):{DATE_RANGE} — [你选定的副标题]`
2. **一行标语** — 用简洁的英文说明本周的核心内容
3. **叙事部分**({BUDGET}) — 讲述故事。根据数据显示的结果,延续并解决前一周的线索。引入新的故事线。使用具体的观测细节。
4. **线索延续/开启/解决**部分
5. **悬念/后续展望**
6. **结转块** — 放在最底部,用```carry-forward ... ```包裹——为下周的代理提供结构化的交接内容。
**结转块规范:**
- 字数限制约350词。
- 主动精简:删除本周未出现的故事线,除非它们是尚未解决的关键悬念。
- 删除连续2周未出现的角色,除非它们对长期故事线至关重要。
- 质量优先于完整性。下一个代理只会继承你提到的内容,请谨慎选择。
必填的结转块子部分:
- **活跃故事线** — 下周代理需要关注的持续主题/项目
- **角色** — 值得注意的命名系统/人员/工具(延续的+新增的)
- **未解决问题** — 待解答的疑问或未完成的工作
- **语气说明** — 故事的讲述方式(语气、视角、风格演变)
**语气规则:**
- 使用第三人称叙述,尖锐、客观。避免过于花哨。
- AI称为"Claude";人类用户称为"{USER_FIRST_NAME}"。
- 将代码库组件视为角色——项目中反复出现的任何命名系统(例如worker、队列、进程管理器、反复出现的bug、不稳定的迁移)都可作为角色。不要引入其他项目的名称;仅使用此项目观测数据中出现的名称。
- 不要编造戏剧性内容。如实呈现数据中的内容。
- 逐周跟踪用户提示风格的演变(沮丧标记、语气升级、风格转变)。
- 如果项目具有自反性(例如一个记录自身工作的工具、一个调试自身的AI代理、一个发现自身回归的系统),请记录这种元递归特性。
- 留意新的“反派”或“配角”并为其命名。
- 对于低谷/静默周:沉默本身就是故事。不要凑字数。说明未发生的事情。
- 对于高峰周(>2000条观测记录):选择4-7条核心故事线并清晰讲述。不要逐条罗列。
**重要提示:**请勿超出源文件内容进行推测。
完成文件撰写后,返回:
1. 你写入的文件路径
2. 结转块原文
3. 本周内容的一句话总结Narrative Budget by Observation Count
按观测记录数量分配叙事篇幅
Scale narrative length proportionally to the week's volume:
| Obs count | Narrative section budget |
|---|---|
| < 100 | 200–400 words |
| 100–500 | 300–600 words |
| 500–1,500 | 500–900 words |
| 1,500–3,000 | 700–1,100 words |
| 3,000+ | 800–1,300 words |
Pad these into the slot of the prompt for each week.
{BUDGET}根据每周的数据量按比例调整叙事长度:
| 观测记录数量 | 叙事部分篇幅预算 |
|---|---|
| < 100 | 200–400词 |
| 100–500 | 300–600词 |
| 500–1,500 | 500–900词 |
| 1,500–3,000 | 700–1,100词 |
| 3,000+ | 800–1,300词 |
将这些数值填入每个周提示的位置。
{BUDGET}The First Week
第一周
For Week 1, pass an empty and an instruction noting it's the origin chapter — the agent should establish initial cast, tone, and arcs for everyone after.
STORY_SO_FAR_BLOCK对于第1周,传入空的,并说明这是起始章节——代理需要为后续章节设定初始角色、语气和故事线。
STORY_SO_FAR_BLOCKThe Final Week
最后一周
The final week gets a different ending: no carry-forward block. Instead, instruct the agent to write a section (~250 words) naming what's still open at the moment of writing. Tell the agent the project is ongoing — the digest stops; the story doesn't. Don't give the story a false ending.
## Where We Are最后一周的结尾方式不同:无需结转块。取而代之的是,指示代理撰写一个部分(约250词),说明撰写时仍未完成的工作。告知代理项目仍在进行中——摘要结束,但故事并未结束。不要给故事一个虚假的结局。
## 当前状态When N = 1 (single-week project)
当N=1(仅一周的项目)
Apply BOTH treatments to the same chapter: empty AND instead of a carry-forward block. The agent is writing both the origin and the close in one pass. Don't reference prior or future chapters that don't exist.
STORY_SO_FAR_BLOCK## Where We Are对唯一的章节同时应用起始和结尾处理:传入空的,并以替代结转块。代理需要在一次撰写中完成起始和收尾工作。请勿引用不存在的前序或后续章节。
STORY_SO_FAR_BLOCK## 当前状态Step 6: Rename Files for Sortable Order
步骤6:重命名文件以确保排序正确
The agents write digests with names like . These already sort chronologically by ISO week (until a project crosses a year boundary inside one project name), but add a zero-padded numeric prefix so the order is unambiguous to humans browsing or scripting against the directory:
YYYY-W<NN>-digest.mdbash
cd docs/timeline-weeks/digests
total=$(ls *.md | wc -l | tr -d ' ')
width=${#total} # 1 for N<10, 2 for N<100, 3 for N<1000
[ "$width" -lt 2 ] && width=2 # always pad to at least 2 for readability
i=0
for f in *.md; do
printf -v prefix "%0${width}d" $i
mv "$f" "${prefix}-$f"
i=$((i+1))
doneResult for N=30: through . For N=4: through . For N=120: through . Always zero-pad — and sort wrong without it.
00-...md29-...md00-...md03-...md000-...md119-...md1-...md10-...mdDo NOT also prepend the order number to the digest title line inside each file. The filename prefix is for sorting; the title stays clean: .
# Week N (W##): Date — Subtitle代理生成的摘要文件名为。这些文件名已经可以按ISO周 chronological排序(除非项目在一年内跨年度),但添加零填充的数字前缀可以确保人类浏览或脚本处理时顺序明确:
YYYY-W<NN>-digest.mdbash
cd docs/timeline-weeks/digests
total=$(ls *.md | wc -l | tr -d ' ')
width=${#total} # N<10时为1,N<100时为2,N<1000时为3
[ "$width" -lt 2 ] && width=2 # 为了可读性,至少填充到2位
i=0
for f in *.md; do
printf -v prefix "%0${width}d" $i
mv "$f" "${prefix}-$f"
i=$((i+1))
done当N=30时,结果为到;当N=4时,结果为到;当N=120时,结果为到。务必使用零填充——否则和的排序会出错。
00-...md29-...md00-...md03-...md000-...md119-...md1-...md10-...md请勿在每个文件内的标题行前添加序号。文件名前缀仅用于排序;标题保持简洁:。
# 第N周(W##):日期 — 副标题Step 7: Report Completion
步骤7:报告完成情况
Tell the user:
- Total weeks digested (N)
- Output directory path
- Date range covered
- Any silent/trough weeks worth flagging
- A one-sentence capstone summarizing the arc — written by the final-chapter agent, or composed by the operator from the final agent's section.
## Where We Are
告知用户:
- 已处理的总周数(N)
- 输出目录路径
- 覆盖的日期范围
- 任何值得关注的静默/低谷周
- 一句总结整个故事线的收尾语——由最后一章的代理撰写,或由操作者根据最后一章代理生成的部分整理而成。
## 当前状态
Pipeline Discipline
流程规范
These rules emerged from running the pipeline end-to-end. Encode them every time:
- Sequential, not parallel. The whole point is the carry-forward chain. Parallelism breaks it.
- Carry-forward is bounded. It will bloat without active pruning. Tell every agent: cap ~350 words, drop dormant arcs, drop absent cast.
- Track register evolution explicitly. The user's prompt-style across weeks is a story arc. Frustration markers shift over time (whatever they happen to be in this project's data). Name the shifts.
- Treat components as characters. Whatever recurring named systems show up in the observations are this project's villains and co-stars. Stable cast across weeks builds narrative coherence.
- Honor silence. Trough weeks (10–100 obs) are real chapters. Name what didn't happen. Don't pad.
- Don't manufacture drama. Just observe the data. If the project is reflexive, the recursion is the drama; you don't need to add more.
- Final week: no false ending. The digest stops; the project doesn't. Write , not "the end."
## Where We Are
这些规则是从端到端运行流程的实践中总结出来的。每次运行都必须遵守:
- 按顺序运行,而非并行。核心价值在于结转链。并行会破坏连贯性。
- 结转块长度受限。如果不主动精简,它会膨胀。告知每个代理:限制约350词,删除休眠的故事线,删除缺席的角色。
- 明确跟踪风格演变。用户每周的提示风格是一条故事线。沮丧标记会随时间变化(取决于项目数据中的具体情况)。记录这些变化。
- 将组件视为角色。观测数据中反复出现的任何命名系统都是项目的“反派”或“配角”。稳定的跨周角色有助于构建叙事连贯性。
- 尊重沉默。低谷周(10–100条观测记录)是真实的章节。说明未发生的事情。不要凑字数。
- 不要编造戏剧性内容。只需如实呈现数据。如果项目具有自反性,递归本身就是戏剧性内容;无需额外添加。
- 最后一周:不要虚假结局。摘要结束,但项目仍在进行中。撰写,而非“结束”。
## 当前状态
Error Handling
错误处理
- Empty timeline: project name wrong, or worker not running. to verify.
curl -s "http://localhost:${WORKER_PORT}/api/search?query=*&limit=1" - Worker not running: start it via your usual method or check .
ps aux | grep worker-service - Subagent returns malformed carry-forward: extract the carry-forward block by regex () and pass forward verbatim. If missing, ask the agent to retry with the explicit instruction "your reply MUST include the carry-forward block fenced as
```carry-forward ... ```at the very end."carry-forward ... - One agent fails mid-pipeline: retry that week with the same carry-forward. Don't skip — the chain breaks.
- Carry-forward growing past ~500 words: tighten the discipline instruction in subsequent prompts. Force pruning explicitly.
- 空时间线:项目名称错误,或worker未运行。执行验证。
curl -s "http://localhost:${WORKER_PORT}/api/search?query=*&limit=1" - worker未运行:通过常规方式启动,或检查。
ps aux | grep worker-service - 子代理返回格式错误的结转块:通过正则表达式提取结转块()并原样传递。如果缺失,请要求代理重试,并明确指示“你的回复必须在最后包含用
```carry-forward ... ```包裹的结转块”。carry-forward ... - 流程中途某个代理失败:使用相同的结转块重试该周。请勿跳过——否则链条会断裂。
- 结转块长度超过约500词:在后续提示中加强精简要求。明确强制精简。
Examples
示例
Long-running project (~30 weeks)
长期项目(约30周)
User: "Make weekly digests for [project] from beginning to end"
- Resolve worker port, detect project name.
- Fetch full timeline → .
.scratch/cm-timeline.md - Run → N weekly files in
.scratch/split-timeline.py(e.g. 30).docs/timeline-weeks/ - Generate index.
docs/timeline-weeks/README.md - Launch N subagents consecutively, one per week. Each gets the prior week's carry-forward. The first chapter starts with empty carry-forward; the final chapter writes instead of a carry-forward block.
## Where We Are - Rename digests with zero-padded order prefix (through
00-...md).29-...md - Report total chapters, date range, any troughs/peaks, and the one-line capstone the final agent produced.
用户:“为[项目]生成从开始到现在的每周摘要”
- 解析worker端口,检测项目名称。
- 获取完整时间线 → 。
.scratch/cm-timeline.md - 运行→ 在
.scratch/split-timeline.py中生成N个周文件(例如30个)。docs/timeline-weeks/ - 生成索引。
docs/timeline-weeks/README.md - 按顺序启动N个子代理,每个周对应一个。每个代理接收前一周的结转块。第一章从空结转块开始;最后一章撰写而非结转块。
## 当前状态 - 为摘要文件添加零填充的序号前缀(到
00-...md)。29-...md - 报告总章节数、日期范围、任何低谷/高峰周,以及最后一个代理生成的一句收尾语。
Short-lived project (~3 weeks)
短期项目(约3周)
Same flow, just smaller. N=3, so:
- Chapter 1: empty carry-forward, establish cast/tone/arcs.
- Chapter 2: receives chapter 1's carry-forward, builds on it.
- Chapter 3: receives chapter 2's carry-forward, BUT gets the final-chapter treatment (instead of carry-forward block).
## Where We Are - Filenames: ,
00-...md,01-...md.02-...md
流程相同,只是规模更小。N=3,因此:
- 第1章:空结转块,设定角色/语气/故事线。
- 第2章:接收第1章的结转块,延续故事。
- 第3章:接收第2章的结转块,但采用最后一章的处理方式(以替代结转块)。
## 当前状态 - 文件名:、
00-...md、01-...md。02-...md
Single-week project (N=1)
单周项目(N=1)
Apply both first-and-final-chapter treatment to the only chapter: empty carry-forward, close, no inter-chapter references. Filename: .
## Where We Are00-...md对唯一的章节同时应用起始和结尾处理:空结转块,以收尾,不引用章节间内容。文件名:。
## 当前状态00-...md