majiayu000 Create Ticket
Purpose
Capture intent for future work. This is NOT about planning implementation - it's about recording WHAT needs doing and WHY, with enough context to understand the task later.
Workflow
Step 1: Verify Environment
Check we have a GitHub remote and are on a clean, up-to-date main/master:
git remote -v
git status
git fetch origin
git rev-parse --abbrev-ref HEAD
git status -uno
STOP if:
- No remote exists → "This skill requires a GitHub remote. Please add one with
git remote add origin <url>first." - Not on main/master → "Please switch to main/master first:
git checkout main" - Uncommitted changes → "Please commit or stash your changes first."
- Behind remote → "Please pull latest changes:
git pull"
Step 2: Understand the Request
Listen to what the user wants to do. Ask clarifying questions if needed:
- What's the goal?
- Why is this needed?
- Any constraints or requirements?
Keep questions minimal - don't over-engineer the discovery.
Step 3: Assess Scope
Decide if this is:
- Single task - one coherent piece of work
- Multiple tasks - should be split into separate issues
If splitting, create separate issues for each logical unit of work.
Step 4: Gather Context
Briefly explore the codebase to understand:
- What currently exists that's relevant
- Where the change would likely happen
- Any related code or patterns
This context goes INTO the issue - you're not planning, just documenting what exists.
Step 5: Create GitHub Issue
gh issue create --title "<title>" --body "$(cat <<'EOF'
## Summary
<One paragraph describing what needs to be done and why>
## Context
<What currently exists that's relevant - files, patterns, related code>
## Notes
<Any constraints, requirements, or considerations>
EOF
)"
Step 6: Report Back
Tell the user:
- What issue(s) were created
- GitHub issue URL(s)
- Brief summary of what was captured
Ticket Writing Guidelines
DO:
- Describe the intent clearly
- Include relevant context about existing code
- Note any constraints mentioned by user
- Keep it concise but complete
DON'T:
- Write implementation plans
- Include step-by-step instructions
- Estimate time or effort
- Make architectural decisions
Example Ticket
# Add rate limiting to API endpoints
## Summary
API endpoints currently have no rate limiting, making them vulnerable to abuse. Need to add rate limiting to protect the service.
## Context
- API routes defined in `src/api/routes.py`
- Currently using FastAPI with no middleware for rate limiting
- Redis is already available in the stack (`src/services/redis.py`)
## Notes
- User mentioned starting with a simple per-IP limit
- Should be configurable per-endpoint
Checklist
- Verify GitHub remote exists and on clean, up-to-date main/master
- Understand what user wants to do
- Ask clarifying questions if needed
- Assess if single or multiple issues
- Explore codebase for relevant context
- Create GitHub issue(s)
- Report back with issue URL(s)