adversarial-feature-research

name

adversarial-feature-research

description

Use when a feature idea, spec, or implementation plan needs an adversarial review before or during delivery. This skill researches the feature as if trying to break the proposal, then reports holes, blockers, hidden dependencies, unrealistic assumptions, missing environments, missing contracts, required mockups, required synthetic data, and missing validation evidence. Use it to produce a structured go/no-go gap report for a feature that must actually work, not just look plausible on paper.

Adversarial Feature Research

Research the feature as if the default assumption is: the proposal is incomplete until proven otherwise.

The output is not a generic summary. It is a gap report focused on everything the feature still needs in order to work end-to-end.

When to use

Use this skill when the user wants any of:

• an adversarial feature review
• a pre-implementation feasibility check
• a report of hidden work or blocked assumptions
• a list of required mockups, fixtures, environments, or synthetic data
• an analysis of why a feature cannot yet be built or verified honestly

Do not use this skill for:

• a standard feature spec rewrite
• implementation once the open questions are already resolved
• a code review of finished code unless the review is specifically about missing prerequisites or false assumptions

Core stance

Treat every feature as having five failure surfaces:

1. The feature is underspecified.
2. The feature depends on systems, data, or contracts that do not exist yet.
3. The happy path exists, but verification is weak or fake.
4. The UI/demo path exists, but operational reality is missing.
5. The feature can be built locally, but not run end-to-end in a real workflow.

Your job is to find evidence for these failures.

Required workflow

1. Restate the feature in one short paragraph.
2. Identify the claimed user-visible outcome.
3. Identify the minimum end-to-end path required for the feature to be considered real.
4. Enumerate all required inputs:
   • systems
   • services
   • APIs
   • files
   • schemas
   • environments
   • credentials
   • contracts
   • test assets
   • sample or synthetic datasets
   • UI assets or mockups
5. Challenge each input:
   • Does it already exist?
   • Is it accessible?
   • Is it stable?
   • Is it trustworthy enough for verification?
   • Is it only implied rather than specified?
6. Identify hidden implementation work:
   • glue code
   • migrations
   • setup/bootstrap
   • contract generation
   • data seeding
   • tooling
   • observability
   • packaging/deployment
7. Identify blockers and classify them:
   • hard blocker
   • soft blocker
   • sequencing issue
   • validation gap
   • environment gap
8. Identify every artifact still needed to make the feature testable:
   • mockups
   • fixtures
   • synthetic data
   • contract examples
   • scripts
   • test harnesses
   • example requests/responses
   • telemetry expectations
9. Distinguish between:
   • needed to implement
   • needed to demo
   • needed to validate
   • needed to ship safely
10. End with a direct verdict:

• ready
• ready with conditions
• not ready

Research rules

• Prefer primary sources: repository code, specs, schemas, official docs, concrete configs.
• Do not assume missing infrastructure exists.
• Do not treat placeholders as working dependencies.
• Do not treat TODOs, stubs, fake endpoints, screenshots, or demos as proof.
• Call out where the proposal relies on mockups or synthetic data to proceed.
• If synthetic data is required, state exactly why, where it comes from, and what it must simulate.
• If mockups are required, state exactly what decision they unblock.
• If an end-to-end path cannot currently be run, say so plainly.

Output format

Use this exact section order.

Feature

One paragraph: what the feature claims to do and what "working" means.

End-to-End Reality Check

• Minimal real workflow
• What must already exist for that workflow to run
• What currently appears missing or uncertain

Holes

Flat bullet list of missing specifications, contracts, decisions, edge-case handling, operational details, or ownership gaps.

Blockers

For each blocker, include:

• type: hard / soft / sequencing / validation / environment
• why it blocks progress
• what artifact or decision removes the block

Hidden Work

Flat bullet list of work that the feature implicitly requires but the proposal does not clearly include.

Required Mockups

List every mockup still needed.

For each one, include:

• what must be mocked
• what decision it unblocks
• whether it is for implementation, review, or validation

If none are needed, say None.

Required Synthetic Data

List every synthetic dataset, fixture family, or seeded scenario still needed.

For each one, include:

• what it must represent
• why real data is unavailable or unsuitable
• what behaviors or edge cases it must cover
• whether it is for implementation, test, or demo

If none are needed, say None.

Validation Gaps

List what cannot currently be verified honestly and what evidence is still missing.

Recommended Next Moves

Numbered list of the smallest actions that convert the feature from speculative to workable.

Verdict

One of:

• Ready
• Ready with Conditions
• Not Ready

Then add a short paragraph explaining the verdict.

Severity guidance

Use these standards:

• hard blocker: feature cannot be built or run meaningfully without this
• soft blocker: feature can progress, but quality or correctness risk is high
• sequencing issue: work exists but prerequisites are in the wrong order
• validation gap: implementation may proceed, but proof of correctness is missing
• environment gap: the runtime, service, credential, or deployment context is missing

Adversarial prompts to apply during research

Ask these silently while researching:

• What part of this only works in a slide deck?
• What dependency is being assumed but not named?
• What data is required before the feature can be meaningfully exercised?
• What contract must exist before implementation can be safe?
• What would make the first end-to-end test impossible today?
• What would force the team to fabricate data or UI states?
• What evidence would I demand before calling this feature real?

Good skill behavior

• Be specific about missing artifacts.
• Separate speculation from evidence.
• Prefer concrete blockers over abstract risk language.
• Report uncomfortable truths early.
• Optimize for delivery honesty, not optimism.