dstack-core

Plugin dstack-core from marketplace dstack in gosuda/dalcom-skills. Commands read from the repo's manifest — 3 days ago.

Skills (86)

• abstract-well

  Use when the user wants to classify abstractions as useful, bad, or busy and keep one shallow level. Not for tasks requiring source or remote-system changes.

• architect

  Use when non-trivial code needs a design, codebase architecture needs improving through survey and deepening, or one module needs targeted interface narrowing, seams, or testability. Not for rendered visual artifacts, deploy, or irreversible changes.

• architecture-simplification

  Use when the user explicitly asks to simplify an architecture, collapse modules or crates, or cut a dependency graph within approved boundaries. Executes an approved layout direction slice by slice. Not for single-module cleanup: use code-simplification. Not for layout planning from nothing: use arc

• ask-dalcom

  Use when the user asks which dstack skill or chain of skills to use for a situation and names no skill, which route to take across skills, or what must exist before a named skill. Recommends one route and runs none of it. Not for a repository orientation or first contribution: use onboard. Not for p

• askme

  Use when eliciting intent/scope/referents or gating long/bundled/high-stakes/hard-to-undo work: exhaustive/collaborative/adversarial/grill/gate/batch/interview/proposal/pairing. Grill me and grill batches select evidence-backed, chat-only grill mode. Not for scanning a stated request: use clarify. N

• audit-project

  Use when the user says "audit my code", "find all the bugs", "review until clean", or "grill my changes". Not for remote, credential, or irreversible changes.

• autolearn

  Use when a verified fix yields a generalized well-abstracted invariant with enforcement or proof, or existing solution docs need bounded refresh. Not for unverified fixes, minor learnings, narrative/activity/weak-test stories, retrospective analysis, or remote migration.

• autopilot

  Use when a human has a delivery plan, or an approved one from autoplan or brainstorm, and wants the full chain run under phase gates, including a reply of approved, approve all, run it, or go on right after a plan was presented. Not for planning, open-ended debugging, or single-step execution.

• autoplan-and-autopilot

  Use when the user invokes /autoplan-and-autopilot on an idea or plan to review across four perspectives, derive a task ledger, present the amended plan, and execute under verified phase gates; the invocation approves local, reversible work. Not for open-ended debugging, single-step execution, or una

• autoplan

  Use when the user runs /autoplan on a plan or idea. Reviews, amends, and derives purpose-named tasks with a final human approval gate. Not for remote, credential, publish, deploy, or irreversible changes.

• autowatch

  Use when the user explicitly asks for autonomous end-to-end work from request to an open pull request or merge request, or asks to watch an existing open pull request or merge request until decided. Not for step-by-step supervised work and never as an alias for lfg.

• brainstorm

  Use when capturing or refining notes, a transcript, a brain dump, or an existing idea, or when a concrete visual question is clearer shown in a local browser. Not for independent candidate generation: use ideate-multiple-agents.

• breaking-driven

  Use when bloated code needs clean re-derivation, or the user says "this module is bloated" or "break it and rebuild". Not for untracked data or changes without VCS rollback.

• catchup

  Use when the human returns after a gap, cannot follow the project, asks what happened, or wants a visual HTML recap page. Not for onboarding: use onboard. Not for handoff: use handoff.

• ci-fix

  Use when "CI is red", "fix the checks", or "make CI green", one check needs classifying, or a bounded sweep runs. Not for deploys, credentials, or rerun-as-fix. Non-CI bugs: use grill-core.

• clarify

  Use when the user says "clarify", "what is ambiguous here", or when a prompt or spec reads as under-specified before planning. Not for exploring intent with questions: use askme.

• code-review

  Use when a named diff or pull request needs review for bugs, regressions, tests, and standards. Not for reviewing requirements or plans, handling feedback already left on a PR, or shipping the change.

• code-simplification

  Use when a named module, file set, or dependency slice needs less code and structure without losing required behavior. Covers dead code, unused settings, and redundant wrappers. Use simplify to choose the right level of work, architecture-simplification to reorganize modules, tests-purge-unneeded to

