agentleFS
wundercorpwundercorp/loki/skills/software-development/dogfood/SKILL.md

dogfood

Skill28 starsChanged 2 months agoMITView on GitHub

Exploratory QA of web apps: find bugs, evidence, reports.

78 other projects use a version of this, 38 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use dep-refs, feature-boundary-planner and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • betacatslingSkill

    dep-refs

    Use when needs to inspect TypeScript export references in the z-code workspace, list exports from a file, verify whether an export is unused before deletion, investigate who imports a symbol during refactors, or combine pnpm knip unused-export results with pnpm dep:refs symbol-level reference tracing.

    Also in 5 projects that use this

  • betacatslingSkill

    feature-boundary-planner

    Map a ZCode behavior change to current UI surfaces, state owners, protocol commands, persistence, and validation. Use for impact analysis, product-boundary planning, or an implementation handoff grounded in the checked-out source.

    Also in 5 projects that use this

  • lir-navcooSkill

    yuanbao

    Yuanbao (元宝) groups: @mention users, query info/members.

    Also in 18 projects that use this

  • Cartograf666Skill

    architecture-governance

    Bootstrap, document, enforce, and review a project's architecture through layer responsibilities, dependency direction, architecture manifests, legacy baselines, Change Envelopes, cross-layer approval policy, and deterministic architecture checks. Use when starting a project, auditing an existing codebase, planning cross-layer work, preventing architecture erosion, reviewing structural changes, or deciding whether implementation may expand into another layer.

    Also in 5 projects that use this

  • john-data-chenSkill

    touchdesigner-mcp

    Control a running TouchDesigner instance via twozero MCP — create operators, set parameters, wire connections, execute Python, build real-time visuals. 36 native tools.

    Also in 7 projects that use this

  • math-incSkill

    minecraft-modpack-server

    Set up a modded Minecraft server from a CurseForge/Modrinth server pack zip. Covers NeoForge/Forge install, Java version, JVM tuning, firewall, LAN config, backups, and launch scripts.

    Also in 5 projects that use this

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 4 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 78 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow this 5-phase systematic workflow:

    line 34
  2. Distinctive:

    Create the output directory structure:

    line 38
  3. Distinctive:

    Do this after every navigation and after every significant interaction.

    line 70
  4. Very specific:

    Test keyboard navigation: browser_press(key="Tab"), browser_press(key="Enter")

    line 81
  5. Distinctive:

    Test form validation with invalid inputs

    line 83
  6. Very specific:

    Use annotate=true with browser_vision: when you need to reason about interactive element positions or when the snapshot refs are …

    line 158
  7. Very specific:

    When reporting screenshots to the user, include MEDIA:<screenshot_path> so they can see the evidence inline.

    line 164

“Common” is measured: kept by at least 6 in 10 of the 78 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Dogfood: Systematic Web Application QA Testing

Overview

This skill guides you through systematic exploratory QA testing of web applications using the browser toolset. You will navigate the application, interact with elements, capture evidence of issues, and produce a structured bug report.

Prerequisites

  • Browser toolset must be available (browser_navigate, browser_snapshot, browser_click, browser_type, browser_vision, browser_console, browser_scroll, browser_back, browser_press)
  • A target URL and testing scope from the user

Inputs

The user provides:

  1. Target URL — the entry point for testing
  2. Scope — what areas/features to focus on (or "full site" for comprehensive testing)
  3. Output directory (optional) — where to save screenshots and the report (default: ./dogfood-output)

Workflow

Follow this 5-phase systematic workflow:

Phase 1: Plan

  1. Create the output directory structure:
    {output_dir}/
    ├── screenshots/       # Evidence screenshots
    └── report.md          # Final report (generated in Phase 5)
  2. Identify the testing scope based on user input.
  3. Build a rough sitemap by planning which pages and features to test:
    • Landing/home page
    • Navigation links (header, footer, sidebar)
    • Key user flows (sign up, login, search, checkout, etc.)
    • Forms and interactive elements
    • Edge cases (empty states, error pages, 404s)

