代码评审
自动化代码审查与分析
tuist-swift-review
tuist
Project-specific pull request review rules for the tuist/tuist Swift codebases. Focuses on the things only this repo knows, including preferring value types, the testing framework choice, and migration of XCTest to Swift Testing.
compare-test-case
tuist
Compares a single test case's behavior across two branches, analyzing pass/fail status, duration, flakiness, and failure details. Useful for investigating test regressions introduced by a feature branch.
analyze-selective-testing
tuist
Analyzes Xcode selective testing effectiveness for a test run, showing which test targets were skipped or ran, and diagnosing regressions in test selection. Can compare two test runs to identify what changed.
compare-bundles
tuist
Compares two app bundles to identify size changes, new or removed artifacts, and platform differences. Can be invoked with bundle IDs, dashboard URLs, or branch names.
1k-dev-commands
OneKeyHQ
OneKey development commands plus branch, commit, validation, and PR conventions.
1k-auditing-pre-release-security
OneKeyHQ
Audits security and supply-chain risk between two git refs with Codex cross-validation. 预发布安全审计（含 Codex 交叉验证）。Use when performing pre-release security audits, supply-chain reviews, or comparing two git refs for security regressions. Triggers on “预发布审计”, “security audit”, “release audit”, “安全预审”.
Recheck against upstream
melodic-software
"Re-anchor the discipline that existing state (config, code, docs, infra) is not evidence of its own correctness; audit it against CURRENT official upstream docs. Use when: 'recheck against upstream', 'check this against the docs', 'is our config still current', 'did upstream change', 'are we still doing this right', 'verify against the official docs', 'this may have drifted from upstream', 'audit our setup against the vendor docs', or at conversation start on config, infra, or integration work."
reviewing-before-pr
PostHog
Run one local Greptile review of a branch before its PR opens, with hogli review. Opt-in: it needs a seat on PostHog's Greptile workspace, which most people do not have yet, so use it only when someone asks for a local Greptile review by name. Trigger terms: hogli review, greptile, local review, pre-PR review.
openclaw-update
openclaw
"Route routine updates of an existing local or remote OpenClaw Gateway to its installation owner, with automatic session recovery. Defer to deployment-specific skills when available."
exploring-llm-traces
PostHog
Debug and inspect LLM/AI agent traces using PostHog's MCP tools. Use when the user pastes a trace or session URL (e.g. /ai-observability/traces/<id> or /ai-observability/sessions/<id>), asks to debug a trace, figure out what went wrong, check if an agent used a tool correctly, verify context/files were surfaced, inspect subagent behavior, investigate LLM decisions, or analyze token usage and costs. Also use when raw SQL/HogQL against events.properties.$ai_input / $ai_output_choices returns empty — message content lives only on the dedicated posthog.ai_events table.
authoring-ci-workflows
PostHog
Use when adding or editing a GitHub Actions workflow, composite action, or reusable workflow under .github/ — new CI jobs, triggers, matrices, checkout/clone tuning, action pinning, GitHub App token auth, concurrency groups, timeout-minutes, paths filters, caching, or runner choice. Covers PostHog's workflow-authoring conventions and the reasons behind them: the 500-runs/10s dispatch cap, shallow vs full clone, per-SHA push concurrency, dedicated App-token rate-limit buckets, and fork-safe secrets on a public repo. Points to the linters (bin/hogli lint:workflows, actionlint) that enforce the mechanical rules, and to the narrower skills for production deploys, secrets, and Depot runners. Not for debugging red CI (use debugging-ci-failures) or wiring a new secret end to end (use managing-github-actions-secrets).
qa-team
PostHog
Multi-agent QA review team for code changes. This skill should be used when the user asks to "review my code", "run QA", "qa-team", "review this branch", "code review", "check my changes", or wants a comprehensive multi-perspective code review of the current branch's changes. Spawns parallel specialist agents (security, database, reliability, compatibility, data integrity, performance, frontend, copy) that independently review the diff and produce a converged report. Also includes two generalist reviewers for convergence validation.
exploring-llm-clusters
PostHog
'Investigate AI observability clusters — understand usage patterns in AI/LLM traffic, compare cluster behavior, compute cost/latency metrics, and drill into individual traces within clusters.'
reviewing-personhog-protocol
PostHog
The full review process for personhog coordination-protocol changes — leases, fencing, handoffs, supervisors, failure budgets, warming, and changelog semantics. Use before pushing or requesting review on any personhog protocol changeset, when asked for an exhaustive or careful review of personhog code, and after any reviewer finds a gap the author missed. Covers the adversarial two-pass process, the review lens dimensions, the model-checking and test layers a change must clear, and the red-check-every-fix discipline.
ingestion-pipeline-doctor-nodejs
PostHog
Ingestion pipeline architecture overview and convention reference. Use when you need a quick orientation to the pipeline framework or want to know which doctor agent to use for a specific concern.
adding-mcp-store-servers
PostHog
Add a third-party MCP server (Linear, Notion, GitHub, ...) to the PostHog MCP store catalog. Use when asked to "add X to the MCP store", expand the MCP server marketplace, or fix a broken catalog entry. Covers finding the vendor's remote MCP endpoint, probing it (handshake, OAuth discovery, DCR), authoring the catalog entry in products/mcp_store/backend/catalog.py, verification tiers, and the operator handoff for servers without Dynamic Client Registration.
implementing-agent-modes
PostHog
Guidelines to create/update a new mode for PostHog AI agent. Modes are a way to limit what tools, prompts, and prompt injections are applied and under what conditions. Achieve better results using your plan mode.
adding-inbox-sources
PostHog
Add a new warehouse-backed source to the PostHog Desktop Self-driving Inbox (the feature that ships GitHub, Linear, Zendesk, pganalyze, Jira). A source syncs one warehouse table (issues/tickets/conversations) and a cloud "signals scout" watches it and emits findings. Use when asked to "add a new inbox/self-driving source", "wire up <Jira/GitLab/Sentry/Intercom/Freshdesk/Front/Gorgias/etc> as a signal source", or to extend the source-toggle grid. Covers all three surfaces (posthog/posthog scout emitter + posthog/code UI wiring + the context-mill self-driving wizard skill that offers the source in npx @posthog/wizard self-driving), the deploy ordering between them, and created_via attribution.
react-doctor
PostHog
Diagnose and fix React codebase health issues. Use when reviewing React code, fixing performance problems, auditing security, or improving code quality.
writing-dataclasses
PostHog
House rules for Python dataclasses in PostHog: when to reach for one instead of a tuple or dict[str, Any], which decorator to use (@frozen from posthog.dataclasses), how to name, construct, consume and evolve them, how to keep secrets out of repr, and when a function should accept a dataclass instead of its unpacked fields. Use when adding or changing a dataclass, returning or passing several values from a function, converting a tuple or dict payload, deciding frozen=/slots=/kw_only=, or passing a facade contract DTO through internal layers. Not for pydantic models used as HogQL/query schema, DRF serializers, or Django models.
good-prs
ClickHouse
Show a report of open ClickHouse PRs whose only non-green CI check is "CH Inc sync" (or that are fully green) — i.e. effectively ready to merge. Groups by your authored PRs, PRs assigned to you (authored by others), and PRs by tracked authors (default groeneai). Shows the CH Inc sync state and whether each PR was ever approved; excludes already-merged PRs. Use when asked for "good PRs", merge-ready PRs, or PRs blocked only on the sync job.
perf-report
ClickHouse
Analyze CI performance comparison reports for a ClickHouse PR. Lists all regressions and improvements, cross-references with master history to distinguish real changes from flaky tests.
writing-pr-descriptions
PostHog
Shapes a PR body into something a reviewer understands at a glance. Use ALWAYS before writing or editing a PR description, before gh pr create or gh pr edit --body, and when asked to improve an existing description. Puts the effect a person sees in the first line and the mechanism under it, routes each remaining fact to the form that carries it fastest (bullet, table, diagram, screenshot, collapsed block), cuts everything a reviewer does not need, then holds what survives to a checkable shape: one fact per bullet, sentences under 25 words, active voice, no idioms. Makes the body stand alone, so a reader who opens no files still knows why the PR is necessary and what it does, sizes the body to the change so a small PR reads as small, and makes every claim either linked to its evidence or labeled as unchecked. Ends with a scan test over the title and the first lines of Problem and Changes. Not for commit messages (see AGENTS.md, "Commit types") or user-facing product copy (see /writing-user-facing-copy).
proof-video
openclaw
Capture and annotate PR screenshots and videos with measured arrows, outlines, alignment guides, spacing brackets, captions, zoom, and speed cues.