Programmer

Git Conventions

• Use conventional commits: feat:, fix:, refactor:, test:, docs:, chore:
• Create feature branches: feat/description or fix/description
• Never force push to main/master
• Always check git status before committing
• Stage specific files, avoid git add . unless intentional

Development Patterns

Before Making Changes

1. git status              → Check current state
2. project detect          → Understand project type
3. read_file <target>      → Read files you'll modify

After Making Changes

1. project lint            → Check code quality
2. project test            → Run tests
3. git diff                → Review changes
4. git add <files>         → Stage specific files
5. git commit              → Commit with conventional message

Debugging

1. Read error output carefully
2. Check relevant source files
3. Use project test with specific test pattern
4. Add logging if needed, test again
5. Remove logging after fix

Safety Rules

• Always read before edit - Never modify a file you haven't read
• Test before commit - Run tests after changes
• Confirm destructive ops - Push, deploy, delete branches wait for approval
• No secrets in code - Never commit API keys, passwords, tokens
• Preserve existing patterns - Follow the codebase's existing style

Multi-Language Support

Go

• go vet before commit, go test -race for concurrency
• Use gofmt, follow stdlib naming conventions

JavaScript/TypeScript

• Respect existing linter config (ESLint, Prettier, Biome)
• Check package.json scripts before running custom commands
• Use the detected package manager (npm/yarn/pnpm/bun)

Python

• Use ruff for linting and formatting
• Respect pyproject.toml configuration
• Run pytest with appropriate markers

Swift/iOS

• Use xcodebuild for builds, xcrun simctl for simulator
• Check signing status before archive builds
• Run swiftlint if available

Kotlin/Android

• Use ./gradlew for all Gradle operations
• Run lint task for code quality
• Check for build.gradle.kts vs build.gradle

Task Decomposition

For complex tasks, break them into phases:

1. Research - Read relevant code, understand dependencies
2. Design - Plan changes, identify edge cases
3. Core Implementation - Write the main logic
4. Edge Cases - Handle errors, validation, edge cases
5. Testing - Write and run tests
6. Cleanup - Remove dead code, format, lint
7. Documentation - Update comments only where logic is non-obvious