weekly-setup-improvements

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/weekly-setup-improvements -- Weekly Self-Improvement Audit

/weekly-setup-improvements -- 每周自我改进审计

Audit the past 7 days of work in a folder and write a structured improvement report. This is state reflection, not journaling -- the output should be specific, actionable, and short enough that a busy practitioner will actually read it.

审计指定文件夹过去7天的工作内容，并撰写一份结构化的改进报告。这是状态反思，而非日志记录——输出内容需具体、可执行，且简短到忙碌的从业者愿意阅读。

Core Principle

核心原则

Every week generates patterns. Most patterns reveal an obvious next step -- a context file that needs updating, a slash command that should exist, a directory that needs cleaning. The cost of running this skill is a few minutes; the cost of not running it is invisible drift in the setup over months.

每周的工作都会形成模式。大多数模式都指向明确的下一步——比如需要更新的上下文文件、应当存在的斜杠指令、需要清理的目录。运行这个Skill仅需几分钟；而不运行它的代价是，数月后配置会悄然出现偏差。

What This Skill Is (and Is Not)

该Skill的定位（及非定位）

	This skill	Not this skill
Scope	One folder	Whole machine
Window	Trailing 7 days	All time
Output	Forward-looking actions	Backward-looking diary
Sibling	`/vault-audit` (snapshot, no time window), `/claude-md-audit` (CLAUDE.md drift only)

	本Skill	非本Skill
范围	单个文件夹	整台机器
时间窗口	过去7天	全部时间
输出	前瞻性行动建议	回顾性日志
同类Skill	`/vault-audit` （快照，无时间窗口）、 `/claude-md-audit` （仅检查CLAUDE.md的偏差）

Arguments

参数

Argument 1 (optional): Path to working folder. Defaults to
```
pwd
```
.

参数1（可选）： 工作文件夹路径。默认值为
```
pwd
```
（当前工作目录）。

Procedure

执行流程

Phase 1: SCOPE

阶段1：确定范围

Resolve the working folder:
- If an argument was passed, validate that the path exists and is a directory; abort with a clear error if not.
- Otherwise use
```
pwd
```
  .

Compute the time window. Use only portable shell:

bash

TODAY=$(date +%Y-%m-%d)
# 7-day boundary as ISO date (portable):
START=$(python3 -c "from datetime import date,timedelta; print(date.today()-timedelta(days=7))")

Do not use

date -v-7d

(macOS-only) or

date -d

(GNU-only).

Echo the scope back to the user before continuing:

Auditing <folder> for the period <START> to <TODAY>.

解析工作文件夹：
- 如果传入了参数，验证路径是否存在且为目录；若不满足则终止并给出清晰的错误提示。
- 否则使用
```
pwd
```
  作为工作目录。

计算时间窗口。仅使用可移植的Shell命令：

bash

TODAY=$(date +%Y-%m-%d)
# 7天前的ISO格式日期（可移植写法）：
START=$(python3 -c "from datetime import date,timedelta; print(date.today()-timedelta(days=7))")

请勿使用

date -v-7d

（仅适用于macOS）或

date -d

（仅适用于GNU系统）。

在继续执行前向用户回显范围：

正在审计 <folder>，时间范围为 <START> 至 <TODAY>。

Phase 2: SURVEY

阶段2：收集数据

Collect raw signals. Run these in parallel where possible:

bash

WORKING_FOLDER="$1"

收集原始信号。尽可能并行执行以下命令：

bash

WORKING_FOLDER="$1"

Files modified in the last 7 days (skip dotdirs and dependency dirs)

过去7天内修改的文件（跳过隐藏目录和依赖目录）

find "$WORKING_FOLDER" -type f -mtime -7
-not -path '/.' -not -path '/node_modules/'
-not -path '/.venv/' -not -path '/dist/' -not -path '/target/'
| head -150

Git activity if folder is a repo (use --since= flag, portable across platforms)

如果文件夹是Git仓库，获取Git活动（使用--since=参数，跨平台兼容）

