| name | feature-tester |
| description | Exercise an EXISTING feature or flow end-to-end and report whether it actually
works — the "vaan testaa" / AI-QA skill. Drives real behavior (DB/RLS, RPC,
edge function, or browser UI) with real roles and payloads, then reports
pass/fail with evidence. Writes NO test files and cleans up any test data.
Use for: "testaa tämä ominaisuus/flow", "aja X läpi", "toimiiko X oikeasti",
"AI-testaa", "verify this feature works", "does anon see X", checking an
approval/visibility flow, validating a flow before a human tester, confirming
a bug fix behaves correctly at runtime.
NOT for: writing test files (→ test-writer), fixing red CI (→ ci-doctor),
auditing security posture/access matrices (→ security-auditor), root-causing a
known bug (→ systematic-debugging).
Triggers: "testaa ominaisuus", "vaan testaa", "aja läpi", "toimiiko",
"AI-testaa", "ai-testattu", "feature test", "does it work", "näkyykö anonille",
"hyväksyntävirta toimii".
|
Feature Tester
Prove whether a shipped feature works right now, by exercising it — not by
reading code and reasoning, and not by writing test files. The deliverable is a
pass/fail report with evidence, plus any bug found while exercising it.
The one rule that makes a test faithful
Test at the LOWEST layer that the real user actually goes through — but first
confirm what that layer IS. A test that probes a different path than the app
uses will pass while the feature is broken (or vice-versa).
Before writing any probe, answer: how does the real client read/write this?
Grep the hook/component for the actual call before choosing. Example lesson: the
community-answer public read is a direct answers table select
(usePublishedAnswers), so its anon visibility is pure table RLS — testing an
RPC instead would have missed the bug entirely.
The golden rule: never leave test data in production
This skill runs against the live Supabase project. Every fixture MUST be
undone. In order of preference:
- Rolled-back transaction — do the whole test inside
BEGIN … ROLLBACK.
For DB/RLS tests, wrap the assertions in a DO $$ … $$ block that
RAISE EXCEPTION 'ALL PASS >> …' at the end: any failed assertion raises with
which check failed; success raises the summary. Either way the exception
rolls back ALL fixtures atomically. This is the primary pattern — see
references/rls-role-test.md.
- Create + explicit cleanup — when a rollback can't hold (e.g. an edge
function commits, or a browser flow writes). Mark rows unmistakably
(
body_md prefix ZZ_TEST_, a known test user), and DELETE them at the end.
Re-query to confirm zero test rows remain. Report exactly what was created and
removed.
- Read-only probing — best of all: if data already exists in the needed
state, just observe it (no writes). Survey with a privileged
SELECT first.
Never mutate a real user's settings/rows outside a transaction that restores
them. If a cleanup could be interrupted, capture the original value first and
restore it explicitly.
Workflow
- Restate the flow as concrete pass/fail checks. Turn "the approval flow
works" into ordered assertions with expected outcomes (C1 hidden before
approval, C2 visible after, C3 hidden without opt-in, C4 author sees own).
- Find the real path (grep the client call) → pick the layer.
- Survey live state (privileged SELECT) → reuse existing rows read-only
where possible; otherwise plan minimal fixtures + cleanup.
- Exercise each check as the real role/identity (recipes in references).
- Report: a table of check → expected → actual → pass/fail, the evidence
(counts, responses, screenshots), confirmation that all test data is gone,
and any bug found (with root cause + suggested fix). If a fix is applied,
re-run the whole suite to confirm green.
Choosing the layer — recipes
Prefer the lowest faithful layer (it's fastest and most deterministic); escalate
to the browser only when the behavior lives in the UI or when a human would only
trust an on-screen result.
Boundaries (hand off)
- Need a regression test committed to the repo →
test-writer.
- The exercise reveals a red CI / build failure →
ci-doctor.
- The question is "is this access control safe/complete" (matrix, GRANTs,
advisors) rather than "does this flow work" →
security-auditor.
- Found a bug and need to root-cause it methodically →
systematic-debugging.
- Fixing what you found is fine here; if the fix is a migration/RPC change, use
the relevant domain skill's conventions (e.g.
supabase-migration-writer).
Learnings
Read references/learnings.md before probing — it holds
gotchas (rollback-vs-result, role-impersonation, faithful-path) discovered while
running these tests.
