Update the GitHub issue linked to completed Factory work after verifying the target repository. Remove specified triage labels and, for open issues, add a pending-close label and completion comment without closing the issue.
Mark a GitHub issue as done and update its status labels
Review the instructions the agent will receive before you install.
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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Design and audit an agent's system prompt, the instructions that guide its work. Define a concrete outcome, starting input, available tools, completion checks, fallback behavior, and final report so the prompt describes a complete run.
Create a dedicated test project linked to the current worktree and check Agent Builder through APIs and browser interactions. It covers agent and skill management, permissions, defaults, and related features, with selectable test sections.
Reviews pull requests for bugs, error handling, code quality, and style consistency. Organizes feedback into an overview, must-fix issues with file locations, improvement suggestions, and positive notes so reviewers can distinguish urgent problems from refinements.
Design instructions for agents that write, fix, review, or refactor code. Define behavior based on file access, select suitable tools, and set clear verification and completion rules for repository changes or copyable code output.
Configure Factory board behavior and GitHub or Linear event handlers in deployment code. Adjust stage transitions, phase meanings, and tool-result handling, then check the changes with focused tests and versioned audit records.
Design agents that draft blog posts, social posts, newsletters, and marketing copy. Define the audience, brand voice, length, and required output so each agent delivers a complete draft with a headline and supporting notes.