How do I install the Issue Pr Workflow skill?

Run npx skillmds@latest add tomevault-io/issue-pr-workflow in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Issue Pr Workflow safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Issue Pr Workflow?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Issue Pr Workflow free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Issue Pr Workflow?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Issue Pr Workflow by tomevault-io — Agent Skill

Name: Issue Pr Workflow
Author: tomevault-io

Issue Pr Workflow

GitHub issue triage, .wiki handoff updates, branch-per-issue implementation, mandatory Research Review Round, CI gating, PR comments, and issue closure. Read before sweeping issues or running the issue-to-PR loop. Use when this capability is needed.

tomevault-io Updated Sep 17, 2026

File contents

Issue PR Workflow

Read before triaging GitHub issues into .wiki, implementing issue fixes, or running the branch-per-issue PR loop.

Issue Triage

Use gh for GitHub issue and PR mutations; install or authenticate it when the environment requires it. Browser UI is only a fallback for read-only inspection when gh cannot provide the needed data.

Review open issues against current source, linked PRs, merged commits, and tests. If an issue is already fixed, invalid, unsupported by the target spec, or impossible after fact-checking, comment with the evidence, close it with the right gh issue close --reason, and remove it from .wiki entirely.

Keep .wiki as the live handoff state. It lists only open, actionable execution candidates; closed, rejected, resolved, duplicate, design-only, and speculative items must not appear there. For each remaining candidate, write the implementation outline, touched source areas, test plan, risk notes, and current blocking facts in Korean.

One Issue Loop

Work one issue per branch from an updated master.

git checkout master
git pull --ff-only
git checkout -b fix/<issue>-short-name

Use PR and commit titles in the repository Conventional Commits style, such as fix(typia): ..., feat(typia): ..., or feat(utils): .... Keep unrelated working-tree changes out of the branch and stage files explicitly when the tree is mixed.

Implement from source evidence, not from the issue text alone. Add tests that would fail without the fix, including negative or type-level cases where the bug is type-system behavior. Once the first coherent implementation and focused tests are locally green, commit, push, and open the PR immediately.

Before each commit, run the required formatter from .codex/skills/development/SKILL.md. If formatting dirties unrelated files, restore those unrelated files and keep the PR scoped.

Review Gate

Before treating a PR as merge-ready, run .codex/skills/multi-agent/SKILL.md Research Review Round on the changed source, docs, and tests. Continue rounds while at least one validated improvement survives. Commit and push each accepted improvement as a small follow-up, then rerun local validation. Do not batch review fixes into a late super-commit.

The PR is merge-ready only after both gates pass:

Research Review Round has no surviving improvement proposals.
GitHub CI checks have completed successfully, ignoring only explicitly neutral/skipped checks.

Merge only when the active operator is allowed to merge by the current repository contract. Codex hands back after the review and CI gates pass when .codex/skills/pull-request/SKILL.md says not to merge.

PR And Issue Closure

Open the PR with a complete body: changed behavior, root cause, validation commands, local limitations, and Fixes #<issue> when appropriate. Add an issue comment linking the PR and, for this TypeScript-Go / typia 13 batch, state that the fix will ship with the official typia 13 release after the TypeScript-Go official release.

When the fix is implemented and CI has passed, close the issue with gh issue close --reason completed and the same release-timing note. Do not leave closed issues in .wiki.

After the PR is merged by an allowed operator, return to master, pull, and start the next issue branch. Repeat until there are no actionable execution candidates left.

Source: samchon/typia — distributed by TomeVault.

---name: issue-pr-workflowdescription: GitHub issue triage, .wiki handoff updates, branch-per-issue implementation, mandatory Research Review Round, CI gating, PR comments, and issue closure. Read before sweeping issues or running the issue-to-PR loop. Use when this capability is needed.---# Issue PR WorkflowRead before triaging GitHub issues into `.wiki`, implementing issue fixes, or running the branch-per-issue PR loop.## Issue TriageUse `gh` for GitHub issue and PR mutations; install or authenticate it when the environment requires it. Browser UI is only a fallback for read-only inspection when `gh` cannot provide the needed data.Review open issues against current source, linked PRs, merged commits, and tests. If an issue is already fixed, invalid, unsupported by the target spec, or impossible after fact-checking, comment with the evidence, close it with the right `gh issue close --reason`, and remove it from `.wiki` entirely.Keep `.wiki` as the live handoff state. It lists only open, actionable execution candidates; closed, rejected, resolved, duplicate, design-only, and speculative items must not appear there. For each remaining candidate, write the implementation outline, touched source areas, test plan, risk notes, and current blocking facts in Korean.## One Issue LoopWork one issue per branch from an updated `master`.```bashgit checkout mastergit pull --ff-onlygit checkout -b fix/<issue>-short-name```Use PR and commit titles in the repository Conventional Commits style, such as `fix(typia): ...`, `feat(typia): ...`, or `feat(utils): ...`. Keep unrelated working-tree changes out of the branch and stage files explicitly when the tree is mixed.Implement from source evidence, not from the issue text alone. Add tests that would fail without the fix, including negative or type-level cases where the bug is type-system behavior. Once the first coherent implementation and focused tests are locally green, commit, push, and open the PR immediately.Before each commit, run the required formatter from `.codex/skills/development/SKILL.md`. If formatting dirties unrelated files, restore those unrelated files and keep the PR scoped.## Review GateBefore treating a PR as merge-ready, run `.codex/skills/multi-agent/SKILL.md` **Research Review Round** on the changed source, docs, and tests. Continue rounds while at least one validated improvement survives. Commit and push each accepted improvement as a small follow-up, then rerun local validation. Do not batch review fixes into a late super-commit.The PR is merge-ready only after both gates pass:- Research Review Round has no surviving improvement proposals.- GitHub CI checks have completed successfully, ignoring only explicitly neutral/skipped checks.Merge only when the active operator is allowed to merge by the current repository contract. Codex hands back after the review and CI gates pass when `.codex/skills/pull-request/SKILL.md` says not to merge.## PR And Issue ClosureOpen the PR with a complete body: changed behavior, root cause, validation commands, local limitations, and `Fixes #<issue>` when appropriate. Add an issue comment linking the PR and, for this TypeScript-Go / typia 13 batch, state that the fix will ship with the official typia 13 release after the TypeScript-Go official release.When the fix is implemented and CI has passed, close the issue with `gh issue close --reason completed` and the same release-timing note. Do not leave closed issues in `.wiki`.After the PR is merged by an allowed operator, return to `master`, pull, and start the next issue branch. Repeat until there are no actionable execution candidates left.---> Source: [samchon/typia](https://github.com/samchon/typia) — distributed by [TomeVault](https://tomevault.io).

Frequently asked questions