# Idea To Design Doc

> Use when turning a rough idea into a focused product/design Markdown doc through guided questions, without moving into implementation too early.

- **Type:** Skill
- **Install:** `agentstack add skill-akoliteza-hermes-agent-idea-workflow-idea-to-design-doc`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [AkoliteZA](https://agentstack.voostack.com/s/akoliteza)
- **Installs:** 0
- **Category:** [Content & Media](https://agentstack.voostack.com/c/content-and-media)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [AkoliteZA](https://github.com/AkoliteZA)
- **Source:** https://github.com/AkoliteZA/hermes-agent-idea-workflow/tree/main/idea-to-design-doc

## Install

```sh
agentstack add skill-akoliteza-hermes-agent-idea-workflow-idea-to-design-doc
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Idea to Design Doc Workflow

Use this skill when the user says things like:
- "I have an idea for an app"
- "Help me flesh out this product"
- "Turn this thought into a design doc"
- "Make me a list of ideas and link each one to a note"

## Goal

Convert a rough idea into a structured design document with:
1. A master ideas index
2. One markdown note per idea
3. A guided interview that stops when the user says `stop`, `that's enough`, or `done`
4. The product idea, philosophy, intended experience, and practical technical shape needed to understand the app

This workflow starts with *product thinking* and only moves into technical aspects after the concept/philosophy is clear. The design doc should capture what the user wants and enough technical direction to support a later build plan.

## Important constraints

- Do **not** push into backend, frameworks, database design, or code architecture too early.
- First capture product intent, behavior, audience, layout, features, UX, and philosophy.
- Then, when drafting the design doc, include the relevant technical aspects: platform assumptions, major system components, data needs, integrations, constraints, and likely architecture questions.
- For Full mode or build-bound ideas, recommend sensible technical defaults first, then let the user accept or change them. Cover database/storage, hosting/deployment, backend/runtime, frontend/UI, auth, platform targets, and other technical pieces only after the product direction is clear.
- Ask one question at a time when possible.
- If the user gives a short answer, follow up with a narrower question.
- If the user says to stop, immediately draft the note from what you have.

## Default storage layout

Save files locally first, rather than directly into the Obsidian vault.

Recommended local folder structure:

- `./ideas/Ideas Index.md`
- `./ideas/.md`

If the user later wants Obsidian export, treat that as a separate export step.

## Lite vs Full mode

Use **Lite mode** for quick idea capture: ask only enough to produce a useful note. Use **Full mode** when the user wants a durable design doc or eventual implementation handoff.

The user can force the next stage with the exact phrase **GREENLIGHT NEXT STAGE**. If they use it, stop questioning, draft with current information, and record gaps under **Open questions**.

## Interview flow

Ask questions in this order, adapting to the user's answers. For stronger prompts, use `idea-superpowers-suite/references/interview-question-bank.md`:

1. **Working title**
   - "What should we call this idea for now?"
2. **Problem / purpose**
   - "What problem does it solve, or what is it for?"
3. **Audience**
   - "Who is it for?"
4. **Core behavior**
   - "What should it do when someone uses it?"
5. **Primary user flow**
   - "What is the main thing a user should be able to do from start to finish?"
6. **Key features**
   - "What are the must-have features?"
7. **Layout / organization**
   - "How should the main parts be arranged or grouped?"
8. **Data location / hosting preference**
   - "Should the data stay local, be self-hosted, go to Cloudflare/AWS/another cloud, or is that undecided?"
9. **Platform targets**
   - "Should this be web-only, or should it also have a Windows app, Mac app, cross-platform desktop app, mobile app, or responsive mobile web?"
10. **Recommended technical defaults**
   - "Based on this idea, I recommend these technical defaults: . Do you want to accept them or change any part?"
11. **Preferences / feel**
   - "Should it feel simple, playful, serious, fast, calm, etc.?"
12. **Non-goals**
   - "What should this *not* do?"
13. **Success criteria**
    - "How will you know this idea is good enough to move forward?"

## Interview style

Use prompts like:
- "Tell me more about that part."
- "What would happen next?"
- "Can you give an example?"
- "Is that a must-have or a nice-to-have?"
- "Do you want it to be simple or more feature-rich?"

If the user is unsure, offer lightweight options instead of open-ended pressure:
- "Do you want this to be more like a list app, an overview page, or a single-focus tool?"
- "Should users see everything at once, or step through it one section at a time?"

## Stop condition

If the user says any of the following, stop interviewing and draft immediately:
- stop
- that's enough
- enough for now
- done
- draft it
- write it up
- GREENLIGHT NEXT STAGE

## Output format

When drafting, produce a markdown note with this structure:

```markdown
# 

## One-line summary

## Problem / purpose

## Product philosophy

## Target user

## Core concept

## Desired behavior

## Key features

## Layout / information architecture

## UX / product notes

## Technical shape

## Data / integrations / platform needs

## Hosting / data location

## Platform targets

## Recommended technical defaults

## Non-goals

## Open questions

## Next steps
```

## Master index format

Maintain `Ideas Index.md` as a simple bullet list of idea notes:

```markdown
# Ideas Index

- [[Idea Title]] — short one-line summary
- [[Another Idea]] — short one-line summary
```

If the index file exists, append the new idea in alphabetical or newest-first order, but stay consistent.

## Suggested response behavior

During the interview:
- Be conversational and concise.
- Ask a question, then wait for the user's answer.
- Keep the scope on product/design thinking.

When the user stops:
- Summarize the idea clearly.
- Capture uncertainties under **Open questions**.
- Save the note locally.
- Add/update the local index.
- Give the user the local note path.

## Quality bar

A good result should make it easy to revisit the idea later and immediately understand:
- what it is
- who it is for
- how it should behave
- what matters most
- what is intentionally out of scope

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [AkoliteZA](https://github.com/AkoliteZA)
- **Source:** [AkoliteZA/hermes-agent-idea-workflow](https://github.com/AkoliteZA/hermes-agent-idea-workflow)
- **License:** MIT

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-akoliteza-hermes-agent-idea-workflow-idea-to-design-doc
- Seller: https://agentstack.voostack.com/s/akoliteza
- 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%.