corgi

Author and explain corgi-compose.yml files and the corgi CLI. Use when writing or editing a corgi-compose.yml, picking db drivers / healthchecks / tunnels, or explaining corgi concepts, commands, and flags. Corgi is a Go CLI (`brew install andriiklymiuk/homebrew-tools/corgi`) that spins up databases, services, and required tools from one yml file — think docker-compose for services plus databases plus tool checks. NOT for starting a stack (use the run skill) or diagnosing a broken one (use the debug skill).

Use to diagnose a corgi stack OR gather runtime data while investigating a bug. Entry modes — (1) broken stack — a service won't start, crashed, is stuck/unhealthy, or hangs on boot ("debug the stack", "why is X not starting", "the api is down"); (2) bug ticket needing data — pull logs, request traces, analytics, or backend perf, local or deployed ("pull the staging logs", "check the 500s", "why is this endpoint slow"); (3) CI red on a PR — a pushed branch's checks failed ("why is CI red", "the build broke"); (4) env/version skew — same code, different behavior across environments or app versions ("works on staging not prod", "old build works but latest is broken", "fine locally but 500 in prod"). Local-first (corgi ps/status/doctor/logs); escalates to the repo's logs/analytics provider (auto-detected) on demand and after asking. Client-side/UI perf is the app framework's job, not this. NOT for authoring corgi-compose.yml (corgi skill), starting a stack (run skill), or reviewing PRs (review skill).

Use when the user wants to bring up a corgi-compose stack — start, launch, run, spin up, or boot the whole stack or a slice (e.g. "run the stack", "run with tunnel and logs", "run web + mobile against the remote backend", "run just the api", "run for the android emulator"). Boots detached, waits until healthy with a timeout, flags anything stuck, reports URLs + how to stop. NOT for authoring corgi-compose.yml (use the corgi skill), shipping tickets/features (stories), or diagnosing an already-broken stack (use the debug skill).

Use when the user wants corgi to run a SUPERVISED background loop that continuously drains the build-ready ticket queue into draft PRs — "autopilot", "keep shipping the agent queue", "run the loop", "drain the backlog overnight", "babysit the queue and open PRs". Each batch still passes ONE spec sign-off gate (supervised, not zero-touch) and opens DRAFT PRs only — never merges. It composes the existing tracker pickup (/corgi-queue), stories, and review skills and is scheduled by the host's /loop or /schedule — it does not reinvent scheduling. Has a kill switch (corgi autopilot stop/pause) and a heartbeat. NOT for a single batch you'd run once with /corgi-queue, NOT for auto-merging anything, and NOT for authoring/running corgi-compose itself.

