ワンクリックでManusで任意のスキルを実行

git-issues-start

スター4

フォーク0

更新日2026年5月30日 03:57

Fetch `ready`-labeled GitHub issues, analyze complexity, and implement each in a parallel isolated worktree. Use to kick off a batch implementation run.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

ServiceNowDevProgram

ServiceNowDevProgram/ServiceNow-SDK-CC-Starter

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Step 1: Gather issues

If $ARGUMENTS is non-empty, fetch all open issues and filter to only the specified issue numbers (no label requirement):

gh issue list --state open --json number,title,body,labels,assignees --limit 100

If $ARGUMENTS is empty, fetch only issues labeled ready:

gh issue list --state open --label "ready" --json number,title,body,labels,assignees --limit 100

If no issues are found, stop and report that there are no ready issues to work on.

Step 2: Analyze each issue

For every issue, determine:

Which files likely need to change (use Grep/Glob to verify they exist)
Complexity: small (1–2 files), medium (3–5 files), large (6+ files or cross-layer)
Dependencies on other issues (shared files = must run sequentially)

Project area map:

Frontend components: src/client/components/ — React JSX + paired CSS (Name.jsx + Name.css)
Frontend services: src/client/services/ — API service modules (plain JS)
Frontend pages: src/client/ root — top-level page JSX + HTML entry points
Server logic: src/server/script-includes/, src/server/rest-handlers/, src/server/rest-api/ — ServiceNow server-side JS
Fluent definitions: src/fluent/ — TypeScript .now.ts files defining tables, seed data, business rules, navigation, form layouts
Fluent script includes: src/fluent/script-includes/ — .now.ts wrappers for server script includes
Build/config: package.json, root config files

Step 3: Build execution plan

Group issues into batches:

Issues touching completely different files can run in parallel
Issues sharing files must run sequentially within the same batch
Order batches so dependencies resolve first

Log the full execution plan:

## Execution Plan

### Batch 1 (parallel)
- #3: Fix header alignment → src/client/components/Header.jsx
- #7: Add export action → src/client/components/Toolbar.jsx, src/client/services/ExportService.js

### Batch 2 (after Batch 1)
- #12: Add new seed fields → src/client/components/DetailPanel.jsx, src/fluent/seed-data.now.ts
⚠️ Sequential — shares seed-data.now.ts with a prior dependency

Proceed immediately without asking for approval.

Step 4: Execute batches

For each batch:

Comment on each issue being started:

gh issue comment <number> --body "Starting work on this issue."

For each issue in the batch, launch a sub-agent with isolation: "worktree" using this prompt structure:
You are fixing a bug / implementing a feature for this ServiceNow scoped application. Read CLAUDE.md (if present) at the repo root for project-specific context and conventions.

Issue #: <BODY>
Project Conventions (typical ServiceNow SDK starter — override per-project in CLAUDE.md)
- Frontend components: src/client/components/ — typically paired files like Name.jsx + Name.css. Follow whatever pattern already exists in nearby files.
- Frontend services: src/client/services/ — API/service modules. Follow existing patterns.
- Server: src/server/script-includes/, src/server/rest-handlers/, src/server/rest-api/ — ServiceNow server-side JavaScript using GlideRecord and scoped-app patterns.
- Fluent layer: src/fluent/ — TypeScript .now.ts files using @servicenow/sdk Fluent API (createTable, createBusinessRule, createScriptInclude, etc.).
- Build/config: package.json, root config files.
Files to Read First
Task
1. Read and understand the relevant code
2. Make the minimal change needed to address this issue
3. Do NOT refactor surrounding code or add unrelated improvements
4. Run npm run build to verify compilation succeeds
5. Do NOT commit — leave changes uncommitted in the worktree
When done, report: which files were modified and a brief description of what changed.
Wait for all agents in the batch to finish before starting the next batch.

After each batch, comment results on each issue:

gh issue comment <number> --body "$(cat <<'EOF'
Changes ready for review.

**Files modified:**
- `path/to/file`: what changed

**Approach:**
Brief explanation of the fix/implementation.

**Testing notes:**
What to verify after deploying with `npm run deploy`.
EOF
)"

Step 5: Gather changes into main working tree (uncommitted)

After all batches complete, transfer each worktree's changes into the main working tree as uncommitted changes so the user can review everything in one place before /git-issues-end commits and pushes.

List all worktrees: git worktree list
For each worktree (excluding the main working tree):
- Stage all changes in the worktree so untracked files are included in the diff:
```
git -C <worktree-path> add -A
```
- Produce a patch of the staged changes (use --binary so binary assets apply cleanly):
```
git -C <worktree-path> diff --cached --binary > /tmp/issue-<number>.patch
```
- Apply the patch to the main working tree (without staging):
```
git apply /tmp/issue-<number>.patch
```
  If git apply fails because of overlap with an earlier batch's changes, resolve manually using context from both issues.
