// Fix a GitHub issue end-to-end following yamada-ui conventions. Analyzes the issue, implements the fix, writes tests, and creates a PR.
Create a GitHub Issue for yamada-ui. Use when the user says they want to create an issue, report a bug, request a feature, report a documentation problem, or file an issue against yamada-ui.
Add or remove entries in .agents/references/pr-review-anti-patterns/. Use when the user wants to document a review miss from one or more merged PRs, or remove a stale anti-pattern entry.
Apply labels to GitHub issue. Analyze the issue, select appropriate labels, and apply the selected labels.
| name | fix-issue |
| description | Fix a GitHub issue end-to-end following yamada-ui conventions. Analyzes the issue, implements the fix, writes tests, and creates a PR. |
| argument-hint | <issue-number-or-url> |
| metadata | {"internal":true} |
You are a Yamada UI contributor. Your task is to fix a GitHub issue end-to-end: analyze it, implement the fix, write tests, and submit a PR.
Follow all conventions in AGENTS.md. This skill defines the workflow steps only — do not duplicate rules already documented there.
The issue reference is: $ARGUMENTS
Parse the input:
https://github.com/yamada-ui/yamada-ui/issues/123) → extract the numeric issue number#123 or bare 123 → strip # and use as-isValidate that the resolved value is a positive integer. If $ARGUMENTS is empty or not a valid issue reference, ask the user to provide the issue number or URL before proceeding.
The repository is always yamada-ui/yamada-ui.
Run gh issue view <number> --repo yamada-ui/yamada-ui to get the issue details.
Classify the issue type: fix, feat, docs, test, refactor, or chore.
Identify the affected package and component/area:
@yamada-ui/react → packages/react/src/components/<name>/ or packages/react/src/hooks/<name>/@yamada-ui/utils → packages/utils/src/@yamada-ui/cli → packages/cli/src/www (docs site) → www/contents/Summarize your analysis to the user before proceeding. If the issue is unclear or lacks enough information to act on, stop and explain what's missing.
Check for uncommitted changes first:
git status --short
If there are uncommitted changes, alert the user and do not proceed until they confirm how to handle them.
git switch main && git pull --ff-only origin main
Check for branch name conflicts before creating:
git branch --list "<type>/<scope>"
git switch -c <type>/<scope>
Map the issue to file locations. Read the relevant source files, tests, and stories before making any changes. Understand the existing code thoroughly.
Key patterns:
createComponent / withContextcreateSlotComponent / withContext (e.g., accordion, tabs, drawer, card)"use client" directive — omit only for pure render utilities with no hooks or browser APIs (e.g., <Show>, <For>)ui-<name> or ui-<name>__<slot> — do not set class names manuallyMake the minimal changes needed to address the issue. Follow existing code patterns.
Do not bundle multiple fixes. Only fix what the issue describes.
Tests are required for bug fixes and new features. Skip for docs-only changes.
Run targeted tests:
# For components:
pnpm react test:jsdom --run src/components/<name>/
# For hooks:
pnpm react test:jsdom --run src/hooks/<name>/
Follow the changeset rules in AGENTS.md. Name the file with a randomly-generated phrase (e.g., purple-foxes-smile.md), matching the project's existing convention. Check for name collisions.
If changes span multiple packages, list all affected packages in the changeset frontmatter.
Run git status --short to review all changes. Verify no unexpected files appear.
Stage only the specific files you changed. Commit with a conventional commit message per AGENTS.md.
Before pushing, ask the user for confirmation. Show them:
git diff main..HEAD --stat)Only proceed if the user confirms.
git push -u origin <branch-name>
Create the PR following .github/pull_request_template.md. Always include:
Closes #<issue-number>--base main flagAfter creating the PR, check CI status and inform the user if it fails.