From release
Capture explored work as a backlog item for future implementation. Use when you've explored an enhancement, alternative approach, or feature but decided to defer it. Creates comprehensive plan files in backlog/ directory with enough context for a future session to execute efficiently.
npx claudepluginhub fairchild/dotclaude --plugin skill-creatorThis skill uses the workspace's default tool permissions.
Create a comprehensive backlog item for work we've explored but decided not to implement now.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Create a comprehensive backlog item for work we've explored but decided not to implement now.
Ask these questions to understand what we're deferring:
Choose the category and encode it in the filename suffix:
Use filename format: backlog/{task-name}-{category}.md
Examples:
backlog/docs-r2-storage-plan.mdbacklog/session-cache-followups-task-list.mdNotes:
{task-name})-{category}), not frontmatterbacklog/ = pending, backlog/done/ = doneCreate a file at backlog/{task-name}-{category}.md with this structure:
---
# Optional metadata only (omit keys you don't need)
topic: {slug-topic-name}
relates_to: {after:other-task-plan|until:other-task-plan}
priority: {1|2|3...} # 1 = highest priority
description: {short summary for UI/list views}
---
# {Feature Name}
## Problem Statement
{1-2 paragraphs explaining why this work matters and what problem it solves}
## Key Decisions
| Decision | Choice | Rationale |
|----------|--------|-----------|
| {decision point} | {what we'd choose} | {why} |
## Architecture
{ASCII diagram if helpful}
## Implementation Phases
### Phase 1: {Name}
**Files to modify:**
- `path/to/file.ts` - {what changes}
**Files to create:**
- `path/to/new-file.ts` - {purpose}
**Acceptance criteria:**
- [ ] {testable outcome}
- [ ] {testable outcome}
### Phase 2: {Name}
...
## Verification Commands
```bash
# Commands to verify the implementation works
{How to undo if things go wrong}
### Step 4: Include Research Artifacts
Incorporate what we learned during exploration:
- Code snippets we prototyped or found
- Configuration examples
- API patterns from existing code
- External documentation links
### Step 5: Commit
Commit the backlog file with message:
chore: add {feature} to backlog
{One sentence on what this enables}
## Quality Checklist
Before finishing, verify the backlog file:
- [ ] Has enough context that a fresh session can understand without the original conversation
- [ ] Includes specific file paths (with line numbers when relevant)
- [ ] Has verification commands or acceptance criteria
- [ ] References related code patterns in the codebase
- [ ] Uses minimal optional metadata only (`topic`, `relates_to`, `priority`, `description`) and omits unused keys
- [ ] Uses kebab-case filename suffix format: `{task-name}-{category}.md`
## List Backlog Items
To see all backlog items, run:
```bash
~/.claude/skills/backlog/scripts/status.sh
Detect stale or likely-completed backlog items that were never moved to done/.
~/.claude/skills/backlog/scripts/groom.sh [path/to/backlog]
The script cross-references pending items against git history (title/keyword matches and in-file references) and the filesystem (files that were supposed to be created). It flags items that look done so you can review and close them.
See references/grooming.md for the full grooming workflow and checklist.
User: /backlog
Claude: I'll help capture the work we explored for future implementation.
What feature/enhancement are we deferring?
> R2 storage for docs assets
Why did we explore it?
> Docs screenshots are gitignored, wanted persistent storage without git bloat
Why are we deferring?
> Works fine locally for now, R2 adds complexity we don't need yet
What did we learn?
> R2 bindings in wrangler.jsonc, Worker route pattern, wrangler CLI for uploads
[Creates backlog/docs-r2-storage-plan.md with full implementation plan]
See references/agents-schema.md for directory setup, naming conventions, and metadata conventions.
references/agents-schema.md — Categories, lifecycle, filename conventions, directory setupreferences/grooming.md — Backlog maintenance workflow and checklistreferences/README.md — Background, design philosophy, and related projects