{"id":"9f652410-a1ef-4ee7-bcc0-57c83ea2aad6","entityType":"agent","slug":"clawhub-athola-nm-sanctum-do-issue","name":"do-issue","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-sanctum-do-issue","canonicalPath":"/agent/clawhub-athola-nm-sanctum-do-issue","generatedAt":"2026-10-10T13:32:41.425Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T10:23:13.920Z","emptyReason":null},"description":"Implements GitHub or GitLab issues via parallel subagents with review gates between task batches Skill: do-issue Owner: athola Summary: Implements GitHub or GitLab issues via parallel subagents with review gates between task batches Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:20:02.434Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:40:08.985Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:57:01.762Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:05:01.720Z | user Release v1.9.14 v1.9.13 | 2026-","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.5K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-sanctum-do-issue","sourceUrl":"https://clawhub.ai/athola/nm-sanctum-do-issue","homepage":"https://clawhub.ai/athola/skills/nm-sanctum-do-issue","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-sanctum-do-issue","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-sanctum-do-issue","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":64,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Implements GitHub or GitLab issues via parallel subagents with review gates between task batches Skill: do-issue Owner: athola Summary: Implements GitHub or Git"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T10:23:13.920Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T10:23:13.920Z","emptyReason":null},"stars":null,"forks":null,"downloads":1498,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.5K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T10:23:13.706Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T10:23:13.920Z","lastCrawledAt":"2026-10-10T10:23:13.706Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T10:23:13.706Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:20:02.434Z","changelog":"Release v1.9.19","fileCount":9,"zipByteSize":15737},{"version":"1.9.17","createdAt":"2026-07-30T05:40:08.985Z","changelog":"Release v1.9.17","fileCount":9,"zipByteSize":15896},{"version":"1.9.16","createdAt":"2026-07-14T19:57:01.762Z","changelog":"Release v1.9.16","fileCount":9,"zipByteSize":15872},{"version":"1.9.14","createdAt":"2026-06-30T18:05:01.720Z","changelog":"Release v1.9.14","fileCount":9,"zipByteSize":15625},{"version":"1.9.13","createdAt":"2026-06-27T16:22:55.143Z","changelog":"Release v1.9.13","fileCount":9,"zipByteSize":15887},{"version":"1.9.12","createdAt":"2026-06-19T03:18:15.926Z","changelog":"Release v1.9.12","fileCount":9,"zipByteSize":15868},{"version":"1.0.3","createdAt":"2026-06-18T15:19:49.116Z","changelog":"Release v1.9.12","fileCount":9,"zipByteSize":15761},{"version":"1.0.2","createdAt":"2026-05-09T02:19:42.757Z","changelog":"Release v1.9.5","fileCount":9,"zipByteSize":15598}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-sanctum-do-issue","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T13:32:41.420Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-do-issue/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T10:23:13.920Z","emptyReason":null},"readme":"Skill: do-issue\n\nOwner: athola\n\nSummary: Implements GitHub or GitLab issues via parallel subagents with review gates between task batches\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:20:02.434Z | user\n\nRelease v1.9.19\n\nv1.9.17 | 2026-07-30T05:40:08.985Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:57:01.762Z | user\n\nRelease v1.9.16\n\nv1.9.14 | 2026-06-30T18:05:01.720Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:22:55.143Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:18:15.926Z | user\n\nRelease v1.9.12\n\nv1.0.3 | 2026-06-18T15:19:49.116Z | user\n\nRelease v1.9.12\n\nv1.0.2 | 2026-05-09T02:19:42.757Z | user\n\nRelease v1.9.5\n\nv1.0.1 | 2026-05-06T14:21:02.695Z | user\n\nRelease v1.9.4\n\nv1.0.0 | 2026-04-15T17:01:47.624Z | auto\n\n- Initial release of the do-issue skill for resolving issues via parallel subagent execution with quality control gates.\n- Supports automatic detection of GitHub, GitLab, or Bitbucket and appropriate CLI commands.\n- Enables parallel task execution with agent teams (defaults to up to 4 concurrent workers), or downgrades as needed.\n- Implements a single consolidated PR for multiple issues, with code review between task batches.\n- Includes fresh context isolation for each subagent, automated task planning, and flexible input handling.\n- Provides configuration examples, CLI usage, and troubleshooting resources.\n\nArchive index:\n\nArchive v1.9.19: 9 files, 15737 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12058b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), skill-card.md (2428b), SKILL.md (5579b), _meta.json (139b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: do-issue\ndescription: |\n Implements GitHub or GitLab issues via parallel subagents with review gates between task batches\nversion: 1.9.8\ntriggers:\n - github\n - gitlab\n - issues\n - subagents\n - parallel\n - automation\n - cross-platform\n - resolving multi-step issues end-to-end\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/sanctum\", \"emoji\": \"\\u2699\\ufe0f\", \"requires\": {\"config\": [\"night-market.leyline:git-platform\", \"night-market.superpowers:subagent-driven-development\", \"night-market.superpowers:writing-plans\", \"night-market.superpowers:test-driven-development\", \"night-market.superpowers:requesting-code-review\", \"night-market.superpowers:finishing-a-development-branch\"]}}}\nsource: claude-night-market\nsource_plugin: sanctum\n---\n\n> **Night Market Skill** — ported from [claude-night-market/sanctum](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Key Features](#key-features)\n- [Workflow Overview](#workflow-overview)\n- [Required TodoWrite Items](#required-todowrite-items)\n- [Configuration](#configuration)\n- [Detailed Resources](#detailed-resources)\n\n\n# Fix Issue(s)\n\nRetrieves issue content from the detected git platform (GitHub, GitLab, or Bitbucket) and uses subagent-driven-development to systematically address requirements, executing tasks in parallel where dependencies allow.\n\n**Platform detection is automatic** via the `leyline:git-platform` SessionStart hook. Check session context for `git_platform:` to determine which CLI to use.\n\n## Key Features\n\n- **Cross-Platform**: Automatically detects GitHub/GitLab/Bitbucket and uses appropriate CLI\n- **Flexible Input**: Single issue number, platform URL, or space-delimited list\n- **Parallel Execution**: Independent tasks run concurrently via subagents\n- **One PR**: All issues produce one consolidated PR (never per-issue PRs)\n- **Quality Gates**: Code review between task groups\n- **Fresh Context**: Each subagent starts with clean context for focused work\n\n## Workflow Overview\n\n| Phase | Description | Module |\n|-------|-------------|--------|\n| 1. Discovery | Parse input, fetch issues, extract requirements | [issue-discovery](modules/issue-discovery.md) |\n| 2. Planning | Analyze dependencies, create task breakdown | [task-planning](modules/task-planning.md) |\n| 3. Execution | Dispatch parallel subagents for independent tasks | [parallel-execution](modules/parallel-execution.md) |\n| 4. Quality | Code review gates between task batches | [quality-gates](modules/quality-gates.md) |\n| 5-6. Completion | Sequential tasks, final review, issue updates | [completion](modules/completion.md) |\n\n## Required TodoWrite Items\n\n1. `do-issue:discovery-complete`\n2. `do-issue:tasks-planned`\n3. `do-issue:parallel-batch-complete`\n4. `do-issue:review-passed`\n5. `do-issue:sequential-complete`\n6. `do-issue:issues-updated`\n\n## Forge CLI Commands\n\nUse the platform detected in session context (`git_platform:`). See `Skill(leyline:git-platform)` for full mapping.\n\n| Operation | GitHub (`gh`) | GitLab (`glab`) |\n|-----------|---------------|-----------------|\n| Fetch issue | `gh issue view --json title,body,labels,comments` | `glab issue view ` |\n| Comment | `gh issue comment --body \"msg\"` | `glab issue note --message \"msg\"` |\n| Close | `gh issue close --comment \"reason\"` | `glab issue close ` |\n| Search | `gh issue list --search \"query\"` | `glab issue list --search \"query\"` |\n\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Agent Teams (Default Execution Mode)\n\nAgent teams is the **default** parallel execution backend for do-issue. Teammates coordinate via filesystem-based messaging, enabling real-time communication when shared files or dependencies are discovered mid-implementation.\n\n**Automatic downgrade**: For single issues with `--scope minor`, agent teams is skipped (Task tool or inline execution is used instead). Use `--no-agent-teams` to force Task tool dispatch for any invocation.\n\n**Requires**: Claude Code 2.1.32+, tmux, `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`. If prerequisites are missing, silently falls back to Task tool dispatch.\n\n```yaml\n# Agent teams configuration\nfix_issue:\n agent_teams:\n enabled: true # on by default; --no-agent-teams to disable\n max_teammates: 4 # limit concurrent workers\n model: sonnet # teammate model (lead uses current model)\n auto_downgrade: true # skip agent teams for --scope minor\n```\n\nSee `modules/parallel-execution.md` for detailed agent teams patterns.\n\n## Configuration\n\n```yaml\nfix_issue:\n parallel_execution: true\n max_parallel_subagents: 3\n review_between_batches: true\n auto_close_issues: false\n commit_per_task: true\n```\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Detailed Resources\n\n- **Phase 1**: See [modules/issue-discovery.md](modules/issue-discovery.md) for input parsing and requirement extraction\n- **Phase 2**: See [modules/task-planning.md](modules/task-planning.md) for dependency analysis\n- **Phase 3**: See [modules/parallel-execution.md](modules/parallel-execution.md) for subagent dispatch\n- **Phase 4**: See [modules/quality-gates.md](modules/quality-gates.md) for review patterns\n- **Phase 5-6**: See [modules/completion.md](modules/completion.md) for finalization\n- **Errors**: See [modules/troubleshooting.md](modules/troubleshooting.md) for common issues\n\nFile v1.9.19:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-sanctum-do-issue\",\n \"version\": \"1.9.19\",\n \"publishedAt\": 1787750402434\n}\n\nFile v1.9.19:modules/completion.md\n\n# Phases 5-6: Completion\n\nExecute sequential tasks and finalize the workflow.\n\n## Phase 5: Sequential Tasks\n\nFor tasks with dependencies, execute sequentially:\n\n```\nTask tool (general-purpose):\n description: \"Issue #42 - Task 2: Add login endpoint\"\n prompt: |\n You are implementing Task 2 from Issue #42.\n\n This task depends on completed Task 1 (auth middleware).\n\n [Task requirements]\n\n Verify Task 1's middleware works before building on it.\n```\n\nReview after each sequential task following the subagent-driven-development pattern.\n\n## Phase 6: Final Review\n\nDispatch detailed review of all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Final review: Issues #42, #43, #44\"\n prompt: |\n Review complete implementation for issues: #42, #43, #44\n\n Verify:\n - All acceptance criteria met\n - Tests detailed and passing\n - No regressions introduced\n - Code quality meets standards\n - Documentation updated if needed\n```\n\n## Update Issue Status\n\nFor each completed issue:\n\n```bash\n# Add completion comment\ngh issue comment 42 --body \"Fixed in commit $(git rev-parse --short HEAD)\n\nChanges:\n- Implemented auth middleware\n- Added login endpoint\n- Added detailed tests\n\nReady for review.\"\n\n# Optionally close issue\ngh issue close 42 --comment \"Completed via automated fix workflow\"\n```\n\n## Pre-PR Consolidation Check\n\nBefore creating the PR, verify all work is on ONE branch:\n\n```bash\n# Confirm current branch contains all issue commits\ngit log --oneline --grep=\"Fixes #42\" --grep=\"Fixes #43\" \\\n --all-match HEAD\n# If commits are on separate branches, cherry-pick or\n# rebase them onto the shared branch first.\n```\n\n## Finish Development\n\nUse `superpowers:finishing-a-development-branch` to:\n\n- Verify all tests pass\n- Present merge options\n- Execute chosen completion path\n\n**One PR rule**: Always create exactly ONE pull request\nthat references all issues via `Fixes #N` lines in\nthe body. See Step 6.2 in the do-issue command for\nthe template. Never create separate PRs per issue.\n\n## Tooling Reflection (Night-Market Feedback Loop)\n\nAfter completing the workflow, reflect on the *tooling itself*\n(skills, agents, commands, hooks) rather than the repo code:\n\n- Did any skill behave unexpectedly or have unclear guidance?\n- Was a subagent slow, redundant, or missing context?\n- Did the do-issue command skip steps or require unnecessary\n manual intervention?\n- Did a hook fire incorrectly or miss a case?\n\n**If yes**, post to https://github.com/athola/claude-night-market/discussions\n(Learnings category) using the pattern from `fix-pr`\nStep 6.7. Always target the night-market repo, not the\ncurrent working repo.\n\n**If no observations**, skip this step silently.\n\n> Repo-specific learnings stay in the current repo. Tooling\n> learnings always go to\n> https://github.com/athola/claude-night-market/discussions\n> so the framework can improve.\n\n## Example Final Output\n\n```\nFinal Review: All requirements met\n\nIssues Summary:\n #42: 3 tasks completed, all tests passing\n #43: 2 tasks completed, all tests passing\n #44: 1 task completed, all tests passing\n\nPR: fix(auth): add middleware and login endpoint (#42, #43, #44)\n - Fixes #42, Fixes #43, Fixes #44\n - All issues consolidated in single PR\n```\n\nFile v1.9.19:modules/issue-discovery.md\n\n# Phase 1: Issue Discovery\n\nParse input arguments and retrieve issue content from the detected git platform. Check session context for `git_platform:` to determine which CLI to use.\n\n## Input Formats\n\nThe command accepts flexible input:\n\n```bash\n# Single issue number\n/do-issue 42\n\n# Platform URL (GitHub or GitLab)\n/do-issue https://github.com/owner/repo/issues/42\n/do-issue https://gitlab.com/owner/repo/-/issues/42\n\n# Multiple issues (space-delimited)\n/do-issue 42 43 44\n\n# Mixed formats\n/do-issue 42 https://github.com/owner/repo/issues/43\n```\n\n## Retrieve Issue Content\n\nFor each issue, fetch the full content using the platform-appropriate CLI:\n\n```bash\n# GitHub\ngh issue view 42 --json title,body,labels,assignees,comments\ngh issue view https://github.com/owner/repo/issues/42 --json title,body,labels,assignees,comments\n\n# GitLab\nglab issue view 42\n```\n\n## Extract Requirements\n\nFrom each issue body, identify:\n\n| Category | Look For |\n|----------|----------|\n| **Acceptance Criteria** | Checkboxes, \"should\", \"must\" statements |\n| **Technical Requirements** | Code references, API specs, constraints |\n| **Test Expectations** | Expected behavior, edge cases |\n| **Dependencies** | Related issues, blocking items |\n\n## Example Output\n\n```\nFetching issue #42...\nTitle: Add user authentication\nRequirements identified: 4\n - Acceptance Criteria: 2\n - Technical Requirements: 1\n - Test Expectations: 1\nTasks will be generated: 3\n```\n\n## Next Phase\n\nAfter discovery, proceed to [task-planning.md](task-planning.md) for dependency analysis and task breakdown.\n\nFile v1.9.19:modules/parallel-execution.md\n\n# Phase 3: Parallel Execution\n\nDispatch subagents for independent tasks concurrently.\n\n## Important: Plan Before Large Dispatch\n\n**When dispatching 4+ agents**, enter plan mode first:\n\n| Agent Count | Requirement |\n|-------------|-------------|\n| 1-3 agents | Dispatch directly (standard parallel) |\n| 4+ agents | **Enter plan mode, write strategy, get user approval, execute** |\n\n### Why This Threshold Exists\n\nLarge agent dispatches (4+ agents) create:\n- **Observability loss**: Too many concurrent outputs to track\n- **Context overflow**: Research agents produce large results, triggering continuation agents that lose state\n- **Recovery difficulty**: If 2 of 7 agents fail, there's no plan to resume from\n- **Wasted compute**: Without user alignment, agents may research the wrong things\n\n### Plan-Before-Dispatch Checklist\n\nBefore launching 4+ agents, your plan should specify:\n\n1. **Agent roster**: Name, type (`general-purpose`/`Explore`/specialized), and model (`sonnet`/`haiku`/`opus`) for each\n2. **Scope per agent**: Exactly what each agent investigates (files, topics, questions)\n3. **Output contract**: What each agent should return (format, length, key questions to answer)\n4. **Result integration**: How you'll combine agent outputs into a coherent response\n5. **Failure strategy**: What happens if an agent hits context limits or returns incomplete results\n\n### Example Plan Structure\n\n```markdown\n## Agent Dispatch Plan: [Goal]\n\n### Agents (N total)\n\n| # | Agent Type | Model | Scope | Output Contract |\n|---|-----------|-------|-------|-----------------|\n| 1 | Explore | haiku | Search plugins/ for X | File paths + summaries |\n| 2 | general-purpose | sonnet | Research Y via web | Key findings, 500 words max |\n| 3 | general-purpose | sonnet | Analyze Z files | Structured assessment |\n\n### Integration Strategy\n[How results combine into final answer]\n\n### Failure Handling\n- Agent timeout/overflow: [strategy]\n- Incomplete results: [strategy]\n```\n\n### Enforcement\n\nThis rule applies to ALL multi-agent dispatches, including:\n- Research/audit missions (web + codebase analysis)\n- Large refactoring across many files\n- Comprehensive review tasks\n- Any task requiring continuation agents\n\n## WARNING: Remote Control / Headless Limitations\n\n**Avoid running parallel subagent dispatches via\n`/remote-control` or headless SDK sessions.**\n\nThe Task tool blocks the main thread while awaiting\nsubagent completion. If any subagent hangs (a known\nupstream bug), the parent session becomes unrecoverable\nbecause remote-control has no programmatic equivalent\nof the `Esc` interrupt.\n\n**Safe alternatives for remote-control use:**\n- Use `run_in_background: true` on Agent calls\n- Run with `--scope minor` (inline execution, no\n subagent dispatch)\n- Use a local terminal with remote-control as a\n monitoring-only window\n\nSee [troubleshooting.md](troubleshooting.md) for recovery\nsteps if a subagent hangs.\n\n## Execute Nonconflicting Tasks in Parallel\n\n**When you have multiple nonconflicting tasks, invoke all Task tools in a single response.**\n\nParallel execution is the default for nonconflicting tasks.\n\n## Identify Nonconflicting Tasks\n\nTasks can run in parallel only when all conditions are met:\n\n✅ **Safe for parallel execution:**\n- Tasks modify **different files** (no overlap)\n- Tasks have **no shared state** (independent data)\n- Tasks don't modify **same code paths** (no merge conflicts)\n- Tasks have **satisfied dependencies** (no blocking)\n- Tasks don't depend on **each other's outputs**\n\n❌ **Not safe for parallel execution:**\n- Tasks modify the **same file** or related files\n- Tasks share **configuration** or **global state**\n- Tasks have **sequential dependencies**\n- Tasks touch **overlapping code paths** that could conflict\n- Tasks need results from **each other**\n- Both tasks are `[R:RED]` (compounding risk prohibited)\n- Either task is `[R:CRITICAL]` (always executes solo)\n\n## Analyze Task Conflicts BEFORE Dispatching\n\n**Required**: Perform conflict analysis before parallel execution:\n\n```markdown\nAnalyzing tasks for parallel execution:\n\nTask 1 (Issue #42): Create auth middleware in src/auth/middleware.py\nTask 2 (Issue #43): Fix validation bug in src/validators/schema.py\nTask 3 (Issue #44): Add logging to src/utils/logger.py\n\nConflict Check:\n- Files: ✅ No overlap (middleware.py, schema.py, logger.py are different)\n- Dependencies: ✅ No sequential dependencies between tasks\n- State: ✅ No shared configuration or database schema\n- Code paths: ✅ Independent modules, no import conflicts\n\nDecision: Execute Tasks 1, 2, 3 in PARALLEL (3 Task tool invocations in single response)\n```\n\n**COUNTER-EXAMPLE** - Sequential execution required:\n\n```markdown\nTask A (Issue #50): Refactor User model in models/user.py\nTask B (Issue #51): Add authentication using User model\n\nConflict Check:\n- Files: ❌ Task B depends on Task A's User model changes\n- Dependencies: ❌ Task B needs Task A's output\n- Code paths: ❌ Both touch authentication flow\n\nDecision: Execute SEQUENTIALLY (Task A first, then Task B)\n```\n\n## Risk-Tier Parallel Safety\n\nWhen tasks have `[R:TIER]` markers (from `leyline:risk-classification`), apply these additional constraints:\n\n| Task A Tier | Task B Tier | Parallel? | Reason |\n|-------------|-------------|-----------|--------|\n| GREEN | Any | Yes | Low risk, independent |\n| YELLOW | YELLOW | Yes | Standard caution |\n| YELLOW | RED | Yes | With conflict monitoring |\n| RED | RED | **No** | Compounding risk too high |\n| Any | CRITICAL | **No** | CRITICAL always solo |\n\nTasks without `[R:TIER]` markers are treated as GREEN (backward compatible).\n\n## Dispatch Parallel Subagents\n\n**All subagents commit to the SAME branch.** The parent\ncreates one shared branch before dispatch (Step 4.1) and\nall work lands there. Do not create per-issue branches.\nThis produces one PR at completion.\n\n**CORRECT PATTERN** - Multiple Task tool invocations in ONE response:\n\n```text\nI'll execute these 3 nonconflicting tasks in parallel:\n\nTask(description: \"Issue #42 - Create auth middleware\")\nTask(description: \"Issue #43 - Fix validation bug\")\nTask(description: \"Issue #44 - Add logging feature\")\n\nEach task will:\n1. Work on the current branch (fix/issues-42-43-44)\n2. Implement in its designated file (no conflicts)\n3. Follow TDD - write failing test first\n4. Verify no regressions\n5. Commit with conventional format\n```\n\n**WRONG PATTERN** - Sequential invocations:\n\n```text\n❌ Task(description: \"Issue #42\")\n [wait for result]\n Task(description: \"Issue #43\")\n [wait for result]\n\nThis wastes time when tasks are nonconflicting!\n```\n\n## Await Parallel Results\n\nCollect results from all parallel subagents before proceeding:\n\n```\nParallel Batch 1: Issues #42, #43, #44 (3 tasks)\n [3 subagents running in parallel...]\n\n ✅ #42: Complete (auth middleware in src/auth/middleware.py)\n ✅ #43: Complete (validation fix in src/validators/schema.py)\n ✅ #44: Complete (logging in src/utils/logger.py)\n\nAll tasks completed without conflicts.\n```\n\n## Key Principles\n\n| Principle | Description |\n|-----------|-------------|\n| **One Branch** | All subagents commit to the shared branch (one PR at the end) |\n| **Fresh Context** | Each subagent starts clean, avoiding context pollution |\n| **TDD by Default** | Subagents write failing tests first |\n| **Conventional Commits** | Each task commits with proper format |\n| **Isolation** | Tasks don't share state between subagents |\n\n## Agent Teams (Default Execution Backend)\n\nAgent teams is the **default** for parallel execution in do-issue. Teammates coordinate via filesystem-based messaging, which prevents merge conflicts and duplicate work that Task tool batches would only catch at the review gate.\n\nUse `--no-agent-teams` to fall back to Task tool dispatch when coordination overhead isn't justified.\n\n### Automatic Downgrade\n\nAgent teams is skipped (Task tool or inline used instead) when:\n- Single issue with `--scope minor` (no parallelism needed)\n- tmux is not installed or `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is unset\n- `--no-agent-teams` flag is explicitly passed\n\n### When Task Tool Is Better\n\n| Scenario | Recommendation |\n|----------|---------------|\n| Single issue, minor scope | Inline execution (no dispatch at all) |\n| 2-3 fully independent issues, no shared files | Task tool is simpler, `--no-agent-teams` |\n| 3+ issues with shared files or dependencies | Agent teams (default) |\n| 5+ issues, complex dependency graph | Agent teams (default) |\n\n### Agent Teams Execution Pattern\n\n```text\nLead agent creates team: do-issue-{timestamp}\n Spawns: worker-1 (Sonnet), worker-2 (Sonnet), worker-3 (Sonnet)\n\nLead assigns tasks via inbox:\n worker-1: \"Implement #42 (auth middleware) in src/auth/\"\n worker-2: \"Fix #43 (validation bug) in src/validators/\"\n worker-3: \"Add #44 (logging) in src/utils/\"\n\nMid-execution coordination:\n worker-1 → worker-3: \"I added auth logging to src/auth/log.py —\n don't duplicate in your logging task\"\n worker-3 → worker-1: \"Acknowledged, will import from your module\"\n\nLead collects completion messages, runs quality gates, shuts down team.\n```\n\n### Key Difference from Task Tool\n\nTask tool subagents are **fire-and-forget** — they can't communicate mid-execution. Agent teams teammates can **send messages to each other** when they discover shared concerns. This prevents merge conflicts and duplicate work that Task tool batches would catch only at the review gate.\n\n### Fallback\n\nIf tmux is unavailable or `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is not set, `--agent-teams` silently falls back to standard Task tool dispatch.\n\n## Worktree Isolation for Parallel Safety (Claude Code 2.1.49+)\n\nSubagents with `isolation: \"worktree\"` run in a temporary\ngit worktree, providing filesystem-level isolation.\n\n### When to Use Worktree Isolation\n\n| Scenario | Use Worktree? | Reason |\n|----------|--------------|--------|\n| Agents touch different files | No | No conflict possible |\n| Agents touch overlapping files | **Yes** | Prevents race conditions |\n| Agent does destructive ops (delete and recreate) | **Yes** | Failed agent won't corrupt main |\n| Research/read-only agents | No | No writes to conflict |\n\n### Worktree Behavior\n\n- Agents with worktree isolation get a separate checkout\n- Empty worktrees are auto-cleaned; worktrees with\n changes return `worktreePath` and `worktreeBranch`\n- If `worktreePath` is NOT in the agent result, changes\n either landed in the main workdir or were lost\n\n### Post-Dispatch Verification (MANDATORY)\n\nAfter ALL parallel agents complete, verify before\nproceeding:\n\n```markdown\n## Post-Dispatch Checklist\n\n1. [ ] Check `git worktree list` for remaining worktrees\n2. [ ] Check `git diff --stat` in main workdir for changes\n3. [ ] For each agent with worktree output:\n - Verify worktree changes via `git diff` in worktree\n - Merge or cherry-pick into main branch\n - Remove worktree: `git worktree remove `\n4. [ ] For agents that deleted + recreated files:\n - Verify new files exist: `ls `\n - Verify imports work: `python -c \"from X import Y\"`\n - If directory exists but is empty, restore original:\n `git checkout HEAD -- `\n5. [ ] Run affected tests before committing\n```\n\n### Never Mix Worktree and Direct Agents on Same Files\n\nWhen agents A (worktree) and B (direct) both modify\n`foo.py`, only one set of changes survives. Either:\n\n- Use worktree isolation for ALL agents in the batch, or\n- Use direct (no isolation) for ALL agents in the batch\n\nMixing isolation modes on overlapping files causes\nsilent data loss.\n\n### Agent Path Confusion\n\nAgents in worktrees or with `cd` in their prompts can\nwrite files to wrong paths. Common failure modes:\n\n- Creates `./foo/` instead of `./plugins/bar/foo/`\n- Deletes original but new directory is empty (agent\n hit context limit mid-operation)\n\nMitigation: include absolute paths in agent prompts\nand verify file existence after completion.\n\n## Next Phase\n\nAfter parallel execution completes, proceed to [quality-gates.md](quality-gates.md) for batch review.\n\nFile v1.9.19:modules/quality-gates.md\n\n# Phase 4: Quality Gates\n\nCode review between task batches to catch issues early.\n\n## Batch Code Review\n\nAfter parallel batch completes, review all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Review parallel batch: Issues #42, #43\"\n prompt: |\n Review changes from parallel implementation batch.\n\n Issues addressed:\n - #42 Task 1: Auth middleware\n - #43 Task 1: Validation fix\n\n BASE_SHA: [sha before batch]\n HEAD_SHA: [current sha]\n\n Focus on:\n - Correct implementation per issue requirements\n - No conflicts between parallel changes\n - Test coverage adequate\n - No security vulnerabilities introduced\n```\n\n## Review Feedback Categories\n\n| Category | Action |\n|----------|--------|\n| **Critical Issues** | Fix immediately via follow-up subagent |\n| **Important Issues** | Fix before next batch |\n| **Minor Issues** | Note for later |\n\n## Example Review Output\n\n```\nBatch Review...\n All changes valid, no conflicts\n\nStrengths:\n - Good test coverage\n - Follows existing patterns\n\nIssues: None\n\nProceeding to sequential phase...\n```\n\n## Handling Critical Feedback\n\nWhen critical issues are found:\n\n```\nTask tool (general-purpose):\n description: \"Fix critical issue in auth middleware\"\n prompt: |\n The code review found a critical issue:\n [Issue description]\n\n Fix this before proceeding.\n```\n\n## Next Phase\n\nAfter review passes, proceed to [completion.md](completion.md) for sequential tasks and finalization.\n\nFile v1.9.19:modules/task-planning.md\n\n# Phase 2: Task Planning\n\nAnalyze issue dependencies and create structured task breakdown.\n\n## Dependency Analysis\n\nIdentify which issues can be worked in parallel:\n\n```python\ndef analyze_dependencies(issues):\n \"\"\"\n Identify which issues can be worked in parallel.\n \"\"\"\n independent = []\n dependent = []\n\n for issue in issues:\n if issue.has_no_blockers(issues):\n independent.append(issue)\n else:\n dependent.append({\n 'issue': issue,\n 'blocked_by': issue.get_blockers(issues)\n })\n\n return independent, dependent\n```\n\n## Task Breakdown\n\nFor each issue, generate tasks following `superpowers:writing-plans` structure:\n\n```markdown\n## Issue #42: Add user authentication\n\n### Task 1: Create auth middleware\n- [ ] Implement JWT validation\n- [ ] Add route protection decorator\n- [ ] Write unit tests\n\n### Task 2: Add login endpoint\n- [ ] Create POST /auth/login\n- [ ] Implement password verification\n- [ ] Return JWT on success\n- [ ] Write integration tests\n```\n\n## Initialize TodoWrite\n\nCreate todos for all tasks across all issues:\n\n```\n- [ ] Issue #42 - Task 1: Create auth middleware\n- [ ] Issue #42 - Task 2: Add login endpoint\n- [ ] Issue #43 - Task 1: Fix validation bug\n```\n\n## Dependency Graph Example\n\n```\nDependency Graph:\n #42: Independent\n #43: Independent\n #44: Depends on #42\n\nParallel Batch 1: Issues #42, #43\nSequential Phase: Issue #44\n```\n\n## Risk Classification\n\nAfter task breakdown, classify each task's risk tier using `leyline:risk-classification` heuristics. Run the heuristic classifier against each task's affected files and append a `[R:TIER]` marker.\n\n### Classification Process\n\n1. For each task, identify the files it will modify\n2. Apply `leyline:risk-classification/modules/heuristic-classifier.md` pattern matching\n3. Append `[R:TIER]` marker to the task line\n\n### Task Format with Risk Markers\n\n```markdown\n- [ ] T001 Create project structure per implementation plan\n- [ ] T005 [P] [R:YELLOW] Implement authentication middleware in src/middleware/auth.py\n- [ ] T012 [P] [US1] [R:YELLOW] Create LoginForm component in src/components/LoginForm.tsx\n- [ ] T015 [US2] [R:RED] Add user migration in migrations/002_add_users.py\n```\n\nTasks without `[R:TIER]` markers default to GREEN. Markers are additive — existing task formats remain valid without them.\n\n## Next Phase\n\nAfter planning, proceed to [parallel-execution.md](parallel-execution.md) to dispatch subagents.\n\nFile v1.9.19:modules/troubleshooting.md\n\n# Troubleshooting\n\nCommon issues and solutions when using do-issue.\n\n## Error: Issue Not Found\n\n```bash\nError: Issue #42 not found\nVerify:\n - Issue exists in current repository\n - You have access to the repository\n - Issue number is correct\n```\n\n## Error: Subagent Failure\n\n```bash\nError: Subagent failed on Issue #42 Task 2\nCause: Test failures after implementation\n\nOptions:\n 1. Dispatch fix subagent (recommended)\n 2. Skip task and continue\n 3. Abort workflow\n\n[Selecting option 1...]\nDispatching fix subagent...\n```\n\n## Warning: Merge Conflicts\n\n```bash\nWarning: Parallel changes created conflicts\nFiles: src/auth/middleware.ts\n\nResolution:\n 1. Pausing parallel execution\n 2. Resolving conflicts via dedicated subagent\n 3. Resuming after resolution\n```\n\n## Subagent Not Following Requirements\n\n```bash\nProblem: Subagent implemented feature differently than specified\nSolution: Re-dispatch with more explicit prompt including:\n - Exact acceptance criteria from issue\n - Code examples if provided\n - Links to related files\n```\n\n## Too Many Parallel Conflicts\n\n```bash\nProblem: Multiple subagents modifying same files\nSolution: Use --no-parallel or manually group tasks to avoid overlap\n```\n\n## Review Taking Too Long\n\n```bash\nProblem: Code review subagent taking excessive time\nSolution: Split large batches into smaller groups\n```\n\n## Subagent Hangs (Remote Control / Headless)\n\nWhen running do-issue through `/remote-control` or headless\nSDK sessions, subagents can hang indefinitely with no\nrecovery path. This is a known upstream bug\n([#28482](https://github.com/anthropics/claude-code/issues/28482)).\n\n**Symptoms:**\n- Task status shows \"In progress\" forever\n- No output, no tool calls, no error from the subagent\n- Remote control web UI shows \"philosophizing/tinkering\"\n indefinitely\n- New prompts are queued but never processed\n\n**Recovery:**\n1. If you have local terminal access, press `Esc` to\n interrupt the hung subagent\n2. If headless: `kill -SIGINT ` to interrupt\n3. Start a fresh session rather than trying to resume\n\n**Prevention:**\n- Run subagent-heavy workflows **locally**, not via\n remote-control (Esc is the only recovery mechanism)\n- Use `run_in_background: true` on Agent calls so the\n parent can continue processing if a subagent stalls\n- Limit concurrent subagents to reduce hang probability\n- Monitor from a local terminal even when using remote\n control\n\n**Related issues:**\n- [#28482](https://github.com/anthropics/claude-code/issues/28482) - Agent hang, no headless recovery\n- [#33232](https://github.com/anthropics/claude-code/issues/33232) - Remote-control WebSocket instability\n- [#13240](https://github.com/anthropics/claude-code/issues/13240) - Master freeze/hang bug\n\n## Best Practices\n\n### Before Running\n\n1. validate clean working directory (`git status` shows no changes)\n2. Pull latest from remote\n3. Verify GitHub CLI is authenticated (`gh auth status`)\n4. Review issues briefly to confirm they're ready for implementation\n\n### During Execution\n\n1. Monitor subagent progress via TodoWrite\n2. Don't manually edit files while subagents are working\n3. Let code reviews complete before proceeding\n4. Address Critical issues immediately\n\n### After Completion\n\n1. Review final changes before merging\n2. Verify all tests pass\n3. Update issue comments with implementation notes\n4. Create PR if working on branch\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nImplements GitHub or GitLab issues via parallel subagents with review gates between task batches.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineering teams use this skill to turn GitHub or GitLab issues into planned implementation tasks, coordinate parallel or sequential agent work, run review gates, and prepare a single consolidated pull request.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can comment on issues, close issues, create pull requests, and post external feedback.\n\nMitigation: Require explicit user confirmation before issue comments, issue closure, pull request creation, or GitHub Discussions posts.\n\nRisk: Issue bodies and comments may contain untrusted instructions that could influence agent behavior.\n\nMitigation: Summarize and sanitize issue content before forwarding requirements to subagents, and keep repository instructions separate from issue text.\n\nRisk: Parallel subagent work can create merge conflicts, duplicate changes, or hard-to-monitor execution.\n\nMitigation: Use dependency and file-conflict analysis before dispatch, limit high-risk parallel batches, run review gates between batches, and fall back to sequential execution when needed.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-sanctum-do-issue)\n- [Publisher profile](https://clawhub.ai/user/athola)\n- [Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown with inline shell commands, task plans, review prompts, issue comments, and configuration snippets.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May coordinate issue updates, issue closure, pull request preparation, and external feedback posting when the user authorizes those actions.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release evidence; artifact frontmatter says 1.9.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 9 files, 15896 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12058b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), skill-card.md (2945b), SKILL.md (5579b), _meta.json (139b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: do-issue\ndescription: |\n Implements GitHub or GitLab issues via parallel subagents with review gates between task batches\nversion: 1.9.8\ntriggers:\n - github\n - gitlab\n - issues\n - subagents\n - parallel\n - automation\n - cross-platform\n - resolving multi-step issues end-to-end\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/sanctum\", \"emoji\": \"\\u2699\\ufe0f\", \"requires\": {\"config\": [\"night-market.leyline:git-platform\", \"night-market.superpowers:subagent-driven-development\", \"night-market.superpowers:writing-plans\", \"night-market.superpowers:test-driven-development\", \"night-market.superpowers:requesting-code-review\", \"night-market.superpowers:finishing-a-development-branch\"]}}}\nsource: claude-night-market\nsource_plugin: sanctum\n---\n\n> **Night Market Skill** — ported from [claude-night-market/sanctum](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Key Features](#key-features)\n- [Workflow Overview](#workflow-overview)\n- [Required TodoWrite Items](#required-todowrite-items)\n- [Configuration](#configuration)\n- [Detailed Resources](#detailed-resources)\n\n\n# Fix Issue(s)\n\nRetrieves issue content from the detected git platform (GitHub, GitLab, or Bitbucket) and uses subagent-driven-development to systematically address requirements, executing tasks in parallel where dependencies allow.\n\n**Platform detection is automatic** via the `leyline:git-platform` SessionStart hook. Check session context for `git_platform:` to determine which CLI to use.\n\n## Key Features\n\n- **Cross-Platform**: Automatically detects GitHub/GitLab/Bitbucket and uses appropriate CLI\n- **Flexible Input**: Single issue number, platform URL, or space-delimited list\n- **Parallel Execution**: Independent tasks run concurrently via subagents\n- **One PR**: All issues produce one consolidated PR (never per-issue PRs)\n- **Quality Gates**: Code review between task groups\n- **Fresh Context**: Each subagent starts with clean context for focused work\n\n## Workflow Overview\n\n| Phase | Description | Module |\n|-------|-------------|--------|\n| 1. Discovery | Parse input, fetch issues, extract requirements | [issue-discovery](modules/issue-discovery.md) |\n| 2. Planning | Analyze dependencies, create task breakdown | [task-planning](modules/task-planning.md) |\n| 3. Execution | Dispatch parallel subagents for independent tasks | [parallel-execution](modules/parallel-execution.md) |\n| 4. Quality | Code review gates between task batches | [quality-gates](modules/quality-gates.md) |\n| 5-6. Completion | Sequential tasks, final review, issue updates | [completion](modules/completion.md) |\n\n## Required TodoWrite Items\n\n1. `do-issue:discovery-complete`\n2. `do-issue:tasks-planned`\n3. `do-issue:parallel-batch-complete`\n4. `do-issue:review-passed`\n5. `do-issue:sequential-complete`\n6. `do-issue:issues-updated`\n\n## Forge CLI Commands\n\nUse the platform detected in session context (`git_platform:`). See `Skill(leyline:git-platform)` for full mapping.\n\n| Operation | GitHub (`gh`) | GitLab (`glab`) |\n|-----------|---------------|-----------------|\n| Fetch issue | `gh issue view --json title,body,labels,comments` | `glab issue view ` |\n| Comment | `gh issue comment --body \"msg\"` | `glab issue note --message \"msg\"` |\n| Close | `gh issue close --comment \"reason\"` | `glab issue close ` |\n| Search | `gh issue list --search \"query\"` | `glab issue list --search \"query\"` |\n\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Agent Teams (Default Execution Mode)\n\nAgent teams is the **default** parallel execution backend for do-issue. Teammates coordinate via filesystem-based messaging, enabling real-time communication when shared files or dependencies are discovered mid-implementation.\n\n**Automatic downgrade**: For single issues with `--scope minor`, agent teams is skipped (Task tool or inline execution is used instead). Use `--no-agent-teams` to force Task tool dispatch for any invocation.\n\n**Requires**: Claude Code 2.1.32+, tmux, `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`. If prerequisites are missing, silently falls back to Task tool dispatch.\n\n```yaml\n# Agent teams configuration\nfix_issue:\n agent_teams:\n enabled: true # on by default; --no-agent-teams to disable\n max_teammates: 4 # limit concurrent workers\n model: sonnet # teammate model (lead uses current model)\n auto_downgrade: true # skip agent teams for --scope minor\n```\n\nSee `modules/parallel-execution.md` for detailed agent teams patterns.\n\n## Configuration\n\n```yaml\nfix_issue:\n parallel_execution: true\n max_parallel_subagents: 3\n review_between_batches: true\n auto_close_issues: false\n commit_per_task: true\n```\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Detailed Resources\n\n- **Phase 1**: See [modules/issue-discovery.md](modules/issue-discovery.md) for input parsing and requirement extraction\n- **Phase 2**: See [modules/task-planning.md](modules/task-planning.md) for dependency analysis\n- **Phase 3**: See [modules/parallel-execution.md](modules/parallel-execution.md) for subagent dispatch\n- **Phase 4**: See [modules/quality-gates.md](modules/quality-gates.md) for review patterns\n- **Phase 5-6**: See [modules/completion.md](modules/completion.md) for finalization\n- **Errors**: See [modules/troubleshooting.md](modules/troubleshooting.md) for common issues\n\nFile v1.9.17:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-sanctum-do-issue\",\n \"version\": \"1.9.17\",\n \"publishedAt\": 1785390008985\n}\n\nFile v1.9.17:modules/completion.md\n\n# Phases 5-6: Completion\n\nExecute sequential tasks and finalize the workflow.\n\n## Phase 5: Sequential Tasks\n\nFor tasks with dependencies, execute sequentially:\n\n```\nTask tool (general-purpose):\n description: \"Issue #42 - Task 2: Add login endpoint\"\n prompt: |\n You are implementing Task 2 from Issue #42.\n\n This task depends on completed Task 1 (auth middleware).\n\n [Task requirements]\n\n Verify Task 1's middleware works before building on it.\n```\n\nReview after each sequential task following the subagent-driven-development pattern.\n\n## Phase 6: Final Review\n\nDispatch detailed review of all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Final review: Issues #42, #43, #44\"\n prompt: |\n Review complete implementation for issues: #42, #43, #44\n\n Verify:\n - All acceptance criteria met\n - Tests detailed and passing\n - No regressions introduced\n - Code quality meets standards\n - Documentation updated if needed\n```\n\n## Update Issue Status\n\nFor each completed issue:\n\n```bash\n# Add completion comment\ngh issue comment 42 --body \"Fixed in commit $(git rev-parse --short HEAD)\n\nChanges:\n- Implemented auth middleware\n- Added login endpoint\n- Added detailed tests\n\nReady for review.\"\n\n# Optionally close issue\ngh issue close 42 --comment \"Completed via automated fix workflow\"\n```\n\n## Pre-PR Consolidation Check\n\nBefore creating the PR, verify all work is on ONE branch:\n\n```bash\n# Confirm current branch contains all issue commits\ngit log --oneline --grep=\"Fixes #42\" --grep=\"Fixes #43\" \\\n --all-match HEAD\n# If commits are on separate branches, cherry-pick or\n# rebase them onto the shared branch first.\n```\n\n## Finish Development\n\nUse `superpowers:finishing-a-development-branch` to:\n\n- Verify all tests pass\n- Present merge options\n- Execute chosen completion path\n\n**One PR rule**: Always create exactly ONE pull request\nthat references all issues via `Fixes #N` lines in\nthe body. See Step 6.2 in the do-issue command for\nthe template. Never create separate PRs per issue.\n\n## Tooling Reflection (Night-Market Feedback Loop)\n\nAfter completing the workflow, reflect on the *tooling itself*\n(skills, agents, commands, hooks) rather than the repo code:\n\n- Did any skill behave unexpectedly or have unclear guidance?\n- Was a subagent slow, redundant, or missing context?\n- Did the do-issue command skip steps or require unnecessary\n manual intervention?\n- Did a hook fire incorrectly or miss a case?\n\n**If yes**, post to https://github.com/athola/claude-night-market/discussions\n(Learnings category) using the pattern from `fix-pr`\nStep 6.7. Always target the night-market repo, not the\ncurrent working repo.\n\n**If no observations**, skip this step silently.\n\n> Repo-specific learnings stay in the current repo. Tooling\n> learnings always go to\n> https://github.com/athola/claude-night-market/discussions\n> so the framework can improve.\n\n## Example Final Output\n\n```\nFinal Review: All requirements met\n\nIssues Summary:\n #42: 3 tasks completed, all tests passing\n #43: 2 tasks completed, all tests passing\n #44: 1 task completed, all tests passing\n\nPR: fix(auth): add middleware and login endpoint (#42, #43, #44)\n - Fixes #42, Fixes #43, Fixes #44\n - All issues consolidated in single PR\n```\n\nFile v1.9.17:modules/issue-discovery.md\n\n# Phase 1: Issue Discovery\n\nParse input arguments and retrieve issue content from the detected git platform. Check session context for `git_platform:` to determine which CLI to use.\n\n## Input Formats\n\nThe command accepts flexible input:\n\n```bash\n# Single issue number\n/do-issue 42\n\n# Platform URL (GitHub or GitLab)\n/do-issue https://github.com/owner/repo/issues/42\n/do-issue https://gitlab.com/owner/repo/-/issues/42\n\n# Multiple issues (space-delimited)\n/do-issue 42 43 44\n\n# Mixed formats\n/do-issue 42 https://github.com/owner/repo/issues/43\n```\n\n## Retrieve Issue Content\n\nFor each issue, fetch the full content using the platform-appropriate CLI:\n\n```bash\n# GitHub\ngh issue view 42 --json title,body,labels,assignees,comments\ngh issue view https://github.com/owner/repo/issues/42 --json title,body,labels,assignees,comments\n\n# GitLab\nglab issue view 42\n```\n\n## Extract Requirements\n\nFrom each issue body, identify:\n\n| Category | Look For |\n|----------|----------|\n| **Acceptance Criteria** | Checkboxes, \"should\", \"must\" statements |\n| **Technical Requirements** | Code references, API specs, constraints |\n| **Test Expectations** | Expected behavior, edge cases |\n| **Dependencies** | Related issues, blocking items |\n\n## Example Output\n\n```\nFetching issue #42...\nTitle: Add user authentication\nRequirements identified: 4\n - Acceptance Criteria: 2\n - Technical Requirements: 1\n - Test Expectations: 1\nTasks will be generated: 3\n```\n\n## Next Phase\n\nAfter discovery, proceed to [task-planning.md](task-planning.md) for dependency analysis and task breakdown.\n\nFile v1.9.17:modules/parallel-execution.md\n\n# Phase 3: Parallel Execution\n\nDispatch subagents for independent tasks concurrently.\n\n## Important: Plan Before Large Dispatch\n\n**When dispatching 4+ agents**, enter plan mode first:\n\n| Agent Count | Requirement |\n|-------------|-------------|\n| 1-3 agents | Dispatch directly (standard parallel) |\n| 4+ agents | **Enter plan mode, write strategy, get user approval, execute** |\n\n### Why This Threshold Exists\n\nLarge agent dispatches (4+ agents) create:\n- **Observability loss**: Too many concurrent outputs to track\n- **Context overflow**: Research agents produce large results, triggering continuation agents that lose state\n- **Recovery difficulty**: If 2 of 7 agents fail, there's no plan to resume from\n- **Wasted compute**: Without user alignment, agents may research the wrong things\n\n### Plan-Before-Dispatch Checklist\n\nBefore launching 4+ agents, your plan should specify:\n\n1. **Agent roster**: Name, type (`general-purpose`/`Explore`/specialized), and model (`sonnet`/`haiku`/`opus`) for each\n2. **Scope per agent**: Exactly what each agent investigates (files, topics, questions)\n3. **Output contract**: What each agent should return (format, length, key questions to answer)\n4. **Result integration**: How you'll combine agent outputs into a coherent response\n5. **Failure strategy**: What happens if an agent hits context limits or returns incomplete results\n\n### Example Plan Structure\n\n```markdown\n## Agent Dispatch Plan: [Goal]\n\n### Agents (N total)\n\n| # | Agent Type | Model | Scope | Output Contract |\n|---|-----------|-------|-------|-----------------|\n| 1 | Explore | haiku | Search plugins/ for X | File paths + summaries |\n| 2 | general-purpose | sonnet | Research Y via web | Key findings, 500 words max |\n| 3 | general-purpose | sonnet | Analyze Z files | Structured assessment |\n\n### Integration Strategy\n[How results combine into final answer]\n\n### Failure Handling\n- Agent timeout/overflow: [strategy]\n- Incomplete results: [strategy]\n```\n\n### Enforcement\n\nThis rule applies to ALL multi-agent dispatches, including:\n- Research/audit missions (web + codebase analysis)\n- Large refactoring across many files\n- Comprehensive review tasks\n- Any task requiring continuation agents\n\n## WARNING: Remote Control / Headless Limitations\n\n**Avoid running parallel subagent dispatches via\n`/remote-control` or headless SDK sessions.**\n\nThe Task tool blocks the main thread while awaiting\nsubagent completion. If any subagent hangs (a known\nupstream bug), the parent session becomes unrecoverable\nbecause remote-control has no programmatic equivalent\nof the `Esc` interrupt.\n\n**Safe alternatives for remote-control use:**\n- Use `run_in_background: true` on Agent calls\n- Run with `--scope minor` (inline execution, no\n subagent dispatch)\n- Use a local terminal with remote-control as a\n monitoring-only window\n\nSee [troubleshooting.md](troubleshooting.md) for recovery\nsteps if a subagent hangs.\n\n## Execute Nonconflicting Tasks in Parallel\n\n**When you have multiple nonconflicting tasks, invoke all Task tools in a single response.**\n\nParallel execution is the default for nonconflicting tasks.\n\n## Identify Nonconflicting Tasks\n\nTasks can run in parallel only when all conditions are met:\n\n✅ **Safe for parallel execution:**\n- Tasks modify **different files** (no overlap)\n- Tasks have **no shared state** (independent data)\n- Tasks don't modify **same code paths** (no merge conflicts)\n- Tasks have **satisfied dependencies** (no blocking)\n- Tasks don't depend on **each other's outputs**\n\n❌ **Not safe for parallel execution:**\n- Tasks modify the **same file** or related files\n- Tasks share **configuration** or **global state**\n- Tasks have **sequential dependencies**\n- Tasks touch **overlapping code paths** that could conflict\n- Tasks need results from **each other**\n- Both tasks are `[R:RED]` (compounding risk prohibited)\n- Either task is `[R:CRITICAL]` (always executes solo)\n\n## Analyze Task Conflicts BEFORE Dispatching\n\n**Required**: Perform conflict analysis before parallel execution:\n\n```markdown\nAnalyzing tasks for parallel execution:\n\nTask 1 (Issue #42): Create auth middleware in src/auth/middleware.py\nTask 2 (Issue #43): Fix validation bug in src/validators/schema.py\nTask 3 (Issue #44): Add logging to src/utils/logger.py\n\nConflict Check:\n- Files: ✅ No overlap (middleware.py, schema.py, logger.py are different)\n- Dependencies: ✅ No sequential dependencies between tasks\n- State: ✅ No shared configuration or database schema\n- Code paths: ✅ Independent modules, no import conflicts\n\nDecision: Execute Tasks 1, 2, 3 in PARALLEL (3 Task tool invocations in single response)\n```\n\n**COUNTER-EXAMPLE** - Sequential execution required:\n\n```markdown\nTask A (Issue #50): Refactor User model in models/user.py\nTask B (Issue #51): Add authentication using User model\n\nConflict Check:\n- Files: ❌ Task B depends on Task A's User model changes\n- Dependencies: ❌ Task B needs Task A's output\n- Code paths: ❌ Both touch authentication flow\n\nDecision: Execute SEQUENTIALLY (Task A first, then Task B)\n```\n\n## Risk-Tier Parallel Safety\n\nWhen tasks have `[R:TIER]` markers (from `leyline:risk-classification`), apply these additional constraints:\n\n| Task A Tier | Task B Tier | Parallel? | Reason |\n|-------------|-------------|-----------|--------|\n| GREEN | Any | Yes | Low risk, independent |\n| YELLOW | YELLOW | Yes | Standard caution |\n| YELLOW | RED | Yes | With conflict monitoring |\n| RED | RED | **No** | Compounding risk too high |\n| Any | CRITICAL | **No** | CRITICAL always solo |\n\nTasks without `[R:TIER]` markers are treated as GREEN (backward compatible).\n\n## Dispatch Parallel Subagents\n\n**All subagents commit to the SAME branch.** The parent\ncreates one shared branch before dispatch (Step 4.1) and\nall work lands there. Do not create per-issue branches.\nThis produces one PR at completion.\n\n**CORRECT PATTERN** - Multiple Task tool invocations in ONE response:\n\n```text\nI'll execute these 3 nonconflicting tasks in parallel:\n\nTask(description: \"Issue #42 - Create auth middleware\")\nTask(description: \"Issue #43 - Fix validation bug\")\nTask(description: \"Issue #44 - Add logging feature\")\n\nEach task will:\n1. Work on the current branch (fix/issues-42-43-44)\n2. Implement in its designated file (no conflicts)\n3. Follow TDD - write failing test first\n4. Verify no regressions\n5. Commit with conventional format\n```\n\n**WRONG PATTERN** - Sequential invocations:\n\n```text\n❌ Task(description: \"Issue #42\")\n [wait for result]\n Task(description: \"Issue #43\")\n [wait for result]\n\nThis wastes time when tasks are nonconflicting!\n```\n\n## Await Parallel Results\n\nCollect results from all parallel subagents before proceeding:\n\n```\nParallel Batch 1: Issues #42, #43, #44 (3 tasks)\n [3 subagents running in parallel...]\n\n ✅ #42: Complete (auth middleware in src/auth/middleware.py)\n ✅ #43: Complete (validation fix in src/validators/schema.py)\n ✅ #44: Complete (logging in src/utils/logger.py)\n\nAll tasks completed without conflicts.\n```\n\n## Key Principles\n\n| Principle | Description |\n|-----------|-------------|\n| **One Branch** | All subagents commit to the shared branch (one PR at the end) |\n| **Fresh Context** | Each subagent starts clean, avoiding context pollution |\n| **TDD by Default** | Subagents write failing tests first |\n| **Conventional Commits** | Each task commits with proper format |\n| **Isolation** | Tasks don't share state between subagents |\n\n## Agent Teams (Default Execution Backend)\n\nAgent teams is the **default** for parallel execution in do-issue. Teammates coordinate via filesystem-based messaging, which prevents merge conflicts and duplicate work that Task tool batches would only catch at the review gate.\n\nUse `--no-agent-teams` to fall back to Task tool dispatch when coordination overhead isn't justified.\n\n### Automatic Downgrade\n\nAgent teams is skipped (Task tool or inline used instead) when:\n- Single issue with `--scope minor` (no parallelism needed)\n- tmux is not installed or `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is unset\n- `--no-agent-teams` flag is explicitly passed\n\n### When Task Tool Is Better\n\n| Scenario | Recommendation |\n|----------|---------------|\n| Single issue, minor scope | Inline execution (no dispatch at all) |\n| 2-3 fully independent issues, no shared files | Task tool is simpler, `--no-agent-teams` |\n| 3+ issues with shared files or dependencies | Agent teams (default) |\n| 5+ issues, complex dependency graph | Agent teams (default) |\n\n### Agent Teams Execution Pattern\n\n```text\nLead agent creates team: do-issue-{timestamp}\n Spawns: worker-1 (Sonnet), worker-2 (Sonnet), worker-3 (Sonnet)\n\nLead assigns tasks via inbox:\n worker-1: \"Implement #42 (auth middleware) in src/auth/\"\n worker-2: \"Fix #43 (validation bug) in src/validators/\"\n worker-3: \"Add #44 (logging) in src/utils/\"\n\nMid-execution coordination:\n worker-1 → worker-3: \"I added auth logging to src/auth/log.py —\n don't duplicate in your logging task\"\n worker-3 → worker-1: \"Acknowledged, will import from your module\"\n\nLead collects completion messages, runs quality gates, shuts down team.\n```\n\n### Key Difference from Task Tool\n\nTask tool subagents are **fire-and-forget** — they can't communicate mid-execution. Agent teams teammates can **send messages to each other** when they discover shared concerns. This prevents merge conflicts and duplicate work that Task tool batches would catch only at the review gate.\n\n### Fallback\n\nIf tmux is unavailable or `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is not set, `--agent-teams` silently falls back to standard Task tool dispatch.\n\n## Worktree Isolation for Parallel Safety (Claude Code 2.1.49+)\n\nSubagents with `isolation: \"worktree\"` run in a temporary\ngit worktree, providing filesystem-level isolation.\n\n### When to Use Worktree Isolation\n\n| Scenario | Use Worktree? | Reason |\n|----------|--------------|--------|\n| Agents touch different files | No | No conflict possible |\n| Agents touch overlapping files | **Yes** | Prevents race conditions |\n| Agent does destructive ops (delete and recreate) | **Yes** | Failed agent won't corrupt main |\n| Research/read-only agents | No | No writes to conflict |\n\n### Worktree Behavior\n\n- Agents with worktree isolation get a separate checkout\n- Empty worktrees are auto-cleaned; worktrees with\n changes return `worktreePath` and `worktreeBranch`\n- If `worktreePath` is NOT in the agent result, changes\n either landed in the main workdir or were lost\n\n### Post-Dispatch Verification (MANDATORY)\n\nAfter ALL parallel agents complete, verify before\nproceeding:\n\n```markdown\n## Post-Dispatch Checklist\n\n1. [ ] Check `git worktree list` for remaining worktrees\n2. [ ] Check `git diff --stat` in main workdir for changes\n3. [ ] For each agent with worktree output:\n - Verify worktree changes via `git diff` in worktree\n - Merge or cherry-pick into main branch\n - Remove worktree: `git worktree remove `\n4. [ ] For agents that deleted + recreated files:\n - Verify new files exist: `ls `\n - Verify imports work: `python -c \"from X import Y\"`\n - If directory exists but is empty, restore original:\n `git checkout HEAD -- `\n5. [ ] Run affected tests before committing\n```\n\n### Never Mix Worktree and Direct Agents on Same Files\n\nWhen agents A (worktree) and B (direct) both modify\n`foo.py`, only one set of changes survives. Either:\n\n- Use worktree isolation for ALL agents in the batch, or\n- Use direct (no isolation) for ALL agents in the batch\n\nMixing isolation modes on overlapping files causes\nsilent data loss.\n\n### Agent Path Confusion\n\nAgents in worktrees or with `cd` in their prompts can\nwrite files to wrong paths. Common failure modes:\n\n- Creates `./foo/` instead of `./plugins/bar/foo/`\n- Deletes original but new directory is empty (agent\n hit context limit mid-operation)\n\nMitigation: include absolute paths in agent prompts\nand verify file existence after completion.\n\n## Next Phase\n\nAfter parallel execution completes, proceed to [quality-gates.md](quality-gates.md) for batch review.\n\nFile v1.9.17:modules/quality-gates.md\n\n# Phase 4: Quality Gates\n\nCode review between task batches to catch issues early.\n\n## Batch Code Review\n\nAfter parallel batch completes, review all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Review parallel batch: Issues #42, #43\"\n prompt: |\n Review changes from parallel implementation batch.\n\n Issues addressed:\n - #42 Task 1: Auth middleware\n - #43 Task 1: Validation fix\n\n BASE_SHA: [sha before batch]\n HEAD_SHA: [current sha]\n\n Focus on:\n - Correct implementation per issue requirements\n - No conflicts between parallel changes\n - Test coverage adequate\n - No security vulnerabilities introduced\n```\n\n## Review Feedback Categories\n\n| Category | Action |\n|----------|--------|\n| **Critical Issues** | Fix immediately via follow-up subagent |\n| **Important Issues** | Fix before next batch |\n| **Minor Issues** | Note for later |\n\n## Example Review Output\n\n```\nBatch Review...\n All changes valid, no conflicts\n\nStrengths:\n - Good test coverage\n - Follows existing patterns\n\nIssues: None\n\nProceeding to sequential phase...\n```\n\n## Handling Critical Feedback\n\nWhen critical issues are found:\n\n```\nTask tool (general-purpose):\n description: \"Fix critical issue in auth middleware\"\n prompt: |\n The code review found a critical issue:\n [Issue description]\n\n Fix this before proceeding.\n```\n\n## Next Phase\n\nAfter review passes, proceed to [completion.md](completion.md) for sequential tasks and finalization.\n\nFile v1.9.17:modules/task-planning.md\n\n# Phase 2: Task Planning\n\nAnalyze issue dependencies and create structured task breakdown.\n\n## Dependency Analysis\n\nIdentify which issues can be worked in parallel:\n\n```python\ndef analyze_dependencies(issues):\n \"\"\"\n Identify which issues can be worked in parallel.\n \"\"\"\n independent = []\n dependent = []\n\n for issue in issues:\n if issue.has_no_blockers(issues):\n independent.append(issue)\n else:\n dependent.append({\n 'issue': issue,\n 'blocked_by': issue.get_blockers(issues)\n })\n\n return independent, dependent\n```\n\n## Task Breakdown\n\nFor each issue, generate tasks following `superpowers:writing-plans` structure:\n\n```markdown\n## Issue #42: Add user authentication\n\n### Task 1: Create auth middleware\n- [ ] Implement JWT validation\n- [ ] Add route protection decorator\n- [ ] Write unit tests\n\n### Task 2: Add login endpoint\n- [ ] Create POST /auth/login\n- [ ] Implement password verification\n- [ ] Return JWT on success\n- [ ] Write integration tests\n```\n\n## Initialize TodoWrite\n\nCreate todos for all tasks across all issues:\n\n```\n- [ ] Issue #42 - Task 1: Create auth middleware\n- [ ] Issue #42 - Task 2: Add login endpoint\n- [ ] Issue #43 - Task 1: Fix validation bug\n```\n\n## Dependency Graph Example\n\n```\nDependency Graph:\n #42: Independent\n #43: Independent\n #44: Depends on #42\n\nParallel Batch 1: Issues #42, #43\nSequential Phase: Issue #44\n```\n\n## Risk Classification\n\nAfter task breakdown, classify each task's risk tier using `leyline:risk-classification` heuristics. Run the heuristic classifier against each task's affected files and append a `[R:TIER]` marker.\n\n### Classification Process\n\n1. For each task, identify the files it will modify\n2. Apply `leyline:risk-classification/modules/heuristic-classifier.md` pattern matching\n3. Append `[R:TIER]` marker to the task line\n\n### Task Format with Risk Markers\n\n```markdown\n- [ ] T001 Create project structure per implementation plan\n- [ ] T005 [P] [R:YELLOW] Implement authentication middleware in src/middleware/auth.py\n- [ ] T012 [P] [US1] [R:YELLOW] Create LoginForm component in src/components/LoginForm.tsx\n- [ ] T015 [US2] [R:RED] Add user migration in migrations/002_add_users.py\n```\n\nTasks without `[R:TIER]` markers default to GREEN. Markers are additive — existing task formats remain valid without them.\n\n## Next Phase\n\nAfter planning, proceed to [parallel-execution.md](parallel-execution.md) to dispatch subagents.\n\nFile v1.9.17:modules/troubleshooting.md\n\n# Troubleshooting\n\nCommon issues and solutions when using do-issue.\n\n## Error: Issue Not Found\n\n```bash\nError: Issue #42 not found\nVerify:\n - Issue exists in current repository\n - You have access to the repository\n - Issue number is correct\n```\n\n## Error: Subagent Failure\n\n```bash\nError: Subagent failed on Issue #42 Task 2\nCause: Test failures after implementation\n\nOptions:\n 1. Dispatch fix subagent (recommended)\n 2. Skip task and continue\n 3. Abort workflow\n\n[Selecting option 1...]\nDispatching fix subagent...\n```\n\n## Warning: Merge Conflicts\n\n```bash\nWarning: Parallel changes created conflicts\nFiles: src/auth/middleware.ts\n\nResolution:\n 1. Pausing parallel execution\n 2. Resolving conflicts via dedicated subagent\n 3. Resuming after resolution\n```\n\n## Subagent Not Following Requirements\n\n```bash\nProblem: Subagent implemented feature differently than specified\nSolution: Re-dispatch with more explicit prompt including:\n - Exact acceptance criteria from issue\n - Code examples if provided\n - Links to related files\n```\n\n## Too Many Parallel Conflicts\n\n```bash\nProblem: Multiple subagents modifying same files\nSolution: Use --no-parallel or manually group tasks to avoid overlap\n```\n\n## Review Taking Too Long\n\n```bash\nProblem: Code review subagent taking excessive time\nSolution: Split large batches into smaller groups\n```\n\n## Subagent Hangs (Remote Control / Headless)\n\nWhen running do-issue through `/remote-control` or headless\nSDK sessions, subagents can hang indefinitely with no\nrecovery path. This is a known upstream bug\n([#28482](https://github.com/anthropics/claude-code/issues/28482)).\n\n**Symptoms:**\n- Task status shows \"In progress\" forever\n- No output, no tool calls, no error from the subagent\n- Remote control web UI shows \"philosophizing/tinkering\"\n indefinitely\n- New prompts are queued but never processed\n\n**Recovery:**\n1. If you have local terminal access, press `Esc` to\n interrupt the hung subagent\n2. If headless: `kill -SIGINT ` to interrupt\n3. Start a fresh session rather than trying to resume\n\n**Prevention:**\n- Run subagent-heavy workflows **locally**, not via\n remote-control (Esc is the only recovery mechanism)\n- Use `run_in_background: true` on Agent calls so the\n parent can continue processing if a subagent stalls\n- Limit concurrent subagents to reduce hang probability\n- Monitor from a local terminal even when using remote\n control\n\n**Related issues:**\n- [#28482](https://github.com/anthropics/claude-code/issues/28482) - Agent hang, no headless recovery\n- [#33232](https://github.com/anthropics/claude-code/issues/33232) - Remote-control WebSocket instability\n- [#13240](https://github.com/anthropics/claude-code/issues/13240) - Master freeze/hang bug\n\n## Best Practices\n\n### Before Running\n\n1. validate clean working directory (`git status` shows no changes)\n2. Pull latest from remote\n3. Verify GitHub CLI is authenticated (`gh auth status`)\n4. Review issues briefly to confirm they're ready for implementation\n\n### During Execution\n\n1. Monitor subagent progress via TodoWrite\n2. Don't manually edit files while subagents are working\n3. Let code reviews complete before proceeding\n4. Address Critical issues immediately\n\n### After Completion\n\n1. Review final changes before merging\n2. Verify all tests pass\n3. Update issue comments with implementation notes\n4. Create PR if working on branch\n\nFile v1.9.17:skill-card.md\n\n## Description:
\nImplements GitHub or GitLab issues via parallel subagents with review gates between task batches.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and engineering agents use this skill to fetch GitHub or GitLab issues, break them into implementation tasks, run independent work in parallel where appropriate, review batches, and consolidate the result into one pull request.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The workflow can make persistent remote changes through authenticated GitHub or GitLab access, including comments, issue closure, commits, and pull request preparation.
\nMitigation: Confirm the target repository and issues before use, review generated comments or closure actions before posting, and keep automatic closure disabled unless explicitly approved.
\nRisk: The workflow can ask the agent to post tooling feedback to an unrelated public Night Market repository.
\nMitigation: Skip that feedback step unless the user explicitly approves it and the content has been reviewed and sanitized.
\nRisk: Parallel subagent execution can create coordination failures, merge conflicts, or hard-to-monitor changes.
\nMitigation: Use the documented planning threshold for larger dispatches, review each batch before proceeding, and fall back to sequential execution when tasks share files or high-risk changes.
\n\n\n## Reference(s):
\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-sanctum-do-issue)
\n- [ClawHub Publisher Profile](https://clawhub.ai/user/athola)
\n- [OpenClaw Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum)
\n- [Issue Discovery](modules/issue-discovery.md)
\n- [Task Planning](modules/task-planning.md)
\n- [Parallel Execution](modules/parallel-execution.md)
\n- [Quality Gates](modules/quality-gates.md)
\n- [Completion](modules/completion.md)
\n- [Troubleshooting](modules/troubleshooting.md)
\n\n\n## Skill Output:
\n**Output Type(s):** [guidance, markdown, code, shell commands, configuration]
\n**Output Format:** [Markdown guidance with inline shell commands and configuration snippets]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May coordinate issue comments, issue closure, commits, and pull request preparation through authenticated forge CLIs.]
\n\n## Skill Version(s):
\n1.9.17 (source: server release evidence; artifact frontmatter: 1.9.8)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.16: 9 files, 15872 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12058b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), skill-card.md (2881b), SKILL.md (5579b), _meta.json (139b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: do-issue\ndescription: |\n Implements GitHub or GitLab issues via parallel subagents with review gates between task batches\nversion: 1.9.8\ntriggers:\n - github\n - gitlab\n - issues\n - subagents\n - parallel\n - automation\n - cross-platform\n - resolving multi-step issues end-to-end\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/sanctum\", \"emoji\": \"\\u2699\\ufe0f\", \"requires\": {\"config\": [\"night-market.leyline:git-platform\", \"night-market.superpowers:subagent-driven-development\", \"night-market.superpowers:writing-plans\", \"night-market.superpowers:test-driven-development\", \"night-market.superpowers:requesting-code-review\", \"night-market.superpowers:finishing-a-development-branch\"]}}}\nsource: claude-night-market\nsource_plugin: sanctum\n---\n\n> **Night Market Skill** — ported from [claude-night-market/sanctum](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Key Features](#key-features)\n- [Workflow Overview](#workflow-overview)\n- [Required TodoWrite Items](#required-todowrite-items)\n- [Configuration](#configuration)\n- [Detailed Resources](#detailed-resources)\n\n\n# Fix Issue(s)\n\nRetrieves issue content from the detected git platform (GitHub, GitLab, or Bitbucket) and uses subagent-driven-development to systematically address requirements, executing tasks in parallel where dependencies allow.\n\n**Platform detection is automatic** via the `leyline:git-platform` SessionStart hook. Check session context for `git_platform:` to determine which CLI to use.\n\n## Key Features\n\n- **Cross-Platform**: Automatically detects GitHub/GitLab/Bitbucket and uses appropriate CLI\n- **Flexible Input**: Single issue number, platform URL, or space-delimited list\n- **Parallel Execution**: Independent tasks run concurrently via subagents\n- **One PR**: All issues produce one consolidated PR (never per-issue PRs)\n- **Quality Gates**: Code review between task groups\n- **Fresh Context**: Each subagent starts with clean context for focused work\n\n## Workflow Overview\n\n| Phase | Description | Module |\n|-------|-------------|--------|\n| 1. Discovery | Parse input, fetch issues, extract requirements | [issue-discovery](modules/issue-discovery.md) |\n| 2. Planning | Analyze dependencies, create task breakdown | [task-planning](modules/task-planning.md) |\n| 3. Execution | Dispatch parallel subagents for independent tasks | [parallel-execution](modules/parallel-execution.md) |\n| 4. Quality | Code review gates between task batches | [quality-gates](modules/quality-gates.md) |\n| 5-6. Completion | Sequential tasks, final review, issue updates | [completion](modules/completion.md) |\n\n## Required TodoWrite Items\n\n1. `do-issue:discovery-complete`\n2. `do-issue:tasks-planned`\n3. `do-issue:parallel-batch-complete`\n4. `do-issue:review-passed`\n5. `do-issue:sequential-complete`\n6. `do-issue:issues-updated`\n\n## Forge CLI Commands\n\nUse the platform detected in session context (`git_platform:`). See `Skill(leyline:git-platform)` for full mapping.\n\n| Operation | GitHub (`gh`) | GitLab (`glab`) |\n|-----------|---------------|-----------------|\n| Fetch issue | `gh issue view --json title,body,labels,comments` | `glab issue view ` |\n| Comment | `gh issue comment --body \"msg\"` | `glab issue note --message \"msg\"` |\n| Close | `gh issue close --comment \"reason\"` | `glab issue close ` |\n| Search | `gh issue list --search \"query\"` | `glab issue list --search \"query\"` |\n\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Agent Teams (Default Execution Mode)\n\nAgent teams is the **default** parallel execution backend for do-issue. Teammates coordinate via filesystem-based messaging, enabling real-time communication when shared files or dependencies are discovered mid-implementation.\n\n**Automatic downgrade**: For single issues with `--scope minor`, agent teams is skipped (Task tool or inline execution is used instead). Use `--no-agent-teams` to force Task tool dispatch for any invocation.\n\n**Requires**: Claude Code 2.1.32+, tmux, `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`. If prerequisites are missing, silently falls back to Task tool dispatch.\n\n```yaml\n# Agent teams configuration\nfix_issue:\n agent_teams:\n enabled: true # on by default; --no-agent-teams to disable\n max_teammates: 4 # limit concurrent workers\n model: sonnet # teammate model (lead uses current model)\n auto_downgrade: true # skip agent teams for --scope minor\n```\n\nSee `modules/parallel-execution.md` for detailed agent teams patterns.\n\n## Configuration\n\n```yaml\nfix_issue:\n parallel_execution: true\n max_parallel_subagents: 3\n review_between_batches: true\n auto_close_issues: false\n commit_per_task: true\n```\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Detailed Resources\n\n- **Phase 1**: See [modules/issue-discovery.md](modules/issue-discovery.md) for input parsing and requirement extraction\n- **Phase 2**: See [modules/task-planning.md](modules/task-planning.md) for dependency analysis\n- **Phase 3**: See [modules/parallel-execution.md](modules/parallel-execution.md) for subagent dispatch\n- **Phase 4**: See [modules/quality-gates.md](modules/quality-gates.md) for review patterns\n- **Phase 5-6**: See [modules/completion.md](modules/completion.md) for finalization\n- **Errors**: See [modules/troubleshooting.md](modules/troubleshooting.md) for common issues\n\nFile v1.9.16:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-sanctum-do-issue\",\n \"version\": \"1.9.16\",\n \"publishedAt\": 1784059021762\n}\n\nFile v1.9.16:modules/completion.md\n\n# Phases 5-6: Completion\n\nExecute sequential tasks and finalize the workflow.\n\n## Phase 5: Sequential Tasks\n\nFor tasks with dependencies, execute sequentially:\n\n```\nTask tool (general-purpose):\n description: \"Issue #42 - Task 2: Add login endpoint\"\n prompt: |\n You are implementing Task 2 from Issue #42.\n\n This task depends on completed Task 1 (auth middleware).\n\n [Task requirements]\n\n Verify Task 1's middleware works before building on it.\n```\n\nReview after each sequential task following the subagent-driven-development pattern.\n\n## Phase 6: Final Review\n\nDispatch detailed review of all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Final review: Issues #42, #43, #44\"\n prompt: |\n Review complete implementation for issues: #42, #43, #44\n\n Verify:\n - All acceptance criteria met\n - Tests detailed and passing\n - No regressions introduced\n - Code quality meets standards\n - Documentation updated if needed\n```\n\n## Update Issue Status\n\nFor each completed issue:\n\n```bash\n# Add completion comment\ngh issue comment 42 --body \"Fixed in commit $(git rev-parse --short HEAD)\n\nChanges:\n- Implemented auth middleware\n- Added login endpoint\n- Added detailed tests\n\nReady for review.\"\n\n# Optionally close issue\ngh issue close 42 --comment \"Completed via automated fix workflow\"\n```\n\n## Pre-PR Consolidation Check\n\nBefore creating the PR, verify all work is on ONE branch:\n\n```bash\n# Confirm current branch contains all issue commits\ngit log --oneline --grep=\"Fixes #42\" --grep=\"Fixes #43\" \\\n --all-match HEAD\n# If commits are on separate branches, cherry-pick or\n# rebase them onto the shared branch first.\n```\n\n## Finish Development\n\nUse `superpowers:finishing-a-development-branch` to:\n\n- Verify all tests pass\n- Present merge options\n- Execute chosen completion path\n\n**One PR rule**: Always create exactly ONE pull request\nthat references all issues via `Fixes #N` lines in\nthe body. See Step 6.2 in the do-issue command for\nthe template. Never create separate PRs per issue.\n\n## Tooling Reflection (Night-Market Feedback Loop)\n\nAfter completing the workflow, reflect on the *tooling itself*\n(skills, agents, commands, hooks) rather than the repo code:\n\n- Did any skill behave unexpectedly or have unclear guidance?\n- Was a subagent slow, redundant, or missing context?\n- Did the do-issue command skip steps or require unnecessary\n manual intervention?\n- Did a hook fire incorrectly or miss a case?\n\n**If yes**, post to https://github.com/athola/claude-night-market/discussions\n(Learnings category) using the pattern from `fix-pr`\nStep 6.7. Always target the night-market repo, not the\ncurrent working repo.\n\n**If no observations**, skip this step silently.\n\n> Repo-specific learnings stay in the current repo. Tooling\n> learnings always go to\n> https://github.com/athola/claude-night-market/discussions\n> so the framework can improve.\n\n## Example Final Output\n\n```\nFinal Review: All requirements met\n\nIssues Summary:\n #42: 3 tasks completed, all tests passing\n #43: 2 tasks completed, all tests passing\n #44: 1 task completed, all tests passing\n\nPR: fix(auth): add middleware and login endpoint (#42, #43, #44)\n - Fixes #42, Fixes #43, Fixes #44\n - All issues consolidated in single PR\n```\n\nFile v1.9.16:modules/issue-discovery.md\n\n# Phase 1: Issue Discovery\n\nParse input arguments and retrieve issue content from the detected git platform. Check session context for `git_platform:` to determine which CLI to use.\n\n## Input Formats\n\nThe command accepts flexible input:\n\n```bash\n# Single issue number\n/do-issue 42\n\n# Platform URL (GitHub or GitLab)\n/do-issue https://github.com/owner/repo/issues/42\n/do-issue https://gitlab.com/owner/repo/-/issues/42\n\n# Multiple issues (space-delimited)\n/do-issue 42 43 44\n\n# Mixed formats\n/do-issue 42 https://github.com/owner/repo/issues/43\n```\n\n## Retrieve Issue Content\n\nFor each issue, fetch the full content using the platform-appropriate CLI:\n\n```bash\n# GitHub\ngh issue view 42 --json title,body,labels,assignees,comments\ngh issue view https://github.com/owner/repo/issues/42 --json title,body,labels,assignees,comments\n\n# GitLab\nglab issue view 42\n```\n\n## Extract Requirements\n\nFrom each issue body, identify:\n\n| Category | Look For |\n|----------|----------|\n| **Acceptance Criteria** | Checkboxes, \"should\", \"must\" statements |\n| **Technical Requirements** | Code references, API specs, constraints |\n| **Test Expectations** | Expected behavior, edge cases |\n| **Dependencies** | Related issues, blocking items |\n\n## Example Output\n\n```\nFetching issue #42...\nTitle: Add user authentication\nRequirements identified: 4\n - Acceptance Criteria: 2\n - Technical Requirements: 1\n - Test Expectations: 1\nTasks will be generated: 3\n```\n\n## Next Phase\n\nAfter discovery, proceed to [task-planning.md](task-planning.md) for dependency analysis and task breakdown.\n\nFile v1.9.16:modules/parallel-execution.md\n\n# Phase 3: Parallel Execution\n\nDispatch subagents for independent tasks concurrently.\n\n## Important: Plan Before Large Dispatch\n\n**When dispatching 4+ agents**, enter plan mode first:\n\n| Agent Count | Requirement |\n|-------------|-------------|\n| 1-3 agents | Dispatch directly (standard parallel) |\n| 4+ agents | **Enter plan mode, write strategy, get user approval, execute** |\n\n### Why This Threshold Exists\n\nLarge agent dispatches (4+ agents) create:\n- **Observability loss**: Too many concurrent outputs to track\n- **Context overflow**: Research agents produce large results, triggering continuation agents that lose state\n- **Recovery difficulty**: If 2 of 7 agents fail, there's no plan to resume from\n- **Wasted compute**: Without user alignment, agents may research the wrong things\n\n### Plan-Before-Dispatch Checklist\n\nBefore launching 4+ agents, your plan should specify:\n\n1. **Agent roster**: Name, type (`general-purpose`/`Explore`/specialized), and model (`sonnet`/`haiku`/`opus`) for each\n2. **Scope per agent**: Exactly what each agent investigates (files, topics, questions)\n3. **Output contract**: What each agent should return (format, length, key questions to answer)\n4. **Result integration**: How you'll combine agent outputs into a coherent response\n5. **Failure strategy**: What happens if an agent hits context limits or returns incomplete results\n\n### Example Plan Structure\n\n```markdown\n## Agent Dispatch Plan: [Goal]\n\n### Agents (N total)\n\n| # | Agent Type | Model | Scope | Output Contract |\n|---|-----------|-------|-------|-----------------|\n| 1 | Explore | haiku | Search plugins/ for X | File paths + summaries |\n| 2 | general-purpose | sonnet | Research Y via web | Key findings, 500 words max |\n| 3 | general-purpose | sonnet | Analyze Z files | Structured assessment |\n\n### Integration Strategy\n[How results combine into final answer]\n\n### Failure Handling\n- Agent timeout/overflow: [strategy]\n- Incomplete results: [strategy]\n```\n\n### Enforcement\n\nThis rule applies to ALL multi-agent dispatches, including:\n- Research/audit missions (web + codebase analysis)\n- Large refactoring across many files\n- Comprehensive review tasks\n- Any task requiring continuation agents\n\n## WARNING: Remote Control / Headless Limitations\n\n**Avoid running parallel subagent dispatches via\n`/remote-control` or headless SDK sessions.**\n\nThe Task tool blocks the main thread while awaiting\nsubagent completion. If any subagent hangs (a known\nupstream bug), the parent session becomes unrecoverable\nbecause remote-control has no programmatic equivalent\nof the `Esc` interrupt.\n\n**Safe alternatives for remote-control use:**\n- Use `run_in_background: true` on Agent calls\n- Run with `--scope minor` (inline execution, no\n subagent dispatch)\n- Use a local terminal with remote-control as a\n monitoring-only window\n\nSee [troubleshooting.md](troubleshooting.md) for recovery\nsteps if a subagent hangs.\n\n## Execute Nonconflicting Tasks in Parallel\n\n**When you have multiple nonconflicting tasks, invoke all Task tools in a single response.**\n\nParallel execution is the default for nonconflicting tasks.\n\n## Identify Nonconflicting Tasks\n\nTasks can run in parallel only when all conditions are met:\n\n✅ **Safe for parallel execution:**\n- Tasks modify **different files** (no overlap)\n- Tasks have **no shared state** (independent data)\n- Tasks don't modify **same code paths** (no merge conflicts)\n- Tasks have **satisfied dependencies** (no blocking)\n- Tasks don't depend on **each other's outputs**\n\n❌ **Not safe for parallel execution:**\n- Tasks modify the **same file** or related files\n- Tasks share **configuration** or **global state**\n- Tasks have **sequential dependencies**\n- Tasks touch **overlapping code paths** that could conflict\n- Tasks need results from **each other**\n- Both tasks are `[R:RED]` (compounding risk prohibited)\n- Either task is `[R:CRITICAL]` (always executes solo)\n\n## Analyze Task Conflicts BEFORE Dispatching\n\n**Required**: Perform conflict analysis before parallel execution:\n\n```markdown\nAnalyzing tasks for parallel execution:\n\nTask 1 (Issue #42): Create auth middleware in src/auth/middleware.py\nTask 2 (Issue #43): Fix validation bug in src/validators/schema.py\nTask 3 (Issue #44): Add logging to src/utils/logger.py\n\nConflict Check:\n- Files: ✅ No overlap (middleware.py, schema.py, logger.py are different)\n- Dependencies: ✅ No sequential dependencies between tasks\n- State: ✅ No shared configuration or database schema\n- Code paths: ✅ Independent modules, no import conflicts\n\nDecision: Execute Tasks 1, 2, 3 in PARALLEL (3 Task tool invocations in single response)\n```\n\n**COUNTER-EXAMPLE** - Sequential execution required:\n\n```markdown\nTask A (Issue #50): Refactor User model in models/user.py\nTask B (Issue #51): Add authentication using User model\n\nConflict Check:\n- Files: ❌ Task B depends on Task A's User model changes\n- Dependencies: ❌ Task B needs Task A's output\n- Code paths: ❌ Both touch authentication flow\n\nDecision: Execute SEQUENTIALLY (Task A first, then Task B)\n```\n\n## Risk-Tier Parallel Safety\n\nWhen tasks have `[R:TIER]` markers (from `leyline:risk-classification`), apply these additional constraints:\n\n| Task A Tier | Task B Tier | Parallel? | Reason |\n|-------------|-------------|-----------|--------|\n| GREEN | Any | Yes | Low risk, independent |\n| YELLOW | YELLOW | Yes | Standard caution |\n| YELLOW | RED | Yes | With conflict monitoring |\n| RED | RED | **No** | Compounding risk too high |\n| Any | CRITICAL | **No** | CRITICAL always solo |\n\nTasks without `[R:TIER]` markers are treated as GREEN (backward compatible).\n\n## Dispatch Parallel Subagents\n\n**All subagents commit to the SAME branch.** The parent\ncreates one shared branch before dispatch (Step 4.1) and\nall work lands there. Do not create per-issue branches.\nThis produces one PR at completion.\n\n**CORRECT PATTERN** - Multiple Task tool invocations in ONE response:\n\n```text\nI'll execute these 3 nonconflicting tasks in parallel:\n\nTask(description: \"Issue #42 - Create auth middleware\")\nTask(description: \"Issue #43 - Fix validation bug\")\nTask(description: \"Issue #44 - Add logging feature\")\n\nEach task will:\n1. Work on the current branch (fix/issues-42-43-44)\n2. Implement in its designated file (no conflicts)\n3. Follow TDD - write failing test first\n4. Verify no regressions\n5. Commit with conventional format\n```\n\n**WRONG PATTERN** - Sequential invocations:\n\n```text\n❌ Task(description: \"Issue #42\")\n [wait for result]\n Task(description: \"Issue #43\")\n [wait for result]\n\nThis wastes time when tasks are nonconflicting!\n```\n\n## Await Parallel Results\n\nCollect results from all parallel subagents before proceeding:\n\n```\nParallel Batch 1: Issues #42, #43, #44 (3 tasks)\n [3 subagents running in parallel...]\n\n ✅ #42: Complete (auth middleware in src/auth/middleware.py)\n ✅ #43: Complete (validation fix in src/validators/schema.py)\n ✅ #44: Complete (logging in src/utils/logger.py)\n\nAll tasks completed without conflicts.\n```\n\n## Key Principles\n\n| Principle | Description |\n|-----------|-------------|\n| **One Branch** | All subagents commit to the shared branch (one PR at the end) |\n| **Fresh Context** | Each subagent starts clean, avoiding context pollution |\n| **TDD by Default** | Subagents write failing tests first |\n| **Conventional Commits** | Each task commits with proper format |\n| **Isolation** | Tasks don't share state between subagents |\n\n## Agent Teams (Default Execution Backend)\n\nAgent teams is the **default** for parallel execution in do-issue. Teammates coordinate via filesystem-based messaging, which prevents merge conflicts and duplicate work that Task tool batches would only catch at the review gate.\n\nUse `--no-agent-teams` to fall back to Task tool dispatch when coordination overhead isn't justified.\n\n### Automatic Downgrade\n\nAgent teams is skipped (Task tool or inline used instead) when:\n- Single issue with `--scope minor` (no parallelism needed)\n- tmux is not installed or `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is unset\n- `--no-agent-teams` flag is explicitly passed\n\n### When Task Tool Is Better\n\n| Scenario | Recommendation |\n|----------|---------------|\n| Single issue, minor scope | Inline execution (no dispatch at all) |\n| 2-3 fully independent issues, no shared files | Task tool is simpler, `--no-agent-teams` |\n| 3+ issues with shared files or dependencies | Agent teams (default) |\n| 5+ issues, complex dependency graph | Agent teams (default) |\n\n### Agent Teams Execution Pattern\n\n```text\nLead agent creates team: do-issue-{timestamp}\n Spawns: worker-1 (Sonnet), worker-2 (Sonnet), worker-3 (Sonnet)\n\nLead assigns tasks via inbox:\n worker-1: \"Implement #42 (auth middleware) in src/auth/\"\n worker-2: \"Fix #43 (validation bug) in src/validators/\"\n worker-3: \"Add #44 (logging) in src/utils/\"\n\nMid-execution coordination:\n worker-1 → worker-3: \"I added auth logging to src/auth/log.py —\n don't duplicate in your logging task\"\n worker-3 → worker-1: \"Acknowledged, will import from your module\"\n\nLead collects completion messages, runs quality gates, shuts down team.\n```\n\n### Key Difference from Task Tool\n\nTask tool subagents are **fire-and-forget** — they can't communicate mid-execution. Agent teams teammates can **send messages to each other** when they discover shared concerns. This prevents merge conflicts and duplicate work that Task tool batches would catch only at the review gate.\n\n### Fallback\n\nIf tmux is unavailable or `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is not set, `--agent-teams` silently falls back to standard Task tool dispatch.\n\n## Worktree Isolation for Parallel Safety (Claude Code 2.1.49+)\n\nSubagents with `isolation: \"worktree\"` run in a temporary\ngit worktree, providing filesystem-level isolation.\n\n### When to Use Worktree Isolation\n\n| Scenario | Use Worktree? | Reason |\n|----------|--------------|--------|\n| Agents touch different files | No | No conflict possible |\n| Agents touch overlapping files | **Yes** | Prevents race conditions |\n| Agent does destructive ops (delete and recreate) | **Yes** | Failed agent won't corrupt main |\n| Research/read-only agents | No | No writes to conflict |\n\n### Worktree Behavior\n\n- Agents with worktree isolation get a separate checkout\n- Empty worktrees are auto-cleaned; worktrees with\n changes return `worktreePath` and `worktreeBranch`\n- If `worktreePath` is NOT in the agent result, changes\n either landed in the main workdir or were lost\n\n### Post-Dispatch Verification (MANDATORY)\n\nAfter ALL parallel agents complete, verify before\nproceeding:\n\n```markdown\n## Post-Dispatch Checklist\n\n1. [ ] Check `git worktree list` for remaining worktrees\n2. [ ] Check `git diff --stat` in main workdir for changes\n3. [ ] For each agent with worktree output:\n - Verify worktree changes via `git diff` in worktree\n - Merge or cherry-pick into main branch\n - Remove worktree: `git worktree remove `\n4. [ ] For agents that deleted + recreated files:\n - Verify new files exist: `ls `\n - Verify imports work: `python -c \"from X import Y\"`\n - If directory exists but is empty, restore original:\n `git checkout HEAD -- `\n5. [ ] Run affected tests before committing\n```\n\n### Never Mix Worktree and Direct Agents on Same Files\n\nWhen agents A (worktree) and B (direct) both modify\n`foo.py`, only one set of changes survives. Either:\n\n- Use worktree isolation for ALL agents in the batch, or\n- Use direct (no isolation) for ALL agents in the batch\n\nMixing isolation modes on overlapping files causes\nsilent data loss.\n\n### Agent Path Confusion\n\nAgents in worktrees or with `cd` in their prompts can\nwrite files to wrong paths. Common failure modes:\n\n- Creates `./foo/` instead of `./plugins/bar/foo/`\n- Deletes original but new directory is empty (agent\n hit context limit mid-operation)\n\nMitigation: include absolute paths in agent prompts\nand verify file existence after completion.\n\n## Next Phase\n\nAfter parallel execution completes, proceed to [quality-gates.md](quality-gates.md) for batch review.\n\nFile v1.9.16:modules/quality-gates.md\n\n# Phase 4: Quality Gates\n\nCode review between task batches to catch issues early.\n\n## Batch Code Review\n\nAfter parallel batch completes, review all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Review parallel batch: Issues #42, #43\"\n prompt: |\n Review changes from parallel implementation batch.\n\n Issues addressed:\n - #42 Task 1: Auth middleware\n - #43 Task 1: Validation fix\n\n BASE_SHA: [sha before batch]\n HEAD_SHA: [current sha]\n\n Focus on:\n - Correct implementation per issue requirements\n - No conflicts between parallel changes\n - Test coverage adequate\n - No security vulnerabilities introduced\n```\n\n## Review Feedback Categories\n\n| Category | Action |\n|----------|--------|\n| **Critical Issues** | Fix immediately via follow-up subagent |\n| **Important Issues** | Fix before next batch |\n| **Minor Issues** | Note for later |\n\n## Example Review Output\n\n```\nBatch Review...\n All changes valid, no conflicts\n\nStrengths:\n - Good test coverage\n - Follows existing patterns\n\nIssues: None\n\nProceeding to sequential phase...\n```\n\n## Handling Critical Feedback\n\nWhen critical issues are found:\n\n```\nTask tool (general-purpose):\n description: \"Fix critical issue in auth middleware\"\n prompt: |\n The code review found a critical issue:\n [Issue description]\n\n Fix this before proceeding.\n```\n\n## Next Phase\n\nAfter review passes, proceed to [completion.md](completion.md) for sequential tasks and finalization.\n\nFile v1.9.16:modules/task-planning.md\n\n# Phase 2: Task Planning\n\nAnalyze issue dependencies and create structured task breakdown.\n\n## Dependency Analysis\n\nIdentify which issues can be worked in parallel:\n\n```python\ndef analyze_dependencies(issues):\n \"\"\"\n Identify which issues can be worked in parallel.\n \"\"\"\n independent = []\n dependent = []\n\n for issue in issues:\n if issue.has_no_blockers(issues):\n independent.append(issue)\n else:\n dependent.append({\n 'issue': issue,\n 'blocked_by': issue.get_blockers(issues)\n })\n\n return independent, dependent\n```\n\n## Task Breakdown\n\nFor each issue, generate tasks following `superpowers:writing-plans` structure:\n\n```markdown\n## Issue #42: Add user authentication\n\n### Task 1: Create auth middleware\n- [ ] Implement JWT validation\n- [ ] Add route protection decorator\n- [ ] Write unit tests\n\n### Task 2: Add login endpoint\n- [ ] Create POST /auth/login\n- [ ] Implement password verification\n- [ ] Return JWT on success\n- [ ] Write integration tests\n```\n\n## Initialize TodoWrite\n\nCreate todos for all tasks across all issues:\n\n```\n- [ ] Issue #42 - Task 1: Create auth middleware\n- [ ] Issue #42 - Task 2: Add login endpoint\n- [ ] Issue #43 - Task 1: Fix validation bug\n```\n\n## Dependency Graph Example\n\n```\nDependency Graph:\n #42: Independent\n #43: Independent\n #44: Depends on #42\n\nParallel Batch 1: Issues #42, #43\nSequential Phase: Issue #44\n```\n\n## Risk Classification\n\nAfter task breakdown, classify each task's risk tier using `leyline:risk-classification` heuristics. Run the heuristic classifier against each task's affected files and append a `[R:TIER]` marker.\n\n### Classification Process\n\n1. For each task, identify the files it will modify\n2. Apply `leyline:risk-classification/modules/heuristic-classifier.md` pattern matching\n3. Append `[R:TIER]` marker to the task line\n\n### Task Format with Risk Markers\n\n```markdown\n- [ ] T001 Create project structure per implementation plan\n- [ ] T005 [P] [R:YELLOW] Implement authentication middleware in src/middleware/auth.py\n- [ ] T012 [P] [US1] [R:YELLOW] Create LoginForm component in src/components/LoginForm.tsx\n- [ ] T015 [US2] [R:RED] Add user migration in migrations/002_add_users.py\n```\n\nTasks without `[R:TIER]` markers default to GREEN. Markers are additive — existing task formats remain valid without them.\n\n## Next Phase\n\nAfter planning, proceed to [parallel-execution.md](parallel-execution.md) to dispatch subagents.\n\nFile v1.9.16:modules/troubleshooting.md\n\n# Troubleshooting\n\nCommon issues and solutions when using do-issue.\n\n## Error: Issue Not Found\n\n```bash\nError: Issue #42 not found\nVerify:\n - Issue exists in current repository\n - You have access to the repository\n - Issue number is correct\n```\n\n## Error: Subagent Failure\n\n```bash\nError: Subagent failed on Issue #42 Task 2\nCause: Test failures after implementation\n\nOptions:\n 1. Dispatch fix subagent (recommended)\n 2. Skip task and continue\n 3. Abort workflow\n\n[Selecting option 1...]\nDispatching fix subagent...\n```\n\n## Warning: Merge Conflicts\n\n```bash\nWarning: Parallel changes created conflicts\nFiles: src/auth/middleware.ts\n\nResolution:\n 1. Pausing parallel execution\n 2. Resolving conflicts via dedicated subagent\n 3. Resuming after resolution\n```\n\n## Subagent Not Following Requirements\n\n```bash\nProblem: Subagent implemented feature differently than specified\nSolution: Re-dispatch with more explicit prompt including:\n - Exact acceptance criteria from issue\n - Code examples if provided\n - Links to related files\n```\n\n## Too Many Parallel Conflicts\n\n```bash\nProblem: Multiple subagents modifying same files\nSolution: Use --no-parallel or manually group tasks to avoid overlap\n```\n\n## Review Taking Too Long\n\n```bash\nProblem: Code review subagent taking excessive time\nSolution: Split large batches into smaller groups\n```\n\n## Subagent Hangs (Remote Control / Headless)\n\nWhen running do-issue through `/remote-control` or headless\nSDK sessions, subagents can hang indefinitely with no\nrecovery path. This is a known upstream bug\n([#28482](https://github.com/anthropics/claude-code/issues/28482)).\n\n**Symptoms:**\n- Task status shows \"In progress\" forever\n- No output, no tool calls, no error from the subagent\n- Remote control web UI shows \"philosophizing/tinkering\"\n indefinitely\n- New prompts are queued but never processed\n\n**Recovery:**\n1. If you have local terminal access, press `Esc` to\n interrupt the hung subagent\n2. If headless: `kill -SIGINT ` to interrupt\n3. Start a fresh session rather than trying to resume\n\n**Prevention:**\n- Run subagent-heavy workflows **locally**, not via\n remote-control (Esc is the only recovery mechanism)\n- Use `run_in_background: true` on Agent calls so the\n parent can continue processing if a subagent stalls\n- Limit concurrent subagents to reduce hang probability\n- Monitor from a local terminal even when using remote\n control\n\n**Related issues:**\n- [#28482](https://github.com/anthropics/claude-code/issues/28482) - Agent hang, no headless recovery\n- [#33232](https://github.com/anthropics/claude-code/issues/33232) - Remote-control WebSocket instability\n- [#13240](https://github.com/anthropics/claude-code/issues/13240) - Master freeze/hang bug\n\n## Best Practices\n\n### Before Running\n\n1. validate clean working directory (`git status` shows no changes)\n2. Pull latest from remote\n3. Verify GitHub CLI is authenticated (`gh auth status`)\n4. Review issues briefly to confirm they're ready for implementation\n\n### During Execution\n\n1. Monitor subagent progress via TodoWrite\n2. Don't manually edit files while subagents are working\n3. Let code reviews complete before proceeding\n4. Address Critical issues immediately\n\n### After Completion\n\n1. Review final changes before merging\n2. Verify all tests pass\n3. Update issue comments with implementation notes\n4. Create PR if working on branch\n\nFile v1.9.16:skill-card.md\n\n## Description:
\nImplements GitHub or GitLab issues via parallel subagents with review gates between task batches.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and engineering agents use this skill to fetch GitHub or GitLab issues, break them into tasks, execute independent work in parallel, review batches, and consolidate completed issue work into one pull request.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill can use authenticated GitHub or GitLab CLI access to read issues, change code, commit work, comment on issues, close issues, or create a pull request.
\nMitigation: Run it only in repositories where that level of agent access is acceptable, and review proposed issue comments, closures, commits, and pull requests before they are published.
\nRisk: The workflow includes an external public feedback step for tooling observations that could expose project details without clear confirmation.
\nMitigation: Disable that step or require explicit manual approval before posting any tooling feedback outside the current repository.
\nRisk: Parallel subagent execution can create merge conflicts, incomplete work, or hard-to-recover hangs in remote-control or headless sessions.
\nMitigation: Use the documented review gates, keep high-risk or dependent tasks sequential, limit parallelism, and prefer local sessions when subagents are required.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-sanctum-do-issue)
\n- [Metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum)
\n- [Claude Code issue #28482](https://github.com/anthropics/claude-code/issues/28482)
\n- [Claude Code issue #33232](https://github.com/anthropics/claude-code/issues/33232)
\n- [Claude Code issue #13240](https://github.com/anthropics/claude-code/issues/13240)
\n\n\n## Skill Output:
\n**Output Type(s):** [Guidance, Markdown, Shell commands, Code, Configuration]
\n**Output Format:** [Markdown with inline shell commands, issue workflow steps, task prompts, and configuration examples]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May direct the agent to read and comment on issues, modify code, run tests, commit changes, and prepare one consolidated pull request.]
\n\n## Skill Version(s):
\n1.9.16 (source: ClawHub release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.14: 9 files, 15625 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12058b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), skill-card.md (2227b), SKILL.md (5579b), _meta.json (139b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: do-issue\ndescription: |\n Implements GitHub or GitLab issues via parallel subagents with review gates between task batches\nversion: 1.9.8\ntriggers:\n - github\n - gitlab\n - issues\n - subagents\n - parallel\n - automation\n - cross-platform\n - resolving multi-step issues end-to-end\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/sanctum\", \"emoji\": \"\\u2699\\ufe0f\", \"requires\": {\"config\": [\"night-market.leyline:git-platform\", \"night-market.superpowers:subagent-driven-development\", \"night-market.superpowers:writing-plans\", \"night-market.superpowers:test-driven-development\", \"night-market.superpowers:requesting-code-review\", \"night-market.superpowers:finishing-a-development-branch\"]}}}\nsource: claude-night-market\nsource_plugin: sanctum\n---\n\n> **Night Market Skill** — ported from [claude-night-market/sanctum](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Key Features](#key-features)\n- [Workflow Overview](#workflow-overview)\n- [Required TodoWrite Items](#required-todowrite-items)\n- [Configuration](#configuration)\n- [Detailed Resources](#detailed-resources)\n\n\n# Fix Issue(s)\n\nRetrieves issue content from the detected git platform (GitHub, GitLab, or Bitbucket) and uses subagent-driven-development to systematically address requirements, executing tasks in parallel where dependencies allow.\n\n**Platform detection is automatic** via the `leyline:git-platform` SessionStart hook. Check session context for `git_platform:` to determine which CLI to use.\n\n## Key Features\n\n- **Cross-Platform**: Automatically detects GitHub/GitLab/Bitbucket and uses appropriate CLI\n- **Flexible Input**: Single issue number, platform URL, or space-delimited list\n- **Parallel Execution**: Independent tasks run concurrently via subagents\n- **One PR**: All issues produce one consolidated PR (never per-issue PRs)\n- **Quality Gates**: Code review between task groups\n- **Fresh Context**: Each subagent starts with clean context for focused work\n\n## Workflow Overview\n\n| Phase | Description | Module |\n|-------|-------------|--------|\n| 1. Discovery | Parse input, fetch issues, extract requirements | [issue-discovery](modules/issue-discovery.md) |\n| 2. Planning | Analyze dependencies, create task breakdown | [task-planning](modules/task-planning.md) |\n| 3. Execution | Dispatch parallel subagents for independent tasks | [parallel-execution](modules/parallel-execution.md) |\n| 4. Quality | Code review gates between task batches | [quality-gates](modules/quality-gates.md) |\n| 5-6. Completion | Sequential tasks, final review, issue updates | [completion](modules/completion.md) |\n\n## Required TodoWrite Items\n\n1. `do-issue:discovery-complete`\n2. `do-issue:tasks-planned`\n3. `do-issue:parallel-batch-complete`\n4. `do-issue:review-passed`\n5. `do-issue:sequential-complete`\n6. `do-issue:issues-updated`\n\n## Forge CLI Commands\n\nUse the platform detected in session context (`git_platform:`). See `Skill(leyline:git-platform)` for full mapping.\n\n| Operation | GitHub (`gh`) | GitLab (`glab`) |\n|-----------|---------------|-----------------|\n| Fetch issue | `gh issue view --json title,body,labels,comments` | `glab issue view ` |\n| Comment | `gh issue comment --body \"msg\"` | `glab issue note --message \"msg\"` |\n| Close | `gh issue close --comment \"reason\"` | `glab issue close ` |\n| Search | `gh issue list --search \"query\"` | `glab issue list --search \"query\"` |\n\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Agent Teams (Default Execution Mode)\n\nAgent teams is the **default** parallel execution backend for do-issue. Teammates coordinate via filesystem-based messaging, enabling real-time communication when shared files or dependencies are discovered mid-implementation.\n\n**Automatic downgrade**: For single issues with `--scope minor`, agent teams is skipped (Task tool or inline execution is used instead). Use `--no-agent-teams` to force Task tool dispatch for any invocation.\n\n**Requires**: Claude Code 2.1.32+, tmux, `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`. If prerequisites are missing, silently falls back to Task tool dispatch.\n\n```yaml\n# Agent teams configuration\nfix_issue:\n agent_teams:\n enabled: true # on by default; --no-agent-teams to disable\n max_teammates: 4 # limit concurrent workers\n model: sonnet # teammate model (lead uses current model)\n auto_downgrade: true # skip agent teams for --scope minor\n```\n\nSee `modules/parallel-execution.md` for detailed agent teams patterns.\n\n## Configuration\n\n```yaml\nfix_issue:\n parallel_execution: true\n max_parallel_subagents: 3\n review_between_batches: true\n auto_close_issues: false\n commit_per_task: true\n```\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Detailed Resources\n\n- **Phase 1**: See [modules/issue-discovery.md](modules/issue-discovery.md) for input parsing and requirement extraction\n- **Phase 2**: See [modules/task-planning.md](modules/task-planning.md) for dependency analysis\n- **Phase 3**: See [modules/parallel-execution.md](modules/parallel-execution.md) for subagent dispatch\n- **Phase 4**: See [modules/quality-gates.md](modules/quality-gates.md) for review patterns\n- **Phase 5-6**: See [modules/completion.md](modules/completion.md) for finalization\n- **Errors**: See [modules/troubleshooting.md](modules/troubleshooting.md) for common issues\n\nFile v1.9.14:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-sanctum-do-issue\",\n \"version\": \"1.9.14\",\n \"publishedAt\": 1782842701720\n}\n\nFile v1.9.14:modules/completion.md\n\n# Phases 5-6: Completion\n\nExecute sequential tasks and finalize the workflow.\n\n## Phase 5: Sequential Tasks\n\nFor tasks with dependencies, execute sequentially:\n\n```\nTask tool (general-purpose):\n description: \"Issue #42 - Task 2: Add login endpoint\"\n prompt: |\n You are implementing Task 2 from Issue #42.\n\n This task depends on completed Task 1 (auth middleware).\n\n [Task requirements]\n\n Verify Task 1's middleware works before building on it.\n```\n\nReview after each sequential task following the subagent-driven-development pattern.\n\n## Phase 6: Final Review\n\nDispatch detailed review of all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Final review: Issues #42, #43, #44\"\n prompt: |\n Review complete implementation for issues: #42, #43, #44\n\n Verify:\n - All acceptance criteria met\n - Tests detailed and passing\n - No regressions introduced\n - Code quality meets standards\n - Documentation updated if needed\n```\n\n## Update Issue Status\n\nFor each completed issue:\n\n```bash\n# Add completion comment\ngh issue comment 42 --body \"Fixed in commit $(git rev-parse --short HEAD)\n\nChanges:\n- Implemented auth middleware\n- Added login endpoint\n- Added detailed tests\n\nReady for review.\"\n\n# Optionally close issue\ngh issue close 42 --comment \"Completed via automated fix workflow\"\n```\n\n## Pre-PR Consolidation Check\n\nBefore creating the PR, verify all work is on ONE branch:\n\n```bash\n# Confirm current branch contains all issue commits\ngit log --oneline --grep=\"Fixes #42\" --grep=\"Fixes #43\" \\\n --all-match HEAD\n# If commits are on separate branches, cherry-pick or\n# rebase them onto the shared branch first.\n```\n\n## Finish Development\n\nUse `superpowers:finishing-a-development-branch` to:\n\n- Verify all tests pass\n- Present merge options\n- Execute chosen completion path\n\n**One PR rule**: Always create exactly ONE pull request\nthat references all issues via `Fixes #N` lines in\nthe body. See Step 6.2 in the do-issue command for\nthe template. Never create separate PRs per issue.\n\n## Tooling Reflection (Night-Market Feedback Loop)\n\nAfter completing the workflow, reflect on the *tooling itself*\n(skills, agents, commands, hooks) rather than the repo code:\n\n- Did any skill behave unexpectedly or have unclear guidance?\n- Was a subagent slow, redundant, or missing context?\n- Did the do-issue command skip steps or require unnecessary\n manual intervention?\n- Did a hook fire incorrectly or miss a case?\n\n**If yes**, post to https://github.com/athola/claude-night-market/discussions\n(Learnings category) using the pattern from `fix-pr`\nStep 6.7. Always target the night-market repo, not the\ncurrent working repo.\n\n**If no observations**, skip this step silently.\n\n> Repo-specific learnings stay in the current repo. Tooling\n> learnings always go to\n> https://github.com/athola/claude-night-market/discussions\n> so the framework can improve.\n\n## Example Final Output\n\n```\nFinal Review: All requirements met\n\nIssues Summary:\n #42: 3 tasks completed, all tests passing\n #43: 2 tasks completed, all tests passing\n #44: 1 task completed, all tests passing\n\nPR: fix(auth): add middleware and login endpoint (#42, #43, #44)\n - Fixes #42, Fixes #43, Fixes #44\n - All issues consolidated in single PR\n```\n\nFile v1.9.14:modules/issue-discovery.md\n\n# Phase 1: Issue Discovery\n\nParse input arguments and retrieve issue content from the detected git platform. Check session context for `git_platform:` to determine which CLI to use.\n\n## Input Formats\n\nThe command accepts flexible input:\n\n```bash\n# Single issue number\n/do-issue 42\n\n# Platform URL (GitHub or GitLab)\n/do-issue https://github.com/owner/repo/issues/42\n/do-issue https://gitlab.com/owner/repo/-/issues/42\n\n# Multiple issues (space-delimited)\n/do-issue 42 43 44\n\n# Mixed formats\n/do-issue 42 https://github.com/owner/repo/issues/43\n```\n\n## Retrieve Issue Content\n\nFor each issue, fetch the full content using the platform-appropriate CLI:\n\n```bash\n# GitHub\ngh issue view 42 --json title,body,labels,assignees,comments\ngh issue view https://github.com/owner/repo/issues/42 --json title,body,labels,assignees,comments\n\n# GitLab\nglab issue view 42\n```\n\n## Extract Requirements\n\nFrom each issue body, identify:\n\n| Category | Look For |\n|----------|----------|\n| **Acceptance Criteria** | Checkboxes, \"should\", \"must\" statements |\n| **Technical Requirements** | Code references, API specs, constraints |\n| **Test Expectations** | Expected behavior, edge cases |\n| **Dependencies** | Related issues, blocking items |\n\n## Example Output\n\n```\nFetching issue #42...\nTitle: Add user authentication\nRequirements identified: 4\n - Acceptance Criteria: 2\n - Technical Requirements: 1\n - Test Expectations: 1\nTasks will be generated: 3\n```\n\n## Next Phase\n\nAfter discovery, proceed to [task-planning.md](task-planning.md) for dependency analysis and task breakdown.\n\nFile v1.9.14:modules/parallel-execution.md\n\n# Phase 3: Parallel Execution\n\nDispatch subagents for independent tasks concurrently.\n\n## Important: Plan Before Large Dispatch\n\n**When dispatching 4+ agents**, enter plan mode first:\n\n| Agent Count | Requirement |\n|-------------|-------------|\n| 1-3 agents | Dispatch directly (standard parallel) |\n| 4+ agents | **Enter plan mode, write strategy, get user approval, execute** |\n\n### Why This Threshold Exists\n\nLarge agent dispatches (4+ agents) create:\n- **Observability loss**: Too many concurrent outputs to track\n- **Context overflow**: Research agents produce large results, triggering continuation agents that lose state\n- **Recovery difficulty**: If 2 of 7 agents fail, there's no plan to resume from\n- **Wasted compute**: Without user alignment, agents may research the wrong things\n\n### Plan-Before-Dispatch Checklist\n\nBefore launching 4+ agents, your plan should specify:\n\n1. **Agent roster**: Name, type (`general-purpose`/`Explore`/specialized), and model (`sonnet`/`haiku`/`opus`) for each\n2. **Scope per agent**: Exactly what each agent investigates (files, topics, questions)\n3. **Output contract**: What each agent should return (format, length, key questions to answer)\n4. **Result integration**: How you'll combine agent outputs into a coherent response\n5. **Failure strategy**: What happens if an agent hits context limits or returns incomplete results\n\n### Example Plan Structure\n\n```markdown\n## Agent Dispatch Plan: [Goal]\n\n### Agents (N total)\n\n| # | Agent Type | Model | Scope | Output Contract |\n|---|-----------|-------|-------|-----------------|\n| 1 | Explore | haiku | Search plugins/ for X | File paths + summaries |\n| 2 | general-purpose | sonnet | Research Y via web | Key findings, 500 words max |\n| 3 | general-purpose | sonnet | Analyze Z files | Structured assessment |\n\n### Integration Strategy\n[How results combine into final answer]\n\n### Failure Handling\n- Agent timeout/overflow: [strategy]\n- Incomplete results: [strategy]\n```\n\n### Enforcement\n\nThis rule applies to ALL multi-agent dispatches, including:\n- Research/audit missions (web + codebase analysis)\n- Large refactoring across many files\n- Comprehensive review tasks\n- Any task requiring continuation agents\n\n## WARNING: Remote Control / Headless Limitations\n\n**Avoid running parallel subagent dispatches via\n`/remote-control` or headless SDK sessions.**\n\nThe Task tool blocks the main thread while awaiting\nsubagent completion. If any subagent hangs (a known\nupstream bug), the parent session becomes unrecoverable\nbecause remote-control has no programmatic equivalent\nof the `Esc` interrupt.\n\n**Safe alternatives for remote-control use:**\n- Use `run_in_background: true` on Agent calls\n- Run with `--scope minor` (inline execution, no\n subagent dispatch)\n- Use a local terminal with remote-control as a\n monitoring-only window\n\nSee [troubleshooting.md](troubleshooting.md) for recovery\nsteps if a subagent hangs.\n\n## Execute Nonconflicting Tasks in Parallel\n\n**When you have multiple nonconflicting tasks, invoke all Task tools in a single response.**\n\nParallel execution is the default for nonconflicting tasks.\n\n## Identify Nonconflicting Tasks\n\nTasks can run in parallel only when all conditions are met:\n\n✅ **Safe for parallel execution:**\n- Tasks modify **different files** (no overlap)\n- Tasks have **no shared state** (independent data)\n- Tasks don't modify **same code paths** (no merge conflicts)\n- Tasks have **satisfied dependencies** (no blocking)\n- Tasks don't depend on **each other's outputs**\n\n❌ **Not safe for parallel execution:**\n- Tasks modify the **same file** or related files\n- Tasks share **configuration** or **global state**\n- Tasks have **sequential dependencies**\n- Tasks touch **overlapping code paths** that could conflict\n- Tasks need results from **each other**\n- Both tasks are `[R:RED]` (compounding risk prohibited)\n- Either task is `[R:CRITICAL]` (always executes solo)\n\n## Analyze Task Conflicts BEFORE Dispatching\n\n**Required**: Perform conflict analysis before parallel execution:\n\n```markdown\nAnalyzing tasks for parallel execution:\n\nTask 1 (Issue #42): Create auth middleware in src/auth/middleware.py\nTask 2 (Issue #43): Fix validation bug in src/validators/schema.py\nTask 3 (Issue #44): Add logging to src/utils/logger.py\n\nConflict Check:\n- Files: ✅ No overlap (middleware.py, schema.py, logger.py are different)\n- Dependencies: ✅ No sequential dependencies between tasks\n- State: ✅ No shared configuration or database schema\n- Code paths: ✅ Independent modules, no import conflicts\n\nDecision: Execute Tasks 1, 2, 3 in PARALLEL (3 Task tool invocations in single response)\n```\n\n**COUNTER-EXAMPLE** - Sequential execution required:\n\n```markdown\nTask A (Issue #50): Refactor User model in models/user.py\nTask B (Issue #51): Add authentication using User model\n\nConflict Check:\n- Files: ❌ Task B depends on Task A's User model changes\n- Dependencies: ❌ Task B needs Task A's output\n- Code paths: ❌ Both touch authentication flow\n\nDecision: Execute SEQUENTIALLY (Task A first, then Task B)\n```\n\n## Risk-Tier Parallel Safety\n\nWhen tasks have `[R:TIER]` markers (from `leyline:risk-classification`), apply these additional constraints:\n\n| Task A Tier | Task B Tier | Parallel? | Reason |\n|-------------|-------------|-----------|--------|\n| GREEN | Any | Yes | Low risk, independent |\n| YELLOW | YELLOW | Yes | Standard caution |\n| YELLOW | RED | Yes | With conflict monitoring |\n| RED | RED | **No** | Compounding risk too high |\n| Any | CRITICAL | **No** | CRITICAL always solo |\n\nTasks without `[R:TIER]` markers are treated as GREEN (backward compatible).\n\n## Dispatch Parallel Subagents\n\n**All subagents commit to the SAME branch.** The parent\ncreates one shared branch before dispatch (Step 4.1) and\nall work lands there. Do not create per-issue branches.\nThis produces one PR at completion.\n\n**CORRECT PATTERN** - Multiple Task tool invocations in ONE response:\n\n```text\nI'll execute these 3 nonconflicting tasks in parallel:\n\nTask(description: \"Issue #42 - Create auth middleware\")\nTask(description: \"Issue #43 - Fix validation bug\")\nTask(description: \"Issue #44 - Add logging feature\")\n\nEach task will:\n1. Work on the current branch (fix/issues-42-43-44)\n2. Implement in its designated file (no conflicts)\n3. Follow TDD - write failing test first\n4. Verify no regressions\n5. Commit with conventional format\n```\n\n**WRONG PATTERN** - Sequential invocations:\n\n```text\n❌ Task(description: \"Issue #42\")\n [wait for result]\n Task(description: \"Issue #43\")\n [wait for result]\n\nThis wastes time when tasks are nonconflicting!\n```\n\n## Await Parallel Results\n\nCollect results from all parallel subagents before proceeding:\n\n```\nParallel Batch 1: Issues #42, #43, #44 (3 tasks)\n [3 subagents running in parallel...]\n\n ✅ #42: Complete (auth middleware in src/auth/middleware.py)\n ✅ #43: Complete (validation fix in src/validators/schema.py)\n ✅ #44: Complete (logging in src/utils/logger.py)\n\nAll tasks completed without conflicts.\n```\n\n## Key Principles\n\n| Principle | Description |\n|-----------|-------------|\n| **One Branch** | All subagents commit to the shared branch (one PR at the end) |\n| **Fresh Context** | Each subagent starts clean, avoiding context pollution |\n| **TDD by Default** | Subagents write failing tests first |\n| **Conventional Commits** | Each task commits with proper format |\n| **Isolation** | Tasks don't share state between subagents |\n\n## Agent Teams (Default Execution Backend)\n\nAgent teams is the **default** for parallel execution in do-issue. Teammates coordinate via filesystem-based messaging, which prevents merge conflicts and duplicate work that Task tool batches would only catch at the review gate.\n\nUse `--no-agent-teams` to fall back to Task tool dispatch when coordination overhead isn't justified.\n\n### Automatic Downgrade\n\nAgent teams is skipped (Task tool or inline used instead) when:\n- Single issue with `--scope minor` (no parallelism needed)\n- tmux is not installed or `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is unset\n- `--no-agent-teams` flag is explicitly passed\n\n### When Task Tool Is Better\n\n| Scenario | Recommendation |\n|----------|---------------|\n| Single issue, minor scope | Inline execution (no dispatch at all) |\n| 2-3 fully independent issues, no shared files | Task tool is simpler, `--no-agent-teams` |\n| 3+ issues with shared files or dependencies | Agent teams (default) |\n| 5+ issues, complex dependency graph | Agent teams (default) |\n\n### Agent Teams Execution Pattern\n\n```text\nLead agent creates team: do-issue-{timestamp}\n Spawns: worker-1 (Sonnet), worker-2 (Sonnet), worker-3 (Sonnet)\n\nLead assigns tasks via inbox:\n worker-1: \"Implement #42 (auth middleware) in src/auth/\"\n worker-2: \"Fix #43 (validation bug) in src/validators/\"\n worker-3: \"Add #44 (logging) in src/utils/\"\n\nMid-execution coordination:\n worker-1 → worker-3: \"I added auth logging to src/auth/log.py —\n don't duplicate in your logging task\"\n worker-3 → worker-1: \"Acknowledged, will import from your module\"\n\nLead collects completion messages, runs quality gates, shuts down team.\n```\n\n### Key Difference from Task Tool\n\nTask tool subagents are **fire-and-forget** — they can't communicate mid-execution. Agent teams teammates can **send messages to each other** when they discover shared concerns. This prevents merge conflicts and duplicate work that Task tool batches would catch only at the review gate.\n\n### Fallback\n\nIf tmux is unavailable or `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` is not set, `--agent-teams` silently falls back to standard Task tool dispatch.\n\n## Worktree Isolation for Parallel Safety (Claude Code 2.1.49+)\n\nSubagents with `isolation: \"worktree\"` run in a temporary\ngit worktree, providing filesystem-level isolation.\n\n### When to Use Worktree Isolation\n\n| Scenario | Use Worktree? | Reason |\n|----------|--------------|--------|\n| Agents touch different files | No | No conflict possible |\n| Agents touch overlapping files | **Yes** | Prevents race conditions |\n| Agent does destructive ops (delete and recreate) | **Yes** | Failed agent won't corrupt main |\n| Research/read-only agents | No | No writes to conflict |\n\n### Worktree Behavior\n\n- Agents with worktree isolation get a separate checkout\n- Empty worktrees are auto-cleaned; worktrees with\n changes return `worktreePath` and `worktreeBranch`\n- If `worktreePath` is NOT in the agent result, changes\n either landed in the main workdir or were lost\n\n### Post-Dispatch Verification (MANDATORY)\n\nAfter ALL parallel agents complete, verify before\nproceeding:\n\n```markdown\n## Post-Dispatch Checklist\n\n1. [ ] Check `git worktree list` for remaining worktrees\n2. [ ] Check `git diff --stat` in main workdir for changes\n3. [ ] For each agent with worktree output:\n - Verify worktree changes via `git diff` in worktree\n - Merge or cherry-pick into main branch\n - Remove worktree: `git worktree remove `\n4. [ ] For agents that deleted + recreated files:\n - Verify new files exist: `ls `\n - Verify imports work: `python -c \"from X import Y\"`\n - If directory exists but is empty, restore original:\n `git checkout HEAD -- `\n5. [ ] Run affected tests before committing\n```\n\n### Never Mix Worktree and Direct Agents on Same Files\n\nWhen agents A (worktree) and B (direct) both modify\n`foo.py`, only one set of changes survives. Either:\n\n- Use worktree isolation for ALL agents in the batch, or\n- Use direct (no isolation) for ALL agents in the batch\n\nMixing isolation modes on overlapping files causes\nsilent data loss.\n\n### Agent Path Confusion\n\nAgents in worktrees or with `cd` in their prompts can\nwrite files to wrong paths. Common failure modes:\n\n- Creates `./foo/` instead of `./plugins/bar/foo/`\n- Deletes original but new directory is empty (agent\n hit context limit mid-operation)\n\nMitigation: include absolute paths in agent prompts\nand verify file existence after completion.\n\n## Next Phase\n\nAfter parallel execution completes, proceed to [quality-gates.md](quality-gates.md) for batch review.\n\nFile v1.9.14:modules/quality-gates.md\n\n# Phase 4: Quality Gates\n\nCode review between task batches to catch issues early.\n\n## Batch Code Review\n\nAfter parallel batch completes, review all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Review parallel batch: Issues #42, #43\"\n prompt: |\n Review changes from parallel implementation batch.\n\n Issues addressed:\n - #42 Task 1: Auth middleware\n - #43 Task 1: Validation fix\n\n BASE_SHA: [sha before batch]\n HEAD_SHA: [current sha]\n\n Focus on:\n - Correct implementation per issue requirements\n - No conflicts between parallel changes\n - Test coverage adequate\n - No security vulnerabilities introduced\n```\n\n## Review Feedback Categories\n\n| Category | Action |\n|----------|--------|\n| **Critical Issues** | Fix immediately via follow-up subagent |\n| **Important Issues** | Fix before next batch |\n| **Minor Issues** | Note for later |\n\n## Example Review Output\n\n```\nBatch Review...\n All changes valid, no conflicts\n\nStrengths:\n - Good test coverage\n - Follows existing patterns\n\nIssues: None\n\nProceeding to sequential phase...\n```\n\n## Handling Critical Feedback\n\nWhen critical issues are found:\n\n```\nTask tool (general-purpose):\n description: \"Fix critical issue in auth middleware\"\n prompt: |\n The code review found a critical issue:\n [Issue description]\n\n Fix this before proceeding.\n```\n\n## Next Phase\n\nAfter review passes, proceed to [completion.md](completion.md) for sequential tasks and finalization.\n\nFile v1.9.14:modules/task-planning.md\n\n# Phase 2: Task Planning\n\nAnalyze issue dependencies and create structured task breakdown.\n\n## Dependency Analysis\n\nIdentify which issues can be worked in parallel:\n\n```python\ndef analyze_dependencies(issues):\n \"\"\"\n Identify which issues can be worked in parallel.\n \"\"\"\n independent = []\n dependent = []\n\n for issue in issues:\n if issue.has_no_blockers(issues):\n independent.append(issue)\n else:\n dependent.append({\n 'issue': issue,\n 'blocked_by': issue.get_blockers(issues)\n })\n\n return independent, dependent\n```\n\n## Task Breakdown\n\nFor each issue, generate tasks following `superpowers:writing-plans` structure:\n\n```markdown\n## Issue #42: Add user authentication\n\n### Task 1: Create auth middleware\n- [ ] Implement JWT validation\n- [ ] Add route protection decorator\n- [ ] Write unit tests\n\n### Task 2: Add login endpoint\n- [ ] Create POST /auth/login\n- [ ] Implement password verification\n- [ ] Return JWT on success\n- [ ] Write integration tests\n```\n\n## Initialize TodoWrite\n\nCreate todos for all tasks across all issues:\n\n```\n- [ ] Issue #42 - Task 1: Create auth middleware\n- [ ] Issue #42 - Task 2: Add login endpoint\n- [ ] Issue #43 - Task 1: Fix validation bug\n```\n\n## Dependency Graph Example\n\n```\nDependency Graph:\n #42: Independent\n #43: Independent\n #44: Depends on #42\n\nParallel Batch 1: Issues #42, #43\nSequential Phase: Issue #44\n```\n\n## Risk Classification\n\nAfter task breakdown, classify each task's risk tier using `leyline:risk-classification` heuristics. Run the heuristic classifier against each task's affected files and append a `[R:TIER]` marker.\n\n### Classification Process\n\n1. For each task, identify the files it will modify\n2. Apply `leyline:risk-classification/modules/heuristic-classifier.md` pattern matching\n3. Append `[R:TIER]` marker to the task line\n\n### Task Format with Risk Markers\n\n```markdown\n- [ ] T001 Create project structure per implementation plan\n- [ ] T005 [P] [R:YELLOW] Implement authentication middleware in src/middleware/auth.py\n- [ ] T012 [P] [US1] [R:YELLOW] Create LoginForm component in src/components/LoginForm.tsx\n- [ ] T015 [US2] [R:RED] Add user migration in migrations/002_add_users.py\n```\n\nTasks without `[R:TIER]` markers default to GREEN. Markers are additive — existing task formats remain valid without them.\n\n## Next Phase\n\nAfter planning, proceed to [parallel-execution.md](parallel-execution.md) to dispatch subagents.\n\nFile v1.9.14:modules/troubleshooting.md\n\n# Troubleshooting\n\nCommon issues and solutions when using do-issue.\n\n## Error: Issue Not Found\n\n```bash\nError: Issue #42 not found\nVerify:\n - Issue exists in current repository\n - You have access to the repository\n - Issue number is correct\n```\n\n## Error: Subagent Failure\n\n```bash\nError: Subagent failed on Issue #42 Task 2\nCause: Test failures after implementation\n\nOptions:\n 1. Dispatch fix subagent (recommended)\n 2. Skip task and continue\n 3. Abort workflow\n\n[Selecting option 1...]\nDispatching fix subagent...\n```\n\n## Warning: Merge Conflicts\n\n```bash\nWarning: Parallel changes created conflicts\nFiles: src/auth/middleware.ts\n\nResolution:\n 1. Pausing parallel execution\n 2. Resolving conflicts via dedicated subagent\n 3. Resuming after resolution\n```\n\n## Subagent Not Following Requirements\n\n```bash\nProblem: Subagent implemented feature differently than specified\nSolution: Re-dispatch with more explicit prompt including:\n - Exact acceptance criteria from issue\n - Code examples if provided\n - Links to related files\n```\n\n## Too Many Parallel Conflicts\n\n```bash\nProblem: Multiple subagents modifying same files\nSolution: Use --no-parallel or manually group tasks to avoid overlap\n```\n\n## Review Taking Too Long\n\n```bash\nProblem: Code review subagent taking excessive time\nSolution: Split large batches into smaller groups\n```\n\n## Subagent Hangs (Remote Control / Headless)\n\nWhen running do-issue through `/remote-control` or headless\nSDK sessions, subagents can hang indefinitely with no\nrecovery path. This is a known upstream bug\n([#28482](https://github.com/anthropics/claude-code/issues/28482)).\n\n**Symptoms:**\n- Task status shows \"In progress\" forever\n- No output, no tool calls, no error from the subagent\n- Remote control web UI shows \"philosophizing/tinkering\"\n indefinitely\n- New prompts are queued but never processed\n\n**Recovery:**\n1. If you have local terminal access, press `Esc` to\n interrupt the hung subagent\n2. If headless: `kill -SIGINT ` to interrupt\n3. Start a fresh session rather than trying to resume\n\n**Prevention:**\n- Run subagent-heavy workflows **locally**, not via\n remote-control (Esc is the only recovery mechanism)\n- Use `run_in_background: true` on Agent calls so the\n parent can continue processing if a subagent stalls\n- Limit concurrent subagents to reduce hang probability\n- Monitor from a local terminal even when using remote\n control\n\n**Related issues:**\n- [#28482](https://github.com/anthropics/claude-code/issues/28482) - Agent hang, no headless recovery\n- [#33232](https://github.com/anthropics/claude-code/issues/33232) - Remote-control WebSocket instability\n- [#13240](https://github.com/anthropics/claude-code/issues/13240) - Master freeze/hang bug\n\n## Best Practices\n\n### Before Running\n\n1. validate clean working directory (`git status` shows no changes)\n2. Pull latest from remote\n3. Verify GitHub CLI is authenticated (`gh auth status`)\n4. Review issues briefly to confirm they're ready for implementation\n\n### During Execution\n\n1. Monitor subagent progress via TodoWrite\n2. Don't manually edit files while subagents are working\n3. Let code reviews complete before proceeding\n4. Address Critical issues immediately\n\n### After Completion\n\n1. Review final changes before merging\n2. Verify all tests pass\n3. Update issue comments with implementation notes\n4. Create PR if working on branch\n\nFile v1.9.14:skill-card.md\n\n## Description:
\nImplements GitHub or GitLab issues via parallel subagents with review gates between task batches.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[athola](https://clawhub.ai/user/athola)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and repository maintainers use this skill to retrieve GitHub or GitLab issues, break them into implementation tasks, run independent work through subagents, and consolidate the result into one reviewed pull request.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill can use an authenticated GitHub or GitLab CLI session to read issues, create commits and pull requests, comment on issues, and optionally close them.
\nMitigation: Review planned repository changes, issue comments, and issue closures before they are sent or merged.
\nRisk: The security summary flags automatic external feedback posting that can send workflow details to another GitHub repository without a clear consent gate.
\nMitigation: Disable or manually approve Night Market feedback posting before use.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-sanctum-do-issue)
\n- [Project homepage](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance]
\n**Output Format:** [Markdown guidance with inline shell commands, task plans, code changes, commit or pull request instructions, and issue comments]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [May use authenticated GitHub or GitLab CLI sessions and subagents to make repository changes, create commits or pull requests, and update issues.]
\n\n## Skill Version(s):
\n1.9.14 (source: ClawHub release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.9.13: 9 files, 15887 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12058b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), skill-card.md (2820b), SKILL.md (5579b), _meta.json (139b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: do-issue\ndescription: |\n Implements GitHub or GitLab issues via parallel subagents with review gates between task batches\nversion: 1.9.8\ntriggers:\n - github\n - gitlab\n - issues\n - subagents\n - parallel\n - automation\n - cross-platform\n - resolving multi-step issues end-to-end\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/sanctum\", \"emoji\": \"\\u2699\\ufe0f\", \"requires\": {\"config\": [\"night-market.leyline:git-platform\", \"night-market.superpowers:subagent-driven-development\", \"night-market.superpowers:writing-plans\", \"night-market.superpowers:test-driven-development\", \"night-market.superpowers:requesting-code-review\", \"night-market.superpowers:finishing-a-development-branch\"]}}}\nsource: claude-night-market\nsource_plugin: sanctum\n---\n\n> **Night Market Skill** — ported from [claude-night-market/sanctum](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Key Features](#key-features)\n- [Workflow Overview](#workflow-overview)\n- [Required TodoWrite Items](#required-todowrite-items)\n- [Configuration](#configuration)\n- [Detailed Resources](#detailed-resources)\n\n\n# Fix Issue(s)\n\nRetrieves issue content from the detected git platform (GitHub, GitLab, or Bitbucket) and uses subagent-driven-development to systematically address requirements, executing tasks in parallel where dependencies allow.\n\n**Platform detection is automatic** via the `leyline:git-platform` SessionStart hook. Check session context for `git_platform:` to determine which CLI to use.\n\n## Key Features\n\n- **Cross-Platform**: Automatically detects GitHub/GitLab/Bitbucket and uses appropriate CLI\n- **Flexible Input**: Single issue number, platform URL, or space-delimited list\n- **Parallel Execution**: Independent tasks run concurrently via subagents\n- **One PR**: All issues produce one consolidated PR (never per-issue PRs)\n- **Quality Gates**: Code review between task groups\n- **Fresh Context**: Each subagent starts with clean context for focused work\n\n## Workflow Overview\n\n| Phase | Description | Module |\n|-------|-------------|--------|\n| 1. Discovery | Parse input, fetch issues, extract requirements | [issue-discovery](modules/issue-discovery.md) |\n| 2. Planning | Analyze dependencies, create task breakdown | [task-planning](modules/task-planning.md) |\n| 3. Execution | Dispatch parallel subagents for independent tasks | [parallel-execution](modules/parallel-execution.md) |\n| 4. Quality | Code review gates between task batches | [quality-gates](modules/quality-gates.md) |\n| 5-6. Completion | Sequential tasks, final review, issue updates | [completion](modules/completion.md) |\n\n## Required TodoWrite Items\n\n1. `do-issue:discovery-complete`\n2. `do-issue:tasks-planned`\n3. `do-issue:parallel-batch-complete`\n4. `do-issue:review-passed`\n5. `do-issue:sequential-complete`\n6. `do-issue:issues-updated`\n\n## Forge CLI Commands\n\nUse the platform detected in session context (`git_platform:`). See `Skill(leyline:git-platform)` for full mapping.\n\n| Operation | GitHub (`gh`) | GitLab (`glab`) |\n|-----------|---------------|-----------------|\n| Fetch issue | `gh issue view --json title,body,labels,comments` | `glab issue view ` |\n| Comment | `gh issue comment --body \"msg\"` | `glab issue note --message \"msg\"` |\n| Close | `gh issue close --comment \"reason\"` | `glab issue close ` |\n| Search | `gh issue list --search \"query\"` | `glab issue list --search \"query\"` |\n\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Agent Teams (Default Execution Mode)\n\nAgent teams is the **default** parallel execution backend for do-issue. Teammates coordinate via filesystem-based messaging, enabling real-time communication when shared files or dependencies are discovered mid-implementation.\n\n**Automatic downgrade**: For single issues with `--scope minor`, agent teams is skipped (Task tool or inline execution is used instead). Use `--no-agent-teams` to force Task tool dispatch for any invocation.\n\n**Requires**: Claude Code 2.1.32+, tmux, `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`. If prerequisites are missing, silently falls back to Task tool dispatch.\n\n```yaml\n# Agent teams configuration\nfix_issue:\n agent_teams:\n enabled: true # on by default; --no-agent-teams to disable\n max_teammates: 4 # limit concurrent workers\n model: sonnet # teammate model (lead uses current model)\n auto_downgrade: true # skip agent teams for --scope minor\n```\n\nSee `modules/parallel-execution.md` for detailed agent teams patterns.\n\n## Configuration\n\n```yaml\nfix_issue:\n parallel_execution: true\n max_parallel_subagents: 3\n review_between_batches: true\n auto_close_issues: false\n commit_per_task: true\n```\n**Verification:** Run the command with `--help` flag to verify availability.\n\n## Detailed Resources\n\n- **Phase 1**: See [modules/issue-discovery.md](modules/issue-discovery.md) for input parsing and requirement extraction\n- **Phase 2**: See [modules/task-planning.md](modules/task-planning.md) for dependency analysis\n- **Phase 3**: See [modules/parallel-execution.md](modules/parallel-execution.md) for subagent dispatch\n- **Phase 4**: See [modules/quality-gates.md](modules/quality-gates.md) for review patterns\n- **Phase 5-6**: See [modules/completion.md](modules/completion.md) for finalization\n- **Errors**: See [modules/troubleshooting.md](modules/troubleshooting.md) for common issues\n\nFile v1.9.13:_meta.json\n\n{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-sanctum-do-issue\",\n \"version\": \"1.9.13\",\n \"publishedAt\": 1782577375143\n}\n\nFile v1.9.13:modules/completion.md\n\n# Phases 5-6: Completion\n\nExecute sequential tasks and finalize the workflow.\n\n## Phase 5: Sequential Tasks\n\nFor tasks with dependencies, execute sequentially:\n\n```\nTask tool (general-purpose):\n description: \"Issue #42 - Task 2: Add login endpoint\"\n prompt: |\n You are implementing Task 2 from Issue #42.\n\n This task depends on completed Task 1 (auth middleware).\n\n [Task requirements]\n\n Verify Task 1's middleware works before building on it.\n```\n\nReview after each sequential task following the subagent-driven-development pattern.\n\n## Phase 6: Final Review\n\nDispatch detailed review of all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Final review: Issues #42, #43, #44\"\n prompt: |\n Review complete implementation for issues: #42, #43, #44\n\n Verify:\n - All acceptance criteria met\n - Tests detailed and passing\n - No regressions introduced\n - Code quality meets standards\n - Documentation updated if needed\n```\n\n## Update Issue Status\n\nFor each completed issue:\n\n```bash\n# Add completion comment\ngh issue comment 42 --body \"Fixed in commit $(git rev-parse --short HEAD)\n\nChanges:\n- Implemented auth middleware\n- Added login endpoint\n- Added detailed tests\n\nReady for review.\"\n\n# Optionally close issue\ngh issue close 42 --comment \"Completed via automated fix workflow\"\n```\n\n## Pre-PR Consolidation Check\n\nBefore creating the PR, verify all work is on ONE branch:\n\n```bash\n# Confirm current branch contains all issue commits\ngit log --oneline --grep=\"Fixes #42\" --grep=\"Fixes #43\" \\\n --all-match HEAD\n# If commits are on separate branches, cherry-pick or\n# rebase them onto the shared branch first.\n```\n\n## Finish Development\n\nUse `superpowers:finishing-a-development-branch` to:\n\n- Verify all tests pass\n- Present merge options\n- Execute chosen completion path\n\n**One PR rule**: Always create exactly ONE pull request\nthat references all issues via `Fixes #N` lines in\nthe body. See Step 6.2 in the do-issue command for\nthe template. Never create separate PRs per issue.\n\n## Tooling Reflection (Night-Market Feedback Loop)\n\nAfter completing the workflow, reflect on the *tooling itself*\n(skills, agents, commands, hooks) rather than the repo code:\n\n- Did any skill behave unexpectedly or have unclear guidance?\n- Was a subagent slow, redundant, or missing context?\n- Did the do-issue command skip steps or require unnecessary\n manual intervention?\n- Did a hook fire incorrectly or miss a case?\n\n**If yes**, post to https://github.com/athola/claude-night-market/discussions\n(Learnings category) using the pattern from `fix-pr`\nStep 6.7. Always target the night-market repo, not the\ncurrent working repo.\n\n**If no observations**, skip this step silently.\n\n> Repo-specific learnings stay in the current repo. Tooling\n> learnings always go to\n> https://github.com/athola/claude-night-market/discussions\n> so the framework can improve.\n\n## Example Final Output\n\n```\nFinal Review: All requirements met\n\nIssues Summary:\n #42: 3 tasks completed, all tests passing\n #43: 2 tasks completed, all tests passing\n #44: 1 task completed, all tests passing\n\nPR: fix(auth): add middleware and login endpoint (#42, #43, #44)\n - Fixes #42, Fixes #43, Fixes #44\n - All issues consolidated in single PR\n```\n\nFile v1.9.13:modules/issue-discovery.md\n\n# Phase 1: Issue Discovery\n\nParse input arguments and retrieve issue content from the detected git platform. Check session context for `git_platform:` to determine which CLI to use.\n\n## Input Formats\n\nThe command accepts flexible input:\n\n```bash\n# Single issue number\n/do-issue 42\n\n# Platform URL (GitHub or GitLab)\n/do-issue https://github.com/owner/repo/issues/42\n/do-issue https://gitlab.com/owner/repo/-/issues/42\n\n# Multiple issues (space-delimited)\n/do-issue 42 43 44\n\n# Mixed formats\n/do-issue 42 https://github.com/owner/repo/issues/43\n```\n\n## Retrieve Issue Content\n\nFor each issue, fetch the full content using the platform-appropriate CLI:\n\n```bash\n# GitHub\ngh issue view 42 --json title,body,labels,assignees,comments\ngh issue view https://github.com/owner/repo/issues/42 --json title,body,labels,assignees,comments\n\n# GitLab\nglab issue view 42\n```\n\n## Extract Requirements\n\nFrom each issue body, identify:\n\n| Category | Look For |\n|----------|-\n\nArchive v1.9.12: 9 files, 15868 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12058b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), skill-card.md (2781b), SKILL.md (5579b), _meta.json (139b)\n\nArchive v1.0.3: 9 files, 15761 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12058b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), skill-card.md (2573b), SKILL.md (5579b), _meta.json (138b)\n\nArchive v1.0.2: 9 files, 15598 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12056b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), skill-card.md (2207b), SKILL.md (5532b), _meta.json (138b)\n\nArchive v1.0.1: 8 files, 14420 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12056b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), SKILL.md (5532b), _meta.json (138b)\n\nArchive v1.0.0: 8 files, 14421 bytes\n\nFiles: modules/completion.md (3256b), modules/issue-discovery.md (1565b), modules/parallel-execution.md (12056b), modules/quality-gates.md (1480b), modules/task-planning.md (2493b), modules/troubleshooting.md (3374b), SKILL.md (5532b), _meta.json (138b)","readmeExcerpt":"Skill: do-issue Owner: athola Summary: Implements GitHub or GitLab issues via parallel subagents with review gates between task batches Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:20:02.434Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:40:08.985Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:57:01.762Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:05:01.720Z | user Release v1.9.14 v1.9.13 | 2026-","codeSnippets":[],"executableExamples":[{"language":"yaml","snippet":"# Agent teams configuration\nfix_issue:\n agent_teams:\n enabled: true # on by default; --no-agent-teams to disable\n max_teammates: 4 # limit concurrent workers\n model: sonnet # teammate model (lead uses current model)\n auto_downgrade: true # skip agent teams for --scope minor"},{"language":"yaml","snippet":"fix_issue:\n parallel_execution: true\n max_parallel_subagents: 3\n review_between_batches: true\n auto_close_issues: false\n commit_per_task: true"},{"language":"text","snippet":"Task tool (general-purpose):\n description: \"Issue #42 - Task 2: Add login endpoint\"\n prompt: |\n You are implementing Task 2 from Issue #42.\n\n This task depends on completed Task 1 (auth middleware).\n\n [Task requirements]\n\n Verify Task 1's middleware works before building on it."},{"language":"text","snippet":"Task tool (superpowers:code-reviewer):\n description: \"Final review: Issues #42, #43, #44\"\n prompt: |\n Review complete implementation for issues: #42, #43, #44\n\n Verify:\n - All acceptance criteria met\n - Tests detailed and passing\n - No regressions introduced\n - Code quality meets standards\n - Documentation updated if needed"},{"language":"bash","snippet":"# Add completion comment\ngh issue comment 42 --body \"Fixed in commit $(git rev-parse --short HEAD)\n\nChanges:\n- Implemented auth middleware\n- Added login endpoint\n- Added detailed tests\n\nReady for review.\"\n\n# Optionally close issue\ngh issue close 42 --comment \"Completed via automated fix workflow\""},{"language":"bash","snippet":"# Confirm current branch contains all issue commits\ngit log --oneline --grep=\"Fixes #42\" --grep=\"Fixes #43\" \\\n --all-match HEAD\n# If commits are on separate branches, cherry-pick or\n# rebase them onto the shared branch first."}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: do-issue\ndescription: |\n Implements GitHub or GitLab issues via parallel subagents with review gates between task batches\nversion: 1.9.8\ntriggers:\n - github\n - gitlab\n - issues\n - subagents\n - parallel\n - automation\n - cross-platform\n - resolving multi-step issues end-to-end\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/sanctum\", \"emoji\": \"\\u2699\\ufe0f\", \"requires\": {\"config\": [\"night-market.leyline:git-platform\", \"night-market.superpowers:subagent-driven-development\", \"night-market.superpowers:writing-plans\", \"night-market.superpowers:test-driven-development\", \"night-market.superpowers:requesting-code-review\", \"night-market.superpowers:finishing-a-development-branch\"]}}}\nsource: claude-night-market\nsource_plugin: sanctum\n---\n\n> **Night Market Skill** — ported from [claude-night-market/sanctum](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [Key Features](#key-features)\n- [Workflow Overview](#workflow-overview)\n- [Required TodoWrite Items](#required-todowrite-items)\n- [Configuration](#configuration)\n- [Detailed Resources](#detailed-resources)\n\n\n# Fix Issue(s)\n\nRetrieves issue content from the detected git platform (GitHub, GitLab, or Bitbucket) and uses subagent-driven-development to systematically address requirements, executing tasks in parallel where dependencies allow.\n\n**Platform detection is automatic** via the `leyline:git-platform` SessionStart hook. Check session context for `git_platform:` to determine which CLI to use.\n\n## Key Features\n\n- **Cross-Platform**: Automatically detects GitHub/GitLab/Bitbucket and uses appropriate CLI\n- **Flexible Input**: Single issue number, platform URL, or space-delimited list\n- **Parallel Execution**: Independent tasks run concurrently via subagents\n- **One PR**: All issues produce one consolidated PR (never per-issue PRs)\n- **Quality Gates**: Code review between task groups\n- **Fresh Context**: Each subagent starts with clean context for focused work\n\n## Workflow Overview\n\n| Phase | Description | Module |\n|-------|-------------|--------|\n| 1. Discovery | Parse input, fetch issues, extract requirements | [issue-discovery](modules/issue-discovery.md) |\n| 2. Planning | Analyze dependencies, create task breakdown | [task-planning](modules/task-planning.md) |\n| 3. Execution | Dispatch parallel subagents for independent tasks | [parallel-execution](modules/parallel-execution.md) |\n| 4. Quality | Code review gates between task batches | [quality-gates](modules/quality-gates.md) |\n| 5-6. Completion | Sequential tasks, final review, issue updates | [completion](modules/completion.md) |\n\n## Required TodoWrite Items\n\n1. `do-issue:discovery-complete`\n2. `do-issue:tasks-planned`\n3. `do-issue:parallel-batch-complete`\n4. `do-issue:review-passed`\n5. `do-issue:sequential-complete`\n6. `do-issue:issues-up"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n \"slug\": \"nm-sanctum-do-issue\",\n \"version\": \"1.9.19\",\n \"publishedAt\": 1787750402434\n}"},{"path":"modules/completion.md","content":"# Phases 5-6: Completion\n\nExecute sequential tasks and finalize the workflow.\n\n## Phase 5: Sequential Tasks\n\nFor tasks with dependencies, execute sequentially:\n\n```\nTask tool (general-purpose):\n description: \"Issue #42 - Task 2: Add login endpoint\"\n prompt: |\n You are implementing Task 2 from Issue #42.\n\n This task depends on completed Task 1 (auth middleware).\n\n [Task requirements]\n\n Verify Task 1's middleware works before building on it.\n```\n\nReview after each sequential task following the subagent-driven-development pattern.\n\n## Phase 6: Final Review\n\nDispatch detailed review of all changes:\n\n```\nTask tool (superpowers:code-reviewer):\n description: \"Final review: Issues #42, #43, #44\"\n prompt: |\n Review complete implementation for issues: #42, #43, #44\n\n Verify:\n - All acceptance criteria met\n - Tests detailed and passing\n - No regressions introduced\n - Code quality meets standards\n - Documentation updated if needed\n```\n\n## Update Issue Status\n\nFor each completed issue:\n\n```bash\n# Add completion comment\ngh issue comment 42 --body \"Fixed in commit $(git rev-parse --short HEAD)\n\nChanges:\n- Implemented auth middleware\n- Added login endpoint\n- Added detailed tests\n\nReady for review.\"\n\n# Optionally close issue\ngh issue close 42 --comment \"Completed via automated fix workflow\"\n```\n\n## Pre-PR Consolidation Check\n\nBefore creating the PR, verify all work is on ONE branch:\n\n```bash\n# Confirm current branch contains all issue commits\ngit log --oneline --grep=\"Fixes #42\" --grep=\"Fixes #43\" \\\n --all-match HEAD\n# If commits are on separate branches, cherry-pick or\n# rebase them onto the shared branch first.\n```\n\n## Finish Development\n\nUse `superpowers:finishing-a-development-branch` to:\n\n- Verify all tests pass\n- Present merge options\n- Execute chosen completion path\n\n**One PR rule**: Always create exactly ONE pull request\nthat references all issues via `Fixes #N` lines in\nthe body. See Step 6.2 in the do-issue command for\nthe template. Never create separate PRs per issue.\n\n## Tooling Reflection (Night-Market Feedback Loop)\n\nAfter completing the workflow, reflect on the *tooling itself*\n(skills, agents, commands, hooks) rather than the repo code:\n\n- Did any skill behave unexpectedly or have unclear guidance?\n- Was a subagent slow, redundant, or missing context?\n- Did the do-issue command skip steps or require unnecessary\n manual intervention?\n- Did a hook fire incorrectly or miss a case?\n\n**If yes**, post to https://github.com/athola/claude-night-market/discussions\n(Learnings category) using the pattern from `fix-pr`\nStep 6.7. Always target the night-market repo, not the\ncurrent working repo.\n\n**If no observations**, skip this step silently.\n\n> Repo-specific learnings stay in the current repo. Tooling\n> learnings always go to\n> https://github.com/athola/claude-night-market/discussions\n> so the framework can improve.\n\n## Example Final Output\n\n```\nFinal Review: All requirements met\n\nIssues Summary:\n #42: 3 tasks complet"},{"path":"modules/issue-discovery.md","content":"# Phase 1: Issue Discovery\n\nParse input arguments and retrieve issue content from the detected git platform. Check session context for `git_platform:` to determine which CLI to use.\n\n## Input Formats\n\nThe command accepts flexible input:\n\n```bash\n# Single issue number\n/do-issue 42\n\n# Platform URL (GitHub or GitLab)\n/do-issue https://github.com/owner/repo/issues/42\n/do-issue https://gitlab.com/owner/repo/-/issues/42\n\n# Multiple issues (space-delimited)\n/do-issue 42 43 44\n\n# Mixed formats\n/do-issue 42 https://github.com/owner/repo/issues/43\n```\n\n## Retrieve Issue Content\n\nFor each issue, fetch the full content using the platform-appropriate CLI:\n\n```bash\n# GitHub\ngh issue view 42 --json title,body,labels,assignees,comments\ngh issue view https://github.com/owner/repo/issues/42 --json title,body,labels,assignees,comments\n\n# GitLab\nglab issue view 42\n```\n\n## Extract Requirements\n\nFrom each issue body, identify:\n\n| Category | Look For |\n|----------|----------|\n| **Acceptance Criteria** | Checkboxes, \"should\", \"must\" statements |\n| **Technical Requirements** | Code references, API specs, constraints |\n| **Test Expectations** | Expected behavior, edge cases |\n| **Dependencies** | Related issues, blocking items |\n\n## Example Output\n\n```\nFetching issue #42...\nTitle: Add user authentication\nRequirements identified: 4\n - Acceptance Criteria: 2\n - Technical Requirements: 1\n - Test Expectations: 1\nTasks will be generated: 3\n```\n\n## Next Phase\n\nAfter discovery, proceed to [task-planning.md](task-planning.md) for dependency analysis and task breakdown."},{"path":"modules/parallel-execution.md","content":"# Phase 3: Parallel Execution\n\nDispatch subagents for independent tasks concurrently.\n\n## Important: Plan Before Large Dispatch\n\n**When dispatching 4+ agents**, enter plan mode first:\n\n| Agent Count | Requirement |\n|-------------|-------------|\n| 1-3 agents | Dispatch directly (standard parallel) |\n| 4+ agents | **Enter plan mode, write strategy, get user approval, execute** |\n\n### Why This Threshold Exists\n\nLarge agent dispatches (4+ agents) create:\n- **Observability loss**: Too many concurrent outputs to track\n- **Context overflow**: Research agents produce large results, triggering continuation agents that lose state\n- **Recovery difficulty**: If 2 of 7 agents fail, there's no plan to resume from\n- **Wasted compute**: Without user alignment, agents may research the wrong things\n\n### Plan-Before-Dispatch Checklist\n\nBefore launching 4+ agents, your plan should specify:\n\n1. **Agent roster**: Name, type (`general-purpose`/`Explore`/specialized), and model (`sonnet`/`haiku`/`opus`) for each\n2. **Scope per agent**: Exactly what each agent investigates (files, topics, questions)\n3. **Output contract**: What each agent should return (format, length, key questions to answer)\n4. **Result integration**: How you'll combine agent outputs into a coherent response\n5. **Failure strategy**: What happens if an agent hits context limits or returns incomplete results\n\n### Example Plan Structure\n\n```markdown\n## Agent Dispatch Plan: [Goal]\n\n### Agents (N total)\n\n| # | Agent Type | Model | Scope | Output Contract |\n|---|-----------|-------|-------|-----------------|\n| 1 | Explore | haiku | Search plugins/ for X | File paths + summaries |\n| 2 | general-purpose | sonnet | Research Y via web | Key findings, 500 words max |\n| 3 | general-purpose | sonnet | Analyze Z files | Structured assessment |\n\n### Integration Strategy\n[How results combine into final answer]\n\n### Failure Handling\n- Agent timeout/overflow: [strategy]\n- Incomplete results: [strategy]\n```\n\n### Enforcement\n\nThis rule applies to ALL multi-agent dispatches, including:\n- Research/audit missions (web + codebase analysis)\n- Large refactoring across many files\n- Comprehensive review tasks\n- Any task requiring continuation agents\n\n## WARNING: Remote Control / Headless Limitations\n\n**Avoid running parallel subagent dispatches via\n`/remote-control` or headless SDK sessions.**\n\nThe Task tool blocks the main thread while awaiting\nsubagent completion. If any subagent hangs (a known\nupstream bug), the parent session becomes unrecoverable\nbecause remote-control has no programmatic equivalent\nof the `Esc` interrupt.\n\n**Safe alternatives for remote-control use:**\n- Use `run_in_background: true` on Agent calls\n- Run with `--scope minor` (inline execution, no\n subagent dispatch)\n- Use a local terminal with remote-control as a\n monitoring-only window\n\nSee [troubleshooting.md](troubleshooting.md) for recovery\nsteps if a subagent hangs.\n\n## Execute Nonconflicting Tasks in Parallel\n\n**When you have multiple nonconflicting "}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Implements GitHub or GitLab issues via parallel subagents with review gates between task batches Skill: do-issue Owner: athola Summary: Implements GitHub or GitLab issues via parallel subagents with review gates between task batches Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:20:02.434Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:40:08.985Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:57:01.762Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:05:01.720Z | user Release v1.9.14 v1.9.13 | 2026-","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1296,"uniquenessScore":51,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T10:23:13.920Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T10:23:13.920Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T13:32:41.425Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}