markusgraf_ch/CLAUDE.md

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:

   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

OpenSpec Instructions

These instructions are for AI assistants working in this project.

Always open @/openspec/AGENTS.md when the request:

• Mentions planning or proposals (words like proposal, spec, change, plan)
• Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
• Sounds ambiguous and you need the authoritative spec before coding

Use @/openspec/AGENTS.md to learn:

• How to create and apply change proposals
• Spec format and conventions
• Project structure and guidelines

Keep this managed block so 'openspec update' can refresh the instructions.