菜单
Fetch live ThumbGate revenue, paid orders, and funnel telemetry from production billing endpoints. Use BEFORE answering any question about money, conversion, traffic, or "why we didn't make X." Never quote planning documents as actuals.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
ThumbGate provides pre-action gates for AI coding agents. It captures thumbs-up/down feedback on agent actions, auto-promotes repeated failures into prevention rules, and blocks known-bad tool calls via PreToolUse hooks. Trigger when the user wants to add safety guardrails to an AI agent workflow, capture structured feedback on agent output, generate prevention rules from failure patterns, gate high-risk actions before execution, or export DPO training pairs from production feedback. Works with any MCP-compatible agent including Cursor, Codex, Gemini CLI, Amp, and OpenCode.
Make any ThumbGate-facing copy — landing/pricing/compare/guide pages, README, postinstall banners, CLI receipts, Reddit/LinkedIn/Bluesky/Threads posts, docs, outreach drafts, blog/launch content — sound like ThumbGate: direct, technical, honest, anti-hype. Use BEFORE writing or editing customer-facing or marketing text, and when the user says "write a landing page", "draft a Reddit/LinkedIn post", "write the README", "make this on-brand", "punch up this copy", or "review this copy for voice". Do NOT use for code comments, commit messages, internal notes, or non-ThumbGate copy — and never to add fabricated traction or unsupported claims (honesty is the brand).
Capture thumbs up/down feedback into structured memories and prevention rules. Require one sentence of why before claiming memory promotion. Use when user gives explicit quality signals about agent work (e.g. "that worked", "that failed", "thumbs up/down"). Do NOT use for general questions, code generation, file operations, or any task that is not explicit feedback on prior agent output.
Give your agent persistent cross-session memory — recall what went wrong on similar tasks before starting, then capture whether the work succeeded or failed so repeated mistakes auto-promote into prevention rules. Runs locally via the ThumbGate MCP server (recall, capture_feedback, prevention_rules, feedback_stats) — no API key needed. Use when the user says "recall", "what went wrong last time", "remember this for next time", "capture feedback", "thumbs up/down on that", or at the start of a new task or session. Do NOT use when the user wants to force one specific mistake into an enforced block gate (use the thumbgate-guard skill), to list rules that already exist (thumbgate-rules), or to check ThumbGate wiring (thumbgate-doctor).
Course-correct from over-planning to execution — when the agent has produced a plan, research, or options instead of doing work the user already approved, drop the analysis and execute the smallest end-to-end action now (branch, run, deploy, verify). Use when the user says "stop planning, just do it", "why are you researching, execute", "just ship it", "enough analysis", or pushes back that you keep proposing instead of acting on an already-decided task. Do NOT use when the task is genuinely undecided and needs a plan first, when the user explicitly asked for research/options/a design, or for routine work where no over-planning has occurred — acting on an unscoped or destructive task is its own failure.
Show ThumbGate's enforcement record — how many risky actions were actually blocked versus warned, which gates fire most, the tokens/damage saved, and the full feedback to check to rejection pipeline. Reads live enforcement counters via the gate_stats and enforcement_matrix MCP tools (CLI fallback `npx thumbgate gate-stats`). Use when the user says "what has ThumbGate blocked", "show gate stats", "is enforcement working", "how many tokens did we save", "show the enforcement matrix", or "what got stopped". Do NOT use to list rule DEFINITIONS that exist (use the thumbgate-rules skill), to create a new rule (use the thumbgate-guard skill), or to check whether ThumbGate is installed and wired (use the thumbgate-doctor skill).
基于 SOC 职业分类
| name | revenue-truth |
| description | Fetch live ThumbGate revenue, paid orders, and funnel telemetry from production billing endpoints. Use BEFORE answering any question about money, conversion, traffic, or "why we didn't make X." Never quote planning documents as actuals. |
| allowed-tools | ["Bash","Read"] |
On 2026-05-26 the CTO answered "why didn't we make money?" three times in a row by quoting planning documents and stale March snapshots as if they were current telemetry. The CEO had to push back with "are you sure?" three times before the CTO admitted he had never queried the live billing endpoint. This skill exists so that never happens again.
The first version of this skill (written same day) referenced an env var named THUMBGATE_ADMIN_KEY that does not exist anywhere in the codebase — a name I invented without grepping. The CEO caught it with another "are you sure?". The skill now defers to the canonical scripts/revenue-status.js pipeline so it cannot drift again.
Before claiming any revenue, visitor, conversion, or funnel number, you MUST run node scripts/revenue-status.js and quote its output. If no credentials are configured, say so — do not fall back to planning docs.
node scripts/revenue-status.js
Reads credentials in this exact priority order (same as scripts/operational-summary.js and scripts/operational-dashboard.js):
$THUMBGATE_OPERATOR_KEY — read-only billing-summary access, recommended for agents~/.config/thumbgate/operator.json — created by node bin/cli.js billing:setup$THUMBGATE_API_KEY — full admin, only when operator unavailableOutput sections (quote these directly, never paraphrase):
Source: — hosted-billing-summary (live) vs local-fallback (no creds)Today / 30d / Lifetime: — visitors, pageViews, checkoutStarts, paidOrders, bookedRevenue30d attribution coverage — channel telemetry qualityGaps: — exact phrases describing what's missingIf you need a single field rather than the full report, query directly:
KEY="${THUMBGATE_OPERATOR_KEY:-${THUMBGATE_API_KEY:-}}"
[ -z "$KEY" ] && { echo "no operator/api key configured"; exit 1; }
curl -fsS \
-H "Authorization: Bearer ${KEY}" \
"https://thumbgate-production.up.railway.app/v1/billing/summary?window=30d" \
| jq '{
window,
booked_cents: .revenue.bookedRevenueCents,
paid_orders: .revenue.paidOrders,
checkout_starts: .funnel.checkoutStarts,
visitors: .funnel.uniqueVisitors,
acquisition: .funnel.acquisitionBySource
}'
curl -fsS https://api.stripe.com/v1/charges?limit=20 \
-u "${STRIPE_SECRET_KEY:?set STRIPE_SECRET_KEY in env}:" \
| jq '[.data[] | select(.paid==true and .refunded==false)
| {amount, created, description, customer}]
| {count: length, total_cents: (map(.amount) | add)}'
Note the var is STRIPE_SECRET_KEY (matches src/api/server.js:2597), not STRIPE_SECRET. If the two sources disagree, /v1/billing/summary is truth for booked-revenue claims; Stripe disagreement is an attribution bug worth filing.
| Source | Truth? | Notes |
|---|---|---|
scripts/revenue-status.js output where Source: hosted-billing-summary | YES | Backed by Stripe-reconciled ledger |
scripts/revenue-status.js output where Source: local-fallback | NO | Means no key configured; numbers are zero-state local |
Stripe API /v1/charges | YES | Cross-check only |
reports/gtm/*/operator-close-packet.md numbers labeled "revenue plan" | NO | These are forecasts |
docs/VERIFICATION_EVIDENCE.md snapshot dates | YES at that date, NO as current | Always check the date in the section heading |
docs/COMMERCIAL_TRUTH.md cumulative line | YES as of file's "Updated:" date | Stale if git log -1 -- docs/COMMERCIAL_TRUTH.md is >7 days old |
State this exactly:
"No operator key in this session's env and no
~/.config/thumbgate/operator.jsonon this container.scripts/revenue-status.jsreportsSource: local-fallback. The last verified production snapshot in the repo is<date>: <numbers>fromdocs/VERIFICATION_EVIDENCE.md. Any number labeled '30d' in operator packets without a corresponding live curl is a forecast, not measured traffic."
Then offer one specific resolution:
"To unlock live numbers for this session AND future sessions: paste a
THUMBGATE_OPERATOR_KEYvalue into the harness env (the agent container's env, not Railway's server env). Generate one withnode bin/cli.js billing:setupon a machine where the admin key is already configured, or copy the existing operator key from Railway's variables."
Then stop. Do not speculate. Do not quote forecasts as actuals.
When booked revenue is low, also pull acquisition breakdown:
KEY="${THUMBGATE_OPERATOR_KEY:-${THUMBGATE_API_KEY:-}}"
curl -fsS \
-H "Authorization: Bearer ${KEY}" \
"https://thumbgate-production.up.railway.app/v1/billing/summary?window=30d" \
| jq '.funnel.acquisitionBySource'
This tells you whether traffic came from channels we actually posted to (Bluesky, Threads, Reddit) or from background ai_search / direct. Channel mismatch is usually the real story.
Use the wrapper, not the raw script:
npm run revenue:truth # or: bash bin/revenue-truth.sh
The wrapper handles three branches:
Source: hosted-billing-summary.~/.config/thumbgate/operator.json exists but no longer authenticates against Railway after a rotation). Runs the pipeline, then prints a loud WARNING — configured operator key authenticated against the LOCAL fallback block with the exact fix command. This is what you want to see when describing the 401 to the CEO instead of guessing.$CI, $CODESPACES, $GITHUB_ACTIONS, $CLAUDE_CODE_REMOTE, or /home/user/... Linux container path). Prints a one-paragraph "revenue truth is local-only by design, run from your laptop, do NOT paste the key here" message and exits 0. This is the expected posture for cloud sessions — not a bug, not a blocker, not something to keep reporting back to the CEO.The wrapper refuses to accept the operator key as a CLI argument (exits 64). Pasting the key on the command line would leak it to shell history; pasting it into the Claude transcript would leak it to the model context. Per CLAUDE.md hard-block rule #2.
Anti-pattern this section exists to prevent: an agent in a cloud session running node scripts/revenue-status.js directly, hitting 401, then repeatedly telling the CEO "I can't see hosted revenue" across multiple turns as if it were news. After the first observation, route to npm run revenue:truth so the diagnostic message is the response, not a back-and-forth.