claudient 0.1.0

package/workflows/new-project-bootstrap.md

@@ -0,0 +1,173 @@
+# New Project Bootstrap Workflow
+
+How to spin up a new project with Claude Code — structured, opinionated, and ready to build on from day one.
+
+---
+
+## When to use this workflow
+- Starting a new application from scratch
+- Setting up a new service in an existing system
+- Creating a new repository for a side project or client engagement
+
+---
+
+## Step 1 — Define what you're building
+
+Before touching any code or config, answer these questions clearly.
+
+**Prompt 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.
+```
+
+Do not proceed until the scope is confirmed in writing.
+
+---
+
+## Step 2 — Choose the stack
+
+**Prompt 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.
+```
+
+Lock in the stack before writing any code. Record decisions in `docs/adr/` if they're non-obvious.
+
+---
+
+## Step 3 — Bootstrap the project structure
+
+**Prompt 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.
+```
+
+Verify it runs before continuing.
+
+---
+
+## Step 4 — Set up CLAUDE.md
+
+**Prompt 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.
+```
+
+---
+
+## Step 5 — Set up the development environment
+
+**Prompt 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)
+```
+
+---
+
+## Step 6 — Set up CI
+
+**Prompt 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.
+```
+
+Verify CI passes on the initial commit before moving to feature development.
+
+---
+
+## Step 7 — First feature planning
+
+Once the skeleton is running and CI is green:
+
+**Prompt 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.
+```
+
+See `workflows/feature-development.md`.
+
+---
+
+## Bootstrap checklist
+
+- [ ] Scope defined and confirmed in writing
+- [ ] Stack decided with documented reasoning
+- [ ] Project structure created and running ("hello world" works)
+- [ ] CLAUDE.md written and committed
+- [ ] Docker Compose / local dependencies running
+- [ ] .env.example committed with all required vars
+- [ ] Tests configured and at least one passing
+- [ ] CI pipeline green on first push
+- [ ] `docs/adr/` created with initial architectural decisions
+
+---
+
+> **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/)

package/workflows/nl/code-review.md

@@ -0,0 +1,153 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../code-review.md).
+
+# Code Review Workflow
+
+Hoe je een gestructureerde, geautomatiseerde code-review uitvoert met Claude Code voor of naast menselijke review.
+
+---
+
+## Wanneer deze workflow te gebruiken
+- Je eigen wijzigingen zelfreviewen voor pushen
+- Een PR pre-screenen voor het aanvragen van menselijke review
+- AI-gegenereerde code beoordelen voor acceptatie
+- Onboarding-review: begrijpen wat er is gewijzigd in een onbekende PR
+
+---
+
+## Stap 1 — Bereid context voor
+
+Geef Claude alles wat het nodig heeft om zinvol te beoordelen.
+
+**Vraag Claude:**
+```
+I need you to review the following changes.
+
+Project context:
+- Stack: [language, framework, key libraries]
+- Testing approach: [unit/integration, mocking policy]
+- Key conventions: [paste relevant CLAUDE.md sections]
+
+Changed files:
+[paste git diff output OR list files and ask Claude to read them]
+
+This PR: [one sentence on what it's supposed to do]
+```
+
+---
+
+## Stap 2 — Correctheidsreview
+
+**Vraag Claude:**
+```
+Review these changes for correctness only.
+
+Check:
+1. Does the code do what the PR description says it does?
+2. Are there edge cases not handled? (null inputs, empty collections, concurrent access, large inputs)
+3. Are there off-by-one errors, wrong comparisons, or logic inversions?
+4. Are error paths handled — can this panic, throw, or silently fail?
+5. Are there race conditions if this code runs concurrently?
+
+Format: [FILE:LINE] — [issue description] — [suggested fix]
+Only report real issues. Do not nitpick style.
+```
+
+---
+
+## Stap 3 — Beveiligingsreview
+
+**Vraag Claude:**
+```
+Review these changes for security issues.
+
+Check:
+1. Is any user input used in SQL, shell commands, file paths, or HTML without sanitization?
+2. Are there missing authentication or authorization checks?
+3. Are secrets, tokens, or credentials exposed in logs, errors, or responses?
+4. Are there insecure direct object references (IDOR)?
+5. Are there missing rate limits on sensitive endpoints?
+
+Severity: CRITICAL / HIGH / MEDIUM / LOW
+Format: [SEVERITY] [FILE:LINE] — [vulnerability] — [fix]
+```
+
+---
+
+## Stap 4 — Testdekking controleren
+
+**Vraag Claude:**
+```
+Review the test coverage for these changes.
+
+Check:
+1. Is every new function or method covered by at least one test?
+2. Is the happy path tested?
+3. Is at least one error/edge case tested?
+4. Do the tests actually assert meaningful behavior, or just that the function runs?
+5. Are there behaviors changed by this PR that existing tests don't cover?
+
+List: [what is tested] and [what is missing]
+```
+
+---
+
+## Stap 5 — Onderhoudbaarheidsreview
+
+**Vraag Claude:**
+```
+Review these changes for maintainability.
+
+Check:
+1. Will a developer unfamiliar with this code understand it in 6 months?
+2. Are function names and variable names clear and accurate?
+3. Is there duplicated logic that should be extracted?
+4. Are there magic numbers or strings that should be named constants?
+5. Does this introduce unnecessary coupling between modules?
+
+Only flag real maintainability issues — not style preferences.
+```
+
+---
+
+## Stap 6 — Consolideer bevindingen
+
+**Vraag Claude:**
+```
+Consolidate all findings from the review into a final report.
+
+Format:
+## CRITICAL (must fix before merge)
+[list]
+
+## HIGH (strongly recommended)
+[list]
+
+## SUGGESTED (worth doing)
+[list]
+
+## NITPICK (optional)
+[list]
+
+## VERDICT
+[ ] Approved — no blockers
+[ ] Approved with suggestions — merge after addressing CRITICAL
+[ ] Changes requested — must address before merge
+```
+
+---
+
+## De Code Reviewer agent gebruiken
+
+Voor grotere PR's, delegeer naar de Code Reviewer agent in plaats van inline te draaien:
+
+```
+Spawn a Code Reviewer agent (Sonnet 4.6) to review [list of files].
+Give it the project context from CLAUDE.md and the PR description.
+Have it return a structured CRITICAL/SUGGESTED/NITPICK report.
+```
+
+Zie `agents/core/code-reviewer.md` voor de volledige agentdefinitie.
+
+---
+
+> **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/debugging-session.md

@@ -0,0 +1,146 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../debugging-session.md).
+
+# Debugging Session Workflow
+
+Systematische workflow voor het diagnosticeren en oplossen van bugs met Claude Code — zonder symptomen na te jagen.
+
+---
+
+## Wanneer deze workflow te gebruiken
+- Een bug die niet direct duidelijk is bij het lezen van de code
+- Een falende test waarbij de oorzaak niet duidelijk is
+- Een productiefout die je lokaal niet kunt reproduceren
+- Intermitterende fouten
+
+---
+
+## Stap 1 — Bouw eerst een feedbacklus
+
+Maak een manier om de bug betrouwbaar te reproduceren voor je onderzoekt. Sla deze stap niet over.
+
+**Vraag Claude:**
+```
+I have a bug: [describe the symptom exactly — error message, unexpected behavior, what you expected]
+
+Before we investigate, help me build a reliable way to reproduce it.
+
+Options to consider:
+- A failing test that captures the bug
+- A curl command or script that triggers it
+- A minimal code snippet that demonstrates it
+- Steps to reproduce via the UI
+
+Which is most appropriate here, and write it now.
+```
+
+**Ga niet door totdat je een betrouwbare reproductie hebt.** Debuggen zonder reproductie is raden.
+
+---
+
+## Stap 2 — Isoleer de blaststraal
+
+Begrijp waar de bug mogelijk kan leven voor je code leest.
+
+**Vraag Claude:**
+```
+Here is the reproduction: [paste the reproduction from Step 1]
+
+Without looking at code yet, answer:
+1. What is the earliest point in the call stack where this could go wrong?
+2. What external systems are involved (DB, cache, third-party API, queue)?
+3. What changed recently that could have introduced this? (check git log)
+4. What is the smallest unit of code that, if wrong, would cause this symptom?
+
+List the files most likely to contain the bug, ranked by probability.
+```
+
+---
+
+## Stap 3 — Genereer hypothesen
+
+**Vraag Claude:**
+```
+Based on the reproduction and the candidate files, generate 3–5 falsifiable hypotheses.
+
+For each hypothesis:
+- State it as a specific claim: "The bug occurs because [X] when [Y]"
+- Describe how to test it: what would we observe if this hypothesis is true?
+- Describe how to disprove it: what would we observe if it's false?
+
+Do not start testing yet. List all hypotheses first.
+```
+
+Bekijk de hypothesen. Voeg toe welke je zelf mist die Claude miste. Rangschik ze op waarschijnlijkheid.
+
+---
+
+## Stap 4 — Test hypothesen, hoogste waarschijnlijkheid eerst
+
+**Voor elke hypothese:**
+```
+Test hypothesis [N]: "[paste the hypothesis]"
+
+Add the minimal instrumentation needed to confirm or rule this out:
+- A log statement at the right point
+- A debug assertion
+- A targeted test with a specific input
+
+Do not add instrumentation for other hypotheses yet.
+```
+
+Na elke test:
+- Als bevestigd: ga naar Stap 5
+- Als uitgesloten: ga naar de volgende hypothese
+- Als niet-concludent: verfijn de hypothese en hertest
+
+---
+
+## Stap 5 — Repareer en verifieer
+
+Zodra de hoofdoorzaak is bevestigd:
+
+**Vraag Claude:**
+```
+Root cause confirmed: [describe what you found]
+
+Now:
+1. Apply the minimal fix — change only what's needed to fix this specific bug
+2. Do not refactor surrounding code
+3. Update the reproduction from Step 1 to be a regression test
+4. Run the full test suite — confirm nothing else broke
+
+Explain in one sentence why this fix works.
+```
+
+---
+
+## Stap 6 — Postmortem (voor ernstige bugs)
+
+Voor bugs die gebruikersinvloed hadden, dataverlies veroorzaakten, of meer dan 2 uur duurden om te vinden:
+
+**Vraag Claude:**
+```
+Write a brief post-mortem for this bug:
+
+1. What was the bug? (one sentence)
+2. What was the root cause?
+3. How long did it take to find and why?
+4. What would have caught this earlier? (missing test, missing monitoring, code review gap)
+5. What should we add/change to prevent this class of bug?
+
+Keep it under 200 words. No blame, no fluff.
+```
+
+---
+
+## Te vermijden antipatronen
+
+- **Het symptoom repareren, niet de oorzaak** — als je niet begrijpt waarom, heb je het niet gerepareerd
+- **Meerdere dingen tegelijk wijzigen** — je weet niet welke wijziging het heeft gerepareerd
+- **Debuggen zonder reproductie** — je raadt
+- **Instrumentatie overal toevoegen** — richt je op specifieke hypothesen
+- **De regressietest overslaan** — de bug komt terug
+
+---
+
+> **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/feature-development.md

@@ -0,0 +1,155 @@
+> 🇳🇱 Dit is de Nederlandse vertaling. [Engelse versie](../feature-development.md).
+
+# Feature Development Workflow
+
+End-to-end workflow voor het nemen van een feature van idee tot samengevoegde PR met Claude Code.
+
+---
+
+## Wanneer deze workflow te gebruiken
+- Een nieuwe feature bouwen die meer dan één bestand aanraakt
+- Een spec of ticket implementeren dat opgesplitst moet worden voor het coderen
+- Elke feature waarbij je een gestructureerd, beoordeelbaar proces wilt
+
+---
+
+## Stap 1 — Definieer en valideer reikwijdte
+
+Stel exact vast wat je bouwt voordat je code schrijft.
+
+**Vraag Claude:**
+```
+I need to build: [describe the feature in one paragraph]
+
+Read the relevant files first:
+- [list key files: routes, models, services]
+- CLAUDE.md and CONTEXT.md if present
+
+Then tell me:
+1. What files will need to change?
+2. What new files will be created?
+3. What are the edge cases I should handle?
+4. What decisions do I need to make before we start?
+5. Are there any risks or dependencies I'm missing?
+
+Do not write code yet.
+```
+
+**Waar op te letten in het antwoord:**
+- Bestanden die je niet had overwogen
+- Randgevallen die bugs zouden veroorzaken als ze worden gemist
+- Beslissingen die in CLAUDE.md moeten zodra ze zijn genomen
+
+---
+
+## Stap 2 — Plan de implementatie
+
+Zodra de reikwijdte duidelijk is, krijg je een gesequentieerd plan.
+
+**Vraag Claude:**
+```
+Based on the scope we just defined, create a numbered implementation plan.
+
+Each step must be:
+- A concrete, bounded action (not "implement auth" — "add JWT validation middleware to src/middleware/auth.ts")
+- Completable in a single session
+- Independently testable
+
+Include which files change in each step. Note dependencies between steps.
+```
+
+Bekijk het plan. Als een stap te groot is, vraag Claude om het verder op te splitsen. Vergrendel het plan voor je code aanraakt.
+
+---
+
+## Stap 3 — Implementeer stap voor stap
+
+Voer één planstap tegelijk uit. Sla niet vooruit.
+
+**Voor elke stap:**
+```
+Implement step [N]: [paste the step description]
+
+Rules:
+- Only change what's needed for this step
+- Write or update tests for this step's behavior
+- Do not refactor code outside the scope of this step
+- Tell me when this step is complete and what to verify
+```
+
+**Na elke stap:**
+- Voer tests uit: bevestig groen voor de volgende stap
+- Bekijk de diff zelf: is dit wat je bedoelde?
+- Als een stap nieuwe complexiteit onthult, werk het plan bij voor te doorgaan
+
+---
+
+## Stap 4 — Integratiecontrole
+
+Zodra alle stappen zijn voltooid, verifieer dat de volledige feature end-to-end werkt.
+
+**Vraag Claude:**
+```
+All implementation steps are complete. Now:
+
+1. Run the full test suite — report any failures
+2. Check that all edge cases from Step 1 are handled — list each one and confirm
+3. Check for any TODOs or incomplete error handling introduced during implementation
+4. Verify the feature works with [specific test scenario relevant to this feature]
+```
+
+Los eventuele gevonden problemen op voor je doorgaat.
+
+---
+
+## Stap 5 — Zelfreview
+
+Bekijk je eigen wijzigingen voor het aanmaken van een PR.
+
+**Vraag Claude:**
+```
+Review the changes on this branch against main.
+
+Focus on:
+1. CRITICAL issues (bugs, security, data loss risks)
+2. Missing tests for changed behavior
+3. Convention violations vs this project's CLAUDE.md
+4. Anything that would confuse a reader in 6 months
+
+Format: CRITICAL / SUGGESTED / NITPICK
+```
+
+Los alle CRITICAL-problemen op. Gebruik oordeel voor SUGGESTED-items.
+
+---
+
+## Stap 6 — PR-beschrijving
+
+**Vraag Claude:**
+```
+Write a PR description for these changes.
+
+Include:
+- What this PR does (one paragraph)
+- Why it's needed (the problem it solves)
+- How to test it (specific steps a reviewer can follow)
+- Any decisions made and why (reference CLAUDE.md or ADRs if relevant)
+- Screenshots or output if applicable
+
+Do not include a list of files changed — the diff covers that.
+```
+
+---
+
+## Checklist voor samenvoegen
+
+- [ ] Alle tests slagen
+- [ ] Zelfreview voltooid, geen CRITICAL-problemen
+- [ ] Randgevallen uit Stap 1 zijn allemaal afgehandeld
+- [ ] PR-beschrijving geschreven
+- [ ] CLAUDE.md bijgewerkt als nieuwe beslissingen zijn genomen
+- [ ] CONTEXT.md bijgewerkt als nieuwe domaintermen zijn geïntroduceerd
+
+---
+
+> **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/)