# Ops Feature Request Collector

> Use when a user in a legal AI chat session expresses a desire for a new feature, capability, or improvement. Guides the assistant through detecting feature-request language, gathering structured context, tagging by category and persona, submitting to the product backlog (Linear), and aggregating requests for weekly prioritization — distinct from bug reports which go to the bug collector.

- Skill: `sboghossian-mini-claude-for-legal/ops-feature-request-collector` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sboghossian-mini-claude-for-legal/ops-feature-request-collector`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sboghossian-mini-claude-for-legal/ops-feature-request-collector/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: sboghossian (https://skillmd.com/u/sboghossian-mini-claude-for-legal)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/sboghossian-mini-claude-for-legal/ops-feature-request-collector

---


# Ops — Feature Request Collector

## When to use this

Activate when a user's message contains any of the following patterns (or close semantic equivalents):

- "I wish Louis could…"
- "Can you add…"
- "It would be great if…"
- "Why doesn't Louis have…"
- "Other tools do X, why can't you?"
- "Is there a way to…" (when the answer is no, and the user seems to expect yes)
- "Will you support…"

Do not activate for existing feature questions ("how do I use X?") or for bug reports ("X isn't working"). Route those to [[ops-bug-report-collector]] if applicable.

## Collection flow

### 1. In-chat acknowledgement

At the next natural turn break, confirm you heard the request and ask permission to log it:

> That sounds like a useful feature. Mind if I log it for the product team?
>
> [**Yes, log it**]  [**No thanks**]

If the user says yes, proceed. If no, thank them and move on — do not pressure or re-ask in the same session.

### 2. Context gathering

Ask up to four clarifying questions, keeping the interaction brief:

1. "What specifically would you like the feature to do?"
2. "How often would you use it?" (daily / weekly / occasionally)
3. "How would you use it — in what kind of work?" (drafting / review / research / client communication / etc.)
4. "Any examples from other tools you've seen?"

Capture the user's own words. Do not paraphrase or reframe in legal jargon.

### 3. Auto-tagging

Tag the feature request automatically:

| Tag dimension | Values |
|--------------|--------|
| Category | `UI` / `drafting` / `review` / `research` / `integration` / `collaboration` / `export` / `analytics` / `settings` |
| Persona | `lawyer` / `in-house` / `consumer` / `student` / `enterprise-admin` |
| Tier | `free` / `starter` / `pro` / `business` / `enterprise` |
| Jurisdiction | Infer from user context if available |
| Effort estimate | `small` (UI tweak) / `medium` (feature) / `large` (platform change) — rough auto-estimate only |

Persona and tier are inferred from the user's account profile, not asked.

### 4. Linear submission

Create a Linear issue in the `LOUIS-FEATURES` project:

- **Title**: Short feature name in the form "User can [do X]" (e.g., "User can export draft to Google Docs")
- **Description**: User's exact words + context tags + source ("collected in-chat by feature-request-collector skill")
- **Labels**: category tag + persona tag + tier
- **Priority**: set to P3 by default; the product team triages to P2/P1/P0 based on aggregation
- **Linked to user profile**: so the team can follow up and also count how many users have requested this feature

### 5. User confirmation

After submission:

> Logged it. We'll evaluate it for the roadmap. Would you like us to let you know if it gets added?
>
> [**Yes please**]  [**No thanks**]

If they opt in, store the notification preference against the Linear issue.

## Aggregation

The feature request log is reviewed weekly by the product team. The aggregation process:

1. **Cluster similar requests**: group Linear issues by semantic similarity (e.g., multiple users asking for Google Docs integration).
2. **Count unique requesters**: a feature requested by 10 users outweighs the same feature requested once, even if the wording differs.
3. **Surface trending requests**: requests that received 3+ new instances in the last 7 days are surfaced in the Linear weekly digest.
4. **Cross-reference with NPS feedback**: detractors requesting missing features signal high-priority gaps.

## Prioritization signals (for the product team)

When the product team triages the collected requests, they use:

| Signal | Weight |
|--------|--------|
| Number of unique requesters | High |
| Requesters on paid tiers (Pro/Business/Enterprise) | High — their retention has higher revenue impact |
| Strategic fit with roadmap | High |
| Estimated engineering cost | Medium |
| Competitive differentiation | Medium |
| Requests from NPS detractors | High — these are features whose absence is causing dissatisfaction |

## Privacy

- Store only the feature description and metadata, not the full conversation context.
- User IDs stored against requests are anonymized tenant-scoped identifiers.
- Users who opt out of data collection can still submit requests — just without the follow-up notification.

## Related skills

- [[ops-bug-report-collector]] — the parallel flow for issues (not features)
- [[ops-linear-triage-from-chat-bug-report]] — downstream triage workflow
- [[ops-nps-collector-in-chat]] — NPS detractor feedback often surfaces feature gaps
- [[ops-feature-flag-experiment-launcher]] — high-priority feature requests often become experiments