sb

Plugin sb from marketplace agents in leesangb/agents. Commands read from the repo's manifest — 4 days ago.

Skills (48)

• analyze

  Investigate code, logs, documentation, architecture, bugs, and behavior to return bounded evidence, call paths, data flow, impact scope, and unresolved decisions. Use when a code workflow needs read-only exploration before planning or implementation.

• architecture-plan

  Plan code changes from confirmed evidence and a fixed Outcome Contract when design or cross-module decisions need investigation.

• benchmark-checklist

  Validate a benchmark harness and measured speedup or regression: completed work, errors, tuning, bottlenecks, physical limits, repeatability, and user-visible relevance.

• blast-radius

  Find what a change can break beyond its diff and verify the key safety assumption; use for impact analysis, 'what could this break', or '영향 범위'.

• bro

  Restate the previous explanation in plain human language when explicitly asked, including '쉽게 말해줘'; preserve the conclusion, evidence, and consequential caveats.

• code

  Route implementation and planning requests that change product code, executable tooling, configuration, or agent workflows.

• correct

  Prevent demonstrated recurring mistakes in a scoped repository through ownership, types, or executable checks. Use when asked to stop repeated agent errors or encode recurring corrections; not for an ordinary one-off bug fix.

• create-verification-skill

  Create a project-local skill and feature map for driving and verifying an application's real UI, CLI, or service. Use when asked to make reusable app verification instructions or create a project-specific verification skill.

• hillclimb

  Repeatedly improve one measurable outcome through isolated hypotheses, a fixed measurement recipe, and keep-or-revert decisions. Use for an explicit sustained optimization loop toward a target; not for a one-off bug fix or an ordinary performance review.

• how

  Explain how code or a subsystem works, including runtime flow, ownership, and layering; use for walkthroughs and '어떻게 동작해'. Use why for historical rationale.

• implement

  Implement or fix an authorized code-change plan as the designated writer, preserving its contract and verifying completion.

• maintain-verification-skill

  Check and repair an existing project's verification skill, feature map, and owned harness against source and real application behavior. Use when asked to audit or maintain those verification instructions.

• principle-behavioral-substitutability

  Preserve supported behavior when implementations, inheritance, extension contracts, or mutable domain invariants change.

• principle-behavioral-verification

  Express API and function intent as executable guarantees through the owning boundary; use when writing tests or assessing regression evidence.

• principle-build-the-lever

  Make transformations, analyses, or verification reproducible with a small tool when deterministic execution improves correctness or reviewability.

• principle-caller-obligations

  Simplify API use by moving repeatable mechanics to their owner and comparing language builtins; use for caller setup, ordering, lifecycle, or error duties.

• principle-challenge-shared-premise

  Question the premise shared by repeatedly failing fixes and choose an observation that can disprove it before another attempt.

• principle-completion-evidence

  Before claiming completion, directly verify the final artifact or requested behavior and show the evidence supporting that claim.

• principle-composition-and-mechanisms

  Keep feature policy at its composition point and extract mechanisms only for independent obligations; use for assembly and interface boundaries.

• principle-correctness-and-failure-paths

  Trace correctness and failure paths; preserve error context and recovery ownership when logic, guards, errors, or fallbacks change.

• principle-decision-trail

  Record consequential choices with evidence during long-running, unattended, or multi-session work; preserve pivots without inventing history.

• principle-deep-modules

  Judge module depth by useful behavior versus caller knowledge and duties; use when evaluating interfaces, hidden mechanics, or seams.

• principle-defensive-history

  Recover the incident or contract behind unclear defensive code before removing it; missing rationale is not proof it is unnecessary.

• principle-design-foundations

  Resolve competing design criteria from the current use case, trusted values, ownership, and concrete costs rather than a fixed architecture.

• principle-encode-lessons-in-structure

  Prevent demonstrated recurring mistakes through ownership, types, or executable checks that reject the bad case.

