一键在 Manus 中运行任何 Skill

issue-management

星标3

分支1

更新时间2026年3月11日 14:32

Use when checking, creating, updating, syncing, or triaging GitHub issues in this repository via scripts/issue_manager.py and direct GitHub API reads.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

doorae-lab

doorae-lab/doorae

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Issue Management

Use this skill for GitHub issue operations in this repository.

Primary tools

scripts/issue_manager.py
direct GitHub REST calls with the token in .env when the script does not expose the read path you need

If network access is blocked, request escalation instead of guessing from stale local state.

Commands

check: python scripts/issue_manager.py check --title "<title>"
create: python scripts/issue_manager.py create --title "<title>" --body "<body>"
update: python scripts/issue_manager.py update --number <n> --body "<body>"
sync: python scripts/issue_manager.py sync
push local spec: python scripts/issue_manager.py push <path>
push all specs: python scripts/issue_manager.py push-all
create PR: python scripts/issue_manager.py create-pr --title "<title>" --body "<body>" --head <branch> --base <branch>

Required workflow

Check for duplicates before creating a new issue.
Choose a UTF-8-safe write path before creating or updating any issue with non-ASCII text.
Keep one issue to one concrete outcome.
If an issue is larger than 1-2 work sessions, split it before marking it active.
Add missing labels or acceptance criteria during triage instead of creating parallel tracking elsewhere.
Only sync to .specs/ when local spec files are part of the work.

Encoding safety

Treat non-ASCII issue text as a write-path decision, not a cleanup step.

When issue titles or bodies contain Korean or other non-ASCII text:

Do not create a new issue from shell-escaped inline strings or ad-hoc here-strings.
Prefer scripts/issue_manager.py when it already targets the correct repository and write path.
Otherwise serialize the JSON payload with explicit UTF-8 before the request.
If using PowerShell REST calls, send application/json; charset=utf-8 and use [System.Text.Encoding]::UTF8.GetBytes($json) or a UTF-8 file written with Set-Content -Encoding utf8.
Fetch the created or updated issue immediately and confirm the returned title/body before telling the user the write succeeded.
If verification does not match, treat the first write as failed and retry with the verified UTF-8 payload instead of reporting success and fixing it later.

Preferred sequence:

Build the payload object.
Serialize it with explicit UTF-8.
POST or PATCH once.
Read the response back and compare the title/body.
Report success only after the comparison passes.

Triage checklist

Is this still aligned with the current product direction?
Should it be active, split, defer, or close candidate?
Does it need labels?
Does it have scope and acceptance criteria?
Is it duplicated elsewhere?
Can it fit in a short side-project session?

Spec linkage rules

Do not create a .specs document without a GitHub issue number.
Reuse the issue number in the spec filename.
Treat epics as containers; keep deliverable work in sub-issues.
Do not overwrite local spec files with sync --overwrite unless the user explicitly wants GitHub to win.

Safety

Avoid deleting issues unless the user explicitly asks.
If an issue looks stale but the decision is unclear, recommend defer or close instead of auto-closing it.
When triaging an existing backlog, call out unlabeled or oversized issues first.

Example session

Read the active backlog.
Group issues into keep, split, defer, and close candidate.
Rewrite or relabel only the issues that are about to be worked on.
Create new issues only after checking for duplicates.
Sync .specs only if the issue has a corresponding local design doc.

同仓库更多 Skills

同仓库

github-notion-project-ops

doorae-lab/doorae

Use when planning or operating a side project with GitHub issues and Notion only. Splits sources of truth, keeps active work small, and defines a low-overhead weekly and per-session routine.

2026-03-113

github-workflow

doorae-lab/doorae

Use when turning local work into a GitHub-backed change in this repository. Covers branch creation, issue linkage, push, and PR creation using local git plus scripts/issue_manager.py or direct GitHub API access.

2026-03-113

notion-edit-safety

doorae-lab/doorae

Preserve existing links when editing Notion pages. Use for any request that updates Notion page content so edits are based on the current source and do not accidentally remove previously written links.

2026-03-113

pull-request-workflow

doorae-lab/doorae

Automates the process of creating a pull request using the custom issue_manager script, replacing the need for gh CLI.

2026-03-113

spec-creation

doorae-lab/doorae

Use when creating or reorganizing `.specs` files in this repository. Keeps specs aligned with GitHub issue numbers, epic folders, and the current area-based directory layout.

2026-03-113

name	issue-management
description	Use when checking, creating, updating, syncing, or triaging GitHub issues in this repository via scripts/issue_manager.py and direct GitHub API reads.

Issue Management

Use this skill for GitHub issue operations in this repository.

Primary tools

scripts/issue_manager.py
direct GitHub REST calls with the token in .env when the script does not expose the read path you need

If network access is blocked, request escalation instead of guessing from stale local state.

Commands

check: python scripts/issue_manager.py check --title "<title>"
create: python scripts/issue_manager.py create --title "<title>" --body "<body>"
update: python scripts/issue_manager.py update --number <n> --body "<body>"
sync: python scripts/issue_manager.py sync
push local spec: python scripts/issue_manager.py push <path>
push all specs: python scripts/issue_manager.py push-all
create PR: python scripts/issue_manager.py create-pr --title "<title>" --body "<body>" --head <branch> --base <branch>

Required workflow

Check for duplicates before creating a new issue.
Choose a UTF-8-safe write path before creating or updating any issue with non-ASCII text.
Keep one issue to one concrete outcome.
If an issue is larger than 1-2 work sessions, split it before marking it active.
Add missing labels or acceptance criteria during triage instead of creating parallel tracking elsewhere.
Only sync to .specs/ when local spec files are part of the work.

Encoding safety

Treat non-ASCII issue text as a write-path decision, not a cleanup step.

When issue titles or bodies contain Korean or other non-ASCII text:

Do not create a new issue from shell-escaped inline strings or ad-hoc here-strings.
Prefer scripts/issue_manager.py when it already targets the correct repository and write path.
Otherwise serialize the JSON payload with explicit UTF-8 before the request.
If using PowerShell REST calls, send application/json; charset=utf-8 and use [System.Text.Encoding]::UTF8.GetBytes($json) or a UTF-8 file written with Set-Content -Encoding utf8.
Fetch the created or updated issue immediately and confirm the returned title/body before telling the user the write succeeded.
If verification does not match, treat the first write as failed and retry with the verified UTF-8 payload instead of reporting success and fixing it later.

Preferred sequence:

Build the payload object.
Serialize it with explicit UTF-8.
POST or PATCH once.
Read the response back and compare the title/body.
Report success only after the comparison passes.

Triage checklist

Is this still aligned with the current product direction?
Should it be active, split, defer, or close candidate?
Does it need labels?
Does it have scope and acceptance criteria?
Is it duplicated elsewhere?
Can it fit in a short side-project session?

Spec linkage rules

Do not create a .specs document without a GitHub issue number.
Reuse the issue number in the spec filename.
Treat epics as containers; keep deliverable work in sub-issues.
Do not overwrite local spec files with sync --overwrite unless the user explicitly wants GitHub to win.

Safety

Avoid deleting issues unless the user explicitly asks.
If an issue looks stale but the decision is unclear, recommend defer or close instead of auto-closing it.
When triaging an existing backlog, call out unlabeled or oversized issues first.

Example session

Read the active backlog.
Group issues into keep, split, defer, and close candidate.
Rewrite or relabel only the issues that are about to be worked on.
Create new issues only after checking for duplicates.
Sync .specs only if the issue has a corresponding local design doc.