quaere

This skill should be used whenever the user wants a plan, claim, design, decision, PR, or their own understanding adversarially pressure-tested before committing — grill me, poke holes in this, challenge my thinking, play devil's advocate, red-team my plan, stress-test this, 詰めて, 反論して, この設計の穴を突いて — or when an agent should grill its OWN proposed plan before shipping it. It runs an evidence-gated interrogation that decomposes the target into load-bearing claims, attacks the most decisive one with falsifier-seeking and alternative-hypothesis questions, and refuses to bless it until each load-bearing claim has survived a named challenge backed by new evidence or a defended rebuttal, or been logged as an explicit unresolved gap, never flipping a claim to survived on confident-but-unverified pushback. Intensity is calibrated to stakes. Do not use to cooperatively flesh out a vague under-specified idea (use deep-interview) or to self-investigate an unexplained bug (use quaere-evidence).

This skill should be used whenever the user asks what to build next, what feature, tool, or product is missing, where the opportunities are in a codebase or domain, or makes any 0→1 origination request — 次に何を作るべきか, what should we build, this repo is missing something, find the gaps, surface opportunities — where the agent would otherwise answer with a generic, ungrounded wishlist (add tests, add CI, add dark mode) instead of a real gap. It forces every proposed opportunity to name a gap verified to exist in the actual system, the beneficiary and the job they are blocked on, evidence the demand is real rather than assumed, and the smallest probe that would validate or kill it before any build, classifying each as verified gap, assumed gap, already covered, or wishlist. Trigger before a problem is chosen; for non-obvious solutions to an already-chosen problem, use quaere-invention instead.

This skill should be used whenever the user asks to investigate unclear bugs, defend or reject PR review comments, triage CI failures or flaky tests, review risky/security/database/concurrency/external-API changes or multi-file refactors, or make any claim that needs evidence before patching. It enforces a falsifiable Finding → Hypothesis / Review Claim → Defense → Probe → Decision → Patch → Verification → Handoff workflow so the agent does not jump to fixes, accept plausible but unverified explanations, or publish noisy review comments.

This skill should be used whenever the user authorizes multi-step coding implementation: applying a plan, finishing a feature, implementing review feedback, writing tests, making a refactor, fixing a bug whose cause is already confirmed, or turning a specification into working code. It enforces a Plan → Do → Study → Act implementation loop with scoped units, fresh verification evidence, diff review, fix loops, and commit/push discipline so the agent does not blind-patch, batch unrelated changes, claim success without tests, or commit unless explicitly authorized. Do not use for trivial one-line edits, command-only requests, or pure explanations.

This skill should be used whenever implementation or review depends on external, version-sensitive facts: libraries, SDKs, APIs, CLIs, cloud services, security advisories, changelogs, release notes, or documentation that may have changed. The skill anchors local versions, ranks source quality, runs an executable probe and a lateral corroborator before promoting any claim to `confirmed`, and turns confirmed facts into implementation constraints. Trigger when the task depends on any external surface whose freshness binds correctness — model memory is not evidence. Also trigger when the user names a model, package, API, or version identifier the agent does not recognize: unfamiliar names likely post-date training and must be verified, not corrected.

This skill should be used whenever the user asks to "read", "review", "explore", "understand", "explain", "全文レビュー", "意味を分析", or "コード探索" in depth, or whenever implementation requires understanding existing code's intent before changing it. The skill forces per-symbol meaning analysis — splitting mechanical behavior from domain intent, naming invariants and failure modes, mapping backward and forward slice — so the agent does not paraphrase code as understanding. Trigger when surface-level scanning would produce a wrong edit.

This skill should be used whenever the user asks for a serious security audit, vulnerability review, bug bounty triage, threat-model-driven code review, protocol/spec conformance audit, auth/authz or tenant-isolation review, exploitability analysis, CVE/advisory impact assessment, or security-sensitive PR review when exploitability or a security property must be proven. It coordinates a property-driven audit: scope and rules of engagement → security properties → attack surface → source/boundary/sink or guard mapping → proof attempt → false-positive gates → severity/confidence → safe repro/report, with companion handoffs for external facts, semantic invariants, evidence-gated claims, and authorized PoC/fix work.

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 default basin it is escaping, break the assumptions that make that default feel inevitable through structured mutation passes, classify each candidate's novelty honestly, and design a kill-probe before promoting any idea — so divergence does not collapse into hype. Trigger when settling on the obvious solution too early would be the failure.

This skill should be used whenever the user needs to name a product, SaaS tool, brand, library, open source project, CLI, bot, or app, or asks to rename or rebrand a product or project, find a brand name, pick a product name, or escape generic AI-slop names. It enforces a metaphor-driven process that establishes a naming brief before generating anything, explores conceptual territories instead of thesaurus synonyms, filters anti-patterns, verifies availability with real tool checks instead of guessing from memory, and presents only vetted finalists that each carry a metaphor origin story. Trigger when the user says name this, what should we call it, we need a brand name, give me naming ideas, or the current names sound generic. Do not use for renaming code symbols, variables, functions, files, or branches inside an existing codebase.