@hanzlaa/rcode 3.6.16 → 4.1.0

package/rcode/skills/actions/4-implementation/rcode-herdr-orchestration/templates/STATE-template.md

@@ -0,0 +1,40 @@
+# CAMPAIGN STATE
+
+Last update: <ISO-TIMESTAMP>
+Heartbeat: `.planning/campaign/HEARTBEAT` (file mtime should be < 60s old while campaign is live)
+Heartbeat PID: see `.planning/campaign/HEARTBEAT.pid`
+
+## TSC drift over time
+
+| Time (UTC) | Wave | TSC errors | Delta vs baseline |
+|---|---|---|---|
+| <iso> (campaign start) | 0 (baseline) | <count> | 0 |
+| <iso> | 1 | <count> | +/-N |
+| <iso> | 2 | <count> | +/-N |
+
+## Wave history
+
+### Wave 1 — <one-line theme>
+- Dispatched: <iso>
+- Agents: 4 (pane labels: <Pane1, Pane2, Pane3, Pane4>)
+- Branches: `<branch-1>`, `<branch-2>`, `<branch-3>`, `<branch-4>`
+- Outcome:
+  - merged: `<branch-1>` (3 commits), `<branch-2>` (5 commits), `<branch-3>` (2 commits)
+  - rebase needed: `<branch-4>` (conflict on shared file)
+- Pushed to origin: <iso>
+- Cumulative commits: <count>
+
+### Wave 2 — <one-line theme>
+- …
+
+## Active panes
+
+| Pane | Label | Branch | Status | Last commit at |
+|---|---|---|---|---|
+| `<pane-id>` | <label> | `<branch>` | working/idle/done | <iso> |
+
+## Open questions / blockers
+
+<!-- Things the orchestrator surfaces to the human at next opportunity. -->
+
+- <blocker description>

package/rcode/skills/actions/4-implementation/rcode-herdr-orchestration/templates/heartbeat.sh

@@ -0,0 +1,29 @@
+#!/bin/bash
+# Background heartbeat for the autonomous fix campaign.
+#
+# Run:   bash heartbeat.sh & echo $! > .planning/campaign/HEARTBEAT.pid
+# Kill:  kill $(cat .planning/campaign/HEARTBEAT.pid) && rm .planning/campaign/HEARTBEAT.pid
+#
+# Touches .planning/campaign/HEARTBEAT every 30s with an ISO-8601 UTC timestamp.
+# External watchers can monitor mtime to see the campaign is alive.
+#
+# This is the SECONDARY heartbeat. The PRIMARY heartbeat is ScheduleWakeup inside
+# the assistant session — without ScheduleWakeup the assistant goes silent regardless
+# of this bash loop.
+
+set -euo pipefail
+
+HEARTBEAT_DIR="${HEARTBEAT_DIR:-.planning/campaign}"
+mkdir -p "$HEARTBEAT_DIR"
+
+HEARTBEAT_FILE="$HEARTBEAT_DIR/HEARTBEAT"
+INTERVAL="${HEARTBEAT_INTERVAL:-30}"
+
+echo "[heartbeat] starting — writes to $HEARTBEAT_FILE every ${INTERVAL}s" >&2
+
+trap 'echo "[heartbeat] received SIGTERM, exiting" >&2; exit 0' TERM INT
+
+while true; do
+  date -u +%FT%TZ > "$HEARTBEAT_FILE"
+  sleep "$INTERVAL"
+done

package/rcode/skills/actions/4-implementation/rcode-herdr-orchestration/templates/wave-prompt.md

