Initial commit

This commit is contained in:
Zhongwei Li
2025-11-29 18:29:20 +08:00
commit 742559fa58
14 changed files with 1131 additions and 0 deletions

View File

@@ -0,0 +1,349 @@
---
name: grey-haven-linear-workflow
description: Grey Haven's Linear issue workflow - creating well-documented issues, proper branch naming from issue IDs, commit message integration, PR linking, and status management. Use when creating issues, starting work, or managing project workflow.
---
# Grey Haven Linear Workflow
Follow Grey Haven Studio's workflow for **Linear issue management**, **Git branching**, and **pull request integration**.
## Linear Issue Management
### Issue Creation Guidelines
**Always create Linear issues BEFORE starting work** to track progress and context.
**Issue Title Format**: Specific, actionable statements
```
[OK] Good titles:
- Add magic link authentication
- Fix race condition in user repository
- Migrate organizations table to multi-tenant
[X] Bad titles (too vague):
- Auth improvements
- Fix bug
- Update dependencies
```
### Issue Templates
**Feature Issue Structure**:
```markdown
Title: Add magic link authentication
## Description
[What you're building]
## Motivation
[Why this is needed - user pain points, business value]
## Acceptance Criteria
- [ ] Specific, testable criteria
- [ ] Include multi-tenant isolation requirements
- [ ] Target >80% test coverage
## Technical Notes
- Tech stack references (better-auth, TanStack, etc.)
- Doppler environment variables needed
- Database schema changes (snake_case fields)
## Related Issues
- Blocks: GREY-XXX
- Related: GREY-YYY
Labels: feature, [component], [priority]
Estimate: X points
```
**Bug Issue Structure**:
```markdown
Title: Fix race condition in user repository
## Description
[What's broken]
## Steps to Reproduce
1. [Step-by-step]
2. [With specific inputs]
3. [Expected vs actual]
## Impact
- Frequency: X% of requests
- User experience impact
- Data corruption risk
## Proposed Solution
[How to fix it]
## Environment
- Backend: cvi-backend-template
- Database: PostgreSQL with RLS
- Doppler config: production
Labels: bug, [component], [priority]
Priority: [critical/high-priority/normal/low-priority]
```
### Labels
**Type Labels**: `feature`, `bug`, `chore`, `docs`, `refactor`, `performance`
**Component Labels**: `frontend`, `backend`, `database`, `auth`, `multi-tenant`, `testing`
**Priority Labels**: `critical`, `high-priority`, `low-priority`
### Story Point Estimates
Use Fibonacci sequence:
- **1 point**: < 1 hour (config change, simple fix)
- **2 points**: 1-2 hours (small feature, simple bug)
- **3 points**: Half day (moderate feature)
- **5 points**: 1 day (complex feature, migration)
- **8 points**: 2-3 days (large feature, major refactor)
- **13 points**: 1 week (should be broken down into smaller issues)
## Git Branching Strategy
### Branch Naming Convention
**Format**: `<issue-id>-<type>-<short-description>`
```bash
# Examples
GREY-234-feat-magic-link-auth
GREY-456-fix-user-race-condition
GREY-890-migrate-add-tenant-id
GREY-123-chore-update-dependencies
GREY-789-docs-update-api-guide
```
### Creating Branches from Linear Issues
```bash
# Always branch from latest main!
git checkout main
git pull origin main
git checkout -b GREY-234-feat-magic-link-auth
```
### Branch Protection Rules
Main branch protection:
- ✅ Require pull request before merging
- ✅ Require 1 approval
- ✅ Require status checks to pass
- ✅ Require branches to be up to date
- ✅ Require linear history (squash merges)
- ❌ Do NOT allow force pushes
- ❌ Do NOT allow deletions
## Commit Message Integration
### Format with Linear
```
<type>(<scope>): <subject>
[optional body]
[Linear issue reference]
```
**Examples**:
```bash
# Feature commit
feat(auth): add magic link authentication
Implement magic link provider using better-auth with email
verification via Resend.
- Single-use tokens with 15 minute expiry
- Tenant isolation via RLS policies
- Server functions for sending/verifying links
Closes GREY-234
# Bug fix commit
fix(repositories): prevent race condition in user creation
Add database-level unique constraint and proper IntegrityError
handling in UserRepository.
Fixes GREY-456
# Migration commit
feat(db): add tenant_id to organizations table
Add tenant_id column and RLS policies for multi-tenant isolation.
Backfill from service_id column.
Related to GREY-890
```
### Linear Keywords
Use these keywords to automatically update Linear issues:
- **Closes GREY-123**: Marks issue as Done when PR merges
- **Fixes GREY-123**: Same as Closes (for bugs)
- **Related to GREY-123**: Links issue without closing
- **Blocks GREY-123**: Indicates dependency
- **Blocked by GREY-123**: Indicates blocker
## Pull Request Integration
### PR Title Format
Include Linear ID at the end:
```
<type>(<scope>): <description> [GREY-123]
```
**Examples**:
```
feat(auth): add magic link authentication [GREY-234]
fix(repositories): prevent race condition in user creation [GREY-456]
feat(db): add tenant_id to organizations table [GREY-890]
```
### PR Description Template
```markdown
## Summary
[2-4 sentence description]. Closes GREY-XXX.
## Linear Issue
https://linear.app/grey-haven/issue/GREY-XXX/issue-title
## Motivation
[Why these changes are needed]
## Implementation Details
### Key Changes
- **Component**: [what changed]
- **Database**: [schema changes with snake_case]
- **Tests**: [test coverage with markers]
### Multi-Tenant Considerations
- tenant_id added to [tables]
- RLS policies created
- Queries filter by tenant_id
### Doppler Configuration
- Added/updated: [environment variables]
- Required in: [dev/test/staging/production]
## Testing
### Automated Tests
- [OK] Unit tests: [coverage %]
- [OK] Integration tests: [coverage %]
- [OK] E2E tests: [coverage %]
- [OK] Total coverage: >80%
### Manual Testing
Run with Doppler:
```bash
doppler run --config dev -- bun run dev
doppler run --config test -- bun test
```
## Checklist
- [ ] Code follows Grey Haven style (90 char TS, 130 char Python)
- [ ] Tests added/updated (>80% coverage)
- [ ] Multi-tenant isolation verified
- [ ] Doppler env vars documented
- [ ] Pre-commit hooks passing
- [ ] Database migrations tested (if applicable)
- [ ] Linear issue linked
```
## Linear Status Management
### Issue Lifecycle
```
Backlog → Todo → In Progress → In Review → Done
↓ ↓
Canceled Canceled
```
### Status Transitions
**Todo → In Progress**:
1. Create branch: `GREY-234-feat-magic-link-auth`
2. Linear automatically moves to "In Progress"
3. Start coding
**In Progress → In Review**:
1. Push commits to branch
2. Create PR with "Closes GREY-234" in description
3. Linear automatically moves to "In Review"
4. Request review from team
**In Review → Done**:
1. Squash and merge PR to main
2. Linear automatically closes issue (via "Closes GREY-234")
3. Delete feature branch
## Supporting Documentation
All supporting files are under 500 lines per Anthropic best practices:
- **[examples/](examples/)** - Complete workflow examples
- [feature-issue-template.md](examples/feature-issue-template.md) - Feature issue template
- [bug-issue-template.md](examples/bug-issue-template.md) - Bug issue template
- [migration-issue-template.md](examples/migration-issue-template.md) - Migration template
- [commit-message-examples.md](examples/commit-message-examples.md) - Commit message examples
- [pr-description-examples.md](examples/pr-description-examples.md) - PR description examples
- [INDEX.md](examples/INDEX.md) - Examples navigation
- **[reference/](reference/)** - Workflow references
- [labels.md](reference/labels.md) - Label definitions and usage
- [status-transitions.md](reference/status-transitions.md) - Status lifecycle details
- [branch-protection.md](reference/branch-protection.md) - Branch protection rules
- [linear-keywords.md](reference/linear-keywords.md) - Automatic issue updates
- [INDEX.md](reference/INDEX.md) - Reference navigation
- **[templates/](templates/)** - Copy-paste ready templates
- [feature-issue.md](templates/feature-issue.md) - Feature issue template
- [bug-issue.md](templates/bug-issue.md) - Bug issue template
- [pr-description.md](templates/pr-description.md) - PR description template
- **[checklists/](checklists/)** - Workflow checklists
- [issue-creation-checklist.md](checklists/issue-creation-checklist.md) - Pre-issue checklist
- [pr-checklist.md](checklists/pr-checklist.md) - Pre-PR checklist
## When to Apply This Skill
Use this skill when:
- Creating new Linear issues
- Starting work on a feature or bug
- Creating Git branches
- Writing commit messages
- Opening pull requests
- Managing issue status transitions
- Setting up Linear workflows for new team members
## Template Reference
These patterns are from Grey Haven's production workflows:
- **Linear workspace**: grey-haven team configuration
- **GitHub integration**: Automatic status updates
- **Branch naming**: Issue ID prefixed branches
## Critical Reminders
1. **Create issues BEFORE work**: Track all work in Linear
2. **Branch from main**: Always `git checkout main && git pull`
3. **Branch naming**: `GREY-XXX-<type>-<description>`
4. **Commit keywords**: Use "Closes", "Fixes", "Related to"
5. **PR title format**: Include `[GREY-XXX]` at the end
6. **Multi-tenant**: Document tenant isolation in PRs
7. **Doppler**: Document env vars in issue/PR
8. **Test coverage**: Maintain >80% coverage
9. **Linear automation**: Keywords auto-update issue status
10. **Squash merges**: Keep main branch history clean

