菜单
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 页面并帮你完成安装。
基于 SOC 职业分类
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.
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.
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`.
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.
Stage, commit, and push all changes to remote. Use when ready to push to the remote branch.
Generate a Microsoft Teams markdown table summarizing a range of GitHub issues. Use to produce a status update for stakeholders.
| 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 |
Fetch open GitHub issues labeled ready and work through them using worktree-isolated agents, then merge all changes back into main for immediate deployment.
Arguments: $ARGUMENTS (optional — space- or comma-separated issue numbers to limit scope, e.g. "3 7 12". Explicit numbers bypass the ready label requirement.)
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.
For every issue, determine:
Project area map:
src/client/components/ — React JSX + paired CSS (Name.jsx + Name.css)src/client/services/ — API service modules (plain JS)src/client/ root — top-level page JSX + HTML entry pointssrc/server/script-includes/, src/server/rest-handlers/, src/server/rest-api/ — ServiceNow server-side JSsrc/fluent/ — TypeScript .now.ts files defining tables, seed data, business rules, navigation, form layoutssrc/fluent/script-includes/ — .now.ts wrappers for server script includespackage.json, root config filesGroup issues into batches:
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.
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 likeName.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.tsfiles using@servicenow/sdkFluent API (createTable, createBusinessRule, createScriptInclude, etc.).- Build/config:
package.json, root config files.Files to Read First
Task
- Read and understand the relevant code
- Make the minimal change needed to address this issue
- Do NOT refactor surrounding code or add unrelated improvements
- Run
npm run buildto verify compilation succeeds- 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
)"
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):
git -C <worktree-path> add -A
--binary so binary assets apply cleanly):
git -C <worktree-path> diff --cached --binary > /tmp/issue-<number>.patch
git apply /tmp/issue-<number>.patch
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.
/git-issues-end will commit it.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:
git status, git diff) to validate each change/deploy against dev to smoke-test on an instancegit checkout -- <file>; re-run /git-issues-start <number> for a specific issue if you want to redo it/git-issues-end — it will create issue-referencing commits, push, auto-close issues via Closes #N, and remove the worktreesisolation: "worktree" for each parallel agent to prevent conflicts/git-issues-end/git-issues-end removes them after committing