@@ -0,0 +1,69 @@
+# Wave-Agent Prompt Template
+
+Use this as the body of `herdr pane send-text` when dispatching each agent in a wave. Replace the placeholders.
+
+---
+
+```
+You are in an isolated worktree at <WORKTREE_PATH> on branch <BRANCH_NAME>. <REPO_NAME> repo.
+
+YOUR PARENT BRANCH IS <INTEGRATION_BRANCH> (NOT master). Your branch was forked from <INTEGRATION_BRANCH>. When you finish, the orchestrator will merge your branch INTO <INTEGRATION_BRANCH> (not master). Master stays untouched throughout the campaign.
+
+If you need to pull the latest parent work (rare, only between waves):
+  git fetch origin
+  git merge origin/<INTEGRATION_BRANCH> --no-edit
+
+CAMPAIGN MODE — pick top 3-5 pending P1/P2 items from <AUDIT_DOC_PATH> and ship them. Long-running autonomous fix campaign — your branch will be merged into the campaign integration branch when done.
+
+PROTOCOL
+1. Read <AUDIT_DOC_PATH> fully. Identify items marked pending, ⏳, [ ], TODO, or labeled P1/P2 that are NOT already shipped (cross-reference `git log <INTEGRATION_BRANCH>` to avoid double-fixing).
+2. Pick 3-5 items that are surgical, well-scoped, and unrelated to other in-flight campaign agents (no overlap with: <IN_FLIGHT_AREAS>).
+3. Implement each item as a small, separately-committed change. Conventional commit format (e.g. `fix(area): summary` / `feat(area): summary`). Each commit message must reference the audit finding.
+4. STRICT auto-heal from project CLAUDE.md while editing:
+   - super_admin in role filters
+   - no silent .catch(()=>{}) — use logger.warn with reason
+   - no React.FC, no style={{}}, no raw <button> (use Button component)
+   - no alert()/confirm() — use toast/AlertDialog
+   - Prisma schema changes need migration files via `prisma migrate dev --create-only --name <slug>`
+   - new /api routes need server/middleware/routeSecurity.js MANIFEST entries
+5. Keep TSC at baseline. Run `pnpm tsc --noEmit` before final commit. If you introduce a NEW error, fix it before committing.
+6. STAY on branch <BRANCH_NAME>. Do NOT push. Do NOT merge to master. Do NOT merge to <INTEGRATION_BRANCH>. Do NOT touch other audit areas.
+7. End with a short numbered summary listing each commit (hash + one-line message) and what audit item it addressed.
+
+DO NOT
+- Touch master at all
+- Merge into the integration branch (the orchestrator does that — your job is to commit on your own branch and stop)
+- Touch out-of-scope code outside the audit area
+- Add new abstractions or refactor wholesale
+- Make schema changes without a migration file
+- Write tests "as a bonus" unless the audit specifically called for them
+- Push to origin
+
+Begin by reading the audit doc and listing the candidate items you'll fix.
+```
+
+---
+
+## Placeholders
+
+| Placeholder | Source |
+|---|---|
+| `<WORKTREE_PATH>` | `../sm-worktrees/camp-<area>` |
+| `<BRANCH_NAME>` | `campaign-<area>` |
+| `<INTEGRATION_BRANCH>` | `campaign-integration` (default) or `campaign-<topic>` for named campaigns |
+| `<REPO_NAME>` | e.g. `LeadLyze` |
+| `<AUDIT_DOC_PATH>` | `.planning/audits/AUDIT-<area>.md` |
+| `<IN_FLIGHT_AREAS>` | Comma-list from STATE.md |
+
+## When to deviate from this template
+- **Heavy schema work**: add explicit migration-naming guidance and require `prisma migrate diff` review before commit.
+- **Pure UI/CSS area**: drop the routeSecurity MANIFEST bullet, add "use design tokens not hex codes".
+- **Authentication / RBAC area**: add "no role-relation rename without checking every call site; super_admin always included".
+
+## Related templates
+- `BACKLOG-template.md` — initial backlog format
+- `heartbeat.sh` — secondary heartbeat process
+
+## Related rules
+- `rules/integration-branch.md` — why the parent branch is `<INTEGRATION_BRANCH>` and not master
+- `rules/merge-strategy.md` — what happens after sub-agent commits land on the branch