Use when generating store screenshots for an Expo / React Native app — "make App Store screenshots", "Play Market screenshots", "store screenshots for all languages", "framed marketing screenshots", "screenshots in the right store sizes", "feature graphic", "upload screenshots to the stores", "send screenshots to App Store / Play automatically", "device-frame the screenshots with headlines". Covers the capture matrix (iPhone / iPad / Android phone+tablet × locales), framing via the external app-store-screenshots editor skill, exporting at exact store sizes, and uploading with fastlane deliver/supply. NOT a single-screen verify (that's the `mobile` skill) or authoring corgi-compose (the `corgi` skill).

Use when managing In-App Purchases / store metadata / RevenueCat for an Expo / React Native app — "set up the IAPs", "push the IAP review notes", "update store metadata for purchases", "the App Review notes for each pack", "configure RevenueCat products", "add a premium pack / deck / unlock", "manage non-consumables", "sync product ids across stores". Covers the product-id source-of-truth, a version-controlled local source for per-IAP App Review notes (примечание) generated from the catalog with a drift-guard test, and pushing IAP `reviewNote` via the App Store Connect API — because fastlane `deliver` does NOT manage IAP metadata. NOT for the binary submit (ship skill) or device verification (mobile skill).

Use when the user wants a code review of one or more EXISTING pull/merge requests — any phrasing of "review this PR/MR" with GitHub PR or GitLab MR links/numbers ("review these MRs <link>", "code review <link>", "check the api + web MRs for ABC-123", or a bare link with "thoughts?"). Reviews against the repo's own standards (CLAUDE.md/AGENTS.md, lint config), pulls intent from any linked Linear/Jira ticket, runs a cross-service contract check when the set spans services, then posts a summary comment + inline suggestions behind a preview gate. ALSO use to address review feedback on your OWN PR/MR — "fix the comments on this MR", "address the feedback for story ABC-123" — reads the reviewer threads, applies the valid ones (pushes back on the wrong ones), replies + resolves, and pushes the fixes. Resolve the target from a link, a bare number, or a tracker story-id. NOT for creating PRs from issues/feature text (stories skill) or reviewing the local uncommitted diff (built-in /code-review).

Use when the user wants to ship work across a corgi-compose workspace — EITHER a batch of tracker issues (Linear/Jira links/keys like ABC-123; "do these stories", "implement these tickets", "ship X and Y") OR a free-text feature ("build a feature that …", "add X across the services") OR "find/pick what to work on" with nothing named ("pick the stories", "what should I work on", "grab some agent tickets"). NOT for authoring/running corgi-compose itself (use the corgi skill) or a trivial one-line edit you'd just make directly.

Use when the user wants corgi to PROACTIVELY surface improvements on a schedule instead of on demand — "suggest things automatically", "run suggest every week", "open a ticket for the best idea on a cadence", "be a proactive engineer / push me work", or when a scheduled job invokes /corgi-suggest-proactive. Runs the suggest ranking, dedupes the top idea against open tickets + recently-dismissed ones, and either proposes it (default) or, only if auto-file-drafts is opted in, files exactly ONE draft tracker ticket — rate-limited, never spammy, draft-only, never assigned or built. NOT for on-demand idea generation (use the suggest skill) or implementing anything (use the stories skill).

Use when the user wants feature or improvement ideas for a corgi workspace — "suggest features", "what should we build next", "ideas to improve X", "how do we make this faster/safer/cheaper", "what's missing", "any new business cases". Scans the stack + its business domain + existing features and proposes RANKED, evidence-backed suggestions across two lenses — product/business (new features, new business cases, UX) and engineering (performance, reliability, security, cost, tech-debt, even a language rewrite when the ROI is high) — each tied to a measurable outcome. Specs the chosen one and offers to create a tracker story (asks where). NOT for implementing it (use the stories skill) or authoring corgi-compose.yml (use the corgi skill).

Tracker-side work for a corgi workspace (Linear or Jira). Four jobs — (1) STATUS/standup — "where are we", "what's blocked", "give me an update"; (2) TRIAGE the inbox — "sort the new issues", "any duplicates"; (3) DECOMPOSE — "break this epic into tickets", "plan the work for X"; (4) PICK UP WORK (/corgi-queue) — "what's ready to build", "what should I start with", "pick from the backlog", "most impactful", "any bugs", "grab the agent tickets" — resolved by scope (the `agent` queue by default, a status, the backlog, priority/ROI, or links you pass) and handed to the stories skill. Edge over the tracker UI — ties each ticket to REAL code state — branch, draft/open/merged PR, CI — across every compose service (GitHub or GitLab), surfacing drift like "In Progress but no branch". Read-only itself; one confirm gate guards any write. NOT for implementing tickets (stories), ideas (suggest), reviewing PRs (review), running/diagnosing the stack (run/debug), or authoring corgi-compose.yml (corgi).

Use when verifying a mobile (Expo / React Native) change on a real device — "test on the emulator", "run it on the simulator", "screenshot the app", "drive it with Maestro", "does this screen render", "check it on Android/iOS", "tap through the app", "is the animation right" — or when a local iOS/Android build + TestFlight/Play ship needs driving. Covers the device-driving loop (deep links, Maestro flows, screenshots, sips crops) AND the gotchas that actually bite — Maestro ASCII-only input, non-login-shell pod builds, Metro `--clear` redbox desync, native-needs-rebuild, SceneKit magenta-at-runtime, square particles, apple-targets widget/App-Clip extension creds + App Group capability, stale Android autolinking package, low-disk local-build ENOSPC, native dep/ABI skew → dyld symbol-missing launch crash, Maestro `launchApp` resuming the last screen. NOT for writing the app code (normal edits) or authoring corgi-compose (corgi skill).

Use when shipping an Expo / React Native app to the stores via the repo's LOCAL build targets — "ship it", "make ship", "build and submit to TestFlight / Play", "push a release to the App Store", "cut a build", "release the app", "upload the binary". Drives a local prod build → IPA/AAB → eas submit to TestFlight + Google Play, with the shell/locale rules, the no-double-bump rule, background+poll (no completion event), ground-truth verification (not the exit code), DRAFT-on-Play behavior, and a stopShip escape hatch. Gates on the `mobile` skill's on-device render before submitting. NOT for verifying a change on a device (mobile skill), IAP / store metadata (purchases skill), or remote EAS cloud builds.

Use when the user wants to refine OR create an agent skill from what happened this conversation — "improve my <X> skill", "update the skill so next time it does Y", "the skill should've caught Z", "fix the stories/review/debug skill", "make a skill for <workflow we just did>", or hands you a SKILL.md / skill folder to sharpen. Lived failure or friction (or a workflow you just drove) in this session is the evidence. If the path points at a skill that does NOT exist yet, it SCAFFOLDS a new one there from the same evidence (a big or discipline-enforcing skill defers to superpowers:writing-skills). NOT for corgi-compose (corgi skill) or normal code edits.

The workspace memory convention for a corgi stack — a committed, shared `.corgi/memory/` store of decisions, incidents, domain facts, and recurring fixes that the suggest/debug/stories/review skills read before acting and append to after a notable outcome. Use when a skill needs to read prior workspace decisions/incidents, when recording why a choice was made or how an incident was fixed, or when a recurring fix should be PROPOSED as a learned skill/template. Read-before-act, confirm-before-write, never stores secrets, never auto-installs anything.