• commit-push-pr

  Use when asked to commit and push a feature branch, with or without a pull request or merge request. Description-only and description-update modes draft or refresh the body without committing.

• commit

  Use when asked to commit working-tree changes as typed atomic local commits. Not for push, PR, or remote publication: use commit-push-pr.

• complexity-grill

  Use when a user wants to identify the true sources of complexity qualitatively before counting metrics. Not for source or remote mutation.

• compound

  Use when the user explicitly asks to save a generalized invariant from a closed knowledge-work session. Admits only well-abstracted reusable mechanisms with supported scope, enforcement, and material consequence; zero output is normal. Not for fixes, trivia, diaries, remote publish, or retrospective

• contract-driven

  Use when crossing a public API boundary, guarding complex invariants, or hardening untrusted input or integration seams. Not for remote or irreversible changes.

• contraint-driven

  Use when no quality bar is written down, when setting up constraints, or when implementing under non-negotiable budgets, limits, or API rules. Not for one-off spikes or remote, credential, publish, deploy changes.

• decide

  Use when the user has a fork and wants it resolved and applied, not explored: "decide this", "choose the path", or "decide and fix it".

• do-it-now

  Use when the user asks to finish the whole task now, clear active todos, or unblock undone implementation without deferred phases or follow-up remainders, or says do it now, do all, or don''t ask. Not for bypassing approvals, cutting requested scope, or authorizing publish, deploy, or irreversible c

• docs-practices

  Use when deciding whether a durable document, ADR, plan, or spec is needed, or when checking its invariant quality, scope, and naming. Not for drafting prose or restructuring agent-consumed documents.

• doubt-driven

  Use when a non-trivial decision sits under uncertainty and correctness matters more than speed. Not for patch review: use review.

• enforce-workflow-constraints

  Use when any bounded workflow starts or reaches an action, path, proposal, or merge boundary. Refuses rather than default-allow on an unreadable constraint set.

• exhaustive

  Use when asked to prove coverage, find missing cases, or enumerate state, decision, requirement, or behavior space. Not for round-based or single-property tests: use askme, tests-practices.

• explore

  Use when asked to explore the codebase to map structure, symbols, and dependencies. Not for a single file under 50 LOC: read it directly.

• fix

  Use when the user asks to fix a local bug, make a verifier pass, or implement an already-adjudicated repair, including a pasted FIX: block, traceback, or compiler error with a known local cause. Select and prove a root repair. Not for acquiring reviews, adjudicating review feedback, PR or CI orchest

• from-first-principle

  Use when a user wants to rebuild a design, organization, or API from primitives. Not for a perspective take: use from-perspective.

• fromzero

  Use when replacing a greenfield attempt with a clean pad of verified requirements. Not for rebuilding from primitives: use from-first-principle. Requires a committed, VCS-recoverable attempt.

• generalize

  Use when asked to derive the general rule a request carries as examples instead of a stated rule, then bound it. Not for ambiguity in a stated request: use askme. Read-only.

• grill-core

  Use when the cause is unknown, including a pasted traceback or compiler error nobody can explain yet, the fault recurs as a class, or a review comment needs a root-design repair rather than a patch. Survey the subsystem and remove the fault class. Not for implementing a known defect, greenfield feat

• ground-latest

  Use when starting or scaffolding a codebase or service, migrating, refactoring, or picking language, framework, or dependency, or latest, LTS, or modern way. Not for remote or irreversible changes.

• guillotine

  Use when dead, duplicate, superseded, or generated residue must leave more than one artifact class of a repo or subsystem, preserving behavior. Not for a single enumerated record set with no cross-artifact consumers.

• handoff

  Use when work reaches a session boundary or the user asks to hand off, delegate, or get a clipboard-ready prompt. Mode brief packages continuity; mode prompt builds the delegation prompt.

• inits

  Use when onboarding to a repository, capturing costly conventions, constraints, or rationale, or improving AGENTS.md. Not for remote, credential, publish, deploy, or irreversible changes.