package/rcode/skills/actions/4-implementation/rcode-incremental/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: rcode-incremental
+internal: true
+description: Ship code in small, atomic, verifiable steps.
+triggers:
+  - "ship incrementally"
+  - "atomic commits"
+  - "small steps"
+  - "step by step build"
+  - "incremental implementation"
+  - "one commit at a time"
+  - "build verifiably"
+  - "rollback ready"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+Treats every change as a sequence of small, verifiable steps that compile, pass tests, and revert cleanly. The unit isn't "the feature" — it's "the next 30 lines that still leave the build green." This is how rcode itself was reshaped (see `.rcode/memory/project/decisions.md`).
+
+## Workflow
+
+1. **Decompose first.** Before touching code, list the steps as a numbered checklist. Each step must end with the codebase still building and tests still passing.
+2. **One logical change per commit.** No bundled refactors. If you find yourself writing "and also" in the commit subject, split it.
+3. **Verify after each step.** Run the targeted test, the type-check, the linter — whatever the project gates require — before moving on.
+4. **Commit with intent.** Conventional Commits format (`type(scope): subject`); subject describes the WHY, not the WHAT (the diff already shows the what).
+5. **Pause at logical milestones.** After every 3–5 commits, ask whether to push, get review, or continue locally.
+6. **Revert is the first option, not the last.** If a step goes sideways, `git revert <sha>` and try a different decomposition. Never accumulate broken state.
+
+## Output Format
+
+For each implementation request, return:
+- **Step plan** — numbered checklist with one-line scope per step
+- **Per-step commit messages** drafted in Conventional Commits format
+- **Verification command** the agent will run after each step
+- **Rollback note** for each step (what `git revert` undoes)
+
+Do NOT include: bundled diffs, "and also" steps, or commits without verification.
+
+## Examples
+
+**Happy path** — "Add dark mode to dashboard" → 5-step plan: (1) extract colour tokens to CSS vars, (2) add theme state + localStorage, (3) wire `data-theme` on `<html>`, (4) add toggle button, (5) screenshot regression. Each step compiles + tests pass.
+
+**Edge case — refactor that touches 30 files** — Decompose into directory-by-directory commits. If a single commit must touch many files (e.g. an alias rename), state that in the plan and verify the codebase still parses afterwards.
+
+**Negative — speculative future cleanup** — "Refactor the whole auth layer" without a current task driving it. Refuse. Pair this skill with a real bug fix or feature; otherwise it becomes scope creep.
+
+## Memory Bank Hooks
+
+- **Reads:** `.rcode/memory/project/decisions.md` (so context for "why this approach" is loaded)
+- **Writes:** append to `.rcode/memory/project/decisions.md` when a step encodes a non-obvious choice

