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:

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:

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