Review backlog items and organize them into project groupings with parallelism analysis. This skill should be used when the user asks to "organize the backlog", "group backlog items into projects", "review backlog for project planning", "what projects should we create from the backlog", "prioritize backlog items", or when the backlog has accumulated enough items that grouping and project creation would be valuable.
From project-docsnpx claudepluginhub ichabodcole/project-docs-scaffold-template --plugin project-docsThis skill uses the workspace's default tool permissions.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Retrieves current documentation, API references, and code examples for libraries, frameworks, SDKs, CLIs, and services via Context7 CLI. Ideal for API syntax, configs, migrations, and setup queries.
Uses ctx7 CLI to fetch current library docs, manage AI coding skills (install/search/generate), and configure Context7 MCP for AI editors.
Review active backlog items, identify natural groupings based on overlapping concerns, and propose projects with parallelism analysis. Present groupings to the user for approval, then create project folders for accepted groups.
Read all files in docs/backlog/ (excluding _archive/). For each item,
extract:
Present the inventory as a summary table:
| # | Item | Area | Type | Complexity |
|---|------|------|------|------------|
| 1 | ... | ... | ... | ... |
Cluster items using these signals (strongest to weakest):
Items that don't cluster naturally become standalone projects.
For each proposed group, identify the files and directories it would touch. Two groups can run in parallel when their file footprints don't overlap. Flag conflicts explicitly:
Present a parallelism matrix showing which groups can run concurrently.
Present the groupings with:
Ask the user to approve, modify, or reject groupings before proceeding.
For each approved grouping, create a project folder with a proposal. Follow the
create-project conventions:
docs/projects/TEMPLATES/PROPOSAL.template.md for the templatedocs/projects/<name>/proposal.mddocs/projects/After project creation, archive the backlog items that were absorbed into projects:
docs/backlog/ to docs/backlog/_archive/The backlog is an inbox — once an idea graduates to a project proposal, the proposal becomes the source of truth. The archived backlog items remain accessible via the proposal's related documents links.
Stage and commit all new project folders and archived backlog items in a single commit. Present a final summary:
Prefer fewer, cohesive projects over many tiny ones. A good project has 2-6 backlog items that share a clear theme. Single-item projects are fine for large or isolated work.
Don't force groupings. If items don't naturally cluster, leave them as standalone backlog items or single-item projects. Bad groupings create more coordination overhead than they save.
Consider the work type mix. A project mixing "quick code changes" with "needs UX research first" may stall the quick wins. Split if the research would block implementation items that are already clear.
Respect file boundaries for parallelism. The primary benefit of grouping is enabling parallel execution. If two items touch the same files, they should be in the same project to avoid merge conflicts.
docs/backlog/ (not docs/backlog/_archive/)plan.md or sessions/ — those come later../../backlog/_archive/<filename>.md (since items are
archived after project creation)