Mushi integration
π¦Curated Cursor AI agent skills, slash commands, MCP configs, subagents & rules for full-stack dev β React 19, Next.js 15, Supabase, Tailwind v4, TypeScript
npx -y skills add kensaurus/cursor-kenji --skill mushi-integrationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Full end-to-end Mushi Mushi integration smoke test: bug capture β AI triage β story mapping β TDD test generation β approval β execution β PDCA cycle. Use when "test mushi integration", "verify full pipeline", "mushi e2e check", "does mushi work end-to-end", "smoke test mushi", or after deploying changes.
The file declares its own license as MIT. That is the authorβs claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.6 KB, as published. Nobody here has run it
Mushi Integration Smoke Test
Exercises every stage of the Mushi pipeline end-to-end. Run after setup, after a deploy, or any time you need proof that the whole loop works.
Prerequisites
mushi doctorpasses (all green) β runmushi-healthfirst if unsure.- At least one BYOK key for
anthropicandfirecrawlis active. - You have the app URL you want to map stories from.
Stage 1 β Bug capture
Send a real test report through the SDK pipeline:
mushi test
Expected: Test report submitted β id: rep_...
Verify in DB (Supabase MCP):
SELECT id, status, severity, category, created_at
FROM reports
ORDER BY created_at DESC LIMIT 1;
Expected: a row with status = classified and a non-null severity within ~30 seconds.
If still pending after 60 s: classify-report edge function failed β check get_logs(service: 'api').
Stage 2 β AI triage
Confirm the classifier ran:
mushi reports list --limit 1
Expected output includes severity, category, and blast_radius.
Verify via MCP:
get_report_detail(reportId)
Confirm classification.severity and classification.category are set.
Stage 3 β Story mapping
Map user stories from a live URL:
mushi stories map --url https://your-app.com --wait
--wait polls until the crawl finishes (usually 30β90 s). Expected terminal output:
β Crawled 12 pages
β Claude drafted 8 user stories
β Proposal created: prop_...
Open in console β Inventory β Discovery β Past proposals
Verify in DB:
SELECT id, source, status, pages_crawled, created_at
FROM inventory_proposals
ORDER BY created_at DESC LIMIT 1;
Expected: source = 'live_crawl', status = 'pending_review'.
Accept the proposal in the Mushi console (Inventory β Discovery β Past proposals β Accept), or via CLI when the accept command is available.
Stage 4 β TDD test generation
Pick a story id from the accepted inventory and generate a Playwright test:
# List available stories from the accepted inventory
mushi tdd pending
# Generate a test (review mode β goes to approval queue)
mushi tdd gen <story-id> --mode review
Expected output:
β Test generated: qa_...
β Draft PR opened: https://github.com/.../pull/...
Waiting for approval β run: mushi tdd approve qa_...
Verify in DB:
SELECT id, title, approval_status, source, automation_mode, created_at
FROM qa_stories
ORDER BY created_at DESC LIMIT 1;
Expected: source = 'test_gen_from_story', approval_status = 'pending_review'.
Via MCP:
list_pending_review_stories(projectId)
Stage 5 β Approval and execution
Approve the generated test:
mushi tdd approve <qa-story-id>
Trigger a manual run immediately:
mushi tdd run <qa-story-id>
Verify in DB:
SELECT id, status, latency_ms, provider_session_url, created_at
FROM qa_story_runs
WHERE qa_story_id = '<qa-story-id>'
ORDER BY created_at DESC LIMIT 1;
Expected: status = 'completed' (or failed β a failure here is fine; it means the test ran and detected real friction).
Via MCP:
run_qa_story(projectId, qaStoryId)
Stage 6 β PDCA improvement cycle
If Stage 5 produced a failure, trigger the PDCA improver:
mushi tdd improve
Expected: Claude analyzes the failure, writes an improved test, and queues it for review.
Verify:
SELECT id, title, source, parent_story_id, approval_status, created_at
FROM qa_stories
WHERE source = 'pdca'
ORDER BY created_at DESC LIMIT 3;
Expected: at least one row with source = 'pdca' and a parent_story_id pointing to the original.
Stage 7 β Evolution loop (optional)
Check the full PDCA dashboard to confirm the loop is converging:
Via MCP resource:
project://dashboard
Look for:
- Rising
judge_scoresover time. - Falling
recurrence_rate(same bugs re-appearing). fix_attemptswithstatus = 'completed'outpacingfailed.
Pass/Fail Summary
| Stage | What ran | Status | Notes |
|---|---|---|---|
| 1. Bug capture | mushi test β reports row | β / β | |
| 2. AI triage | classify-report β severity/category | β / β | |
| 3. Story mapping | story-mapper β inventory_proposals | β / β | |
| 4. TDD generation | test-gen-from-story β qa_stories | β / β | |
| 5. Approval + run | qa-story-runner β qa_story_runs | β / β | |
| 6. PDCA improve | pdca-runner β qa_stories (source=pdca) | β / β |
All β
β Mushi is fully operational end-to-end.
Any β β the relevant edge function failed. Run the mushi MCP diagnose_setup tool for targeted diagnosis.
Tips
- Fastest smoke test: Stages 1β2 only. Takes ~60 s and confirms bug capture + triage is alive.
- Story map only: Stage 3. Useful after changing the Firecrawl key or updating the
story-mapperfunction. - TDD-only check: Stages 4β6. Run this after changing
test-gen-from-storyorpdca-runner. - Browserbase vs Firecrawl: Stage 5 uses
firecrawl_actionsby default. To test Browserbase: setprovider = 'browserbase'on the QA story in the console first.