# 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.

<!-- 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

<!-- OPENSPEC:START -->