AI tools + resources for newsrooms | Center for Cooperative Media

01 // GUIDES

PRIMARY_MODULES

Tutorials, reference materials, and documentation for working with AI coding assistants. Start with the Vibe Coding Guide to understand the mindset.

:: VIBE_CODING

Vibe Coder's guide

Everything you need to ship code with AI. Essentials, advanced skills, glossary, and cheat sheet.

START_VIBING ->

:: SETUP_GUIDE

Terminal setup

Configure your terminal for Claude Code, Gemini CLI, and Codex. Mac/Windows setup and status line config.

INIT_TERMINAL ->

:: CHEAT_SHEET

Quick reference

Printable one-page reference card. Essential info, workflow steps, and common pitfalls.

VIEW_DATA ->

:: DOCS

Language guide

When to use Python vs JavaScript vs R. Practical guide for common journalism tasks.

READ_FILE ->

:: DATABASE

Technical glossary

Plain-language definitions of 40+ technical terms. No jargon, just clear explanations.

ACCESS_DB ->

:: STATIC_DOC

LLM selection guide

Static documentation and decision matrices for choosing AI coding assistants.

READ_FILE ->

:: DEV_TOOLKIT

Tool stacks

Low-cost development stack for shipping projects. IDEs, databases, auth, deployment—all free or nearly free.

VIEW_STACK ->

:: ADVANCED

Code patterns

Seven battle-tested Claude Code patterns. Error logging, commands-as-apps, hooks, context hygiene, and more.

LOAD_PATTERNS ->

CLAUDE CODE v2.1

TERMINAL_AI_ASSISTANT

Build tools faster with Claude Code—Anthropic's AI coding assistant that runs in your terminal. It reads your files, executes code, and iterates autonomously.

Plan mode

Use /plan to have Claude explore your codebase and design architecture before coding.

Hooks

Automate validation with PreToolUse/PostToolUse hooks that run on every edit.

Skills

Teach Claude specialized knowledge with reusable skills in .claude/skills/.

Background tasks

Press Ctrl+B to run tasks in background while you keep working.

DOWNLOAD_QUICKREF ADVANCED_PATTERNS EXPLORE_TOOLS_TRACK

02 // MY_TOOLS

EXTERNAL_APPLICATIONS

Standalone tools I've built for journalism and data work. These live at their own domains but share the same design philosophy.

:: DECISION_ENGINE

LLM Advisor

Decision support system for choosing the right LLM and approach for your newsroom project.

JavaScript Decision Tree

LAUNCH_APP ->

:: LIBRARY_DATABASE

Python Explorer

Interactive directory of Python libraries across 8+ domains. Browse, search, and compare packages.

JavaScript Search

EXPLORE_DB ↗

:: WEB_SCRAPER

Scrapefruit

Visual web scraping with anti-bot bypass. PyWebView GUI + Playwright stealth mode for extracting content from protected sites.

Python Playwright Flask

LAUNCH_APP ↗

:: VOICE_TERMINAL

AudioBash

Voice-controlled desktop terminal. Speak commands, execute instantly with AI-powered context awareness.

Electron React TypeScript

VIEW_REPO ↗

03 // ASSETS

TEMPLATES & CHECKLISTS

Downloadable markdown files to copy into your projects. Use checklists during coding sessions, changelogs to track progress, and LESSONS templates for retrospectives.

VIBE-CODING-CHECKLIST.md

Pre-flight checklist for AI-assisted coding sessions

# Vibe coding quick start checklist

Pre-flight checklist for AI-assisted coding sessions. Print this out or keep it open during your first few projects.

---

## Before you start

- [ ] **Define a specific goal** — Write down exactly what "done" looks like in one sentence
- [ ] **Gather your data** — Have sample files ready, know your data format
- [ ] **Choose your LLM** — Pick one and stick with it for this session
- [ ] **Create project folder** — Clear name, organized structure
- [ ] **Start a changelog** — Use the CHANGELOG-TEMPLATE.md file
- [ ] **Test your environment** — Can you run "Hello World" in your language of choice?
- [ ] **Set a time limit** — Protect yourself from rabbit holes

---

## During the session

### Prompting best practices

- [ ] Start with the big picture, then drill into details
- [ ] Include your environment info (OS, language version, key libraries)
- [ ] Provide sample input/output when possible
- [ ] Ask for code in chunks, not all at once
- [ ] When stuck, ask "What might be causing this?" not just "Fix this"

### When code breaks

- [ ] Copy the **full error message**, not just the last line
- [ ] Paste it back to the AI with context: "I ran this code and got this error"
- [ ] If same error 3+ times, step back and explain the bigger goal
- [ ] Check if the error is your environment, not the code

### Red flags

- [ ] Code getting too complex? Split into smaller scripts
- [ ] Scope creeping? Note the new idea for later, stay focused
- [ ] Going in circles? Take a break, return with fresh eyes
- [ ] AI giving same wrong answer? Try rephrasing or different LLM

---

## Before you stop

- [ ] **Test with real data** — Not just the sample
- [ ] **Document what you built** — Update the changelog
- [ ] **Note what's unfinished** — Clear next steps for future you
- [ ] **Save working state** — Commit to git or backup the folder
- [ ] **Clean up** — Remove test files, add comments to unclear code

