Create Superpowers Lite fork

This commit is contained in:
mujing
2026-05-12 16:05:03 +08:00
parent f2cbfbefeb
commit dd2eb8b351
33 changed files with 221 additions and 399 deletions

View File

@@ -1,6 +1,6 @@
---
name: brainstorming
description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
description: "Manual-only skill. Activate only after an explicit user request for superpowers-lite:brainstorming or Superpowers Lite brainstorming."
---
# Brainstorming Ideas Into Designs
@@ -10,7 +10,7 @@ Help turn ideas into fully formed designs and specs through natural collaborativ
Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
When this skill was explicitly activated, do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it.
</HARD-GATE>
## Anti-Pattern: "This Is Too Simple To Need A Design"
@@ -26,7 +26,7 @@ You MUST create a task for each of these items and complete them in order:
3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
4. **Propose 2-3 approaches** — with trade-offs and your recommendation
5. **Present design** — in sections scaled to their complexity, get user approval after each section
6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
6. **Write design doc** — save to `.superpowers-lite/specs/YYYY-MM-DD-<topic>-design.md` and keep it out of git
7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
8. **User reviews written spec** — ask user to review the spec file before proceeding
9. **Transition to implementation** — invoke writing-plans skill to create implementation plan
@@ -108,10 +108,11 @@ digraph brainstorming {
**Documentation:**
- Write the validated design (spec) to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`
- Before writing files, ensure `.superpowers-lite/` is listed in `.git/info/exclude` when the project is a git repository
- Write the validated design (spec) to `.superpowers-lite/specs/YYYY-MM-DD-<topic>-design.md`
- (User preferences for spec location override this default)
- Use elements-of-style:writing-clearly-and-concisely skill if available
- Commit the design document to git
- Do not commit generated design documents unless the user explicitly asks
**Spec Self-Review:**
After writing the spec document, look at it with fresh eyes:
@@ -126,7 +127,7 @@ Fix any issues inline. No need to re-review — just fix and move on.
**User Review Gate:**
After the spec review loop passes, ask the user to review the written spec before proceeding:
> "Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
> "Spec written to `<path>` as a local, untracked artifact. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.