-
Ask whether to use a dedicated git worktree
- Ask this before any other workflow questions.
- If yes, use/create the worktree and continue there.
-
Confirm issue context and success criteria
- Read the issue body, labels, and linked discussions once, then reuse that context instead of refetching.
- Restate the implementable scope and explicitly list out-of-scope items.
-
Confirm assignee intent for issue closure work
- Check whether the current user is assigned to the primary issue.
- If the current user is not assigned, ask whether they want to assign themselves before continuing.
- For each sub-issue that will be resolved or closed by this workflow, check assignee status once and reuse the result for closure decisions.
- If the current user is not assigned on a sub-issue, ask whether they want to assign themselves before resolving/closing it.
-
Apply low-token GitHub strategy
- Prefer MCP-backed tools over ad hoc
gh api or GraphQL calls when equivalent tools exist.
- Avoid duplicate lookups for labels, issue types, and duplicate detection.
- Cache per-run context (issue metadata, duplicate matches, issue-type support, label sets, assignee candidates) and reuse it — do not re-fetch data that was already retrieved in this session.
- When delegating to
fusion-issue-authoring or its subordinate skills, the orchestrator's session-cache rules apply: labels and assignee candidates are fetched once per repository, issue types once per organization.
- Use GraphQL fallback only when MCP coverage is unavailable and do not loop retries.
- GraphQL mutations cost 5 secondary-limit points each (vs 1 for queries); batch fields into single calls and pause at least 1 second between mutation calls.
- Budget awareness: a typical implementation session (read issue + duplicate check + 1–2 mutations + sub-issue links) should stay under ~20 MCP read calls and ~5 mutations. If the running total approaches 30+ calls, pause optional enrichment and proceed with local work.
- Respect
retry-after and x-ratelimit-reset headers; do not retry before the indicated wait.
- If rate limits are hit, stop non-essential operations and continue with local implementation/PR preparation when possible.
-
Build and track a concrete plan
- Create actionable todos ordered by dependencies.
- Keep exactly one step in progress and update status as work completes.
-
Research before edits
- Inspect relevant files, tests, and adjacent usage.
- Prefer root-cause fixes over surface patches.
-
Implement in small scoped changes
- Keep each change aligned to issue acceptance criteria.
- Avoid unrelated refactors and generated release artifacts.
-
Validate incrementally
- Run targeted checks first, then required project checks.
- If checks fail, fix relevant issues and re-run before proceeding.
-
Prepare PR-ready output
- Summarize what changed and why.
- Include validation evidence and known follow-ups.
- Draft the PR body in a
.tmp/ file with an issue/context-specific name (for example, .tmp/pr-body-issue-123-scope-summary.md), not a shared .tmp/pr-body.md.
- Base the draft on
.github/pull_request_template.md and keep it updated as implementation evolves.
- Ask which base branch to target and propose a likely default (typically
main, or the branch the current branch was cut from).
- Ask whether the PR should be opened as draft or ready for review.
- Ask whether the PR should be assigned to the user and whether related issues should be linked.
-
Optional GitHub mutation steps
