AI Skill Report Card
Managing Backlog Issues
Markdown--- name: managing-backlog-issues description: Converts raw feature/bug ideas into well-structured backlog issues with clear titles, descriptions, and acceptance criteria, then tracks their status (todo/in-progress/done) as items are added, updated, or removed. Use when a user provides a list of features, bugs, or tasks and wants them turned into actionable backlog items, or when managing the lifecycle of existing backlog issues. ---
Quick Start15 / 15
Given a raw list like:
- login with google
- fix crash on checkout page
- add dark mode
Produce backlog issues like:
Markdownundefined
Recommendation▾
Add an example of handling removal/deletion confirmation flow explicitly, not just status update and creation
[FEATURE] Google OAuth Login
Status: Todo Priority: Medium Type: Feature
Description
Allow users to sign in using their Google account instead of (or in addition to) email/password.
Acceptance Criteria
- User can click "Sign in with Google" on the login page
- Successful auth creates or links a user account
- User is redirected to dashboard after login
- Error state shown if OAuth fails or is cancelled
- Existing email/password login still works
Notes
- Requires Google OAuth client ID/secret config
- Consider account-linking if email already exists
Repeat per item, assign an ID (e.g. `BL-001`), and append to the backlog store (file, table, or issue tracker).
Workflow14 / 15
Progress:
- Step 1: Parse the raw input list into discrete items
- Step 2: Classify each item (Feature / Bug / Chore / Spike)
- Step 3: Draft a clear title (imperative, specific, no vague wording)
- Step 4: Write a short description (what + why, 1–3 sentences)
- Step 5: Write acceptance criteria (3–6 testable, binary checkboxes)
- Step 6: Assign priority and initial status (default: Todo)
- Step 7: Assign a unique ID and add to the backlog
- Step 8: Confirm with user before bulk-adding if list is long (>10 items)
- Step 9: For updates, locate issue by ID/title and apply status/content change
- Step 10: For removal, confirm item identity before deleting
Classification defaults
- Bug: something broken vs expected behavior → include repro steps if known, severity
- Feature: new capability → include user story framing
- Chore: non-user-facing (refactor, deps, CI) → include scope/why
- Spike: research/investigation → acceptance criteria = "answer documented," not implementation
Status lifecycle
Todo → In Progress → In Review → Done (or Blocked, Won't Do)
Always state the current status explicitly in the issue; update it in place rather than duplicating issues.
Recommendation▾
Include a brief ID-assignment scheme detail (e.g., how to detect next available ID from existing backlog) since it's referenced but not specified
Examples17 / 20
Example 1 — Bug input
Input: fix crash on checkout page
Output:
Markdownundefined
Recommendation▾
Consider adding a short example of bulk input handling (>10 items) to show the confirmation preview format mentioned in Step 8
[BUG] Checkout Page Crashes on Submit
Status: Todo Priority: High Type: Bug
Description
The checkout page crashes when the user submits an order. Exact trigger/reproduction steps need confirmation.
Acceptance Criteria
- Crash is reproduced and root cause identified
- Checkout completes successfully for standard payment flow
- Error handling added for edge cases (empty cart, invalid payment)
- Regression test added to prevent recurrence
Notes
- Severity: High (blocks purchases)
- Needs reproduction steps / stack trace from reporter
**Example 2 — Status update**
Input: `mark BL-003 as done`
Output: Locate `BL-003`, change `**Status:** In Progress` → `**Status:** Done`, leave rest of issue unchanged. Confirm back: "BL-003 (Dark Mode) marked as Done."
**Example 3 — Vague input needing clarification-by-default**
Input: `improve performance`
Output:
```markdown
[CHORE] Investigate and Improve App Performance
Status: Todo Priority: Medium Type: Spike
Description
General performance concern raised without specifics. Needs investigation to identify bottlenecks before scoping fixes.
Acceptance Criteria
- Key performance metrics identified (load time, TTI, API latency)
- Bottlenecks documented with data (profiling results)
- Follow-up issues created for concrete fixes
(Default to a Spike rather than blocking on clarification — note the assumption instead.)
Best Practices
- Titles: imperative mood, specific, no "stuff," "etc," or vague scope.
- Acceptance criteria must be testable/binary — each one should be answerable yes/no. Avoid "works well" or "is fast."
- One concern per issue. Split compound requests ("add dark mode and fix login bug") into separate issues.
- Always set an explicit status and priority, even if default (Todo/Medium), so nothing is ambiguous.
- Preserve IDs — never reuse or renumber IDs after removal; keeps history traceable.
- State assumptions in a Notes section rather than blocking on missing info.
- Batch confirm before adding many issues at once — show a short preview list first.
Common Pitfalls
- Don't write acceptance criteria that just restate the title ("Dark mode works").
- Don't silently delete issues — confirm identity (ID + title) first.
- Don't leave status/priority unset — ambiguity breaks backlog triage.
- Don't merge unrelated bugs/features into one issue for convenience.
- Don't invent technical implementation details not implied by the request — keep description/AC focused on behavior, not architecture, unless the user specified it.