Receber por email
← Voltar para o catálogo

absolute-brainstorm

Ultrathink reasoning, codebase-first intelligence, strict dependency-resolved interviews, and flexible exit

185estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add AbsolutelySkilled/AbsolutelySkilled

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/absolute-brainstorm/svg)](https://www.skillteca.com.br/skills/absolute-brainstorm)
#ai

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

When this skill is activated, always start your first response with the brain emoji.

Absolute Brainstorm

Activation Banner

At the very start of every absolute-brainstorm invocation, before any other output, display this ASCII art banner:

 █████╗ ██████╗ ███████╗ ██████╗ ██╗     ██╗   ██╗████████╗███████╗
██╔══██╗██╔══██╗██╔════╝██╔═══██╗██║     ██║   ██║╚══██╔══╝██╔════╝
███████║██████╔╝███████╗██║   ██║██║     ██║   ██║   ██║   █████╗
██╔══██║██╔══██╗╚════██║██║   ██║██║     ██║   ██║   ██║   ██╔══╝
██║  ██║██████╔╝███████║╚██████╔╝███████╗╚██████╔╝   ██║   ███████╗
╚═╝  ╚═╝╚═════╝ ╚══════╝ ╚═════╝ ╚══════╝ ╚═════╝    ╚═╝   ╚══════╝
██████╗ ██████╗  █████╗ ██╗███╗   ██╗███████╗████████╗ ██████╗ ██████╗ ███╗   ███╗
██╔══██╗██╔══██╗██╔══██╗██║████╗  ██║██╔════╝╚══██╔══╝██╔═══██╗██╔══██╗████╗ ████║
██████╔╝██████╔╝███████║██║██╔██╗ ██║███████╗   ██║   ██║   ██║██████╔╝██╔████╔██║
██╔══██╗██╔══██╗██╔══██║██║██║╚██╗██║╚════██║   ██║   ██║   ██║██╔══██╗██║╚██╔╝██║
██████╔╝██║  ██║██║  ██║██║██║ ╚████║███████║   ██║   ╚██████╔╝██║  ██║██║ ╚═╝ ██║
╚═════╝ ╚═╝  ╚═╝╚═╝  ╚═╝╚═╝╚═╝  ╚═══╝╚══════╝   ╚═╝    ╚═════╝ ╚═╝  ╚═╝╚═╝     ╚═╝

Follow the banner immediately with: Entering plan mode - ultrathink enabled

A relentless, ultrathink-powered design interview that turns vague ideas into bulletproof specs. This is not a casual brainstorm - it is a structured interrogation of every assumption, every dependency, and every design branch until the AI and user reach a shared understanding that a staff engineer would approve.

When to use this skill

Trigger this skill when the user:

  • Requests a new feature, component, or functionality that needs design before implementation
  • Asks to build something and the scope or approach is not yet clear
  • Wants to brainstorm or explore options for a design decision
  • Is starting a greenfield project and needs to define architecture
  • Needs to refactor or redesign an existing system
  • Says "let's think through this" or "help me plan this"
  • Wants to decompose a complex request into a validated spec before coding

Do NOT trigger this skill for:

  • Quick bug fixes or typo corrections where the solution is obvious
  • Pure code review tasks with no design decisions
  • Tasks where the user explicitly says "just do it" and the scope is trivially clear

Hard Gates

<HARD-GATE>

  1. ALWAYS enter plan mode at the start of this skill. Do not proceed in normal mode.
  2. ALWAYS use extended thinking (ultrathink / think hard) before every question,

every decision, every approach proposal, and every design section. No exceptions.

  1. Do NOT invoke any implementation skill, write any code, scaffold any project,

or take any implementation action until the spec is written and the user has approved it. This applies to EVERY project regardless of perceived simplicity.

  1. ALWAYS continue asking questions and ultrathink until BOTH the user AND the AI

are 100% confident and in full agreement on the design decisions. If either party has any doubt, uncertainty, or unresolved concern - keep interviewing. Do not advance to design presentation while any ambiguity remains. </HARD-GATE>

Anti-Pattern: "This Is Too Simple To Need A Design"

Every project goes through this process. A todo list, a single-function utility, a config change - all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.

Checklist

You MUST complete these steps in order:

  1. Enter plan mode
  2. Deep context scan - read docs/, README.md, CLAUDE.md, CONTRIBUTING.md, recent commits, project structure
  3. Codebase-first exploration - before every question, check if the codebase already answers it
  4. Scope assessment - if the request spans multiple independent subsystems, decompose first
  5. Relentless interview - one question at a time, strictly linear, dependency-resolved, ultrathink every decision
  6. Approach proposal - only when there's a genuine fork; mark one (Recommended) with rationale
  7. Confidence self-check - ultrathink through every decision, verify 100% confidence before presenting
  8. Design presentation - section by section, user approval per section
  9. Write spec - save to docs/plans/YYYY-MM-DD-<topic>-design.md
  10. Spec review loop - dispatch reviewer subagent, fix issues, max 3 iterations
  11. User reviews spec - gate before proceeding
  12. Recommend absolute-human - strongly recommend delegating to absolute-human for execution

Process Flow

digraph absolute_brainstorm {
    rankdir=TB;
    node [shape=box];

    "Enter plan mode" -> "Deep context scan";
    "Deep context scan" -> "Scope assessment";
    "Scope assessment" -> "Decompose into sub-projects" [label="too large"];
    "Scope assessment" -> "Relentless interview" [label="right-sized"];
    "Decompose into sub-projects" -> "Relentless interview" [label="first sub-project"];
    "Relentless interview" -> "Genuine fork?" [shape=diamond];
    "Genuine fork?" -> "Propose approaches\n(mark Recommended)" [label="yes"];
    "Genuine fork?" -> "Next question or\ndesign presentation" [label="no, obvious answer"];
    "Propose approaches\n(mark Recommended)" -> "Next question or\ndesign presentation";
    "Next question or\ndesign presentation" -> "Relentless interview" [label="more branches"];
    "Next question or\ndesign presentation" -> "Confidence self-check" [label="tree resolved"];
    "Confidence self-check" -> "Relentless interview" [label="doubts remain"];
    "Confidence self-check" -> "Present design sections" [label="100% confident"];
    "Present design sections" -> "User approves section?" [shape=diamond];
    "User approves section?" -> "Present design sections" [label="no, revise"];
    "User approves section?" -> "Write spec to docs/plans/" [label="yes, all sections"];
    "Write spec to docs/plans/" -> "Spec review loop\n(subagent, max 3)";
    "Spec review loop\n(subagent, max 3)" -> "User reviews spec";
    "User reviews spec" -> "Write spec to docs/plans/" [label="changes requested"];
    "User reviews spec" -> "User chooses next step" [label="approved"];
}

Phase 1: Deep Context Scan

Before asking the user a single question, build comprehensive project awareness.

Mandatory reads (if they exist):

  • docs/ directory - read README.md first, then scan all files
  • README.md at project root
  • CLAUDE.md / .claude/ configuration
  • CONTRIBUTING.md
  • docs/plans/ - existing design docs that might overlap
  • Recent git commits (last 10-20)
  • Package manifests (package.json, Cargo.toml, pyproject.toml, etc.)
  • Project structure overview (top-level directories)

What you're looking for:

  • Existing patterns, conventions, and architectural decisions
  • Tech stack and dependencies
  • Testing patterns and CI setup
  • Overlapping or related design docs
  • Code style and organizational conventions

Output to the user: A brief summary of what you found, highlighting anything relevant to the task at hand. Do NOT dump a file listing - synthesize what matters.

Phase 2: Codebase-First Intelligence

Before asking ANY question, check if the codebase already answers it.

This is the core differentiator. The AI must:

  1. Identify what it needs to know to make the next design decision
  2. Search the codebase for the answer (grep, glob, read relevant files)
  3. Only ask the user if the code genuinely cannot answer the question

Examples:

  • "What database are you using?" - DON'T ASK. Check package.json, config files, existing code.
  • "How do you handle authentication?" - DON'T ASK. Search for auth middleware, JWT usage, session handling.
  • "What testing framework?" - DON'T ASK. Check test files, config, package.json.
  • "What's the visual style you want?" - ASK. Code can't answer aesthetic preferences.
  • "Sho
Compartilhar X LinkedIn