workthrough

此技能会自动为所有开发工作生成详细的工作过程文档，以清晰、结构化的格式记录背景、所做的更改和验证结果。

何时使用此技能

在以下情况后自动使用此技能：

• 实现新功能或功能性改进
• 修复 Bug 或错误
• 重构代码
• 更改配置
• 更新依赖项
• 解决构建／编译问题
• 进行任何重要的代码修改

文档结构

工作过程文档遵循以下结构：

1. 标题：清晰、准确地描述已完成的工作
2. 概述：简要总结完成了什么以及原因
3. 所做更改：详细列出所有修改
4. 代码示例：展示重要更改的关键代码片段
5. 验证结果：确认成功的构建／测试结果

实施指南

生成工作过程文档时：

1. 记录完整背景

• 要解决什么问题？
• 之前存在哪些错误或问题？
• 采用了什么方案？
• 为什么做出特定决策？

2. 系统地记录所有更改

• 列出修改的每个文件及其完整路径
• 描述每个文件中的更改
• 针对重要更改提供修改前后的代码片段
• 注明添加或移除的依赖项
• 记录配置更新

3. 展示代码示例

使用清晰、格式规范的代码块：

// file: src/path/to/file.tsx
<div className="example">
  {/* Show relevant code changes */}
</div>

4. 包含验证信息

• 显示成功结果的构建输出
• 测试结果
• 错误消息（如仍有错误）
• 退出代码
• 屏幕截图（如相关）

5. 使用清晰的格式

• 使用 Markdown 标题（##、###）
• 使用项目符号和编号列表
• 使用带语法高亮的代码块
• 使用块引用展示输出／日志
• 保持段落简洁

文档组织

按照以下命名约定保存工作过程文档：

workthrough/YYYY-MM-DD-brief-description.md

或者按功能／项目组织：

workthrough/feature-name/implementation.md
workthrough/bugfix/issue-123.md

工作过程文档结构示例

# [Clear Descriptive Title]

## Overview
Brief 2-3 sentence summary of what was accomplished.

## Context
- Why was this work needed?
- What was the initial problem/requirement?
- Any relevant background information

## Changes Made

### 1. [First Major Change]
- Specific modification 1
- Specific modification 2
- File: `path/to/file.tsx`

### 2. [Second Major Change]
- Specific modification 1
- File: `path/to/another-file.ts`

### 3. [Additional Changes]
- Dependencies added: `package-name@version`
- Configuration updates: `config-file.json`

## Code Examples

### [Feature/Fix Name]
```typescript
// src/path/to/file.tsx
const example = () => {
  // Show the key code changes
}

验证结果

构建验证

> build command output
✓ Compiled successfully
Exit code: 0

测试结果

> test command output
All tests passed

后续步骤

• 需要完成的后续任务
• 已知限制或未来改进

## Automation Instructions

After completing ANY development work:

1. **Gather Information**
   - Review all files modified during the session
   - Collect build/test output
   - Identify the main objective that was accomplished

2. **Create Document**
   - Generate workthrough document in `workthrough/` directory
   - Use timestamp or descriptive filename
   - Follow the structure guidelines above

3. **Be Comprehensive**
   - Include all relevant details
   - Don't assume future readers have context
   - Document decisions and reasoning
   - Show concrete examples

4. **Verify Completeness**
   - Confirm all changes are documented
   - Include verification results
   - Add any relevant warnings or notes

## Quality Standards

Good workthrough documentation should:
- Be readable by other developers
- Provide enough detail to understand changes
- Include verification that changes work
- Serve as a reference for similar future work
- Capture important decisions and context

Avoid:
- Overly verbose descriptions
- Unnecessary technical jargon
- Missing verification steps
- Vague or unclear explanations
- Incomplete code examples

## Output Location

Unless specified otherwise, save workthrough documents to:

workthrough/YYYY-MM-DD-brief-description.md

Create the `workthrough/` directory if it doesn't exist.

## Integration with Workflow

This skill should be triggered automatically at the end of development sessions. The documentation serves as:
- A development log/journal
- Knowledge base for the project
- Onboarding material for new developers
- Reference for debugging similar issues
- Record of architectural decisions

Remember: Good documentation is a gift to your future self and your team.