“root cause”的搜索结果

Evidence-before-action diagnosis of failing ML experiments. Probes the system before guessing causes, process list, dmesg, GPU stats, log scrollback, checkpoint state, then states a hypothesis as a hypothesis and runs a smoke before claiming a root cause. Use when the user asks why a run is failing, diverging, OOMing, hanging, slow, producing weird metrics, has crashed, or asks to debug, diagnose, troubleshoot, or investigate a training issue.

中文简介正在准备中。当前显示原文说明。

Fix rsky-pds createRecord/putRecord hanging indefinitely with no error logs. Use when: (1) createSession succeeds but createRecord never returns, (2) No error appears in PDS logs despite request hanging for 60+ seconds, (3) PDS health endpoint works but write operations hang, (4) readiness probes intermittently fail on rsky-pds pod. Root cause: PDS_CRAWLERS env var configures crawler notification URLs that are called via reqwest HTTP client WITHOUT any timeout in crawlers.rs. If the crawler URL is unreachable from the cluster, every write hangs forever. Also: setting PDS_CRAWLERS="" produces [""] (one empty string element) which causes a "builder error" instead — must fully unset the env var.

中文简介正在准备中。当前显示原文说明。

Fix silent data loss when mutating Nostr replaceable events (Kind 0 profile, Kind 3 contact/follow list, Kind 10002 relay list, etc.) in client apps. Use when: (1) Following someone wipes the user's entire follow list, (2) Updating profile metadata loses existing fields, (3) Fresh browser session or mobile login causes data loss on first action, (4) Replaceable event mutation uses stale or null cached state. Root cause: Nostr replaceable events are full-replace (no partial update), so publishing based on stale/unloaded cache overwrites the canonical version. Applies to any Nostr client using React, Flutter, or similar reactive frameworks where query state may not be loaded when a mutation fires.

中文简介正在准备中。当前显示原文说明。

Fix misleading Flutter/Dart test failures where expected data is empty ([]) or default values instead of the mocked response, caused by stale Mockito generated mocks or missing stubs being silently swallowed by try/catch in provider/repository code. Use when: (1) Test expects non-empty data but gets [], (2) Mock stubs for a method are set up but the code under test returns fallback/empty results, (3) A PR added new methods to a service class and tests that previously passed now fail with misleading "expected X, actual: empty" assertions, (4) "Generated files are out of date" CI error alongside test failures. The root cause is MissingStubError thrown by unstubbed mock methods, caught by production try/catch blocks, causing silent fallback to empty state.

中文简介正在准备中。当前显示原文说明。

Fix black camera/microphone preview in Flutter macOS apps launched via `flutter run` from a terminal emulator (cmux, iTerm, Terminal.app, VS Code integrated terminal, Cursor, etc.). Use when: (1) camera plugin reports initialized but preview is black with no frames, (2) logs show "initialization completed via timeout" or similar first-frame timeout fallback, (3) AVCaptureSession.startRunning() returns without error but zero frames arrive, (4) the app's Info.plist has NSCameraUsageDescription and entitlements (com.apple.security.device.camera, audio-input) are correctly set, (5) no permission dialog ever appears, (6) same failure mode for microphone. Root cause is macOS TCC attributing camera/mic requests to the *responsible process* (the parent terminal) rather than the Flutter app itself. TCC refuses to prompt because the terminal is hardened-runtime without a camera entitlement, and silently denies. Not a bug in the camera plugin — would reproduce with ANY camera code.

中文简介正在准备中。当前显示原文说明。

Explain why counterexamples violate specifications by analyzing formal specifications (temporal logic, invariants, pre/postconditions, code contracts), informal requirements (user stories, acceptance criteria), test specifications (assertions, property-based tests), and providing step-by-step traces showing state changes, comparing expected vs actual behavior, identifying root causes, and assessing violation impact. Use when debugging test failures, understanding model checker output, explaining runtime assertion violations, analyzing static analysis warnings, or teaching specification concepts. Produces structured markdown explanations with traces, comparisons, state diagrams, and cause chains. Triggers when users ask why something failed, explain a violation, understand a counterexample, debug a specification, or analyze why a test fails.

