workthrough

このスキルは、すべての開発作業について、背景、変更内容、検証結果を明確で構造化された形式で記録した詳細な作業記録ドキュメントを自動生成します。

このスキルを使用するタイミング

次の作業の後に、このスキルを自動的に使用してください。

• 新機能や機能を実装したとき
• バグやエラーを修正したとき
• コードをリファクタリングしたとき
• 設定を変更したとき
• 依存関係を更新したとき
• ビルド／コンパイルの問題を解決したとき
• その他、重要なコード変更を行ったとき

ドキュメントの構成

作業記録ドキュメントは、次の構成に従います。

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.