os-june

Run the os-june review battery over the diff between HEAD and a fixed point: a two-axis review (Standards — does the code follow this repo's documented rules; Spec — does it faithfully implement the originating issue/design) in parallel sub-agents, plus an adversarial review that attacks the change's assumptions. Every axis is a fillable prompt template that can run on any harness (Claude sub-agent, Codex, ...) via bundled runner scripts. Use when the user asks to review a branch, PR, or diff, run the review battery, re-run reviews until clean, or verify a change is aligned with its spec and repo standards.

Dispatch a scoped implementation task to another agent harness (Claude Code headless or Codex) from the current one: fill the shared task-brief template and run it through a per-harness runner script that can edit the worktree and run the gate, but never commits or pushes. Use when the user asks to delegate work to Codex or Claude, wants a second implementation pass from the other harness, or a skill (e.g. repo-review fix rounds) needs to hand a precise fix prescription to an implementer outside this session.

Run live, agent-driven end-to-end QA for os-june by opening the real app or web preview, clicking through changed flows, inspecting visible state, recording and compressing video, attaching QA videos to PRs through os-platform file uploads, capturing screenshots/logs, and reporting pass/fail evidence. Use when a user asks for full integration testing, live app QA, visual inspection, "open the app and use it", "click through it", "record the QA run", "attach the video to the PR", native Tauri verification, WKWebView inspection, onboarding smoke tests, HUD/tray/hotkey checks, or manual QA replacement by an agent. Compose Browser, Chrome, Computer Use, terminal commands, and repo tests as appropriate.

Test, screenshot, and debug a Tauri or Vite frontend in a real browser using Playwright or Chrome DevTools MCP. Use when asked to run/screenshot a desktop-app or web UI, verify a frontend change visually, debug rendering without the native build, or when the native webview (macOS WKWebView) can't be driven by Playwright/CDP. Covers faking the Tauri IPC bridge so surfaces render with no backend.

Hand the entire repo-build-pr workflow to a harness of your choice (Claude Code headless or Codex): the chosen harness acts as orchestrator and validator — it creates its own worktree, implements (sub-delegating via repo-delegate where useful), runs the gate, runs the repo-review battery with cross-harness adversarial dispatch, and either stops ready-to-publish (default) or pushes and opens the draft PR (--publish). Use when the user wants to pick which harness orchestrates a build end to end, delegate a whole task AFK, or run the same build prompt under a different orchestrator for comparison.

Query and update live Open Software os-platform production data through the platform API. Use when an agent needs current Issues/Bounties, Orgs, Projects, Submissions, Comments, Activity, Contributors, or API status, or needs to create, assign, move, or comment on tracked work.

End-to-end implementation loop for the os-june repo: study the prompt, ask the clarifying questions that change what gets built, plan and architect on the session model while delegating bulk implementation and review to cheaper strong models, isolate work in git worktrees, validate with deterministic checks plus agent-driven live app walkthroughs, record and upload QA video evidence through os-platform, open a draft PR, run the automated Greptile and Codex review loop with judgment, and mark it ready. Use when the user invokes /repo-build-pr (or $repo-build-pr in Codex), or asks to build, implement, ship, or fix something in os-june from a feature prompt, bug report, screenshot, PR comment, or tracker task id, optionally with a cross-harness implementer directive like "/repo-build-pr JUN-200 with codex".

Post-cycle retrospective for the os-june build pipeline: mine the finished session conversation, every PR review surface, and the user's corrections for evidence-backed lessons, then fold each lesson into the one skill or doc file that owns it (repo-review axes and CALIBRATION.md, repo-build-pr workflow, repo-delegate briefs, CONTEXT.md, AGENTS.md) as a small docs-only change. Use after a PR merges or a build/review loop closes, or when the user asks to run a retrospective, capture learnings, or improve the pipeline/loop from what just happened.

Autonomously remove your info from data-broker sites.

Use when the user wants to turn open Open Software Issues into AFK-ready, agent-implementable tasks: find ready-to-code Issues for an org/project, diagnose each against the local codebase (root cause, files, code fragments, dependencies, blockers, acceptance, verify), enrich the Issue description on the platform, optionally assign them to the current user, and emit a table of one-line `repo-build-pr` prompts to dispatch to autonomous agents. Triggers on "prep tasks", "get issues ready to implement", "enrich issues with diagnosis", "prepare build prompts", "ready-to-code tasks for agents".

Use when working on a Rust backend that follows the Open Software Network house style — the seven-crate Cargo workspace split (`domain / services / persistence / providers / config / api / app`) shared by `os-accounts` and `os-platform` (`fellow`). Trigger on: scaffolding a new service in this org ("like os-accounts", "fellow-sidekick"), deciding **which crate something belongs in** (trait vs impl, sqlx pool, reqwest call, business logic, handler), adding an endpoint returning the `ApiResponse<T>` envelope, wiring a provider behind a `#[async_trait]` trait, writing sqlx repositories or migrations with snake_case enums and `CHECK` constraints, or integration tests with `rstest` + real Postgres + `wiremock`. Signals without naming the architecture: `accounts-*` / `fellow-*` / `os-*` crate prefixes, axum + sqlx + figment in this org, `osk_` / `usr_` ids, figment-typed config (no `env::var`), or questions like "where does this live" / "how do we shape backends here".

Integrate consumer apps, Tauri desktop clients, or backend services with OS Accounts, the Open Software identity and credit-billing platform. Use when adding Login with Open Software, PKCE callback handling, /me, access-token verification with JWKS/ES256, auth middleware for Hono/Fastify/Express/Rust, top-up links, credit balance reads, or metered authorize->charge usage with an osk_ App API key. Trigger on mentions of OS Accounts login, credits, wallet, metering, Action tokens, Grants, Holds, usr_/agt_/agts_/txn_ ids, osk_ keys, or token validation. Includes HTTP contract plus Next.js App Router BFF, backend, and Tauri references.

Use this skill when the user wants to set up, configure, debug, or extend a GitHub Actions pipeline for a Rust backend that runs CI checks and produces a container image artifact in GHCR. Scope is **testing + artifact only** — deployment is intentionally out of scope. Trigger on: PR checks (fmt, clippy, tests, OpenAPI / contract drift) for a Rust API; build-and-push on push-to-main; tagging images `:<short-sha>` plus mutable `:staging` / `:production` pointers in GHCR; a manual promote workflow that re-tags an existing image instead of rebuilding (build-once); rollback by re-promoting an older SHA; configuring `GHCR_TOKEN` / `packages: write` permissions; debugging `api.yml`, `build-api.yml`, `promote.yml`, or the `setup-rust` / `changed-paths` composite actions. Also trigger for vaguer phrasings like "set up CI for our notes-api", "immutable image refs with manual promote", or any image-tag-promotion / staging-then-production artifact pipeline on a Rust + GHCR stack. Do not trigger for non-Rust backends or g