• principle-experience-first

  Prefer the user's core experience over implementation convenience when product, UX, API, or feature-scope tradeoffs arise; justify every control and caller obligation.

• principle-intent-and-contracts

  Expose concrete meaning and constraints in names, types, outcomes, values, effects, and documentation; distinguish naming from behavior changes.

• principle-operational-safety

  Trace actual trust, data, recovery, compatibility, lifetime, concurrency, or resource risks and the effects of rollback.

• principle-performance-evidence

  Explain measured performance numbers and evaluation scores through comparable completed work, bottlenecks, representative samples, variation, and measurement limits.

• principle-reexecution-safety

  Prove repeated execution and recovery after partial failure preserve one logical operation without duplicating effects or adopting unrelated state.

• principle-requirement-fidelity

  Map behavior and proof to accepted requirements; separate missing, partial, and ambiguous evidence from scope expansion.

• principle-responsibility-and-change

  Place behavior and shared design knowledge with their owner; use when responsibility, dependency direction, or coordinated edits change.

• principle-root-cause-repair

  Investigate failures or review causal explanations even without a fix request; validate the failed precondition, trace its first broken guarantee, and identify its responsible owner.

• principle-separate-shared-state

  Separate independent write targets before adding locks; serialize structurally when one canonical mutable object is a real invariant.

• principle-simplicity-and-coupling

  Reduce caller knowledge, navigation, and hidden or duplicated state while preserving contracts; use for separation, merging, inlining, deletion, or deriving values.

• principle-verifiable-units

  Sequence dependent sweeps and migrations into meaningful units, check each before building on it, then verify the integrated result.

• recall

  Reconstruct scoped prior work, decisions, failed approaches, and current status across sessions. Use when asked to catch up on a project or recover where earlier work left off; not for ordinary work with sufficient context or extracting workflow lessons.

• reflect

  Derive durable improvements to existing skills or tools from a scoped conversation. Use when asked to reflect on a session or learn from repeated workflow corrections, rather than auditing unrelated history or changing skills after every task.

• restate

  Restate the user's goals and underlying problem in your own words when asked to check your understanding.

• review-audit

  Audit a fixed self-contained review packet for evidence support, consistency, completeness, and scope. Use only when sb:review selects a separate audit for a material dispute, high-impact judgment, or explicit rigorous-audit request.

• review

  Review a diff, PR, implementation, plan, design, or API boundary using shared principles and evidence-backed findings. Covers caller obligations, module depth, builtin alternatives, responsibility boundaries, and conceptual integrity. Main selects useful independent reviews, validates their evidence

• runtime-forensics

  Capture and analyze evidence from a running app or process to diagnose CPU work, retention, waits, or unexpected activity. Use for an explicit live profiling or runtime investigation request; not for existing-artifact analysis or an automatic product fix.

• swarm

  Coordinate independent investigation slices or candidate comparisons and return one evidenced result; use for explicit swarm or useful parallel coverage. Preserve the caller's workflow and writer boundaries.

• technical-writing

  Write or review technical docs, RFCs, READMEs, PR descriptions, and procedures around the reader's task, precise conditions, and observable results.

• trace-forensics

  Diagnose hot paths, retention, waits, or execution flow from an existing profile, heap snapshot, stack sample, or trace. Use when a captured artifact is supplied for analysis; not to capture a live process or automatically fix product code.

• typescript-best-practices

  Apply TypeScript coding guidance when reading, writing, or reviewing .ts and .tsx files: precise domain types, boundary validation, narrowing, value-oriented code, and inferred returns.

• unslop

  Remove vague claims, AI filler, jargon, and over-compression from writing while preserving meaning, evidence, and the requested voice; use for prose cleanup or '자연스럽게 고쳐줘'.

• why

  Investigate why code or a design took its current shape using history and decision records; separate recorded intent from inference. Use for rationale, regressions, and '왜 이렇게 만들었어'.

Subagents (1)

• thinker

  Performs read-only planning or review reasoning with an explicitly injected capability.

Similar plugins