v0.8.0 — Right-sizing: declare a project's QA method once in the constitution

Added

• A project with no browser-observable surface can declare its QA method once, so the QA step proceeds by that method automatically instead of asking the same override question on every feature.
• A release for such a project now describes QA as having run by that declared method — a settled project fact — rather than reporting a one-off exception granted for that release.

Changed

• A later review or QA pass can now cite a fact an earlier pass in the same feature already established, instead of re-deriving it from scratch — except when verifying a fix to that exact fact, verifying a required acceptance criterion, when the earlier pass flagged the fact as unverified, or when there's a concrete reason to doubt it; those cases still get a fresh check.
• On a project with no such declaration (every project's default today, unchanged), or where the declaration is missing a piece or names a method the session genuinely can't perform, the QA step behaves exactly as before — same question, nothing silently skipped.

Fixed

• The QA-method override that had to be renegotiated by hand on four consecutive features no longer needs repeating once declared.

Stated plainly, not hidden: four of the files carrying this release's QA-declaration wording — skills/demo-day/SKILL.md, skills/spark/SKILL.md, skills/go-live/SKILL.md, agents/release-manager.md — remain not-verified-live in this loop's own testing; the nested session needed to exercise them could not authenticate in this environment, reproduced in all 8 QA rounds. Recorded as an accepted, environment-caused gap, not a defect, and still true as of this release. This change makes no claim about line, token or cost savings, and no claim that the result generalizes beyond this project.

---

Full gate trail and evidence: .spark/right-sizing/ (spec, plan, review, qa, release, evidence). Merged via #31.

v0.6.0 — Lean artifacts: a fixed address on every report

Added

Every review, QA, spec, plan and release report now opens with a short Handoff block right at the top — status, a one-line verdict, what (if anything) is still open, which section has the final ruling, and what wins if the block and the rest of the report ever disagree. You can tell whether a report is done and what's left without reading the whole thing.

Changed

The team members and ceremonies that act on a previous report — the Reviewer doing a re-review, /increment closing out findings, /go-live checking its two release gates, /next-steps scanning for open items across features — now read that new block first, and only read further when they specifically need to (for example, verifying a fix was actually made, or working out a genuine disagreement between the block and the report). Reports written before this change keep working exactly as they did before; nothing about reading them changes.

Fixed

Nothing — this release adds a new capability rather than fixing a defect. No token or byte saving is claimed anywhere: the new block adds lines, it does not shrink anything.

---

Full gate trail and evidence: .spark/lean-artifacts/ (spec, plan, review, qa, release, evidence). Merged via #22.

aSPARK v0.4.0 - Graph-gates: an optional accelerant for the loop

Ceremonies that run /sprint-plan, /peer-review or /demo-day now notice an
installed, built aspark-graph on their own and use it to scope their work
faster - no install step, no flag, no config file. Absent, nothing
changes. Present but stale, unbuilt, or silent on a query, the ceremony
says so once and falls back to reading the project by hand, exactly as
before.

Plans can now name, per task, which files it touches (a 'files:' note in
the Definition of Done) - added only when knowable up front.

Six acceptance criteria ship as documented partials rather than full
passes, each with a named, structural reason; none is a broken feature,
and every one degrades safely to prior behavior.

aSPARK v0.3.1 — Propose the next feature

Adds /next-steps: when there's no idea in hand, the Product Owner surveys
the project's current state - shipped features from git history, in-flight
and stalled work from .spark/ artifact statuses (including open review/QA
findings), and the constitution's Product Principles - and proposes one
concrete next feature with a ranked alternative or two.

Advisory only: nothing is written to .spark/ and nothing needs approval.
The output hands straight into /story-time or /spark once the user picks
(or overrides with their own idea). /spark itself now points here instead
of guessing when there's no feature left to resume.

aSPARK v0.3.0 — situational lenses

Adds a situational layer on top of the SPARK loop: the process now adapts to what kind of software you're building, so relevant concerns get scrutinized and irrelevant ones stay quiet. Fully backward compatible — a project without a profile behaves exactly as before, because no lens is ever applied without one.

✨ New

• Project profile — the constitution gains a Project Profile & Active Lenses section recording the project's type (website, web-app, api, cli, library) and its characteristics (handles-auth, is-public, handles-payments, handles-pii, has-database, is-multilingual). The Facilitator grounds both in the repo's real signals with evidence; the user confirms. A project can be several types and carry several characteristics.
• Eight lenses — situational checklists the existing agents apply in the phases they own. Lenses are knowledge, not roles: no new agents, no new ceremonies.
  • seo — indexability, SSR vs client-only render, per-page metadata, structured data, Core Web Vitals
  • ux — flow efficiency, empty/loading/error/success states, forms, responsive & touch
  • api — resource design, error-envelope consistency, versioning & breaking-change detection, auth surface
  • cli — help clarity, stdout/stderr discipline, exit codes, safety flags
  • library — public API surface, semver & deprecation discipline, packaging & footprint
  • security — header/transport hardening, auth lifecycle, authz matrix, supply chain, PII/privacy
  • i18n — externalized strings, locale-aware formatting, text-expansion & RTL layout
  • data — migration safety, integrity & transactions, indexing at scale, retention & recovery
• Two trigger axes — a lens activates from the type (seo←website, ux←web-app, api←api, cli←cli, library←library) or from a characteristic (security←auth/public/payments/PII, i18n←multilingual, data←database). Security is a property of what software does with data, not of its shape — so it binds to behavior, not type.
• Traceability, not assertion — a lens concern becomes a measurable NFR- in Specify and is verified downstream under the same ID, riding the existing gates. Nothing is raised in one phase and quietly dropped in the next.
• Constitution as single source of truth — the profile is the only place a lens is switched on, so phases can't drift from one another. With no constitution, a phase gives a one-line nudge toward /charter and applies nothing.
• Lens load flag — no cap on stacking; at 4+ active lenses the profile flags the elevated load, because visibility is the throttle.
• Add-a-file extensibility — a new concern is a new file in lenses/ plus a profile entry. Skills pass active lens paths generically, so no agent or skill is rewritten.

🔧 Changed

• Templates: constitution.md gains the Project Profile & Active Lenses section and the load flag; spec.md notes that active-lens concerns land as measurable NFRs.
• Agents: facilitator detects type + characteristics and derives active lenses; product-owner captures lens concerns as NFRs; designer applies ux/seo/i18n; reviewer verifies each lens's review slice in the diff; qa-tester verifies the browser-observable slice (ux, seo, security, i18n).
• Skills: /charter surfaces the profile and load as the user's decision; /story-time, /look-and-feel, /peer-review, /demo-day resolve active lenses from the constitution and pass their paths; /spark nudges toward /charter when no profile exists.
• Docs: docs/workflow.md gains a Situational Concerns section; new lenses/README.md documents the lens contract, both trigger axes, and the detection signals.

✅ Validation

• Dogfooded through aSPARK's own loop. The feature was run through /story-time before release (.spark/situational-lenses/spec.md). The Product Owner's Clarify pass caught two real defects in the first cut, both fixed before this shipped:
  • the no-constitution fallback was duplicated across three skills and re-derived lens logic per phase (drift-prone) — now nudge-only;
  • nothing surfaced when many lenses stack — now flagged at 4+.
• All eight lens files conform to the documented contract (frontmatter, per-phase owner map, falsifiable checks only).

⚠️ Known limits (recorded, not papered over)

• Non-UI lenses have no QA surface. api, cli, library and data contribute zero /demo-day checks — the QA phase is browser-shaped and they have no browser to click. Their verification is Specify, Review and the increment's own tests. This is a pre-existing limitation of the loop that the lens layer makes visible rather than hides.
• Lens compliance is instruction-driven. No test enforces that a lens actually fired; a silently-skipped lens looks like a correct N/A. The human gate is the only check.
• The success signal is not yet proven. The feature's own spec defines success as a UI lens firing and being QA-verified on a website plus a Review lens firing and being Review-verified on an api, both under the same NFR-. Neither has been demonstrated by a full loop run yet.

Full changelog: v0.2.0...v0.3.0

aSPARK v0.2.0 — spec-driven layer

Adds a spec-driven-development layer on top of the SPARK loop: standing project context, sharper specs, and requirement traceability end to end. Fully backward compatible — existing .spark/ artifacts keep working.

✨ New

• Project constitution — /charter and a new Facilitator agent capture project-wide principles, constraints, quality bars and non-negotiables in .spark/constitution.md, read by the Product Owner, Designer, Engineering Manager and Reviewer. Set the ground rules once instead of re-arguing them every feature.
• Clarify pass — /story-time now runs a structured ambiguity sweep across an 8-category taxonomy (functional boundaries, data, permissions, error/edge cases, NFRs, integrations, UX states, out-of-scope) before the spec gate, logged in a Clarifications table.
• Non-functional requirements — specs gain an NFR section with measurable, falsifiable NFR- entries that inherit the constitution's quality bars.
• Traceability — US-/AC-/NFR- IDs flow spec → plan (Covers column) → review (Requirements Traceability table) → QA (NFR rows), enforced at each gate.

🔧 Changed

• Templates: new constitution.md; spec.md, plan.md, review-report.md, qa-report.md extended with the sections and gate checks above.
• Agents: product-owner, engineering-manager, reviewer, designer read the constitution; qa-tester verifies browser-observable NFRs.
• Docs: docs/workflow.md gains Project-Wide Context and Traceability sections.

✅ Validation

• claude plugin validate passes.
• Dry-run-validated through the Plan phase on a sample project: /charter → /story-time (Clarify) → /look-and-feel → /sprint-plan, with the constitution binding every phase and full Must-AC coverage in the plan.

Full changelog: v0.1.0...v0.2.0

aSPARK v0.1.0 — agile AI product team for Claude Code

aSPARK turns Claude Code from a coding copilot into a gated delivery process — an agile AI product team where a Product Owner challenges your idea, a Designer spots bad design, an Engineering Manager locks the architecture, a Reviewer finds your bugs, a QA Tester clicks through your app in a real browser, and a Release Manager ships it.

Every feature travels through five phases — Specify → Plan → Act → Review → Keep — and may only move forward when the previous phase's quality gate is green.

What's in this release

• 6 team agents — product-owner, designer, engineering-manager, reviewer, qa-tester, release-manager, each with its own mindset, standards and hard rules.
• 7 ceremony skills — /story-time, /look-and-feel, /sprint-plan, /increment, /peer-review, /demo-day, /go-live.
• /spark orchestrator — runs the whole loop end-to-end with gate stops, resume support and feedback-loop escalation.
• 5 gated artifact templates — spec, plan, review, QA and release notes, each ending in an explicit gate checklist. Artifacts live in .spark/<feature>/ inside your project, so the whole decision trail is transparent and reviewable.
• Workflow deep-dive (docs/workflow.md) — the artifact chain, gate invariants, feedback loops and role boundaries.

Validated end-to-end

This release passed a full dry run: the loop took a vanilla-JS quick-todo app from idea to release — PO → Designer → EM → build → code review → real-browser QA → release — with all five gates enforced. Plugin structure verified with claude plugin validate.

Install

In a normal (interactive) Claude Code session:

/plugin marketplace add a-lottes/aSPARK
/plugin install aspark@aspark

Then restart Claude Code. See the README for the step-by-step guide and the non-interactive CLI variant.

---

MIT licensed.