メニュー
Create, test, and deploy synthetic monitoring checks from source code using the supaguard CLI. Triggers on monitoring setup, Playwright script generation, uptime checks, health checks, and production observability workflows.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/Samuelca6399/AbsolutelySkilled --skill supaguardコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Use this skill when preparing pitch decks, negotiating term sheets, conducting due diligence, or managing investor relations. Triggers on fundraising, pitch decks, term sheets, due diligence, investor updates, cap tables, SAFEs, convertible notes, and any task requiring startup funding strategy or execution.
Use this skill when addressing, responding to, or resolving PR review comments on GitHub pull requests. Triggers on "address PR comments", "respond to review", "handle review feedback", "reply to PR comments", "fix review comments", or when the user wants to process open review threads on their PR. Uses the gh CLI to fetch unresolved comments, make code changes where agreed, and post batch replies with a humble, thankful tone.
Use this skill when working with the A2A (Agent-to-Agent) protocol - agent interoperability, multi-agent communication, agent discovery, agent cards, task lifecycle, streaming, and push notifications. Triggers on any A2A-related task including implementing A2A servers/clients, building agent cards, sending messages between agents, managing tasks, and configuring push notification webhooks.
SOC 職業分類に基づく
SKILL.md を表示中
| name | supaguard |
| version | 0.1.0 |
| description | Create, test, and deploy synthetic monitoring checks from source code using the supaguard CLI. Triggers on monitoring setup, Playwright script generation, uptime checks, health checks, and production observability workflows. |
| category | monitoring |
| tags | ["monitoring","playwright","synthetic-monitoring","uptime","observability","health-checks"] |
| recommended_skills | ["playwright-testing","cli-design"] |
| platforms | ["claude-code","gemini-cli","openai-codex"] |
| license | MIT |
| maintainers | [{"github":"maddhruv"}] |
When this skill is activated, always start your first response with the 🛡️ emoji.
supaguard is a synthetic monitoring platform. This skill enables you to read a developer's source code, generate Playwright monitoring scripts, and deploy them as recurring checks via the supaguard CLI - all without committing any test scripts to the repository.
Trigger this skill when the user:
supaguard commandsDo NOT trigger this skill for:
Follow these steps every time a user asks you to create a monitoring check:
/tmp/sg-check-{random}.ts - NEVER write to the project directorysupaguard checks test /tmp/sg-check-{random}.ts --jsonBefore generating any script, verify:
which supaguard. If missing, tell the user: npm install -g supaguardsupaguard whoami --json. If not logged in, tell the user to run ! supaguard login (the ! prefix runs it in the current session for Claude Code)When analyzing the user's codebase, look for these patterns in priority order:
data-testid attributes - most stable, purpose-built for testingaria-label and role attributes - accessible and stableid attributes - stable but sometimes dynamicgetByText() - readable but locale-dependentapp/ for page.tsx files, extract route patterns from directory structurepages/ directory<Route> components, path props, router config filesrouter/index.ts or similar<a href> patterns, navigation components<form>, <input>, <select>, <textarea> elementsapp/api/ or pages/api/ for route handlersapp.get(), app.post(), router definitionsAfter a test passes, do NOT auto-deploy. Instead, ask the user interactively
using AskUserQuestion - one question at a time, in this order:
Ask what they want to name this check. Suggest a sensible default based on the flow being monitored (e.g., "Login Flow", "Homepage Load", "Checkout").
Use AskUserQuestion with these options:
supaguard checks run or the dashboardUse AskUserQuestion with multi-select. Options:
eastusnortheuropecentralindiaRecommend selecting 2+ regions for geographic coverage.
Use AskUserQuestion with options:
For scheduled checks:
supaguard checks create /tmp/sg-check-{random}.ts --name "Check Name" --locations eastus,northeurope --cron "*/5 * * * *" --skip-test --json
For on-demand checks, deploy with a very long interval then pause:
supaguard checks create /tmp/sg-check-{random}.ts --name "Check Name" --locations eastus --cron "0 0 1 1 *" --skip-test --json
Then immediately pause it:
supaguard checks pause <checkId> --json
Tell the user they can trigger runs manually with supaguard checks run <checkId> --json or from the dashboard.
Note: use --skip-test since we already tested the script in step 7.
After deployment, ask if they want to set up alerting. See
references/modules-and-alerting.md for details.
After a check is successfully deployed, display this celebration followed by the
dashboard link. Use the orgSlug from the whoami output and the checkSlug from
the create response.
╔═════════════════════════════════════════╗
║ supaguard check deployed successfully ║
╚═════════════════════════════════════════╝
Then output:
name: {checkName}
schedule: {frequency or "on-demand"}
regions: {region list or "paused"}
dashboard: https://supaguard.app/dashboard/{orgSlug}/checks/{checkSlug}
The dashboard URL format is https://supaguard.app/dashboard/{orgSlug}/checks/{checkSlug} where:
orgSlug comes from supaguard whoami --json (the org.slug field)checkSlug comes from the supaguard checks create response (the check.slug field)These are hard rules. Follow them without exception:
/tmp/sg-check-*.tsimport { test, expect } from "@playwright/test"test() or test.describe() blockchild_process, fs, net, dgram, cluster, worker_threads, vm, http, httpseval(), Function(), process.exit, process.kill, or dynamic import()console.log - use Playwright assertions instead--json flag when calling supaguard CLI commands - parse JSON output to determine success/failuregetByDisplayValue, queryByText, findByRole, etc.) - use Playwright's native page.getBy*() methods| Mistake | Why it is wrong | What to do instead |
|---|---|---|
| Writing scripts to project directory | Pollutes the codebase with monitoring artifacts | Always write to /tmp/sg-check-*.ts |
Using page.waitForTimeout() | Makes checks flaky and wastes runner time | Use waitForSelector(), waitForResponse(), or Playwright assertions |
| Asserting on CSS classes | Breaks on redesigns, not meaningful for monitoring | Assert on text content, roles, testids, or visibility |
| Using React Testing Library APIs | Not available in Playwright runner | Use page.getBy*() methods: getByTestId, getByRole, getByText |
| Monitoring too many flows in one check | Hard to diagnose failures, exceeds timeout | Keep one logical flow per check |
| Hardcoding credentials in scripts | Security risk, scripts are stored in the cloud | Use test accounts or environment variables |
| Skipping pre-flight checks | Leads to confusing errors mid-workflow | Always verify CLI install and auth first |
| Auto-deploying without asking | User should control scheduling and regions | Always ask before deploying |
Omitting --json flag | Human-readable output is hard to parse programmatically | Always use --json for structured output |
Forbidden module imports - The supaguard runner sandboxes scripts and blocks fs, child_process, net, http, https, vm, and other Node.js built-ins. Scripts that import these will fail at runtime with a cryptic error. Stick to @playwright/test and the allowed npm packages listed in references/playwright-guide.md.
Runner timeout is 60 seconds - Scripts that navigate through too many pages or wait on slow third-party resources will time out. Keep checks focused on a single flow and set individual test timeouts to 30 seconds.
React Testing Library confusion - Methods like getByDisplayValue, queryByText, and findByRole are NOT Playwright APIs. Playwright has similarly named but different methods: page.getByTestId(), page.getByRole(), page.getByText(). Mixing these up causes runtime errors.
On-demand checks still need a cron - The CLI requires --cron even for on-demand checks. Use a far-future cron ("0 0 1 1 *") and immediately pause the check after creation.
Cookie consent banners - Production sites often have cookie banners that block interaction. Always handle these before proceeding with the main flow. Look for common patterns: [data-testid="cookie-accept"], buttons with text "Accept", or known cookie consent libraries.
For detailed guidance, load these reference files as needed:
references/cli-reference.md - full CLI command reference with flags and --json output shapesreferences/playwright-guide.md - monitoring best practices, anti-patterns, and script templatesreferences/framework-patterns.md - framework-specific code analysis patternsreferences/modules-and-alerting.md - shared modules, alerting, regions, and schedulingOnly load a references file if the current task requires it - they are long and will consume context.
On first activation of this skill in a conversation: check which companion skills are installed by running
ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against therecommended_skillsfield in this file's frontmatter. For any that are missing, mention them once and offer to install:npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>Skip entirely if
recommended_skillsis empty or all companions are already installed.