@sprouted/create-vibes/templates/base/CONTRIBUTING.md

Create a new Vibes monorepo

# Contributing to Vibes

Thanks for wanting to contribute! Here's how to keep the good vibes flowing.

## The Vibe Test

Before contributing, ask yourself:
- Does this make things simpler?
- Is it immediately obvious what this does?
- Would a newcomer understand it?
- Does it feel natural?

## How to Contribute

### 1. Share Your Vibe
Open an issue describing what you want to add or change. Include:
- Why it would improve the vibe
- How it keeps things simple
- Example code if applicable

### 2. Code with Clarity
- Keep it obvious
- Avoid clever tricks
- Write like you're explaining to a friend
- If you need comments to explain it, simplify instead

### 3. Test the Vibe
- Does it work smoothly?
- Is the happy path clear?
- Are errors helpful?

### 4. Submit with Confidence
- Small PRs are better than large ones
- One concept per PR
- Include examples

## Code Style

### TypeScript/JavaScript
```typescript
// ✅ Good vibe - obvious and clear
export function createTodo(title: string): Todo {
  return {
    id: generateId(),
    title,
    completed: false,
    createdAt: new Date()
  };
}

// ❌ Bad vibe - unnecessarily complex
export const createTodo = (title: string): Todo => ({
  ...getDefaultTodo(),
  title,
  id: (() => generateId())(),
  createdAt: (() => new Date())()
});
```

### Go
```go
// ✅ Good vibe - straightforward
func (s *TodoService) GetTodos() ([]*Todo, error) {
    return s.repo.FindAll()
}

// ❌ Bad vibe - premature abstraction
func (s *TodoService) GetTodos() ([]*Todo, error) {
    return s.executeQuery(func() (interface{}, error) {
        return s.repo.FindAll()
    }).([]*Todo)
}
```

## Feature Development

1. **Start Simple**
   - Basic implementation first
   - Add complexity only when needed
   - Let patterns emerge naturally

2. **Keep Boundaries Clear**
   - Features are self-contained
   - No cross-feature imports
   - Clear public APIs

3. **Examples Over Documentation**
   - Show, don't tell
   - Working examples > lengthy docs
   - Keep READMEs short

## What We're Looking For

### ✅ Good Vibes
- Tools that make development smoother
- Simplifications of existing features
- Clear examples and patterns
- Helpful error messages
- Performance improvements that don't add complexity

### ❌ Not Our Vibe
- Complex abstractions
- "Enterprise" patterns
- Configuration over convention
- Features that require extensive documentation
- Premature optimization

## Review Process

1. **Vibe Check** - Does it feel right?
2. **Simplicity Review** - Could it be simpler?
3. **Integration Test** - Does it play well with everything else?
4. **Documentation** - Is it self-explanatory?

## Commit Guidelines

Use conventional commits for clear history:
- `fix:` - Bug fixes
- `feat:` - New features
- `docs:` - Documentation changes
- `chore:` - Maintenance tasks
- `test:` - Test improvements

Include issue references to automatically close issues:
- Use `fixes #123`, `closes #123`, or `resolves #123`
- Reference without closing: `related to #123` or just `#123`

Examples:
```
fix: resolve authentication error

Fixes #42

feat: add dark mode support (closes #15)

fix: resolve login and logout issues

Fixes #23, #24
```

Benefits:
- Automatically closes issues when PR is merged
- Links commits to issues for better traceability
- Makes code history easier to understand

## Getting Help

- Open a "Vibe Check" issue if something feels off
- Ask in discussions if you're unsure
- Start with a draft PR for early feedback

Remember: Perfect is the enemy of good vibes. Ship it when it feels right!