# Ideas

> Use when the user prompts "write ideas" or "make ideas".

- Skill: `romeerez/ideas` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add romeerez/ideas`
- Raw SKILL.md: https://api.skillmd.com/api/skills/romeerez/ideas/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: romeerez (https://skillmd.com/u/romeerez)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/romeerez/ideas

---


Read an existing `changes/<feature-name>/research.md` and write or update `changes/<feature-name>/ideas.md`.

**Input**: The argument after `/ideas` should identify an existing researched change. It may be:

- A free-form feature or topic name
- A change folder name
- A short user description that clearly points to an existing researched change

Examples:

- `/ideas row level security`
- `/ideas 611-row-level-security-integration`
- `/ideas composite foreign keys in relations`

**Goal**

Produce an ideas document that turns the existing research into a prioritized list of user-facing ideas for later proposal, design, and implementation work.

The existing `research.md` is the source of truth. Use it to understand the topic well, then distill only the ideas that clearly follow from it.

By "ideas", we mean user-facing goals, proposals, or features. This document is not an implementation plan.

Every listed idea must:

- Add concrete value for the end user on its own
- Be clear about why it matters in the researched topic
- Be framed from the interface or product-design perspective
- Be accessible to a human reader without relying on unexplained shorthand or jargon
- Avoid implementation details unless they are necessary for high-level understanding

If two partial ideas only make sense together, combine them into one idea instead of listing both.

**Steps**

1. **Identify the target change folder**

   Search `changes/` for the existing folder that best matches the user's input.

   Prefer:
   - An exact folder-name match
   - A folder whose name clearly matches the described feature
   - A folder that already contains `research.md`

   If multiple folders are plausible, stop and ask the user which one to use.
   Do not guess when the match is ambiguous.

   If no relevant researched change exists, tell the user that no matching `changes/<feature-name>/research.md` was found.
   Do not create a new change folder here.

   The output path is `changes/<feature-name>/ideas.md`.

2. **Read the existing research thoroughly**

   Read the full `research.md` before drafting anything.

   Use it to understand:
   - The problem being solved
   - The intended user-facing outcome
   - Which capabilities appear essential vs optional
   - The main user pain points or constraints
   - What orchid-orm already supports and what is missing

   Pay special attention to:
   - `Purpose and goals`
   - `Requirements and edge cases`
   - `Existing support in orchid-orm`
   - `Proposed user-facing design`

   `Valuable external context` and `Community ideas and pain points` matter only insofar as they help clarify what ideas are justified in the research document itself.

3. **Derive candidate ideas from the research**

   Extract only ideas that are clearly supported by the research.

   Good ideas are:
   - User-facing capabilities
   - Clear product or interface proposals
   - Distinct pieces of value a user could understand and want

   Exclude:
   - Internal implementation tasks
   - Refactors
   - Infrastructure work with no standalone user value
   - Open questions presented in the research but not resolved enough to become an idea
   - Anything that requires adding assumptions beyond the research

   Do not split a single cohesive capability into multiple ideas unless each part independently adds value to users.
   If an idea only matters because another idea exists, it should likely be part of that larger idea.
   Prefer wording that a human can understand on first read.
   If the research uses dense shorthand, rename the idea or explain it later in `How`.

4. **Categorize the ideas**

   Use up to these three categories and in this order:
   - `Must haves`: ideas that are required for the feature to function in a meaningful way
   - `Valuables`: ideas that clearly improve the feature for users, but the main purpose is still achievable without them
   - `Nice to have`: extra convenience or narrower-scope ideas that are beneficial but not essential

   Skip any category that has no supported ideas.

   A lower-priority category must not contain an idea that higher-priority ideas depend on.
   If that happens, reclassify the blocking idea upward or merge the ideas.

5. **Prioritize and connect the ideas**

   Within each category, order ideas by:
   - First: ideas that do not depend on another listed idea
   - Then: ideas that depend on earlier ideas
   - Throughout: higher-concept importance first

   The ordering should make conceptual sense for the feature, not read like a task list.

   For every idea, determine which earlier ideas it depends on.
   Only list ideas that actually appear earlier in the document.
   If none, say `None`.

6. **Write or update `ideas.md`**

   If `changes/<feature-name>/ideas.md` already exists, read it now, preserve any still-supported ideas, remove unsupported or stale content, and reconcile the document with the current `research.md`.

   If the file does not exist yet, create it.

   Use this structure:

   ```md
   # <Feature Title>

   ## Must haves

   ### 1. <Idea title>

   - Why: <Why this idea matters for the researched feature.>
   - Adds: <What user-facing value or capability this idea adds.>
   - How: <How the idea would work or be experienced from the user's perspective. Use a short list instead if multiple ingredients are needed to make the idea understandable.>
   - Depends on: <Comma-separated earlier idea titles, or `None`.>

   #### Use cases (optional)

   - <Brief scenario that shows the problem and how this idea solves it.>
     <Optional minimal code example if it genuinely helps.>

   ## Valuables

   ### 2. <Idea title>

   - Why: <Why this idea matters for the researched feature.>
   - Adds: <What user-facing value or capability this idea adds.>
   - How: <How the idea would work or be experienced from the user's perspective. Use a short list instead if multiple ingredients are needed to make the idea understandable.>
   - Depends on: <Comma-separated earlier idea titles, or `None`.>

   **Use cases**: (one or more, optional)

   - <Brief scenario that shows the problem and how this idea solves it.>
     <Optional minimal code example if it genuinely helps.>

   ## Nice to have

   ### 3. <Idea title>

   - Why: <Why this idea matters for the researched feature.>
   - Adds: <What user-facing value or capability this idea adds.>
   - How: <How the idea would work or be experienced from the user's perspective. Use a short list instead if multiple ingredients are needed to make the idea understandable.>
   - Depends on: <Comma-separated earlier idea titles, or `None`.>

   #### Use cases (optional)

   - <Brief scenario that shows the problem and how this idea solves it.>
     <Optional minimal code example if it genuinely helps.>
   ```

   Document guidance:
   - Use the research title for `# <Feature Title>` when it is clear
   - Keep every field concise and specific
   - `Why` should explain importance in the context of this researched topic
   - `Adds` should explain the concrete user-facing value
   - `How` should make the idea easier for a human to picture, especially when the title or `Adds` could still feel abstract
   - Keep `How` at a user-facing level; mention workflow or API shape only when it genuinely clarifies the idea
   - If `How` needs multiple ingredients, use a short list instead of cramming them into one sentence
   - `Depends on` should name earlier ideas exactly as written, or `None`
   - Add `Use cases` when they make the idea clearer
   - Every use case should briefly show the situation, state how the idea solves it, and may include a minimal code example
   - If there are multiple distinct use cases, list all of them
   - If there is only one useful use case, include just one
   - If the idea is simple and already self-explanatory, skip `Use cases` instead of adding filler
   - Do not add category intros unless they are genuinely useful
   - Do not include implementation steps, acceptance criteria, or internal architecture

7. **Quality check**

   Before finishing, verify:
   - The file was written to the correct `changes/<feature-name>/ideas.md` path
   - The chosen change folder is the best match for the user's input
   - Every listed idea is clearly supported by `research.md`
   - No idea depends on unstated assumptions outside the research
   - Each idea adds standalone user value
   - Categories are correct and empty ones were skipped
   - Ordering reflects conceptual priority and dependency
   - `Depends on` only references earlier ideas that the current idea truly relies on
   - `How` makes ambiguous ideas more understandable without turning them into implementation plans
   - `Use cases` are present when they add clarity, and omitted when they would just repeat the idea
   - The document stays at the user-facing or interface-design level
   - Implementation detail appears only when necessary for high-level understanding
   - Idea titles are `###` headings prefixed with numbers, and numbering continues across categories without restarting

**Guardrails**

- Do not do new research for this command
- Do not inspect orchid-orm code or docs to invent additional ideas
- Do not create a new change folder
- Do not treat unresolved questions as settled ideas
- Do not add ideas just because they sound useful
- Do not split ideas too finely
- Do not turn this into a proposal, design doc, or implementation plan
- Ask a focused clarifying question if the target folder is ambiguous
- If the research does not justify any concrete user-facing ideas, say so instead of inventing filler