# Backlog Scanner

> Scan transcripts, meeting notes, chats, or any input for backlog item opportunities, and produce a structured markdown file of candidates with user stories, acceptance criteria and routing for everything screened out. Use when the user says 'backlog scan', 'scan for backlog', 'backlog items', 'find backlog opportunities', 'extract backlog', or provides a transcript or document and asks to identify actionable items for a product backlog.

- Skill: `romain-nicod/backlog-scanner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add romain-nicod/backlog-scanner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/romain-nicod/backlog-scanner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: romain-nicod (https://skillmd.com/u/romain-nicod)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/romain-nicod/backlog-scanner

---


# Backlog Scanner

Identify, classify and format backlog candidates from any source
material: meeting transcripts, chat history, documents, side
conversations, user feedback.

The output is a file someone can act on: candidates written as user
stories, and everything that did not qualify listed with where it
should go instead. Nothing raised in the source is silently dropped.

---

## Trigger

Activated when the user:

- Says "backlog scan", "scan for backlog", "extract backlog items",
  "find backlog opportunities"
- Provides a transcript or document and asks for backlog extraction
- Asks to consolidate backlog items across several sources

## Workflow

### Step 0: establish the context

Ask before scanning, in one message, and keep the answers for the
rest of the session. Skip any question the user has already answered
in their request.

1. **What is this product or programme called?** Used in the output
   filename and its heading.
2. **Who are the users, by role?** Their real job titles, not
   "user". An analyst, a site foreman, a claims handler, a teacher:
   the specific role is what makes a user story arguable.
3. **Is there an existing backlog to check against?** If yes, what
   are its reference prefixes and where can it be read.
4. **Who decides what enters the backlog?** The candidates file is
   addressed to that person, and saying so changes how it is
   written.

If the user does not answer, proceed with generic defaults and say
so once at the top of the output: roles become "as a user", the
filename uses the source name, and no cross-referencing is done.
Do not stall the scan waiting for an answer.

### Step 1: source identification

Identify what is being scanned:

- **Transcript**: a meeting recording (`.docx`, `.odt`, `.vtt`,
  `.txt`). Scan the full text.
- **Chat history**: search past conversations by keyword. Scan
  several if needed.
- **Document**: any uploaded file. Extract actionable items.
- **Several sources**: if the user asks to consolidate, scan all of
  them and deduplicate.

### Step 2: extraction pass

For each source, identify statements matching ANY of these
patterns.

**Feature signals**

- "I want…", "we need…", "it would be nice if…"
- "What if we could…", "can we…", "is it possible to…"
- Someone describes a workflow pain point
- Someone describes a manual process that could be automated
- A comparison with another tool ("product X does this")

**Governance and process signals**

- "We need to define…", "there is no standard for…"
- "Who decides…", "how do we handle…"
- A recurring problem with no defined response
- Scaling concerns ("when we open this to more people…")

**Infrastructure signals**

- "We need more…", "it is too slow…", "it crashed…"
- Monitoring gaps, alerting gaps, capacity concerns
- Deployment friction, environment issues

**Architecture signals**

- "We should restructure…", "the current design…"
- Integration needs between systems
- Resilience, redundancy, switching provider

For each signal, capture:

- **Who said it** (reporter)
- **Timestamp**, if available
- **Verbatim quote**, or a close paraphrase
- **Context**: what prompted the statement
- **Who confirmed or supported it**, if anyone

**The need-without-solution rule.** A clearly expressed need
qualifies as a candidate even when no solution was discussed,
provided it implies a product, infrastructure or delivery
capability. The admission gate below still applies: a complaint
implying no capability is not a candidate. Write the story at the
capability level and park the unresolved solution under "Constraints
and open questions". A need whose solution is unknown is flagged as
needing scoping, and it is never dropped for being hard to estimate.

### Step 3: the admission gate

Candidates are created through a product owner's lens. A candidate
is a new or changed product capability that would go on a roadmap
and be weighed against other build work competing for the same
delivery capacity. Much of what a meeting raises is something else.

Before an extracted signal becomes a candidate, classify it into
exactly ONE bucket. Only **product opportunities** proceed. The
other three are routed out and listed in the "Screened out" section,
never silently dropped and never mixed into the candidate list.

| Bucket | Definition | Test | Routed to |
|---|---|---|---|
| **Bug fix** | Restores intended behaviour where the product deviates from its spec, or from parity with another environment | "Is this fixing something that should already work?" A stakeholder or the vendor calling it a bug settles it | Bug tracker, plus a linked investigation action |
| **Task or action** | A one-off provisioning, access, configuration, migration or ops step, with a single owner and a done state | "Is this a one-off thing someone does, rather than a capability to build?" Granting access, declaring a domain, claiming storage | Action tracker |
| **Documentation or one-off governance** | A document, scheme, naming convention or piece of guidance to write once | "Is the deliverable a document, rather than a built capability?" | Governance or documentation workstream |
| **Product opportunity** | A new or changed capability worth prioritising against other build work | "Would a product owner put this on the roadmap and weigh it against other features?" | Backlog candidate |

Rules that settle the frequent cases:

- The type label (feature, governance, infra, architecture) is a
  sub-category of a product opportunity. It is never a pass: an
  "infra" item can still be a provisioning task and get screened
  out.
- A crash, or "it does not behave the way the other environment
  does", is a bug.
- "We need access to X", "declare a subdomain", "claim storage" is a
  task, even when it unlocks a capability. The capability may
  separately be a candidate; the provisioning is not.
- "We need to define, categorise or write a scheme" is
  documentation, unless it means building a standing mechanism into
  the product.
- Governance items survive as candidates only when they structure
  delivery as a built or standing mechanism.
- When torn between a product opportunity and one of the other
  three, state the classification chosen and why, so the reader can
  override it.

### Step 4: classification

For each item that passed the gate:

| Field | How to determine it |
|---|---|
| Type | Feature, governance, infra or architecture, from the nature of the change needed |
| Priority | P1 blocks current work or live operations. P2 is needed for the next milestone. P3 is wanted with no immediate pressure |
| Reporter | Who raised it, plus a timestamp |
| Confirmed | Whether anyone else explicitly agreed |
| Existing reference | Cross-check against the backlog named in step 0. On a match, note it and skip, unless the new context adds something |

### Step 5: deduplication

Before generating the output, check the item against the backlog
named in step 0 and against any candidates file produced earlier. A
duplicate is either skipped or recorded as "enriches [reference]". A
new item gets a provisional number.

### Step 6: output

Produce a markdown file with this structure.

```markdown
# Backlog candidates: [source name and date]

