aspark

Plugin aspark from marketplace aspark in a-lottes/aSPARK. Commands read from the repo's manifest — today.

Skills (12)

• backlog

  Seed a backlog from the project's documents: the Product Owner reads docs/ (plus the constitution and ROADMAP.md), proposes an ordered list of feature-sized items each traced to a source section, the user edits the list, and on explicit confirmation each item is filed as a GitHub issue that /story-t

• campaign

  Start a campaign draft: build `.spark/campaigns/<name>/campaign.md` from an existing campaign kind, asking only what the kind leaves open. Only when the user types /campaign.

• charter

  Establish or amend the project constitution — the standing principles and constraints that bind every SPARK phase. Use once at project start to give the team its ground rules, or any time a project-wide decision (stack choice, quality bar, non-negotiable) changes and should apply to all future featu

• demo-day

  Hands-on QA in a real browser: the QA Tester clicks through the running app, verifies every acceptance criterion from the spec, explores beyond the happy path and files reproducible bugs. Use after /peer-review passes, or to re-test after fixes. Requires a running app and browser tooling.

• go-live

  Start the Keep phase of the SPARK loop: the Release Manager runs fresh pre-flight checks, writes the user-facing changelog, prepares tag/PR/ deploy, publishes on the user's explicit go, and records the cycle's learnings. Use when review and QA have both passed and the increment should be released.

• increment

  Start the Act phase of the SPARK loop: build the increment strictly following the approved plan, task by task, with progress tracked in the plan. Use after the plan is approved, or to fix findings that came back from /peer-review or /demo-day.

• look-and-feel

  Run the Designer over a spec (design risks, usability heuristics, accessibility) or over an implemented UI (screenshots, running app). Use after /story-time for UI-facing features, or any time the user wants a design critique of a spec, mockup, page or component.

• next-steps

  Have the Product Owner survey the project's current state — shipped features, in-flight work, open findings, standing goals — and propose one concrete next feature ready to hand to /story-time or /spark. Use when the user has no idea in hand and asks "what should we build next", when a loop just clo

• peer-review

  Start the Review phase of the SPARK loop: the Reviewer audits the diff produced by /increment — plan conformance, correctness, edge cases, security, test quality — and writes the review report. Use after /increment reports done, or to re-review after fixes.

• spark

  Run the full SPARK loop end-to-end for one feature: Specify → Plan → Act → Review → Keep, pausing at every gate for the user's decision. Use when the user brings a feature idea and wants the whole agile team to take it from idea to release in one guided session — or wants to resume a feature that is

• sprint-plan

  Start the Plan phase of the SPARK loop: the Engineering Manager turns an approved spec into a technical plan — architecture decision with rejected alternatives, ordered task breakdown with definitions of done, test strategy and risks. Use after the spec is approved, or to revise a plan after review/

• story-time

  Start the Specify phase of the SPARK loop: the Product Owner interrogates a product idea and turns it into a spec with user stories and testable acceptance criteria. Use when the user brings a new feature idea, product idea or change request that has no spec yet — or wants an existing spec challenge

Subagents (7)

• designer

  The Designer of the aSPARK team. Use in the Specify phase (/look-and-feel) to design-check a spec before planning starts, or later to critique an implemented UI (from screenshots or markup provided by the caller). Detects bad design: usability heuristics violations, inconsistency, accessibility prob

• engineering-manager

  The Engineering Manager of the aSPARK team. Use in the Plan phase (/sprint-plan) to turn an approved spec into a technical plan: architecture decision with rejected alternatives, ordered task breakdown, test strategy and risks. Also use when a plan must be revised after review or QA findings.

• facilitator

  The Facilitator of the aSPARK team. Use with /charter to establish or amend the project constitution — the standing principles and constraints that bind every SPARK phase. Grounds the constitution in what the project actually is, proposes concrete defaults, and challenges aspirational entries the co

• product-owner

  The Product Owner of the aSPARK team. Use in the Specify phase (/story-time) when a product idea or feature request must be challenged and turned into a spec with user stories and testable acceptance criteria. Also use when an existing spec needs re-prioritization or scope decisions, or in /next-ste

• qa-tester

  The QA Tester of the aSPARK team. Use in the Review phase (/demo-day) to test the running application hands-on in a real browser: verify every acceptance criterion from the spec, explore beyond the happy path, check console and network, and file reproducible bugs. Requires a browser integration (Cla

• release-manager

  The Release Manager of the aSPARK team. Use in the Keep phase (/go-live) to take a review- and QA-approved increment to release: fresh pre-flight checks, user-facing changelog, version tag, PR or deploy, post-release smoke check, and recording the cycle's learnings.

• reviewer

  The Reviewer of the aSPARK team. Use in the Review phase (/peer-review) to audit the diff produced by /increment with a staff-engineer eye: plan conformance, correctness, edge cases, error handling, security and test quality. Writes the review report and may fix obvious low-risk issues directly.

Similar plugins