Skip to content
cccskills
FreePublished on GitHub

diagnose-a-red-run

Investigate failed tests, type checks, builds, and CI jobs by recording exact evidence and repeating checks in a clean comparison environment. Use the results to distinguish existing failures, newly introduced problems, environment issues, and unresolved cases.

OriginalShow the original description

Test is red, typecheck failed, CI job failed, flaky, timed out, was this already broken. Use to classify any failing check before changing code or calling it pre-existing.

See how to install

Good for

  • Checking whether a failing test was already broken
  • Investigating a failure that appears only in CI
  • Distinguishing timeouts from environment problems
  • Reviewing evidence before labeling a test flaky

Files included (1)

  • SKILL.md3.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Skill: Diagnose a Red Run

Capture the branch failure

  • Record the exact command, commit SHA, exit code, and passed/failed/skipped counts. Quote the first actionable failure; do not summarize it away.
  • Classify the check: testkit spec, typecheck, build, lint, or CI job.

Run a clean control

Never call a failure pre-existing from memory or from a modified checkout.

git fetch origin dev
git worktree add /tmp/openwork-dev-control --detach origin/dev
# In that clean worktree, prepare the same prerequisites and run the exact command.
git worktree remove /tmp/openwork-dev-control
  • Keep tool versions, environment, services, flags, and secrets equivalent.
  • Quote the control command, origin/dev SHA, exit code, counts, and matching failure text.
  • Classify as pre-existing only when the clean control demonstrates the same failure. Otherwise classify it as introduced, environment-specific, or unresolved. A non-reproducing control is not proof of flakiness; repeat both sides before using that label.

Classify by signature

  • Unit/type/CI-only failure: inspect the first failing job and run its exact command locally before broadening scope.
  • Vision disagreement on identical pixels: claim wording or product ambiguity. Make the product unambiguous or make the claim factual.
  • Timeout with an On-screen dump: read it. It names the state; for example, /session can expose a steer-back race.
  • Auth 403 INVALID_ORIGIN: inspect Den trusted origins.
  • Authorize URL points at the real provider: Den booted without mock env.
  • Teardown 403 fresh_auth_required: the session aged; a freshSession retry exists.

Red core journey (pr-proof.yml "Core journey")

  • Open the job summary's "Freestyle world" table first: it names the path (reused, fast, full build) and its reason.
  • World preparation failed: read the "builder log" group in the job log; it is the VM's own build or boot output. A fast path that fails falls back to a full build by itself, so a red here is a real build or boot failure.
  • Journey failed: the timeout prints the on-screen state. Reproduce with the run-tests core journey command on the same pushed commit.

Environment forensics

  • Kill by port, not process name. tsx watch can orphan its Node child, which keeps the port while /health lies.
  • EADDRINUSE in logs while health returns 200 means a zombie survived.
  • Electron zombies can respawn from a root process; kill the process group.
  • Leaked state pollutes organizations; delete leftover connectors between runs.

For a testkit failure, read the test run's last unvalidated artifacts before touching code. Name the verdict as CI posted it: Passed only when every claim has an observable assertion; a skip or a pending looks() judgment is Incomplete, never Passed. Red evidence is useful evidence; never soften or omit it.

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

add-a-feature

FreeSummary

Manage OpenWork feature releases with feature flags, switches that control access to new behavior. Register features before coding, release them by organization and deployment, prepare a global shutdown option, and remove temporary flags after rollout.

  • Registering a feature before implementation
  • Releasing a feature to selected organizations
  • Separating cloud and self-hosted availability
different-ai/openwork24.2KUpdated Oct 18, 2026

Connect OpenCode browser tools to a locally running OpenWork Electron app to inspect its UI, enter a task, and check the response. This skill supports exploration and debugging through CDP, Chrome's remote control protocol.

  • Connecting browser tools to a local Electron development app
  • Inspecting screen state during debugging
  • Entering a task in the composer and running it
different-ai/openwork24.2KUpdated Oct 18, 2026

Check added lines in a change for information identifying customers, prospects, partners, or outside individuals. Report locations and generic remediation without reproducing identities, and escalate cases where the information is already public.

  • Checking changes for customer and partner identities
  • Reviewing documents and test data for identifying details
  • Reporting disclosure locations without repeating identities
different-ai/openwork24.2KUpdated Oct 18, 2026

Connects supported AI clients, including Claude Code and Codex, to OpenWork through MCP, a protocol for accessing external tools. It guides account sign-in and verifies that tools for finding and running organization capabilities are available.

  • Connecting an AI client to OpenWork organization resources
  • Signing in and verifying available MCP tools
  • Switching organizations or troubleshooting authentication
different-ai/openwork24.2KUpdated Oct 18, 2026

Review an outside contributor’s pull request before running its code. Identify concealed behavior, obfuscated code, risky dependencies, and build hooks, with file locations and specific checks for maintainers to follow up.

  • Screening an outside contributor’s pull request before execution
  • Checking encoded code and unexplained network calls
  • Reviewing dependency changes and installation scripts
different-ai/openwork24.2KUpdated Oct 18, 2026

create-plugin

FreeSummary

Create an OpenCode plugin for OpenWork with custom tools and hooks, which run code at specific events. The skill builds the plugin file and adds its entry to the project configuration.

  • Adding custom tools to OpenWork
  • Creating a plugin to save and list notes
  • Running custom code before or after tool execution
different-ai/openwork24.2KUpdated Oct 18, 2026

See all skills by different-ai

Report a problem with this skill