Items identified from [source description].
[For review by <the decision-maker from step 0> before entry into the backlog.]

Provisional numbering: BC[start] to BC[end].

---

## Summary

| # | Title | Type | Priority |
|---|---|---|---|
| BC[N] | [title] | [type] | [priority] |

---

### BC[N]: [title]

| Field | Value |
|---|---|
| Type | [feature / governance / infra / architecture] |
| Reporter | [name], [timestamp] |
| Confirmed | [who confirmed, if anyone] |

**As a** [role],
**I want** [capability],
**so that** [benefit].

**Acceptance criteria**

- [criterion]

**Constraints and open questions**

- [if any]

**Dependencies**

- [if any]

---

## Screened out

Items raised in the source that did not pass the admission gate,
with their routing, so nothing is lost.

| Item | Classification | Rationale | Routed to |
|---|---|---|---|
| [item] | Bug / task / documentation | [one line] | [where it goes] |

## Already tracked

| Existing reference | Title | New context from this scan |
|---|---|---|
| [reference] | [title] | [what this scan adds] |
```

### Step 7: filename

`{context} - {YYYYMMDD} - Backlog Candidates v{NN}.md`, where
`{context}` is the product or programme named in step 0. For a
consolidation across several inputs, use the programme name and
`Backlog Consolidation` in place of `Backlog Candidates`.

If the user has their own naming convention, follow theirs.

---

## Writing the user stories

**Role.** Use the real roles gathered in step 0. "As a user" is the
fallback when no specific role applies, and it weakens the story
every time it is used by default.

**Want.** Describe the capability rather than the implementation. "I
want to forward an email into the system" beats "I want an Outlook
plugin".

**So that.** Describe the business benefit rather than the technical
outcome. "So that I can search the content the same day" beats "so
that it is indexed".

**Acceptance criteria.** Observable, testable behaviours.

**Constraints.** Technical limits, security considerations,
dependencies, attributed to whoever raised them, with a timestamp.

An item that does not fit the story format (a governance framework,
a process definition, an architectural constraint) is written
free-form with the same header fields.

---

## Quality checks before delivery

1. Every item has a reporter and a timestamp, or "chat context" when
   the source carries none.
2. No item duplicates an existing entry without adding new context.
3. Stories pass INVEST: independent, negotiable, valuable,
   estimable, small, testable. Flag the ones that are too large and
   suggest how to split them.
4. Priorities are justified rather than defaulted to P2.
5. Dependencies point at other candidates or at existing entries.
6. Every candidate passed the admission gate, and everything that
   did not is in the "Screened out" section with its routing.