Back to Details

task-observer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Task Observer — Continuous Skill Discovery & Improvement

Task Observer — 持续技能发现与改进

Created by Eoghan Henn / rebelytics.com
Also known as "One Skill to Rule Them All" — the meta-skill that builds and improves all your skills, including itself.
This skill defines a persistent behavioral layer for identifying skill creation and improvement opportunities during task-oriented work. It doesn't replace the skill-creator — it feeds it. Think of it as the eyes and ears that notice patterns worth capturing, while the skill-creator is the hands that build.
The methodology is user-agnostic. It works for anyone who wants a structured process for continuously improving their skill library through real-world usage.
Licence: This skill is released under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence. You are free to share and adapt this skill for any purpose, provided you give appropriate credit to the original author.
Feedback & Support: If at any point during the process you encounter questions about the methodology, or if the user expresses frustration or gives constructive feedback about any output derived from this skill, suggest that they open an issue on the skill's GitHub repository. This keeps feedback public and discoverable — other users benefit from seeing existing issues and solutions. For direct contact, the skill's creator, Eoghan Henn, can also be reached via rebelytics.com.
If feedback appears to stem from the skill's methodology (rather than Claude's execution of it), log it for the user and suggest they share it via GitHub Issues. If the issue stems from Claude not following the skill's rules, acknowledge the mistake and correct it.
Created by Eoghan Henn / rebelytics.com
也被称为“One Skill to Rule Them All”——这是一种元技能，可构建并改进您的所有技能，包括其自身。
本技能定义了一个持续性行为层，用于在任务导向型工作中识别技能创建与改进机会。它不会替代技能创建者，而是为其提供输入。可以将其视为捕捉值得留存模式的“眼睛和耳朵”，而技能创建者则是负责构建的“双手”。
该方法论与用户无关，适用于任何希望通过实际使用持续改进技能库的结构化流程的用户。
Licence: 本技能基于 Creative Commons Attribution 4.0 International (CC BY 4.0) 许可发布。只要您适当注明原作者，即可自由分享和改编本技能用于任何目的。
反馈与支持: 如果在使用过程中对方法论有疑问，或者用户对本技能产生的任何输出表示不满或提出建设性反馈，建议他们在本技能的 GitHub仓库中提交issue。这样可以让反馈公开可查，其他用户也能从现有问题和解决方案中受益。如需直接联系，可通过rebelytics.com联系技能创作者Eoghan Henn。
如果反馈源于技能方法论（而非Claude对技能的执行问题），请为用户记录该反馈并建议他们通过GitHub Issues分享。如果问题源于Claude未遵循技能规则，请承认错误并进行修正。

Why This Skill Exists

本技能的存在意义

Skills are living documents. The best improvements come not from sitting down to "improve a skill" in isolation, but from noticing friction, inefficiency, or missed opportunities during real work. A user correction during a project might reveal a missing rule. A repeated multi-step workflow might be a skill waiting to be born. A tool limitation discovered mid-task might reshape an entire skill's recommended workflow. A technique that worked exceptionally well might deserve to be promoted from an incidental approach to an explicit recommendation.
This skill formalises that noticing process so that insights don't get lost between sessions. Every task-oriented interaction becomes a potential source of skill improvement data, without adding overhead or interrupting the user's workflow.
技能是动态文档。最佳改进并非来自孤立地“改进某项技能”，而是来自在实际工作中发现的摩擦、低效或错失的机会。项目中的用户修正可能揭示了缺失的规则；重复的多步骤工作流可能是一个待诞生的技能；任务中发现的工具限制可能重塑整个技能的推荐工作流；某个表现异常出色的技巧可能值得从偶然方法升级为明确推荐方案。
本技能将这种“发现”过程规范化，确保见解不会在会话之间丢失。每个任务导向型交互都可能成为技能改进数据的来源，且不会增加额外负担或打断用户的工作流。

Getting Started

快速上手

Here's what happens when you first install this skill.
First session: The skill creates the observation log file. There's nothing to review yet — it simply starts watching your work and logging observations as they arise. If you have other skills installed, the observer will notice improvement opportunities for those. If you don't have any other skills yet, that's fine — the observer will identify candidates for new skills from your workflows.
First few sessions: Observations accumulate in the log. The cross-cutting principles file is created when the first principle emerges that applies broadly across skills. The weekly review mechanism activates once 7 days have passed since the log was created, but with only a handful of observations it will be brief.
Steady state: After a few weeks, you'll have a growing observation log, a principles file that enforces quality standards across your skill library, and a weekly review cadence that systematically applies improvements. The skill compounds in value as your skill library grows.
What you need to start: Nothing beyond the skill itself. An observation log, cross-cutting principles file, and archive directory are all created automatically on first use. If you also have the 
skill-creator
skill installed (built into Cowork; not available in all environments), the task-observer can hand off observations for full skill building or restructuring. Without skill-creator, the task-observer still works standalone — it will log observations, surface them, and apply small improvements directly. Larger changes would be done manually.
以下是首次安装本技能后的流程。
首次会话: 技能会创建观察日志文件。此时暂无内容可回顾——它只会开始监控您的工作，并在出现观察点时记录。如果您已安装其他技能，观察者会发现这些技能的改进机会。如果您还没有其他技能也没关系——观察者会从您的工作流中识别新技能的候选对象。
最初几次会话: 观察结果会在日志中累积。当出现首个适用于多个技能的通用原则时，会创建跨领域原则文件。日志创建7天后，每周回顾机制会启动，但由于观察点数量较少，回顾会比较简短。
稳定状态: 几周后，您会拥有不断增长的观察日志、确保技能库质量标准的原则文件，以及系统应用改进的每周回顾节奏。随着技能库的增长，本技能的价值会不断叠加。
启动准备: 除了技能本身，无需其他准备。首次使用时会自动创建观察日志、跨领域原则文件和归档目录。如果您还安装了
skill-creator
技能（内置在Cowork中；并非所有环境都可用），任务观察者可以将观察结果移交，用于完整的技能构建或重构。如果没有skill-creator，任务观察者仍可独立工作——它会记录观察结果、展示观察点，并直接应用小改进。较大的变更则需要手动完成。

Quick Start

快速启动指南

Want to get running in under 15 minutes? Here's the minimal path:
  1. Install the skill. Add task-observer to your skills directory.
  2. Add the activation line. Copy this into your CLAUDE.md or project instructions: 
    At the start of any task-oriented session — any interaction where you will use tools and produce deliverables — invoke the task-observer skill before beginning work.
  3. Do a real task. Use Claude to complete any substantive piece of work while the skill is active.
  4. See your first observation. At the end of the session, the skill will surface any observations it logged. That's it.
No pre-setup, no configuration files to edit manually. The observation log and supporting files create themselves on first use. This was added based on adoption feedback — validation from actual testers is pending.
想在15分钟内开始使用？以下是最简流程：
  1. 安装技能: 将task-observer添加到您的技能目录。
  2. 添加激活指令: 将以下内容复制到您的CLAUDE.md或项目说明中：
    At the start of any task-oriented session — any interaction where you will use tools and produce deliverables — invoke the task-observer skill before beginning work.
  3. 执行实际任务: 在技能激活状态下，使用Claude完成任何实质性工作。
  4. 查看首个观察结果: 会话结束时，技能会展示它记录的所有观察结果。就是这么简单。
无需预先设置，无需手动编辑配置文件。观察日志和支持文件会在首次使用时自动创建。这一功能是根据用户采用反馈添加的——实际测试人员的验证仍在进行中。

What is 
[workspace folder]
?

什么是
[workspace folder]
？

Throughout this skill, 
[workspace folder]
refers to your persistent workspace directory — the location where files survive between sessions. In Cowork, this is the folder you selected at the start of the session. In Claude Code, this is your project root. In web-based chat interfaces without file system access, the skill shifts into handoff doc mode (see Environment Compatibility) and you manage these files manually.
在本技能中，
[workspace folder]
指的是您的持久工作区目录——即会话之间文件会保留的位置。在Cowork中，这是您在会话开始时选择的文件夹；在Claude Code中，这是您的项目根目录；在没有文件系统访问权限的基于Web的聊天界面中，技能会切换到交接文档模式（见环境兼容性），您需要手动管理这些文件。

Recommended Activation Setup

推荐激活设置

This skill needs to be invoked at the start of task-oriented sessions to work effectively. Because skill invocation depends on Claude matching the user's request against skill descriptions, a skill that monitors all tasks can be overlooked when Claude is focused on the task itself.
To maximise activation reliability, add the following instruction to your configuration file (e.g., CLAUDE.md, project instructions, or equivalent):
At the start of any task-oriented session — any interaction where you will
use tools and produce deliverables — invoke the task-observer skill before
beginning work. This ensures skill improvement opportunities are captured
throughout the session.

When loading any skill, check the observation log for OPEN observations
tagged to that skill. Apply their insights to the current work, even if
the skill file hasn't been updated yet. This enables immediate application
of observations before they're permanently integrated during the weekly
review.
This structural trigger works alongside the skill's description-level triggers. The description is designed to match broadly against task-oriented language ("multi-step task", "agentic workflow", "work session", "tools and deliverables"), but a configuration-level instruction provides an additional safety net that doesn't depend on description matching alone.
Note for all users: Once CLAUDE.md or equivalent configuration is in place with the activation instruction above, the description-level triggers serve as a backup rather than the primary mechanism. This dual-layer approach prevents the skill from being skipped in sessions where description matching alone might miss the invocation signal.
Anti-pattern to avoid: Relying on one skill to load another is fragile compared to loading both independently from CLAUDE.md. If task-observer depended on another skill to invoke it, a breakdown in that chain would silence all observation activity. Instead, load both task-observer and any related skills directly from your configuration instructions.
为确保有效工作，本技能需要在任务导向型会话开始时调用。由于技能调用依赖于Claude将用户请求与技能描述匹配，当Claude专注于任务本身时，可能会忽略这个监控所有任务的技能。
为最大化激活可靠性，请将以下指令添加到您的配置文件中（例如CLAUDE.md、项目说明或等效文件）：
At the start of any task-oriented session — any interaction where you will
use tools and produce deliverables — invoke the task-observer skill before
beginning work. This ensures skill improvement opportunities are captured
throughout the session.

