iterate-post-launch — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited iterate-post-launch (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.
You shipped. That is the beginning, not the end. Real users hit real paths you did not test. Sentry, Supabase logs, and the live UI tell you exactly what to fix next — if you know how to read them. This skill turns those signals into a ranked, actionable improvement plan and then implements it.
Plan → Signal → Triage → Fix → Verify. Do not guess what to improve. Let production data point to the highest-impact work first.
Before ANY browser action, read `protocol-browser-anti-stall`.
Read the stack before pulling any signals:
package.json → framework, Sentry SDK, Supabase client version
.env.local → SENTRY_ORG, SENTRY_PROJECT, SUPABASE_PROJECT_ID (name only)
README → any known issues the team is trackingConfirm available MCPs: plugin-sentry-sentry, plugin-supabase-supabase, user-firecrawl, user-playwright.
Run all signal sources in parallel, then synthesise.
Look up tool schemas under mcps/plugin-sentry-sentry/tools/ first.
CallMcpTool(server: "plugin-sentry-sentry", toolName: "search_issues", arguments: {
"organizationSlug": "<ORG>",
"naturalLanguageQuery": "unresolved issues last 14 days sorted by frequency",
"projectSlugOrId": "<PROJECT>",
"regionUrl": "<REGION_URL>",
"limit": 25
})For each top-5 issue, get root-cause analysis:
CallMcpTool(server: "plugin-sentry-sentry", toolName: "analyze_issue_with_seer", arguments: {
"organizationSlug": "<ORG>",
"issueId": "<ISSUE_ID>",
"regionUrl": "<REGION_URL>"
})Record per issue: title, frequency (events/users), first/last seen, component.
CallMcpTool(server: "plugin-supabase-supabase", toolName: "get_logs", arguments: {
"project_id": "<PROJECT_ID>",
"service": "api"
})CallMcpTool(server: "plugin-supabase-supabase", toolName: "get_logs", arguments: {
"project_id": "<PROJECT_ID>",
"service": "postgres"
})CallMcpTool(server: "plugin-supabase-supabase", toolName: "get_advisors", arguments: {
"project_id": "<PROJECT_ID>"
})Flag:
Navigate the app's 3–5 most-used flows as a real user. Look for:
browser_navigate → primary pages
browser_console_messages → capture errors
browser_network_requests → capture 4xx/5xx
browser_take_screenshot → visual evidence per pageFor each signal category that surfaced issues:
CallMcpTool(server: "user-firecrawl", toolName: "firecrawl_search", arguments: {
"query": "<framework> <issue-type> fix best practices 2026",
"limit": 3,
"sources": [{ "type": "web" }]
})Build an improvement backlog. For each finding:
| Field | What to fill |
|---|---|
| Source | Sentry / Supabase logs / Advisor / Live walkthrough |
| Finding | One sentence describing what is wrong |
| Affected users | High (blocks most users) / Medium (hits some) / Low (edge case) |
| Effort | S (< 1 h) / M (half day) / L (multi-day, consider splitting) |
| Priority | Critical / High / Medium / Low |
Priority mapping:
Sort the backlog: Critical first, then by impact ÷ effort (quick wins above hard ones).
For the top 5–10 items, map each to specific code:
Improvement: [title]
Root cause: [1 sentence]
Fix: [file path + what to change]
Verify: [how to confirm it is fixed]
Risk: [low / medium — explain if medium+]Present the plan to the user. Get confirmation before making changes.
Work through the approved list one by one, following workflow-coding-discipline principles:
ReadLints after each edit. Fix introduced linter errors.apply_migration for DDL, execute_sql for data fixessupabase/migrations/information_schema / pg_indexes / pg_policiesAfter each fix, drive the specific flow that was broken:
browser_navigate → affected page
browser_snapshot → confirm page renders correctly
[reproduce the original scenario]
browser_console_messages → green (no new errors)
browser_network_requests → 2xx where it was failing
browser_take_screenshot → evidence of fixed stateFor Supabase fixes, re-run the failing query with execute_sql and confirm the performance improvement or policy correction.
For Sentry issues: mark as resolved only after live verification confirms the fix, not before:
CallMcpTool(server: "plugin-sentry-sentry", toolName: "update_issue", arguments: {
"organizationSlug": "<ORG>",
"issueId": "<ISSUE_ID>",
"status": "resolved",
"regionUrl": "<REGION_URL>"
})## Post-Launch Improvement Report — [App] — [Date]
### Signal sources checked
- Sentry: [issue count, date range]
- Supabase logs: [service, date range]
- Supabase advisors: [ERROR count / WARN count]
- Live walkthrough: [pages tested]
### Improvements implemented
| # | Source | Finding | Fix (file) | Verified |
|---|--------|---------|-----------|---------|
| 1 | Sentry | [error] | [file:line] | ✅ |
### Deferred (needs more investigation or is out of scope)
| # | Finding | Why deferred | Recommendation |
|---|---------|-------------|----------------|
### Remaining Sentry noise
- [issues that are known / won't-fix / need tracking ticket]
### Before / after summary
- Errors resolved: [count]
- Queries improved: [count, estimated ms saved]
- UX issues fixed: [count]~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.