skills/team/qrspi-implement/SKILL.md
QRSPI Implement phase -- executes an approved plan.md slice-by-slice with strict Red-Green-Refactor per slice and a fresh-session checkpoint after each. Use for "/qrspi-implement <feature>", "execute the qrspi plan", "build the approved plan slice by slice". Not for a bare TDD cycle with no plan (use tdd); this phase requires plan.md status: approved and writes per-slice logs.
npx skillsauth add michaelalber/ai-toolkit qrspi-implementInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
"Amateurs practice until they get it right. Professionals practice until they can't get it wrong."
The Implement phase executes an already-approved plan mechanically -- every design decision was settled by Spec and Plan. Each plan phase is one vertical slice, and each slice runs the full Red-Green-Refactor loop end-to-end before the next begins. The discipline is test-first and per-slice: a slice is not done until its RED proof and GREEN proof are recorded on disk. One slice is ideally one fresh session -- the per-slice log is the resumption point, so context never has to span the whole feature.
Non-Negotiable Constraints:
plan.md status: approved; never implement from memoryimplementation/slice-NN-{name}.mdPRE-FLIGHT
[ ] Locate the feature folder thoughts/shared/qrspi/YYYY-MM-DD-{slug}/
[ ] Read plan.md. If absent -> STOP; route the user to /qrspi-plan
[ ] Confirm plan.md status: approved. If only ready-for-review -> STOP; ask the human to approve
[ ] Run the baseline test suite. If red -> STOP; report; do not fix the baseline
[ ] Read the ENTIRE plan; identify the next unfinished slice from implementation/
SLICE LOOP (one slice = one plan phase, ideally one fresh session)
1. RED — write the failing test from the phase; RUN it; it MUST FAIL.
If it passes, the test is wrong -> fix the test, not the code.
2. GREEN — write the minimal production code; RUN build + tests; they MUST PASS.
3. REFACTOR — clean up; RUN again; it MUST stay GREEN.
4. RECORD — write implementation/slice-NN-{name}.md: RED output, GREEN output, files changed.
5. CHECKPOINT — suggest one commit for the slice; if context > 40% or the slice is done,
tell the user to start a fresh session for the next slice.
REPORT
Slices complete / total · last verification result · next slice (or "feature complete").
Exit criteria: each executed slice has a slice-NN-{name}.md log holding its RED proof and GREEN
proof; the build/tests are GREEN; a per-slice commit was suggested; the user knows the next slice or
that the feature is complete.
<qrspi-implement-state>
phase: PRE-FLIGHT | RED | GREEN | REFACTOR | RECORD | CHECKPOINT | COMPLETE
feature_folder: thoughts/shared/qrspi/YYYY-MM-DD-{slug}/
plan_present: true | false # MUST be true to proceed
plan_approved: true | false # MUST be true to proceed
baseline_green: true | false # MUST be true before any change
current_slice: [NN]
slices_total: [count]
slices_complete: [count]
last_verification: red | green | pending # RED step expects red; GREEN/REFACTOR expect green
context_budget: under-40 | approaching-60 | checkpoint-now
</qrspi-implement-state>
See references/slice-log-template.md for the per-slice implementation/slice-NN-{name}.md
structure -- the RED proof, GREEN proof, files-changed list, and the resume note.
| Skill | Relationship |
|-------|-------------|
| qrspi-plan | Prior phase. Its approved plan.md is the contract this phase executes; refuses to run without status: approved. |
| tdd | The inner loop. Each slice IS a RED-GREEN-REFACTOR cycle; load tdd for the test-first mechanics this skill enforces per slice. |
| dotnet-vertical-slice / python-feature-slice / rust-feature-slice | Stack scaffolders for the slice each phase builds. |
development
Interviews the user relentlessly about a plan, decision, or idea — one question at a time, each with a recommended answer. Shared engine behind "grill-me" and "grill-with-docs". Use on any "grill" trigger phrase or to stress-test thinking. Do NOT use to build the plan; it ends at shared understanding, not implementation.
testing
Runs a relentless interview to sharpen a plan or design, capturing the decisions as ADRs and a glossary along the way. Use when the user wants to be grilled AND wants the session to leave durable domain documentation behind. Do NOT use for a throwaway stress-test with no artifacts; use grill-me instead.
tools
OWASP-based security review of Vue/TypeScript front-ends. Detects framework (Vite/Vue CLI/Nuxt), entry points, and data flows; scans the OWASP Top 10 (2025) mapped to Vue client-side risks (raw-HTML XSS via v-html, URL/protocol injection, bundled secrets, insecure token storage, dependency CVEs, missing CSP, open redirects, router guard bypass); emits an exec summary plus graded findings. Use to audit Vue for vulnerabilities. Not for architecture grading (vue-architecture-checklist).
tools
Analyzes legacy Vue codebases and produces actionable modernization plans. Primary migration paths include Options API to Composition API, Vue 2 to Vue 3, Vue CLI to Vite, JavaScript to TypeScript, Vue Test Utils/Karma/Mocha to Vitest + Vue Testing Library, legacy Vuex to Pinia, and removed-in-Vue-3 pattern cleanup (filters, event bus, `$listeners`). Does NOT perform the migration — assesses, quantifies risk, and plans.