When loading any skill, check the observation log for OPEN observations
tagged to that skill. Apply their insights to the current work, even if
the skill file hasn't been updated yet. This enables immediate application
of observations before they're permanently integrated during the weekly
review.
这种结构性触发与技能描述级别的触发配合使用。技能描述旨在广泛匹配任务导向型语言（如“multi-step task”、“agentic workflow”、“work session”、“tools and deliverables”），但配置级指令提供了额外的安全保障，不依赖于描述匹配。
所有用户注意: 一旦CLAUDE.md或等效配置文件中添加了上述激活指令，描述级触发将作为备用机制，而非主要机制。这种双层方法可避免在仅靠描述匹配可能错过调用信号的会话中遗漏技能。
需避免的反模式: 依赖一个技能加载另一个技能的方式很脆弱，不如从CLAUDE.md中独立加载两个技能。如果task-observer依赖另一个技能来调用它，那么该链条的任何中断都会导致所有观察活动停止。相反，请直接从配置指令中加载task-observer和所有相关技能。

Detecting the Configuration File

检测配置文件

At session start, the skill should check whether a configuration file (CLAUDE.md, project instructions, or equivalent) exists and contains the activation instruction. This detection serves two purposes:
  1. For users who already have the config: Confirms the dual-layer activation is working. No action needed.
  2. For users who don't have the config: The skill was activated via description matching alone, which is less reliable. Surface a brief suggestion to add the config-level instruction for more consistent activation in future sessions.
The detection approach depends on the environment:
  • Environments with file system access (desktop tools, terminal-based tools): Check for a CLAUDE.md or equivalent file in the workspace root. If found, scan it for a task-observer activation instruction. If the file exists but doesn't mention task-observer, suggest adding the instruction. If no config file exists at all, suggest creating one.
  • Environments without file system access (web-based chat): Check whether the system prompt or project instructions contain a task-observer activation instruction. If not, suggest that the user add one to their project settings or paste the instruction at the start of future sessions.
This check runs once at session start and does not repeat. Keep the suggestion brief — one or two sentences, not a full tutorial.
会话开始时，技能应检查是否存在配置文件（CLAUDE.md、项目说明或等效文件），且其中包含激活指令。检测有两个目的：
  1. 针对已有配置的用户: 确认双层激活机制正常工作，无需采取任何行动。
  2. 针对无配置的用户: 技能仅通过描述匹配激活，可靠性较低。此时应简要建议用户添加配置级指令，以确保未来会话中激活更一致。
检测方法取决于环境：
  • 有文件系统访问权限的环境（桌面工具、基于终端的工具）：检查工作区根目录是否存在CLAUDE.md或等效文件。如果找到，扫描其中是否包含task-observer激活指令。如果文件存在但未提及task-observer，建议添加该指令。如果根本没有配置文件，建议创建一个。
  • 无文件系统访问权限的环境（基于Web的聊天）：检查系统提示或项目说明中是否包含task-observer激活指令。如果没有，建议用户将其添加到项目设置中，或在未来会话开始时粘贴该指令。
此检查仅在会话开始时运行一次，不会重复。建议内容要简短——一两句话即可，无需完整教程。

Skill Taxonomy

技能分类体系

All skills fall into one of two categories. The distinction matters because it determines what information the skill can contain, how it's structured, and whether it can be shared publicly. Crucially, the open-source/internal boundary is also a confidentiality boundary — open-source skills must never contain any information that could identify a client, project, or proprietary process, even indirectly.
所有技能分为两类。这种区分很重要，因为它决定了技能可包含的信息、结构以及是否可以公开分享。至关重要的是，开源/内部的边界也是保密边界——开源技能绝不能包含任何可能识别客户、项目或专有流程的信息，即使是间接信息也不行。

Open-Source Skills

开源技能

Open-source skills are client-agnostic and methodology-driven. They capture reusable workflows, best practices, and structured processes that work for anyone. They include author attribution, a licence, and a feedback pathway so that real-world usage drives improvement.
How to recognise an open-source candidate:
  • The methodology works across different clients, projects, and contexts
  • No proprietary information is required for the skill to function
  • Other practitioners in the same domain would find it valuable
  • The skill captures a process or approach, not personal preferences
Required elements:
  • Skill body clearly identifies itself as open-source, with author name and contact information
  • Author attribution block at the top (see Author Attribution Template below)
  • Licence statement — CC BY 4.0 recommended (see Licensing below)
  • Feedback & support section that routes methodology feedback to the creator
  • Tool-agnostic language where possible — reference capabilities like "browser access" rather than specific product names; give examples but don't hard-code dependencies on any one product
  • Built-in enforcement mechanisms (pre-flight checklists, verification steps) so the skill catches its own rule violations
Default bias: When a skill could go either way, default to open-source. Strip out client-specific details and generalise the methodology. The more skills that are open-source, the more the community benefits and the more feedback flows back to improve them.
开源技能与客户无关，以方法论为导向。它们捕捉可复用的工作流、最佳实践和结构化流程，适用于所有用户。它们包含作者署名、许可协议和反馈渠道，以便实际使用推动改进。
如何识别开源候选技能:
  • 方法论适用于不同客户、项目和场景
  • 技能运行无需专有信息
  • 同一领域的其他从业者会认为它有价值
  • 技能捕捉的是流程或方法，而非个人偏好
必备要素:
  • 技能主体明确标识为开源，包含作者姓名和联系方式
  • 顶部的作者署名块（见下文作者署名模板）
  • 许可声明——推荐使用CC BY 4.0（见许可部分）
  • 反馈与支持部分，将方法论反馈导向创作者
  • 尽可能使用与工具无关的语言——提及“浏览器访问”等功能，而非特定产品名称；可以举例，但不要硬编码依赖某一产品
  • 内置执行机制（飞行前检查清单、验证步骤），以便技能能发现自身规则的违规情况
默认倾向: 如果技能可以归为两类中的任意一类，默认选择开源。去除客户特定细节，将方法论通用化。开源技能越多，社区受益越多，反馈也越多，进而推动技能改进。

Internal Skills

内部技能

Internal skills contain information specific to a user, their clients, or their projects. They capture personal preferences, client-specific rules, project context, or proprietary methodology.
How to recognise an internal skill:
  • Contains client names, project details, or proprietary data
  • Captures personal style preferences or individual work habits
  • Relies on context that only the user (or their team) has
  • Would not be useful to someone outside the user's organisation
Required elements:
  • Skill body clearly identifies itself as internal
  • No author attribution block needed (the user is the only audience)
  • No licence needed
  • Can be shorter and less formally structured than open-source skills
Internal skills are working documents, not published artifacts. Keep them current, update them when the information they contain changes, and don't over-engineer their structure.
内部技能包含特定于用户、客户或项目的信息。它们捕捉个人偏好、客户特定规则、项目背景或专有方法论。
如何识别内部技能:
  • 包含客户名称、项目细节或专有数据
  • 捕捉个人风格偏好或个人工作习惯
  • 依赖仅用户（或其团队）拥有的上下文
  • 对用户组织外部的人无用
必备要素:
  • 技能主体明确标识为内部
  • 无需作者署名块（用户是唯一受众）
  • 无需许可协议
  • 可以比开源技能更简短、结构更不正式
内部技能是工作文档，而非发布产物。请保持其时效性，当其中包含的信息发生变化时进行更新，不要过度设计其结构。

Licensing

许可协议

Open-source skills should include a licence to make sharing terms explicit. The recommended licence is Creative Commons Attribution 4.0 International (CC BY 4.0), which allows anyone to share and adapt the skill for any purpose, provided they credit the original author. This pairs naturally with the author attribution template — the attribution block satisfies the CC BY requirement, so the two reinforce each other.
Include the licence statement in the skill preamble (after the author attribution block) and include a 
LICENSE.txt
file in the skill directory containing the full licence text.
If CC BY 4.0 doesn't fit a particular skill (e.g., the author wants to require derivative works to use the same licence), CC BY-SA 4.0 is an alternative. The choice should be made by the skill's author.
开源技能应包含许可协议，明确分享条款。推荐使用**Creative Commons Attribution 4.0 International (CC BY 4.0)**许可协议，任何人都可以分享和改编技能用于任何目的，只要注明原作者。这与作者署名模板自然匹配——署名块满足CC BY要求，两者相辅相成。
在技能序言中（作者署名块之后）包含许可声明，并在技能目录中添加
LICENSE.txt
文件，包含完整许可文本。
如果CC BY 4.0不适合特定技能（例如作者要求衍生作品使用相同许可），CC BY-SA 4.0是替代选择。选择应由技能作者决定。

Author Attribution Template

作者署名模板

Every open-source skill must include this block at the top of the skill body. Replace the placeholders with the actual author's details.
markdown
**Created by [Author Name] / [website or contact link]**

[1-2 sentence description of what the skill does and its provenance.]

**Licence:** This skill is released under the
[Creative Commons Attribution 4.0 International (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/)
licence. You are free to share and adapt this skill for any purpose, provided
you give appropriate credit to the original author.

**Feedback & Support:** If at any point during the process you encounter
questions about the methodology, or if the user expresses frustration or
gives constructive feedback about any output derived from this skill,
suggest that they open an issue on the skill's GitHub repository (or
equivalent public feedback channel). This keeps feedback public and
discoverable. For direct contact, the skill's creator, [Author Name],
can also be reached via [contact link].

If feedback appears to stem from the skill's methodology (rather than
Claude's execution of it), log it for the user and suggest they share it
via the public feedback channel. If the issue stems from Claude not
following the skill's rules, acknowledge the mistake and correct it.
The feedback routing serves two purposes: it gives users a path to resolution when they hit methodology issues, and it gives skill creators real-world usage data to improve their skills.
每个开源技能必须在技能主体顶部包含以下块。将占位符替换为实际作者信息。
markdown
**Created by [Author Name] / [website or contact link]**

