gco-stack-trace-read
Stack trace / error analysis using GitHub Copilot CLI. Use when: (1) User says 'read stack trace', 'debug this error', 'what does this trace mean', (2) User pastes a stack trace or error output, (3) User provides a file path with an error log. Passes the trace to Copilot for structured debugging pointers. Diagnostic only — no fixes. Falls back to Claude direct analysis if Copilot unavailable.
Best use case
gco-stack-trace-read is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Stack trace / error analysis using GitHub Copilot CLI. Use when: (1) User says 'read stack trace', 'debug this error', 'what does this trace mean', (2) User pastes a stack trace or error output, (3) User provides a file path with an error log. Passes the trace to Copilot for structured debugging pointers. Diagnostic only — no fixes. Falls back to Claude direct analysis if Copilot unavailable.
Teams using gco-stack-trace-read should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/gco-stack-trace-read/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How gco-stack-trace-read Compares
| Feature / Agent | gco-stack-trace-read | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Stack trace / error analysis using GitHub Copilot CLI. Use when: (1) User says 'read stack trace', 'debug this error', 'what does this trace mean', (2) User pastes a stack trace or error output, (3) User provides a file path with an error log. Passes the trace to Copilot for structured debugging pointers. Diagnostic only — no fixes. Falls back to Claude direct analysis if Copilot unavailable.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# GCO Stack Trace Read
Diagnostic analysis of a stack trace or error output via GitHub Copilot CLI.
**Read-only — no file modifications.**
## Process
### Step 0: Pre-flight Rate Limit Check
```bash
RATE_CHECK=$(node $HOME/.claude/scripts/gco-rate-limit.js check 2>&1)
```
If output starts with `degraded:`, notify the user Copilot is in low-cost mode but **proceed anyway** — still usable.
If the check itself fails (node error, script missing), **skip silently** and proceed. Do NOT block on rate-check failure.
### Step 1: Resolve the Trace Input
The argument may be:
- **Inline trace text** — a multi-line block pasted directly
- **File path** — read the file content
```bash
# If argument looks like a file path (no newlines, path-like):
if [ -f "<argument>" ]; then
TRACE_TEXT=$(cat "<argument>")
else
TRACE_TEXT="<inline argument text>"
fi
```
If no argument was provided, ask the user to paste the trace or provide a file path.
### Step 2: Build the Prompt
The prompt passed to `gco-pure.sh` must **not** include the trace text — `gco-pure.sh` appends stdin to the prompt automatically. The prompt should end with the `Stack trace / error:` header.
Assign `PROMPT` to the following literal text:
```bash
PROMPT="You are a debugging assistant. Analyze the following stack trace / error output.
Do NOT suggest code fixes or patches. Return a structured diagnostic report only.
Respond with exactly these three sections:
## Likely causes
Ranked bullets — most probable first. Each bullet: one sentence explaining what could cause this error, and why.
## Files / lines to inspect
File paths and line numbers mentioned in the trace, plus any implicated callsites. Format: \`path/to/file.ext:line\` — one per bullet. If no line numbers are available, list the file.
## Suggested next steps
Concrete debugging actions: add a log statement here, check this condition, verify this env var, reproduce with this input, etc. No code — just directions.
Stack trace / error:"
```
`gco-pure.sh` will append `\n\n<TRACE_TEXT>` after this header automatically (via stdin).
### Step 3: Run Copilot
```bash
LOGDIR=$(node "$HOME/.claude/scripts/get-logdir.js")
mkdir -p "$LOGDIR"
DATETIME=$(date +%Y%m%d_%H%M%S)
printf '%s' "$TRACE_TEXT" | \
bash "$HOME/.claude/skills/gco/scripts/gco-pure.sh" \
"$PROMPT" \
> "$LOGDIR/${DATETIME}-gco-stack-trace.md" \
2> "$LOGDIR/${DATETIME}-gco-stack-trace-stderr.log"
```
`$PROMPT` is the variable assigned in Step 2. `$TRACE_TEXT` is the resolved trace from Step 1.
`gco-pure.sh` already has a 15-minute internal timeout. Run as a **background Bash task**.
### Step 4: Check Rate Limit in Output
```bash
node "$HOME/.claude/scripts/gco-rate-limit.js" check-output \
"$LOGDIR/${DATETIME}-gco-stack-trace.md" \
"$LOGDIR/${DATETIME}-gco-stack-trace-stderr.log"
```
If non-zero exit (rate limit detected): **silently fall back** — proceed to Step 5 without notifying the user.
### Step 5: Fallback
If Copilot timed out, produced **no usable output**, rate limit was detected, or Copilot is **not installed**:
- **Silently fall back** — do NOT report the rate limit, timeout, or fallback to the user. Do NOT pause the workflow.
- Perform Claude-direct analysis of the trace: identify likely causes, files/lines to inspect, and suggested next steps using the same three-section structure
- Continue as if direct analysis was the original plan
### Step 6: Present Results
1. Read `$LOGDIR/${DATETIME}-gco-stack-trace.md`
2. Present the three-section report to the user
3. Include the log file path for reference
4. Do NOT attempt any code fixes — this skill is diagnostic only
## Important Notes
- **No file modifications** — this skill only reads and reports
- Pass the trace to `gco-pure.sh` via stdin (pipe), not as a second argument, to avoid shell escaping issues with large traces
- NEVER use `~` in paths — use `$HOME`
- `gco-pure.sh` uses `--available-tools` with no list = zero tools (read-only, no web access)
- Output: `$LOGDIR/${DATETIME}-gco-stack-trace.md`Related Skills
zudoesa-articlify
Convert conversation context into an esa article via the zudoesa-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write esa article', 'esa記事', 'esaに書いて', 'articlify for esa', or /zudoesa-articlify. Gathers context, creates a writing brief, delegates to the writer subagent.
zudoesa-apply-voice
Apply Takazudo's esa writing voice and vocabulary rules to text. Use when: (1) User wants to write/rewrite text in Takazudo's esa style, (2) User says 'apply voice', 'esa voice', 'esa文体で', 'esa風に書いて', '文体を適用', (3) User provides text to transform to esa style. Reads writing-style.md and vocabulary-rule.md from takazudo-esa-writing repo and applies the rules.
zudocg-articlify
Convert conversation context into a CodeGrid article via the zudocg-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write codegrid article', 'CodeGrid記事', 'codegridに書いて', 'articlify for codegrid', or /zudocg-articlify. Gathers context, creates a writing brief, delegates to the writer subagent.
zudocg-apply-voice
Apply Takazudo's CodeGrid writing voice and vocabulary rules to text. Use when: (1) User wants to write/rewrite text in Takazudo's CodeGrid style, (2) User says 'apply voice', 'codegrid voice', 'codegrid文体で', 'codegrid風に書いて', '文体を適用', (3) User provides text to transform to CodeGrid style. Reads writing-style.md and vocabulary-rule.md from takazudo-codegrid-writing repo and applies the rules.
zpaper-articlify
Convert conversation context into a zpaper blog article via the zpaper-writer subagent. ONLY invoke when the user explicitly asks — NEVER proactively propose. Triggers: 'write zpaper article', 'zpaper記事', 'zpaperに書いて', 'articlify for zpaper', or /zpaper-articlify. Gathers context, creates a writing brief, delegates to the writer subagent.
zpaper-apply-voice
Apply Takazudo's zpaper blog writing voice and vocabulary rules to text. Use when: (1) User wants to write/rewrite text in Takazudo's zpaper style, (2) User says 'apply voice', 'zpaper voice', 'zpaper文体で', 'zpaper風に書いて', 'ブログ文体を適用', (3) User provides text to transform to zpaper style. Reads writing-style.md and vocabulary-rule.md from the zpaper repo and applies the rules.
xlsx
Spreadsheet creation, editing, and analysis. Use when working with .xlsx, .xlsm, .csv, .tsv files for: (1) Creating spreadsheets with formulas and formatting, (2) Reading or analyzing data, (3) Modifying existing spreadsheets while preserving formulas, (4) Data analysis and visualization, (5) Recalculating formulas.
x
Facade for development workflows. Routes on two axes: plan-first vs implement-now (escalates to /big-plan -a when the request needs research / decomposition / has unclear scope — the appended -a makes the plan chain into implementation in-session), then single vs multi on the ready-to-build fast paths (/x-as-pr single-topic, /x-wt-teams multi-topic parallel). Use when: (1) User says '/x' followed by dev instructions, (2) User wants to start development without choosing the workflow skill, (3) User says 'dev', 'implement', or 'build' with a task. Default option: -v (verify-ui). Review-loop (-l) is opt-in — without -l the downstream skill runs a single /deep-review pass. Forwards -a (autonomy/auto-chain) and -m (merge at the end + cleanup + CI watch) through every route; auto-fix of raised findings (-f) and issue-raising (-ri) are downstream defaults, with -nf/--no-fix and -nori/--no-raise-issues as the forwarded opt-outs. -a and -m are orthogonal — full hands-off end-to-end is -a -m.
x-wt-teams
Parallel multi-topic development using git worktrees, base branches, and Claude Code agent teams. Use when: (1) User wants to work on multiple related features in parallel, (2) User mentions 'worktree', 'base branch', 'parallel development', 'split into topics', or 'multi-topic'. FULLY AUTONOMOUS — creates worktrees, spawns teams, coordinates everything. Also supports Super-Epic child mode for [Epic] issues from /big-plan with '**Super-epic:** #N' markers (targets the super-epic base branch instead of main).
x-as-pr
Start a development workflow as a draft PR. Creates a NEW branch from the current branch, empty start commit, draft PR targeting the current branch, then implements. ALWAYS creates a new branch by default — produces a nested PR-on-PR when the current branch already has one. Use when: (1) User says 'dev as pr', (2) User wants a PR-first workflow before coding, (3) User passes -s/--stay to reuse the current branch instead of nesting, (4) User passes a GitHub issue URL to implement, (5) User passes --make-issue/--issue to create an issue first. Logs progress via issue comments when an issue is linked.
watch-ci
Watch GitHub PR CI checks in the background and notify on completion. Use when: (1) User wants to monitor CI/CD status, (2) User says 'watch CI', 'check CI', 'monitor checks', or 'wait for CI', (3) User wants to know when checks pass or fail. Runs a background gh polling shell loop (NOT a subagent — near-zero token cost), sends macOS notification on completion. Also handles merged PRs by watching the target branch CI.
w-update-wording-rule
Add or update wording rules (表記ルール) in the w repo's vocabulary-rule.md files. Use when: (1) User says 'add wording rule', 'update wording rule', '表記ルール追加', (2) User wants to add a kanji/hiragana usage rule, (3) User provides a rule like 'X should be Y' with examples.