b60638f0a3
Community Skills (32): - jat: jat-start, jat-verify, jat-complete - pi-mono: codex-cli, codex-5.3-prompting, interactive-shell - picoclaw: github, weather, tmux, summarize, skill-creator - dyad: 18 skills (swarm-to-plan, multi-pr-review, fix-issue, lint, etc.) - dexter: dcf valuation skill Agents (23): - pi-mono subagents: scout, planner, reviewer, worker - toad: 19 agent configs (Claude, Codex, Gemini, Copilot, OpenCode, etc.) System Prompts (91): - Anthropic: 15 Claude prompts (opus-4.6, code, cowork, etc.) - OpenAI: 49 GPT prompts (gpt-5 series, o3, o4-mini, tools) - Google: 13 Gemini prompts (2.5-pro, 3-pro, workspace, cli) - xAI: 5 Grok prompts - Other: 9 misc prompts (Notion, Raycast, Warp, Kagi, etc.) Hooks (9): - JAT hooks for session management, signal tracking, activity logging Prompts (6): - pi-mono templates for PR review, issue analysis, changelog audit Sources analyzed: jat, ralph-desktop, toad, pi-mono, cmux, pi-interactive-shell, craft-agents-oss, dexter, picoclaw, dyad, system_prompts_leaks, Prometheus, zed, clawdbot, OS-Copilot, and more
84 lines
3.3 KiB
Markdown
84 lines
3.3 KiB
Markdown
---
|
|
name: dyad:fix-issue
|
|
description: Create a plan to fix a GitHub issue, then implement it locally.
|
|
---
|
|
|
|
# Fix Issue
|
|
|
|
Create a plan to fix a GitHub issue, then implement it locally.
|
|
|
|
## Arguments
|
|
|
|
- `$ARGUMENTS`: GitHub issue number or URL.
|
|
|
|
## Instructions
|
|
|
|
1. **Fetch the GitHub issue:**
|
|
|
|
First, extract the issue number from `$ARGUMENTS`:
|
|
- If `$ARGUMENTS` is a number (e.g., `123`), use it directly
|
|
- If `$ARGUMENTS` is a URL (e.g., `https://github.com/owner/repo/issues/123`), extract the issue number from the path
|
|
|
|
Then fetch the issue:
|
|
|
|
```
|
|
gh issue view <issue-number> --json title,body,comments,labels,assignees
|
|
```
|
|
|
|
2. **Sanitize the issue content:**
|
|
|
|
Run the issue body through the sanitization script to remove HTML comments, invisible characters, and other artifacts:
|
|
|
|
```
|
|
printf '%s' "$ISSUE_BODY" | python3 .claude/skills/fix-issue/scripts/sanitize_issue_markdown.py
|
|
```
|
|
|
|
This removes:
|
|
- HTML comments (`<!-- ... -->`)
|
|
- Zero-width and invisible Unicode characters
|
|
- Excessive blank lines
|
|
- HTML details/summary tags (keeping content)
|
|
|
|
3. **Analyze the issue:**
|
|
- Understand what the issue is asking for
|
|
- Identify the type of work (bug fix, feature, refactor, etc.)
|
|
- Note any specific requirements or constraints mentioned
|
|
|
|
4. **Explore the codebase:**
|
|
- Search for relevant files and code related to the issue
|
|
- Understand the current implementation
|
|
- Identify what needs to change
|
|
- Look at existing tests to understand testing patterns used in the project
|
|
|
|
5. **Determine testing approach:**
|
|
|
|
Consider what kind of testing is appropriate for this change:
|
|
- **E2E test**: For user-facing features or complete user flows. Prefer this when the change involves UI interactions or would require mocking many dependencies to unit test.
|
|
- **Unit test**: For pure business logic, utility functions, or isolated components.
|
|
- **No new tests**: Only for trivial changes (typos, config tweaks, etc.)
|
|
|
|
Note: Per project guidelines, avoid writing many E2E tests for one feature. Prefer one or two E2E tests with broad coverage. If unsure, ask the user for guidance on testing approach.
|
|
|
|
**IMPORTANT for E2E tests:** You MUST run `npm run build` before running E2E tests. E2E tests run against the built application binary. If you make any changes to application code (anything outside of `e2e-tests/`), you MUST re-run `npm run build` before running E2E tests, otherwise you'll be testing the old version.
|
|
|
|
6. **Create a detailed plan:**
|
|
|
|
Write a plan that includes:
|
|
- **Summary**: Brief description of the issue and proposed solution
|
|
- **Files to modify**: List of files that will need changes
|
|
- **Implementation steps**: Ordered list of specific changes to make
|
|
- **Testing approach**: What tests to add (E2E, unit, or none) and why
|
|
- **Potential risks**: Any concerns or edge cases to consider
|
|
|
|
7. **Execute the plan:**
|
|
|
|
If the plan is straightforward with no ambiguities or open questions:
|
|
- Proceed directly to implementation without asking for approval
|
|
- Implement the plan step by step
|
|
- Run `/dyad:pr-push` when complete
|
|
|
|
If the plan has significant complexity, multiple valid approaches, or requires user input:
|
|
- Present the plan to the user and use `ExitPlanMode` to request approval
|
|
- After approval, implement the plan step by step
|
|
- Run `/dyad:pr-push` when complete
|