View File

@@ -0,0 +1,82 @@
# Issue Creation Checklist
**Use before creating Linear issues.**
## Issue Content
### Title
- [ ] Title is specific and actionable
- [ ] Title starts with verb (Add, Fix, Update, etc.)
- [ ] Title describes user-facing change or technical goal
- [ ] Title is under 100 characters
### Description
- [ ] Description clearly explains what needs to be done
- [ ] Description includes "why" (motivation/user pain point)
- [ ] For bugs: steps to reproduce included
- [ ] For features: user story or use case included
- [ ] Technical implementation notes included (optional)
### Acceptance Criteria
- [ ] Acceptance criteria are specific and testable
- [ ] Each criterion starts with "User can..." or "System..."
- [ ] Multi-tenant isolation requirements specified
- [ ] Test coverage target specified (>80%)
- [ ] Performance requirements specified (if applicable)
### Technical Details
#### Multi-Tenant Considerations
- [ ] tenant_id requirements documented
- [ ] RLS policy requirements documented
- [ ] Tenant isolation testing specified
#### Database Changes (if applicable)
- [ ] Schema changes use snake_case field names
- [ ] Migration strategy documented
- [ ] Rollback plan documented
- [ ] Index requirements specified
#### Doppler Configuration
- [ ] Required environment variables listed
- [ ] Doppler environments specified (dev/test/staging/production)
- [ ] Secret rotation strategy noted (if applicable)
### Labels
- [ ] Type label assigned (feature/bug/chore/docs/refactor)
- [ ] Component label assigned (frontend/backend/database/auth)
- [ ] Priority label assigned (critical/high-priority/low-priority)
- [ ] Additional relevant labels added
### Estimate
- [ ] Story points assigned using Fibonacci sequence
- [ ] Estimate reflects complexity + uncertainty
- [ ] Issues >8 points broken into smaller issues
- [ ] Estimate discussed with team (if unclear)
### Relationships
- [ ] Related issues linked (Blocks/Blocked by)
- [ ] Parent epic linked (if part of larger feature)
- [ ] Dependencies documented
## Before Submitting
### Quality Check
- [ ] Title and description are clear to someone unfamiliar with context
- [ ] Technical jargon explained or avoided
- [ ] Links to relevant documentation included
- [ ] Screenshots/mockups attached (if applicable)
### Team Alignment
- [ ] Issue aligns with current sprint goals
- [ ] Issue priority discussed with team lead (if high-priority)
- [ ] Issue dependencies communicated to affected team members
- [ ] Issue assigned to appropriate team member (or left unassigned for triage)
## Post-Creation
### Issue Management
- [ ] Issue added to appropriate project/milestone
- [ ] Issue added to current cycle (if starting immediately)
- [ ] Issue status set correctly (Backlog/Todo)
- [ ] Team notified of new issue (if urgent)