---

## Quick reference

### When to use which language

| Task | Language |
|------|----------|
| Data cleaning/analysis | Python |
| Statistical analysis | R |
| Interactive web visualization | JavaScript |
| File automation | Bash/Python |
| Database queries | SQL |

### Current best LLMs for coding (Dec 2025)

| Need | Recommendation |
|------|----------------|
| Coding and writing | Claude 4.5 Opus |
| Front-end design, large docs | Gemini 3.0 Pro |
| OpenAI coding tasks | Codex (GPT 5.1) |
| Free, getting started | Claude.ai free tier |

---

*From [Center for Cooperative Media](https://centerforcooperativemedia.org) AI Tools for Newsrooms*

LLM-COMPARISON.md

Detailed comparison chart of AI models for journalism projects

# LLM comparison chart for journalism projects

> Last updated: December 2025. The AI landscape changes fast—verify current pricing and capabilities.

---

## At a glance

| Model | Best for | Speed | Cost | Free tier? |
|-------|----------|-------|------|------------|
| Claude 4.5 Opus | Best for coding and writing | Slower | $$$ | Limited |
| Claude 4.5 Sonnet | All-around tasks, best balance | Fast | $$ | Yes |
| Gemini 3.0 Pro | Front-end design, large documents | Fast | $$ | Yes |
| Codex (GPT 5.1) | OpenAI coding tasks | Fast | $$ | Limited |
| GPT 5.1 | Deep research, complex reasoning | Slower | $$$ | Limited |
| GitHub Copilot | In-editor suggestions | Real-time | $10/mo | Students |

---

## Detailed breakdown

### Claude 4.5 Opus

**Strengths:**
- Best model for coding and writing by far
- Excellent code architecture decisions
- Thorough debugging—explains *why* things break
- Long context window for large codebases
- Unmatched code generation quality

**Weaknesses:**
- Slower response time
- Higher cost per query

**Best for:** All coding tasks, large projects, difficult bugs, long-form writing

---

### Claude 4.5 Sonnet

**Strengths:**
- Great balance of speed and capability
- Excellent at following instructions precisely
- Strong at explaining code clearly
- Good at iterating on feedback

**Weaknesses:**
- Less capable on very complex tasks than Opus
- Better for brainstorming than production code

**Best for:** Daily tasks, brainstorming, quick iterations

---

### Gemini 3.0 Pro

**Strengths:**
- Best for front-end design work
- Industry-leading context window for large documents
- Excellent multimodal capabilities
- Good integration with Google products

**Weaknesses:**
- Not as strong for pure coding as Claude 4.5 Opus
- May train on data unless opted out

**Best for:** Front-end design, large document analysis, multimodal projects

---

### Codex (GPT 5.1)

**Strengths:**
- Specialized for coding tasks
- Excellent at multi-file projects
- Strong debugging capabilities

**Weaknesses:**
- Less versatile for non-coding tasks
- Requires OpenAI subscription

**Best for:** All OpenAI coding work, multi-file projects

---

### GPT 5.1

**Strengths:**
- Top-tier reasoning for complex problems
- Powers the 'Deep Research' feature
- Highly steerable for specific tasks

**Weaknesses:**
- Higher cost
- Can be overly thorough on simple tasks

**Best for:** Deep research, complex reasoning, investigative work

---

### GitHub Copilot

**Strengths:**
- Integrated into your editor (VS Code, etc.)
- Real-time suggestions as you type
- Great for boilerplate code
- Affordable monthly price

**Weaknesses:**
- Less capable than chat-based AI for complex tasks
- Suggestions without explanation
- Requires code editor setup

**Best for:** Writing code when you know what you want, reducing typing

---

## Cost comparison (approximate, Dec 2025)

| Service | Pricing model | Typical monthly cost |
|---------|---------------|---------------------|
| Claude Pro | Subscription | $20/month |
| Claude API | Per token | Varies ($5-50+ based on usage) |
| ChatGPT Plus | Subscription | $20/month |
| OpenAI API | Per token | Varies |
| GitHub Copilot | Subscription | $10/month |
| Gemini Advanced | Subscription | $20/month |

---

## Which should you start with?

### Complete beginner, no budget
→ **Claude.ai free tier** or **Gemini free tier**

### Some experience, willing to pay $20/month
→ **Claude Pro** (best for coding and writing)

### Regular coding work
→ **Claude 4.5 Opus** + **GitHub Copilot** for in-editor

### Front-end design or large documents
→ **Gemini 3.0 Pro** (best context window and multimodal)

### Building production tools for newsroom
→ **Claude 4.5 Opus** for all coding tasks

---

## Tips for effective prompting

1. **Include your environment** — "I'm using Python 3.11 on Mac with pandas 2.0"

2. **Show sample data** — Paste a few rows of your actual data

3. **State your goal, not just the task** — "I need to identify trends" is better than "make a graph"

4. **Ask for chunks, not everything** — Build incrementally

5. **When stuck, explain context** — "This is for a story about X, and I'm trying to show Y"

---

*From [Center for Cooperative Media](https://centerforcooperativemedia.org) AI Tools for Newsrooms*

CHANGELOG-TEMPLATE.md

Document each vibe coding session with structured notes

# Project Name — Changelog

> Use this template to document each vibe coding session. Copy this file to your project folder and update it after each work session.

---

## [YYYY-MM-DD] Session Title

### Goal
<!-- What you set out to accomplish this session -->


### What worked
<!-- Wins, successful implementations, things that went smoothly -->
-

### What broke
<!-- Errors, problems, things that didn't work as expected -->
-
- **Error:**
- **Fix:**

### What I learned
<!-- Insights, discoveries, things to remember for next time -->
-

### Code changes
<!-- Brief description of files created/modified -->
- `filename.py` — Description of what this file does

### Next steps
<!-- Tasks for the next session -->
- [ ]
- [ ]

---

## Template usage tips

1. **Be specific about errors** — Copy the actual error message. Your future self will thank you.

2. **Note the "why" not just the "what"** — "Fixed the bug" is less useful than "Fixed the bug by adding null check because API sometimes returns empty response."

3. **Link to relevant docs** — If you found a helpful Stack Overflow answer or documentation page, paste the URL.

4. **Track time spent** — Optional, but useful for estimating similar tasks later.

5. **Include context** — Note which LLM you used, any specific prompts that worked well.

---

*Template from [Center for Cooperative Media](https://centerforcooperativemedia.org) AI Tools for Newsrooms*

LESSONS-TEMPLATE.md

General template for documenting project learnings

# Lessons learned — [Project Name]

> Use this template to document what you learned from a completed or abandoned project. This preserves institutional knowledge for future work.

**Project:** [Name]
**Date range:** [Start] – [End]
**Status:** [Completed / Abandoned / On hold]
**Author:** [Your name]

---

## Project summary

<!-- One paragraph: What was this? What problem did it solve? Who was it for? -->


---

## What worked

### Technical wins
<!-- Decisions, tools, or approaches that paid off -->
-
-

### Process wins
<!-- Workflows, habits, or practices that helped -->
-
-

---

## What didn't work

### Critical failures
<!-- Things that blocked progress or caused major problems -->
-
-

### Technical debt
<!-- Shortcuts that caused problems later -->
-
-

---

## The real problem

<!-- This is the most important section. What was *actually* needed vs. what you initially set out to build? What did you learn about the underlying problem? -->


---

## What I'd tell past me

<!-- Knowing what you know now, what advice would you give yourself at the start? -->

1.
2.
3.

---

## Recommendations

### If continuing this project
<!-- Next steps, priorities, what to fix first -->
1.
2.

### If starting fresh
<!-- What would you do differently? What would you keep the same? -->
-
-

---

## Artifacts worth keeping

<!-- Code, templates, or patterns that could be reused in future projects -->

| File/Component | Why it's useful |
|----------------|-----------------|
| | |
| | |

---

## Tools and resources

<!-- Things that helped during this project -->

- **LLM used:**
- **Key libraries:**
- **Helpful documentation:**
- **People who helped:**

---

## Questions for next time

<!-- Things you still don't understand or want to research -->

-
-

---

*Template from [Center for Cooperative Media](https://centerforcooperativemedia.org) AI Tools for Newsrooms*

LESSONS TEMPLATES

Project retrospective documents

Fill these in when you finish, abandon, or pause a project. They capture what worked, what didn't, and "the real problem" — insights that help future you (or your team) avoid repeating mistakes. Deploy: Copy to your project root as LESSONS.md

SOFTWARE_DEVELOPMENT

LESSONS-general.md General projects

# Lessons learned — [Project name]

> Template for: General projects
> Last updated: YYYY-MM-DD

## Project summary
[One paragraph: What is this? What problem does it solve? Who is it for?]

## What worked

### Technical wins
- [Decision that paid off]
- [Tool/library that worked well]
- [Architecture pattern that scaled]

### Process wins
- [Development workflow that helped]
- [Testing approach that caught bugs]
- [Documentation that saved time]

## What didn't work

### Critical failures
- [Blocker that stopped progress]
- [Assumption that proved wrong]

### Technical debt
- [Shortcut that caused problems]
- [Complexity that wasn't needed]

### External factors
- [Dependency that broke]
- [Requirement that changed]

## Key insights

### The real problem
[What was actually needed vs what you built. This is the most important section.]

### What I'd tell past me
- [Insight 1]
- [Insight 2]
- [Insight 3]

## Recommendations

### If continuing this project
1. [Most important next step]
2. [Second priority]

### If starting fresh
- [What you'd do differently]
- [What you'd keep the same]

## Artifacts worth keeping

| File/Component | Why |
|----------------|-----|
| [path] | [reason it's reusable] |

## Links & references
- [Related project or resource]
- [Documentation that helped]

---

*This is a living document. Update it when you learn something new.*

LESSONS-desktop-app.md Electron, Tauri, etc.

# Lessons learned — [Project name]

> Template for: Desktop applications (Electron, Tauri, etc.)
> Last updated: YYYY-MM-DD

## Project summary
[One paragraph describing what this app does and its primary use case]

## What worked

### Technical wins
- [Tech decision that paid off]
- [Library/API that worked well]
- [Architecture pattern that scaled]

### UX wins
- [User interaction that felt right]
- [Design decision users appreciated]
- [Accessibility improvement]

### Distribution wins
- [Installer/packaging approach]
- [Auto-update mechanism]
- [Cross-platform considerations]

## What didn't work

### Critical failures
- [Blocker that stopped core functionality]
- [Assumption that proved wrong]
- [Integration that failed]

### Technical debt
- [Shortcut that caused problems later]
- [Dependency that became a burden]
- [Code pattern that didn't scale]

### Platform issues
- [Windows-specific problem]
- [macOS-specific problem]
- [Permission/security issue]

## Key insights

### The real problem
[What users actually needed vs what you built]

### Architecture lessons
[IPC patterns, main/renderer split, state management]

### Performance lessons
[Memory usage, startup time, bundle size]

## Recommendations for future work

### If continuing this project
- [Priority 1 fix/improvement]
- [Priority 2 fix/improvement]

### If starting fresh
- [What you'd do differently]
- [Alternative architecture to consider]

### Tech stack recommendations
- [Keep: tool/library that worked]
- [Replace: tool/library to swap out]
- [Add: missing capability]

## Artifacts worth keeping

| File | Why |
|------|-----|
| `path/to/file` | Reusable pattern/logic |

## Build & distribution notes
- Dev command: `npm run dev`
- Build command: `npm run build`
- Installer output: `dist/`
- Known installer issues: [any signing, permission issues]

---

*Update this document when new insights emerge.*

LESSONS-browser-extension.md Chrome, Firefox, etc.

# Lessons learned — [Project name]

> Template for: Browser extensions (Chrome, Firefox, etc.)
> Last updated: YYYY-MM-DD

## Project summary
[One paragraph describing what this extension does]

## What worked

### Technical wins
- [Manifest V3 pattern that worked]
- [Service worker architecture decision]
- [Storage API usage]

### UX wins
- [Popup design that worked]
- [Context menu integration]
- [Keyboard shortcut]

### Distribution wins
- [Web Store submission process]
- [Review approval strategy]
- [Update deployment]

## What didn't work

### Critical failures
- [Permission that got rejected]
- [API that didn't work as expected]
- [Cross-browser compatibility issue]

### Manifest V3 pain points
- [Service worker limitation]
- [Content script restriction]
- [Background script timeout issue]

### Review/store issues
- [Rejection reason]
- [Policy violation discovered]
- [Metadata requirement missed]

## Key insights

### The real problem
[What users actually needed vs what you built]

### Permission strategy
[Minimum permissions needed, optional permissions approach]

### Cross-browser lessons
[Chrome vs Firefox vs Edge differences]

## Recommendations for future work

### If continuing this project
- [Priority 1 fix/improvement]
- [Priority 2 fix/improvement]

### If starting fresh
- [What you'd do differently]
- [Manifest V2 vs V3 considerations]

## Artifacts worth keeping

| File | Why |
|------|-----|
| `manifest.json` | Permission patterns |
| `background.js` | Service worker patterns |

## Store listing notes
- Chrome Web Store ID: [if published]
- Firefox Add-on ID: [if published]
- Key screenshots needed: [list]
- Privacy policy requirements: [notes]

---

*Update this document when new insights emerge.*

LESSONS-web-app.md React, Vue, static sites

# Lessons learned — [Project name]

> Template for: Web applications (React, Vue, Static sites, etc.)
> Last updated: YYYY-MM-DD

## Project summary
[One paragraph describing what this web app does]

## What worked

### Technical wins
- [Framework choice that paid off]
- [Build tool that worked well]
- [State management approach]

### UX/design wins
- [Design system decision]
- [Responsive approach]
- [Animation/interaction that worked]

### Deployment wins
- [Hosting solution]
- [CI/CD pipeline]
- [CDN/caching strategy]

## What didn't work

### Critical failures
- [Performance bottleneck]
- [SEO issue]
- [Accessibility gap]

### Technical debt
- [Component that got messy]
- [State management complexity]
- [CSS/styling issues]

### Infrastructure issues
- [Hosting limitation]
- [Build time problem]
- [Environment configuration pain]

## Key insights

### The real problem
[What users actually needed vs what you built]

### Performance lessons
- [Bundle size insights]
- [Loading strategy]
- [Runtime performance]

### Design system lessons
- [What should be componentized]
- [Styling approach retrospective]

## Recommendations for future work

### If continuing this project
- [Priority 1 fix/improvement]
- [Priority 2 fix/improvement]

### If starting fresh
- [Framework reconsideration]
- [Build tool alternatives]

### Tech stack recommendations
- [Keep: tool/library that worked]
- [Replace: tool/library to swap out]

## Artifacts worth keeping

| File | Why |
|------|-----|
| `components/` | Reusable UI patterns |
| `styles/` | Design tokens/theme |

## Deployment notes
- Hosting: [Firebase, Vercel, Netlify, etc.]
- Build command: `npm run build`
- Deploy command: [command or CI trigger]
- Environment variables needed: [list]

---

*Update this document when new insights emerge.*

LESSONS-data-pipeline.md Python, ETL, scraping

# Lessons learned — [Project name]

> Template for: Data pipelines & processing tools (Python, ETL, scraping, etc.)
> Last updated: YYYY-MM-DD

## Project summary
[One paragraph describing what this pipeline does and what data it processes]

## What worked

### Technical wins
- [Library that handled the job well]
- [Data storage approach]
- [Error handling strategy]

### Data quality wins
- [Validation approach that caught issues]
- [Deduplication strategy]
- [Data enrichment technique]

### Operational wins
- [Logging/monitoring approach]
- [Recovery/retry mechanism]
- [Scheduling solution]

## What didn't work

### Critical failures
- [Data source that broke]
- [Rate limiting issue]
- [Memory/performance bottleneck]

### Technical debt
- [Hardcoded assumption that broke]
- [Missing error handling]
- [Schema drift not handled]

### External dependencies
- [API that changed]
- [Service that went down]
- [Authentication issue]

## Key insights

### The real problem
[What the data actually needed vs what you built]

### Scraping/API lessons
- [Anti-bot detection encountered]
- [Rate limiting strategies]
- [Authentication patterns]

### Data storage lessons
- [Why you chose SQLite/Sheets/Postgres/etc.]
- [Schema evolution approach]
- [Backup strategy]

## Recommendations for future work

### If continuing this project
- [Priority 1 fix/improvement]
- [Priority 2 fix/improvement]

### If starting fresh
- [Architecture reconsideration]
- [Tool alternatives]

### Tech stack recommendations
- [Keep: library that worked]
- [Replace: library to swap out]
- [Add: missing capability]

## Artifacts worth keeping

| File | Why |
|------|-----|
| `processors/` | Reusable data transformations |
| `utils/` | Helper functions |

## Operational notes
- Run command: `python main.py`
- Schedule: [cron expression or manual]
- Data location: [path or service]
- Credentials needed: [list, no values]
- Recovery procedure: [steps if it fails]

## Data schema
```
[Key tables/collections and their relationships]
```

---

*Update this document when new insights emerge.*

LESSONS-mobile-app.md React Native, Flutter, etc.

# Lessons learned — [Project name]

> Template for: Mobile & cross-platform apps (React Native, Capacitor, Flutter, etc.)
> Last updated: YYYY-MM-DD

## Project summary
[One paragraph describing what this app does and target platforms]

## What worked

### Technical wins
- [Cross-platform framework choice]
- [Native module that worked well]
- [State management approach]

### UX wins
- [Navigation pattern]
- [Platform-specific adaptation]
- [Gesture/interaction that felt native]

### Distribution wins
- [App Store submission process]
- [Beta testing approach]
- [Update strategy]

## What didn't work

### Critical failures
- [Platform-specific bug]
- [Performance issue]
- [Native integration failure]

### Cross-platform pain
- [Inconsistency between iOS/Android]
- [Native module compatibility]
- [Build configuration nightmare]

### Store/distribution issues
- [Rejection reason]
- [Review process pain]
- [Signing/certificate issue]

## Key insights

### The real problem
[What users actually needed vs what you built]

### Platform lessons
- [iOS-specific learnings]
- [Android-specific learnings]
- [Web/PWA considerations]

### Performance lessons
- [Startup time optimization]
- [Memory management]
- [Battery impact]

## Recommendations for future work

### If continuing this project
- [Priority 1 fix/improvement]
- [Priority 2 fix/improvement]

### If starting fresh
- [Framework reconsideration]
- [Native vs cross-platform decision]

### Tech stack recommendations
- [Keep: tool/library that worked]
- [Replace: tool/library to swap out]

## Artifacts worth keeping

| File | Why |
|------|-----|
| `components/` | Cross-platform UI |
| `native/` | Platform bridges |

## Build & distribution notes

### iOS
- Bundle ID: [com.example.app]
- Build command: `npm run ios`
- TestFlight setup: [notes]
- App Store ID: [if published]

### Android
- Package name: [com.example.app]
- Build command: `npm run android`
- Keystore location: [path, not password]
- Play Store ID: [if published]

### Common issues
- [Build failure pattern and fix]
- [Emulator/device debugging tip]

---

*Update this document when new insights emerge.*

JOURNALISM_&_PUBLISHING

LESSONS-digital-archive.md Preservation projects

# Lessons learned — [Archive name]

> Template for: Digital archives & preservation projects
> Last updated: YYYY-MM-DD

## Project summary
[What is being archived? Whose work? What time period? What's the preservation goal?]

## Collection overview
- **Total items:** [count]
- **Date range:** [start] - [end]
- **Content types:** [articles, audio, video, images, documents]
- **Primary sources:** [websites, publications, personal files]

## What worked

### Acquisition wins
- [Scraping/crawling approach that worked]
- [API or data source that was reliable]
- [Relationship that gave access]

### Preservation wins
- [Format decisions that aged well]
- [Metadata schema that proved useful]
- [Storage solution that scaled]

### Access wins
- [Search/discovery feature users loved]
- [Interface design that worked]
- [Citation/sharing feature]

## What didn't work

### Acquisition failures
- [Source that went dark]
- [Anti-scraping measure that blocked us]
- [Content that couldn't be captured]

### Preservation issues
- [Format that degraded or became obsolete]
- [Metadata gap that caused problems]
- [Storage/backup failure]

### Access problems
- [Discoverability issue]
- [Rights/permissions blocker]
- [Performance problem at scale]

## Key insights

### The real problem
[What researchers/users actually needed vs what you built]

### Content lessons
- [What content was most valuable]
- [What was missing that people wanted]
- [Unexpected use cases]

### Sustainability lessons
- [Ongoing maintenance burden]
- [Funding/resource requirements]
- [Institutional support needs]

## Rights & permissions
- [Copyright status of materials]
- [Permissions obtained]
- [Outstanding rights issues]
- [Takedown requests received]

## Recommendations for future work

### If continuing this project
- [Priority gaps to fill]
- [Maintenance tasks]

### If starting a similar archive
- [What to prioritize]
- [What to skip]

## Artifacts worth keeping

| Component | Why |
|-----------|-----|
| [Scraper code] | [Reusable for similar sources] |
| [Metadata schema] | [Could be standard for similar projects] |

## Stakeholders & relationships
- [Subject/creator of archived work]
- [Institutional partners]
- [User communities]

## Technical notes
- Storage location: [cloud service, institutional repository]
- Backup strategy: [approach]
- Access URL: [if public]

---

*Archives are never "done." Update this as the collection evolves.*

LESSONS-event-website.md Conferences, summits

# Lessons learned — [Event name]

> Template for: Conference, summit, and event websites
> Last updated: YYYY-MM-DD

## Event overview
- **Event name:** [name]
- **Date(s):** [dates]
- **Location:** [venue/virtual]
- **Expected attendance:** [number]
- **Website launch:** [date] | **Event date:** [date]

## What worked

### Content wins
- [Messaging that resonated]
- [Speaker/session presentation that drove interest]
- [Call-to-action that converted]

### Design wins
- [Visual identity choice]
- [Mobile experience]
- [Accessibility feature]

### Technical wins
- [Registration integration]
- [Schedule display approach]
- [Performance optimization]

### Promotion wins
- [Channel that drove traffic]
- [Partnership that expanded reach]
- [Timing that worked]

## What didn't work

### Content failures
- [Information people couldn't find]
- [Confusion caused by messaging]
- [Missing content that caused support requests]

### Design issues
- [Element that confused users]
- [Branding inconsistency]
- [Responsive breakpoint problem]

### Technical problems
- [Registration friction]
- [Load time issue]
- [Integration failure]

### Promotion misses
- [Channel that underperformed]
- [Timing mistake]
- [Audience not reached]

## Key insights

### The real problem
[What attendees actually needed from the site vs what you built]

### Timeline lessons
- [What should have been ready earlier]
- [What could have waited]
- [Crunch points to avoid]

### Stakeholder lessons
- [Whose input was essential]
- [Approval bottlenecks]
- [Communication gaps]

## Content checklist for next time

### Must-have at launch
- [ ] Date, time, location
- [ ] Registration link/form
- [ ] Basic schedule/agenda
- [ ] Speaker highlights
- [ ] Venue/access info
- [ ] Contact information

### Add before event
- [ ] Full schedule with sessions
- [ ] Speaker bios and photos
- [ ] Sponsor recognition
- [ ] FAQ
- [ ] Accessibility info
- [ ] Code of conduct

### Post-event
- [ ] Recordings/slides
- [ ] Photo gallery
- [ ] Thank you messaging
- [ ] Save the date for next year

## Recommendations for future events

### If running this event again
- [What to keep]
- [What to change]

### For similar events
- [Transferable patterns]
- [Pitfalls to avoid]

## Artifacts worth keeping

| Component | Why |
|-----------|-----|
| [Design system/brand assets] | [Reusable for future years] |
| [Registration flow] | [Proven conversion] |
| [Email templates] | [Tested messaging] |

## Analytics summary
- Total unique visitors: [number]
- Registration conversion: [%]
- Top traffic sources: [list]
- Peak traffic day: [date]

---

*Update after the event with attendee feedback and final metrics.*

LESSONS-content-pipeline.md CMS, publishing workflows

# Lessons learned — [Pipeline name]

> Template for: Content management & publishing pipelines
> Last updated: YYYY-MM-DD

## Project summary
[What content flows through this pipeline? From where to where? Who are the producers and consumers?]

## Pipeline overview
```
[Source] → [Processing] → [Storage] → [Distribution] → [Audience]
```

## What worked

### Ingestion wins
- [Source integration that worked smoothly]
- [Format handling that saved time]
- [Automation that reduced manual work]

### Processing wins
- [Transformation that added value]
- [Quality check that caught issues]
- [Enrichment that improved content]

### Distribution wins
- [Channel that reached audience]
- [Format that performed well]
- [Timing/scheduling that worked]

### Editorial wins
- [Workflow that editors liked]
- [Review process that caught errors]
- [Collaboration feature that helped]

## What didn't work

### Ingestion failures
- [Source that broke or changed]
- [Format that caused problems]
- [Manual step that created bottleneck]

### Processing issues
- [Transformation that corrupted content]
- [Quality check that missed errors]
- [Step that was too slow]

### Distribution problems
- [Channel that underperformed]
- [Format that didn't render correctly]
- [Scheduling failure]

### Editorial pain
- [Workflow friction]
- [Approval bottleneck]
- [Version control nightmare]

## Key insights

### The real problem
[What content producers/consumers actually needed vs what you built]

### Volume lessons
- [What broke at scale]
- [What scaled fine]
- [Capacity planning insights]

### Quality vs speed tradeoffs
- [Where quality was sacrificed]
- [Where speed was sacrificed]
- [Right balance in retrospect]

## Content types handled

| Type | Volume | Complexity | Notes |
|------|--------|------------|-------|
| [Articles] | [/day] | [low/med/high] | [notes] |
| [Images] | [/day] | [low/med/high] | [notes] |
| [Video] | [/day] | [low/med/high] | [notes] |

## Recommendations for future work

### If continuing this pipeline
- [Bottleneck to fix]
- [Automation to add]

### If rebuilding
- [Architecture change]
- [Tool replacement]

## Artifacts worth keeping

| Component | Why |
|-----------|-----|
| [Ingestion scripts] | [Handles tricky source] |
| [Transform logic] | [Reusable patterns] |

## Integration points
- **Sources:** [CMS, feeds, APIs, manual upload]
- **Storage:** [database, cloud storage, CDN]
- **Outputs:** [website, app, social, email]

## Operational notes
- Typical throughput: [items/hour or day]
- Failure rate: [%]
- Recovery procedure: [steps]
- On-call contact: [who handles issues]

---

*Content pipelines are living systems. Update as the workflow evolves.*

LESSONS-editorial-tool.md Newsroom tools

# Lessons learned — [Tool name]

> Template for: Editorial, journalism & newsroom tools
> Last updated: YYYY-MM-DD

## Project summary
[What does this tool do? Who uses it? What editorial workflow does it support?]

## User overview
- **Primary users:** [reporters, editors, producers, etc.]
- **User count:** [number]
- **Usage frequency:** [daily, weekly, per-story]

## What worked

### Workflow wins
- [Step that got faster]
- [Error that got eliminated]
- [Collaboration that improved]

### Adoption wins
- [Feature that drove adoption]
- [Training approach that worked]
- [Champion who helped spread use]

### Integration wins
- [System it connected well with]
- [Data it surfaced usefully]
- [Export/output that fit workflow]

## What didn't work

### Workflow failures
- [Step that got harder]
- [New error introduced]
- [Workaround users invented]

### Adoption blockers
- [Why some users resisted]
- [Training gap]
- [Competing tool preference]

### Integration problems
- [System it didn't connect with]
- [Data format mismatch]
- [Authentication friction]

## Key insights

### The real problem
[What journalists actually needed vs what you built]

### Newsroom culture lessons
- [How deadline pressure affected adoption]
- [How existing habits shaped usage]
- [What editors vs reporters needed differently]

### Trust lessons
- [What made users trust the tool]
- [What made users distrust it]
- [Accuracy/reliability requirements]

## User feedback themes

### Loved
- [Quote or paraphrase]
- [Quote or paraphrase]

### Hated
- [Quote or paraphrase]
- [Quote or paraphrase]

### Requested
- [Feature request pattern]
- [Feature request pattern]

## Recommendations for future work

### If continuing this tool
- [Priority fix based on feedback]
- [Feature to add]

### If building similar tools
- [Design principle to follow]
- [Mistake to avoid]

## Artifacts worth keeping

| Component | Why |
|-----------|-----|
| [UI patterns] | [Tested with real journalists] |
| [Data models] | [Reflects editorial concepts correctly] |

## Metrics
- Daily active users: [number]
- Key action completion rate: [%]
- Time saved per task: [estimate]
- Error rate before/after: [comparison]

---

*Newsroom tools must evolve with the newsroom. Update as needs change.*

LESSONS-research-project.md Investigations, analysis

# Lessons learned — [Project name]

> Template for: Research, investigation & analysis projects
> Last updated: YYYY-MM-DD

## Project summary
[What question were you trying to answer? What was the investigation about?]

## Research overview
- **Duration:** [timeframe]
- **Team:** [who worked on it]
- **Output:** [article, report, database, tool]
- **Status:** [published, ongoing, abandoned]

## What worked

### Source wins
- [Source type that proved valuable]
- [Access obtained that was crucial]
- [FOIA/records request that succeeded]

### Method wins
- [Analysis technique that revealed insights]
- [Tool that accelerated work]
- [Collaboration approach that helped]

### Verification wins
- [Fact-check process that caught errors]
- [Corroboration method that worked]
- [Expert consultation that added credibility]

## What didn't work

### Source failures
- [Source that dried up]
- [Access denied]
- [Records request that failed/delayed]

### Method problems
- [Analysis that led nowhere]
- [Tool that wasted time]
- [Assumption that proved wrong]

### Verification gaps
- [Fact we couldn't verify]
- [Conflicting information unresolved]
- [Expert who wouldn't go on record]

## Key insights

### The real story
[What the investigation was actually about vs what you thought initially]

### Data lessons
- [What data existed vs what you expected]
- [Quality issues encountered]
- [Gaps that couldn't be filled]

### Human source lessons
- [How to approach sources for this topic]
- [What motivated sources to talk]
- [What scared sources off]

## Findings summary
- [Key finding 1]
- [Key finding 2]
- [Key finding 3]

## What we couldn't prove
- [Hypothesis that remained unconfirmed]
- [Question that stayed unanswered]

## Ethical considerations
- [Privacy decision made]
- [Harm consideration]
- [Source protection measure]

## Recommendations for future work

### If continuing this investigation
- [Lead to pursue]
- [Source to revisit]
- [Data to request]

### For similar investigations
- [Approach to replicate]
- [Mistake to avoid]
- [Tool to use]

## Artifacts worth keeping

| Component | Why |
|-----------|-----|
| [Data collection scripts] | [Could be reused for follow-up] |
| [Source database] | [Contacts for future stories] |
| [Analysis notebooks] | [Methodology documentation] |

## Source log
*(Keep detailed, consider security)*
- [Source type, not name if sensitive]
- [How contacted, response]

## Documents obtained
- [Document type, source, date obtained]
- [Storage location]

## Timeline of key events
- [Date]: [Event in the story]
- [Date]: [Event in the story]

---

*Investigations may be revisited. Keep notes thorough.*

LESSONS-publication.md Newsletters, blogs, podcasts

# Lessons learned — [Publication name]

> Template for: Newsletters, blogs, ongoing publications
> Last updated: YYYY-MM-DD

## Publication overview
- **Name:** [publication name]
- **Format:** [newsletter, blog, podcast, etc.]
- **Frequency:** [daily, weekly, etc.]
- **Audience:** [who reads it]
- **Issues published:** [count]
- **Subscribers/readers:** [count]

## What worked

### Content wins
- [Topic/format that resonated]
- [Voice/tone that connected]
- [Series or feature that performed]

### Growth wins
- [Channel that drove subscriptions]
- [Referral pattern that worked]
- [Partnership that expanded reach]

### Production wins
- [Workflow that made publishing sustainable]
- [Tool that saved time]
- [Template that maintained consistency]

### Monetization wins (if applicable)
- [Revenue stream that worked]
- [Sponsor relationship that fit]
- [Premium offering that converted]

## What didn't work

### Content failures
- [Topic that flopped]
- [Format that didn't land]
- [Experiment that confused readers]

### Growth problems
- [Channel that didn't convert]
- [Churn pattern observed]
- [Audience mismatch]

### Production pain
- [Bottleneck in workflow]
- [Burnout factor]
- [Quality/consistency tradeoff]

### Monetization misses (if applicable)
- [Revenue attempt that failed]
- [Sponsor mismatch]
- [Pricing mistake]

## Key insights

### The real value
[What readers actually came for vs what you thought you were providing]

### Voice & identity lessons
- [What made the publication distinctive]
- [What felt inauthentic]
- [Evolution of voice over time]

### Sustainability lessons
- [What made it maintainable]
- [What led to burnout]
- [Right frequency in retrospect]

## Audience insights
- **Who they are:** [demographics, psychographics]
- **Why they subscribe:** [value proposition]
- **What they share:** [most viral content]
- **What they reply to:** [engagement triggers]

## Top performing issues/posts

| Title | Date | Why it worked |
|-------|------|---------------|
| [title] | [date] | [reason] |
| [title] | [date] | [reason] |

## Recommendations for future work

### If continuing this publication
- [Content to do more of]
- [Workflow to fix]
- [Growth channel to invest in]

### If starting a similar publication
- [What to replicate]
- [What to skip]
- [Minimum viable version]

## Artifacts worth keeping

| Component | Why |
|-----------|-----|
| [Style guide] | [Defines voice] |
| [Templates] | [Speeds production] |
| [Subscriber data] | [Audience insights] |

## Platform & tools
- **Publishing platform:** [Substack, Ghost, WordPress, etc.]
- **Email service:** [if different]
- **Analytics:** [what you track]
- **Writing tools:** [what you use]

## Metrics
- Open rate: [%]
- Click rate: [%]
- Growth rate: [%/month]
- Churn rate: [%/month]

---

*Publications evolve with their audience. Update as you learn what resonates.*

CLAUDE-RULES TEMPLATES

Project memory files for Claude Code — official docs

These give Claude Code persistent context about your project. Claude reads them at the start of every conversation, so it understands your codebase, conventions, and preferences without you re-explaining. Deploy: Copy to your project root as CLAUDE.md at the start of a project.

SOFTWARE_DEVELOPMENT

CLAUDE-RULES-general.md General projects

CLAUDE-RULES-web-app.md React, Vue, Next.js

CLAUDE-RULES-desktop-app.md Electron, Tauri

CLAUDE-RULES-browser-extension.md Chrome, Firefox

CLAUDE-RULES-data-pipeline.md ETL, scraping

CLAUDE-RULES-mobile-app.md React Native, Flutter