Decision Questionnaire Skill for Hermes Agent: Async Stakeholder Input

When a decision stalls because the facts live in someone else's head, you need a way to extract those facts without a live meeting. The Decision Questionnaire skill turns that blocked decision into a Markdown document you hand to one person to fill in async, or fill out together in a meeting. It is built for the moment you catch yourself saying "I need to ask X about this" and then deferring the call for another week.

What it does

The skill produces a questionnaire, not an answer. The recipient holds knowledge you lack, and the document is structured to pull it out of them. The agent interviews you about the send (who it goes to, what you need back), then drafts questions aimed at the gap between what the recipient knows and what you need to decide. The output is a Markdown file written to decision-questionnaire-.md in the current directory, with the absolute path reported back to you.

This is a discovery questionnaire by design. It assumes you lack context and the recipient has it, so questions are ordered most-important-first. Async recipients fade, and you may only get one pass, so the critical question cannot be buried.

Before you start

This is an optional skill, installed on demand rather than shipped by default. The skill path is optional-skills/productivity/decision-questionnaire, version 1.0.0. It runs on linux, macos, and windows. The license is MIT, and the skill is ported from mattpocock/skills' MIT-licensed to-questionnaire skill, with credit to Matt Pocock.

There are no stated permission requirements or platform limits beyond the platform list. The practical prerequisite is that you can name a specific person who holds the missing knowledge. If you cannot, the skill has nothing to work with.

How the interview works

The core principle is to interview the send, not the subject. You cannot answer the subject-matter questions, which is the entire reason the document exists. But you can always answer questions about the send. The agent runs two short exchanges:

1. Who is it going to? Role, expertise, relationship to you. This fixes the questionnaire's tone and how much context it must carry. The exchange is done when the agent knows who the recipient is and what they know that you do not.
2. What do you need back? The specific decisions or facts you cannot resolve alone. Done when there is a concrete list of what you must walk away able to do or decide.

After those two exchanges, the agent writes the questionnaire. The draft is done when the file exists and every item from step 2 is covered by a question.

Document structure

The questionnaire follows a fixed template. Group questions under ## headings by theme once there are more than a handful.

# <Questionnaire title>

**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>

## Context

One paragraph orienting a recipient who wasn't in the user's head. Enough
to answer well, not a page.

## How to answer

Deadline and rough effort. Partial answers and "I don't know" are useful:
flag anything you're unsure of rather than skipping it.

## <Theme heading>

### <One question — a single idea, never compound>

_Why this matters: <one line, only where the question could be misread or
invite a throwaway answer>._

>

## Anything else?

A closing catch-all: anything we didn't ask that we should know?

Every question gets an answer stub (>) directly beneath it. The stub is what makes the document fillable rather than just readable.

Pitfalls to avoid

The source lists five failure modes. They are worth reading before you draft, because each one is easy to commit by accident.

1. Grilling the user about the subject. You cannot answer it, which is why the document exists. Only interview the send.
2. Compound questions. One idea per question. Split "and/or" questions.
3. Burying the critical question. Most-important-first, because async recipients fade.
4. Context dump. One orienting paragraph, not the whole history.
5. Skipping the "why this matters" line on ambiguous questions. That line is what turns a throwaway answer into a useful one, but do not add it to questions that are already unambiguous.

Verification checklist

Before you send the questionnaire, confirm the following:

• Recipient's role and knowledge, plus the needed outcomes, captured in two exchanges before drafting
• Every step-2 item covered by at least one question
• Questions single-idea, most-important-first, answer stubs present
• File written and absolute path reported to you

When not to use it

Do not reach for this skill when the answer is discoverable from the environment: the codebase, the docs, or the web. Find it yourself first. The questionnaire is for knowledge held by another person, not for knowledge you simply have not looked up yet.

Limits and gotchas

The skill depends on you naming a recipient and articulating what you need back. If either is vague, the draft will be vague. The two-exchange interview is deliberately short, so arrive with the recipient's role and a concrete list of outcomes in mind. The most-important-first ordering is a hard constraint, not a stylistic preference: async means you may only get one pass, and a buried critical question may never come back answered.

What pairs with it

If the questionnaire surfaces action items rather than answers, the related skills meeting-action-items and document-to-action-items cover that conversion. They are the natural next step once the filled-in document comes back.