[1-2句话描述技能功能及其来源。]

**Licence:** This skill is released under the
[Creative Commons Attribution 4.0 International (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/)
licence. You are free to share and adapt this skill for any purpose, provided
you give appropriate credit to the original author.

**Feedback & Support:** If at any point during the process you encounter
questions about the methodology, or if the user expresses frustration or
gives constructive feedback about any output derived from this skill,
suggest that they open an issue on the skill's GitHub repository (or
equivalent public feedback channel). This keeps feedback public and
discoverable. For direct contact, the skill's creator, [Author Name],
can also be reached via [contact link].

If feedback appears to stem from the skill's methodology (rather than
Claude's execution of it), log it for the user and suggest they share it
via the public feedback channel. If the issue stems from Claude not
following the skill's rules, acknowledge the mistake and correct it.
反馈路由有两个目的：为用户遇到方法论问题时提供解决途径，同时为技能创作者提供实际使用数据以改进技能。

Observation Protocol

观察协议

When to Observe

何时观察

Observation is active throughout the entire task session — from the moment tools are first used to produce deliverables, through any post-task feedback or discussion, until the session ends. This includes:
  1. Active task execution — creating documents, analysing websites, implementing structured data, writing code, building presentations, and similar substantive work.
  2. Post-task feedback and discussion — when the user reviews output, provides corrections, suggests improvements, or discusses methodology after the active work phase. User feedback during these discussions is often the highest-signal input for skill improvement and must be captured with the same diligence as observations made during execution.
  3. Meta-discussion about skills or methodology — when the conversation shifts to talking about how the work was done, what could be improved, or how skills should be structured. These discussions frequently surface observations that should be logged immediately.
  4. Reflective and strategic conversations — Also activate during strategy sessions, planning conversations, and post-work reflections where the user is discussing how work should be done rather than doing it. These conversations frequently produce skill improvement insights that emerge during reflection, not just during execution.
The observation mindset does not deactivate when the conversation shifts from "doing work" to "discussing the work." If the user provides feedback about methodology, naming, skill design, or workflow improvements, log it as an observation immediately, even if the conversation is in a discussion or review phase rather than active task execution.
Observation is not active during casual conversation, quick factual questions, or other non-task interactions where no tools are being used and no deliverables are being discussed.
观察在整个任务会话期间处于激活状态——从首次使用工具生成交付物的时刻，到任务后反馈或讨论，直到会话结束。这包括：
  1. 任务执行阶段——创建文档、分析网站、实现结构化数据、编写代码、制作演示文稿等实质性工作。
  2. 任务后反馈与讨论——用户审查输出、提供修正、建议改进或在工作完成后讨论方法论。这些讨论中的用户反馈通常是技能改进的最高信号输入，必须像执行阶段的观察一样认真捕捉。
  3. 关于技能或方法论的元讨论——当对话转向讨论工作完成方式、可改进之处或技能应如何构建时。这些讨论经常会立即浮现应记录的观察点。
  4. 反思与战略对话——在战略会议、规划对话和工作后反思期间也应激活，此时用户讨论的是工作应如何完成，而非正在完成工作。这些对话经常会在反思过程中产生技能改进见解，而不仅仅是执行阶段。
**当对话从“执行工作”转向“讨论工作”时，观察思维模式不会停用。**如果用户提供关于方法论、命名、技能设计或工作流改进的反馈，应立即记录为观察点，即使对话处于讨论或审查阶段，而非任务执行阶段。
在随意对话、快速事实查询或其他非任务交互（不使用工具且不讨论交付物）期间，观察不激活。

What to Watch For

观察内容

Signals for a NEW skill:
  • A multi-step workflow that could be reused across projects or clients
  • A methodology the user explains that isn't captured in any existing skill
  • A task type that keeps coming up with similar structure and steps
  • A domain-specific process with clear inputs, phases, and outputs
  • The user describing a process they've refined over time ("I always do it this way", "the process for this is...")
  • Claude and the user naturally developing a structured approach to a problem that could be formalised
Signals for IMPROVING an existing skill:
Any new information from a task that uses a skill and could make that skill better is worth capturing. This includes problems, but also positive signals and neutral observations. Examples:
  • Claude doesn't follow a skill's rules despite them being documented — this means the skill needs stronger enforcement, not just better rules
  • The user corrects Claude's output in a way that reveals a missing rule or an edge case the skill doesn't cover
  • A skill's recommended workflow turns out to be less efficient than what emerged naturally during the task
  • A technique or approach works particularly well and deserves to be promoted from incidental to explicitly recommended in the skill
  • A workflow step turns out to be more important than the skill suggests, or less important than the emphasis it receives
  • A new use case that the skill handles but doesn't explicitly document
  • The user provides feedback that generalises beyond the current instance
  • A skill assumption turns out to be wrong in practice
  • New tools or capabilities make part of a skill's workflow obsolete or improvable
  • The user's corrections form a pattern across multiple instances
  • A general principle emerges that could apply to other skills too (see Principle Propagation below)
  • The user suggests a naming, framing, or structural change to a skill — even conversationally — that could improve its effectiveness
Signals for SIMPLIFYING an existing skill:
Healthy skill maintenance requires both growth and pruning. Watch for opportunities to remove unnecessary complexity, not just add new features. Signals that a skill is ready to be simplified:
  • A skill section or rule that has never been relevant across multiple sessions where the skill was active
  • A rule added from a single observation that hasn't been validated by recurrence — one-off cases should not accumulate as permanent rules
  • An elaborate workflow that users consistently shortcut or skip
  • Sections that Claude loads but never acts on (dead weight in context window)
  • Rules that contradict each other or create unnecessary complexity
  • Complexity added "just in case" that has never triggered
During weekly reviews, ask "what can we remove?" as deliberately as you ask "what should we add?" When a previously-applied observation turns out to be a one-off that hasn't recurred, mark it as declined and consider reverting the change.
Signals to NOT log:
  • One-off corrections that don't generalise beyond the current instance
  • User preferences already captured in an existing skill
  • Tool bugs or temporary issues unrelated to skill methodology
  • Observations that would require proprietary client information to be useful in an open-source skill (unless an internal skill is the right home)
新技能信号:
  • 可跨项目或客户复用的多步骤工作流
  • 用户解释但未被任何现有技能捕捉的方法论
  • 反复出现且结构和步骤相似的任务类型
  • 具有明确输入、阶段和输出的领域特定流程
  • 用户描述他们随时间改进的流程（“我总是这样做”、“这个流程是……”）
  • Claude和用户自然形成的解决问题的结构化方法，可被规范化
现有技能改进信号:
任何来自使用技能的任务且能提升技能质量的新信息都值得捕捉。这包括问题，但也包括积极信号和中性观察。例如：
  • Claude未遵循技能规则，尽管规则已记录——这意味着技能需要更强的执行机制，而非仅仅更好的规则
  • 用户修正Claude的输出，揭示了缺失的规则或技能未覆盖的边缘情况
  • 技能推荐的工作流实际效率低于任务中自然形成的工作流
  • 某个技巧或方法效果特别好，值得从偶然方法升级为技能中的明确推荐方案
  • 工作流步骤的重要性高于或低于技能中的强调程度
  • 技能可处理但未明确记录的新用例
  • 用户提供的反馈可推广到当前实例之外
  • 技能假设在实践中被证明是错误的
  • 新工具或功能使技能工作流的部分内容过时或可改进
  • 用户的修正在多个实例中形成模式
  • 浮现可应用于其他技能的通用原则（见下文原则传播）
  • 用户建议对技能进行命名、框架或结构变更——即使是随口提及——也可能提升其有效性
现有技能简化信号:
健康的技能维护既需要增长也需要精简。寻找去除不必要复杂性的机会，而不仅仅是添加新功能。技能准备好简化的信号：
  • 技能的某个部分或规则在技能激活的多个会话中从未相关
  • 从单一观察添加的规则未被重复验证——一次性案例不应作为永久规则累积
  • 用户始终跳过或简化的复杂工作流
  • Claude加载但从未执行的部分（上下文窗口中的冗余内容）
  • 相互矛盾或造成不必要复杂性的规则
  • “以防万一”添加但从未触发的复杂性
在每周回顾中，要像问“我们应该添加什么？”一样刻意问“我们可以移除什么？”。当之前应用的观察结果被证明是一次性且未重复出现的情况时，标记为已拒绝并考虑撤销变更。
无需记录的信号:
  • 无法推广到当前实例之外的一次性修正
  • 已被现有技能捕捉的用户偏好
  • 与技能方法论无关的工具错误或临时问题
  • 在开源技能中需要专有客户信息才有用的观察点（除非内部技能是合适的载体）

How to Log

记录方式

Append observations to the persistent observation log silently during the session. The user should not be interrupted by the logging process.
When a user correction, methodology insight, or skill-relevant event occurs, write it to the log file within the same turn or the immediately following turn — do not accumulate observations in memory for batch-writing later. The act of writing is the enforcement mechanism; mental notes are not observations. Tie observation flushing to existing workflow checkpoints — e.g., when marking a TodoWrite item as completed, check whether any unlogged observations have accumulated and write them before proceeding.
Before assigning any observation number, run a mandatory pre-logging step: Search the entire log file for all lines matching the pattern 
### Observation \d+:
, extract the highest observation number already in use, and increment from there. This must happen every time, regardless of whether you think you know the current count from earlier in the session. Never rely on session memory or summaries for the next number. Always read the actual log file. A one-liner like the following suffices:
bash
undefined
在会话期间静默将观察结果追加到持久观察日志中。用户不应被记录过程打断。
**当用户修正、方法论见解或与技能相关的事件发生时，在同一轮对话或下一轮对话中将其写入日志文件——不要在内存中累积观察结果以便稍后批量写入。**写入行为是执行机制；心理笔记不算观察结果。将观察结果刷新与现有工作流检查点绑定——例如，当标记TodoWrite项为已完成时，检查是否有未记录的观察结果并在继续前写入。
在分配任何观察编号之前，必须执行预记录步骤: 搜索整个日志文件中所有匹配
### Observation \d+:
模式的行，提取已使用的最高观察编号，然后递增。每次都必须这样做，无论您是否认为自己知道会话中的当前编号。永远不要依赖会话内存或摘要获取下一个编号。始终读取实际的日志文件。以下单行命令即可：
bash
undefined