• leave-only-first-principle

  Use when asked to prune a design or codebase until only primitives remain, producing a first-principles map. Not for remote, credential, publish, deploy, or irreversible changes.

• let-fate-decide

  Use when the user says let fate decide, YOLO, dealer choice, surprise me, whatever, or delegates a vague choice in a casual or playful tone, or when you are about to pick arbitrarily between valid options. Not when instructions are precise, one approach is clearly correct, or the call governs safety

• minimalism-driven

  Use when writing or restructuring code, before adding a helper, wrapper, config key, or dependency, or when the user asks for minimal or DRY code. Not for performance tuning: use optimize.

• necessary-work

  Use when work is about to grow past the ask, the task may already be done, or the user requests only the minimum. Not for executing the work: use tests-practices to build or grill-core to fix.

• no-comments

  Use when asked to remove source comments by replacing them with clear code or accessible documentation. Not for deleting legal notices, required tool directives, or public documentation contracts without an equivalent home.

• no-excuses

  Use when a material claim rests on missing proof, an untested assumption, or unresolved counterevidence that investigation can still settle. Not for unrelated research, actions outside the granted authority, or bypassing required approvals.

• offensive-driven

  Use when the user explicitly asks for a replacement-first pass such as "rebuild it clean", "replace-first", or "offensive pass on <target>" spanning code, docs, plans, or research. Not for code-only restructuring (existing code skills already own that and stay offensive by default); not for root-cau

• parallel-launch

  Use when work splits into independent sub-tasks or cross-domain research, or the user says orchestrate, fan out, or more parallel about independent work. Not for durable scope ownership with per-scope review: use partition-scopes-to-subagents.

• plans-complete

  Use when a plan must be proven complete before implementation begins. Extract every deliverable and proof obligation, compare it with the current tree, expose acceptance drift, and block on unresolved or unverifiable work.

• plans

  Use when multi-step work needs a structured implementation plan that preserves outcomes and constraints. Not for exploratory framing, executing the work, or running tests to learn from results.

• proof-driven

  Use when property-based testing, theorem proving, or formal proof tactics require zero unproven properties. Not for remote, credential, publish, deploy, or irreversible changes.

• purge-slop-docs

  Use when a human asks to purge stale docs, clean Markdown, or reorder the documentation hierarchy. Not for code debris. This skill edits Markdown prose only.

• recall

  Use when asked to recover prior work and current status before resuming. Not for handoff snapshots: use handoff. Not for source or remote-system changes.

• refactor-break-compat

  Use when modernizing APIs, removing compat shims, killing feature flags, or rewriting a subsystem cleanly. Not for additive refactors that must preserve the old path.

• research

  Use when researching a named library, framework, SDK, API, or service, or finding a migration guide. Not for codebase-internal research. Dispatch a scout agent.

• resolve-pr-comments

  Use when handling GitHub PR or GitLab MR review threads, top-level comments, or review bodies on one named PR/MR in a single batch: enumerate completely, judge against current code, repair valid findings at the root, and post replies, resolutions, and pushes under explicit human approval or under th

• resolve

  Use when local feedback needs adjudication, or the user explicitly chooses analyze, reception, summary, interactive, or autonomous mode for one feedback batch. Human gates all pushes, replies, and resolutions. Use resolve-pr-comments for the direct one-PR/MR comment workflow, not this mode-based ent

• retro

  Use when a finished session, period, milestone, or cycle needs an evidence-backed look-back, or an existing system needs its unexplained rationale recovered. Not for saving learnings into docs: use compound or autolearn.

• retune

  Use when a skill corpus degrades on a new model and needs measurement-first retuning against a registered bar. Not for word-reduction passes, single-skill edits, or static audits presented as retuning. Explicit request only; never auto-invoked.

• review-fix-loop

  Use when review and repair must repeat to an evidenced end state, locally or across one or more GitHub PRs or GitLab MRs, or the user says resolve new review findings, fix failing CIs, or loop until green across all open PRs. Coordinates batches, topology, and convergence. Not for a single feedback