View File

@@ -0,0 +1,120 @@
# Pull Request Checklist
**Use before opening pull requests.**
## Before Opening PR
### Code Quality
- [ ] Code follows Grey Haven style guide (90 char TS, 130 char Python)
- [ ] No commented-out code
- [ ] No console.log or print statements (use structured logging)
- [ ] No TODO comments (create Linear issues instead)
- [ ] All imports organized and unused imports removed
- [ ] Pre-commit hooks passing
### Testing
- [ ] Unit tests added for new functions/components
- [ ] Integration tests added for new features
- [ ] E2E tests added for critical user flows
- [ ] All tests passing locally with Doppler: `doppler run --config test -- bun test`
- [ ] Test coverage >80% (verify with coverage report)
- [ ] Tests use appropriate markers (@pytest.mark.unit, Vitest describe blocks)
### Multi-Tenant Compliance
- [ ] All new tables include tenant_id column (NOT NULL, indexed)
- [ ] All queries filter by tenant_id
- [ ] RLS policies created for new tables
- [ ] Tenant isolation tested with different tenant contexts
- [ ] No cross-tenant data leakage possible
### Database Changes (if applicable)
- [ ] Migration generated (Drizzle Kit or Alembic)
- [ ] Migration tested up (apply)
- [ ] Migration tested down (rollback)
- [ ] Schema uses snake_case field names (NOT camelCase)
- [ ] Indexes created for foreign keys and tenant_id
- [ ] Migration reviewed by teammate
### Doppler Configuration
- [ ] New environment variables added to Doppler
- [ ] Environment variables documented in PR description
- [ ] Environment variables added to all environments (dev/test/staging/production)
- [ ] No secrets committed to git
- [ ] .env.example updated (if applicable)
### Git & Linear
- [ ] Branch follows naming convention: GREY-XXX-type-description
- [ ] Commits follow conventional commits format
- [ ] Linear issue ID in commits (Closes GREY-XXX / Fixes GREY-XXX)
- [ ] Branch up to date with main: `git pull origin main`
## PR Content
### Title
- [ ] PR title follows format: `<type>(<scope>): <description> [GREY-XXX]`
- [ ] PR title matches issue title (or explains deviation)
- [ ] PR title is under 100 characters
### Description
- [ ] Summary section explains changes (2-4 sentences)
- [ ] "Closes GREY-XXX" keyword included
- [ ] Linear issue URL included
- [ ] Motivation section explains "why"
- [ ] Implementation details section covers key changes
### Implementation Details
- [ ] Key changes documented by component
- [ ] Database changes listed (if applicable)
- [ ] Multi-tenant considerations documented
- [ ] Doppler configuration changes documented
- [ ] Breaking changes called out (if applicable)
### Testing Section
- [ ] Automated test results documented
- [ ] Test coverage percentage included
- [ ] Manual testing steps included (if applicable)
- [ ] Doppler test command included
- [ ] Screenshots/recordings attached (if UI changes)
### Checklist
- [ ] All PR description checklist items checked
- [ ] Reviewers assigned
- [ ] Labels synced from Linear issue
## After Opening PR
### CI/CD
- [ ] GitHub Actions passing (tests, linting)
- [ ] No merge conflicts with main
- [ ] Branch protection checks passing
- [ ] Deployment preview working (if applicable)
### Review Process
- [ ] At least 1 reviewer assigned
- [ ] Responded to review comments within 24 hours
- [ ] All requested changes addressed
- [ ] Re-requested review after changes
- [ ] Approved by required reviewers
### Before Merging
- [ ] All conversations resolved
- [ ] CI/CD passing
- [ ] Branch up to date with main
- [ ] Squash merge selected (for clean history)
- [ ] Linear issue will auto-close (verified "Closes GREY-XXX" in description)
## After Merging
### Post-Merge
- [ ] Feature branch deleted
- [ ] Linear issue automatically closed (verify)
- [ ] Deployment to staging successful (if applicable)
- [ ] Smoke tests passing in staging
- [ ] Team notified of significant changes
### Deployment
- [ ] Production deployment successful
- [ ] Smoke tests passing in production
- [ ] Monitoring shows no errors (Sentry, Axiom)
- [ ] Performance metrics acceptable
- [ ] Linear issue updated with deployment notes