package/rcode/skills/actions/4-implementation/rcode-migrate/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: rcode-migrate
+internal: true
+description: Plan and execute the move from MVP to production-grade infrastructure without rewriting from.
+triggers:
+  - "graduate the mvp"
+  - "production grade infra"
+  - "mvp to prod"
+  - "scale this beyond demo"
+  - "harden the stack"
+  - "revamp the architecture"
+  - "from prototype to product"
+  - "ready for real users"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+MVPs are built to ship — corners get cut by design. Past a certain user count or revenue threshold, those cuts become tax: every new feature gets harder, every deploy is scary, every bug takes a day to root-cause. This skill plans the graduation in phases that ship continuously, never with a "we'll rewrite the whole thing" big bang.
+
+## Workflow
+
+1. **Audit the gaps.** Run a 30-minute MVP-vs-production gap report against the eight checks below.
+2. **Triage by blast radius.** Which gap, if it stays, kills the next 3 sprints? Fix that one first. Cosmetic gaps wait.
+3. **Plan in 1-week increments.** Each increment must leave the system shippable. No "we'll come back to fix this in 2 weeks" half-states.
+4. **Bring the team along.** New patterns get documented in `decisions.md` and `glossary.md` so the next dev finds them.
+5. **Each increment closes with a smoke-test deploy** and a metric showing the improvement.
+
+## The eight production checks
+
+For each: pass / partial / fail. "Partial" means it exists but isn't enforced; treat as fail for planning.
+
+1. **Tests.** Unit + integration + at least one end-to-end happy-path test, all running in CI on every PR.
+2. **CI/CD.** Push-to-deploy on a PR-merge basis, with a manual approval gate to production.
+3. **Observability.** Errors land in Sentry (or equivalent) within 30s. Latency p95 graph exists. Logs are searchable.
+4. **Authentication.** Real provider (Keycloak, Auth0, Clerk, Firebase). No "rolled our own JWT".
+5. **Authorisation.** Tenant isolation enforced at the query layer, not just the URL.
+6. **Database backups.** Automated, tested (restore drill within the last 90 days).
+7. **Infrastructure as code.** Production reproducible from the repo (Helm + Terraform / Pulumi). No "I configured the load balancer manually".
+8. **Documentation.** README + architecture diagram + change records. New devs onboard in <1 day.
+
+## Gap → action mapping (defaults)
+
+| Gap | First-week action | Skill to invoke |
+|---|---|---|
+| No tests | Cover the 3 most-used flows with E2E tests | `rcode-prove-it` |
+| Manual deploys | Add GitHub Actions workflow that deploys on tag | `rcode-ci` |
+| No Sentry | Drop in `@sentry/node` + `@sentry/nextjs`; PII redaction | `rcode-harden` |
+| Hand-rolled JWT | Migrate to Keycloak / Clerk; flag old tokens for forced rotation | `rcode-harden` |
+| Tenant leak risk | Add `tenant_id` to every query; enforce via Postgres RLS or middleware | `rcode-harden` |
+| No backups | Configure automated `pg_dump` to S3 with 30-day retention | inline |
+| Manual infra | Helm chart for the app + values per environment | `rcode-ci` |
+| Stale README | Auto-generate architecture from code + write a 1-page onboarding | `rcode-trim` (for dead docs) |
+
+## Output Format
+
+```
+MVP-vs-production gap report (<date>)
+
+Pass:       <count> / 8
+Partial:    <count>
+Fail:       <count>
+
+Critical gaps (block scaling):
+  ✗ <gap> — <why this is critical now>
+
+Plan (1-week increments):
+  Week 1: <gap to close> — owner: <persona>
+  Week 2: <gap to close> — owner: <persona>
+  ...
+
+Each week ends with: smoke-test deploy + metric showing improvement.
+Each week is reversible: if anything goes sideways, the previous week's state ships fine.
+```
+
+## Examples
+
+**Happy path** — Audit shows 3 gaps: no Sentry, manual deploys, no E2E tests. Week 1: add Sentry + PII filter. Week 2: GitHub Actions deploy-on-tag. Week 3: Playwright E2E for login + main flow. Each week ships independently.
+
+**Edge case — partial backups** — `pg_dump` exists in cron but no one has tested restore. Treat as fail. Week's action: restore drill in a staging instance; document the runbook.
+
+**Negative — "let's rewrite in $NEW_FRAMEWORK"** — Refuse. A rewrite is not graduation. Graduation means filling specific gaps in the current system. Rewrites take 6 months and break what worked.
+
+## When NOT to use this skill
+
+Do NOT use this skill for greenfield projects, framework rewrites (graduation fills gaps, it does not rewrite), feature development, or CI setup alone (use rcode-ci).
+
+## Memory Bank Hooks
+
+- **Reads:** `.rcode/memory/project/stack.md` (current state), `.rcode/memory/incidents/known-issues.md` (operational pain), `.rcode/memory/milestones/current.md`
+- **Writes:** the gap report into `.rcode/memory/change-records/YYYYMMDD-NNN.md`; each week's plan as a phase entry under `.rcode/memory/milestones/current.md`