• security-review

  Use when changes touch auth, parsing, dependencies, network, or pre-release, or a diff or baseline needs regression review, or the user asks for a security review, vulnerability audit, or OWASP review of a supplied file, diff, or component, covering injection, XSS, auth, or crypto, with high-confide

• setup-repo

  Use when the user asks to set up a repository: deterministic gitignore, repository-native pre-commit hooks, or REVIEW.md and CONTRIBUTE.md rules that enforce anti-slop, anti-spaghetti, and offensive-minimalism defaults. Single owner for repository setup, superseding earlier setup-* skills. Not for o

• show-me

  Use when asked to show/diagram: comparison table, data record, metric card, stepper, mockup, numeric chart, interactive explainer. Modes: widget/chart/explainer. Not for audits: use show-me-your-work.

• simplify

  Use when the user asks to simplify a change-set, diff, branch, or module and the right level is not yet decided; routes each cut to the simplification skill that owns it.

• skill-gap-finder

  Use when the user suspects no installed skill covers a task and wants proof. Names the owning skill or writes a missing-skill brief. Never routes or invokes the matched skill.

• skill-scanner

  Use when a user asks to scan, audit, or validate a skill for security issues. Not for source-code or infrastructure review: use security-review. Not for remote-system changes.

• source-driven

  Use when writing or verifying framework-specific code, boilerplate, or a documented, correct implementation. Not for pure logic, renames, or when the caller explicitly wants speed over verification.

• spec-driven

  Use when starting a project or feature, requirements are unclear, or a change crosses modules. Accepts new specs and already-approved specs via the existing-spec entry.

• strict-validation-setup

  Use when a user invokes a strict-mode validation or verifiable-goals loop setup. Not for remote, credential, publish, deploy, or irreversible changes.

• subagent-driven

  Use when a user says execute with subagents or orchestrate, or hands over an ordered multi-task plan. Not for credential, paid, or deployment work, or any mutation outside the skill''s designated workspace.

• sync-docs

  Use when a behavioral diff may have left docs or CHANGELOG stale, or when tidy targets stale code comments. Applies only safe fixes. Not for steering a document toward a target state you name: use writing-for-agents for agent-read documents or docs-writing for others. Not for roadmap drift: use drif

• tasty-abstraction

  Use when a user wants to design an abstraction boundary that collapses a complex implementation into a simpler interface without leaking internal state. Not for implementation.

• tests-adversarial

  Use when hardening error handling, validating boundary behavior, or hunting silent failures. Not for feature development: use tests-practices. Not for test deletion: use tests-purge-unneeded.

• tests-practices

  Use when developing a fix or feature test-first, plan a TDD build, or work red-to-green in slices. Every test is invariant-based or offensive: it states a quantified property or an attack with an independent oracle, detects a named realistic fault, and survives behavior-preserving refactors. Not for

• tests-purge-unneeded

  Use when a legacy, slow, or duplicate test suite needs purging, a post-refactor sweep is due, or types cover a contract.

• to-greenfield

  Use when the user says greenfield this or rescue this codebase, names a field (dark, red, blue, or brown), or diagnoses a subsystem. Not for specs. Not for remote or irreversible changes.

• todo-add

  Use when a message contains `TODO ADD: <requirement>`. Not for deepening coarse lists: use todos-enhance. Not for resyncing lists: use todos-update. Not for retitling/reordering/completing todos.

• todos-enhance

  Use when tasks are too vague, read as headings, or the user asks to sophisticate the todos. Not for stale reconciliation: use todos-update. Not for adding requirements: use todo-add.

• todos-update

  Use when user asks to update todos, resync the task list, say what to do next, or plan and tree have drifted apart. Not for coarse lists: use todos-enhance. Not for adding requirements: use todo-add.

• type-driven

  Use when modeling a domain, encoding a state machine, hardening APIs, making invalid states unrepresentable, or parsing instead of validating. Not for TypeScript: use typescript-best-practices.

• unslop
• validation-first-driven
• verification-before-completion
• wayfinder
• workflows-driven
• writing-for-agents

Similar plugins