New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Bug Finder for daisyUI

by saadeghi in saadeghi/daisyui

Investigates suspected bugs in the daisyUI monorepo through read-only analysis, then writes a decision-ready fix plan in tmp/bugs without changing any product code.

MITAuto-check passedDevelopment

Install Bug Finder for daisyUI

skills CLI
$ npx skills add saadeghi/daisyui --skill find-bugs -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install saadeghi/daisyui find-bugs --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/saadeghi/daisyui.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/find-bugs .claude/skills/find-bugs && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
find-bugs
GitHub stars
43k
Token cost
~2.3k tokens
SKILL.md length
1,221 words
Files
4 (incl. references)
Skills in repo
7
Repo updated
First seen
Licence
MIT

At a glance

Investigates suspected bugs in the daisyUI monorepo through read-only analysis, then writes a decision-ready fix plan in tmp/bugs without changing any product code.

  • Works in 7 steps: Establish a clean evidence baseline → Search from behavior toward ownership → Reproduce and prove product impact → …
  • Reproducing a reported daisyUI component defect and proving its impact
  • SKILL.md covers Required agent routing, Non-negotiable boundary, Load the relevant guidance and Investigation workflow, plus 1 more section
  • Calls git and rg

What it does

Evidence-backed product bugs are the only output here, and the result is a plan you can approve or reject rather than a fix. The agent reproduces the defect, proves its impact, finds the root cause and the boundary within which it can be isolated, weighs non-code options, and writes the plan as a markdown file under tmp/bugs. It also supports proactive bug hunts across packages/daisyui and packages/docs.

A strict boundary keeps the repository read-only apart from those plan files: no edits to source, tests, snapshots, config, dependencies or Git metadata, no formatters or installers, no branches, commits or PRs, and no patch or replacement code, only a prose description of the intended behavior. Disposable reproductions and screenshots go in an operating system temp directory, and anything that would write build output runs on a temporary copy or is recorded as pending.

Work is routed to a custom agent named bug_finder, and the skill stops with a report if that agent is unavailable. Before investigating, the agent reads the packages and target package AGENTS.md files and the matching reference notes for daisyUI, the docs site and the bug plan format.

When your agent uses it

  • Reproducing a reported daisyUI component defect and proving its impact
  • Searching packages/daisyui or packages/docs for bugs on your own initiative
  • Finding the root cause of a bug without changing any code
  • Preparing a bug-fix plan to approve before implementation starts

Example prompts

  • “A user says the modal backdrop does not close on click, so reproduce it and write the bug plan.”
  • “Scan packages/docs for broken examples and report only the confirmed bugs.”
  • “Find the root cause of the dropdown positioning issue without touching the code.”

Requirements

  • A checkout of the daisyUI monorepo
  • A custom agent named bug_finder

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Establish a clean evidence baseline
  2. Search from behavior toward ownership
  3. Reproduce and prove product impact
  4. Establish root cause and isolation
  5. Develop solution options without changing code
  6. Apply the plan readiness gate
  7. Group findings and write plans

What it can do on your machine

Read from SKILL.md and the folder at commit 9adbeaa. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • rg

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Bug Finder for daisyUI loads about 2.3k tokens when it runs, and up to ~3.8k if it reads all its reference files. Until then it costs about 126 tokens; SKILL.md has 1,221 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~126
When it runs · the whole SKILL.md, loaded when a task matches
~2.3k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~3.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from saadeghi/daisyui at commit 9adbeaa, republished under its MIT licence (© saadeghi). 1,221 words, ~2,332 tokens.

Download SKILL.mdSave it as .claude/skills/find-bugs/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
find-bugs
description
Investigate reported or suspected bugs in this daisyUI monorepo, including proactive bug searches in packages/daisyui and packages/docs. Use when Codex must reproduce a defect, prove product impact, identify its root cause and isolation boundary, evaluate non-code solution options, or prepare a decision-ready bug-fix plan in tmp/bugs/. This skill performs read-only source analysis and verification; it never implements a fix, edits product source or tests, changes dependencies, or commits.
metadata.internal
true

Bug Finder

Find only evidence-backed product bugs and leave the user with a plan they can approve or reject. Do not implement the plan.

Required agent routing

  • If you are not the bug_finder custom agent, delegate the complete task to bug_finder and wait for its result. Tell the agent to use this skill. Do not investigate the bug or write the plan in the current agent.
  • If you are the bug_finder custom agent, perform this workflow directly. Do not delegate it again.
  • If bug_finder is not available, stop and report the problem. Do not run this workflow with a different agent or model.