Do NOT stage, commit, or remove the worktrees here. The user will review the uncommitted diff, and /git-issues-end will create commits, push, and clean up the worktrees.
Run npm run build on main to verify the combined uncommitted changes compile.
- If the build fails, diagnose and fix. Leave the fix uncommitted alongside the rest — /git-issues-end will commit it.

Step 6: Present summary

Print a results table:

Issue	Title	Status	Files Changed	Build

List any issues that were skipped (ambiguous, conflicted, or failed) with reasons.

All changes are now uncommitted in the main working tree. Worktrees are intact for /git-issues-end to clean up.

Next steps:

Review the uncommitted diff (git status, git diff) to validate each change
Optionally run /deploy against dev to smoke-test on an instance
If something is wrong, edit files directly or discard pieces with git checkout -- <file>; re-run /git-issues-start <number> for a specific issue if you want to redo it
When satisfied, run /git-issues-end — it will create issue-referencing commits, push, auto-close issues via Closes #N, and remove the worktrees

Rules

Do NOT ask for approval or confirmation at any point — just do the work
Use isolation: "worktree" for each parallel agent to prevent conflicts
If an issue is ambiguous or clearly depends on out-of-scope changes, skip it and flag it in the summary
Prefer minimal, focused fixes — do not let agents refactor or over-engineer
Do NOT commit, push, or merge — leave that for /git-issues-end
Do NOT remove worktrees — /git-issues-end removes them after committing
Agents inside worktrees must leave their changes uncommitted (see the agent prompt in Step 4)

このリポジトリの他の Skills

同じリポジトリ

deploy

ServiceNowDevProgram/ServiceNow-SDK-CC-Starter

Build and deploy the ServiceNow app to an instance. Supports dev/uat/prod environments with a confirmation gate for prod and an annotated git tag for each UAT/prod deploy.

2026-05-304

find-issues

ServiceNowDevProgram/ServiceNow-SDK-CC-Starter

Audit the codebase for bugs, inconsistencies, incomplete work, performance problems, and UI issues using a parallel agent team. Present findings and let the user pick which to file as GitHub issues.

2026-05-304

git-issues-end

ServiceNowDevProgram/ServiceNow-SDK-CC-Starter

Survey changes, create commits referencing their issues, push to remote, comment on each issue, and clean up agent worktrees. Use after the user has reviewed the changes from `/git-issues-start`.

2026-05-304

issue-interview

ServiceNowDevProgram/ServiceNow-SDK-CC-Starter

Conduct a Q&A session on a GitHub issue, write a structured spec into the issue body, and label it `ready`. Use to prepare an issue before implementation. Supports single-issue (default), `auto` (non-interactive batch), and `chain` (interactive batch) modes.

2026-05-304

push

ServiceNowDevProgram/ServiceNow-SDK-CC-Starter

Stage, commit, and push all changes to remote. Use when ready to push to the remote branch.

2026-05-304

teams-issue-summary

ServiceNowDevProgram/ServiceNow-SDK-CC-Starter

Generate a Microsoft Teams markdown table summarizing a range of GitHub issues. Use to produce a status update for stakeholders.

2026-05-304

## Execution Plan ### Batch 1 (parallel) - #3: Fix header alignment → src/client/components/Header.jsx - #7: Add export action → src/client/components/Toolbar.jsx, src/client/services/ExportService.js ### Batch 2 (after Batch 1) - #12: Add new seed fields → src/client/components/DetailPanel.jsx, src/fluent/seed-data.now.ts ⚠️ Sequential — shares seed-data.now.ts with a prior dependency

gh issue comment <number> --body "$(cat <<'EOF' Changes ready for review. **Files modified:** - `path/to/file`: what changed **Approach:** Brief explanation of the fix/implementation. **Testing notes:** What to verify after deploying with `npm run deploy`. EOF )"

name	git-issues-start
description	Fetch `ready`-labeled GitHub issues, analyze complexity, and implement each in a parallel isolated worktree. Use to kick off a batch implementation run.
user-invocable	true

git-issues-start

Step 1: Gather issues

Step 2: Analyze each issue

Step 3: Build execution plan

Step 4: Execute batches

Issue #: <BODY>

Project Conventions (typical ServiceNow SDK starter — override per-project in CLAUDE.md)

Files to Read First

Task

Step 5: Gather changes into main working tree (uncommitted)

Step 6: Present summary

Rules

このリポジトリの他の Skills

このリポジトリの他の Skills

Step 1: Gather issues

Step 2: Analyze each issue

Step 3: Build execution plan

Step 4: Execute batches

Issue #: <BODY>

Project Conventions (typical ServiceNow SDK starter — override per-project in CLAUDE.md)

Files to Read First

Task

Step 5: Gather changes into main working tree (uncommitted)

Step 6: Present summary

Rules