菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
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".
| name | os-platform |
| description | 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. |
Use this skill when the user asks about current Open Software / os-platform state or an agent needs to keep tracked work current: Issues, Bounties, Projects, Orgs, Submissions, Comments, Activity, Contributors, or whether API endpoints are real-backed. Prefer the bundled script over reading code, seed data, frontend fixtures, or docs when the question is about production data.
Run commands from this skill directory:
python3 scripts/os_platform.py status
python3 scripts/os_platform.py issues list open-software --q "wallet" --limit 10
python3 scripts/os_platform.py issues list open-software --assignee me --status todo,in_progress
python3 scripts/os_platform.py issues search open-software "wallet bug" --status todo
python3 scripts/os_platform.py issues show open-software 123
python3 scripts/os_platform.py issues create open-software --title "Fix wallet sync" --body "Issue details" --type bug --priority urgent
python3 scripts/os_platform.py issues assign open-software 123
python3 scripts/os_platform.py issues status open-software 123 in_review
python3 scripts/os_platform.py issues take open-software 123 --yes
python3 scripts/os_platform.py files upload ./evidence.mp4 --purpose attachment
python3 scripts/os_platform.py issues attach open-software 123 --path ./evidence.mp4 --public
python3 scripts/os_platform.py comments add open-software 123 --body "Opened PR #456."
Configuration:
https://app.opensoftware.co/api.OS_PLATFORM_API_BASE_URL can override the default unless --base-url is passed.OS_PLATFORM_API_KEY is required unless --api-key is passed. The script sends it as Authorization: Bearer ....OS_PLATFORM_USER_AGENT can override the default os-platform-cli/2.0 (+https://opensoftware.co) User-Agent.os-platform.json in the workspace root or a parent directory. Supported fields are org and limit; both are optional.The script is deterministic. Read commands do not mutate platform state. Write commands create Issues, assign the authenticated user, update status, add comments, upload files, or attach uploaded files. issues take remains the confirmed shortcut that moves a todo Issue to in_progress; if the Issue has no assignee, it first assigns it to the authenticated API user. Do not rely on the script to decide user intent. Route the request before calling it, and verify writes with a read.
Use the user prompt first, then os-platform.json, then ask the user for missing required parameters. Do not guess an org, issue number, project, or contributor when the prompt and config do not provide one.
org get <org>.projects list <org> or project get <org> <project>.issues list <org> with the narrowest filters.issues search <org> "<query>" with narrow filters when useful.issues show <org> <number>.issues create <org> --title <title> --body <body> with --type and --priority when known. Contract types are feature, bug, improvement, design, docs, refactor, and other; priorities are none, low, med, high, and urgent. The CLI passes both values through for platform validation.issues assign <org> <number>; --to me is accepted but optional. The command refuses to replace another assignee unless --force is passed deliberately, then re-reads the Issue to catch a concurrent assignment race.issues status <org> <number> <status> with proposed, todo, in_progress, in_review, completed, or cancelled. It refuses another user's Issue unless --force is deliberate; terminal completed and cancelled transitions require --yes.issues take <org> <number>; use --yes only when confirmation already happened in chat or another trusted workflow.files upload <path> for a private attachment, add --public only when public download access is intended, and use --purpose attachment|avatar when the default attachment is not appropriate.issues attach <org> <number> --file-id <fil_xxx> with a public upload, or --path <path> --public to upload-then-attach; --public is required with --path and acknowledges that anyone with the URL can download the file. The command preserves all existing attachments.comments add <org> <number> --body <body>.<org> and <issue-number>.contributors list <org> or contributors show <org> <user-handle>.If the user asks for issues and omits org, read os-platform.json; if it has org, use it. If no org is available, ask the user which org to use before running the script.
When the user asks for their own tasks or issues assigned to them, pass --assignee me (the script resolves me/@me to the authenticated API user via GET /v1/users/me, so no handle lookup is needed). When the user asks for issues to work on generally, prioritize todo issues assigned to the user or with no assignee before other todo issues. If the user identity is unclear, prefer unassigned todo issues.
Use the platform as the source of truth for tracked work whenever it is available.
in_progress.in_progress.issues take; its todo check and confirmation discipline are authoritative. Use separate issues assign and issues status commands only for Issues you already own.in_review when the PR opens, completed after it merges, and cancelled when the work is deliberately abandoned or will not be done.JUN-123 or a Closes JUN-123 line. The Org's GitHub pr-links webhook integration creates the platform PR link automatically; there is no CLI PR-link write command. If the integration does not link it, add the PR URL with comments add.When the user asks about a specific issue, fetch the live issue first, then inspect the current local codebase before suggesting implementation work.
issues show <org> <number> to get the live issue title, body, labels, project, and status.scripts/os_platform.py is an API helper for platform reads and controlled Issue workflow writes. It uses only Python standard library modules; file uploads invoke curl for streaming multipart transfer.
Core commands:
python3 scripts/os_platform.py status
python3 scripts/os_platform.py org get <org>
python3 scripts/os_platform.py projects list <org>
python3 scripts/os_platform.py project get <org> <project>
python3 scripts/os_platform.py issues list <org>
python3 scripts/os_platform.py issues search <org> "<query>"
python3 scripts/os_platform.py issues show <org> <number>
python3 scripts/os_platform.py issues create <org> --title <title> --body <body>
python3 scripts/os_platform.py issues assign <org> <number>
python3 scripts/os_platform.py issues status <org> <number> <status>
python3 scripts/os_platform.py issues attach <org> <number> --file-id <fil_xxx>
python3 scripts/os_platform.py issues take <org> <number>
python3 scripts/os_platform.py files upload <path>
python3 scripts/os_platform.py submissions list <org> <issue-number>
python3 scripts/os_platform.py activity list <org> <issue-number>
python3 scripts/os_platform.py comments list issue <org> <issue-number>
python3 scripts/os_platform.py comments add <org> <issue-number> --body <body>
python3 scripts/os_platform.py contributors list <org>
python3 scripts/os_platform.py contributors show <org> <user-handle>
python3 scripts/os_platform.py raw GET /v1/...
Common flags:
--limit N caps list output.--json prints the unwrapped data payload.--full prints the full unwrapped data without compact summarization. issues show always does this, so its --full flag is a backward-compatible no-op.--base-url URL overrides OS_PLATFORM_API_BASE_URL and the default base URL.issues take:
todo.in_progress, unless --yes is passed.Other writes:
issues create creates an Org-scoped Issue with a required title and body plus optional contract type and priority values. The metadata flags remain pass-through values and do not use client-side choices.issues assign fetches the Issue and resolves the authenticated user before assigning. assignee_user_id is the authoritative identity: a missing or empty value is unassigned, even if a sparse assignee display object exists. It is a no-op when already self-assigned, refuses another current assignee, and accepts --force for a deliberate replacement. After a PATCH, it re-reads and fails if another writer won the assignment race.issues status fetches the Issue and authenticated user first, prints its external id, title, and current status, and accepts proposed, todo, in_progress, in_review, completed, or cancelled. It refuses another user's Issue unless --force is passed. completed and cancelled require --yes; without it, the command prints what would change and exits without writing.files upload sends multipart file, is_public, and purpose fields to POST /v1/files; purpose is attachment or avatar and defaults to attachment.issues attach reads the Issue's existing files[].id values and sends the complete list plus the new id as file_ids through the Issue PATCH. --path uploads first with private attachment defaults.comments add adds a Markdown comment to an Issue.scripts/install.sh installs this skill into a local agent skills directory. It defaults to ~/.codex/skills, supports --dest, --source, --repo, --ref, --path, and --force, and never stores credentials.
references/api-map.md.issues show always returns the full Issue; use --json or --full on other reads when exact fields matter.bounties, explain results to users as Issues unless discussing internal implementation.issues create or comments add after a timeout or other ambiguous failure can duplicate the write. Read before retrying.OS_PLATFORM_API_KEY.Read references/api-map.md for endpoint mappings, useful filters, and real-vs-fixture guidance.