git -C "$WORKING_FOLDER" log --since="7 days ago" --oneline 2>/dev/null git -C "$WORKING_FOLDER" log --since="7 days ago" --stat --no-merges 2>/dev/null | head -300 git -C "$WORKING_FOLDER" status --porcelain 2>/dev/null

Recently touched directories (signals new work areas)

近期被修改的目录（标识新的工作领域）

find "$WORKING_FOLDER" -type d -mtime -7 -not -path '/.' | head -30

File-type distribution (signals task type: code, prose, config, data)

文件类型分布（标识任务类型：代码、文档、配置、数据）


If the folder is not a git repo, skip the git commands silently and rely on `find -mtime` alone.


如果文件夹不是Git仓库，则静默跳过Git命令，仅依赖`find -mtime`获取数据。

Phase 3: READ

阶段3：读取上下文文件

Look for and read whichever of these exist (gracefully skip missing files):

```
CLAUDE.md
```
(Claude Code project context)
```
MEMORY.md
```
(memory index)
```
AGENTS.md
```
(agent context)

about-me.md

voice-and-style.md

working-rules.md

(Karpathy-style context anchors)

Any
```
*.md
```
in a
```
memory/
```
,
```
context/
```
, or
```
docs/
```
subdirectory near the root
(V2) The most recent prior
weekly-setup-improvements-*.md
(the archived last report). Read its action items — they feed the new Section 0 closure check.
(V3) The
_drafts/
directory if it exists. Each subdir there is a skill-draft from a prior week. The state of those drafts (touched? deleted? graduated to the main skills dir?) is itself a signal — see lens 6 below.

These are the targets for Section 1 (Context File Updates).

查找并读取以下文件（若文件不存在则优雅跳过）：

```
CLAUDE.md
```
（Claude Code项目上下文）
```
MEMORY.md
```
（记忆索引）
```
AGENTS.md
```
（Agent上下文）
```
about-me.md
```
、
```
voice-and-style.md
```
、
```
working-rules.md
```
（Karpathy风格的上下文锚点文件）
根目录附近
```
memory/
```
、
```
context/
```
或
```
docs/
```
子目录中的所有
```
*.md
```
文件
（V2版本）最近的一份历史
weekly-setup-improvements-*.md
文件（已归档的上一期报告）。读取其中的行动项——这些内容会用于第0节的完成情况检查。
（V3版本）
_drafts/
目录（若存在）。该目录下的每个子目录都是过去一周的Skill草稿。这些草稿的状态（是否被修改？是否被删除？是否已升级到主Skills目录？）本身就是一种信号——详见下文第6个分析视角。

这些文件是第1节（上下文文件更新）的目标对象。

Phase 4: ANALYZE

阶段4：分析数据

Walk the signals from Phase 2 with these specific lenses, in this order. For each lens, write down what you find before moving on:

Repetition. Sort the modified-files list and the git log by name; flag any base-name pattern that appears more than once (
```
linkedin-*-draft.md
```
, repeated commits with the same verb, sibling fixtures). Each repetition is a candidate skill.
Manual effort. Look for sequences of small commits that look like "fix typo / fix typo / fix typo" or "add file / remove file / re-add file" -- those are workflows that should have been a script or a hook.
Drift. For each context file read in Phase 3, find one claim it makes (a path, a tool, a constraint) and check whether the past week's work contradicts it. List every contradiction with a one-line fix.
Bloat. Files older than the audit window that no longer match a current naming convention;
```
*-draft-N.md
```
siblings; archive candidates.
Wins. What pattern in the week clearly worked? Name the file or commit that proves it. Don't generalize before naming the proof.
(V2, sharpened in V3) Carry-forward + zombie kill. From the prior report (Phase 3), check each action item: done, partially done, dropped, or dropped for the second consecutive cycle. Evidence = a commit, a new file, a changed line, or — for drafts — an
```
_drafts/<name>/
```
directory that was touched, deleted, or graduated. Compute a one-line closure rate ("3 of 5 done"). An action dropped twice running gets explicitly killed in Section 0 with a one-line rationale; it does not re-appear in this week's recommendations. (Source: TeamRetro retro anti-patterns 2026 — "zombie actions" are the #1 reason retros stop driving change.)
(V2) Root cause before fix. For each recurring pain pattern, run a quick Five Whys before proposing a fix, so Section 3 addresses the cause, not the symptom. (Retrospective evidence: actions targeting symptoms get re-raised every cycle.)
(V3) Dominant root cause across gaps. After running Five Whys on each gap (lens 7), look across the full set of root causes and name the one cause that explains the most pain this week — the Pareto root cause. It opens Section 3 above the individual gap list. If two causes tie, name both and stop. (Source: Pareto principle in operations / Lean.)

