Back to Details

diary

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Diary

实现日记

An implementation diary captures the narrative of your work: what you did, why, what worked, what broke, what was tricky, and what needs review. The concept of "diary" activates existing behavioral patterns without requiring much engineering -- the model already knows what a diary is.
实现日记用于记录你的工作过程：做了什么、为什么这么做、哪些方案有效、哪里出了问题、遇到的难点，以及需要评审的内容。“日记”的概念借助了已有的行为模式，无需额外的工程化改造——模型本身就理解日记的含义。

Working Loop

工作循环

Follow this cycle for each meaningful unit of progress:
  1. Implement -- make the code change
  2. Update diary -- add or update the current step in the diary file
  3. Commit -- commit the code and diary together
A "step" is a logical chunk of work, not necessarily a single commit. Examples: "wire up the API endpoint", "debug the flaky test", "research how the auth middleware works".
针对每个有意义的进度单元，遵循以下流程：
  1. 实现 —— 完成代码变更
  2. 更新日记 —— 在日记文件中添加或更新当前步骤
  3. 提交 —— 同时提交代码和日记
一个“步骤”是逻辑上的工作块，不一定对应单次提交。例如：“对接API接口”、“调试不稳定的测试用例”、“研究认证中间件的工作原理”。

File Location

文件位置

Diary files live at 
docs/diary/YYYY-MM-DD-<slug>.md
relative to the project root.
  • The date is when work on the task started
  • The slug is free-form: a feature name, ticket reference, or whatever describes the task
  • One file per task or feature -- if work spans multiple days, steps accumulate in the same file
  • Create the 
    docs/diary/
    directory if it doesn't exist
Examples:
  • docs/diary/2026-03-25-add-diary-skill.md
  • docs/diary/2026-03-20-fix-auth-race-condition.md
  • docs/diary/2026-03-18-PROJ-123.md
日记文件存放在项目根目录下的
docs/diary/YYYY-MM-DD-<slug>.md
路径中。
  • 日期为任务启动的日期
  • Slug为自定义内容：可以是功能名称、工单编号，或任何能描述任务的内容
  • 每个任务或功能对应一个文件——若工作跨多天，后续步骤累积到同一个文件中
  • 若
    docs/diary/
    目录不存在，请创建该目录
示例：
  • docs/diary/2026-03-25-add-diary-skill.md
  • docs/diary/2026-03-20-fix-auth-race-condition.md
  • docs/diary/2026-03-18-PROJ-123.md

Diary File Structure

日记文件结构

markdown
undefined
markdown
undefined

Diary: <task description>

Diary: <task description>

Brief description of the goal and context for this task.
Brief description of the goal and context for this task.

Step 1: <short description>

Step 1: <short description>

Prompt Context

Prompt Context

Verbatim prompt: <the exact user prompt that initiated this step> Interpretation: <what the assistant understood from the prompt> Inferred intent: <the underlying goal behind the prompt>
Verbatim prompt: <the exact user prompt that initiated this step> Interpretation: <what the assistant understood from the prompt> Inferred intent: <the underlying goal behind the prompt>

What I did

What I did

<factual description of actions taken, files touched, commands run>
<factual description of actions taken, files touched, commands run>

Why

Why

<connects the actions to the goal>
<connects the actions to the goal>

What worked

What worked

<positive signals worth replicating>
<positive signals worth replicating>

What didn't work

What didn't work

<failures recorded immediately with verbatim errors and commands>
<failures recorded immediately with verbatim errors and commands>

What I learned

What I learned

<tacit knowledge that isn't obvious from the code>
<tacit knowledge that isn't obvious from the code>

What was tricky

What was tricky

<friction points, hidden complexity, sharp edges>
<friction points, hidden complexity, sharp edges>

What warrants review

What warrants review

<tells a reviewer where to look and how to validate>
<tells a reviewer where to look and how to validate>

Future work

Future work

<implied follow-ups that naturally fell out of the work, not a wishlist>
<implied follow-ups that naturally fell out of the work, not a wishlist>

Step 2: <short description>

Step 2: <short description>

...
undefined
...
undefined

Writing Rules

写作规则

  • Prose-first. The diary is a narrative, not a log dump. Technical details (paths, hashes, error messages) are included inline but wrapped in readable prose.
  • All sections, every step. Never skip a section. If "What didn't work" is genuinely empty because everything went smoothly, say that explicitly.
  • Failures are gold. Record them immediately with verbatim error messages and the exact commands that produced them. These are the most valuable parts of the diary.
  • Absolute paths from project root. All file paths referenced in the diary are absolute relative to the project root (e.g., 
    /src/handler.go
    ).
  • Prompt Context is verbatim. Copy the user's prompt exactly as given. Don't paraphrase the verbatim section.
  • 以叙述为主：日记是一份叙事记录，而非日志堆砌。技术细节（路径、哈希值、错误信息）需嵌入可读性强的叙述内容中。
  • 每步必填所有章节：切勿跳过任何章节。若“未成功方案”确实无内容（一切进展顺利），请明确说明这一点。
  • 失败记录是核心价值：立即记录失败情况，包含确切的错误信息和执行的命令。这些是日记中最有价值的部分。
  • 使用项目根目录绝对路径：日记中提及的所有文件路径均为相对于项目根目录的绝对路径（例如：
    /src/handler.go
    ）。
  • Prompt Context需完全还原：精确复制用户的原始Prompt，切勿改写该部分内容。

When to Activate

启用场景

This skill activates proactively during non-trivial implementation work:
  • New features
  • Bug fixes
  • Refactors
  • Research spikes
Do not activate for:
  • One-line fixes
  • Config tweaks
  • Quick questions about the codebase
  • Trivial changes that don't warrant narration
在进行以下非琐碎的实现工作时，主动启用该技能：
  • 新功能开发
  • Bug修复
  • 代码重构
  • 研究探索
请勿在以下场景启用：
  • 单行代码修复
  • 配置调整
  • 代码库快速答疑
  • 无需记录的琐碎变更