Basic Cohub abilities. Most agents already have these mounted; listed here for reference.
Platform Published by the Neta team.
Official Made by the Neta team.
Verified Reviewed by the Neta team.
Community Shared by a Cohub user. Not reviewed — read SKILL.md before you use it.
questionnaire
Platformneta/questionnaire
Use it in Cohub
Paste this into your agent's chat — it fetches the skill and follows it.
Use the skill: questionnaire. Run `npx -y @neta-art/neta-search-cli@latest skills use neta/questionnaire --via site` and follow what it prints. Read its complete output, redirecting it to a temporary file first if necessary, and resolve relative paths from the skill directory it prints.
Install from a terminal
npx -y @neta-art/neta-search-cli@latest skills use neta/questionnaire
Summary
Before building, the agent asks you a few quick questions grounded in your own world, then builds from your answers.
Shows a short form beside the chat with 3 to 6 questions, most important first, so you can start answering right away.
Options name your real characters, places and works, such as a specific character or lighthouse, instead of vague placeholders.
Every question has a way out: type your own answer, or tap "Decide for me" and let the agent choose.
When words aren't enough, you get a page to look at or try instead, such as drafts side by side or a layout to compare.
You're asked once per task, and the agent then builds from your answers and tells you any small choices it made.
SKILL.md
# Asking the creator
You are here because the decision to ask is already made — by the core rule or by the skill you are
running. This file covers how: what to look at first, which form to use, and what to do with the
answer. Ask once, then build from the answers.
Size the round to the real ambiguity: the output, the scope, the audience, the fidelity, how many
variations. A question earns its place when its answer changes what you make.
## Pick the form
- **Questionnaire** — the choice reads as words: options a creator can pick from their labels, with
ready-made images only when a skill supplies them (style thumbnails via `styleIds`). Structured,
and it always offers `Other` and `Decide for me`.
- **Page** — the creator has to see or try something to decide: drafts or characters side by side,
a layout or palette to compare, a draft to mark up, a short interactive sample. Also for showing
what chat cannot hold, like a table too wide for it. You write it in HTML.
- Neither: one open detail is a chat question; anything the creator keeps, reopens, shares or plays
is a Work through its own skill; an answer, a recap or a single image is the reply itself.
One question per turn, in one form: never a questionnaire and a page together.
## See the world first, then ask
You are almost always inside a world that already exists, and that world is a premise of the work
rather than one of its options: every option you write lives inside it. Which world, which IP, which
setting, who is in it — look those up. How tightly a piece hugs canon is a fair question; which world
it belongs to is already answered.
So before writing a single question, look at the world as it now stands: who is in it, where, what
is already in motion, and what has been made from it. `neta atom list` / `neta work list` /
`neta find` read atoms and works cheaply; the world's own text is the body of `world/WORLD.md`;
relationships live in the atoms' Markdown bodies, so read for those; web Works are not in the index.
This look is cheap and it is required — it is the difference between a form the creator has to
translate and a round that already knows their world:
- When a question is about the world's own content, name the real thing. Not "a character" but Mira;
not "a location" but the drowned lighthouse; not "an existing work" but the prologue you already
published. An option the creator can picture beats an abstraction they must decode.
- Questions the world cannot answer stay plain. Scope, fidelity, format, how many variations, how it
should feel to play — those are genuinely still open, and world nouns make them worse. Local colour
is not a quota to fill.
- Ground the options; leave the question itself as open as the brief was. The world supplies material
for the answers, not a narrower thing to ask. Asked for "a work" in a world built on weaving, ask
what kind of work — a loom is one answer the creator might pick, not the frame you hand them. A stem
that assumes a medium or a setting they never named tends to contradict its own options, which is
how you catch it.
- Let the gaps suggest the questions: the character standing in no story, the conflict the prologue
names but never stages. A fact already on disk suggests nothing.
- Defer the expensive reads. Complete reference packages, every reference analysed, scaffolding
initialised — how much of that is warranted depends on the answers. Knowing what exists is cheap;
understanding what is inside waits.
- An empty world is the exception: with no atoms and no works yet, the open questions are real.
- Fold in what another skill would otherwise ask on its own — how to combine references, which scope
— so the creator meets it once, here.
Reflect briefly what you already understand, then ask once, without narrating your research.
Done when nothing you asked was already on disk. World-specific options are the by-product of having
looked, not a quota: a round whose scope and fidelity questions read plainly is right.
## Size of the round
Normally 3-6 questions; the protocol accepts 1-8. Size the round to the actual ambiguity — a
genuinely open brief warrants the full 6, a half-specified one may need only 3. Let the count fall
where the real uncertainties do.
Order most-important-first: the form streams in, so the creator can start answering before the rest
lands. Keep titles short; descriptions are optional clarifications.
One round per turn and one per complex task. Per-turn is enforced mechanically through
`COHUB_TURN_ID`; per-task is yours to hold — if you already ran a round for this piece of work,
carry those answers forward.
While a question is open — a questionnaire you are waiting on, or a page you just published — close
on it alone: no next-steps beside it, even where the skill you are running marks its closing step
required. Doors and open questions on one screen are two competing calls to action.
## What a good round looks like
Ask at the first point where the answer can still shape the work — the cheapest moment to change
direction, and the one that spares a wasted build. Bundle every real uncertainty into that one
round: serial interrogation across turns is the experience this replaces.
Derive from the world what the world can answer, and spend questions only on what it cannot. A
question earns its place by what its answer changes, not by making the plan feel safer.
Afterwards, make the minor calls yourself and name them in your summary. If a later discovery
contradicts an early answer, surface the contradiction rather than carrying the wrong assumption
forward.
## Questionnaire: authoring
Supported variants: `pills`, `cards`, `tiles`, `slider`, `date`, `text`.
- Prefer multiple choice: easier for the creator than a blank field.
- Every non-text question carries two escape hatches, visible from first render as peers of the real
options: an inline custom input (`Other`) and `Decide for me` (`__defer__`). They are force-enabled
for you — leave them out of the spec, and expect them whatever you send. Defer is mutually
exclusive with real options and custom text.
- `otherLabel` / `otherPlaceholder` only customise copy. Text is intrinsically custom input and
gets no duplicate Other.
- For `multi: true`, write copy that works when several are picked.
- `optional` allows omission; it is distinct from explicit Defer.
- Default to `pills` or `cards`. A slider fits when the stops are points on a single measured axis —
intensity, length, budget, fidelity — where more-versus-less is the whole meaning and a creator
would read it as a dial.
- Ordered alone does not make a dial. "Small prototype / full chapter / short game" is ordered, yet
each stop is a different deliverable with its own explanation, so it belongs in `cards`. The
give-away: a stop label carries no description in the UI, so an option that needs a sentence to be
understood belongs elsewhere.
- When a slider is right: sorted `marks` for every stop including both endpoints, max 12.
- `date` fits a real calendar date — a deadline, a launch day, an anniversary the story turns on.
Reach for it rarely: the calendar that opens is the browser's own and will not match Studio's look,
and "when should this land?" seldom needs day precision. Timing questions belong in `pills` —
"this week" / "this month" / "no rush". If you can name what happens on that exact day, it is a
date question; otherwise it is a `pills` question.
- Write warm, concrete, low-pressure copy in the creator's language. Lean their way: they can skip
anything, and the round should read like an offer rather than a gate.
- Default to text-only options. Image-bearing options (`tiles`/`cards` with `imageUrl`) fit when a
skill supplies ready-made images as their source material — a style-selection skill whose entries
already carry style images, say. Reaching for images to add visual appeal either stalls the round
on generation or leaves a broken, empty media area.
- When a skill does provide the images, `imageUrl` is gated source material rather than decoration:
include it once the asset was already in context and you inspected it and confirmed it matches the
option. A guessed URL, borrowed media, or empty image all land as a broken slot.
## Questionnaire: the call
Author the spec and ask in **one call**. `ask` validates its own input, so there is no separate
validation step; `--id` defaults to `q1`. The call returns `pending` as soon as the form is up
beside the chat, and that ends your turn: close on one short line, without next steps and without
repeating the questions in chat. Run nothing after it. The answer arrives as the next message.
```bash
node /mods/neta/neta questionnaire ask <<'JSON'
{
"title": "A few directions, then I build",
"questions": [
{ "id": "lead", "label": "Who does the player follow?", "variant": "pills",
"options": [
{ "value": "mira", "label": "Mira, at the drowned lighthouse" },
{ "value": "kaelen", "label": "Kaelen, the season before he turns" },
{ "value": "new", "label": "Someone new to this coast" }
] },
{ "id": "scope", "label": "How far this time?", "variant": "cards",
"options": [
{ "value": "proto", "label": "Small prototype", "description": "One core loop, playable straight away" },
{ "value": "chapter", "label": "Full first chapter", "description": "Onboarding, win/lose, restart" }
] },
{ "id": "play", "label": "How should it feel to play? (pick any)", "variant": "pills", "multi": true,
"options": [
{ "value": "explore", "label": "Explore & collect" },
{ "value": "tense", "label": "Tense, few resources" }
] }
]
}
JSON
```
Note what the shape is teaching: **Mira, Kaelen and the drowned lighthouse are not invented** — they
stand for atoms you actually read out of this world's index, and you replace them with the real
names you found. Scope and feel stay generic because those are genuinely still open. A round where
*every* option could have been written without opening the world is a round you did not research.
`title` plus 1-8 `questions` is the whole input; `intro` is optional. **Write the questions in the
creator's language** — this example is English only because the file is; match whatever language
they are writing to you in.
A slider stop needs a `value` aligned to `min`/`max`/`step` and a short `label`. Note what makes this
a dial rather than a list: the stops differ only in *how much*, and a creator can read the whole
scale without any of them being explained.
```json
{ "id": "grit", "label": "How much grit can the party take?", "variant": "slider",
"min": 1, "max": 5, "step": 1,
"marks": [
{ "value": 1, "label": "Cosy" },
{ "value": 2, "label": "Bruised" },
{ "value": 3, "label": "Bloody" },
{ "value": 4, "label": "Brutal" },
{ "value": 5, "label": "Merciless" }
] }
```
Scope — prototype versus full chapter versus short game — looks similar but reads as a list, not a
dial: those stops are different deliverables that each need a sentence, so they belong in `cards`.
Leave these out of the spec:
- `allowOther` / `allowDefer` — the two escape hatches are force-enabled for you whatever you send,
so writing them changes nothing. You cannot switch them off either: `allowOther: false` is
rejected outright.
- `version`, `turnId`, `requestId`, `status` — persisted envelope fields, not input. **Every object
in this spec is strict: one unrecognised key fails the whole thing.**
- `imageUrl` — a real field (https only), but gated by the rule above: default to text-only unless a
skill supplied the image as ready-made material.
For an unusually large spec, write the JSON to a file and pipe it instead of fighting a long
heredoc: `node /mods/neta/neta questionnaire ask < /tmp/questionnaire.json`.
`questionnaire validate < file` exists as a no-UI, non-blocking check. It is a debugging aid, not
part of the normal path — `ask` already validates.
If `ask` returns `{"ok":false,"error":...}`, the spec never reached the creator: nothing was written
and this turn's single slot is still free. Fix it and call again, up to twice. If it still fails, ask
the same questions inline in chat as one block, keeping the same way out — they can skip any of it,
or hand the choice back to you — and carry on from what they actually answer.
## Page: the call
Read `node /mods/neta/neta artifact publish --help` once before your first page: it holds the input
and the HTML rules, and publish rejects HTML that breaks them. What it means for the conversation:
- Studio opens the page in the same panel as questionnaires, in Studio's own look. A page with
fields gets a Submit button; a page without fields only shows. Call it a page to the creator.
- Publishing does not wait. A page with fields is this turn's question: end the turn on one short
line, and do not repeat its images, links or options in chat — the page shows itself.
- One page per decision. When it needs a change — the creator asked, or something on it was wrong —
republish that same page (`id` + `baseRevision`) as a new revision; that reopens it for a new answer.
- A page belongs to the conversation, not the world: it is never a Work, so it gets no handover
line and no link. It stays open beside the chat until it is answered, even while the
conversation moves on.
## Results
Both forms end the same way: the turn ends once the question is up, and the answer comes back as
the next message. Build from it; anything it left open is your call — say in one line what you
chose.
- A questionnaire's answer arrives as a message listing each question with what the creator picked
or typed. Briefly recap the choices that most shape the work, gently flag any answer you would
push back on, then build. "Decide for me" on a question hands that choice back to you.
- When they skip the whole questionnaire, the message says so: proceed on sensible defaults, state
them in one line, and do not re-ask or pressure.
- A page's answer arrives as a message headed with the page's title.
- Any other message is something else: answer it as usual. A message typed over an open
questionnaire replaces it, so do not ask it again; a page stays open for later.
- `unavailable` from `ask`: no form was shown, so the creator decided nothing. Ask the same
questions inline in chat as one consolidated block, and carry on from their answers.