View File

@@ -0,0 +1,47 @@
# Linear Workflow Examples
Complete examples for Grey Haven's Linear workflow, Git branching, and PR integration.
## Available Examples
### [feature-issue-template.md](feature-issue-template.md)
Complete feature issue template with examples.
- Description and motivation
- Acceptance criteria
- Technical notes and Doppler setup
- Multi-tenant considerations
### [bug-issue-template.md](bug-issue-template.md)
Complete bug issue template with examples.
- Steps to reproduce
- Impact assessment
- Proposed solution
- Environment details
### [migration-issue-template.md](migration-issue-template.md)
Database migration issue template.
- Migration steps
- Rollback plan
- Testing strategy
- Risk assessment
### [commit-message-examples.md](commit-message-examples.md)
Commit message examples with Linear integration.
- Feature commits with "Closes"
- Bug fix commits with "Fixes"
- Migration commits with "Related to"
- Multi-commit workflows
### [pr-description-examples.md](pr-description-examples.md)
Pull request description examples.
- Feature PR with full testing details
- Bug fix PR with reproduction steps
- Migration PR with rollback plan
- Doppler configuration documentation
## Quick Reference
**Need issue template?** → [feature-issue-template.md](feature-issue-template.md), [bug-issue-template.md](bug-issue-template.md)
**Need commit examples?** → [commit-message-examples.md](commit-message-examples.md)
**Need PR template?** → [pr-description-examples.md](pr-description-examples.md)
**Need migration template?** → [migration-issue-template.md](migration-issue-template.md)

