Initial commit

2025-11-30 09:07:57 +08:00
commit d45452f0f6
14 changed files with 4068 additions and 0 deletions
--- a/skills/project-field-management/SKILL.md
+++ b/skills/project-field-management/SKILL.md
@@ -0,0 +1,650 @@
+---
+name: project-field-management
+description: Comprehensive guide to GitHub Projects field types, configuration, and management strategies. Use when setting up fields, troubleshooting field issues, or optimizing field structures.
+---
+
+# GitHub Projects Field Management
+
+This skill provides deep knowledge of GitHub Projects V2 custom fields, their types, capabilities, limitations, and best practices.
+
+## Field Types Overview
+
+### Single Select
+
+**Purpose**: Dropdown with one choice from predefined options
+
+**Use cases**:
+- Status (Backlog, Todo, In Progress, Done)
+- Priority (P0, P1, P2, P3)
+- Component (Frontend, Backend, DevOps)
+- Team (Team A, Team B, Team C)
+- Environment (Dev, Staging, Prod)
+
+**Characteristics**:
+- Mutually exclusive choices
+- Enables grouping in board views
+- Filterable and searchable
+- Color-coded options possible (via UI)
+- Maximum ~50 options recommended
+
+**CLI Creation**:
+```bash
+# IMPORTANT: Status field is built-in and already exists in new projects!
+# Do NOT create a Status field - it's already there.
+
+# For other SINGLE_SELECT fields, options are REQUIRED at creation:
+gh project field-create <project-id> --owner "@me" \
+  --data-type SINGLE_SELECT \
+  --name "Priority" \
+  --single-select-options "P0 (Critical),P1 (High),P2 (Medium),P3 (Low)"
+```
+
+**CRITICAL**:
+- Options MUST be provided at creation time using `--single-select-options`
+- Options cannot be added later via CLI
+- Format: Comma-separated, no spaces after commas
+- Status field is a built-in default field - never create it
+
+**Best Practices**:
+- Keep options list short (5-10 ideal)
+- Use clear, unambiguous names
+- Order logically (workflow progression)
+- Avoid overlapping meanings
+- Document what each option means
+
+### Number
+
+**Purpose**: Numeric values (integer or decimal)
+
+**Use cases**:
+- Story Points (1, 2, 3, 5, 8, 13)
+- Estimated Hours (decimal)
+- Customer Impact (count)
+- Revenue Impact (dollars)
+- Affected Users (count)
+- Sprint Capacity (points)
+
+**Characteristics**:
+- Sortable and filterable
+- Supports math operations (sum, average)
+- No min/max validation (set via workflow norms)
+- Can be decimal or integer
+
+**CLI Creation**:
+```bash
+gh project field-create <project-id> --owner "@me" \
+  --data-type NUMBER --name "Story Points"
+```
+
+**CLI Update**:
+```bash
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --number 5
+```
+
+**Best Practices**:
+- Document units (hours, points, count)
+- Use consistent scale (Fibonacci for story points)
+- Don't use for categorical data (use Single Select)
+- Consider aggregation needs
+
+### Date
+
+**Purpose**: Calendar date (no time component)
+
+**Use cases**:
+- Due Date
+- Start Date
+- Launch Date
+- Reported Date
+- Target Completion
+- Review By Date
+
+**Characteristics**:
+- Format: YYYY-MM-DD
+- Enables timeline/roadmap views
+- Sortable and filterable
+- No time component (dates only)
+- Past dates highlighted in red (in UI)
+
+**CLI Creation**:
+```bash
+gh project field-create <project-id> --owner "@me" \
+  --data-type DATE --name "Due Date"
+```
+
+**CLI Update**:
+```bash
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --date "2025-12-31"
+```
+
+**Best Practices**:
+- Use for deadlines and milestones
+- Combine with Status for at-risk detection
+- Set realistic dates (avoid always late pattern)
+- Review and adjust dates as needed
+- Use roadmap view for visualization
+
+### Iteration
+
+**Purpose**: Time-boxed planning cycles (sprints)
+
+**Use cases**:
+- 2-week sprints
+- Monthly cycles
+- Quarterly planning
+- Release trains
+- PI (Program Increment) planning
+
+**Characteristics**:
+- Fixed duration (1-4 weeks typical)
+- Start and end dates
+- Automatically creates future iterations
+- Enables velocity tracking
+- Burndown calculations
+- Sortable chronologically
+
+**CLI Creation**:
+```bash
+gh project field-create <project-id> --owner "@me" \
+  --data-type ITERATION --name "Sprint"
+```
+
+**Configuration** (via UI):
+- Set iteration duration (days)
+- Set start date
+- System generates future iterations
+
+**CLI Update** (complex - requires iteration ID):
+```bash
+# First get iteration IDs via field-list
+ITERATIONS=$(gh project field-list <project-id> --owner "@me" --format json | \
+  jq '.[] | select(.name=="Sprint") | .configuration.iterations')
+
+# Then update item with iteration ID
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --iteration-id <iteration-id>
+```
+
+**Best Practices**:
+- Consistent duration (2 weeks standard)
+- Start sprints on same weekday
+- Name iterations clearly (Sprint 1, Sprint 2 or dates)
+- Close/archive old iterations after 6 months
+- Track velocity across iterations
+
+### Text
+
+**Purpose**: Free-form text input (single line)
+
+**Use cases**:
+- Owner name
+- External ticket ID
+- Slack thread link
+- Sprint goal
+- Related feature
+- Customer name
+
+**Characteristics**:
+- Single line (not multiline)
+- Searchable
+- Not structured (no validation)
+- Filterable (exact match or contains)
+- Max length ~1000 characters
+
+**CLI Creation**:
+```bash
+gh project field-create <project-id> --owner "@me" \
+  --data-type TEXT --name "Owner"
+```
+
+**CLI Update**:
+```bash
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --text "Alice Johnson"
+```
+
+**Best Practices**:
+- Use for unstructured data only
+- Consider Single Select if options are limited
+- Document expected format (if any)
+- Avoid using for categorical data
+- Good for links and external references
+
+## Built-in Fields
+
+These fields exist automatically and cannot be customized:
+
+### Title
+- Item title
+- Always visible
+- Editable in place
+- Searchable
+- Required field
+
+### Assignees
+- GitHub user assignments
+- Multiple assignees possible
+- Inherited from issue/PR
+- Can filter by assignee
+- Enables workload distribution
+
+### Labels
+- Inherited from linked issue/PR
+- Not directly editable in project
+- Change on issue to reflect in project
+- Filterable and searchable
+- Color-coded
+
+### Repository
+- Where issue/PR resides
+- Read-only in project
+- Useful for multi-repo projects
+- Filter by repo
+
+### Milestone
+- Inherited from issue/PR
+- Not editable in project view
+- Useful for release planning
+- Can filter by milestone
+
+### Linked Pull Requests
+- PRs linked to issue
+- Shows PR status
+- Quick navigation
+- Enables PR → Issue status sync
+
+## Field Management Strategies
+
+### Minimal Field Set
+
+**Philosophy**: Only add fields you'll actively use
+
+**Recommended minimum**:
+- Status (required)
+- Priority (required)
+- One size/effort field (optional but recommended)
+
+**When to use**:
+- Small teams (<5 people)
+- Simple projects
+- Getting started with GitHub Projects
+- Single-team projects
+
+**Benefits**:
+- Easy to maintain
+- Low cognitive overhead
+- Fast to use
+- Less data entry
+
+### Standard Field Set
+
+**Philosophy**: Cover common planning needs
+
+**Recommended fields**:
+- Status
+- Priority
+- Story Points or Size
+- Iteration or Sprint
+- Component or Area
+- Assignee (built-in)
+
+**When to use**:
+- Medium teams (5-20 people)
+- Agile workflows
+- Cross-functional teams
+- Regular sprint planning
+
+**Benefits**:
+- Good balance of detail and simplicity
+- Enables velocity tracking
+- Supports sprint planning
+- Reasonable overhead
+
+### Comprehensive Field Set
+
+**Philosophy**: Detailed tracking for complex projects
+
+**Recommended fields**:
+- Status
+- Priority
+- Story Points
+- Sprint/Iteration
+- Component
+- Team
+- Effort (hours)
+- Customer Impact
+- Due Date
+- Owner
+- External Ticket ID
+
+**When to use**:
+- Large organizations (>20 people)
+- Multiple teams
+- Regulatory requirements
+- Executive reporting needs
+- Complex dependencies
+
+**Benefits**:
+- Rich reporting capabilities
+- Detailed tracking
+- Multi-team coordination
+- Audit trail
+
+**Drawbacks**:
+- High maintenance overhead
+- More data entry required
+- Can slow down workflow
+- Risk of analysis paralysis
+
+## Field Discovery & Querying
+
+### Get All Fields for a Project
+
+```bash
+# List all fields with metadata
+gh project field-list <project-number> --owner "@me" --format json
+
+# Parse field names and types
+gh project field-list <project-number> --owner "@me" --format json | \
+  jq '.[] | {name: .name, type: .dataType, id: .id}'
+```
+
+### Get Field ID by Name
+
+```bash
+FIELDS=$(gh project field-list <project-number> --owner "@me" --format json)
+
+# Get specific field ID
+STATUS_FIELD_ID=$(echo $FIELDS | jq -r '.[] | select(.name=="Status") | .id')
+```
+
+### Get Single Select Options
+
+```bash
+# Get all options for a single-select field
+gh project field-list <project-number> --owner "@me" --format json | \
+  jq '.[] | select(.name=="Priority") | .options[] | {name: .name, id: .id}'
+
+# Store for later use
+PRIORITY_OPTIONS=$(gh project field-list <project-number> --owner "@me" --format json | \
+  jq '.[] | select(.name=="Priority") | .options')
+```
+
+### Get Iteration IDs
+
+```bash
+# List all iterations with IDs
+gh project field-list <project-number> --owner "@me" --format json | \
+  jq '.[] | select(.dataType=="ITERATION") | .configuration.iterations[] | {title: .title, id: .id, startDate: .startDate, duration: .duration}'
+```
+
+## Field Value Management
+
+### Setting Field Values
+
+**Single Select**:
+```bash
+# Requires option ID, not option name
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --single-select-option-id <option-id>
+```
+
+**Number**:
+```bash
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --number 8
+```
+
+**Date**:
+```bash
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --date "2025-06-15"
+```
+
+**Text**:
+```bash
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --text "Alice Johnson"
+```
+
+**Iteration**:
+```bash
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --iteration-id <iteration-id>
+```
+
+### Clearing Field Values
+
+```bash
+# Use --clear flag to remove value
+gh project item-edit --id <item-id> --project-id <project-id> \
+  --field-id <field-id> --clear
+```
+
+### Batch Field Updates
+
+```bash
+# Update multiple items to same value
+ITEMS=$(gh project item-list <project-number> --owner "@me" --format json)
+
+# Filter items and update
+echo $ITEMS | jq -r '.items[] | select(<filter-criteria>) | .id' | while read ITEM_ID; do
+  gh project item-edit --id $ITEM_ID --project-id $PROJECT_ID \
+    --field-id $FIELD_ID --single-select-option-id $OPTION_ID
+  echo "Updated item $ITEM_ID"
+done
+```
+
+## Common Field Configurations
+
+**NOTE**: Status field is built-in and already exists. The configurations below show recommended options for customizing the existing Status field via the GitHub UI, and CLI commands for creating other fields.
+
+### Agile Scrum
+
+```yaml
+Status:
+  type: SINGLE_SELECT (Built-in - customize via UI)
+  options: [Backlog, Todo, In Progress, In Review, Done]
+
+Priority:
+  type: SINGLE_SELECT
+  options: [P0, P1, P2, P3]
+
+Story Points:
+  type: NUMBER
+  values: [1, 2, 3, 5, 8, 13]
+
+Sprint:
+  type: ITERATION
+  duration: 14 days
+```
+
+### Kanban Flow
+
+```yaml
+Status:
+  type: SINGLE_SELECT
+  options: [Ready, In Progress, Review, Done]
+
+Priority:
+  type: SINGLE_SELECT
+  options: [Critical, High, Normal, Low]
+
+Size:
+  type: SINGLE_SELECT
+  options: [XS, S, M, L, XL]
+
+Type:
+  type: SINGLE_SELECT
+  options: [Bug, Feature, Chore, Tech Debt]
+```
+
+### Bug Tracking
+
+```yaml
+Status:
+  type: SINGLE_SELECT
+  options: [New, Triaged, In Progress, Fixed, Verified, Closed]
+
+Severity:
+  type: SINGLE_SELECT
+  options: [Critical, High, Medium, Low]
+
+Component:
+  type: SINGLE_SELECT
+  options: [Frontend, Backend, API, Database, Infrastructure]
+
+Affected Users:
+  type: NUMBER
+
+Reported Date:
+  type: DATE
+```
+
+### Product Roadmap
+
+```yaml
+Status:
+  type: SINGLE_SELECT
+  options: [Idea, Spec, Development, Beta, Launched]
+
+Priority:
+  type: SINGLE_SELECT
+  options: [Must Have, Should Have, Nice to Have]
+
+Quarter:
+  type: SINGLE_SELECT
+  options: [Q1 2025, Q2 2025, Q3 2025, Q4 2025]
+
+Launch Date:
+  type: DATE
+
+Customer Impact:
+  type: NUMBER
+
+Owner:
+  type: TEXT
+```
+
+## Troubleshooting Field Issues
+
+### Cannot Create Status Field
+
+**Problem**: Error when trying to create Status field
+
+**Cause**: Status is a built-in default field that already exists in all new projects
+
+**Solution**:
+- Do NOT create a Status field
+- The field already exists with default options
+- Customize options via GitHub UI if needed (Project Settings → Fields → Status)
+
+### Field Creation Fails for SINGLE_SELECT
+
+**Problem**: `gh project field-create` succeeds but field has no options
+
+**Cause**: Options were not provided at creation time
+
+**Solution**:
+- Always include `--single-select-options` parameter
+- Format: `--single-select-options "Option1,Option2,Option3"`
+- No spaces after commas
+- Options cannot be added later via CLI
+
+### Field Update Fails
+
+**Problem**: `gh project item-edit` returns error
+
+**Causes**:
+1. Wrong field ID
+2. Wrong option ID (for single-select)
+3. Invalid data format (date, number)
+4. Permission issue
+5. Item doesn't exist in project
+
+**Solutions**:
+```bash
+# Re-fetch field IDs
+gh project field-list <project-number> --owner "@me" --format json
+
+# Verify item exists in project
+gh project item-list <project-number> --owner "@me" --format json | \
+  jq '.items[] | select(.id=="<item-id>")'
+
+# Check auth scopes
+gh auth status
+# If missing: gh auth refresh -s project
+```
+
+### Field Not Showing in Views
+
+**Problem**: Created field doesn't appear
+
+**Causes**:
+1. View is filtered/hidden
+2. Field hidden in view settings
+3. Cache issue
+
+**Solutions**:
+- Refresh browser
+- Check view settings → Fields → Unhide field
+- Create new view to test
+
+### Can't Add Options to Single Select
+
+**Problem**: CLI created field has no options
+
+**Cause**: Options were not provided at creation time (required parameter was missing)
+
+**Solution**:
+- SINGLE_SELECT fields require `--single-select-options` at creation time
+- Options cannot be added later via CLI
+- If field already exists without options, delete and recreate with options
+- Or use GitHub UI to manually add options (Project Settings → Fields)
+
+### Iteration Field Not Working
+
+**Problem**: Can't set iteration or iterations don't appear
+
+**Cause**: Iterations not configured
+
+**Solution**:
+1. Go to project settings
+2. Click on Iteration field
+3. Set start date and duration
+4. Save (future iterations auto-generate)
+
+### Repository Linking Fails
+
+**Problem**: `gh project link` returns error or permission denied
+
+**Cause**: Owner parameter doesn't match repository owner
+
+**Solution**:
+- The `--owner` parameter MUST match the repository owner exactly
+- Cannot use "@me" for organization repositories
+- Examples:
+  ```bash
+  # For personal repo
+  gh project link 1 --owner "your-username" --repo your-username/repo-name
+
+  # For org repo
+  gh project link 1 --owner "org-name" --repo org-name/repo-name
+  ```
+
+## Field Best Practices Summary
+
+1. **Start Minimal**: Add fields as needed, not preemptively
+2. **Clear Names**: Use unambiguous field names (Status, not State)
+3. **Consistent Options**: Standardize across projects
+4. **Document Meanings**: Write down what P0 vs P1 means
+5. **Avoid Duplication**: Don't create multiple fields for same purpose
+6. **Use Right Type**: Single Select > Text for categorical data
+7. **Regular Cleanup**: Remove unused fields
+8. **Team Alignment**: Ensure team understands field purposes
+9. **Automation-Friendly**: Choose fields that can be auto-populated
+10. **Measure Usefulness**: Track which fields are actually used
+
+Remember: Fields should clarify, not complicate. Every field is a cognitive burden and data entry task. Only keep fields that provide clear value to the team.
--- a/skills/project-workflow-patterns/SKILL.md
+++ b/skills/project-workflow-patterns/SKILL.md
@@ -0,0 +1,334 @@
+---
+name: project-workflow-patterns
+description: Common GitHub Projects workflow patterns and best practices for team collaboration. Use when designing workflows, setting up new projects, or optimizing existing processes.
+---
+
+# GitHub Projects Workflow Patterns
+
+This skill provides proven workflow patterns for different team types and development methodologies using GitHub Projects V2.
+
+## Agile Scrum Workflow
+
+### Project Structure
+
+**Fields**:
+- Status: Backlog → Todo → In Progress → In Review → Done
+- Priority: P0, P1, P2, P3
+- Story Points: 1, 2, 3, 5, 8, 13
+- Sprint: 2-week iterations
+- Assignee: Team member
+
+**Views**:
+1. **Sprint Board**: Board view grouped by Status, filtered to current sprint
+2. **Sprint Backlog**: Table view showing all current sprint items sorted by priority
+3. **Product Backlog**: Table view of all Backlog items sorted by priority
+4. **Sprint Velocity**: Custom view tracking completed points
+
+### Workflow Steps
+
+1. **Backlog Refinement** (Weekly):
+   - Review new items in Backlog
+   - Assign Priority based on business value
+   - Estimate Story Points for upcoming items
+   - Add acceptance criteria in item body
+   - Move refined items to top of Backlog
+
+2. **Sprint Planning** (Every 2 weeks):
+   - Review team velocity from last sprint
+   - Select top-priority items from Backlog
+   - Assign to current Sprint iteration
+   - Move items from Backlog to Todo
+   - Ensure total points ≤ team capacity
+
+3. **Daily Standup** (Daily):
+   - Review Sprint Board
+   - Items "In Progress" are discussed
+   - Blockers identified and marked P0/P1
+   - Items "In Review" get review assignments
+
+4. **Development**:
+   - Pull item from Todo to In Progress
+   - Self-assign the item
+   - Create feature branch
+   - Implement and test
+   - Create PR linked to issue
+   - Auto-move to In Review (via automation)
+
+5. **Code Review**:
+   - Team reviews items In Review
+   - Approve or request changes
+   - When PR merges → Auto-move to Done
+
+6. **Sprint Review** (End of sprint):
+   - Review all Done items
+   - Demo completed features
+   - Archive Done items
+   - Celebrate wins
+
+7. **Sprint Retrospective** (End of sprint):
+   - Review sprint metrics
+   - Discuss what went well/poorly
+   - Create action items for improvements
+
+### Success Metrics
+
+- **Velocity**: Average points completed per sprint
+- **Predictability**: % variance from planned vs actual
+- **Cycle Time**: Average time from Todo → Done
+- **Work in Progress**: Should stay ≤ team size
+- **Sprint Completion**: Aim for >80% of committed work
+
+## Kanban Continuous Flow
+
+### Project Structure
+
+**Fields**:
+- Status: Ready → In Progress → Review → Done
+- Priority: Critical, High, Normal, Low
+- Size: S, M, L, XL
+- Type: Bug, Feature, Chore, Tech Debt
+- SLA Days: Number (days until due)
+
+**Views**:
+1. **Flow Board**: Board grouped by Status with WIP limits
+2. **Blocked Items**: Table filtered to items with "blocked" label
+3. **Priority Lane**: Board grouped by Priority
+4. **Aging Report**: Table sorted by days in status
+
+### Workflow Steps
+
+1. **Item Entry**:
+   - New items start in Ready
+   - Assign Priority immediately
+   - Assign Size estimate
+   - Set Type category
+   - Calculate SLA based on Priority
+
+2. **Pull System**:
+   - Team members pull from Ready when capacity available
+   - WIP limits enforced per person (typically 2-3 items)
+   - Highest priority items pulled first
+   - Self-assign when pulling to In Progress
+
+3. **Work In Progress**:
+   - Focus on finishing items before starting new ones
+   - Update item if blockers occur
+   - Seek help if stuck >2 days
+
+4. **Review**:
+   - Items move to Review when PR opens
+   - Automated PR → Review status transition
+   - Reviews prioritized by age (oldest first)
+
+5. **Completion**:
+   - Merged PR auto-moves to Done
+   - Done items archived after 7 days
+   - Metrics tracked continuously
+
+6. **WIP Limit Management**:
+   - In Progress limit: [team size × 2]
+   - Review limit: 5 items maximum
+   - If limits exceeded, stop pulling new work
+
+### Success Metrics
+
+- **Throughput**: Items completed per week
+- **Lead Time**: Time from Ready → Done
+- **WIP**: Average items in progress (lower is better)
+- **Flow Efficiency**: Value-add time / total time
+- **Blocked Rate**: % of time items are blocked
+
+## Bug Triage Workflow
+
+### Project Structure
+
+**Fields**:
+- Status: New → Triaged → In Progress → Fixed → Verified → Closed
+- Severity: Critical, High, Medium, Low
+- Component: Frontend, Backend, API, Database, Infrastructure
+- Affected Users: Number
+- Reported Date: Date
+- Fix Version: Text
+
+**Views**:
+1. **Triage Queue**: Board showing New bugs by Severity
+2. **Active Bugs**: Table of In Progress/Fixed bugs sorted by Severity
+3. **Component View**: Board grouped by Component
+4. **Verification Queue**: Table of Fixed bugs awaiting verification
+
+### Workflow Steps
+
+1. **Bug Reported**:
+   - User/QA creates issue with bug template
+   - Auto-add to project with New status
+   - Triage team notified
+
+2. **Triage** (Daily):
+   - Review all New bugs
+   - Assign Severity based on impact:
+     * Critical: Production down, data loss, security
+     * High: Major feature broken, >100 users affected
+     * Medium: Feature degraded, workaround exists
+     * Low: Minor issue, cosmetic problem
+   - Assign Component
+   - Estimate Affected Users
+   - Move to Triaged status
+   - Assign to component owner if Critical/High
+
+3. **Development**:
+   - Developer pulls bug from Triaged
+   - Move to In Progress
+   - Investigate and fix
+   - Create PR with "Fixes #[issue]" in description
+   - Move to Fixed when PR merges
+
+4. **Verification**:
+   - QA/Reporter tests fix
+   - If verified: Move to Verified, close issue
+   - If not fixed: Move back to In Progress with notes
+
+5. **Closed**:
+   - Verified items move to Closed
+   - Archive after 30 days
+   - Track in Fix Version for release notes
+
+### Success Metrics
+
+- **Triage Time**: Time from New → Triaged (target: <1 day)
+- **Time to Fix**: Time from Triaged → Fixed by severity
+- **Bug Escape Rate**: Bugs found in production vs QA
+- **Reopen Rate**: % of bugs reopened after fix
+- **Critical SLA**: 100% of Critical bugs fixed within SLA
+
+## Feature Development Roadmap
+
+### Project Structure
+
+**Fields**:
+- Status: Idea → Spec → Development → Beta → Launched → Retired
+- Priority: Must Have, Should Have, Nice to Have
+- Quarter: Q1 2025, Q2 2025, Q3 2025, Q4 2025
+- Effort: 1 week, 2 weeks, 1 month, 3 months, 6 months
+- Customer Impact: Number (customers requesting)
+- Owner: Text (PM name)
+- Launch Date: Date
+
+**Views**:
+1. **Roadmap Timeline**: Roadmap view by Launch Date
+2. **This Quarter**: Table filtered to current quarter sorted by Priority
+3. **Ideas Board**: Board of Idea status items grouped by Priority
+4. **Feature Status**: Board grouped by Status
+
+### Workflow Steps
+
+1. **Idea Collection**:
+   - Create draft items in project
+   - Status: Idea
+   - Rough priority assignment
+   - Track Customer Impact
+
+2. **Quarterly Planning**:
+   - Review all Ideas
+   - Assign Priority: Must/Should/Nice to Have
+   - Assign Quarter
+   - Assign Owner (PM)
+   - Top ideas move to Spec status
+
+3. **Specification**:
+   - Owner writes detailed spec
+   - Define success metrics
+   - Estimate Effort
+   - Get stakeholder approval
+   - Move to Development when eng committed
+
+4. **Development**:
+   - Link to engineering project/sprint
+   - Track progress via linked issues
+   - Status updates in weekly sync
+   - Move to Beta when ready for testing
+
+5. **Beta Testing**:
+   - Limited rollout
+   - Gather feedback
+   - Fix critical issues
+   - Refine based on learnings
+   - Move to Launched when GA
+
+6. **Launch**:
+   - Full rollout
+   - Marketing announcement
+   - Track adoption metrics
+   - Monitor for issues
+   - Eventually move to Retired when deprecated
+
+### Success Metrics
+
+- **Delivery Accuracy**: % of features launched on time
+- **Customer Satisfaction**: NPS or CSAT per feature
+- **Adoption Rate**: % of users using new feature
+- **Spec → Launch**: Average time from commit to ship
+- **Roadmap Predictability**: % of quarterly commitments met
+
+## Common Automation Patterns
+
+### Status Automation
+```
+When PR opens → Move item to "In Review"
+When PR merges → Move item to "Done"
+When issue closed → Move item to "Done"
+When item added → Set default Status to "Backlog"
+```
+
+### Priority Automation
+```
+When "critical" label added → Set Priority to P0
+When "bug" label added → Set Priority to P1
+When "enhancement" label added → Set Priority to P2
+```
+
+### Archival Automation
+```
+When item in "Done" for 30 days → Archive
+When item closed and verified → Archive after 7 days
+```
+
+### Notification Automation
+```
+When P0 item added → Notify team on Slack
+When item stuck in "In Review" >3 days → Notify assignee
+When sprint ends → Generate velocity report
+```
+
+## Best Practices Across All Workflows
+
+1. **Single Source of Truth**: Use project as primary view, not issue lists
+2. **Consistent Field Usage**: Standardize field names/values across projects
+3. **Regular Refinement**: Weekly grooming prevents backlog chaos
+4. **Clear Definitions**: Document what each status/priority means
+5. **Limit WIP**: Focus on finishing over starting
+6. **Automate Transitions**: Reduce manual status updates
+7. **Measure & Improve**: Track metrics, iterate on process
+8. **Team Buy-in**: Involve team in workflow design
+9. **Visual Management**: Use boards for transparency
+10. **Archive Regularly**: Keep active views clean and focused
+
+## Choosing the Right Workflow
+
+| Team Type | Recommended Workflow | Why |
+|-----------|---------------------|-----|
+| Product Dev Team | Agile Scrum | Predictable planning, clear sprints |
+| Platform/DevOps | Kanban | Continuous flow, varied work types |
+| Support/Ops | Bug Triage | Prioritize by severity, fast response |
+| Product Management | Feature Roadmap | Long-term planning, stakeholder communication |
+| OSS Maintainers | Kanban + Priority | Flexible, contributor-friendly |
+| Startup | Kanban | Fast iteration, changing priorities |
+
+## Hybrid Workflows
+
+Many teams combine patterns:
+
+- **Scrum + Bug Triage**: Separate projects for planned work vs bugs
+- **Kanban + Roadmap**: Tactical execution + strategic planning
+- **Feature Roadmap → Scrum**: PM roadmap feeds eng sprint planning
+
+Remember: Workflows should serve the team, not constrain them. Start simple, iterate based on what works for your team's unique needs.