Non-negotiable boundary

  • Treat the repository as read-only except for the final tmp/bugs/*.md plan files.
  • Do not edit source, tests, snapshots, fixtures, generated package files, build output, config, translations, dependencies, lockfiles, or Git metadata.
  • Do not create a temporary reproduction inside packages/. Put disposable fixtures, logs, and screenshots in an OS temporary directory.
  • Do not run formatters, auto-fixers, write-mode generators, dependency installers, release commands, or publishing commands.
  • Do not create a branch, commit, PR, issue, comment, or other external side effect.
  • Do not provide a patch or replacement code. Describe the intended behavior and future change boundary in prose.
  • Stop after writing the plan. The user decides whether implementation should happen.

Normal tests, local servers, and read-only diagnostics are allowed. Prefer commands that do not write into the repository. Before running any command, determine whether it creates build output or generated files. If it does, use an OS-temporary copy or a non-writing alternative; otherwise record that verification as pending. Never overwrite or clean up a user's files.

Load the relevant guidance

  1. Read packages/AGENTS.md.
  2. Read the target package's AGENTS.md.
  3. Read references/daisyui.md for packages/daisyui.
  4. Read references/docs.md for packages/docs.
  5. Read both package references when ownership is unclear or the defect crosses the package boundary.
  6. Read references/bug-plan.md before creating or updating a plan.

Re-read current files rather than assuming this skill's repository map is still complete.

Investigation workflow

1. Establish a clean evidence baseline
  • Record git status --short without changing it. Treat every pre-existing change as user-owned.
  • Capture the exact report, affected URL/class/API, environment, configuration, browser/runtime, viewport, theme, language, and expected behavior when known.
  • Define the product claim to test before searching broadly.
  • If no bug was supplied, scope the search to the requested package. If neither package was specified, inspect both without turning code smells or missing features into bugs.
2. Search from behavior toward ownership
  • Use rg --files and rg first. Follow the failing route, selector, class, option, data field, or message into its callers, transformations, and generated/product-facing output.
  • Inspect nearby tests, related components, shared helpers/tokens, build steps, documentation, and recent history when it can explain intent.
  • For proactive searches, prioritize boundary conditions, conflicting states, error and empty paths, SSR/client differences, theme and direction variants, browser-specific behavior, configuration combinations, stale assumptions, and gaps between source and shipped output.
  • Treat TODOs, suspicious code, style preferences, performance opportunities, and absent tests as leads only. They are not bugs without an observable broken product contract.
3. Reproduce and prove product impact

A finding is confirmed only when all of these are true:

  1. State the expected behavior from a reliable source: existing docs, tests, API contract, accessibility/platform behavior, or a clearly established product invariant.
  2. Reproduce the actual behavior on the current checkout with exact steps and a stable failure signal. Repeat it and include a nearby passing control when useful.
  3. Exercise the user-facing path, not only an isolated source fragment. Use the built package, actual docs route, rendered browser state, or public function/configuration involved.
  4. Trace the observed failure back to current source and explain the causal chain.
  5. Rule out stale generated output, unsupported configuration, misuse, external service failure, browser-only flakiness, and intended behavior.

Use the narrowest existing automated test or diagnostic first, then broader verification in proportion to the risk. For visual or interactive behavior, inspect the rendered page, computed state, console, and network as relevant. Never change source merely to make a reproduction.

Do not write a plan for an unverified suspicion. Report what is missing and stop.

Show full SKILL.md (535 more words)Show less
4. Establish root cause and isolation

Identify the smallest source unit that explains every reproduced symptom. Distinguish root cause from the file where the symptom becomes visible.

Map:

  • direct callers/consumers and the source-to-product path;
  • shared selectors, tokens, helpers, data, layouts, translations, and build transforms;
  • configurations, states, routes, themes, languages, directions, and browsers affected;
  • adjacent behavior that must remain unchanged;
  • existing coverage and the exact future regression-test seam.

Call the bug independently fixable only when:

  • one bounded behavioral change addresses the root cause;
  • the public behavior and acceptance criteria are unambiguous;
  • the likely source files and generated downstream outputs are known;
  • unrelated behavior can be protected with focused and broader checks;
  • no dependency addition, broad redesign, unrelated refactor, or speculative cleanup is required.

If isolation cannot be demonstrated, do not present the plan as ready. State the unresolved coupling or product decision needed and stop without creating a decision-ready plan.

5. Develop solution options without changing code
  • Derive solutions from the proven root cause, repository conventions, and smallest safe change boundary.
  • Describe each option's behavior, likely source locations, compatibility, test seam, risks, and effect on generated output. Do not include code or a patch.
  • Prefer the smallest option that preserves public API/class behavior and avoids added bytes, dependencies, specificity, duplication, or new cross-package coupling.
  • Include alternatives when genuinely viable. Explain why the recommendation is safer and why rejected options are broader, brittle, or fail a constraint.
  • Do not test a hypothetical fix by editing source. Specify how an approved implementation would prove the fix and detect regressions.
6. Apply the plan readiness gate

Create a plan only after answering yes to every item:

  • Is the behavior reproducible on the current checkout?
  • Is product impact directly observed?
  • Is expected behavior supported by evidence?
  • Is the root cause evidenced rather than guessed?
  • Is a bounded fix feasible in isolation?
  • Are affected and protected behaviors listed?
  • Is the recommended solution precise enough to implement without rediscovery?
  • Are regression and product-level verification steps defined?
  • Are risks, unknowns, and acceptance criteria explicit?
7. Group findings and write plans
  • Write plans only under tmp/bugs/.
  • Use one Markdown file per independent bug.
  • Combine multiple symptoms or reports only when evidence shows one root cause and the same atomic source change fixes all of them. List every symptom and reproduction in that shared plan.
  • Use separate files when findings require different source changes, even if they affect the same component or were found together.
  • Reuse and update an existing plan when it describes the same root cause; do not create a duplicate.
  • Treat these files as bug reports, even though this workflow calls them plans. Each file must have YAML frontmatter with the bug, issue, or PR status. A new local bug uses status: open.
  • Use the status rules, filename rules, and full structure in references/bug-plan.md.
  • Create tmp/bugs/ only when at least one finding passes the readiness gate.
  • After writing, re-open every plan. Verify its frontmatter status and each factual claim against evidence. Verify that no plan contains implementation code.

Handoff

Report the created or updated plan path, the verified product impact, and any verification that remains pending. Explicitly state that no fix was implemented. End the task and wait for the user's decision.

© saadeghi, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (references) in .agents/skills/find-bugs of saadeghi/daisyui.

  • SKILL.md
  • references/bug-plan.md
  • references/daisyui.md
  • references/docs.md

Open the folder on GitHubat commit 9adbeaa

Compare with similar skills

Bug Finder for daisyUI next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Bug Finder for daisyUI compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Bug Finder for daisyUI this skillsaadeghi/daisyui43k—~2.3kAutomated safety check: PassMIT
Frontend Browser Debugginglobehub/lobehub83k—~1.7kAutomated safety check: PassCustom licence
Debugging Codemajiayu000/claude-skill-registry6662 repos~3.1kAutomated safety check: PassMIT
OpenLogi macOS Permissions TriageAprilNEA/OpenLogi23k—~2.5kAutomated safety check: NotesApache-2.0
Root Cause Debugginggarrytan/gstack136k—~1.4kAutomated safety check: PassMIT
Graph-Based Bug Tracingtirth8205/code-review-graph32k1 repos~287Automated safety check: PassMIT

Similar skills

  • Frontend Browser Debugging

    lobehub/lobehub

    Traces intermittent UI, stale state, ordering and navigation bugs through a browser to find the first boundary where correct data becomes wrong.

    83k GitHub stars~1.7k tokensUpdated today
    DevelopmentAuto-check passed

  • Debugging Code

    majiayu000/claude-skill-registry

    Interactively debug source code — set breakpoints, step through execution line by line, inspect live variable state, evaluate expressions against the running program, and navigate the call stack to…

    666 GitHub starsUsed in 2 repos~3.1k tokens
    DevelopmentAuto-check passed

  • OpenLogi macOS Permissions Triage

    AprilNEA/OpenLogi

    Decides whether an OpenLogi device problem on macOS is a privacy-permission (TCC) problem, using agent log lines, and says which identity needs which grant.

    23k GitHub stars~2.5k tokensUpdated 4 days ago
    DevelopmentAuto-check: notes

  • Root Cause Debugging

    garrytan/gstack

    Investigates bugs, errors and stack traces in phases and requires a root-cause hypothesis to be confirmed before any fix is written.

    136k GitHub stars~1.4k tokensUpdated today
    DevelopmentAuto-check passed

  • Graph-Based Bug Tracing

    tirth8205/code-review-graph

    Traces a bug through a code knowledge graph, following callers, callees and execution flow before opening source files, within a small token budget.

    32k GitHub starsUsed in 1 repo~287 tokens
    DevelopmentAuto-check passed

  • Systematic Debugging

    ChrisWiles/claude-code-showcase

    Applies a four-phase debugging routine that finds the root cause of a bug or failing test before any fix is written.

    6.1k GitHub starsUsed in 3 repos~1.2k tokens
    DevelopmentAuto-check passed

More from saadeghi/daisyui

  • Pull Request Reviewer for daisyUI

    saadeghi/daisyui

    Reviews open pull requests in the daisyUI repository using read-only GitHub data and isolated base-versus-PR checks, then writes a merge verdict report.

    43k GitHub stars~766 tokensUpdated 8 days ago
    Auto-check passed

  • DaisyUI Component Library

    saadeghi/daisyui

    Official daisyUI skill for Tailwind CSS projects, routing to install, usage, configuration, color and per-component guides before writing any HTML or JSX with its classes.

    43k GitHub stars~1.3k tokensUpdated 8 days ago
    Auto-check passed

  • DaisyUI 5 Color Rules

    saadeghi/daisyui

    Rules for using daisyUI 5's semantic color names, such as primary and base-100, so interfaces stay readable across themes.

    43k GitHub stars~1.7k tokensUpdated 8 days ago
    Auto-check passed

  • Styling Rules for daisyUI 5

    saadeghi/daisyui

    Rules for styling HTML with daisyUI 5 class names first, falling back to Tailwind utilities only when needed, and avoiding unnecessary custom CSS or default color variants.

    43k GitHub stars~846 tokensUpdated 8 days ago
    Auto-check passed

  • daisyUI 5 Installation

    saadeghi/daisyui

    Installation instructions for daisyUI 5 with Tailwind CSS 4: the npm setup, CSS plugin lines, CDN usage and pointers to framework-specific guides.

    43k GitHub stars~967 tokensUpdated 8 days ago
    Auto-check passed

  • daisyUI 5 Configuration

    saadeghi/daisyui

    Configuration options for daisyUI 5

    43k GitHub stars~352 tokensUpdated 8 days ago
    Auto-check passed

Works with

Categories

Questions about Bug Finder for daisyUI

What does Bug Finder for daisyUI do?

Investigates suspected bugs in the daisyUI monorepo through read-only analysis, then writes a decision-ready fix plan in tmp/bugs without changing any product code. Evidence-backed product bugs are the only output here, and the result is a plan you can approve or reject rather than a fix. The agent reproduces the defect, proves its impact, finds the root cause and the boundary within which it can be isolated, weighs non-code options, and writes the plan as a markdown file under tmp/bugs.

When should I use Bug Finder for daisyUI?

Bug Finder for daisyUI fits situations like: reproducing a reported daisyUI component defect and proving its impact; searching packages/daisyui or packages/docs for bugs on your own initiative; finding the root cause of a bug without changing any code; preparing a bug-fix plan to approve before implementation starts.

How do I install Bug Finder for daisyUI in Claude Code?

Run `npx skills add saadeghi/daisyui --skill find-bugs -a claude-code`. Or copy the skill folder (.agents/skills/find-bugs in saadeghi/daisyui) into .claude/skills/find-bugs in your project. Claude Code loads it when a task matches its description.

How do I install Bug Finder for daisyUI in Codex?

Run `npx skills add saadeghi/daisyui --skill find-bugs -a codex`. Or copy the skill folder (.agents/skills/find-bugs in saadeghi/daisyui) into .agents/skills/find-bugs in your project. Codex loads it when a task matches its description.

Can I use Bug Finder for daisyUI in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add saadeghi/daisyui --skill find-bugs -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/find-bugs, .gemini/skills/find-bugs, .github/skills/find-bugs and .opencode/skills/find-bugs in your project.

What does Bug Finder for daisyUI need to run?

Going by SKILL.md and its folder, Bug Finder for daisyUI needs the command-line tools its instructions call (git and rg). Our summary lists: A checkout of the daisyUI monorepo; A custom agent named bug_finder.

Does Bug Finder for daisyUI access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Bug Finder for daisyUI safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Bug Finder for daisyUI use?

Bug Finder for daisyUI is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Bug Finder for daisyUI use?

About 2.3k tokens (SKILL.md is roughly 9.3k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.5k tokens, read only when the agent opens those files.

What are the alternatives to Bug Finder for daisyUI?

Skills that share tags, products or a category with Bug Finder for daisyUI: Frontend Browser Debugging (lobehub/lobehub, 83k stars), Debugging Code (majiayu000/claude-skill-registry, 666 stars), OpenLogi macOS Permissions Triage (AprilNEA/OpenLogi, 23k stars) and Root Cause Debugging (garrytan/gstack, 136k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Bug Finder for daisyUI?

saadeghi (a GitHub user) maintains it in saadeghi/daisyui, which has 42,555 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on September 30, 2026.

Source: saadeghi/daisyui on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.