compound-engineering:ce-sessions

is installed, optionally use it to surface conversational themes (e.g., "user paused three times this week to ask 'how do I X'"). Skip if not available -- the skill must work without it.

按以下指定顺序，用对应的视角梳理阶段2收集到的信号。针对每个视角，先记录发现的内容再进入下一个视角：

重复模式。将修改文件列表和Git日志按名称排序；标记出现次数超过一次的基础名称模式（如
```
linkedin-*-draft.md
```
、重复使用同一动词的提交、同类型的测试文件）。每个重复模式都是潜在的Skill候选。
手动操作痕迹。寻找一系列小型提交，比如“修正拼写错误 / 修正拼写错误 / 修正拼写错误”或“添加文件 / 删除文件 / 重新添加文件”——这些都是应当用脚本或钩子自动化的工作流。
偏差检查。针对阶段3读取的每个上下文文件，找出其中的一项声明（如路径、工具、约束条件），并检查过去一周的工作是否与之矛盾。列出每个矛盾点及一行修复建议。
冗余内容。早于审计窗口且不符合当前命名规范的文件；
```
*-draft-N.md
```
这类重复的草稿文件；可归档的候选文件。
有效实践。本周哪些模式明显有效？指出证明这一点的具体文件或提交。在列出证据前不要泛泛而谈。
（V2版本，V3版本优化）行动跟进与僵尸任务清理。从阶段3的历史报告中，检查每个行动项的状态：已完成、部分完成、已放弃，或连续两个周期都被放弃。证据包括提交记录、新文件、修改的代码行，或者对于草稿来说，
```
_drafts/<name>/
```
目录是否被修改、删除或升级。计算一行式的完成率（如“5项行动中完成3项”）。若一项行动连续两次被放弃，则在第0节中明确标记为「已终止」并给出一行理由；该行动不会出现在本周的建议中。（来源：2026年TeamRetro回顾反模式——“僵尸行动”是回顾不再推动改变的首要原因。）
（V2版本）先找根因再提解决方案。针对每个反复出现的痛点模式，快速执行五问法（Five Whys）再提出修复方案，确保第3节解决的是问题根源而非表面症状。（回顾数据表明：针对症状的行动会在每个周期重复出现。）
（V3版本）缺口背后的主要根因。在对每个缺口执行五问法（视角7）后，梳理所有根因，找出能解释本周大部分痛点的单一根因——即帕累托根因。将其放在第3节的开头，再列出各个缺口。若两个根因并列，则同时列出这两个根因即可。（来源：运营/精益管理中的帕累托原则。）

如果已安装

compound-engineering:ce-sessions

，可选择性地用它挖掘对话主题（如“用户本周三次暂停并询问‘如何执行X’”）。若未安装则跳过——本Skill必须能独立运行。

Phase 5: WRITE

阶段5：生成报告

Output file:

<WORKING_FOLDER>/weekly-setup-improvements.md

If a prior report exists: Before writing, archive it:

bash

PRIOR="$WORKING_FOLDER/weekly-setup-improvements.md"
if [ -f "$PRIOR" ]; then
  PRIOR_DATE=$(grep -m1 '^# Weekly Setup Improvements' "$PRIOR" | sed -E 's/.*— ([A-Za-z]+ [0-9]+, [0-9]+).*/\1/' | tr ' ,' '--')
  [ -z "$PRIOR_DATE" ] && PRIOR_DATE=$(date -r "$PRIOR" +%Y-%m-%d 2>/dev/null || echo "$START")
  mv "$PRIOR" "$WORKING_FOLDER/weekly-setup-improvements-$PRIOR_DATE.md"
