Super Saiyan

Plugin super-saiyan from marketplace awakened in coltonbearden/awakened. Commands read from the repo's manifest — 1 month ago.

Skills (18)

• before-you-build

  Compact pre-mortem before building a product, MVP, landing page, internal tool, agent workflow, or major feature. Use when the user is about to start something whose demand, positioning, retention, trust, or distribution is unproven. Names the riskiest assumption, the smallest evidence to gather fir

• clarifying-requirements

  Turns a vague feature request into a scoped, actionable specification through short rounds of focused questions. Use when the user asks for something like "add login" or "build a dashboard" with no acceptance criteria, boundaries, or technical context. Asks Why and Simpler on every requirement, two

• diagnosing-bugs

  Feedback-loop-first diagnosis for hard bugs, flaky failures, and performance regressions. Use when the user says diagnose or debug, or reports something broken, throwing, failing, or slow and no reliable reproduction exists yet. Builds one fast command that goes red on this exact bug, shrinks the re

• documentation-lookup

  Answers library, framework, and API questions from current documentation instead of memory. Use when the user names a framework or package, asks how to configure or call something, or wants a code example that depends on a library's present behaviour. Uses Context7 when it is available, states plain

• executing-plans

  Executes an approved written implementation plan in the current session, task by task, with a critical read first and checkpoints between tasks. Use when the user hands over a plan file or spec and asks for it to be implemented. Treats the plan as data, stops on blockers instead of guessing, and fin

• finishing-a-development-branch

  Closes out a feature branch once implementation is complete. Use when all tasks are done and the work must be integrated. Verifies the suite on the exact tree being handed over, confirms the base branch, offers merge, pull request, or keep as the only options, and cleans up only worktrees it created

• grilling

  Relentless structured interview that stress-tests a plan, design, or decision until nothing is silently assumed. Use when the user says grill me, wants their thinking challenged, or a design must be settled before implementation. Works the decision tree in rounds of numbered questions with recommend

• intent-driven-development

  Makes an ambiguous or high-impact change verifiable before it is built. Use when the user asks to clarify a feature, define acceptance criteria, de-risk a security, data, migration, or integration change, or prepare requirements to hand over to someone else. Inspects the codebase first, asks only bl

• prototype

  Builds throwaway code that answers one design question. Use when the user wants to feel whether a state model or piece of logic holds up, or see what a screen could look like, before committing to real implementation. Picks the logic or UI shape, keeps the prototype runnable in one step and clearly

• reducing-entropy

  Manual-only bias toward the smallest codebase that still does the job. Invoke explicitly when the user asks to shrink, simplify, or delete code, or wants a change judged by how much code exists afterwards. Counts lines before and after, hunts for what a change makes obsolete, and rejects proposals t

• resolving-merge-conflicts

  Resolves an in-progress git merge or rebase conflict by recovering the intent behind both sides. Use when git reports conflicted files during a merge, rebase, or cherry-pick. Reads the history behind each change, preserves both intents where possible, runs the project's checks, and completes the ope

• search-first

  Research-before-coding check that runs before writing a new utility, helper, abstraction, or integration. Use when the user asks to add functionality that common libraries or the codebase itself may already provide. Searches the repository first, then known ecosystems, weighs adopt, extend, or build

• systematic-debugging

  Root-cause-first discipline for any bug, failing test, build failure, or unexpected behaviour. Use before proposing any fix, especially under time pressure or after a previous fix did not hold. Reproduces, traces the bad value to its origin, compares against working code, tests one hypothesis at a t

• test-driven-development

  The red-green-refactor loop for any feature, bug fix, or behaviour change. Use before writing implementation code, when fixing a bug, or when changing code that has tests. Writes one failing test, confirms it fails for the right reason, writes the minimal code to pass, confirms green, then cleans up

• testing-at-seams

  Decides where tests belong before any test is written. Use when starting test-first work, when the user asks for integration tests, or when a test is hard to write. Agrees the public seams under test with the user, names the anti-patterns that make tests brittle, and keeps each cycle to one vertical

• using-skills

  Session discipline that fires before the first action of any task. Checks whether an installed skill or command already covers the job, keeps every action inside the requested scope, and reports verification as evidence rather than confidence. Use at the start of a conversation, before answering a q

• verification-before-completion

  Gate that runs before any claim that work is done, fixed, passing, or shipped. Identifies the command that would prove the claim, runs it fresh, reads the whole output, and only then reports — with the evidence attached and any gap stated. Use before committing, opening a pull request, marking a tas

• writing-plans

  Turns an agreed design or spec into a step-by-step implementation plan that an engineer with no context could execute. Use when a multi-step change is understood well enough to sequence but no plan exists yet, before touching code. Produces a plan file with exact paths, test-first steps, interfaces

Slash commands (9)

• /super-saiyan:build-fix

  Run the project's own build or type-check and fix the errors one at a time with the smallest safe edit, re-running after each. Stops and asks before any dependency change. Use when a build is red.

• /super-saiyan:commit

  Commit a described subset of the working tree: show the staging plan and message, get a yes, commit locally. Never force, never push. Use when you can say in words what belongs in the next commit.

• /super-saiyan:implement

  Execute an approved plan file task by task with a validation ladder (type-check per edit, then lint, tests, build, bounded integration) and write a report. Use once a plan is approved and the branch is ready.

• /super-saiyan:plan-prd

  Write a lean problem-first PRD at .claude/prds/<name>.prd.md through four question gates, stopping before any implementation detail. Use when an idea needs its problem, users, and metrics pinned down.

• /super-saiyan:plan

  Turn a request or PRD into a grounded plan: mandatory reading, what is NOT built, six to ten atomic tasks, validation, risks, blast-radius size; then wait for approval. Use before any multi-file change.

• /super-saiyan:tdd-green

  Make the failing tests pass with the least production code that could work, running the suite after every change and stopping on any regression. Use right after a red phase.

• /super-saiyan:tdd-red

  Write failing tests for a described behaviour in the project's own conventions, run them, and confirm each fails for the intended reason before any production code exists. Use to start a TDD cycle.

• /super-saiyan:test-coverage

  Run the project's own coverage tool, list files below target worst-first, write tests in the existing style, and re-measure. Use to raise coverage toward a threshold (default 80 percent) without adding tools.

• /super-saiyan:ultra-think

  Structured deep analysis of one hard question: hidden assumptions, three genuinely different options, a case against each, and a confidence-rated recommendation. For decisions that are expensive to reverse.

Similar plugins