npm - @hanzlaa/rcode - Versions diffs - 3.6.15 → 4.0.0 - Mend

@hanzlaa/rcode 3.6.15 → 4.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1484) hide show

package/rcode/skills/actions/4-implementation/rcode-git-flow/SKILL.md ADDED Viewed

@@ -0,0 +1,93 @@
+---
+name: rcode-git-flow
+internal: true
+description: Branching, commits, conflicts, parallel work — aligned with the rcode Epic→Feature→Task hierarchy.
+triggers:
+  - "git flow"
+  - "branching strategy"
+  - "open a pr"
+  - "merge conflict"
+  - "rebase or merge"
+  - "feature branch"
+  - "commit policy"
+  - "branch from main"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+## Overview
+The rcode git workflow: feature branches off main, Conventional Commits, PRs that close issues with `Closes #N`, no force-push to main, no AI attribution in commit messages. Aligned with the Epic→Feature→Task hierarchy in `GITHUB_WORKFLOW.md` so every branch traces back to an issue.
+## Branching
+- **`main`** — always green. CI must pass. Never force-pushed.
+- **`feature/<short-slug>`** — branched from latest `main` for new work.
+- **`fix/<issue-N>-<slug>`** — branched from `main` for bug fixes; one branch per issue.
+- **`docs/<short-slug>`** — branched from `main` for doc-only changes.
+Naming: kebab-case slug, ≤40 chars after the prefix.
+## Commit policy
+- **Conventional Commits:** `type(scope): subject`
+- **Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `perf`, `revert`
+- **Scopes:** see `AGENTS.md` for the allow-list (`agents`, `skills`, `workflows`, `templates`, `dashboard`, `docs`, etc.)
+- **Subject:** lowercase first letter, imperative mood, no trailing period, ≤72 chars
+- **Body:** explain the WHY (the diff shows the WHAT)
+- **Footer:** `Closes #N` for the issue this commit completes
+- **Forbidden:** AI attribution lines (`Co-Authored-By: Claude`, "Generated with..."). User does not want this.
+- **Forbidden:** `--no-verify` to skip hooks. Fix the underlying issue.
+- **Forbidden:** `git add -A` or `git add .` without reading the staged set first.
+## Workflow
+1. **Sync.** `git pull --rebase origin main` before starting any new work.
+2. **Branch.** `git checkout -b feature/<slug>` from latest main.
+3. **Commit small.** One logical change per commit. Run tests before committing.
+4. **Push the branch.** **`git push origin <branch>`** requires user authorization (see `AGENTS.md` push policy). Never push to main directly.
+5. **Open the PR.** `gh pr create --base main --title "<conventional-commits subject>" --body "<body>"`. Body links the issue: `Closes #N`.
+6. **Review cycle.** Address feedback as additional commits (don't rewrite history once the PR is open).
+7. **Merge.** Squash-merge by default; preserve commit history only when the chain is meaningful (rare). After merge: `git checkout main && git pull && git branch -d <branch>`.
+## Conflict resolution
+1. Don't reflexively `git pull --rebase` mid-PR. First read both sides.
+2. Use `git mergetool` or your IDE's conflict UI — manual `<<<<<<<` editing is error-prone.
+3. After resolving: run the full test suite. Conflicts often hide behavioural overlaps the tests catch.
+4. Commit message: `merge: resolve conflicts with main` (chore-type, no scope needed).
+## Output Format
+For a new feature:
+```
+Branch: feature/<slug>   (from latest main)
+Issue: #N — <title>
+Commit plan:
+  1. <conventional commit subject>
+  2. <conventional commit subject>
+  ...
+PR title: <type>(<scope>): <subject>
+PR body footer: Closes #N
+Push approval required at: branch push, PR open, post-review push (each separately).
+```
+Do NOT include: force-pushes to main; commits with AI attribution; bundled commits ("feat: do everything").
+## Examples
+**Happy path** — Issue #387 (refresh README counts) → branch `docs/readme-counts` → 1 commit with subject `docs(readme): refresh agent/command/skill counts and add MIGRATIONS link` → push → PR with `Closes #387` → squash-merge.
+**Edge case — conflict on team.yaml** — Two branches both edit team.yaml. Resolve by: pull both versions, manually merge agent entries (preserve unique IDs), run `node --test test/agents-registry.test.cjs`, commit.
+**Negative — pushing to main** — User asks "just push it to main". Refuse — feature branches + PRs are non-negotiable per `AGENTS.md`. Open a PR even for a one-line fix.
+## Memory Bank Hooks
+- **Reads:** `.rcode/memory/project/decisions.md` (so prior branching decisions are loaded)
+- **Writes:** none directly — the skill drives git, not Memory Bank state

package/rcode/skills/actions/4-implementation/rcode-harden/SKILL.md ADDED Viewed

@@ -0,0 +1,98 @@
+---
+name: rcode-harden
+internal: true
+description: Security hardening checklist for SaaS applications.
+triggers:
+  - "harden this"
+  - "security check"
+  - "auth audit"
+  - "tenant isolation"
+  - "keycloak ad sync"
+  - "secure this endpoint"
+  - "owasp"
+  - "before we ship"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+## Overview
+Pre-launch security pass for SaaS code. Not a generic OWASP checklist — opinionated for the rcode-default stack (Next.js / Strapi / Postgres / Keycloak / Sentry). Especially focused on the failure modes that have actually bitten rcode projects: Keycloak ↔ AD sync drift, multi-tenant query leaks, and JWT-as-source-of-truth bugs.
+## Workflow
+1. **Map the attack surface.** List every endpoint, file upload, third-party webhook, and background job. If you can't enumerate them, you can't audit them.
+2. **Per surface, run the checklist** below.
+3. **Triage findings:** Critical (block launch), High (fix before next sprint), Medium (track in `incidents/known-issues.md`).
+4. **Verify fixes** end-to-end — most security bugs are caught by writing the malicious test case, not by code review alone.
+## Checklist (applied per surface)
+### Authentication
+- JWT verified on every request, not just `POST /login`. The token can be forged otherwise.
+- Issuer (`iss`), audience (`aud`), expiry (`exp`), and signature all checked. Missing any one is a compromise.
+- For Keycloak: re-fetch the JWKS keys, don't pin them — Keycloak rotates.
+- AD sync: every Keycloak login should re-validate the user against AD; stale Keycloak users post-AD-deactivation is the documented rcode incident.
+- Session invalidation on password change actually clears all sessions, not just the current one.
+### Authorization
+- Role checks AT the resource handler, not in the URL or query layer.
+- Tenant isolation: every query that reads tenant data MUST filter by tenant_id derived from the JWT, never from a request parameter.
+- "Admin" routes require role check + audit log write, in that order.
+### Input validation
+- All request bodies validated at the boundary (zod / joi / strapi schema).
+- File uploads: MIME-sniff the content, don't trust `Content-Type`; cap size; quarantine before processing.
+- Path parameters: reject `..`, absolute paths, and URL-encoded variants.
+### Data handling
+- Secrets in env vars, not in code. CI scans for committed secrets.
+- PII redacted from logs and Sentry breadcrumbs (`beforeSend` filter).
+- Encryption at rest on Postgres for any table holding government-sensitive data.
+### External integrations
+- Webhook signatures verified on receipt; replay-attack window enforced (timestamp + nonce).
+- Outbound API calls have a timeout; no infinite waits.
+- Third-party SDKs pinned to a known-good version; renovate-bot PRs reviewed manually.
+## Output Format
+```
+Surfaces audited: <count>
+Critical (block launch):
+  ✗ <surface> — <issue> — <exploit path>
+High (fix this sprint):
+  ⚠ <surface> — <issue>
+Medium (track):
+  · <surface> — <issue>
+Memory Bank update:
+  → wrote <count> entries to .rcode/memory/incidents/known-issues.md
+  → wrote audit summary to .rcode/memory/change-records/<date>-001.md
+```
+## Examples
+**Happy path** — Pre-launch audit of a tenant-isolated dashboard → finds 2 queries missing `WHERE tenant_id = $1` (CRITICAL) → 1 webhook missing signature check (HIGH) → 3 medium findings. Block launch until critical findings fixed; reaudit.
+**Edge case — Keycloak ↔ AD drift** — User deactivated in AD but their Keycloak token still works for 24h. Add: validate-against-AD step at every login + 5-minute Keycloak token TTL.
+**Negative — "we'll add security later"** — Refuse. Security retrofits are 10× the cost of building it in. Block until at least the Critical findings have a plan.
+## When NOT to use this skill
+Do NOT use this skill for CI/CD setup (use rcode-ci), performance optimization (use rcode-perf), general code review (use rcode-review), or MVP-to-production migration (use rcode-migrate).
+## Memory Bank Hooks
+- **Reads:** `.rcode/memory/project/stack.md` (auth layer detection), `.rcode/memory/incidents/post-mortems/` (prior auth/security incidents)
+- **Writes:** `.rcode/memory/incidents/known-issues.md` (deferred findings); `.rcode/memory/change-records/YYYYMMDD-NNN.md` (the audit itself as a change record)

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

@@ -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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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 ADDED Viewed

@@ -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.