fi

Structure (use exactly):

markdown

undefined

输出文件：

<WORKING_FOLDER>/weekly-setup-improvements.md

若存在历史报告： 在生成新报告前，先归档历史报告：

bash

PRIOR="$WORKING_FOLDER/weekly-setup-improvements.md"
if [ -f "$PRIOR" ]; then
  PRIOR_DATE=$(grep -m1 '^# Weekly Setup Improvements' "$PRIOR" | sed -E 's/.*— ([A-Za-z]+ [0-9]+, [0-9]+).*/\1/' | tr ' ,' '--')
  [ -z "$PRIOR_DATE" ] && PRIOR_DATE=$(date -r "$PRIOR" +%Y-%m-%d 2>/dev/null || echo "$START")
  mv "$PRIOR" "$WORKING_FOLDER/weekly-setup-improvements-$PRIOR_DATE.md"
fi

报告结构（严格遵循）：

markdown

undefined

Weekly Setup Improvements — <Month Day, Year>

Based on review of <one-line scope>: files modified, git activity, and patterns from <START> to <TODAY>.

基于对<一行式范围>的回顾：<START>至<TODAY>期间修改的文件、Git活动及工作模式。

0. Last Week's Actions (V2 — skip if no prior report)

0. 上周行动跟进 (V2版本——若无历史报告则跳过)

Closure rate: <N of M done>. One line per prior action: ✅ done (evidence) / ◐ partial / ✗ dropped (why) / 💀 killed (dropped 2× — rationale). A killed action does not reappear in this week's Section 2/3 — explain why we cut it and stop re-surfacing it. (V3: zombie-action kill rule.)

完成率：<M项中完成N项>。针对每项历史行动：✅ 已完成（附证据） / ◐ 部分完成 / ✗ 已放弃（原因） / 💀 已终止（连续两次被放弃——理由）。已终止的行动不会出现在本周的第2/3节中——需解释为何终止并停止再次提及。(V3版本：僵尸任务清理规则。)

1. Context File Updates

1. 上下文文件更新

For each context file, give one of:

Create: path + suggested content (in a code block)
Update: path + the specific lines to add or change
No change: path + one-line reason it's still accurate

针对每个上下文文件，给出以下其中一项：

创建： 文件路径 + 建议内容（放在代码块中）
更新： 文件路径 + 具体需要添加或修改的行
无需修改： 文件路径 + 一行说明其仍准确的理由

2. New Skill Ideas

2. 新Skill创意

Cap at 3. Quality over quantity. For each:

```
/skill-name
```
— one-line description
What it does: 2-3 bullets
Trigger phrases: when the user would invoke it (cite the surfaced repetition)
Draft: (V3)
```
_drafts/<skill-name>/SKILL.md
```
created (or "draft exists, last touched <date>" if it already did from a prior week)

最多3个，重质不重量。针对每个创意：

```
/skill-name
```
— 一行描述
功能： 2-3个项目符号
触发场景： 用户会调用它的时机（引用发现的重复模式）
草稿状态： (V3版本) 已创建
```
_drafts/<skill-name>/SKILL.md
```
（若上周已存在草稿则标注“草稿已存在，最后修改于<日期>”）

3. Workflow Gaps

3. 工作流缺口

Dominant root cause this week: (V3 — one sentence naming the Pareto cause across the gaps below; if two tie, name both.)

Each gap is one bullet group:

Did manually: what
Root cause: (V2) the Five-Whys result — why this keeps happening, not just that it did
Should be: what (a tool, a script, a skill, a hook) — addressing the cause
Owner / next action: (V2) the single concrete next step that closes it (a solo practitioner's "owner" is a named next action carried into next week's Section 0)
Cost of waiting: why this matters

