/create-issue

Create GitHub Issue

Standard process for creating well-structured GitHub issues. Use for bugs, feature requests, and tasks.

MCP connectors

| Connector | Purpose | |-----------|---------| | GitHub | Create and label issues |

Bug report template

## Problem

[Clear description of what's broken. Include steps to reproduce.]

1. Step one
2. Step two
3. Observe: [what happens]

## Expected behavior

[What should happen instead]

**Environment**: [browser, OS, version, relevant config]

Feature request template

## Problem

[What user problem does this solve? Who is affected?]

## Expected behavior

[What the feature should do, from the user's perspective]

## Notes

[Optional: technical considerations, related issues, mockups]

Labels

| Label | When to use | |-------|------------| | `bug` | Something is broken | | `feature` | New functionality request | | `enhancement` | Improvement to existing feature | | `docs` | Documentation change needed | | `good first issue` | Simple, well-scoped, good for new contributors | | `priority:high` | Blocks users or causes data issues | | `priority:low` | Nice to have, no urgency | | `needs-triage` | Needs review before prioritization | | `customer-reported` | Came from customer feedback |

Process

1. **Check for duplicates** - search existing issues before creating 2. **Use the right template** - bug report or feature request 3. **Add labels** - at least one type label and one priority label 4. **Link related issues** - reference with `#issue-number` if related 5. **Assign** - only if the assignee is clear; otherwise leave unassigned

Title format

• Bug: `[component] Short description of what's broken`
• Feature: `[component] Short description of desired behavior`
• Docs: `docs: Short description of what needs updating`

Examples:

• `[API] Query timeout on large datasets`
• `[Dashboard] Add date range filter to usage chart`
• `docs: Update authentication setup guide`

Guardrails

• **No PII** - scrub customer names, emails, and company names from all issue content
• **One issue per problem** - no omnibus issues covering multiple bugs
• **No Impact section** - keep body to Problem + Expected behavior only
• **No confidential data** - no API keys, credentials, or internal URLs in issues
• **Don't close issues** - only the CAO or the assignee closes issues

Self-improvement

After the CAO reviews created issues:

1. If the CAO edits an issue title, body, or labels before posting, note the pattern 2. If her edits reveal a preference for how problems are framed, bug reports are structured, or priorities are assigned, update the Templates or Labels sections 3. Update `product/_insights.md` with patterns: which issue formats get the fastest triage, which label conventions the team actually uses 4. If an issue template works particularly well, save it to `product/_examples/` as a reference