capture-idea

name

capture-idea

description

Use when the user wants to externalize a brainstorming conversation into a new project folder. Triggers include "capture this as a project", "let's start a folder for this", "jot this down as an idea", "put this somewhere I won't forget". Creates a folder via project-tracker's `create_project` MCP tool and writes summary files derived from the conversation substance. Distinct from `superpowers:brainstorming` (which explores an idea) - this is the externalization step that takes brainstorm output to disk. Uses the project-tracker MCP server when available; otherwise creates the folder directly and records it in ~/.project-tracker/projects.json.

capture-idea

Externalize a brainstorming conversation into a durable, project-tracker-indexed folder. This skill turns "we were just talking about a cool idea" into a folder on disk containing the conversation substance, an elevator pitch, and a starter plan.

When this skill fires

Triggers are the user saying things like:

• "capture this as a project"
• "let's start a folder for this"
• "jot this down as an idea"
• "put this somewhere I won't forget"
• "I want to come back to this later"

The skill is distinct from superpowers:brainstorming (which explores an idea conversationally) and from superpowers:writing-plans (which produces an implementation plan from an approved spec). It sits between them: brainstorm → capture-idea → later maybe → writing-plans.

Relationship to the brainstorming HARD-GATE

The superpowers:brainstorming skill's HARD-GATE forbids invoking implementation skills before a spec is approved. capture-idea is NOT an implementation skill. It writes notes, not code. It produces no spec for implementation - it externalizes conversation substance so it isn't lost. Invoking capture-idea during or after a brainstorm does not violate the gate.

Workflow

1. Confirm intent. Pose a single yes/no: "Capture this as a project under <proposed-name>? Or keep going first?" Avoid premature externalization when the user is still mid-thought.

2. Propose folder name and parent dir. Derive a kebab-case folder name from the core idea. Use the default parent dir unless the user specifies otherwise. Let the user override either.

3. Call the create_project MCP tool.

   • Required: name
   • Optional: parent_dir, description (one-line), status (defaults to incubating)
   • Returns: {path, project_id, status, warning}. If warning is non-null, relay it to the user verbatim.
   • If the MCP server is unavailable, create the folder yourself (mkdir -p <parent_dir>/<name>) and append {name, path, status, description} to ~/.project-tracker/projects.json (create the file with [] if missing). The registry is an agent-maintained convention for installs without project-tracker: the agent creates it, appends to it, and reads it; the project-tracker tool itself never touches this file (its own store is a SQLite database under ~/.project_tracker/ - note the underscore). If the user later installs project-tracker, entries promote into the real tracker with project-tracker project register <path>.

4. Write files at your judgment. No rigid trio. The three files below are strong defaults - include them unless the conversation clearly doesn't call for them, and add others (e.g. RESEARCH.md) if useful:

   • README.md - one-paragraph elevator pitch, current status, table of contents pointing to sibling files.
   • BRAINSTORM.md - the thinking log. Arguments, pushback from both sides, tangents, half-baked threads, open questions. Near-verbatim from the conversation, not sanitized into executive-summary prose. This is the high-value artifact - don't flatten it.
   • PLAN.md - open tasks in project-tracker's checkbox format, including research questions. Writing this is the payoff for project-tracker's existing plan detection.

5. Report back. Return:

   • Folder path
   • Files written (list)
   • project-tracker project ID (or the registry entry, in fallback mode)
   • One-line "next step" suggestion (continue brainstorming, pick up later via find-task, etc.)

Errors from create_project

If the tool raises:

• ValueError / FileExistsError - relay the message to the user and offer to retry with a different name or parent dir. Do not retry automatically.
• warning in the return dict - relay verbatim so the user knows the folder won't be auto-rediscovered during project-tracker scan.

Out of scope for this skill

• Git init (the promote-project skill covers this)
• Language scaffolding, LICENSE, .gitignore, linters/hooks, CI, remotes - promote-project handles all of it once the stack is decided
• Moving existing files into the new folder
• Editing existing idea folders (regular file editing is fine)
• Templates - for v1, file choice is pure LLM judgment

PLAN.md format (project-tracker integration)

To flow into project-tracker's existing plan detection, write PLAN.md with checkbox syntax:

# <project-name> - Plan

## Inbox

- [ ] First open task or question
- [ ] Second task
- [ ] Research: link to prior art X

project-tracker.find_open_tasks will pick these up on the next scan.