Mark a GitHub issue as done and update its status labels
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Mark the GitHub issue behind a completed Factory work item as done and update its status labels.
Parse the issue URL or number from $ARGUMENTS first. The Factory system prompt identifies the Target repository. Before reading or changing issue state, verify the checkout with git rev-parse --show-toplevel and git remote get-url origin. Normalize SSH and HTTPS GitHub remotes to owner/repository (ignoring a trailing .git) and require the checkout remote to match the target exactly. If $ARGUMENTS contains a GitHub issue URL, extract its owner/repository and require it to match both the target and the checkout remote exactly. Never use a URL's repository to override the target. If only an issue number is supplied, resolve it explicitly in the target repository (for example, with gh issue view <number> --repo <owner/repository>), not from the current gh default. If any identity is missing or mismatched, stop without modifying the issue and report the issue URL or number, expected target, observed remote/root, and mismatch.
Once identities match, read the issue's current state and labels. Remove any of these labels that are present:
status: needs triagestatus: auto-triagedstatus: needs approvalUse gh issue edit --repo <owner/repository> to remove the listed triage labels. If the issue is open, add status: pending-close when it is not already present and post this comment unless the issue already has it. Pass --repo <owner/repository> to every gh issue read or mutation:
This issue has now been marked as done.
If the issue is already closed, do not add status: pending-close or post the comment. Do not modify any other labels or issue fields.
Do not close, reopen, or assign the issue, and do not request another Factory transition.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Universal quality bar and final audit rubric for any agent system prompt. Activate this whenever you are unsure which archetype skill applies, or as a final review pass before writing the system prompt. It defines the required run contract, completion criteria, fallback paths, response format, and anti-patterns every produced agent prompt must satisfy.
日本語の概要は準備中です。原文の説明を表示しています。
Smoke test the Agent Builder feature branch end-to-end against a hermetic project scaffolded by the skill (linked to the current worktree). Covers workspace reconciliation, stored agents/skills CRUD, ownership, visibility, stars, registry/library Copy flow, picker allowlists, model policy, RBAC role gating, role impersonation UI, builder defaults, infrastructure diagnostics, channels, and Studio + Agent Builder UI. Trigger when validating the agent-builder feature branch, PRs that touch packages/server, packages/playground, packages/playground-ui agent-builder routes, or builder EE code paths.
日本語の概要は準備中です。原文の説明を表示しています。
Code quality standards and style guide for reviewing pull requests
日本語の概要は準備中です。原文の説明を表示しています。
Authoring playbook for building agents that write, edit, review, or refactor code. Use this when the user asks for an agent that writes scripts, generates code, reviews pull requests, refactors a codebase, fixes bugs, implements features, writes tests, or works with programming languages such as Python, TypeScript, JavaScript, Go, Rust, SQL, or shell.
日本語の概要は準備中です。原文の説明を表示しています。
Configure board-owned lifecycle, policy, phase-semantics, and tool-result rules, plus integration event rules
日本語の概要は準備中です。原文の説明を表示しています。
Authoring playbook for building agents that draft written content — blog posts, marketing copy, social media posts, newsletters, product descriptions, landing pages, or ad copy. Use this when the user wants an agent that writes, drafts, or rewrites text for publication or marketing.
日本語の概要は準備中です。原文の説明を表示しています。