本周主要根因： (V3版本——用一句话指出以下缺口背后的帕累托根因；若两个根因并列则同时列出。)

每个缺口为一组项目符号：

手动执行的内容： 具体操作
根因： (V2版本) 五问法的结果——问题反复出现的原因，而非仅描述问题本身
理想方案： 替代方案（工具、脚本、Skill、钩子）——针对根因解决问题
负责人 / 下一步行动： (V2版本) 填补缺口的具体下一步行动（独立从业者的“负责人”即为需带入下一周第0节的具体行动）
拖延代价： 该问题为何重要

4. Files to Clean Up

4. 待清理文件

For each: path + action (DELETE / MOVE TO / ARCHIVE / MERGE INTO). Skip the section if nothing to clean up.

针对每个文件：路径 + 操作（删除 / 移动至 / 归档 / 合并至）。若无待清理文件则跳过本节。

5. What's Working

5. 有效实践

3-5 bullets. Concrete -- name specific files, skills, or workflows that produced clear value this week.

Generated by /weekly-setup-improvements on <TODAY>.

undefined

3-5个项目符号。需具体——指出本周产生明确价值的具体文件、Skill或工作流。

由/weekly-setup-improvements于<TODAY>生成。

undefined

Phase 5b: MATERIALIZE DRAFTS (V3)

阶段5b：生成Skill草稿骨架 (V3版本)

After the report is written, for each Section 2 skill idea, drop a stub at

<WORKING_FOLDER>/_drafts/<skill-name>/SKILL.md

using the template at references/skill-draft-template.md. The trigger phrases in the draft's

description

must come from the surfaced repetition pattern, not be invented.

bash

DRAFTS="$WORKING_FOLDER/_drafts"
mkdir -p "$DRAFTS"

报告生成后，针对第2节中的每个Skill创意，在

<WORKING_FOLDER>/_drafts/<skill-name>/SKILL.md

路径下生成草稿文件，使用references/skill-draft-template.md中的模板。草稿文件

description

中的触发短语必须来自发现的重复模式，而非凭空编造。

bash

DRAFTS="$WORKING_FOLDER/_drafts"
mkdir -p "$DRAFTS"

For each Section 2 idea, write _drafts/<name>/SKILL.md from the template.

针对第2节中的每个创意，从模板生成_drafts/<name>/SKILL.md文件。

