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