Development Process Documentation

Document AI-assisted development sessions as transferable case studies showing how human-AI collaboration works, not the specific application built.

Audience & Purpose

• Primary audience: Developers learning to work with AI assistants, technical leads designing processes
• Format: Case study ("how we did this"), not a tutorial
• Focus: The methodology and patterns, not the application being built

Workflow

1. Analyze session context — Review the conversation to identify phases, decisions, and deliverables
2. Extract patterns — Identify reusable conversation patterns and decision rationales
3. Determine increment — Check for existing development-process-*.md files to set the correct number
4. Compose completely — Mentally compose the full document before writing
5. Write once — Save the complete document in a single operation

Output Path

Default: ai_docs/learnings/development-process-{N}.md where {N} is incremental.

If user specifies a different path, use that instead.

To determine {N}: Check existing files in ai_docs/learnings/ matching development-process-*.md and increment from the highest number found.

Document Structure

Use this template structure, adapting sections based on what occurred in the session:

# AI-Assisted Development Process Documentation

## Purpose

[Standard purpose statement about methodology capture]

**Important**: This documents *how* we work together, not the specific application being built.

---

## Part {N}: {Phase Name}

### Overview

[1-2 sentences: What this part covers and the goal]

### Context

**Starting Point**: [What artifacts/state existed before this session]
**Goal**: [What we aimed to produce]

### Conversation Pattern: {Pattern Name}

**Why**: [Rationale — why this pattern matters]

**Pattern Used**:

Human: [Generalized prompt pattern] AI: [Expected response pattern]

**What We Did**:
[Specific application of the pattern in this session]

**Key Insight**: [Transferable lesson learned]

---

### Deliverables Produced

| Deliverable | Location | Purpose |
|-------------|----------|---------|
| [Name] | [Path] | [What it's for] |

---

### Principles Demonstrated

1. **[Principle Name]**: [One-sentence explanation]
2. ...

---

## Summary: Part {N}

| Phase | Pattern | Deliverables |
|-------|---------|--------------|
| [Name] | [Pattern summary] | [Count and type] |

**Next**: [What the next part will cover, if known]

---

## Document History

| Date | Part | What Was Documented |
|------|------|---------------------|
| [Date] | Part {N} | [Brief description] |

---

*This document will be extended as the project progresses through subsequent phases.*

Content Guidelines

What to Capture

• Conversation patterns: The structure of prompts and responses that worked
• Decision rationales: Why choices were made (more important than what)
• Clarification moments: Questions asked before proceeding and why they mattered
• Validation steps: How consistency was verified across deliverables

What to Omit

• Application-specific implementation details (unless illustrating a pattern)
• Code snippets (unless demonstrating a reusable approach)
• Redundant explanations of concepts Claude already knows

Style

• Use tables for consistency checks and deliverable summaries
• Use code blocks for prompt patterns
• Keep "Key Insight" statements to one sentence
• Write for someone who will apply these patterns to different projects

Writing Instructions

CRITICAL: Before writing, fully compose the complete document content mentally, then write it in a SINGLE file creation operation. Do not use incremental file building or append operations.

If the document would exceed reasonable length, discuss with the user how to scope it before writing.