菜单
Merge a green PR to main and verify CI succeeds (staging deploy + draft releases). Use when the user says "merge", "land", "land PR", "merge this", or when a PR has passed CI and is ready to merge. This does NOT deploy to production — use /release-app for that.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | land-pr |
| description | Merge a green PR to main and verify CI succeeds (staging deploy + draft releases). Use when the user says "merge", "land", "land PR", "merge this", or when a PR has passed CI and is ready to merge. This does NOT deploy to production — use /release-app for that. |
Merge a green PR to main and verify CI succeeds. In this repo, merge to main triggers staging deploys and creates draft releases — it does NOT deploy to production. Production release is a separate step via /release-app.
Production deployment requires manually publishing those draft releases (or using /release-app).
gh pr view <PR_NUMBER> --json state,isDraft,mergeable,statusCheckRollup,reviewDecision
Verify ALL of these:
If a precondition fails (other than Draft), report which one and stop.
If isDraft === true, this PR has not been E2E-verified (the Draft gate skips E2E: Lite). /land-pr means "I want this merged" — so flip it Ready, wait for the resulting CI run with E2E to go green, then merge. Don't refuse and don't merge without verification.
gh pr ready <PR_NUMBER> --repo ZenUml/conf-app
Tell the user: "PR is Draft → marking Ready and waiting for CI (~14 min) to verify E2E before merge."
Then delegate to /babysit-pr <PR> (or watch inline). If the new CI run fails, stop and report — do not merge.
If isDraft === false already, skip this step.
Confirm CI is green and E2E: Lite is among the passed checks (not skipped). Re-run the precondition checks. If anything is not green, stop and report.
Fetch the repo's enabled merge strategies and pick the right flag (GitHub requires one when multiple strategies are enabled):
MERGE_FLAG=$(gh api repos/ZenUml/conf-app \
--jq 'if .allow_squash_merge and (.allow_merge_commit | not) and (.allow_rebase_merge | not) then "--squash"
elif .allow_rebase_merge and (.allow_merge_commit | not) and (.allow_squash_merge | not) then "--rebase"
else "--merge" end')
gh pr merge <PR_NUMBER> --auto --delete-branch $MERGE_FLAG
Logic: use --squash if only squash is enabled, --rebase if only rebase is enabled, otherwise --merge (GitHub's default when multiple strategies are on). Do not override with --squash or --rebase unless the user explicitly requests it.
Using --auto arms auto-merge so GitHub merges when all checks pass.
gh pr view <PR_NUMBER> --json state
Poll until state is MERGED. Timeout after 5 minutes.
After merge, the Build, Test and Draft Release workflow runs on main. Watch it:
gh run list --repo ZenUml/conf-app --branch main --limit 1 --json databaseId,status,conclusion
gh run watch <RUN_ID> --repo ZenUml/conf-app
gh release list --repo ZenUml/conf-app --limit 4
Confirm draft releases were created for the expected variants.
Report one of:
Do NOT auto-rollback. Report:
The user decides whether to hotfix or revert.
/release-app for that)/submit-branch)/validate-branch)Enable, launch, monitor, troubleshoot, and stop the local joint-debug environment across conf-app, its Cloudflare Worker, ngrok, Forge tunnel, and diagramly.ai. Use for requests mentioning joint-debug, join-debug, combined local AI Repair testing, starting or monitoring the five-service stack, or closing that stack.
Get the per-space macro count for ONE named client (Confluence tenant/domain), triangulated across three independent sources: Metrics KV (current inventory), Cloudflare D1 (lifetime rows), and Mixpanel (90-day distinct macros viewed). Use whenever a request names one specific tenant (e.g. acme-corp, "our biggest lite customer") and asks how many macros or diagrams it has per space, wants to size a tenant against the Lite 100-macro paywall, reconcile per-space counts that disagree between KV/D1/Mixpanel, spot spaces with many macros but few recent views, or count distinct macros viewed per space over the last N days — even when only one source is named. Prefer this over conf-app, mixpanel, duckdb, or growth whenever the subject is one named tenant and the answer is a per-space macro tally. Do NOT use for product-wide totals across all tenants (use conf-app), single-page macro counts (find-macros-on-page), render-time/duration metrics (rendering-perf), install/marketplace counts (forge-installs), or one-off KV
Manage the ZenUML Lite paywall rollout (Lite variant only — Full and Diagramly have no restrictions). Decide which domains to enroll in CUSTOMER_SUCCESS_SERVICE (CSS), monitor daily paywall activity, and generate the exact KV commands to execute. Use this skill whenever the user asks about paywall rollout, which clients to enable, the CSS flag, tenant enrollment state, space licensing, or "who should be on the paywall list". Also use when the user asks to check a specific domain's paywall state, wants to understand why a tenant is or isn't seeing the paywall, or wants to A/B compare paywall impact (treatment vs. control tenants).
Near-term Atlassian Marketplace cash view for the ZenUML apps — what vendor income to expect over the next few days (client subscriptions renewing) and which paying clients missed a payment in the past few days (renewal lapsed / in grace / dead payment method). Use when the user asks "what income am I expecting", "what's landing this week", "any renewals coming up", "did anyone miss a payment", "who's late", "income projection for the next few days", or wants a daily payments radar. Built on the marketplace-audit engine (licenses + transactions joined on cloudId), payers only, all revenue apps. For lifetime revenue / top payers / a full renewals-in-a-window audit use `marketplace-audit`; for a single tenant's paid status use `tenant`.
Audit Atlassian Marketplace vendor reporting (licenses + sales transactions) for the ZenUML apps at the PORTFOLIO / cohort level — lifetime vendor revenue, renewals due in a date window, annual vs monthly billing, overdue / lapsing payers, top payers, churned payers. Use whenever the user asks about revenue, renewals, "who's overdue", "which annual customers renew this month", biggest paying customers, or any rollup across the customer base — even if they don't say "Marketplace". For a SINGLE tenant's paid status / size / profile ("is <domain> a paying customer", "look up <domain>", trial expiry), use the `tenant` skill instead. Discriminator: a cohort / time-window / ranking -> this skill; one domain in the question -> `tenant`. Prefer this over ad-hoc curl: it uses the fast bulk export endpoint and joins licenses to transactions correctly on cloudId (naive approaches truncate at a 50-row page cap and undercount revenue). Also hosts the shared engine (`scripts/mp_report.py`) + `sync` snapshot that the `tenan
Fulfil a Lite paywall lockout / "temporary editing extension" request — grant a temporary license that lifts the Lite per-space 100-macro limit, by default for ONLY the requesting user, then draft the customer reply. Use whenever a customer (via the JSM extension-request flow or direct email) asks to re-open editing on a space that hit the diagram limit, or when handed a request with a client domain + space key + macro count. It resolves the cloudId, verifies the exact space key, writes the SPACE_LICENSE_KV record, verifies it, computes the Full-plan upgrade price, and drafts the reply from the canonical template. Triggers on "extend", "extension request", "temporary editing extension", "grant a space license", "re-open editing", "paywall lockout", "lift the limit for <space>", "request: temporary Lite editing extension". For the reply template + sent log see the handbook page paywall/extension-request-replies.md; for per-space macro counts use macro-count.