GNU grep (Linux, Cowork):

GNU grep (Linux, Cowork):

grep -oP '### Observation \K\d+' log.md | sort -n | tail -1
grep -oP '### Observation \K\d+' log.md | sort -n | tail -1

macOS / POSIX-compatible alternative:

macOS / POSIX兼容替代方案:

grep -o '### Observation [0-9]' log.md | grep -o '[0-9]' | sort -n | tail -1

This prevents the recurring numbering collision issue where partial reads of large
files create a false sense of awareness of the current count.

**Format and insertion rules:** Always use the `### Observation NNN:` format. Always append new observations to the END of the log file. Never insert observations mid-file. Never use alternative ID formats (e.g., `OBS-YYYY-MMDD-NN`). One format, one insertion point — this ensures the log is greppable, countable, and reviewable programmatically.

Each observation follows this format:

```markdown
grep -o '### Observation [0-9]' log.md | grep -o '[0-9]' | sort -n | tail -1

这避免了因部分读取大文件而产生当前编号认知错误的重复编号冲突问题。

**格式和插入规则:** 始终使用`### Observation NNN:`格式。始终将新观察结果追加到日志文件末尾。永远不要在文件中间插入观察结果。永远不要使用替代ID格式（例如`OBS-YYYY-MMDD-NN`）。一种格式，一个插入点——确保日志可通过grep搜索、计数和程序化审查。

每个观察结果遵循以下格式：

