brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
spec-implementation-reviewReviews implementation waves against approved specs and tickets. Use when completed or partial work needs acceptance, merge, release, or handoff review with path tracing and persisted findings.
Independent GitHub snapshot · Automated classification · Original documentation governs
Review a wave/plan implementation against approved specs. Do not fix code. Persist findings and per-ticket feedback for implementation agents.
Start with the requested wave/plan scope, then expand it to all consumers of a changed public contract, generated artifact, shared asset, or module boundary:
specs/.readiness-report.yaml and scoped specsplans/implementation-plan.md, indexes, wave plan, ticketsRun available gates from their loaded skill packages before semantic review; pass the target repository explicitly rather than assuming it contains this skill suite:
node <spec-readiness-review-skill-root>/scripts/check_specs.mjs <repo-root>/specsnode <spec-implementation-planner-skill-root>/references/check_plan.mjs <repo-root>node <spec-implementation-review-skill-root>/scripts/check_implementation_evidence.mjs <repo-root>Stop if specs or plan are not approved, required evidence is missing, or the review scope cannot be identified.
references/path-tracing.md.scripts/check_implementation_evidence.mjs and apply
references/implementation-evidence.md plus references/review-gates.md
for spec drift, interfaces, tests,
requirements traceability, security, performance, operations, supply chain,
robustness, maintainability, docs, and false work.references/findings-format.md.Reject any failed gate in references/review-gates.md, including spec/contract
drift, unapproved representations or generated mirrors, weak boundary types,
untested happy/unhappy paths, security/privacy/data-loss/operations risks,
false completion, ownerless feedback, or stale source text. Also reject an
undeclared changed asset/module/command effect or an unreviewed affected
consumer. Persist the finding and route it; never accept around it.
Write plans/reviews/<wave-or-plan-id>/<review-id>/:
review.md: decision, path coverage, commands, self-auditfindings.yaml: structured findingsagent-feedback/<ticket-id>.md: implementation-agent feedback for every
ticket with findingsUse references/findings-format.md for required fields and status handoff. Do
not rely on chat-only feedback.
Route implementation findings to spec-ticket-implementation, plan gaps to
spec-implementation-planner, and spec gaps to spec-readiness-review. If
routing is unclear, use spec-driven-workflow.
pass: no blocking findings, commands pass, path matrix completeneeds_fixes: implementation issues are actionable within ticketsblocked_spec_gap: specs are missing, unclear, or contradictoryblocked_plan_gap: plan/tickets/scopes/dependencies cannot route fixespartial: review was intentionally scoped and cannot accept the whole waveOnly independent review transitions reviewed work to accepted. An implementer
may record implemented or review_pending, never acceptance.
Return findings first, ordered by severity. Advisory cleanup must not hide blocking correctness, security, spec, test, or path-coverage issues.