SuperAPI AI Directory

kf-g-github-issue-worktree-management

Coding & development

View repository

Updated 10-15 20:24

About this skill

GitHub issue management and worktree operations

Treat this SKILL.md as an entry point; for details, read the relevant file under references . This skill covers how to proceed with issue handling.

For GitHub operations in general, also use kf-g-github-operations-bot-workflow; for PR creation and review, also use kf-g-github-pr-review-workflow .

Basic policy

  • 1 issue = 1 branch = 1 worktree。
  • When handling an issue, do not work directly in the main worktree.
  • Leave work logs, decisions, progress, and PR URLs as issue comments.
  • When planning from an existing issue, refer to the existing issue's description and comments before planning. For details, see issue-progress.md。
  • HTML distribution available (generated withkf-g-html-document-universal-single-file and uploaded to R2): the issue description should contain only a minimal summary and the ## プランニング用資料 under [v{N}](https://ai-html.hacksaw.work/<object-key>) . Put the full plan and details in the HTML. For the timing and format of description updates, see issue-progress.md。
  • No HTML distribution: once planned, transcribe the planning Markdown into the issue descriptionAs is. In the AI-side planning file, instead of writing the planning Markdown, write only the issue link. For details, see issue-progress.md。
  • When an AI agent leaves a comment / description update / status update, use only the bot helper script after the GitHub App bot preflight succeeds.
  • If the bot preflight fails, show the setup procedure and stop. Falling back to human gh / GH_TOKEN is prohibited.

GitHub writes during Plan mode

In Plan mode, if it turns out that GitHub writes before confirmation are prohibited, ask the user for explicit permission before updating an Issue comment or description.

  1. Before performing a GitHub write, clearly state to the user the update target (Issue comment / description) and an overview of the update content.
  2. Obtain explicit permission from the user.
  3. Do not perform the GitHub write until permission is obtained.
  4. After obtaining permission, update according to this skill's standard procedure (issue-progress.md , etc.).

Branch / commit / push

  • Create work diffs only in the issue branch.
  • If gitleaks, which runs before commit / push, fails, do not commit / push.
    • Do not proceed by bypassing hooks or with --no-verify .
  • For details on gitleaks, read kf-g-github-operations-bot-workflow .

How to read further

  1. If selecting an issue, read issue-selection.md .
  2. If referencing an issue from GitHub Projects, read issue-reference.md .
  3. If creating or operating a worktree, read worktree.md .
  4. For updating an issue during work or separating design materials, read issue-progress.md .
  5. For completion processing after PR creation, read completion.md .
  6. Before completing work, check checklist.md .

Reference files