Turn a decision you can't fully answer into a questionnaire for someone else to fill in.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
Turn something the user can't answer alone into a questionnaire — a Markdown document they hand to one person to fill in async, or fill out together over a meeting. The recipient holds knowledge the user lacks; the questionnaire pulls it out of them.
Grill the send, not the subject. Interview the user only about the send, which they can always answer: who it goes to, and what they need back. The questions in the document then target the gap between what the recipient knows and what the user needs.
Who is it going to? Ask, in one exchange, the recipient's role, expertise, and relationship to the user. This fixes the questionnaire's tone and how much context it must carry. Done when you know who the recipient is and what they know that the user doesn't.
What do you need back? Ask, in one exchange, the specific decisions or facts the user can't resolve alone and needs from this person. Done when you have a concrete list of what the user must walk away able to do or decide.
Write the questionnaire. Draft questions aimed at the gap from steps 1–2, following the Document structure below. Write it to to-questionnaire-<slug>.md in the current directory (slug from the topic) and report the path. Done when the file exists and every item the user named in step 2 is covered by a question.
Frame the document as a discovery questionnaire: the user lacks context, the recipient holds it. Order questions most-important-first — async means you may only get one pass — and group them under ## headings by theme once there are more than a handful. Write it using the template below.
Purpose: why this questionnaire exists and the decision riding on it.
From: <the user> — To: <the recipient> — How your answers will be used: <where they go>
One paragraph orienting a recipient who wasn't in the user's head. Enough to answer well, not a page.
Deadline and rough effort. Partial answers and "I don't know" are useful — flag anything you're unsure of rather than skipping it.
One ## section per theme. Under each, its questions, most-important-first. Every question is one idea — never compound — with an answer stub directly beneath, and a one-line why this matters only where the question could be misread or invite a throwaway answer.
Why this matters: it decides whether we provision for burst traffic now or defer it.
</question-example>
A closing catch-all: anything we didn't ask that we should know?
</questionnaire-template>아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
使用 AACT (Aggregate Analysis of ClinicalTrials.gov) PostgreSQL 数据库进行大批量临床试验历史分析与数据挖掘。触发场景包括：AACT 查询、临床试验批量分析、PostgreSQL 试验数据、全量 NCT 检索、试验数据挖掘、clinical trials data warehouse、疾病领域全景分析、设计相似试验匹配、跨年度试验趋势聚合。本 skill 通过 SQL 接口处理百万级试验记录，支持云端公共 PostgreSQL 服务（aact-db.ctti-clinicaltrials.org）和每日 dump 本地还原两种连接方式，自动检测并优先使用本地高性能模式。
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
使用 AACT (Aggregate Analysis of ClinicalTrials.gov) PostgreSQL 数据仓库进行批量、历史、聚合性临床试验数据挖掘。Use this skill when the user requests bulk SQL analysis over the full clinical trials data warehouse — historical trial trends, disease landscapes, similar-design matching, or multi-year aggregations across hundreds of thousands of NCT records. 触发场景包括：AACT 查询、临床试验批量分析、PostgreSQL 试验数据、全量 NCT 检索、试验数据挖掘、历史试验分析、clinical trials data warehouse、SQL trials、bulk trial analysis、disease landscape、试验设计相似性匹配、跨年度聚合、sponsor/phase/country 多维统计。**与 clinical-trials-v2 差异**：本 skill 走批量 SQL · 离线大数据（PostgreSQL）；v2 走实时 API · 单查询。两者互补：单条 NCT 实时状态用 v2，百万级历史挖掘用本 skill。支持云端公共 PostgreSQL（aact-db.ctti-clinicaltrials.org · 零部署）和每日 dump 本地还原（高性能 · 离线）两种连接方式，自动检测优先用本地。跨平台（macOS/Linux/Windows）参数化 SQL 防注入，read-only 强制保护。
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use when work produces a deliverable, factual claim, dataset, code change, decision, publication, deployment, automation, or irreversible action whose failure would matter; when the user asks for a quality gate, acceptance criteria, QA, completeness, validation, audit, evidence, preflight, release readiness, or a definition of done; or before claiming completion on medium- or high-risk work. Automatically decide whether a formal gate is warranted, derive task-specific pass/fail criteria, gather evidence, and block unsupported completion. Make sure to use this skill even when the user does not say "quality gate" if consequential work needs acceptance criteria or completion evidence. Skip formal gating for trivial, reversible, low-impact requests.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Create a changeset file in .changeset/ that describes a user-facing change for the release notes
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Add a new competitor to the AI Visibility Tool Directory — researches the tool, generates data, takes a screenshot, and inserts into the codebase
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Add tree-sitter language support to codegraph end-to-end — wire the grammar + extractor, write tests, then benchmark extraction quality and retrieval value on 3 popular real-world repos. Use when the user runs /add-lang <language> or asks to add/support a new language (e.g. Lua, Elixir, Zig, OCaml) in codegraph.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.