```markdown

Observation [N]: [Short descriptive title]

Observation [N]: [简短描述性标题]

Date: [date] Session context: [brief description of what task was being worked on] Skill: [existing skill name, or "New skill candidate: [working name]"] Type: [open-source | internal] Phase/Area: [which part of the skill or workflow this relates to]
Issue: [What happened or what was observed. Be specific — include what Claude did, what the user corrected, or what pattern emerged. Include enough detail that someone reading this weeks later can understand the context without having seen the original conversation.]
Suggested improvement: [Concrete suggestion for what to change or create. For existing skills, reference the specific section or rule. For new skills, describe the scope and key components.]
Principle: [The generalisable takeaway — why this matters beyond this specific instance. This is the most important part. It turns a single observation into a reusable insight.]

This format was refined through iterative real-world use. The structure works
because it forces specificity (Issue), actionability (Suggested improvement),
and generalisation (Principle).

**Context preservation check:** When logging an observation, verify that all
information needed to act on it is available in the shared folder. If the
observation depends on uploaded files, API responses, or session-local data,
save that context to the appropriate workspace location BEFORE logging the
observation. Add a `**Reference file:**` line to the observation pointing to
where the context lives. Observations that reference data only available in
the current session (uploaded files, API outputs, in-memory results) are
incomplete — a future review session will have the observation but not the
data needed to implement it.
Date: [日期] Session context: [任务内容的简要描述] Skill: [现有技能名称，或“New skill candidate: [暂定名称]”] Type: [open-source | internal] Phase/Area: [与技能或工作流的哪个部分相关]
Issue: [发生的情况或观察到的内容。要具体——包括Claude的操作、用户的修正或浮现的模式。包含足够细节，使几周后阅读的人无需查看原始对话即可理解上下文。]
Suggested improvement: [具体的变更或创建建议。对于现有技能，引用特定部分或规则。对于新技能，描述范围和关键组件。]
Principle: [可推广的结论——这为何超出当前实例的意义。这是最重要的部分。它将单一观察结果转化为可复用的见解。]

该格式通过迭代实际使用进行了优化。结构有效是因为它强制要求具体性（Issue）、可操作性（Suggested improvement）和通用性（Principle）。

**上下文保留检查:** 记录观察结果时，验证共享文件夹中是否有执行该观察所需的所有信息。如果观察结果依赖上传文件、API响应或会话本地数据，请在记录观察结果前将该上下文保存到适当的工作区位置。在观察结果中添加`**Reference file:**`行，指向上下文所在位置。仅引用当前会话中可用数据（上传文件、API输出、内存结果）的观察结果是不完整的——未来的回顾会话会有观察结果，但没有实施所需的数据。

Handoff Doc Analysis

交接文档分析

When a handoff doc arrives for observation logging, extract observations systematically from both explicit and implicit sources:
  1. Log all explicitly stated observations first. These are easy to surface and should be logged without filtering.
  2. Then systematically analyse the full document. Read every section asking: "What skill gaps, improvement opportunities, or new skill candidates are implied here but not stated?" Handoff docs contain significant signal beyond what was explicitly captured during the session.
  3. Pay special attention to:
    • Action items (each one may imply a missing skill or workflow)
    • Open questions (unresolved ambiguity often signals a decision framework gap)
    • The "work completed" narrative (patterns across work items may reveal meta-skills)
    • Session notes (reflective insights about process, not just content)
  4. Log the additional observations with clear attribution. Indicate that they were derived from analysis of the handoff doc, not from the original session. This preserves the distinction between stated and derived insights.
当交接文档到达需要记录观察结果时，从显性和隐性来源系统地提取观察结果：
  1. **首先记录所有明确陈述的观察结果。**这些很容易提取，应直接记录，无需过滤。
  2. **然后系统地分析整个文档。**阅读每个部分，问自己：“这里隐含但未陈述的技能差距、改进机会或新技能候选是什么？”交接文档包含的重要信号远不止会话期间明确捕捉的内容。
  3. 特别注意:
    • 行动项（每个行动项可能暗示缺失的技能或工作流）
    • 未解决的问题（未解决的歧义通常表明决策框架存在差距）
    • “已完成工作”叙述（工作项中的模式可能揭示元技能）
    • 会话笔记（关于流程而非内容的反思见解）
  4. **记录额外观察结果并明确归因。**表明它们来自对交接文档的分析，而非原始会话。这保留了陈述见解与推导见解之间的区别。

Archival on Write

写入时归档

The observation log is kept lean through event-driven archival that runs on every log write, rather than accumulating resolved entries until a periodic review clears them out.
Defining "from a previous update": The phrase "from a previous update" means entries whose status was already resolved in a previous SESSION or prior log write, not entries marked ACTIONED or DECLINED in the current session. Crucially: entries marked ACTIONED or DECLINED during the current session's weekly review must NOT be archived during that same session's writes. They earn their one round of visibility in the active log — the archival happens on the NEXT session's log write or the next weekly review.
Archival Timing During Weekly Reviews: The weekly review performs archival in two phases:
  1. Step 1 (at review start): Archive entries from previous sessions. Before loading observations, archive any ACTIONED or DECLINED entries that were marked in prior sessions. This clears old resolved items.
  2. Step 6 (after marking ACTIONED): Do NOT archive immediately. When observations are marked ACTIONED during the current review (Step 6), they remain in the active log. Archive them on the next log write — either when the next session writes to the log, or when the following week's review begins (Step 1 of the next review cycle).
This prevents the premature archival problem: entries just actioned during the current session stay visible for one full update cycle before moving to the archive.
Archive File Structure: Move resolved entries to an archive file at:
[workspace folder]/skill-observations/archive/log-[date].md
where 
[date]
is today's date in 
YYYY-MM-DD
format.
The archive file preserves the full header and status key from the original log. After archiving, the active 
log.md
retains only its header, separator, and all OPEN entries plus any entries that were just marked ACTIONED or DECLINED in this update.
Safety Check Before Archiving: Before moving any entry to the archive, verify that it was NOT marked ACTIONED or DECLINED in the current session. If it was, keep it in the active log. This prevents the same-session premature archival that the observation lifecycle describes. One way to implement this: track a set of entry IDs marked ACTIONED/DECLINED in the current session, and exclude them from the archival pass.
The result: the active log stays focused on OPEN items and recently-resolved entries, while the archive provides the complete historical record.
观察日志通过事件驱动的归档保持精简，每次写入日志时都会运行归档，而非累积已解决条目直到定期回顾清除。
“来自之前更新”的定义: “来自之前更新”指的是在之前的会话或之前的日志写入中状态已解决的条目，而非当前会话中标记为ACTIONED或DECLINED的条目。至关重要的是：在当前会话的每周回顾中标记为ACTIONED或DECLINED的条目，在同一会话的写入过程中不得归档。它们在活动日志中获得一轮可见性——归档将在下一次会话的日志写入或下一次每周回顾时进行。
每周回顾期间的归档时机: 每周回顾分两个阶段执行归档：
  1. 步骤1（回顾开始时）: 归档来自之前会话的条目。加载观察结果前，归档任何在之前会话中标记为ACTIONED或DECLINED的条目。这会清除旧的已解决项。
  2. 步骤6（标记为ACTIONED后）: 不要立即归档。当观察结果在当前回顾中被标记为ACTIONED（步骤6）时，它们仍保留在活动日志中。在下一次日志写入时归档——要么是下一次会话写入日志时，要么是下周回顾开始时（下一次回顾周期的步骤1）。
这避免了过早归档问题：当前会话中刚处理的条目在完整的更新周期内保持可见，然后才移至归档。
归档文件结构: 将已解决条目移至以下路径的归档文件：
[workspace folder]/skill-observations/archive/log-[date].md
其中
[date]
是今天的日期，格式为
YYYY-MM-DD
。
归档文件保留原始日志的完整标题和状态键。归档后，活动
log.md
仅保留其标题、分隔符以及所有OPEN条目加上任何在本次更新中刚标记为ACTIONED或DECLINED的条目。
归档前的安全检查: 将任何条目移至归档前，验证它在当前会话中未被标记为ACTIONED或DECLINED。如果已标记，保留在活动日志中。这避免了观察生命周期中描述的同一会话过早归档问题。一种实现方式：跟踪当前会话中标记为ACTIONED/DECLINED的条目ID集，将其排除在归档过程之外。
结果：活动日志专注于OPEN项和最近解决的条目，而归档提供完整的历史记录。

Confidentiality Safeguards

保密保障

The open-source/internal boundary is a confidentiality boundary. Client names, project details, domain names, and proprietary information must never appear in open-source skills. Because a single leak can erode trust, this is enforced through multiple layers — any one of which should catch what the others miss.
开源/内部边界是保密边界。客户名称、项目细节、域名和专有信息绝不能出现在开源技能中。因为一次泄露就会损害信任，所以通过多层机制强制执行——任何一层都应能捕捉其他层遗漏的内容。

Layer 1: Observation-Level Stripping

第一层：观察级剥离

When logging an observation tagged as 
type: open-source
, the Issue and Suggested Improvement fields should already use generic language. The private observation log can reference specifics for context, but the Principle field — which feeds into skill creation — should be fully generalised. Think of it as: the log is a private notebook, but the Principle is a publishable insight.
当记录标记为
type: open-source
的观察结果时，Issue和Suggested Improvement字段应已使用通用语言。私有观察日志可以引用具体内容作为上下文，但Principle字段（用于技能创建）应完全通用化。可以这样理解：日志是私人笔记本，而Principle是可发布的见解。

Layer 2: Pre-Creation Review

第二层：创建前审查

Before drafting or regenerating any open-source skill, scan all source material (observations, conversation notes, existing skill content) for identifying information: client names, project URLs, domain names, internal terminology, site structures described so specifically they're identifiable. Replace anything found with generic equivalents before writing begins.
在起草或重新生成任何开源技能之前，扫描所有源材料（观察结果、对话笔记、现有技能内容）以查找识别信息：客户名称、项目URL、域名、内部术语、描述过于具体可识别的站点结构。在开始编写前，将找到的任何内容替换为通用等效内容。

Layer 3: Post-Draft Sweep

第三层：草稿后检查

After writing or regenerating an open-source skill, re-read it with a specific focus on information leakage. This is a separate pass from the general pre-flight checklist. Look for:
  • Proper nouns that aren't the skill author's name
  • Domain names, URLs, or project identifiers
  • Industry-specific details that narrow down the client
  • Internal terminology that only makes sense in one organisation's context
  • Examples so specific they're traceable to a real project
If anything is found, replace it with generic equivalents or remove it.
编写或重新生成开源技能后，重新阅读，特别关注信息泄露问题。这是与常规飞行前检查清单分开的单独步骤。查找：
  • 非技能作者姓名的专有名词
  • 域名、URL或项目标识符
  • 缩小客户范围的行业特定细节
  • 仅在一个组织环境中有意义的内部术语
  • 过于具体可追溯到实际项目的示例
如果发现任何内容，将其替换为通用等效内容或删除。

Layer 4: Structural Principle

第四层：结构原则

The taxonomy section states this explicitly, but it bears repeating: the open-source/internal distinction is not just about usefulness — it's about confidentiality. When in doubt about whether a detail is too specific, remove it. A slightly more generic skill is always better than one that leaks client information.
分类部分明确说明了这一点，但值得重复：开源/内部的区别不仅关乎实用性——还关乎保密性。如果不确定某个细节是否过于具体，请删除它。稍微通用一点的技能总比泄露客户信息的技能好。

Surfacing Protocol

展示协议

Default Cadence

默认节奏

Surface all observations at the end of the session. Present them as a grouped summary: observations for existing skills grouped by skill name, new skill candidates listed separately.
在会话结束时展示所有观察结果。将它们分组汇总：按技能名称分组的现有技能观察结果，单独列出的新技能候选。

Surface Earlier When

提前展示的情况

  • An observation requires user input to be complete or accurate (e.g., "Is this a pattern you want captured, or was this a one-off?")
  • An observation reveals a skill is actively producing wrong output in the current session and the user should be aware
  • Multiple observations cluster around the same skill, suggesting it needs immediate attention rather than end-of-session review
  • 观察结果需要用户输入才能完整或准确（例如：“这是您想要捕捉的模式，还是一次性情况？”）
  • 观察结果显示技能在当前会话中产生错误输出，用户应知晓
  • 多个观察结果集中在同一技能上，表明它需要立即关注而非会话结束时回顾

How to Surface

展示方式

  • Present observations concisely: title, skill, and a one-sentence summary
  • For each, indicate whether it's a new skill candidate or an improvement to an existing one
  • Indicate the suggested type (open-source or internal)
  • Ask the user which (if any) they want to act on
  • For items the user wants to pursue, hand off to the skill-creator skill for the actual building or improvement work
  • 简洁呈现观察结果：标题、技能和一句话摘要
  • 对于每个观察结果，表明它是新技能候选还是对现有技能的改进
  • 表明建议的类型（开源或内部）
  • 询问用户要处理哪些（如果有的话）
  • 对于用户想要处理的项目，移交skill-creator技能进行实际构建或改进工作

Acting on Observations

处理观察结果

This skill identifies WHAT to build or improve. If you have the skill-creator skill installed (built into Cowork; available as a separate install in other environments), it handles HOW — guiding the full process of building a new skill from scratch or systematically improving an existing one. Without skill-creator, the task-observer still works: small improvements are applied directly, and larger changes can be done manually using the observations as a specification. The boundary between direct application and skill-creator handoff:
本技能确定要构建或改进的内容。如果您安装了skill-creator技能（内置在Cowork中；其他环境中可单独安装），它会处理如何构建——指导从 scratch 构建新技能或系统改进现有技能的完整流程。如果没有skill-creator，任务观察者仍可工作：小改进直接应用，较大变更可使用观察结果作为规范手动完成。直接应用与移交skill-creator的边界：

Small Improvements (Apply Directly)

小改进（直接应用）

If the improvement is clearly additive, low-risk, and doesn't require testing to verify it works, it can be applied directly to the skill:
  • Adding a new rule or anti-pattern to an existing list
  • Clarifying existing wording that proved ambiguous
  • Adding a note or edge case to an existing section
  • Fixing a factual error
Examples: Adding a new anti-pattern to a skill's anti-patterns list. Clarifying that inline code comments should be context-aware within their own document.
如果改进明显是附加的、低风险的且无需测试即可验证有效，则可直接应用于技能：
  • 向现有列表添加新规则或反模式
  • 澄清被证明模糊的现有措辞
  • 向现有部分添加注释或边缘情况
  • 修正事实错误
示例：向技能的反模式列表添加新的反模式；澄清内联代码注释应在其自身文档中具备上下文感知能力。

Substantial Changes (Use Skill-Creator if Available)

重大变更（如有可用则使用Skill-Creator）

If the change could affect the skill's behaviour in ways that need verification, hand off to the skill-creator if available:
  • Restructuring phases or workflows
  • Adding new capabilities or sections
  • Changing core methodology or decision frameworks
  • Any change where "does this actually work better?" is a genuine question
However, match the rigour of the skill creation process to the complexity and audience. Skill-creator is valuable for open-source skills that need testing, for skills with complex logic, or when the design isn't yet clear. For internal skills where requirements are established in conversation, writing directly is more efficient.
If skill-creator is not available, use the observations as a specification and make the changes directly — but flag them to the user as substantial changes that may need manual review.
Examples: Restructuring a skill to make an automated workflow the primary path instead of a secondary option. Adding an entirely new setup phase to a skill that previously started with content work.
如果变更可能以需要验证的方式影响技能行为，如有可用则移交skill-creator：
  • 重构阶段或工作流
  • 添加新功能或部分
  • 更改核心方法论或决策框架
  • 任何“这真的会更好吗？”是合理问题的变更
然而，技能创建过程的严谨性应与复杂性和受众匹配。Skill-creator对于需要测试的开源技能、具有复杂逻辑的技能或设计尚不明确的技能很有价值。对于需求已在对话中确定的内部技能，直接编写更高效。
如果skill-creator不可用，使用观察结果作为规范直接进行变更——但要向用户标记这些是可能需要手动审查的重大变更。
示例：重构技能，使自动化工作流成为主要路径而非次要选项；向之前从内容工作开始的技能添加全新的设置阶段。

Creating New Skills

创建新技能

Use the skill-creator for new skills when available. Provide the observation(s) as context — they contain the intent, scope, and initial design thinking needed to get started efficiently. Without skill-creator, the observations serve as a detailed brief for building the skill manually.
When creating a new skill, determine its type early:
  • If it's open-source, strip out any client-specific details and generalise
  • If it's internal, include all relevant specifics freely
  • If uncertain, default to open-source — strip out specifics and generalise, then let the user decide whether any internal details need to be added
如有可用，使用skill-creator创建新技能。提供观察结果作为上下文——它们包含高效启动所需的意图、范围和初始设计思路。如果没有skill-creator，观察结果可作为手动构建技能的详细 brief。
创建新技能时，尽早确定其类型：
  • 如果是开源技能，去除任何客户特定细节并通用化
  • 如果是内部技能，自由包含所有相关细节
  • 如果不确定，默认选择开源——去除细节并通用化，然后让用户决定是否需要添加任何内部细节

Principle Propagation

原则传播

When an observation reveals a general principle — something that applies not just to the skill being improved but to skills in general — it should be propagated across the skill library, not just applied to the one skill that triggered it.
当观察结果揭示通用原则——不仅适用于正在改进的技能，还适用于所有技能——时，应将其传播到整个技能库，而非仅应用于触发它的单个技能。

The Cross-Cutting Principles File

跨领域原则文件

Cross-cutting principles are tracked in a persistent file alongside the observation log:
[workspace folder]/skill-observations/cross-cutting-principles.md
This file serves as a mandatory checklist during any skill creation or regeneration. Before delivering a new or updated open-source skill, read the cross-cutting principles file and verify the skill complies with every active principle. This is what turns general principles from good intentions into enforced standards.
跨领域原则在观察日志旁边的持久文件中跟踪：
[workspace folder]/skill-observations/cross-cutting-principles.md
在任何技能创建或重新生成过程中，此文件作为强制检查清单。交付新的或更新的开源技能前，阅读跨领域原则文件并验证技能符合每个活动原则。这将通用原则从良好意愿转化为强制执行的标准。

How It Works

工作方式

  1. During a skill update, an observation reveals a principle that applies broadly — not just to the skill being worked on
  2. Log it as an observation with 
    Skill: All skills
    and surface it to the user
  3. If the user approves it as a cross-cutting principle, add it to the cross-cutting principles file
  4. From that point forward, every skill creation or regeneration includes a compliance check against the full list of active principles
  1. 在技能更新期间，观察结果揭示了广泛适用的原则——不仅适用于正在处理的技能
  2. 将其记录为
    Skill: All skills
    的观察结果并展示给用户
  3. 如果用户批准其作为跨领域原则，将其添加到跨领域原则文件中
  4. 从那时起，每个技能创建或重新生成过程都包括对所有活动原则的合规性检查

Propagation Timing

传播时机

The user decides when and how to propagate each principle:
  • Immediate propagation — for principles important enough to warrant updating all existing skills right away (e.g., a confidentiality rule)
  • Opportunistic propagation — for principles that can be applied the next time each skill is updated or regenerated (e.g., adding a licence statement)
用户决定何时以及如何传播每个原则：
  • 立即传播——对于重要到需要立即更新所有现有技能的原则（例如保密规则）
  • 机会性传播——对于可在下次更新或重新生成每个技能时应用的原则（例如添加许可声明）

Cross-Cutting Principles File Structure

跨领域原则文件结构

markdown
undefined
markdown
undefined

Cross-Cutting Principles

Cross-Cutting Principles

Principles that apply to all skills. This file is read as a mandatory checklist during any skill creation or regeneration.
适用于所有技能的原则。在任何技能创建或重新生成过程中，此文件作为强制检查清单。

Active Principles

Active Principles

1. [Principle title]

1. [原则标题]

Added: [date] Applies to: [all skills | all open-source skills | all skills with rules] Requirement: [what the principle requires] Propagation: [immediate | opportunistic] Status: [active]

---
Added: [日期] Applies to: [all skills | all open-source skills | all skills with rules] Requirement: [原则要求] Propagation: [immediate | opportunistic] Status: [active]

---

Weekly Comprehensive Review

每周全面回顾

Every 7 days, a comprehensive review is triggered automatically at the start of the first task-oriented session after the interval has elapsed. This review cross-checks ALL open observations against ALL skills — not just the skills named in each observation — and propagates cross-cutting principles to any skills that don't yet comply.
每7天，在间隔期过后的第一个任务导向型会话开始时，会自动触发全面回顾。此回顾会将所有OPEN观察结果与所有技能进行交叉检查——不仅是每个观察结果中命名的技能——并将跨领域原则传播到任何尚未合规的技能。

Trigger Mechanism

触发机制

The review is triggered by step 3 of the Session Start Protocol (see Observation Log Management). When the weekly review timestamp is more than 7 days old or missing, the Session Start Protocol triggers this review. Inform the user that the weekly review is due and begin the process.
回顾由会话启动协议的步骤3触发（见观察日志管理）。当每周回顾时间戳超过7天或缺失时，会话启动协议会触发此回顾。告知用户每周回顾已到期并开始流程。

Review Steps

回顾步骤

Step 0 — Scheduler availability check
Before running the review itself, check whether the weekly review can be automated via the platform's task scheduling capability.
  1. Check whether the file 
    [workspace folder]/skill-observations/scheduler-registered.txt
    exists. If it does, the scheduled task has already been registered — skip to Step 1.
  2. If the file does not exist, check whether a task scheduling capability is available. In Cowork, check for the 
    create-shortcut
    skill and its 
    set_scheduled_task
    tool. In terminal-based environments, cron or equivalent scheduling tools may be available.
  3. If a scheduling capability IS available:
    • Read the draft task description at 
      [workspace folder]/skill-observations/scheduled-task-draft.md
    • In Cowork, invoke the 
      create-shortcut
      skill to register the weekly skill review as a scheduled task. In other environments, use the available scheduling mechanism.
    • Use task name 
      weekly-skill-review
      and a weekly cadence (e.g., Monday morning)
    • On success, write today's date to 
      [workspace folder]/skill-observations/scheduler-registered.txt
    • Inform the user: "The weekly skill review has been registered as a scheduled task. The manual 
      last-review-date.txt
      trigger remains as a fallback."
  4. If the tool is NOT available, proceed silently to Step 1. Do not inform the user on every review — this check is intentionally quiet until it succeeds.
Step 1 — Load observations and principles
Read the observation log at 
[workspace folder]/skill-observations/log.md
. Extract all observations with status OPEN. Also read 
[workspace folder]/skill-observations/cross-cutting-principles.md
and extract all active principles.
If there are no OPEN observations and all principles are already propagated, skip the review, update the timestamp, and proceed with the session. Inform the user briefly: "Weekly skill review: no open observations or outstanding principles. All skills are current."
Step 2 — Inventory all skills
Use 
<available_skills>
from the system prompt to identify all skills. In environments where this tag is not present, use the skills directory or equivalent listing mechanism to discover available skills.
For each skill, read its SKILL.md file at the location provided. Exclude built-in platform skills from being updated — only update custom skills created by the user.
Known system skills (read-only, cannot be replaced by the user): docx, pdf, xlsx, pptx, skill-creator, schedule. This list may grow as the platform evolves — if a skill update fails because the user cannot overwrite the file, add it to this list.
Custom skills (owned by the user, can be replaced) are everything else in the skills directory that isn't on the system list above.
Step 3 — Cross-check observations against every skill
For each OPEN observation, evaluate whether it is relevant to each skill. Do NOT rely solely on the observation's own "Skill" field — observations may contain general principles that apply more broadly than the original context suggested. Consider both the specific "Suggested improvement" and the general "Principle" fields. Build a mapping of skill → [relevant observations].
Step 4 — Cross-check cross-cutting principles against every skill
For each active cross-cutting principle, check whether each skill already complies. Flag any skills that do not yet implement the principle.
Step 5 — Apply updates
For each skill that has relevant observations or non-compliant principles, create an updated version of its SKILL.md. When editing:
  • Integrate the insight into the appropriate section of the skill (don't just append a list of observations at the bottom)
  • Preserve the skill's existing structure, voice, and author attribution
  • Make the improvement feel native to the skill, not bolted on
  • If an observation suggests a new phase, step, anti-pattern, or checklist item, place it where it logically belongs
Routing observations that target system skills: When an observation targets a system skill (see the known system skills list in Step 2), do NOT skip it. Instead, route the improvement to a complementary skill — a user-owned skill named 
{system-skill}-extras
(e.g., 
docx-extras
) that layers additional guidance on top of the system skill. If the complementary skill doesn't exist yet, create it. The complementary skill should:
  • State which system skill it extends
  • Contain only the delta — the additional rules, anti-patterns, or guidance not present in the system skill
  • Be loaded alongside the system skill (add a note to CLAUDE.md or equivalent configuration if needed)
This ensures observations targeting system skills are still actionable, even though the system skill files themselves cannot be modified.
Important: Do not edit skill files in place. Save updated versions to the workspace folder for user review and manual replacement (see Delivering Updated Skills below).
Step 6 — Mark observations as ACTIONED
After successfully creating an updated skill based on an observation, update that observation's status in 
log.md
from OPEN to ACTIONED. Add a brief note about which skill(s) were updated, e.g.:
ACTIONED — Applied to [skill-name] (weekly review [date])
Note: the standard archival-on-write mechanism (see "Archival on Write" in the Observation Protocol) will automatically archive these newly-resolved entries on the next log write. No separate archival step is needed here.
Step 7 — Update timestamp
Write today's date to 
[workspace folder]/skill-observations/last-review-date.txt
.
Step 8 — Present summary and user action items
Present the user with a clear summary and explicit instructions for what they need to do. Follow the format in Delivering Updated Skills below.
步骤0 — 调度器可用性检查
在运行回顾本身之前，检查是否可通过平台的任务调度功能自动执行每周回顾。
  1. 检查文件 
    [workspace folder]/skill-observations/scheduler-registered.txt
    是否存在。如果存在，已注册调度任务——跳至步骤1。
  2. 如果文件不存在，检查是否有任务调度功能可用。在Cowork中，检查
    create-shortcut
    技能及其
    set_scheduled_task
    工具。在基于终端的环境中，可能有cron或等效调度工具可用。
  3. 如果调度功能可用:
    • 读取 
      [workspace folder]/skill-observations/scheduled-task-draft.md
      中的草稿任务描述
    • 在Cowork中，调用
      create-shortcut
      技能注册每周技能回顾作为调度任务。在其他环境中，使用可用的调度机制。
    • 使用任务名称
      weekly-skill-review
      和每周节奏（例如周一上午）
    • 成功后，将今天的日期写入 
      [workspace folder]/skill-observations/scheduler-registered.txt
    • 告知用户：“每周技能回顾已注册为调度任务。手动
      last-review-date.txt
      触发器仍作为备用。”
  4. 如果工具不可用，静默跳至步骤1。不要在每次回顾时告知用户——此检查在成功前保持静默。
步骤1 — 加载观察结果和原则
读取
[workspace folder]/skill-observations/log.md
中的观察日志。提取所有状态为OPEN的观察结果。同时读取 
[workspace folder]/skill-observations/cross-cutting-principles.md
并提取所有活动原则。
如果没有OPEN观察结果且所有原则已传播，跳过回顾，更新时间戳并继续会话。简要告知用户：“每周技能回顾：无未处理观察结果或未完成原则。所有技能均为最新状态。”
步骤2 — 清点所有技能
使用系统提示中的
<available_skills>
识别所有技能。在没有此标签的环境中，使用技能目录或等效列表机制发现可用技能。
对于每个技能，读取其提供位置的SKILL.md文件。排除内置平台技能的更新——仅更新用户创建的自定义技能。
已知系统技能（只读，用户无法替换）: docx, pdf, xlsx, pptx, skill-creator, schedule。随着平台发展，此列表可能会增长——如果技能更新因用户无法覆盖文件而失败，将其添加到此列表中。
自定义技能（用户拥有，可替换）是技能目录中不在上述系统列表中的所有其他技能。
步骤3 — 将观察结果与每个技能交叉检查
对于每个OPEN观察结果，评估它是否与每个技能相关。不要仅依赖观察结果自身的“Skill”字段——观察结果可能包含比原始上下文更广泛适用的通用原则。同时考虑具体的“Suggested improvement”和通用的“Principle”字段。构建技能→[相关观察结果]的映射。
步骤4 — 将跨领域原则与每个技能交叉检查
对于每个活动跨领域原则，检查每个技能是否已合规。标记任何尚未实施该原则的技能。
步骤5 — 应用更新
对于每个有相关观察结果或不符合原则的技能，创建其SKILL.md的更新版本。编辑时：
  • 将见解集成到技能的适当部分（不要只是在底部追加观察结果列表）
  • 保留技能的现有结构、语气和作者署名
  • 使改进感觉是技能原生的，而非附加的
  • 如果观察结果建议添加新阶段、步骤、反模式或检查项，将其放在逻辑上合适的位置
针对系统技能的观察结果路由: 当观察结果针对系统技能（见步骤2中的已知系统技能列表）时，不要跳过它。相反，将改进路由到补充技能——名为
{system-skill}-extras
的用户拥有技能（例如
docx-extras
），在系统技能之上添加额外指导。如果补充技能不存在，创建它。补充技能应：
  • 说明它扩展了哪个系统技能
  • 仅包含增量内容——系统技能中没有的额外规则、反模式或指导
  • 与系统技能一起加载（如果需要，在CLAUDE.md或等效配置中添加注释）
这确保即使系统技能文件本身无法修改，针对系统技能的观察结果仍可操作。
重要提示: 不要就地编辑技能文件。将更新版本保存到工作区文件夹供用户审查和手动替换（见下文交付更新技能）。
步骤6 — 将观察结果标记为ACTIONED
基于观察结果成功创建更新技能后，将
log.md
中该观察结果的状态从OPEN更新为ACTIONED。添加关于更新了哪些技能的简短注释，例如：
ACTIONED — Applied to [skill-name] (weekly review [date])
注意：标准的写入时归档机制（见观察协议中的“写入时归档”）会在下次日志写入时自动归档这些新解决的条目。此处无需单独的归档步骤。
步骤7 — 更新时间戳
将今天的日期写入 
[workspace folder]/skill-observations/last-review-date.txt
。
步骤8 — 呈现摘要和用户行动项
向用户呈现清晰的摘要和明确的操作说明。遵循下文交付更新技能中的格式。

Constraints

约束条件

  • Do not modify observation entries beyond their status field
  • Do not create new skills — only update existing ones. If an observation suggests a new skill, note it in the summary for the user to action separately via the skill-creator
  • If an observation seems relevant but you're unsure how to integrate it, skip it and note the uncertainty in the summary
  • Treat observations marked "internal" with the same rigour as "open-source"
  • 除状态字段外，不要修改观察条目
  • 不要创建新技能——仅更新现有技能。如果观察结果建议创建新技能，在摘要中注明，供用户通过skill-creator单独处理
  • 如果观察结果看似相关但您不确定如何集成，跳过它并在摘要中注明不确定性
  • 对标记为“internal”的观察结果采用与“open-source”相同的严谨性

Delivering Updated Skills to the User

向用户交付更新技能

When the weekly review (or any other process) produces updated skill files, the updated files must be delivered to the user for manual replacement. Skill files live in a read-only location during sessions and may be managed in version control, synced across devices, or packaged for distribution. Automatic in-place editing is neither possible nor desirable — delivering to the workspace folder with explicit instructions keeps the user in control.
当每周回顾（或任何其他流程）生成更新的技能文件时，必须将更新文件交付给用户进行手动替换。技能文件在会话期间位于只读位置，可能受版本控制管理、跨设备同步或打包分发。自动就地编辑既不可能也不可取——交付到工作区文件夹并提供明确说明可让用户保持控制权。

Delivery Process

交付流程

  1. Save each updated SKILL.md to the workspace folder using this structure:
    [workspace folder]/skill-updates/[date]/[skill-name]/SKILL.md
    For example:
    [workspace folder]/skill-updates/2026-02-16/my-skill-name/SKILL.md
  2. Present the user with an explicit action list using this format:
    ## Weekly Skill Review Complete — [date]

The following skills have been updated based on [N] open observations
and [N] cross-cutting principles.

### What you need to do

For each updated skill below, replace the existing SKILL.md in your
skill directory with the updated version from your workspace folder.

### Updated Skills

**[skill-name]**
- Changes: [1-sentence summary of what changed]
- Observations applied: #[N], #[N]
- Updated file: [link to file in workspace folder]
- Action: Replace [skill-directory]/SKILL.md with this file

[repeat for each updated skill]

### Observations Actioned
[list of observation numbers and titles marked ACTIONED]

### Skipped (needs manual review)
[observations that were unclear or couldn't be applied, with explanation]

### No Changes Needed
[skills that were checked but already compliant]
  3. Do not proceed with other work until the user has acknowledged the summary. The user does not need to replace the files immediately, but they should be aware of what's pending.
  1. 使用以下结构将每个更新的SKILL.md保存到工作区文件夹：
    [workspace folder]/skill-updates/[date]/[skill-name]/SKILL.md
    例如：
    [workspace folder]/skill-updates/2026-02-16/my-skill-name/SKILL.md
  2. 使用以下格式向用户呈现明确的行动列表：
    ## Weekly Skill Review Complete — [date]

The following skills have been updated based on [N] open observations
and [N] cross-cutting principles.

### What you need to do

For each updated skill below, replace the existing SKILL.md in your
skill directory with the updated version from your workspace folder.

### Updated Skills

**[skill-name]**
- Changes: [1句话摘要变更内容]
- Observations applied: #[N], #[N]
- Updated file: [工作区文件夹中的文件链接]
- Action: Replace [skill-directory]/SKILL.md with this file

[为每个更新技能重复]

### Observations Actioned
[标记为ACTIONED的观察编号和标题列表]

### Skipped (needs manual review)
[不清楚或无法应用的观察结果，附解释]

### No Changes Needed
[已检查但已合规的技能]
  3. 在用户确认摘要前，不要继续其他工作。用户无需立即替换文件，但应知晓待处理事项。

Observation Log Management

观察日志管理

Location

位置

The observation log persists between sessions in the user's workspace folder. Create the log file on first use if it doesn't exist. Default path:
[workspace folder]/skill-observations/log.md
观察日志在用户的工作区文件夹中跨会话持久保存。如果不存在，首次使用时创建日志文件。默认路径：
[workspace folder]/skill-observations/log.md

Log Structure

日志结构

markdown
undefined
markdown
undefined

Skill Observation Log

Skill Observation Log

Observations captured during task-oriented work. Each entry identifies a potential skill improvement or new skill opportunity.
Status key: OPEN = not yet actioned | ACTIONED = skill updated/created | DECLINED = user decided not to pursue
任务导向型工作中捕捉的观察结果。每个条目标识潜在的技能改进或新技能机会。
Status key: OPEN = 尚未处理 | ACTIONED = 技能已更新/创建 | DECLINED = 用户决定不推进

[Date or Session Identifier]

[日期或会话标识符]

Observation 1: [Title]

Observation 1: [标题]

Status: OPEN [... full observation format ...]
Status: OPEN [...完整观察格式...]

Observation 2: [Title]

Observation 2: [标题]

Status: ACTIONED — Applied to [skill-name], rule 35 [... full observation format ...]
undefined
Status: ACTIONED — Applied to [skill-name], rule 35 [...完整观察格式...]
undefined

Session Start Protocol

会话启动协议

This is the single entry point for all session-start checks. Run through these steps at the start of each task-oriented session:
  1. Check whether files exist. If the observation log or cross-cutting principles file don't exist yet, this is a first-time setup — create them using the templates in the Log Structure section (below in this document) and the Cross-Cutting Principles File Structure section (under Principle Propagation). If the files already exist, proceed to step 2.
  2. Scan for relevant context. Read any OPEN observations and active cross-cutting principles. Don't surface them unprompted unless they're directly relevant to the current task — just hold them in awareness.
  3. Check the weekly review trigger. Read the timestamp in 
    [workspace folder]/skill-observations/last-review-date.txt
    . If the file doesn't exist or the date is more than 7 days ago, trigger the Weekly Comprehensive Review (described in full under its own section) before proceeding with the user's task. If fewer than 7 days have passed, proceed normally.
  4. Check the configuration file. Run the config detection described in Detecting the Configuration File (under Recommended Activation Setup). This runs once per session.
这是所有会话启动检查的单一入口点。在每个任务导向型会话开始时运行以下步骤：
  1. **检查文件是否存在。**如果观察日志或跨领域原则文件尚不存在，这是首次设置——使用日志结构部分（本文档下方）和原则传播下的跨领域原则文件结构部分中的模板创建它们。如果文件已存在，继续步骤2。
  2. **扫描相关上下文。**读取所有OPEN观察结果和活动跨领域原则。除非与当前任务直接相关，否则不要主动展示——只需记住它们。
  3. **检查每周回顾触发器。**读取 
    [workspace folder]/skill-observations/last-review-date.txt
    中的时间戳。如果文件不存在或日期超过7天前，在继续用户任务前触发每周全面回顾（在其自身部分有完整描述）。如果不到7天，正常继续。
  4. **检查配置文件。**运行推荐激活设置下的配置检测（见检测配置文件）。此检查每个会话运行一次。

Keeping the Log Clean

保持日志整洁

Archival is event-driven and runs on every log write. Before appending new observations or updating statuses, entries that were already marked ACTIONED or DECLINED in a previous update are moved to a timestamped archive file (see "Archival on Write" in the Observation Protocol). This keeps the active log focused on OPEN items and recently-resolved entries, while the archive provides the complete historical record.
归档是事件驱动的，每次写入日志时都会运行。在追加新观察结果或更新状态前，将之前更新中已标记为ACTIONED或DECLINED的条目移至带时间戳的归档文件（见观察协议中的“写入时归档”）。这使活动日志专注于OPEN项和最近解决的条目，而归档提供完整的历史记录。

The Pre-Flight Principle

飞行前原则

One of the most important patterns this skill should propagate to every skill it helps create or improve: built-in enforcement.
Real-world experience has shown that rules documented in a skill are not always followed during the creative flow of producing output. The result: output that violates the skill's own standards, which reflects badly on the skill.
The fix: every skill that contains explicit rules or requirements should include a verification step where Claude re-reads the rules and checks its output against them before delivery. This isn't overhead — it's quality assurance. A 30-second re-read prevents a 30-minute rework cycle.
When creating or improving any skill through this observation process, ask: "Does this skill have rules? If yes, does it have a mechanism to enforce them?" If the answer to the second question is no, add one.
本技能应传播到它帮助创建或改进的每个技能的最重要模式之一：内置执行机制。
实际经验表明，技能中记录的规则在产出输出的创作流程中并不总是被遵循。结果：输出违反技能自身标准，这会损害技能的声誉。
解决方案：每个包含明确规则或要求的技能应包含验证步骤，Claude在交付前重新阅读规则并检查输出是否符合规则。这不是额外负担——而是质量保证。30秒的重新阅读可避免30分钟的返工周期。
通过此观察过程创建或改进任何技能时，问自己：“此技能有规则吗？如果有，它有执行机制吗？”如果第二个问题的答案是否定的，添加一个。

General Debugging Principle

通用调试原则

When debugging, always ask: is this a single instance or a pattern? If an error reveals a pattern (e.g., a class of similar issues), fix the class, not just the instance. Every specific error is a signal about a class of errors. Audit the full scope on first encounter to avoid discovering related failures in subsequent cycles.
调试时，始终问：这是单一实例还是模式？如果错误揭示了模式（例如一类类似问题），修复类别，而非仅修复实例。每个特定错误都是一类错误的信号。首次遇到时审核全部范围，避免在后续周期中发现相关故障。

Self-Enforcement

自我执行

This skill practises what it preaches. Before surfacing observations at end of session, verify:
  1. Were observations logged throughout the full session — including during post-task feedback, discussion phases, and reflective conversations, not just during active tool use?
  2. Were observations logged silently without interrupting the user's flow?
  3. Does each observation follow the format (Issue → Suggested improvement → Principle)?
  4. Is each observation tagged with the correct type (open-source or internal)?
  5. For any observations about existing skills, does the suggested improvement reference the specific section or rule?
  6. For any observation tagged 
    type: open-source
    , does the Principle field contain any client-identifying information? If so, generalise it before surfacing.
If any observation fails these checks, fix it before surfacing.
本技能以身作则。在会话结束时展示观察结果前，验证：
  1. 是否在整个会话期间记录了观察结果——包括任务后反馈、讨论阶段和反思对话，而非仅在主动使用工具期间？
  2. 是否静默记录观察结果，未打断用户的工作流？
  3. 每个观察结果是否遵循格式（Issue → Suggested improvement → Principle）？
  4. 每个观察结果是否标记了正确的类型（open-source或internal）？
  5. 对于任何关于现有技能的观察结果，建议的改进是否引用了特定部分或规则？
  6. 对于任何标记为
    type: open-source
    的观察结果，Principle字段是否包含任何客户识别信息？如果有，在展示前通用化。
如果任何观察结果未通过这些检查，在展示前修复。

Environment Compatibility

环境兼容性

The observation methodology works in any environment where Claude can interact with users during task-oriented work. The persistence mechanism is what varies.
观察方法论适用于Claude可在任务导向型工作中与用户交互的任何环境。持久化机制会有所不同。

With Persistent Storage

有持久存储的环境

In environments with file system access (desktop tools with workspace folders, terminal-based tools with project directories, or similar), the full workflow applies as described: observations are logged to a persistent file, the cross- cutting principles file is read during skill regeneration, and the log carries over between sessions automatically.
在有文件系统访问权限的环境中（带工作区文件夹的桌面工具、带项目目录的基于终端的工具或类似环境），完整工作流按描述应用：观察结果记录到持久文件，技能重新生成时读取跨领域原则文件，日志自动跨会话保留。

Without Persistent Storage

无持久存储的环境

In environments without file system access (web-based chat interfaces or similar), the skill still works — the observation methodology is environment- independent. The difference is that persistence becomes the user's responsibility, and the skill shifts into handoff doc mode to support this.
How handoff doc mode works:
  • Observations are captured within the conversation and surfaced before the session ends, as usual
  • Instead of writing to a log file, observations are collected in-session and presented in a structured handoff document before the session ends
  • The handoff doc includes: all observations in full format, any decisions made during the session, action items and next steps, and any working artifacts (drafts, analyses) that need to survive into the next session
  • The user copies this document to their own storage (notes app, file system, etc.) and pastes it into the next session to restore context
  • Cross-cutting principles should be included in the handoff doc so the user can provide them when starting a new session
Proactive handoff generation: In sessions without persistent storage, don't wait for the user to request a handoff doc. When the conversation starts to wind down — the user is summarising, saying "that's it for now," or the substance is wrapping up — proactively offer to generate one. A premature offer is a minor interruption; a missing one is lost work.
Handoff doc format:
markdown
undefined
在没有文件系统访问权限的环境中（基于Web的聊天界面或类似环境），技能仍可工作——观察方法论与环境无关。区别在于持久化成为用户的责任，技能会切换到交接文档模式以支持这一点。
交接文档模式工作方式:
  • 观察结果在对话中捕捉，并像往常一样在会话结束前展示
  • 不写入日志文件，而是在会话中收集观察结果，并在会话结束前以结构化交接文档形式呈现
  • 交接文档包括：所有完整格式的观察结果、会话期间做出的任何决策、行动项和下一步，以及需要保留到下一会话的任何工作工件（草稿、分析）
  • 用户将此文档复制到自己的存储（笔记应用、文件系统等），并粘贴到下一会话以恢复上下文
  • 跨领域原则应包含在交接文档中，以便用户在开始新会话时提供
主动生成交接文档: 在没有持久存储的会话中，不要等待用户请求交接文档。当对话开始收尾——用户正在总结、说“暂时就这些”或内容即将结束时——主动提供生成交接文档。过早提供是轻微打扰；遗漏则会导致工作丢失。
交接文档格式:
markdown
undefined

Session Handoff: [Session Topic]

Session Handoff: [会话主题]

Date: [date] Context: [what was worked on and what the next session needs to know]
Date: [日期] Context: [已完成工作和下一会话需要了解的内容]

Decisions Made

Decisions Made

[numbered list of decisions]
[决策编号列表]

Observations Logged

Observations Logged

[full observation entries in standard format]
[标准格式的完整观察条目]

Cross-Cutting Principles (current)

Cross-Cutting Principles (current)

[any principles that were active or newly added]
[任何活动或新增的原则]

Action Items

Action Items

[what needs to happen next, with enough context to resume]
[下一步需要做的事情，包含足够上下文以恢复工作]

Working Artifacts

Working Artifacts

[any drafts, analyses, or intermediate work products in full]

This is less seamless than the persistent-storage workflow, but the core value
— systematically capturing insights that would otherwise be lost — is
preserved. The observation format and surfacing protocol are identical in both
environments.

---
[任何草稿、分析或中间工作产物的完整内容]

这不如持久存储工作流无缝，但核心价值——系统捕捉否则会丢失的见解——得以保留。观察格式和展示协议在两种环境中相同。

---

Quick Reference

快速参考

QuestionAnswer
When do I observe?Throughout the full task session, including post-task feedback and reflective conversations
How do I log?Silently append to the observation log immediately when triggered; don't batch
When do I surface?End of session, or earlier if needed
How do I activate reliably?Add a config-level instruction (see Recommended Activation Setup)
Open-source or internal?Default to open-source when possible
Licence for open-source?CC BY 4.0 recommended
Small fix or skill-creator?Needs testing → skill-creator (if available). For internal skills with established requirements, writing directly is efficient. Clearly additive → apply directly
What format?Issue → Suggested improvement → Principle
Author attribution?Required for open-source skills; use the template
Cross-cutting principle?Add to principles file, enforce during regeneration
Confidentiality check?Four layers: observation, pre-creation, post-draft, structural
No persistent storage?Handoff doc mode — observations surfaced in a structured doc at session end
Scheduler automation?Step 0 of weekly review auto-checks; silent until tool is available
Observation numbering?Mandatory pre-logging search ensures no collisions; never use cached numbers
Log archival?Event-driven — resolved entries are archived on the next log write
Simplification signals?Watch for one-off rules, never-used sections, elaborate workflows users skip, and contradictions
Handoff doc analysis?Systematically extract implied observations from action items, open questions, and narrative sections
Debugging approach?Always identify the class of error, not just the instance; audit full scope on first encounter
问题答案
何时观察？整个任务会话期间，包括任务后反馈和反思对话
如何记录？触发时立即静默追加到观察日志；不要批量处理
何时展示？会话结束时，必要时提前展示
如何可靠激活？添加配置级指令（见推荐激活设置）
开源还是内部？尽可能默认选择开源
开源许可？推荐使用CC BY 4.0
小修复还是使用skill-creator？需要测试 → 使用skill-creator（如有可用）。对于需求明确的内部技能，直接编写更高效。明确附加的 → 直接应用
什么格式？Issue → Suggested improvement → Principle
需要作者署名吗？开源技能必需；使用模板
跨领域原则？添加到原则文件，重新生成时强制执行
保密检查？四层：观察级、创建前、草稿后、结构级
无持久存储？交接文档模式——会话结束时在结构化文档中展示观察结果
调度器自动化？每周回顾步骤0自动检查；工具可用前保持静默
观察编号？预记录搜索确保无冲突；永远不要使用缓存编号
日志归档？事件驱动——已解决条目在下次日志写入时归档
简化信号？留意一次性规则、从未使用的部分、用户跳过的复杂工作流和矛盾
交接文档分析？从行动项、未解决问题和叙述部分系统提取隐含观察结果
调试方法？始终识别错误类别，而非仅实例；首次遇到时审核全部范围