workthrough

Use this skill automatically after:

• Implementing new features or functionality
• Fixing bugs or errors
• Refactoring code
• Making configuration changes
• Updating dependencies
• Resolving build/compilation issues
• Any significant code modifications

The workthrough documentation follows this structure:

1. Title: Clear, descriptive title of the work completed
2. Overview: Brief summary of what was accomplished and why
3. Changes Made: Detailed breakdown of all modifications
4. Code Examples: Key code snippets showing important changes
5. Verification Results: Build/test results confirming success

When generating workthrough documentation:

1. Capture Complete Context

• What problem was being solved?
• What errors or issues existed before?
• What approach was taken?
• Why were specific decisions made?

2. Document All Changes Systematically

• List each file modified with full paths
• Describe what changed in each file
• Include before/after code snippets for significant changes
• Note any dependencies added or removed
• Document configuration updates

3. Show Code Examples

Use clear, well-formatted code blocks:

```language

// file: src/path/to/file.tsx

```

4. Include Verification

• Build output showing success
• Test results
• Error messages (if any remain)
• Exit codes
• Screenshots (if relevant)

5. Use Clear Formatting

• Use markdown headers (##, ###)
• Use bullet points and numbered lists
• Use code blocks with syntax highlighting
• Use blockquotes for output/logs
• Keep paragraphs concise

Save workthrough documents with this naming convention:

```

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

```

Or organize by feature/project:

```

workthrough/feature-name/implementation.md

workthrough/bugfix/issue-123.md

```

```markdown

# [Clear Descriptive Title]

Brief 2-3 sentence summary of what was accomplished.

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

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

[Feature/Fix Name]

```typescript

// src/path/to/file.tsx

const example = () => {

// Show the key code changes

}

```

Build Verification

```bash

> build command output

✓ Compiled successfully

Exit code: 0

```

Test Results

```bash

> test command output

All tests passed

```

• Any follow-up tasks needed
• Known limitations or future improvements

```

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

1. Create Document

- Generate workthrough document in workthrough/ directory

- Use timestamp or descriptive filename

- Follow the structure guidelines above

1. Be Comprehensive

- Include all relevant details

- Don't assume future readers have context

- Document decisions and reasoning

- Show concrete examples

1. Verify Completeness

- Confirm all changes are documented

- Include verification results

- Add any relevant warnings or notes

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

Unless specified otherwise, save workthrough documents to:

```

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

```

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

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.