Skip to content
cccskills
FreePublished on GitHub

ce-dogfood

Test user journeys affected by a branch’s changes in a real browser. Check correctness and the experience for intended users, fix small defects with regression tests, and commit fixes alongside a report documenting results and unresolved decisions.

OriginalShow the original description

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.

See how to install

Good for

  • Check user-facing changes before a PR is merged
  • Test complete user journeys affected by a branch
  • Fix small defects and add regression tests
  • Record test results and decisions needing human input

Files included (6)

  • SKILL.md7.5 KB
  • agents/openai.yaml43 B
  • references/dogfood-report-template.md5.3 KB
  • references/phases.md20.7 KB
  • references/test-matrix-taxonomy.md3.8 KB
  • scripts/packs-resolve.py30.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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-browser CLI — 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, never npx 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-worktree handles 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-browser installed. 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 rendered ce-setup invocation for the current install command, followed by the rendered ce-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.

<!-- ce-docs-root:start -->

Resolve the CE artifact root <root> before composing any artifact path.

  • Read docs_root from <repo-root>/.compound-engineering/config.yaml only (<repo-root> = git rev-parse --show-toplevel). Do not read it from config.local.yaml. Unset -> <root> is docs, 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 naming docs_root and the value -- never fall back to docs.
  • 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 read docs.
<!-- ce-docs-root:end -->

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

ce-babysit-pr

FreeSummary

Monitor an open GitHub pull request over time, respond to review feedback, and address automated check failures. Apply and push fixes, then report whether it appears ready to merge or what still blocks progress.

  • Monitoring a pull request until it appears ready to merge
  • Addressing review feedback as it arrives
  • Handling automated check failures during review
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

ce-bakeoff

FreeSummary

Develop independent solutions to a defined problem, compare them against shared requirements, and combine useful contributions into a coherent recommendation. An independent assessment and evidence checks support the selection, while unresolved tradeoffs and verification needs remain explicit.

  • Comparing concrete solutions to a defined problem
  • Developing rough options before choosing an approach
  • Comparing architectural or product proposals
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

ce-brainstorm

FreeSummary

Turn a vague feature idea into clear requirements through dialogue. Define what to build, its scope, and success criteria, then capture the result in a short chat summary or a requirements document ready for implementation planning.

  • Clarifying a vague feature idea
  • Narrowing the scope of an ambitious improvement
  • Documenting requirements before implementation planning
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

ce-code-review

FreeSummary

Review code changes or a pull request for bugs, effects on existing behavior, test gaps, and project standards. Receive findings supported by the code and a clear account of review coverage, with local fixes available when explicitly requested.

  • Reviewing a pull request before release
  • Checking changes for bugs and test gaps
  • Applying review findings locally
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

ce-commit

FreeSummary

Save working changes as local Git commits with messages that explain the outcome. Follow the project's commit style, select files explicitly, and split clearly separate changes into a few logical commits when appropriate.

  • Saving completed work as a local commit
  • Writing messages that explain the outcome
  • Separating unrelated changes into commits
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

Commit and push code changes, then open a pull request with a clear title and description. You can also draft or update PR descriptions and hand published requests to the follow-up monitoring workflow.

  • Committing changes and opening a pull request
  • Drafting only a PR title and description
  • Updating an existing PR description
EveryInc/compound-engineering-plugin25.6KUpdated Oct 19, 2026

See all skills by EveryInc

Report a problem with this skill