claudient 0.1.0

package/workflows/nl/new-project-bootstrap.md

@@ -0,0 +1,175 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../new-project-bootstrap.md).
+
+# New Project Bootstrap Workflow
+
+Hoe je een nieuw project opzet met Claude Code — gestructureerd, opinieus en klaar om op te bouwen vanaf dag één.
+
+---
+
+## Wanneer deze workflow te gebruiken
+- Een nieuwe applicatie van scratch starten
+- Een nieuwe service opzetten in een bestaand systeem
+- Een nieuwe repository aanmaken voor een zijproject of klantbetrokkenheid
+
+---
+
+## Stap 1 — Definieer wat je bouwt
+
+Beantwoord deze vragen duidelijk voor je code of configuratie aanraakt.
+
+**Vraag Claude:**
+```
+I am starting a new project. Help me define it clearly before we write any code.
+
+What I want to build: [describe in 2–3 sentences]
+
+Ask me the following questions one at a time and wait for my answer before asking the next:
+1. Who are the users and what is the primary thing they do?
+2. What is the expected scale at launch? (users, requests/sec, data volume)
+3. What are the hard constraints? (budget, timeline, team size, existing tech stack)
+4. What does "done" look like for v1?
+5. What is explicitly out of scope for v1?
+
+After I answer all five, summarize what we're building and confirm with me before proceeding.
+```
+
+Ga niet door totdat de reikwijdte schriftelijk is bevestigd.
+
+---
+
+## Stap 2 — Kies de stack
+
+**Vraag Claude:**
+```
+Based on what we're building:
+- [paste summary from Step 1]
+
+Recommend a specific stack. For each component (backend, frontend, database, auth, deployment), recommend:
+- Your recommended choice and why it fits our constraints
+- What we'd be giving up vs the next-best alternative
+- No more than 2 options per component — I need a decision, not a menu
+
+Be opinionated. I will push back if I disagree.
+```
+
+Vergrendel de stack voor je code schrijft. Registreer beslissingen in `docs/adr/` als ze niet vanzelfsprekend zijn.
+
+---
+
+## Stap 3 — Bootstrap de projectstructuur
+
+**Vraag Claude:**
+```
+Set up the initial project structure for: [stack from Step 2]
+
+Create:
+1. The directory structure (show as a tree before creating anything)
+2. Package/dependency files with pinned versions
+3. Configuration files (TypeScript, ESLint, Prettier, etc.)
+4. .gitignore appropriate for this stack
+5. A minimal working "hello world" that proves the stack runs
+
+Do not add features yet. The goal is a running skeleton.
+```
+
+Verifieer dat het draait voor je doorgaat.
+
+---
+
+## Stap 4 — Stel CLAUDE.md in
+
+**Vraag Claude:**
+```
+Create a CLAUDE.md for this project.
+
+Include:
+1. What this project is (one paragraph)
+2. Stack summary (language, framework, key libraries, DB)
+3. Directory structure with purpose of each directory
+4. Coding conventions specific to this stack
+5. Commands to run (dev server, tests, build, lint)
+6. Decisions already made (from Steps 1–3) that should not be revisited
+7. What NOT to do in this project
+
+Make it dense and useful — not a tutorial. A senior developer should be able to start contributing after reading it.
+```
+
+---
+
+## Stap 5 — Stel de ontwikkelomgeving in
+
+**Vraag Claude:**
+```
+Set up the development environment:
+
+1. Docker Compose file for local dependencies (database, cache, queues)
+2. Environment variable template (.env.example with all required vars, no real values)
+3. Database migrations setup (initial schema if applicable)
+4. Test setup (test runner config, example test, CI-ready)
+5. A Makefile or scripts/ directory with common commands:
+   - make dev (start local environment)
+   - make test (run tests)
+   - make build (production build)
+   - make lint (lint and format check)
+```
+
+---
+
+## Stap 6 — Stel CI in
+
+**Vraag Claude:**
+```
+Set up a GitHub Actions CI pipeline:
+
+On every PR:
+- Install dependencies (with cache)
+- Run lint
+- Run tests
+- Build (if applicable)
+
+Use the github-actions skill for best practices:
+- Pin action versions
+- Explicit permissions
+- Dependency caching
+- Fail fast on test failures
+
+The pipeline must pass on the current skeleton before we add features.
+```
+
+Verifieer dat CI slaagt op de initiële commit voor je naar featureontwikkeling gaat.
+
+---
+
+## Stap 7 — Eerste feature-planning
+
+Zodra het skelet draait en CI groen is:
+
+**Vraag Claude:**
+```
+The project is bootstrapped. Now plan the first feature:
+
+Feature: [describe the first user-facing capability]
+
+Use the feature-development workflow to plan and implement it.
+Start with Step 1 of that workflow.
+```
+
+Zie `workflows/feature-development.md`.
+
+---
+
+## Bootstrap-checklist
+
+- [ ] Reikwijdte gedefinieerd en schriftelijk bevestigd
+- [ ] Stack besloten met gedocumenteerde redenering
+- [ ] Projectstructuur aangemaakt en draaiend ("hello world" werkt)
+- [ ] CLAUDE.md geschreven en gecommit
+- [ ] Docker Compose / lokale afhankelijkheden draaien
+- [ ] .env.example gecommit met alle vereiste variabelen
+- [ ] Tests geconfigureerd en minimaal één slaagt
+- [ ] CI-pipeline groen op eerste push
+- [ ] `docs/adr/` aangemaakt met initiële architectuurbeslissingen
+
+---
+
+> **Werk met ons:** Claudient wordt ondersteund door [Uitbreiden](https://uitbreiden.com/) — we bouwen AI-producten en B2B-oplossingen met ontwikkelaarsgemeenschappen. [uitbreiden.com](https://uitbreiden.com/)

package/workflows/nl/refactor-safely.md

@@ -0,0 +1,150 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../refactor-safely.md).
+
+# Refactor Safely Workflow
+
+Hoe je code refactort met Claude Code zonder gedrag te breken — met tests als veiligheidsnet gedurende het hele proces.
+
+---
+
+## Wanneer deze workflow te gebruiken
+- Functies extraheren uit een grote methode
+- Modules hernoemen en reorganiseren
+- Een patroon vervangen door een beter patroon over meerdere bestanden
+- Duplicatie verminderen over de codebase
+- De structuur van een module verbeteren zonder het externe gedrag te wijzigen
+
+---
+
+## De gouden regel
+
+**Refactor en wijzig nooit gedrag in dezelfde commit.** Een refactor behoudt extern gedrag. Als tests breken, heb je ofwel gedrag gewijzigd of de tests testten implementatiedetails (ook een probleem).
+
+---
+
+## Stap 1 — Stel een testbasislijn vast
+
+Bevestig dat je adequate testdekking hebt voor je iets wijzigt.
+
+**Vraag Claude:**
+```
+I want to refactor: [describe what you're refactoring and why]
+
+First, assess the current test coverage:
+1. Read the relevant files: [list files]
+2. What behaviors are currently tested?
+3. What behaviors are NOT tested that could break during refactoring?
+4. Write any missing tests now, before we touch production code
+
+Do not change production code yet. Tests only.
+```
+
+**Commit de testtoevoegingen voor de refactoring.** Dit maakt duidelijk welke tests bestonden voor vs. zijn toegevoegd als onderdeel van de refactor.
+
+---
+
+## Stap 2 — Definieer de refactorreikwijdte
+
+**Vraag Claude:**
+```
+Here is what I want to refactor: [describe the goal]
+
+Read the relevant files: [list files]
+
+Define the scope:
+1. What will change structurally? (function signatures, file locations, module boundaries)
+2. What will NOT change? (external behavior, API contracts, database schema)
+3. What are the riskiest parts of this refactor?
+4. What is the smallest first step that makes progress without risk?
+
+Do not start the refactor yet.
+```
+
+---
+
+## Stap 3 — Refactor in kleine, testbare stappen
+
+Splits de refactoring op in stappen die klein genoeg zijn dat tests elk kunnen verifiëren.
+
+**Voor elke stap:**
+```
+Refactor step [N]: [describe the specific structural change]
+
+Rules:
+- Change only what's needed for this step
+- Do not change any behavior
+- After this change, all existing tests must still pass
+- Tell me what to verify after this step
+```
+
+**Na elke stap:**
+```bash
+# Voer tests uit — moeten groen zijn voor volgende stap
+npm test  # of pytest, go test, etc.
+```
+
+Als tests mislukken na een pure structuurwijziging: stop, begrijp waarom, herstel voor doorgaan. Een falende test na een refactoring betekent ofwel dat de refactoring gedrag heeft gewijzigd of dat de test implementatie testte (beide zijn problemen om nu op te lossen).
+
+---
+
+## Stap 4 — Verifieer dat extern gedrag ongewijzigd is
+
+Na alle stappen:
+
+**Vraag Claude:**
+```
+The refactor is structurally complete. Verify that external behavior is unchanged:
+
+1. Run the full test suite
+2. Check that all public APIs/interfaces are identical to before (same inputs, same outputs)
+3. Check that database queries produce identical results
+4. Check that error cases still produce the same errors
+5. If there are integration tests or end-to-end tests, run them
+
+Report any behavioral differences — even small ones.
+```
+
+---
+
+## Stap 5 — Ruim op
+
+**Vraag Claude:**
+```
+Before committing, clean up:
+
+1. Remove any debugging code or temporary comments added during refactoring
+2. Remove any dead code that the refactor made unreachable
+3. Update any documentation or comments that referenced the old structure
+4. Check that import paths are clean (no unused imports)
+
+Do not introduce new logic in this step.
+```
+
+---
+
+## Stap 6 — Commit met een duidelijk bericht
+
+Structureer de refactor-commit(s) om een duidelijk verhaal te vertellen:
+
+```
+refactor: extract payment processing into PaymentService
+
+Moves payment logic out of OrderController into a dedicated service.
+No behavior change — all existing tests pass.
+Motivation: OrderController was 600 lines; this makes both units testable in isolation.
+```
+
+Meng een refactorcommit nooit met een feature- of bugfix-commit. Houd ze gescheiden.
+
+---
+
+## Refactoringantipatronen
+
+- **"Terwijl ik hier toch ben..."** — een refactoring en een feature tegelijk doen. Stop. Voltooi de refactoring eerst.
+- **Refactoring zonder tests** — je breekt iets en weet het niet
+- **Big-bang refactoring** — alles tegelijk wijzigen. Doe het stapsgewijs.
+- **Hernoemen als laatste stap** — hernoem eerst (mechanisch, laag risico), dan herstructureer
+- **De basislijn overslaan** — aannemen dat tests adequaat zijn zonder het te controleren
+
+---
+
+> **Werk met ons:** Claudient wordt ondersteund door [Uitbreiden](https://uitbreiden.com/) — we bouwen AI-producten en B2B-oplossingen met ontwikkelaarsgemeenschappen. [uitbreiden.com](https://uitbreiden.com/)

package/workflows/refactor-safely.md

@@ -0,0 +1,148 @@
+# Refactor Safely Workflow
+
+How to refactor code with Claude Code without breaking behavior — using tests as a safety net throughout.
+
+---
+
+## When to use this workflow
+- Extracting functions from a large method
+- Renaming and reorganizing modules
+- Replacing a pattern with a better one across multiple files
+- Reducing duplication across the codebase
+- Improving a module's structure without changing its external behavior
+
+---
+
+## The golden rule
+
+**Never refactor and change behavior in the same commit.** A refactor preserves external behavior. If tests break, you either changed behavior or the tests were testing implementation details (also a problem).
+
+---
+
+## Step 1 — Establish a test baseline
+
+Before changing anything, confirm you have adequate test coverage.
+
+**Prompt Claude:**
+```
+I want to refactor: [describe what you're refactoring and why]
+
+First, assess the current test coverage:
+1. Read the relevant files: [list files]
+2. What behaviors are currently tested?
+3. What behaviors are NOT tested that could break during refactoring?
+4. Write any missing tests now, before we touch production code
+
+Do not change production code yet. Tests only.
+```
+
+**Commit the test additions before refactoring.** This makes it clear which tests existed before vs. were added as part of the refactor.
+
+---
+
+## Step 2 — Define the refactor scope
+
+**Prompt Claude:**
+```
+Here is what I want to refactor: [describe the goal]
+
+Read the relevant files: [list files]
+
+Define the scope:
+1. What will change structurally? (function signatures, file locations, module boundaries)
+2. What will NOT change? (external behavior, API contracts, database schema)
+3. What are the riskiest parts of this refactor?
+4. What is the smallest first step that makes progress without risk?
+
+Do not start the refactor yet.
+```
+
+---
+
+## Step 3 — Refactor in small, testable increments
+
+Break the refactor into steps small enough that tests can verify each one.
+
+**For each increment:**
+```
+Refactor step [N]: [describe the specific structural change]
+
+Rules:
+- Change only what's needed for this step
+- Do not change any behavior
+- After this change, all existing tests must still pass
+- Tell me what to verify after this step
+```
+
+**After each increment:**
+```bash
+# Run tests — must be green before next step
+npm test  # or pytest, go test, etc.
+```
+
+If tests fail after a pure structural change: stop, understand why, fix before continuing. A failing test after a refactor means either the refactor changed behavior or the test was testing implementation (both are problems to fix now).
+
+---
+
+## Step 4 — Verify external behavior unchanged
+
+After all increments:
+
+**Prompt Claude:**
+```
+The refactor is structurally complete. Verify that external behavior is unchanged:
+
+1. Run the full test suite
+2. Check that all public APIs/interfaces are identical to before (same inputs, same outputs)
+3. Check that database queries produce identical results
+4. Check that error cases still produce the same errors
+5. If there are integration tests or end-to-end tests, run them
+
+Report any behavioral differences — even small ones.
+```
+
+---
+
+## Step 5 — Clean up
+
+**Prompt Claude:**
+```
+Before committing, clean up:
+
+1. Remove any debugging code or temporary comments added during refactoring
+2. Remove any dead code that the refactor made unreachable
+3. Update any documentation or comments that referenced the old structure
+4. Check that import paths are clean (no unused imports)
+
+Do not introduce new logic in this step.
+```
+
+---
+
+## Step 6 — Commit with a clear message
+
+Structure the refactor commit(s) to tell a clear story:
+
+```
+refactor: extract payment processing into PaymentService
+
+Moves payment logic out of OrderController into a dedicated service.
+No behavior change — all existing tests pass.
+Motivation: OrderController was 600 lines; this makes both units testable in isolation.
+```
+
+Never mix a refactor commit with a feature or bug fix commit. Keep them separate.
+
+---
+
+## Refactoring anti-patterns
+
+- **"While I'm in here..."** — doing a refactor and a feature at the same time. Stop. Finish the refactor first.
+- **Refactoring without tests** — you will break something and not know it
+- **Big-bang refactor** — changing everything at once. Do it incrementally.
+- **Renaming as the last step** — rename first (mechanical, low risk), then restructure
+- **Skipping the baseline** — assuming tests are adequate without checking first
+
+---
+
+> **Work with us:** Claudient is backed by [Uitbreiden](https://uitbreiden.com/) — we build AI products and B2B solutions with developer communities. [uitbreiden.com](https://uitbreiden.com/)