sunstack-workflow-v1

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

Skills (23)

• implement-plan

  Use when executing or continuing one ready plan whose delivery context authorizes implementation, or correcting the implementation-owned findings of one review. Not for plan or design defects, independent review or PR work.

• implementation-handoff

  Use when packaging implementation state for another agent, reviewer, CLI, or future session: a copy-paste blurb, reviewer prompt, Claude/Gemini/Codex handoff, unfinished-work handoff, or post-implementation review packet.

• implementation-pr-wrapup

  Use when pushing, opening, updating, monitoring or finishing a GitHub pull request after implementation: its description, checks, comments, review threads, mergeability or \"merge when ready\". Not for fresh code review.

• implementation-review

  Use when independently reviewing implemented code, proof, a diff, commit, PR head or one bounded remediation before PR readiness, even with missing or conflicting governing inputs. Not for design review (spec-program-review).

• orchestrator-design

  Use when asked to run, resume or finish one design cycle. Not for one direct design phase, changing a plan during delivery, implementation delivery or PR work.

• orchestrator-implementation-goal

  Use when starting, resuming, auditing or completing an implementation delivery goal. Not for a design-only cycle or one direct phase.

• plan-handoff

  Use when packaging an existing implementation plan for another agent, CLI, machine, or future session, especially when the user asks for a copy-paste prompt, next-agent context, or portable plan packet.

• plan-implementation

  Use when writing the first implementation plan from a reviewed four-document design, an admitted improvement finding or a direct planning request. Not for changing it later (plan-update) or repo audits (plan-improve-repo).

• plan-improve-repo

  Use when auditing a repository for improvement opportunities, backlog-worthy refactors or quality gaps, and turning admitted findings into plans. Not for planning from a reviewed design.

• plan-update

  Use when a plan's meaning changes in delivery: design correction, plan defect, slice split or merge, new dependency or proof target, PR re-split. Not for first plans (plan-implementation) or in-slice choices (implement-plan).

• practices-manage-agents

  Use when delegating to subagents, teams or parallel agents (fan-out too): picking role, form, model; spawning, commissioning, continuing, steering, awaiting, monitoring, verifying or assessing them. Not for doing the phase.

• program-design

  Use when defining or revising structural How: entities' owners, homes and schemas; components, interfaces, state, flows, failure, trust boundaries, proof seams. Not for what entities mean or other Why/What (spec-design).

• role-advisor

  Use when commissioned or named as the Advisor: a second look at a design, plan or acceptance argument, the owner's questions, or the Lead's stalled work. Not for authorship, acceptance or independent review findings.

• role-implementer

  Use when commissioned as the Implementer for approved changes, product tests, associated proof and corrections. Not for defining the governing outcome, observing as the paired Verifier or independent review.

• role-lead

  Use when you are the owner's main engineering partner responsible for governing design, plans, integration and acceptance. Not for a helper assigned bounded evidence, implementation, observation or independent review.

• role-operator

  Use when assigned as the Operator for prescribed execution, watch, scraping, extraction or guided collection under supplied criteria. Not for choosing engineering probes, synthesizing conclusions or repairing failures.

• role-researcher

  Use when assigned as the Researcher responsible for a checked answer to a bounded question or continuing investigation. Not for prescribed extraction alone, governing design authorship or delivery acceptance.

• role-reviewer

  Use when commissioned as an independent Reviewer for a declared artifact or its corrections, with no authoring history. Not for authoring, implementation or substituting advice for independent findings.

• role-verifier

  Use when commissioned as the paired Verifier to build or keep the verification system, challenge proof feasibility before a build, or observe the adopted outcome. Not for product repairs, writing product tests or acceptance.

• spec-design

  Use when authoring or revising Requirements from settled meaning, or a Specification's obligations, entities and coverage views. Not for eliciting unwritten owner meaning (discuss-pathfinding).

• spec-handoff

  Use when packaging spec, design, architecture, or product-decision context for another agent, CLI, machine, or future session before an implementation plan exists.

• spec-program-review

  Use when independently reviewing a Specification, Program Design or the four-document set, including reader understanding or readability, or whether a spec- or program-only change needs review. Not for implementation review.

• verification-design

  Use when planning how a design's requirements will be proven, after Program Design or when that plan is missing or stale. Not for checking a delivered claim (practices-verification), building journeys or regression tests.

Similar plugins