中文简介正在准备中。当前显示原文说明。

Investigate unexpected behavior and mysterious bugs. Use when the cause of a problem is unknown and the user needs to understand WHY something is happening — symptoms like: sudden unexplained changes in metrics or behavior, works locally but not in staging/production, inconsistent or intermittent failures, correct code producing wrong results, operations succeeding but having no effect, environment-specific failures, duplicate executions, stale data, or any "why did this change?" or "why is this happening?" situation. Covers infrastructure anomalies (cache hit rates dropping, latency spikes, queue behavior shifts) as well as code bugs. The key signal is confusion about root cause, not a request to implement a known fix. Do NOT use for feature requests, known fixes, planning, or documentation tasks.

中文简介正在准备中。当前显示原文说明。

Use when a task in code_review was sent back before (an earlier need_revision comment exists) - verify every prior point was fixed at its root

中文简介正在准备中。当前显示原文说明。

Diagnose and fix mini-program failures through reproducible, evidence-driven root-cause analysis across source, state, asynchronous timing, caches, mock data, build versions, platform behavior, devices, cloud calls, and external services. Use when users report white screens, crashes, stale or jumping values, missing data, intermittent behavior, permission failures, performance stalls, device-only defects, API or cloud-function errors, source-versus-build mismatches, or regressions whose cause is not yet established. Freezes the observation environment, ranks competing hypotheses, runs discriminating checks, creates a failing regression test before repair, covers analogous states, and never hides a known failure with longer waits, swallowed errors, forced success, or cosmetic patches.

中文简介正在准备中。当前显示原文说明。

Investigate why something happens — confirm the question and success criteria with you, then trace the root cause with an evidence chain.

中文简介正在准备中。当前显示原文说明。

Shapes for running many sub-agents at once — fan-out with a barrier, maker/checker, generate-and-filter, tournaments for ranking, hypothesis fan-out for root cause, and loops that stop on a condition with a cap. Use when a phase has several independent targets, when a task is too large or too repetitive for one window, when the same edit applies across many files, when ranking or judging a large set, when several hypotheses compete, or when work must repeat until a signal says stop. Does not apply when units depend on each other's results or the cause is still unknown — investigate first, then parallelize.

中文简介正在准备中。当前显示原文说明。

Use when a human says "overhaul", "rebuild this subsystem", or "rewrite it from scratch". Not for thin-slice features: use incremental-implementation. Not for root-cause repair: use strike-the-root.

中文简介正在准备中。当前显示原文说明。

Fix docker exec hanging when starting background processes (servers, daemons) inside containers. Use when: (1) docker exec never returns despite using & or nohup, (2) background server started in container causes docker exec to hang indefinitely, (3) env_startup_command in SWE-bench or similar frameworks times out, (4) setsid/disown needed for proper process detachment in Docker. Root cause: docker exec tracks ALL processes in the exec session, not just the top-level PID.

中文简介正在准备中。当前显示原文说明。

Provides data-retrieval best practices, tool selection guidance, and performant SQL query syntax for BigQuery telemetry across INFORMATION_SCHEMA, Cloud Monitoring, and the REST API. Use when the telemetry to fetch is already known, selecting telemetry tools, writing performant INFORMATION_SCHEMA queries, retrieving telemetry for diagnosing single-job performance bottlenecks, investigating slot contention, job concurrency and queue latency, analyzing reservation capacity, utilization and autoscaling saturation, or auditing capacity-based and on-demand compute and storage resource billable usage. Don't use for root-cause diagnosis or symptom troubleshooting when the cause is unknown (use bigquery-troubleshooting first), or for writing or optimizing business logic SQL (use bigquery-optimization).

中文简介正在准备中。当前显示原文说明。

Investigate and fix failing CI. Takes a PR reference, one or more CI run/job URLs, or freeform text describing where the failures are, then enumerates failing workflows/jobs/steps, determines the root cause (often one shared cause behind several red checks), proposes a fix plan, applies code changes, commits, pushes, watches the new runs, and repeats until checks pass. Use when the user says "fix CI", "CI is red", "checks are failing", "the build is broken on my PR", "fix the failing jobs", or pastes a failing CI run URL. Do NOT use for authoring new workflows, or for read-only diagnosis with no fix intent — use gha-log-reader for that.

