# Quaere Invention > This skill should be used whenever the user asks for a non-obvious approach, an alternative architecture, a research direction, a product or monetization idea, an agent-skill design, or any "not just the obvious solution" / "発想を広げたい" / "普通じゃない解法" / "brainstorm alternatives" / "アイデア出し" request where the agent is likely to converge on the first average answer. It forces the agent to name the defaul… - **Type:** Skill - **Install:** `agentstack add skill-haru0416-dev-quaere-quaere-invention` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [haru0416-dev](https://agentstack.voostack.com/s/haru0416-dev) - **Installs:** 0 - **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [haru0416-dev](https://github.com/haru0416-dev) - **Source:** https://github.com/haru0416-dev/quaere/tree/main/skills/extensions/quaere-invention - **Website:** https://quaere.dev ## Install ```sh agentstack add skill-haru0416-dev-quaere-quaere-invention ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Invention Probe ## Iron Law **No idea is promoted as novel without naming four things: the default basin it escapes, the assumption it breaks, the mechanism of the break, and the smallest probe that could disconfirm it. An idea that cannot name all four is `recombination` at best — not invention.** This is not a creativity ritual. Asked for something new, a model regresses toward the mean of its training distribution and dresses the common answer in impressive-sounding language; empirically, LLM assistance even homogenizes ideas across different users *(Anderson, Shah & Kreminski 2024 — arXiv:2402.01536)*. "Novel-sounding" is also not the same as good: creativity evaluations find novelty correlates weakly or negatively with quality and diversity, so it must be scored as its own axis *(CreativityPrism — Hou et al. 2025, arXiv:2510.20091)*. The gate changes the evaluation axis from *does this sound impressive* to *which specific default did this leave, and can it be killed*. Divergence without the kill-probe is just confident averaging; the probe is what separates an invention from a nicer-sounding default. Full research basis: `references/research-basis.md`. ## When to use - The user wants a non-obvious approach, alternative architecture, or design the obvious path does not reach. - Research directions, product ideas, monetization paths, or agent-skill designs are being generated before a plan is committed. - The work is at risk of converging on the first plausible answer ("settling too early"). - The user explicitly asks to widen the option space, escape the obvious, or break out of an approach that feels stuck. ## When NOT to use - Factual lookup or current SDK/API/CLI behavior; use `quaere-grounding`. - A small implementation edit, or a plan that is already chosen and just needs building; use `quaere-execution`. - A bug whose cause is not yet understood; use `quaere-evidence` — do not "invent" around an unknown cause. - Cases where the obvious answer is correct and the only cost is wanting it to look clever. Inventing here adds risk, not value. ## Handoff triggers (which skill comes after this one) Invention ends at a small set of candidates with kill-probes, not at a built thing. Hand off when the next step changes discipline: - A surviving candidate needs current external facts (does this library/API/pattern actually exist or behave this way) → `quaere-grounding`. - A candidate needs to be tested or disconfirmed as a claim before commitment → `quaere-evidence` (run the kill-probe there). - A candidate is chosen and authorized to build → `quaere-execution`. - No candidate is testable yet → stop and report the option space and what evidence would unlock a decision; do not build. The standard handoff payload (Blocking question / Confirmed inputs / Inconclusive inputs / Required next skill / Stop condition) is documented at the end of this file under "Handoff to other skills". ## Core procedure Run the steps in order. Each step's output is named so the next step (and any reviewer) can audit it. Keep it tight — output length should match the number of live candidates, not an imagined brainstorming quota. ### 1. Default basin State the boring answer the model would produce by default. Naming it is what makes "escaping it" auditable later. - Default answer: - Why it is attractive (why the model lands here): - Why it may be insufficient: ### 2. Constraint frame Separate what cannot move from what only feels fixed. - Hard constraints (real, externally imposed): - Soft preferences (movable, often mistaken for hard): - Non-goals: - Forbidden shortcuts (cheats that would game the goal): ### 3. Assumption inventory List the assumptions that make the default feel inevitable. Each is a candidate to break in step 4. Tag each with its kind, because different kinds break differently. - A1 — — kind: structural | economic | UX | technical | social | evaluation - A2 — ... - A3 — ... ### 4. Mutation passes Generate candidates by forcing a named mechanism against a named assumption. Use **at least four** different operators. The full operator catalog with worked mini-examples is in `references/mutation-passes.md`; the operators are: - **Inversion** — make the opposite of the default useful. - **Subtraction** — remove a part assumed necessary. - **Transfer** — import a structure from another domain. - **Recomposition** — split the system and reconnect it differently. - **Constraint shift** — optimize a different bottleneck. - **Adversarial design** — assume the obvious solution will be gamed. - **Temporal shift** — move work earlier, later, or into a background loop. Each candidate must name: - broken assumption (by ID from step 3) - mechanism (which operator, and how) - expected gain - likely failure mode ### 5. Novelty filter Classify every candidate. The label is a finding, not a compliment. Do not oversell `recombination` as invention. - `known pattern` — already a named, common solution. - `recombination` — a new mix of known parts. - `locally novel` — likely new for this context, not in general. Permitted only if the candidate carries a falsifiable kill-probe (step 6) whose kill signal could actually occur; the label is earned by *designing* a probe that could disconfirm it — never by self-assessment. The probe itself runs downstream in `quaere-evidence`, so until it has run, emit the label as `locally novel (unprobed)`. Without a kill-probe at all, downgrade to `genuinely uncertain`. - `genuinely uncertain` — cannot tell if it exists; needs grounding. - `incoherent` — does not actually hold together; drop it. **Forbidden:** asserting an idea is "truly novel", "groundbreaking", "revolutionary", or otherwise self-rating its originality. Use the five labels only. If you want to claim general novelty, that is a `quaere-grounding` task (prior-art search), not a self-assessment. ### 6. Probe design For the best 1–3 candidates, define the smallest test that could kill the idea — not confirm it. - Probe: - Success signal: - Kill signal: - Cost: - What evidence would change the decision: A candidate with no kill-probe is not ready to promote; mark it `genuinely uncertain` and hand off to grounding/evidence. ## Output format ```text Invention probe - Default basin: - Constraints: hard / soft / non-goals / forbidden shortcuts - Assumptions: A1..An with kinds Candidates - K-001: Broken assumption: Mechanism: Expected gain: Failure mode: Novelty: known pattern | recombination | locally novel (unprobed) | genuinely uncertain | incoherent - K-002: ... Probes (top 1-3) - P-001 for K-00x: Probe / Success / Kill / Cost / Decision-changing evidence Handoff - ``` ## Common drift modes and anti-patterns The recurring ways a divergence skill collapses back into hype — overselling recombination, generating volume instead of mechanism, skipping the kill-probe, self-rating novelty — are in `references/anti-patterns.md`. Read it when output starts to feel impressive rather than auditable. ## Worked example A full invention pass on a concrete prompt (default basin → assumptions → four mutation passes → novelty labels → kill-probe → handoff) is in `references/worked-example.md`. Read it when the step outputs feel abstract. ## Handoff to other skills When handing off, emit this standard block: ``` Handoff - From skill: quaere-invention - Blocking question: - Confirmed inputs: - Inconclusive inputs: - Required next skill: - Stop condition: ``` - A surviving candidate depends on whether an external pattern/library/API actually exists or behaves as assumed → `quaere-grounding` with the candidate and the unconfirmed external claim. - A candidate is a testable hypothesis that should be disconfirmed before commitment → `quaere-evidence` with the candidate as a claim and its kill-probe as the disconfirming probe. - A candidate is chosen and building is authorized → `quaere-execution` with the candidate, the constraints from step 2, and the kill-probe as a verification. Invention ends at options with kill-probes. It does not pick the winner for the user, and it does not build. Naming the option space and the probes is the deliverable. ## Stop condition The skill is complete when: - The default basin is named (step 1). - At least four mutation passes produced candidates, each naming broken assumption / mechanism / gain / failure mode. - Every candidate carries a novelty label from the fixed five, with no self-rated "truly novel" language; any candidate labeled `locally novel` carries its own falsifiable kill-probe rather than a self-rating, and stays marked `(unprobed)` until that probe has run downstream. - The top 1–3 candidates each have a kill-probe. - A handoff or an explicit "not testable yet" stop is stated. Do not keep generating once the option space is covered and the survivors have probes. More candidates past that point is volume, not invention. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [haru0416-dev](https://github.com/haru0416-dev) - **Source:** [haru0416-dev/quaere](https://github.com/haru0416-dev/quaere) - **License:** MIT - **Homepage:** https://quaere.dev 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-haru0416-dev-quaere-quaere-invention - Seller: https://agentstack.voostack.com/s/haru0416-dev - 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%.