# X9 Idea Critic

> Use only when the user explicitly asks to criticize, red-team, pressure-test, or find reasons an idea may fail — «раскритикуй идею», «найди слабые места», «red-team this idea». Do not trigger for ordinary brainstorming, balanced evaluation, implementation review, or when the user only asks to improve an idea.

- **Type:** Skill
- **Install:** `agentstack add skill-xonika9-agent-skills-x9-idea-critic`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [xonika9](https://agentstack.voostack.com/s/xonika9)
- **Installs:** 0
- **Category:** [Web & Browser](https://agentstack.voostack.com/c/web-and-browser)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [xonika9](https://github.com/xonika9)
- **Source:** https://github.com/xonika9/agent-skills/tree/main/skills/x9-idea-critic
- **Website:** https://skills.sh/xonika9/agent-skills

## Install

```sh
agentstack add skill-xonika9-agent-skills-x9-idea-critic
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Idea critic

Criticize through the routes the user selected. Opus and GPT are independent perspectives with different error profiles; neither route is a fallback or a quality tier.

## Select mode

For `/x9-idea-critic [mode] [idea]`, treat the first argument as a mode only when it is one of the recognized words below. Otherwise it is part of the idea. Natural-language requests map to the same modes.

| Mode | Natural-language examples | Critics |
|---|---|---|
| default / omitted | «раскритикуй идею», «проверь на прочность» | one fresh Opus critic and one fresh GPT critic |
| `opus` | «раскритикуй опусом» | one fresh Opus critic |
| `gpt` | «спроси GPT», «раскритикуй через GPT» | one fresh GPT critic through Codex |
| `full` | «разнеси по полной», «панель критиков» | 2–3 critics from each provider with distinct lenses |

For `full`, use feasibility/execution, user or market demand, and devil's-advocate/simpler-alternative lenses as applicable. Tell the user that this mode is slower and heavier, then start as much parallel work as the host capacity permits.

## Sealed brief

Give each critic the same bounded brief:

- the proposal in neutral language;
- intended user/outcome and observable success criterion;
- known constraints, evidence, and source paths/URLs;
- the critic's job: identify invalidating assumptions, failure modes, relevant competition, a cheaper or simpler path to the same outcome, the most likely practical cause of failure, and the cheapest disconfirming tests;
- required output: `KILLER`, `SERIOUS`, `MINOR`, evidence/uncertainty, and a verdict.

Exclude advocacy and solution-selling from the critic's role, but do not omit factual context that would make the critique a straw man. A critic making factual claims must be able to read the cited repository artifacts or live sources.

## Runtime routes

- **From Claude Code:** run the Opus route in a fresh Opus agent with only the sealed brief. Run the GPT route through `x9-codex-delegation`; it owns the current Codex mechanics and delegation log.
- **From Codex:** run the Opus route in a fresh non-persistent Claude CLI session when available and explicitly pass `--effort high`; do not inherit Codex's bounded-worker effort or the user's Claude CLI effort setting. When the CLI accepts the brief on stdin, materialize only the sealed brief in an OS temporary file created with `mktemp`, restrict it to the current user, and pass it through stdin rather than argv. Install cleanup with a shell trap or equivalent `finally` block before writing the brief, then verify the file is gone after success, failure, or interruption. Never store this transport file in the repository, logs, or user artifacts. Run the GPT route through the native subagent interface after following the active global subagent contract; use `fork_turns: "none"` and request a supported model/effort only when exposed by the live schema.

Use the current configured model unless the user selected an exact available version. Do not pass the surrounding conversation. Pass only the sealed brief and explicit evidence locations. Do not disable tools when repository or source verification is load-bearing; grant only the read surfaces needed.

## Failure and synthesis

- Retry a failed route once only when the failure is transient and the retry changes something concrete.
- Judge completeness against the selected mode. A successful `opus` or `gpt` run is `COMPLETE`; it is not degraded merely because the user requested one critic.
- In default mode, one missing route yields `DEGRADED`. In `full`, a missing requested provider or lens yields `DEGRADED`.
- If every requested route fails or no critic can inspect the load-bearing evidence, return `BLOCKED` with verdict `NOT_PROVEN`; do not manufacture a substantive verdict from the orchestrator's prior beliefs.
- Keep attribution: show which critic raised each invalidating point and whether the other independently agreed.
- Resolve duplicate wording, not disagreement. Surface material conflicts and judge them against evidence.
- Keep the synthesis concise by grouping overlap and separating required changes from optional improvements, not by dropping findings or dependencies that could change the verdict.

## Output

1. Status: `COMPLETE`, `DEGRADED`, or `BLOCKED`.
2. Verdict: `KILL`, `REVISE`, `SURVIVES`, or `NOT_PROVEN` when blocked.
3. Invalidating findings with evidence and attribution.
4. Serious/minor risks.
5. Cheapest tests that could falsify the remaining assumptions.
6. Missing evidence and unresolved disagreement.
7. For `REVISE`, give a concrete revision agenda covering all findings upheld during synthesis. Distinguish changes required to address `KILLER` and `SERIOUS` findings from optional improvements, accepted risks, or deferred work associated with `MINOR` findings. Group overlapping work and show dependencies; do not cap the number of changes or omit necessary architecture work for brevity. For `SURVIVES`, recommend only changes justified by the findings and distinguish them from risks that can reasonably be accepted. For `KILL`, do not manufacture a rescue plan.

`COMPLETE` requires every critic requested by the selected mode and traceable evidence for factual claims. Never silently substitute a different route or fewer critics.
When a CLI transport file was used, completion also requires confirming that it no longer exists.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [xonika9](https://github.com/xonika9)
- **Source:** [xonika9/agent-skills](https://github.com/xonika9/agent-skills)
- **License:** MIT
- **Homepage:** https://skills.sh/xonika9/agent-skills

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-xonika9-agent-skills-x9-idea-critic
- Seller: https://agentstack.voostack.com/s/xonika9
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.