Phase 2: Explore

For each page or feature in your plan:

  1. Navigate to the page:
    browser_navigate(url="https://example.com/page")
  2. Take a snapshot to understand the DOM structure:
    browser_snapshot()
  3. Check the console for JavaScript errors:
    browser_console(clear=true)
    Do this after every navigation and after every significant interaction. Silent JS errors are high-value findings.
  4. Take an annotated screenshot to visually assess the page and identify interactive elements:
    browser_vision(question="Describe the page layout, identify any visual issues, broken elements, or accessibility concerns", annotate=true)
    The annotate=true flag overlays numbered [N] labels on interactive elements. Each [N] maps to ref @eN for subsequent browser commands.
  5. Test interactive elements systematically:
    • Click buttons and links: browser_click(ref="@eN")
    • Fill forms: browser_type(ref="@eN", text="test input")
    • Test keyboard navigation: browser_press(key="Tab"), browser_press(key="Enter")
    • Scroll through content: browser_scroll(direction="down")
    • Test form validation with invalid inputs
    • Test empty submissions
  6. After each interaction, check for:
    • Console errors: browser_console()
    • Visual changes: browser_vision(question="What changed after the interaction?")
    • Expected vs actual behavior

Phase 3: Collect Evidence

For every issue found:

  1. Take a screenshot showing the issue:
    browser_vision(question="Capture and describe the issue visible on this page", annotate=false)
    Save the screenshot_path from the response — you will reference it in the report.
  2. Record the details:
    • URL where the issue occurs
    • Steps to reproduce
    • Expected behavior
    • Actual behavior
    • Console errors (if any)
    • Screenshot path
  3. Classify the issue using the issue taxonomy (see references/issue-taxonomy.md):
    • Severity: Critical / High / Medium / Low
    • Category: Functional / Visual / Accessibility / Console / UX / Content

Phase 4: Categorize

  1. Review all collected issues.
  2. De-duplicate — merge issues that are the same bug manifesting in different places.
  3. Assign final severity and category to each issue.
  4. Sort by severity (Critical first, then High, Medium, Low).
  5. Count issues by severity and category for the executive summary.

Phase 5: Report

Generate the final report using the template at templates/dogfood-report-template.md.

The report must include:

  1. Executive summary with total issue count, breakdown by severity, and testing scope
  2. Per-issue sections with:
    • Issue number and title
    • Severity and category badges
    • URL where observed
    • Description of the issue
    • Steps to reproduce
    • Expected vs actual behavior
    • Screenshot references (use MEDIA:<screenshot_path> for inline images)
    • Console errors if relevant
  3. Summary table of all issues
  4. Testing notes — what was tested, what was not, any blockers

Save the report to {output_dir}/report.md.

Tools Reference

ToolPurpose
browser_navigateGo to a URL
browser_snapshotGet DOM text snapshot (accessibility tree)
browser_clickClick an element by ref (@eN) or text
browser_typeType into an input field
browser_scrollScroll up/down on the page
browser_backGo back in browser history
browser_pressPress a keyboard key
browser_visionScreenshot + AI analysis; use annotate=true for element labels
browser_consoleGet JS console output and errors

Tips

  • Always check browser_console() after navigating and after significant interactions. Silent JS errors are among the most valuable findings.
  • Use annotate=true with browser_vision when you need to reason about interactive element positions or when the snapshot refs are unclear.
  • Test with both valid and invalid inputs — form validation bugs are common.
  • Scroll through long pages — content below the fold may have rendering issues.
  • Test navigation flows — click through multi-step processes end-to-end.
  • Check responsive behavior by noting any layout issues visible in screenshots.
  • Don't forget edge cases: empty states, very long text, special characters, rapid clicking.
  • When reporting screenshots to the user, include MEDIA:<screenshot_path> so they can see the evidence inline.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.