From b1c2ca8732d9df7cfa6a798d9d4d0a15e0427c34 Mon Sep 17 00:00:00 2001
From: Markus Graf <markus.graf@swisspost-cybersecurity.ch>
Date: Mon, 27 Oct 2025 10:32:07 +0100
Subject: [PATCH] Memorize the git workflow

---
 CLAUDE.md | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/CLAUDE.md b/CLAUDE.md
index 0669699..7fbb743 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -15,4 +15,52 @@ Use `@/openspec/AGENTS.md` to learn:
 
 Keep this managed block so 'openspec update' can refresh the instructions.
 
-<!-- OPENSPEC:END -->
\ No newline at end of file
+<!-- OPENSPEC:END -->
+
+# Git Workflow
+
+## Branching Strategy
+
+**IMPORTANT:** This project uses feature branch workflow for all changes.
+
+### All Future Changes
+When the user requests a new feature, change, or proposal:
+
+1. **Create a feature branch** before starting any work:
+   ```bash
+   git checkout -b feature/descriptive-name
+   ```
+
+2. **Work on the feature branch** during:
+   - OpenSpec proposal creation
+   - Design and planning
+   - Implementation
+   - Testing
+
+3. **Commit regularly** with conventional commit messages:
+   - `feat:` for new features
+   - `fix:` for bug fixes
+   - `docs:` for documentation
+   - `refactor:` for code refactoring
+   - `test:` for tests
+
+4. **Only merge to main** after user approval:
+   - User reviews the changes
+   - User explicitly approves
+   - Then merge or create PR
+
+### Branch Naming Convention
+- Features: `feature/short-description`
+- Fixes: `fix/issue-description`
+- Docs: `docs/what-changed`
+- Examples:
+  - `feature/add-blog-section`
+  - `feature/cv-page`
+  - `fix/mobile-navigation`
+  - `docs/update-readme`
+
+### Main Branch Protection
+- `main` branch represents stable, reviewed code
+- Never commit directly to `main` (except initial setup)
+- All changes go through feature branches
+- Keeps history clean and reviewable
\ No newline at end of file