View File

@@ -0,0 +1,40 @@
# Linear Workflow Reference
Configuration and workflow references for Linear issue management and Git integration.
## Available References
### [labels.md](labels.md)
Label definitions and usage guidelines.
- Type labels (feature, bug, chore, etc.)
- Component labels (frontend, backend, database, etc.)
- Priority labels (critical, high-priority, low-priority)
- Label combinations and best practices
### [status-transitions.md](status-transitions.md)
Linear issue status lifecycle details.
- Status flow (Backlog → Todo → In Progress → In Review → Done)
- Automatic transitions via GitHub integration
- Manual status updates
- Status change best practices
### [branch-protection.md](branch-protection.md)
GitHub branch protection rules.
- Main branch protection settings
- Required status checks
- Review requirements
- Merge strategies (squash merges)
### [linear-keywords.md](linear-keywords.md)
Keywords for automatic issue updates.
- Closes/Fixes keywords
- Related to keywords
- Blocks/Blocked by keywords
- Keyword placement in commits/PRs
## Quick Reference
**Need labels?** → [labels.md](labels.md)
**Need status flow?** → [status-transitions.md](status-transitions.md)
**Need branch rules?** → [branch-protection.md](branch-protection.md)
**Need keywords?** → [linear-keywords.md](linear-keywords.md)