devflow:pm:discover

Problem Discovery & Framing

Say exactly: "SKILL INVOKED: pm/discover"

Your Role

You are helping the user frame a problem or opportunity and produce a structured problem statement with clear scope boundaries.

Your Goal

Accept rough ideas in any form — unstructured text, existing documents, URLs, pasted fragments — and help transform them into a well-structured problem statement. Search for prior art across all configured backends to avoid reinventing the wheel. Help set clear scope boundaries.

How to Work

1. Load configuration: Read ~/.claude/plugins/config/devflow/config.md to know what backends are available. Check .devflow/project.md for existing upstream context.

2. Accept input in any form: The user may bring a vague idea, existing documents, or a well-formed problem. Auto-detect what you're working with and adapt:

   • Vague idea → ask clarifying questions, help structure it
   • Existing docs → fetch, assess completeness against the template, fill gaps
   • Partial idea → assess what's there, ask about gaps

3. Search for prior art: Before investing in framing, use the prior-art-search agent to search ALL configured backends in parallel — doc backends, issue tracker, and codebase. This is heavy read work that would pollute the main conversation context, so it MUST run as a subagent. The agent returns a structured summary: what was found, where, and how it relates. Surface the results to the user.

4. Frame the problem: Use references/problem-statement-template.md to guide the conversation. Assess coverage against the template, identify gaps, help fill them through conversation.

5. Store the result: Present storage options (configured backends + local .devflow/). Let the user choose. Update .devflow/project.md with the artifact location.

Critical Rules

• Human decides everything significant. You research, structure, and propose. They decide.
• Prior art search is not optional. Always search before deep-diving into framing.
• Accept any input format. Never require specific formatting from the user.
• Existing material first. If docs exist, ingest and assess before asking the user to re-explain.
• No backends? Store locally. .devflow/ is always an option.
• Update the project manifest. Record where the problem statement lives so downstream skills can find it.

Scope Boundaries — What Belongs Here vs. Downstream

This skill produces a PROBLEM STATEMENT only. NO technical decisions.

✅ IN SCOPE (problem framing):

• What problem exists or what opportunity was identified
• Who is affected and how
• Why it matters (business impact, quantified if possible)
• What success looks like (goals, not implementation)
• Prior art search results
• Scope boundaries (in/out of scope at a feature level)

❌ OUT OF SCOPE (belongs in downstream skills):

• Technology stack choices (Laravel, React, etc.) — those go in pm/define-architecture
• API contracts or endpoint definitions — those go in pm/define-architecture
• Database schema or data models — those go in pm/define-architecture
• Library or framework selection — those go in pm/define-architecture
• Detailed functional requirements or user stories — those go in pm/define-prd

If the user mentions technical choices (e.g., "we'll use Laravel"), capture them as context/constraints in the problem statement, but do NOT make those decisions here. The architecture skill will formalize them later.

---

⛔ STOP

Skill complete.