package/rcode/skills/actions/4-implementation/rcode-perf/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: rcode-perf
+internal: true
+description: Performance optimisation for the rcode-default stack — Next.js (LCP / TBT / CLS / hydration),.
+triggers:
+  - "optimize performance"
+  - "page is slow"
+  - "fps drop"
+  - "core web vitals"
+  - "query is slow"
+  - "lcp regression"
+  - "perf budget"
+  - "tune this"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+Performance work without measurement is theatre. This skill enforces measure → identify → fix → re-measure for every claim. Targets are stack-specific because optimisation moves are stack-specific. For Three.js scenes: frame budget. For Postgres: EXPLAIN ANALYZE. For Next.js: Lighthouse + bundle analyzer. Same skill, different tools.
+
+## Workflow
+
+1. **Baseline.** Capture the current number — LCP in ms, fps, query duration, RAM at peak. Quote the source (Lighthouse, Chrome perf trace, EXPLAIN ANALYZE, K8s metrics).
+2. **Set the budget.** What does "good enough" look like? E.g. LCP ≤ 2.5s, 60fps with 5% headroom, query p95 < 100ms. If there's no budget, the work has no exit condition.
+3. **Identify the bottleneck.** One number, one mechanism. "The page feels slow" isn't a bottleneck — find the specific waterfall step or render loop.
+4. **Fix.** One change. Re-measure.
+5. **Compare to budget.** Either the change cleared the budget (ship it) or it didn't (next bottleneck).
+6. **Stop when the budget is met.** Optimisation past the budget is yak-shaving.
+
+## Stack-specific cheat sheet
+
+### Next.js
+
+- LCP: defer below-the-fold images; preload the LCP image.
+- TBT: split the largest Client Component into Server Component + small Client island.
+- Hydration: prefer Server Components by default; `'use client'` only where interactivity is required.
+- Bundle: `next-bundle-analyzer`; per-route, find the >100KB chunks first.
+
+### Three.js
+
+- Draw calls: instance any geometry rendered >50 times. `InstancedMesh`, not a loop.
+- Geometry uploads: don't recreate `BufferGeometry` per frame — mutate the existing attribute.
+- Materials: `MeshBasicMaterial` is 5-10× cheaper than `MeshStandardMaterial`. Use it where lighting isn't needed.
+- DPR: clamp `renderer.setPixelRatio(Math.min(2, devicePixelRatio))` — 4× DPI on a Retina display kills perf.
+
+### Postgres
+
+- EXPLAIN ANALYZE before touching anything. Look for `Seq Scan` on big tables.
+- Index the columns in `WHERE` and `ORDER BY` first. Composite indexes for multi-column filters.
+- `pg_stat_statements` for finding slow queries in production.
+- For multi-tenant: ensure `tenant_id` is the leading column in indexes.
+
+### Vercel / K8s
+
+- Cold start: prefer regional deploys close to users; use `runtime: 'nodejs'` for heavy SDKs.
+- Memory: K8s pod memory limit + Node `--max-old-space-size` should match (don't let one exceed the other).
+- Edge functions: keep cold-start work async; first response shouldn't await heavy SDK init.
+
+## Output Format
+
+```
+Surface: <route / scene / query / pod>
+Budget: <metric> ≤ <target>
+
+Baseline:
+  <metric>: <value> (<measurement source>)
+
+Bottleneck:
+  <one mechanism>
+
+Fix:
+  <one change>
+
+Post-fix:
+  <metric>: <value>
+  Budget: ✓ met | ✗ still over by <X>
+
+Next bottleneck (if any):
+  <description>
+```
+
+Do NOT include: optimisation without a baseline; "this should be faster" without measurement; broad rewrites pitched as perf fixes.
+
+## Examples
+
+**Happy path — Next.js LCP** — Baseline LCP 4.2s; budget 2.5s. Bottleneck: hero image (1.8MB JPG, no preload). Fix: convert to AVIF + add `<link rel="preload" as="image">`. Post-fix LCP 2.3s. ✓
+
+**Happy path — Three.js scene** — Baseline 28fps; budget 60fps. Bottleneck: 200 trees rendered with 200 separate draw calls. Fix: `InstancedMesh` with one geometry. Post-fix 62fps. ✓
+
+**Edge case — query plan changed in production** — Same query is fast in staging, slow in prod. EXPLAIN ANALYZE in prod shows a `Seq Scan`; `pg_stat_user_tables` reveals a missing index in prod (drift from staging). Add the index; re-measure.
+
+**Negative — premature optimisation** — "Add Redis caching everywhere just in case." Refuse. No measured baseline; no budget violation. Caching is a footgun (invalidation), don't ship it speculatively.
+
+## Memory Bank Hooks
+
+- **Reads:** `.rcode/memory/project/stack.md` (which layer is in scope)
+- **Writes:** when an optimisation establishes a long-lived pattern (e.g. "all hero images use AVIF"), append to `.rcode/memory/project/decisions.md`

package/rcode/skills/actions/4-implementation/rcode-prove-it/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: rcode-prove-it
+internal: true
+description: Test-first development.
+triggers:
+  - "prove it"
+  - "tdd"
+  - "test first"
+  - "write a failing test"
+  - "red green refactor"
+  - "test driven"
+  - "regression test"
+  - "reproduce the bug first"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+Test-first cycle: red (failing test that captures the requirement) → green (smallest code that passes) → refactor (clean up with the test as safety net). For bugs: reproduce-the-bug-as-a-test before fixing — the test then guards against regression. The skill assumes a JS/TS project with Jest, Playwright, or node:test; the choice is detected from the project's `package.json`.
+
+## Workflow
+
+1. **Detect the test runner.** Read `package.json` `devDependencies` and `scripts.test`. Order of preference: `playwright` for E2E flows, `jest` or `vitest` for unit, `node --test` for zero-dep projects (rcode uses this).
+2. **For a new feature:** describe the behaviour in one sentence. Write the test that captures it. Run — confirm it fails for the right reason.
+3. **For a bug fix:** reproduce the bug as a failing test BEFORE looking at the code. The test must fail in the way the user reports.
+4. **Write the smallest code** that makes the test green. Resist the urge to handle cases not in the test.
+5. **Refactor with the test as safety net.** Rename, simplify, deduplicate. The test stays green.
+6. **Add edge-case tests** in a second pass. Common missing cases: empty input, boundary values, error paths, concurrent access.
+7. **Commit:** `test: add failing test for X` → `feat/fix: implement X` → optional `refactor: simplify Y`. Three commits, three diffs.
+
+## Output Format
+
+```
+Detected runner: <jest|playwright|node:test|vitest>
+
+Step 1 — Failing test
+  File: <path>
+  Behaviour: <one sentence>
+  Run: <command>
+  Expected to fail at: <line>
+
+Step 2 — Implementation
+  Files: <list>
+  Smallest change: <one sentence>
+
+Step 3 — Edge cases
+  - <empty input>
+  - <boundary>
+  - <error path>
+```
+
+Do NOT include: tests written after the fact, "I tested manually", or coverage as a substitute for assertions.
+
+## Examples
+
+**Happy path — bug** — "Login fails for usernames with Arabic characters" → test that calls login with "محمد" and asserts no exception → fix the encoding issue → test passes → ship the test alongside the fix as one commit.
+
+**Happy path — feature** — "Add /api/memory endpoint" → test asserts 200 + JSON shape → minimal handler → green → second pass adds tests for empty Memory Bank case.
+
+**Negative — coverage as substitute** — "We have 85% line coverage" without per-behaviour assertions. Refuse to count this as "tested". Coverage is a floor, not a ceiling.
+
+## Memory Bank Hooks
+
+- **Reads:** `.rcode/memory/project/stack.md` (to detect the test runner correctly)
+- **Writes:** append to `.rcode/memory/incidents/known-issues.md` if the bug is acknowledged but the fix is deferred

package/rcode/skills/actions/4-implementation/rcode-qa-generate-e2e-tests/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: rcode-qa-generate-e2e-tests
+internal: true
+description: >
+  Generate end-to-end tests for an existing feature using the project's
+  standard test framework. Activates when the user says "generate e2e
+  tests", "write e2e tests for", "add end-to-end test coverage", "qa this
+  feature", or "generate integration tests". Do NOT use for unit test
+  generation or code review (use rcode-review).
+triggers:
+  - "generate e2e
+  tests"
+  - "write e2e tests for"
+  - "add end-to-end test coverage"
+  - "qa this
+  feature"
+  - "generate integration tests"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+Generate end-to-end tests for an existing feature using the project's standard test framework.
+
+## Workflow
+
+Follow the instructions in ./workflow.md.
+
+## Output Format
+
+- Tests use the project's detected test framework (Playwright/Cypress/pytest/etc.)
+- Test file structure: happy path first, then alternative paths, error paths, edge cases
+- All generated tests MUST be run to verify they pass
+- Do NOT generate tests without running them
+- Do NOT use external test utilities — standard framework APIs only
+
+## Examples
+
+### Happy Path
+**Input:** "Generate e2e tests for the checkout flow"
+**Expected behavior:** Scan checkout files, detect framework, generate tests covering happy path + 3-5 error paths + edge cases, run suite, report results.
+
+### Edge Case: No Test Framework Detected
+**Input:** (project has no test setup)
+**Expected behavior:** Report: "No test framework detected. Install Playwright/Jest/Vitest first, or tell me which framework to scaffold." Do NOT invent a framework.

package/rcode/skills/actions/4-implementation/rcode-qa-generate-e2e-tests/checklist.md

@@ -0,0 +1,33 @@
+# Quinn Automate - Validation Checklist
+
+## Test Generation
+
+- [ ] API tests generated (if applicable)
+- [ ] E2E tests generated (if UI exists)
+- [ ] Tests use standard test framework APIs
+- [ ] Tests cover happy path
+- [ ] Tests cover 1-2 critical error cases
+
+## Test Quality
+
+- [ ] All generated tests run successfully
+- [ ] Tests use proper locators (semantic, accessible)
+- [ ] Tests have clear descriptions
+- [ ] No hardcoded waits or sleeps
+- [ ] Tests are independent (no order dependency)
+
+## Output
+
+- [ ] Test summary created
+- [ ] Tests saved to appropriate directories
+- [ ] Summary includes coverage metrics
+
+## Validation
+
+Run the tests using your project's test command.
+
+**Expected**: All tests pass ✅
+
+---
+
+**Need more comprehensive testing?** Install [Test Architect (TEA)](https://rcode-org.github.io/rcode-test-architecture-enterprise/) for advanced workflows.

package/rcode/skills/actions/4-implementation/rcode-qa-generate-e2e-tests/workflow.md

@@ -0,0 +1,136 @@
+# QA Generate E2E Tests Workflow
+
+**Goal:** Generate automated API and E2E tests for implemented code.
+
+**Your Role:** You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the `rcode-review` skill for that).
+
+---
+
+## INITIALIZATION
+
+### Configuration Loading
+
+Load config from `{project-root}/.rcode/config.json` and resolve:
+
+- `project_name`, `user_name`
+- `communication_language`, `document_output_language`
+- `implementation_artifacts`
+- `date` as system-generated current datetime
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Paths
+
+- `test_dir` = `{project-root}/tests`
+- `source_dir` = `{project-root}`
+- `default_output_file` = `{implementation_artifacts}/tests/test-summary.md`
+
+### Context
+
+- `project_context` = `**/project-context.md` (load if exists)
+
+---
+
+## EXECUTION
+
+### Step 0: Detect Test Framework
+
+Check project for existing test framework:
+
+- Look for `package.json` dependencies (playwright, jest, vitest, cypress, etc.)
+- Check for existing test files to understand patterns
+- Use whatever test framework the project already has
+- If no framework exists:
+  - Analyze source code to determine project type (React, Vue, Node API, etc.)
+  - Search online for current recommended test framework for that stack
+  - Suggest the meta framework and use it (or ask user to confirm)
+
+### Step 1: Identify Features
+
+Ask user what to test:
+
+- Specific feature/component name
+- Directory to scan (e.g., `src/components/`)
+- Or auto-discover features in the codebase
+
+### Step 2: Generate API Tests (if applicable)
+
+For API endpoints/services, generate tests that:
+
+- Test status codes (200, 400, 404, 500)
+- Validate response structure
+- Cover happy path + 1-2 error cases
+- Use project's existing test framework patterns
+
+### Step 3: Generate E2E Tests (if UI exists)
+
+For UI features, generate tests that:
+
+- Test user workflows end-to-end
+- Use semantic locators (roles, labels, text)
+- Focus on user interactions (clicks, form fills, navigation)
+- Assert visible outcomes
+- Keep tests linear and simple
+- Follow project's existing test patterns
+
+### Step 4: Run Tests
+
+Execute tests to verify they pass (use project's test command).
+
+If failures occur, fix them immediately.
+
+### Step 5: Create Summary
+
+Output markdown summary:
+
+```markdown
+# Test Automation Summary
+
+## Generated Tests
+
+### API Tests
+- [x] tests/api/endpoint.spec.ts - Endpoint validation
+
+### E2E Tests
+- [x] tests/e2e/feature.spec.ts - User workflow
+
+## Coverage
+- API endpoints: 5/10 covered
+- UI features: 3/8 covered
+
+## Next Steps
+- Run tests in CI
+- Add more edge cases as needed
+```
+
+## Keep It Simple
+
+**Do:**
+
+- Use standard test framework APIs
+- Focus on happy path + critical errors
+- Write readable, maintainable tests
+- Run tests to verify they pass
+
+**Avoid:**
+
+- Complex fixture composition
+- Over-engineering
+- Unnecessary abstractions
+
+**For Advanced Features:**
+
+If the project needs:
+
+- Risk-based test strategy
+- Test design planning
+- Quality gates and NFR assessment
+- Comprehensive coverage analysis
+- Advanced testing patterns and utilities
+
+> **Install Test Architect (TEA) module**: <https://rcode-org.github.io/rcode-test-architecture-enterprise/>
+
+## Output
+
+Save summary to: `{default_output_file}`
+
+**Done!** Tests generated and verified. Validate against `./checklist.md`.