commit-to-issue

name	commit-to-issue
description	Analyze recent git commits, group them into work units, create GitHub issues with full ThakiCloud Project #5 metadata (Status, Priority, Size, Estimate, Sprint, Start/End date), and verify the result. Use when the user asks to "이슈로 등록", "commit-to-issue", "이번주 작업 이슈 만들어줘", "이번 작업을 이슈로 남겨줘", "회고용 이슈 생성", "커밋을 이슈로", "작업 이슈 등록", "깃허브 이슈로 남겨줘", "project #5에 등록", "오늘 작업 이슈 만들어", or any retrospective issue creation from commits. Do NOT use for creating PRs (use release-ship), single ad-hoc issue creation without Project #5 linking (use `gh issue create` directly), or modifying existing issues.
disable-model-invocation	true

Commit-to-Issue — Convert commits into Project #5 issues

Convert recent git commits into tracked GitHub issues on ThakiCloud Project #5 with all 7 project fields populated.

Pipeline mode: When invoked by release-ship, eod-ship, sod-ship, or morning-ship, this skill MUST run to completion. Partial failures must be reported but never silently swallowed. See release-ship Step 4 for hard-fail rules.

Reference

All Project #5 IDs, GraphQL queries, field defaults, and the set_all_fields() Python helper live in references/project-config.md. Never hardcode IDs elsewhere — read that file every time.

Subagent Model Routing

Task Type	Model	Rationale
Exploration / search / file reading	haiku	낮은 비용, read-only 작업
Analysis / implementation / generation	sonnet	균형 잡힌 품질-비용 비율

Agent tool 호출 시 반드시 model 파라미터를 지정한다.

Workflow (8 steps)

1. Detect repository

git remote -v

Extract OWNER/REPO from the origin URL. Common gotcha: ~/thaki/ai-platform-strategy points to sylvanus4/ai-strategy (personal fork), not ThakiCloud/ai-platform-strategy (which does not exist).

2. Analyze commits

# Recent commits since a date or commit
git log --since="$SINCE" --oneline --no-merges
# Or: commits in the current branch not yet on main
git log $(git merge-base HEAD main)..HEAD --oneline --no-merges

For pipeline-mode (called from release-ship): use only the commits created in this pipeline run, not all branch history.

3. Group commits into work units

Cluster related commits into logical work units. Heuristics:

• Same domain/scope (e.g., all .claude/skills/foo/ changes → one issue)
• Same TYPE prefix + adjacent timestamps
• Same logical feature (e.g., "new orchestrator + planning docs" → one issue)

Never create 1:1 commit-to-issue mappings unless the commits are truly isolated changes — that floods Project #5.

For each group, decide:

• title: TYPE: Summary (English, ≤70 chars, no trailing period)
• labels: pick from repo label list (see references/project-config.md § Common Labels)
• description: 2-5 sentence Korean summary of what shipped and why

4. Compute size + estimate

Count total files changed across all commits in the group:

git show --stat --format="" $HASH1 $HASH2 ... | grep -c "^ .*|"

Then map via auto_size(file_count) from references/project-config.md:

Files	Size	Estimate (days)
≤1	XS	0.25
2-5	S	0.5
6-15	M	1.0
16-40	L	2.0
>40	XL	3.0

Override these when domain knowledge says otherwise (e.g., a single config file that took half a day → M, 1.0).

5. Resolve current sprint

# See references/project-config.md § Sprint Lookup for the full CLI helper.
gh api graphql -f query='...' | python3 -c "..."

Never hardcode sprint IDs. They rotate weekly.

6. Create issue + add to Project #5

ISSUE_URL=$(gh issue create \
  --repo $OWNER/$REPO \
  --title "$TITLE" \
  --assignee sylvanus4 \
  --label $L1 --label $L2 \
  --body-file /tmp/issue-body.md)

ITEM_ID=$(gh project item-add 5 --owner ThakiCloud --url "$ISSUE_URL" --format json | jq -r .id)

Issue body template:

## Description

<2-5 sentence Korean summary>

## Commits

- `<hash1>` <commit message>
- `<hash2>` <commit message>

## Period

YYYY-MM-DD ~ YYYY-MM-DD

## Context (optional)

<why this work was done, links to related issues>

7. Set 7 fields (MANDATORY — never partial)

Call set_all_fields(item_id, sprint_id, file_count=N, start_date=..., end_date=...) from references/project-config.md.

Field set:

1. Status (default: Done for retro; In Progress for live work)
2. Priority (default: P2; raise for critical work)
3. Size (auto from file_count)
4. Estimate (auto from file_count, 1d=1.0)
5. Sprint (current iteration)
6. Start date (--date YYYY-MM-DD, NOT --text)
7. End date (--date YYYY-MM-DD, NOT --text)

If any single field set fails, retry once. After second failure, log {field: X, error: ...} but continue with remaining fields.

8. Verify

After all issues are created, run the verification query from references/project-config.md § Verification Query. Assert:

• Every created issue appears in Project #5
• All 7 fields are non-null for every issue

If any issue is missing or has nulls, report it in the final summary and exit non-zero.

Output

Print a summary table at the end:

Created N/N issues. Fields populated: F/F.

#<num> | <title>
  URL: ...
  Item ID: ...
  Status: Done | Priority: P2 | Size: M | Estimate: 1.0
  Sprint: 26-05-Sprint3 | Start: 2026-05-18 | End: 2026-05-22

Rules

• Every issue MUST be assigned to sylvanus4 — NEVER create an unassigned issue (user directive 2026-06-26). gh issue create --assignee sylvanus4 always. Unassigned cards flood the board and get deleted by the weekend cleanup; don't create them in the first place.
• Project #5 issues only for sylvanus4/ai-strategy (Step 1 repo check). Other repos: do not create Project #5 issues.
• Board hygiene is enforced out-of-band by scripts/skills/project5_sprint_cleanup.py (weekend com.thaki.sprint-archive). Goal = only ai-platform-strategy on my slice: my other personal-repo cards deleted from board; ai-platform current archived→Done, current unassigned→assign me, past assigned→26-Archive, past unassigned→delete. Team items untouched.
• Never hardcode field IDs or option IDs — always read references/project-config.md
• Never set Start/End via --text — always --date YYYY-MM-DD
• Never set only partial fields silently — always attempt all 7
• Never skip Project #5 linking — issue without Project #5 = invisible to team
• Always run verification (step 8) before claiming success
• For pipeline mode: NEVER prompt user for confirmation — the caller already approved