sunstack-dev

Plugin sunstack-dev from marketplace sunstack in ShravanSunder/sunstack. Commands read from the repo's manifest — yesterday.

Skills (43)

• audit-security-review

  Use when the user asks for a security scan, security audit, threat model, vulnerability review, security diff scan, or remediation of one security finding.

• debug-investigation

  Use when investigating bugs, failing tests, flaky behavior, crashes, regressions, build failures, unexpected behavior, long-running monitor/watch requests, or requests to debug/root-cause a problem before implementing fixes.

• discuss-clarify-mental-models

  Use when understanding may have drifted (repeated corrections, hollow agreement, a term with two senses) or asked to reconverge, share understanding, reflect back or re-anchor. Not for edits, review, research or pathfinding.

• discuss-pathfinding

  Use when requirements, user needs, domain terms, tacit process or owner tolerances are unwritten and must be drawn out of someone's head: \"grill me\", \"interview me\". Not for authoring from settled sources.

• docs-maintain

  Use when updating, cleaning up, reconciling, archiving or promoting project docs (AGENTS.md, README, changelogs, runbooks) or workflow artifacts from settled code or decisions. Not for unsettled spec or design.

• domain-code-standards

  Use when writing, changing or reviewing code in any language, especially deciding whose standards apply, where a test goes, how to name a file, or which commands to run.

• domain-python

  Use when writing, changing or reviewing Python code, especially choosing a Pydantic model or a dataclass, typing collections and generics, imports, tagged unions, pytest layout and mocking, and which uv commands to run.

• domain-rust

  Use when writing, changing or reviewing Rust code, a Rust crate's module layout or its SQLx migrations, or choosing which cargo commands to run.

• domain-swift

  Use when writing, changing or reviewing Swift or SwiftUI code, especially types and optionals, view state and view models, Swift Testing, formatting, or which commands to run.

• domain-typescript

  Use when writing, changing or reviewing TypeScript code, naming its files and folders, or choosing which lint, format and test commands to run.

• ops-linear-tracking

  Use when the user asks to create, organize, update, delete, or inspect Linear projects, milestones, issues, dependencies, ticket breakdowns, blocked/unblocked work, or tickets generated from architecture docs.

• ops-observability-stack

  Use when starting, checking, using, debugging, or verifying the shared local OpenTelemetry and Victoria stack, or proving that a local debug or beta app emits OTLP to it.

• practices-cleanup

  Use when a slice, milestone, PR or investigation ends, your own merged worktree is still on disk, or disk runs low, to remove the large residue your task created. Not for archiving documents or managing PR state.

• practices-collaboration

  Use when starting a qualifying task, to find its board project and work thread, or when agents coordinate: messaging or commissioning a session, seats, posts, waiting on another agent, or no board. Not for tool syntax.

• practices-how

  Use when explaining how existing code or a subsystem works, tracing a behavior before changing it, or locating what owns a state, effect or boundary. Not for why, an incident's cause, new architecture or a single fact.

• practices-preflight

  Use when about to start an orchestration, implement a plan or commission an agent: checking inputs, access, credentials, services, tools, assigned agents and disk. Not for checking finished work or choosing who takes a job.

• practices-research

  Use when a task needs source gathering, prior art, current docs or web evidence, or memory, session-log or saved-reader research before design, planning, review or discussion. Not for extracting unwritten owner meaning.

• practices-retrospective

  Use when asked for a retrospective or lessons from a finished or bounded session or delivery, or why a correction recurs across sessions. Not for re-anchoring, diagnosis, evidence alone, skill choice or verify-skill upkeep.

• practices-show-me-your-work

  Use when tracking work in logs or handling a request to show a work log, including decisions, assumptions, checks, owner asks and checkpoints. Not for routine small edits.

• practices-verification-maintenance

  Use when creating or maintaining a project's verification skill, its journeys and drivers. Not for one ordinary verification run, a driver-only task without a project-skill target, product repairs or delivery acceptance.

• practices-verification

  Use when checking a declared behavior on its target, challenging proposed proof, or building or maintaining an assigned verification driver. Not for delivery acceptance, code review, root-causing or product repairs.

• practices-why

  Use when asking why code or a design took its shape: the decision or constraint behind it, where a threshold or check came from, or if its reason holds before a change. Not for how it works, incident causes or a new design.

• presentation-html

  Use when creating or revising a standalone HTML file for a technical explainer, visual engineering document, or architecture page, or a Demistify/HTML Islands artifact. Not for formatting an answer inside chat or a terminal.

• presentation-show-worklog

  Use when the owner explicitly requests a work-log HTML page or asks to refresh one. Not for routine logging, checkpoints or progress replies.

• presentation-tui

  Use when composing a substantial diagram, architecture, comparison, tradeoff or multi-section response, or a design decision for the owner, on a terminal, CLI or unknown host. Not for rendered chat (presentation-webui).

• presentation-webui

  Use when composing a substantial diagram, architecture, comparison, tradeoff or multi-section response, or a design decision for the owner, on a rendered markdown chat host. Not for a terminal or CLI (presentation-tui).

• principle-build-the-shared-model-first

  Use when about to build on someone else's picture (a request, a spec, a resumed plan, another agent's handback), or when agreement on something complex comes too fast.

• principle-define-the-domain-first

  Use when a new noun, state, or stored field appears, one word is doing two jobs, or two sources use different words for what may be one thing.

• principle-design-for-concurrency

  Use when actors already overlap: two workers, retries, callbacks, background tasks, or late results can touch the same resource.

• principle-design-for-failure

  Use when a call, job, or state change has an effect someone else can see and it can time out, be retried, partly succeed, or end without you knowing.

• principle-experiment-before-proposing

  Use when running something would settle a question faster than arguing about it: an unknown API behavior, a performance claim, which of two designs works better, how a prompt or classifier performs.

• principle-hold-the-scope

  Use when a new request arrives, a design or plan comes back from someone else, or work is about to be called done.

• principle-justify-the-complexity

  Use when adding or keeping a layer, abstraction, option, mechanism, or second path, or when sequencing a refactor or rewrite.

• principle-name-the-tradeoffs

  Use when a real choice changes complexity, risk, cost, or reversibility, or when one option is presented for a decision that has others.

• principle-one-owner-per-truth

  Use when truth, effects, or guarantees cross a boundary: two parts can write the same state, a copy holds data another part owns, a schema is defined twice, or stored data starts to mean something new.

• principle-prove-it-works

  Use when about to say a feature, fix, or UI change works, or when a passing test is offered as proof that it does.

• principle-read-ground-truth-first

  Use when about to claim what current code, a system, a document, or a library does, or to explain an unexpected behavior.

• principle-refine-mental-models

  Use when reality surprises the plan, a fix fails twice on the same premise, or the same correction comes twice.

• principle-separate-the-concerns

  Use when adding a module, layer, interface, or dependency, when one part changes for two unrelated reasons, or when testing one rule drags in the network, the clock, or the framework.

• principle-types-are-communication

  Use when designing or reviewing types, signatures, or data that crosses a boundary (network, file, environment, database, model output), especially status fields, ids, and optional fields that only make sense together.

• principle-verify-before-accepting

  Use when accepting any result: a helper's handback, a review finding, a passing run, 'done', an agreement, or your own conclusion.

• principle-write-for-the-reader

  Use when writing a design, code, an instruction, or an explanation someone else must follow: a reviewer, a future maintainer, another agent, the owner tomorrow.

• principle-write-tests-that-can-fail

  Use when writing, changing, or keeping a test for a fix, a feature, or a refactor, or when a claim rests on tests passing.

Similar plugins