
ce-dogfood
Hands-off, diff-scoped browser QA of the active branch: maps user flows, drives a real browser, autonomously fixes small breakages with regression tests and commits, judges experience against product personas, and writes a durable dogfood report. Manual invocation only.
- Installs
- 830
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-dogfood- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads ce-dogfood automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Dogfood
Act as a QA engineer who dogfoods the active branch end-to-end, autonomously, until it is genuinely ready.
Outcome: every user-visible change this branch introduced has been driven in a real browser along its whole journey, judged for correctness and for how it feels to the product's personas, with small breakages fixed, regression-tested, and committed. Done: every matrix scenario is Pass, Fixed, Skipped, or in a terminal Blocked state; the project's automated suite has been run once and its result recorded; and the report at <root>/dogfood-reports/<YYYY-MM-DD>-<branch-slug>-dogfood.md is finalized against its template and committed. A green matrix over a red suite finalizes as a not-ready verdict rather than a ready one. Chasing that suite green is not this run's job.
This is diff-scoped, not whole-app exploration. You test what this branch introduced or modified versus the trunk.
Read references/phases.md before Phase 0 (Scope) and follow it. It defines every phase in detail; the run cannot be executed correctly from the phase list below.
Boundaries
- Drive the browser exclusively through the
agent-browserCLI — never Chrome MCP tools (mcp__claude-in-chrome__*), another browser MCP, or a built-in browser-control tool, even when the platform offers one. Use the direct binary, nevernpx agent-browser(the direct binary uses the fast Rust client). - Never dogfood the trunk on a branch-name or blank target — there is no diff. A PR target always has a base, so it is always diffable even when its head branch is named
main. - A numeric target stays a PR identity through isolation and checkout — never collapse it to its head ref, whose name may itself be
main. - Never switch the primary checkout out from under the user. This skill decides only whether to offer isolation — no for a blank or current-branch target (you are already on it), yes for a PR or another named ref — and
ce-worktreehandles the mechanics and reports the verdict. On a declined offer, check the target out in place, confirming first if uncommitted changes would be disturbed. - Screenshots and other transient artifacts go to OS temp (
mktemp -d "${TMPDIR:-/tmp}/ce-dogfood-XXXXXX"), never the repo root; copy one in only to embed it in the report. - Auto-fix only what is small, well-understood, and low-risk. A change that needs an architectural or schema decision, alters product behavior or UX intent, spans many files, or has plausible competing solutions is escalated to the report's Decisions for a human section, never implemented to clear a matrix item.
Prerequisites
User-runnable invocation rendering. In prerequisite failures, default to /ce-setup and /ce-dogfood <original arguments>; use $ce-setup and $ce-dogfood <original arguments> only when the active host is Codex or explicitly documents dollar-prefixed skill invocation. On oh-my-pi (omp), use /skill:ce-setup and /skill:ce-dogfood <original arguments>. Render only each invocation as inline code and output one form only.
-
A local dev server you can start (
bin/dev,rails server,npm run dev, etc.). -
agent-browserinstalled. Check:command -v agent-browser >/dev/null 2>&1 && echo "Ready" || echo "NOT INSTALLED"If not installed, stop and tell the user to install
agent-browser: print the renderedce-setupinvocation for the current install command, followed by the renderedce-dogfood <original arguments>invocation to retry. This workflow cannot function without it.
Artifact Root
Reports live under <root>/dogfood-reports/ and personas under <root>/personas/. Resolve <root> the first time you compose any <root>/ path, whether you are reading or writing, and never before. A run that composes none skips it.
Resolve the CE artifact root <root> before composing any artifact path.
- Read
docs_rootfrom<repo-root>/.compound-engineering/config.yamlonly (<repo-root>=git rev-parse --show-toplevel). Do not read it fromconfig.local.yaml. Unset -><root>isdocs, exactly as before. - Validate a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under
.git/. Otherwise stop with an error namingdocs_rootand the value -- never fall back todocs. - Use
<root>as the sole artifact location: create it if absent, compose each path as<root>/<subdir>with this skill's own subdirectory, and never also readdocs.
Delegation
ce-dogfood is an orchestrator: prefer an existing CE skill over re-deriving its behavior. Isolate a PR or named-branch target with ce-worktree; take a non-obvious root cause to ce-debug; commit each fix with ce-commit; capture a reusable lesson with ce-compound.
Compound Packs
The repo's declared Compound Packs supply personas and criteria. A pack rule that describes a user is a persona the flows are walked as; one that prescribes how the product must look or behave is a criterion each scenario it reaches is judged against, and a contradiction is a failure that enters the fix loop with its (pack: <id>, <path within the pack>) citation. A contradiction the branch intends is a decision for a human about the rule, not a fix. Judgments that generalize go back to the packs through ce-compound; this skill never writes a pack. references/phases.md defines how packs are applied.
Phase order
Scope -> analyze the diff -> map the flows -> derive the matrix -> serve -> execute -> fix loop -> report. The order is the invariant: the flow model precedes the matrix, and the matrix precedes any browser work. Each phase's conditions are in references/phases.md; read it before Phase 0 (Scope) rather than reconstructing a phase from this line. Work one scenario at a time, judged for correctness and for how it feels to each persona. A fix is not done until a regression test fails before it and passes after, or the report says why no automated test was meaningful.
Checkpoint, not a final write. Create the report from references/dogfood-report-template.md as soon as the matrix exists, with every scenario at Pending, and update it after each scenario is judged and each fix is committed. <branch-slug> is the branch name lowercased, with every run of non-alphanumeric characters — slashes included — collapsed to one -. Find a prior run by globbing <root>/dogfood-reports/*-<branch-slug>-dogfood.md. The task list is session-scoped, but the report on disk is what a later run or a teammate resumes from, so an interrupted run must leave a template-shaped checkpoint rather than a bare matrix.
Terminal states. Blocked (needs human verify) (a step that needs an outside interaction, such as OAuth, real email, payments, or SMS, and cannot be driven headlessly) and Blocked (human decision) (a fix too big to make autonomously) both wait on a person, and each ends that scenario, not the run: continue the rest of the matrix, and never silently re-queue a blocked scenario, on this run or on resume. How a person is reached differs per state, and the phase that sets the state says which.
FAQ
What does the ce-dogfood skill do?
Hands-off, diff-scoped browser QA of the active branch: maps user flows, drives a real browser, autonomously fixes small breakages with regression tests and commits, judges experience against product personas, and writes a durable dogfood report. Manual invocation only.
How do I install ce-dogfood?
Run npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-dogfood in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/ce-dogfood/ (personal) or .claude/skills/ce-dogfood/ (project).
Which AI agents can use ce-dogfood?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is ce-dogfood safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains ce-dogfood?
It is published by everyinc in everyinc/compound-engineering-plugin. It has 830 recorded installs.
More from everyinc/compound-engineering-plugin
ce-brainstorm
everyinc/compound-engineering-plugin
Explore vague or ambitious ideas into a right-sized requirements-only unified plan. Use when the user wants to brainstorm or scope what to build. Not for executing already-specified work. Use ce-pov for a verdict on adopting a named external technology.
ce-code-review
everyinc/compound-engineering-plugin
Review a named diff or PR for bugs, regressions, tests, and standards. Use when asked to review code or when a shipping skill needs a review receipt. Use when asked to apply this review's findings locally. Use ce-resolve-pr-feedback for feedback already left on a PR.
ce-plan
everyinc/compound-engineering-plugin
Create structured plans for multi-step work, including software and non-software tasks. Use when asked to plan, break down implementation, plan from requirements, or deepen an existing plan; prefer ce-brainstorm for exploratory framing.
ce-compound
everyinc/compound-engineering-plugin
Document a solved problem as a durable repo learning. Use when verified work produced non-obvious reasoning absent from its final code, tests, or existing docs; avoid routine fixes whose artifacts already explain the lesson.
ce-doc-review
everyinc/compound-engineering-plugin
Review requirements, plans, or specs with role-specific lenses. Use when the user wants to improve an existing planning document.
ce-work
everyinc/compound-engineering-plugin
Execute a plan or concrete work prompt end-to-end. Use when implementing from a plan document, a spec path, or a clear build request; use ce-debug for open-ended bugs. Use when an outer orchestrator needs implementation and local verification only, without the shipping tail.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work