中文简介正在准备中。当前显示原文说明。

Symptom → root-cause lookup table for nuxt-crouton's recurring failure modes — exact error strings mapped to their known cause, fix, and evidence issue. Use when you hit an error you don't recognize in this repo, before debugging from first principles. Trigger phrases and symptoms: "Cannot resolve entry module .nuxt/hub/db/schema.entry.ts", "Could not load '@fyit/crouton-*'", "No migrations present", "No schema files found", "$setup.t is not a function", "does not provide an export named 'Map'", "no such table: translations_ui", "collection pages 500 in production", "the build was green but the app is broken", "is this a known issue?".

中文简介正在准备中。当前显示原文说明。

Drafts one knowledge article or known-error article from a resolved incident or ticket thread: symptoms as reported, environment, cause exactly as the resolver stated it, resolution steps as performed, workaround with its limits, verification, things tried without effect, related records, keywords and proposed metadata, every statement traced to a ticket note or marked UNKNOWN, with a redaction log and a question list for the knowledge owner. Never decides a root cause, adds a step or publishes. Use when the user asks to "write a KB article from this ticket", "turn this resolved incident into a knowledge article", "draft a known error record for this", "document the fix we just did" or "make this thread into a how-to for the service desk". Do not use for a procedure the team will execute (runbook, operating procedure, playbook), use runbook-drafter instead; for a post-incident review, use incident-postmortem-drafter. Drafts for human review; never approves, authorises or signs off.

中文简介正在准备中。当前显示原文说明。

Disciplined diagnosis loop for hard bugs, regressions, flaky failures, and performance problems with unclear cause. Use for root-cause debugging after a concrete symptom exists; do not use for routine implementation or speculative cleanup.

中文简介正在准备中。当前显示原文说明。

Run a pre-mortem — imagine the project has already failed one year from now and work backward to find the root causes before they happen. Load when the user asks for a pre-mortem, wants to imagine failure before committing, asks "what could go wrong before we start", "assume this fails — why", "risk analysis before launch", "what kills this project", "what could go wrong", or when deep-thinking diagnoses a pre-mortem frame. Based on Gary Klein's prospective hindsight method, which surfaces failure causes more effectively than forward risk analysis. Most useful right before a major commitment.

中文简介正在准备中。当前显示原文说明。

This skill should be used when the user wants to "investigate a bug", "debug an issue", "figure out why something is happening", "find the root cause", "troubleshoot", "強い推論で調査", "仮説を立てて検証", "原因を特定", "バグの原因調査", "なぜ動かないか調べて", "問題を切り分け", "原因不明", "デバッグ", or mentions systematic hypothesis-driven debugging. NOTE: Use this for investigating UNKNOWN causes, not for validating design proposals (use devils-advocate for that).

中文简介正在准备中。当前显示原文说明。

Five Whys root cause analysis. Iteratively asks "why" to drill past symptoms to underlying causes. Use for debugging, investigating failures, or understanding why something went wrong.

中文简介正在准备中。当前显示原文说明。

管理OpenClaw的多个Issue和PR，分配负责人调查原因、修复并验证，在获准范围内推进合并及关闭已解决事项，同时记录证据和进度。

• 管理多个Issue或PR的修复
• 完成已有的修复PR
• 验证并关闭已修复的Issue

先准备可重复复现症状的测试或命令，再按原因调查、正常示例对比、假设验证和修复四个阶段，定位根本原因并用回归测试验证结果。

• 调查测试或构建失败
• 排查跨多个系统的异常
• 复现间歇性缺陷

优先复用现有代码、标准功能和已安装的依赖，以满足请求的最小变更完成实现或修复，处理受影响的调用方并进行必要验证，简要报告省略工作、未核实事项和风险。

• 实现满足请求的最小版本
• 修复共用逻辑中的根本原因
• 重构时减少不必要的新增内容