菜单
Use when intake has identified the likely lifecycle path but the problem statement, solution direction, or key trade-offs are still too fuzzy for requirements, research, or architecture work to start cleanly
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a bug, failing test, regression, or unexpected behavior needs a root-cause-first debugging loop before code changes, especially when brownfield seams, recent releases, or historical defect matches make guesswork unsafe.
Use when E2E tests must go beyond shallow happy-path checks — multi-step user journeys, stateful sessions, cross-boundary state consistency, failure-mode edges — or when the suite passes but production still breaks. Platform- and framework-agnostic (web, mobile, desktop; Playwright, XCUITest, Cypress).
Use when discovery has narrowed an idea enough that the team must make a go/no-go, pivot, or scope-down decision based on technical, economic, operational, or timeline viability before requirements, architecture, or major implementation.
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
Use when discovery needs evidence about market demand, competitors, pricing pressure, or underserved segments for a new product or expansion idea before feasibility, user research, or requirements are finalized.
Use when discovery needs evidence about target users, behaviors, and pain points, especially after intake or problem-framing surfaces open questions that must be validated before requirements are written
| name | pc-problem-framing |
| description | Use when intake has identified the likely lifecycle path but the problem statement, solution direction, or key trade-offs are still too fuzzy for requirements, research, or architecture work to start cleanly |
| metadata | {"phase":"00-discovery","inputs":["intake-brief"],"outputs":["problem-frame","options-brief","design-direction"],"prerequisites":["pc-intake"],"quality_gate":"Approved problem frame and recommended design direction recorded with trade-offs, assumptions, open questions, and next lifecycle destination","roles":["product-manager","tech-lead","architect"],"methodologies":["all"],"effort":"medium"} |
Turn an approved intake route into a crisp problem statement and a small set of decision-ready options.
Problem framing sits immediately after pc-intake when routing is clear but the work is still underspecified.
See context and anti-pattern notes.
I/O contract notes define required inputs and authority.
Review the intake brief before asking anything new.
Extract:
Ask questions one at a time.
Default budget:
Focus on:
Do not restate intake questions unless the answer is still ambiguous or conflicting.
Produce a concise problem-frame covering:
The canonical problem-frame record stays in English under current repo policy, but user-facing framing output may still be presented in the user's locale. Carry source_language, artifact_record_language, and user_presentation_locale forward explicitly.
Carry quality_target_context forward explicitly when it affects scope, risk, or downstream QA. If the target is an agent-internal skill, host runtime tool, or local harness, do not let problem framing drift into a public service design unless the user chose that product target.
The problem frame must be sharp enough that downstream skills do not have to rediscover the core problem.
Use plain language, present user-facing output in the user's requested language or the user_presentation_locale, and explicitly note system shape or collaboration quality when they materially affect the framing.
Produce an options-brief with 2-3 plausible directions.
For each direction, note:
Keep these at the level of product or solution direction, not low-level implementation detail.
Record a design-direction that includes:
pc-market-analysis, pc-user-research, pc-feasibility-study, or pc-requirements-engineering)When the route depends on team boundaries, ownership clarity, workflow friction, or architectural sprawl, say so directly as a collaboration quality or system shape concern instead of hiding it inside generic risk wording.
Ask the user to confirm the framing and chosen direction.
After approval, hand off the framing artifacts to the next skill named in the design-direction.
Produce only declared outputs at their documented quality boundary.
problem-frame states the problem, constraints, non-goals, assumptions, and open questionsoptions-brief compares 2-3 viable directions with explicit trade-offsdesign-direction recommends one direction and names the next skill to invoke