Defines product requirements, business rules and acceptance criteria for a committed intent; edits product docs only.
日本語の概要は準備中です。原文の説明を表示しています。
Evaluates new product opportunities through demand, channels and economics before committing to build.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Goal: Evaluate product opportunities before implementation commitment. Start from observable demand and a reachable acquisition path, eliminate weak candidates early, and recommend one low-cost validation step without manufacturing market precision.
Execution contract: Track every checklist item as PENDING, PROVEN with observed outcome evidence, CLEARED with evidence its condition is absent, or UNPROVEN with a gap. Reading, delegation, tool failure, zero exit status, and self-reported success are not proof. Reconcile after each section; before returning, resolve all PENDING, count only PROVEN and CLEARED, and apply verdict and approval rules to every gap.
Preserve intent, scope, mode, and existing authorization. Complete authorized work before required external approval; ask only consequential unresolved choices. If nobody can answer, report the exact question and apply the skill's gap verdict without waiting or guessing. Cite any blocking instruction and unresolved boundary; never invent approval gates. Scale depth to material risk; preserve mandatory checks, dependencies, and safety order while choosing verification methods.
Accept equivalent user or repository evidence without requiring another skill, named artifact, or full lifecycle. Preserve source requirement and decision IDs. Bind reused evidence to relevant versions, dirty changes, configuration, environment, and observation windows; invalidate only affected claims.
Choose the primary workflow by outcome and explicit selection. Consume neighboring contracts and valid evidence without duplicating ownership or restarting audits. Split distinct deliverables by scope, not mandatory skill invocation. Broad independent assessments use audit workflows; focused domain reviews remain read-only.
On continuation, reconcile task, authorization, state, and gaps. Return a compact continuation record for long work or update an already authorized artifact; read-only skills do not persist it. Distinguish artifact readiness, verified behavior, and external-action authority.
Before retrieval, define the evidence question; read selectively without skipping applicable instructions. Use tools for mechanical processing; summarize bounded results, errors, coverage, and source paths, keeping full output outside context.
Before technical decisions, establish applicability and actual versions; verify version-dependent assumptions against official documentation or specifications. Search and read primary pages for current external recommendations; snippets are not evidence. Version-matched bundled documentation or valid prior evidence suffices. Record decision, version, source, and limitations. Mark unavailable evidence UNVERIFIED; block only essential dependent work. Prefer native mechanisms, justify added tools or abstractions with evidence, and reuse the existing rule owner.
| Need | Preferred tool | Use it when | Fallback |
|---|---|---|---|
| Product and constraints | User context plus existing product, analytics, customer, and strategy documents | Establishing audience, assets, channels, economics, and non-goals | State assumptions and request only consequential missing intent |
| Current demand and acquisition | Web research, trend or marketplace data, communities, reviews, ads, directories, and primary customer evidence | Every external market claim that affects elimination or recommendation | Mark the signal unavailable; never infer a number from search-result count |
| Competition and pricing | Competitor product pages, pricing, release history, distribution channels, reviews, and public filings where relevant | Establishing substitutes, willingness-to-pay signals, and credible differentiation | Use qualitative evidence with explicit confidence |
| Feasibility and validation cost | Existing capabilities, public APIs, regulations, platform rules, and current official documentation | Comparing the cheapest credible experiment and major blockers | Label estimates and name the evidence still required |
Keep the evaluation read-only. Do not create project files, roadmaps, Epics, Stories, implementation plans, campaigns, listings, advertisements, or customer outreach.
| Class | Meaning |
|---|---|
MEASURED | Direct analytics, transactions, experiments, or instrumented observations with known method and date |
REPORTED | A primary source reports a value or behavior, but the underlying measurement is not independently available |
ESTIMATED | A stated model based on explicit inputs and assumptions |
INFERRED | A qualitative conclusion from observable proxies |
UNKNOWN | Evidence is unavailable, stale, incomparable, or too weak to support a decision |
Do not turn REPORTED, ESTIMATED, or INFERRED evidence into a measured market size, search volume, conversion rate, revenue, or willingness-to-pay claim. Date every external source and distinguish the event date from the publication date when they differ.
Treat the creator thesis, intended experience, taste, and conviction as owner preferences and strategic-fit inputs, never as demand, acquisition, or willingness-to-pay evidence.
UNKNOWN under the rule below.UNKNOWN rather than labeling them invalid when a cheap primary experiment can resolve the uncertainty.INCONCLUSIVE.RECOMMEND <candidate> only when the candidate has a credible demand signal, reachable channel, differentiating path, plausible value exchange, and executable validation experiment.INCONCLUSIVE when candidates remain plausible but evidence cannot select among them or a cheap experiment is required; use DO_NOT_PURSUE only when evidence eliminates every candidate within scope.BLOCKED when the decision lacks product context, candidate scope, lawful research access, or a safe validation boundary.Report in the user's language, in this order; label all five fields and state each fact once. Use controlled plain language: one fact per sentence, usually under 20 words, active voice, and one term per concept, with no synonyms for verdicts, IDs, or states. Small results may use one line per field; omit empty tables and do not copy linked artifacts:
Checklist: X/Y complete; Incomplete: None or each UNPROVEN item's reason, outcome impact, and exact next action; residual risks and required decisions.Skill-specific evidence: Product, audience, candidates, constraints, and creator thesis separated from market evidence. Compare demand, channel, substitutes/wedge, economics, validation cost, source/date/class, and confidence. For eliminated or deferred candidates give decisive evidence or unknown and falsification/resolution condition. State the recommendation or inconclusive rationale and the proposed experiment contract, budget, stop rule, and decision-changing evidence; do not execute outreach or experiments.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Defines product requirements, business rules and acceptance criteria for a committed intent; edits product docs only.
日本語の概要は準備中です。原文の説明を表示しています。
Designs user flows, interaction states and mockups for a defined product scope; does not implement UI code.
日本語の概要は準備中です。原文の説明を表示しています。
Defines measurable architecture drivers and constraints before system design; edits architecture docs only.
日本語の概要は準備中です。原文の説明を表示しています。
Documents current architecture from implementation evidence; does not propose a target or audit fitness.
日本語の概要は準備中です。原文の説明を表示しています。
Designs target system boundaries, contracts and tradeoffs from requirements; does not plan tasks or implement.
日本語の概要は準備中です。原文の説明を表示しています。
Records one architecture decision with alternatives, consequences and status; does not design the whole system.
日本語の概要は準備中です。原文の説明を表示しています。