decide
Walk the user through design or implementation decisions one at a time, or review completed code one change at a time. Use when the user says "walk me through each decision", "let's decide together", "help me work through these choices", "walk me through what you did", or "QA step by step". Present concise context, mutually exclusive options, log each answer, and finish with a summary.
git clone --depth 1 https://github.com/superset-sh/superset /tmp/decide && cp -r /tmp/decide/.agents/skills/decide ~/.claude/skills/decideSKILL.md
# Decide ## Prepare Before a design walkthrough, inspect the relevant code and record concrete bugs, inconsistencies, and decision points in `plans/<YYYYMMDD>-<topic>.md` or the appropriate app-scoped `plans/` directory. Preserve existing edits; never discard speculative or user-authored work without explicit approval. Order decisions by dependency and leverage, not document order. ## Decision walkthrough For each decision: 1. Show `## Decision N: <title>`. 2. Give two to four sentences of context grounded in real files or functions. 3. State the trade-off in one sentence. 4. Ask exactly one interactive question with two to four mutually exclusive options. - Use `ask_user` when available. In Codex Plan mode, use `request_user_input` when that is the exposed interactive question tool. - Never substitute a plain-text question when repository instructions require an interactive overlay. - Keep labels to five words or fewer. - Put the recommendation first and suffix its label with `(Recommended)`. - Explain each option and its trade-off in one sentence. - Do not add an `Other` option when the client adds one automatically. 5. After the answer, write `Logged: <decision>.` and continue. If the user acknowledges an issue without choosing, log the recommended choice and say they can correct the assumption. At the end, provide a `| # | Decision | Choice |` table and offer to turn the audit into an implementation plan. Do not write implementation code during the decision walkthrough. ## QA walkthrough Use this mode when the user wants to review existing code step by step. 1. Identify the review unit: a commit, staged diff, PR, or explicit file set. 2. Break it into logical steps in dependency order. 3. Show one step per turn with: - `## Step N: <title>` - One or two sentences explaining what changed and why - A focused real-code excerpt with file and line references - One interactive verdict question: `Looks good, next step (Recommended)`, `Push back, change this`, and, only for non-trivial code, `Pause, explain more` 4. Wait for the verdict before showing the next step. 5. Log approvals, collect requested changes, and finish with a `| # | Step | Verdict |` table. If a step reveals a genuine design fork, pause the QA walkthrough and offer to switch to decision mode for that fork.
Canonical three-section structure for Linear and Superset tickets in this repo. Use when creating, drafting, or grooming a ticket.
Validates project structure against co-location and architecture patterns defined in AGENTS.md
Create workspaces, spawn agents, schedule automations, and manage Superset projects/tasks/hosts via the `superset` CLI. Use to orchestrate coding agents across devices from the terminal.
Verify UI behavior end-to-end by driving the running desktop app over the Chrome DevTools Protocol. Use when asked to verify, reproduce, or confirm a UI change, bug, or regression in the real app rather than in tests.
Create a database migration with Drizzle on a fresh Neon branch. Use when changing the packages/db schema or generating migrations.
Critique and improve the visual design of an existing UI component with concrete implementation guidance. Use when the user asks to redesign, restyle, reimagine, polish, or improve a component, screen, or interface, especially in React and Tailwind codebases.
Read and update the Superset desktop app's user settings (theme, fonts, terminal, git, notifications, behavior) via the superset CLI, including creating and installing custom themes from JSON. Use when asked to change app settings, switch or create a theme, adjust fonts, or configure desktop preferences without opening the settings UI.
Personalized audit that teaches the advanced Superset features the user isn't using yet (automations, parallel agents, tasks, multi-host, terminal remote control, custom commands, MCP) and sets them up live. Use when the user wants to get more out of Superset, asks "what else can Superset do", "how do I 10x my workflow", "what am I missing", or wants to learn a specific Superset feature.