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.