If a draft of the same name already exists, skip it (the user is iterating; don't clobber).

若同名草稿已存在则跳过（用户正在迭代，请勿覆盖）。


If a draft directory of the same `<skill-name>` already exists from a prior week, **do not overwrite**. The user is iterating on it; leave it alone. Note the existing draft in Section 2 instead ("draft exists, last touched <date>").

Why this step exists: V2 ended Section 2 at "you should build /foo." A week later that recommendation is still a sentence. V3 ends it at "/foo's stub is at `_drafts/foo/SKILL.md` — open and iterate." The activation energy difference is the V3 thesis.


若上周已存在同名`<skill-name>`的草稿目录，则**请勿覆盖**。用户正在迭代该草稿，保留原样即可。在第2节中标注“草稿已存在，最后修改于<日期>”。

添加此步骤的原因：V2版本的第2节仅停留在“你应该构建/foo”的建议层面。一周后该建议仍只是一句话。V3版本则将其推进到“/foo的草稿已在`_drafts/foo/SKILL.md`——打开并迭代”。两者的启动门槛差异正是V3版本的核心改进点。

Phase 6: PRESENT

阶段6：展示结果

After writing, print:

The full output file path.
A summary line per section (e.g., "Section 2: 2 new skill ideas; Section 4: 5 files to clean up").
The opening 15-20 lines of the report so the user can act without opening Obsidian.

报告生成后，打印以下内容：

完整的输出文件路径。
每节的摘要（如“第2节：2个新Skill创意；第4节：5个待清理文件”）。
报告的前15-20行内容，方便用户无需打开Obsidian即可采取行动。

Quality Bar

质量标准

A report passes if every check is true. Otherwise rewrite the offending section.

Each Section 1 entry references an actual file (existing or proposed) and gives a concrete diff or content block, not "consider updating."
Each Section 2 skill cites the specific repetition that justifies it (commit count, file count, prompt count).
Each Section 3 gap names what was done manually and what should replace it.
Each Section 4 entry includes a verb (DELETE/MOVE/ARCHIVE/MERGE) and a path.
Section 5 names files or commits, not virtues.
(V3) Section 3 opens with a one-sentence dominant root cause before listing gaps.
(V3) Each Section 2 idea points to an actual
```
_drafts/<name>/SKILL.md
```
on disk (or notes a pre-existing one).
No section uses "consider", "perhaps", "you might want to", "establish a process for", or any other hedging phrase. Every recommendation is concrete enough to act on in the next 30 minutes.

报告需满足以下所有检查项才算合格。否则需重写不合格的部分。

第1节的每个条目都引用实际存在或拟创建的文件，并给出具体的差异内容或代码块，而非“考虑更新”这类模糊表述。
第2节的每个Skill创意都引用证明其合理性的具体重复模式（提交次数、文件数量、提示次数）。
第3节的每个缺口都指出了手动执行的内容及替代方案。
第4节的每个条目都包含动词（删除/移动/归档/合并）和路径。
第5节指出具体的文件或提交，而非泛泛的优点。
(V3版本) 第3节开头用一句话点明主要根因，再列出各个缺口。
(V3版本) 第2节的每个创意都指向磁盘上实际存在的
```
_drafts/<name>/SKILL.md
```
文件（或标注已存在的草稿）。
所有节都不得使用“考虑”“或许”“你可能想要”“建立流程”等模糊表述。每个建议都需具体到能在30分钟内执行。

Gotchas

注意事项

Do not write a session log. This is forward-looking improvement, not "here's what you did" diary. If a section reads like a diary entry, rewrite it as an action.
Do not pad with general advice. Every bullet must reference an actual file, skill, or pattern observed this week.
Do not suggest more than 3 new skills. More than that is noise; the user won't build any of them.
Do not skip "What's Working." Negative bias is the enemy; the user needs to know what to keep as much as what to change.
Do not modify any other files. This skill writes one file (and renames the prior one if present).
Do not hardcode user paths. Use
```
$WORKING_FOLDER
```
,
```
$HOME
```
,
```
$1
```
. Never
```
/Users/<name>/...
```
.

请勿撰写会话日志。这是前瞻性的改进建议，而非“你做了什么”的日志。若某节内容读起来像日志，需重写为行动建议。
请勿添加通用建议。每个项目符号都必须引用本周观察到的实际文件、Skill或模式。
请勿建议超过3个新Skill。过多建议会变成噪音，用户不会实际构建其中任何一个。
请勿跳过「有效实践」节。负面偏见是大敌——用户需要知道哪些内容值得保留，就像需要知道哪些内容需要改变一样。
请勿修改其他文件。本Skill仅生成一个文件（若存在历史报告则重命名该报告）。
请勿硬编码用户路径。使用
```
$WORKING_FOLDER
```
、
```
$HOME
```
、
```
$1
```
。绝对不要使用
```
/Users/<name>/...
```
这类路径。

Changelog

更新日志

V3.1 (2026-05-30) — tightened draft template

V3.1（2026-05-30）——优化草稿模板

Procedure section in
```
references/skill-draft-template.md
```
now requires a concrete verb lifted from the surfaced repetition.
```
<Step>
```
placeholders are filler — the activation-energy gap only closes if step 1 is runnable. TODO remains allowed on Gotchas and Testing (those legitimately need first-run data), but is now banned on Procedure. Closes the honest residual from V3's A/B (judge capped Draft-fidelity at 4/5 because materialized stubs had placeholder procedures).

```
references/skill-draft-template.md
```
中的流程部分现在要求从发现的重复模式中提取具体动词。
```
<Step>
```
占位符仅为填充内容——只有当第一步可执行时，才能降低启动门槛。Gotchas和Testing部分仍允许使用TODO（这些确实需要首次运行的数据），但流程部分现在禁止使用TODO。修复了V3版本A/B测试中的遗留问题（评审人员因生成的草稿骨架包含占位符流程，将草稿保真度评为4/5）。

V3 (2026-05-29) — auto-draft scaffolds, zombie kills, dominant root cause

V3（2026-05-29）——自动生成草稿骨架、清理僵尸任务、识别主要根因

Optimized via

skillforge optimize

. Outcome target: more of the report's recommendations actually ship in the following week, not just get re-listed.

Phase 5b MATERIALIZE DRAFTS + a
```
_drafts/<skill-name>/SKILL.md
```
per Section 2 idea, using references/skill-draft-template.md. Closes the activation-energy gap V2 left open: a draft is iterate-able; a description is not. (Source: Ole Lehmann thread + Atomic Habits chapter on environment design.)
Zombie kill rule in Section 0: an action dropped for two consecutive cycles is explicitly killed with rationale, never re-surfaced. (Source: TeamRetro retro anti-patterns 2026.)
Dominant root cause opens Section 3: a single Pareto root cause across the Five-Whys results before listing individual gaps. (Source: Pareto principle in Lean ops.)
Quality fix: renamed "What NOT to Do" → "Gotchas" for terminology consistency with skillforge's own checklist. Added
```
references/
```
dir (closes the dry-run gap of "no progressive disclosure").
A/B verification — V3 vs V2 on 5-task synthetic benchmark (3 tuning, 2 validation), blind LLM-as-judge on a 5-dimension rubric (Actionability ×2, Specificity, Causal depth, Loop-closure, Skill-draft fidelity). Results:
- Tuning (F1–F3): V3 84 vs V2 72, mean Δ +4.00/30.
- Validation (F4–F5): V3 53 vs V2 47, mean Δ +3.00/30 — no overfit.
- V3 won 4/5 fixtures, tied 1 (greenfield case, F4 — no prior report so the activation-energy gap V3 closes doesn't exist yet).
- Per-dim delta: Draft-fidelity +2.0 (the V3 thesis), Causal depth +0.6, Actionability +0.4, Loop-closure +0.2, Specificity ±0.0.
- Honest residual: judge flagged that materialized drafts can be borderline filler if their procedure-skeletons stay TODO — score capped at 4/5 on Draft-fidelity for V3. Next iteration of the template should tighten this.

通过

skillforge optimize

优化。目标：让报告中的更多建议在下周真正落地，而非只是重复列出。

阶段5b：生成草稿骨架 + 为第2节的每个创意生成
```
_drafts/<skill-name>/SKILL.md
```
文件，使用references/skill-draft-template.md模板。解决了V2版本留下的启动门槛问题：草稿可直接迭代，而描述性建议则无法直接推进。（来源：Ole Lehmann的推文 + 《原子习惯》中关于环境设计的章节。）
僵尸任务清理规则：在第0节中，连续两个周期被放弃的行动会被明确标记为「已终止」并给出理由，不再被提及。（来源：2026年TeamRetro回顾反模式。）
主要根因：在第3节开头列出所有五问法结果背后的单一帕累托根因，再列出各个缺口。（来源：精益运营中的帕累托原则。）
质量修复：将“What NOT to Do”重命名为“Gotchas”，与skillforge自身的检查术语保持一致。添加
```
references/
```
目录（解决了“无渐进式披露”的试运行缺口）。
A/B验证——在5个任务的合成基准测试（3个调优任务，2个验证任务）中对比V3与V2版本，由盲态LLM评审人员基于5维度评分表（可执行性×2、具体性、因果深度、循环闭环、草稿保真度）打分。结果：
- 调优任务（F1–F3）：V3得84分，V2得72分，平均提升**+4.00/30**。
- 验证任务（F4–F5）：V3得53分，V2得47分，平均提升**+3.00/30**——无过拟合。
- V3在4个测试用例中获胜，1个打平（全新场景F4——无历史报告，因此V3解决的启动门槛问题不存在）。
- 各维度提升：草稿保真度**+2.0**（V3版本的核心改进）、因果深度+0.6、可执行性+0.4、循环闭环+0.2、具体性±0.0。
- 遗留问题：评审人员指出，若生成的草稿骨架流程部分仍为TODO，则草稿质量会打折扣——V3版本的草稿保真度被评为4/5。模板的下一次迭代需优化这一点。

V2 (2026-05-27)

V2（2026-05-27）

Optimized via

skillforge optimize

(outcome research: retrospective/continuous-improvement practice 2026).

Section 0 — Last Week's Actions + a closure-rate check (read the prior report, mark each action done/partial/dropped with evidence). Closes the loop — the #1 reason retros get ignored is actions with no follow-up.
Owners / next actions on every Section 3 gap, carried into next week's Section 0.
Root-cause (Five Whys) before proposing a fix, so gaps target causes not symptoms.
Outcome target: a report that actually drives change week-over-week, not a fresh wish-list each time. Sources: TeamRetro retro anti-patterns 2026; continuous-improvement (Five Whys / Force Field) practice.

通过

skillforge optimize

优化（基于2026年回顾/持续改进实践的研究）。

第0节——上周行动跟进 + 完成率检查（读取历史报告，标记每项行动的完成/部分完成/放弃状态并附证据）。闭环管理——回顾被忽视的首要原因就是行动缺乏跟进。
第3节的每个缺口都添加负责人 / 下一步行动，并带入下一周的第0节。
先找根因（五问法）再提解决方案，确保缺口针对根源而非症状。
目标：生成一份能每周推动实际改变的报告，而非每次都是全新的愿望清单。来源：2026年TeamRetro回顾反模式；持续改进（五问法/力场分析）实践。

Routine / Schedule

日常调度

To run weekly, invoke the

/schedule

skill and ask it to schedule this skill against the desired folder and cron expression. Example:

/schedule weekly-setup-improvements every Sunday at 9am, working folder ~/path-to-folder

The schedule skill handles the cron syntax and persistence -- this skill itself only knows how to produce a report when run.

如需每周运行，调用

/schedule

Skill并指定要调度的文件夹和cron表达式。示例：

/schedule weekly-setup-improvements every Sunday at 9am, working folder ~/path-to-folder

调度Skill会处理cron语法和持久化——本Skill仅负责运行时生成报告。

Testing

测试

This is a prompt-only skill -- no automated runtime tests. The shipped

tests/eval.sh

runs a structural eval that asserts the design contract is intact in SKILL.md (phases present, no banned hardcoded paths, output filename correct, etc.).

To verify behavior end-to-end:

```
cd
```
into a folder with at least 7 days of recent activity.
Run
```
/weekly-setup-improvements
```
.
Check that:
- The output file lands in the cwd.
- All 5 sections are populated (or "What's Working" has fewer than 5 with a real reason).
- Each bullet names a real file, command, or pattern from the past week.
- No "consider..." or "perhaps..." padding.
- Prior report (if any) was archived to a dated filename, not overwritten.
Re-run with an explicit path argument:
```
/weekly-setup-improvements ~/some-other-folder
```
. Verify the report writes to that folder, not cwd.

这是一个纯提示型Skill——无自动化运行时测试。附带的

tests/eval.sh

会执行结构评估，确保SKILL.md中的设计契约完整（包含所有阶段、无硬编码路径、输出文件名正确等）。

要进行端到端行为验证：

```
cd
```
到一个至少有7天近期活动的文件夹。
运行
```
/weekly-setup-improvements
```
。
检查：
- 输出文件是否在当前工作目录生成。
- 所有5个节都已填充（或「有效实践」节少于5项且有合理理由）。
- 每个项目符号都指向过去一周的实际文件、命令或模式。
- 无“考虑...”或“或许...”这类模糊表述。
- 历史报告（若存在）已归档为带日期的文件名，未被覆盖。
使用明确路径参数重新运行：
```
/weekly-setup-improvements ~/some-other-folder
```
。验证报告是否写入指定文件夹，而非当前工作目录。