mushi-integration — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited mushi-integration (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 1 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
mushi doctor passes (all green) — run mushi-health first if unsure.anthropic and firecrawl is active.Send a real test report through the SDK pipeline:
mushi testExpected: 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').
Confirm the classifier ran:
mushi reports list --limit 1Expected output includes severity, category, and blast_radius.
Verify via MCP:
get_report_detail(reportId)Confirm classification.severity and classification.category are set.
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 proposalsVerify 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.
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 reviewExpected 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)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)If Stage 5 produced a failure, trigger the PDCA improver:
mushi tdd improveExpected: 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.
Check the full PDCA dashboard to confirm the loop is converging:
Via MCP resource:
project://dashboardLook for:
judge_scores over time.recurrence_rate (same bugs re-appearing).fix_attempts with status = 'completed' outpacing failed.| 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. Use mushi-debug for targeted diagnosis.
story-mapper function.test-gen-from-story or pdca-runner.firecrawl_actions by default. To test Browserbase: set provider = 'browserbase' on the QA story in the console first.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.