# Project Instructions
- Writing: keep user's voice, conversational, stick closely to what user said without making things up, but fix small grammar mistakes
- After adding or renaming tips, run `node scripts/generate-toc.js` to update the table of contents
- `~/.claude/CLAUDE.md` is symlinked to `GLOBAL-CLAUDE.md` in this repo
- When committing changes to the plugin (skills, plugin.json, etc.), bump the patch version in both `.claude-plugin/plugin.json` and `.claude-plugin/marketplace.json`. Don't bump for non-plugin changes.
- Git tags/releases (e.g. `v0.25.1`) and plugin versions (e.g. `0.14.9`) are separate. The git tag follows the repo release progression and is bumped for any change. The plugin version is only in `plugin.json` and `marketplace.json`.
- After pushing a plugin change, update the local install non-interactively (no `/plugin` menu needed): `claude plugin marketplace update ykdojo` then `claude plugin update dx@ykdojo`. The CLI repopulates the versioned cache; a session restart is required to apply.
# Filing Claude Code GitHub issues
For issues against `anthropics/claude-code`. When I ask you to file one:
- Draft it to a temp file and open it in VS Code (`code <file>`) for me to review before filing - never file without showing me first.
- File from host `gh` (`gh issue create`), not a container.
Style (based on my past issues):
- Title: specific, states the symptom; flag regressions. No `[BUG]`/`[FEATURE]` prefix needed.
- Lead with a one-sentence problem statement (no "Description" header). Keep it short and factual, no fluff.
- Note the version where it broke / regression info when relevant.
- Bug sections: `## Steps to reproduce`, `## Expected behavior` (+ `## Actual behavior` if useful), `## Environment` (OS, Claude Code version, terminal).
- Feature requests: `## Problem`, then `## Suggestion` / `## Demonstration`.
- Show concrete fenced code blocks for actual vs expected. Link relevant scripts/files inline rather than pasting them.
---
name: half-clone
description: Clone the later half of the current conversation, discarding earlier context to reduce token usage while preserving recent work.
---
Clone the later half of the current conversation, discarding earlier context to reduce token usage while preserving recent work.
Steps:
1. Get the current session ID and project path: `tail -1 ~/.claude/history.jsonl | jq -r '[.sessionId, .project] | @tsv'`
2. Find half-clone-conversation.sh with bash: `find ~/.claude -name "half-clone-conversation.sh" 2>/dev/null | sort -V | tail -1`
- This finds the script whether installed via plugin or manual symlink
- Uses version sort to prefer the latest version if multiple exist
3. Preview the conversation to verify the session ID: `<script-path> --preview <session-id> <project-path>`
- Check that the first and last messages match the current conversation
4. Run the clone: `<script-path> <session-id> <project-path>`
- Always pass the project path from the history entry, not the current working directory
5. The script prints the new session ID (the `New session: <id>` line). Give the user the exact command to resume it directly, no picker needed:
```
claude --resume <new-session-id>
```
The script automatically appends a reference to the original conversation at the end of the cloned file. (The new session is also marked `[HALF-CLONE <timestamp>]`, e.g. `[HALF-CLONE Jan 7 14:30]`, so `claude -r` and picking it works as a fallback.)
---
name: gha
description: Analyze GitHub Actions failures and identify root causes
argument-hint: <url>
---
Investigate this GitHub Actions URL: $ARGUMENTS
Use the gh CLI to analyze this workflow run. Your investigation should:
1. **Get basic info & identify actual failure**:
- What workflow/job failed, when, and on which commit?
- CRITICAL: Read the full logs carefully to find what SPECIFICALLY caused the exit code 1
- Distinguish between warnings/non-fatal errors vs actual failures
- Look for patterns like "failing:", "fatal:", or script logic that determines when to exit 1
- If you see both "non-fatal" and "fatal" errors, focus on what actually caused the failure
2. **Check flakiness**: Check the past 10-20 runs of THE EXACT SAME failing job:
- IMPORTANT: If a workflow has multiple jobs, you must check history for the SPECIFIC JOB that failed, not just the workflow
- Use `gh run list --workflow=<workflow-name>` to get run IDs, then `gh run view <run-id> --json jobs` to check the specific job's status
- Is this a one-time failure or recurring pattern for THIS SPECIFIC JOB?
- What's the success rate for THIS JOB recently?
- When did THIS JOB last pass?
3. **Identify breaking commit** (if there's a pattern of failures for the specific job):
- Find the first run where THIS SPECIFIC JOB failed and the last run where it passed
- Identify the commit that introduced the failure
- Verify by checking: does THIS JOB fail in ALL runs after that commit? Does it pass in ALL runs before?
- If verified, report the breaking commit with high confidence
4. **Root cause**: Based on logs, history, and any breaking commit, what's the likely cause?
- Focus on what ACTUALLY caused the failure (not just any errors you see)
- Verify your hypothesis against the logs and failure logic
5. **Check for existing fix PRs**: Search for open PRs that might already address this issue:
- Use `gh pr list --state open --search "<keywords>"` with relevant error messages or file names
- Check if any open PR modifies the failing file/workflow
- If a fix PR exists, note it in your report and skip the recommendation section
Write a final report with:
- Summary of failure (what specifically triggered the exit code 1)
- Flakiness assessment (one-time vs recurring, success rate)
- Breaking commit (if identified and verified)
- Root cause analysis (based on the ACTUAL failure trigger)
- Existing fix PR (if found - include PR number and link)
- Recommendation (skip if fix PR already exists)
YakaAI