Weekly metrics reporting loop. Queries the metrics tables in Postgres read-only, compares this week against recent weeks, writes plain-language commentary on what moved and why, and posts one report to {{report_channel}}.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Metric definitions, the source tables/columns, and what counts as a notable
move live in project memory (memory/weekly-report.md if present) or
this skill's defaults below. Treat that as the source of truth for exactly
which metrics to report — no more, no less. If a definition is missing or
ambiguous, query the obvious candidate table and note the assumption in the
report rather than guessing silently.
Run each metric's query against the read-only role, scoped to the metrics tables:
-- This week's window: Monday 00:00 through now
SELECT metric_name, SUM(value) AS value
FROM metrics
WHERE recorded_at >= date_trunc('week', now())
GROUP BY metric_name;
Adapt the table/column names to what the schema actually exposes (e.g.
events, subscriptions, invoices) — the shape above is illustrative, not
literal. The connection is read-only: SELECT only, nothing else is
reachable through this role.
Pull the same metrics for a trailing window (default: the prior 4 weeks) so a single-week blip can be told apart from a trend:
SELECT date_trunc('week', recorded_at) AS week, metric_name, SUM(value) AS value
FROM metrics
WHERE recorded_at >= date_trunc('week', now()) - interval '4 weeks'
AND recorded_at < date_trunc('week', now())
GROUP BY 1, 2
ORDER BY 1;
For each metric, compute week-over-week change and the trend against the trailing average. Flag as notable:
| Signal | Criteria |
|---|---|
| Notable move | ≥15% change week-over-week, or a break from a 3+ week trend |
| Steady | Within normal week-to-week noise for that metric |
| Missing data | The query returned nothing for the current or a prior week — report the gap, don't fill it with a guess |
For every notable move, write one or two plain-language sentences: what changed, the likely driver if it's inferable from the data (a launch, a known outage, a seasonal pattern), and whether it's worth the team's attention. Steady metrics get the number with no commentary — don't manufacture a narrative for noise.
One message to {{report_channel}} per run, in this shape:
Post exactly once. This is a fresh session with nothing to diff against directly — the deltas come from the Step 3 query, not from any file state — so there is nothing else to update before finishing.
</workflow> <guardrails> - **Read-only, always.** The Postgres role can `SELECT` and nothing else — no insert, update, or delete — and it's scoped to the metrics tables. The report can never change the data it reports on. - **One output.** The Slack post to {{report_channel}} is the only thing that leaves the sandbox. No writes back to Postgres, no other messages. - **No memory between runs.** Each run is a fresh session; recompute this week's numbers and the trailing comparison from the current database state rather than assuming anything from a prior report. - **Scoped secrets.** Postgres and Slack access are brokered server-side through connectors; no raw credential is ever pasted into chat. - **Report, don't act.** Notable moves get called out with plain-language commentary; deciding what to do about them belongs to the team reading the report, not the agent. </guardrails> </skill>まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Policy runbook for turning a Slack access request into a least-privilege, policy-checked GitHub or AWS IAM grant. Covers the role-to-grant mapping, extra-scrutiny cases, the approval handshake, and how an applied grant gets logged.
日本語の概要は準備中です。原文の説明を表示しています。
Get a complete picture of any company or person before outreach. This skill always works with web search, and gets significantly better with enrichment and CRM data.
日本語の概要は準備中です。原文の説明を表示しています。
Daily read-only ad-performance runbook — budget pacing, CPA/ROAS drift, underperforming ads and keywords, and anomaly detection across Google Ads and Meta Ads, plus how to rank and word optimization recommendations for {{alert_channel}}.
日本語の概要は準備中です。原文の説明を表示しています。
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.
日本語の概要は準備中です。原文の説明を表示しています。
Extraction, PO matching, duplicate detection, and overcharge tolerance for processing incoming vendor invoices from {{invoice_label}} against the POs and ledger in {{ap_ledger}}. Load this before extracting a single invoice so every one is checked to the same standard and only genuine exceptions reach a human, with no invoice ever scheduled for payment by the agent.
日本語の概要は準備中です。原文の説明を表示しています。
Daily brand-mention monitoring loop for {{brand_terms}}. Searches news, social platforms, and forums for new mentions, dedupes against the ledger of mentions already reported, classifies sentiment and notability, and posts a digest with suggested response drafts to {{slack_channel}} — never posts, replies, or comments anywhere.
日本語の概要は準備中です。原文の説明を表示しています。