@clawhub-mvogt99-7d48143016
The reply ends mid-sentence or mid-code-block because the model hit a token limit or was cut short.
---
name: truncated-output
description: The reply ends mid-sentence or mid-code-block because the model hit a token limit or was cut short.
emoji: ✂️
metadata:
clawdis:
os: [macos, linux, windows]
---
# truncated-output
The reply the user receives is incomplete — the model ran out of tokens, the stream was cancelled, or a code fence opened without closing.
## Symptoms
- Reply ends without terminal punctuation and reads as if more was coming.
- A fenced code block is open (```` ``` ````) with no matching close.
- Enumerated lists or steps trail off before the final item.
- Provider metadata reports `finish_reason: "length"` or `stop_reason: "max_tokens"`.
## What to do
- Before returning the reply, check for an unmatched code fence. If present, the reply is incomplete — do not ship it.
- Check the provider's finish reason. If it indicates a length cap, regenerate with a higher `max_tokens` budget or summarize the remaining work inline.
- Watch context budget. If the prompt is already close to the context ceiling, the reply has no room — trim context before retrying, don't just raise the cap.
- If truncation happens repeatedly on the same task, break the task into smaller turns instead of asking for one giant reply.
- When truncation cannot be avoided (e.g., streaming to a channel with its own cap), surface the incompleteness to the user explicitly rather than pretending the reply is done.
Internal reasoning from <think> blocks leaks into the final user-facing reply instead of being stripped.
---
name: think-block-leakage
description: Internal reasoning from <think> blocks leaks into the final user-facing reply instead of being stripped.
emoji: 🧠
metadata:
clawdis:
os: [macos, linux, windows]
---
# think-block-leakage
The model's internal reasoning escapes into the reply the user sees. This usually means an unclosed `<think>` / `<thinking>` tag, or a reply that begins with planning prose instead of the answer itself.
## Symptoms
- Reply contains literal `<think>`, `<thinking>`, or similar reasoning tags.
- Reply opens with "Let me think...", "Okay, the user wants...", "First I'll need to...", or other planning preamble.
- Reply is cut off mid-sentence and an opening reasoning tag has no matching close.
- A `</think>` appears with only a few dozen characters of content after it.
## What to do
- Inspect the raw LLM output for unmatched reasoning tags before returning it. Strip or redact any content inside reasoning tags.
- If the provider supports a separate reasoning channel, emit reasoning there and keep it out of the reply body entirely.
- If leakage is detected, regenerate the reply. Do not ship reasoning-as-answer.
- If the reply starts with planning language, trim the preamble. The user should see the answer first.
- For persistent leakage, tighten the system prompt to forbid meta-commentary in the reply body.
Review comments are unactionable — "improve this", "handle errors", "refactor" without specifics or suggested alternatives.
---
name: review-vague-fixes
description: Review comments are unactionable — "improve this", "handle errors", "refactor" without specifics or suggested alternatives.
emoji: 👀
metadata:
clawdis:
os: [macos, linux, windows]
---
# review-vague-fixes
A review that says "this needs work" without saying what work is a cost on the author, not a contribution. The author has to either guess what the reviewer meant or push back and ask — both eat time and erode trust.
## Symptoms
- Comments like "refactor this", "improve error handling", "make this cleaner" with no example.
- Blanket style gripes on a change that was explicitly about functionality.
- "I don't like this" with no reason and no alternative.
- Comments that could apply to any file in the codebase — no specificity to what's in front of the reviewer.
## What to do
- Every review comment should state *what* to change, *where*, and *why*. If you can't say why, you probably don't have a concrete objection.
- When you want a refactor, give an example: paste the shape you'd prefer, or point at a similar pattern elsewhere in the codebase.
- Distinguish blocking from nice-to-have. Mark must-fix clearly; leave nitpicks labeled as such.
- Reference the exact line, symbol, or behavior. "In `processOrder`, the retry loop won't back off" beats "improve this function".
- If you don't know the right fix, say so — "this concerns me because X; not sure what the right answer is" is honest and inviting, unlike a vague demand.
Files, sockets, subscriptions, or other finite resources are acquired without a guaranteed release path.
---
name: resource-leak
description: Files, sockets, subscriptions, or other finite resources are acquired without a guaranteed release path.
emoji: 💧
metadata:
clawdis:
os: [macos, linux, windows]
---
# resource-leak
A resource is opened but not closed. Under low load the process recycles or the OS cleans up on exit, so the bug stays hidden. Under real load, file-descriptor exhaustion, memory bloat, or orphaned connections appear and cascade.
## Symptoms
- `open(...)` without a matching `close()` or `with` block.
- Database connections or HTTP clients instantiated per-request without pooling or teardown.
- Event listeners / observers / subscriptions registered but never removed.
- Background tasks or timers spawned without cancellation paths.
- Gradual memory growth that correlates with request count.
## What to do
- Pair every acquire with a release. Use language constructs that guarantee teardown: `with` (Python), `using` / `try-with-resources` (C#/Java), `defer` (Go), `try/finally` (JS/TS).
- For resources that outlive a single function, document ownership: who closes it, when, on which code path — including error paths.
- Prefer pooled clients (HTTP, database) over creating a new one per call.
- When registering event listeners, return the unregister function in the same scope so the caller can clean up.
- Test the teardown path. Kill a process or trigger an error mid-operation and confirm resources are released.
Shared mutable state is accessed from concurrent contexts without synchronization, producing nondeterministic behavior.
---
name: race-condition
description: Shared mutable state is accessed from concurrent contexts without synchronization, producing nondeterministic behavior.
emoji: 🏁
metadata:
clawdis:
os: [macos, linux, windows]
---
# race-condition
Two or more concurrent contexts — threads, async tasks, processes, requests — read and write the same state without coordination. Tests pass on a lightly-loaded machine; production corruption appears under real traffic.
## Symptoms
- Counters that "mostly" work but occasionally lose increments.
- Check-then-act sequences (e.g., "if not exists, create") where two contexts both pass the check and both create.
- Shared caches or singletons mutated from request handlers without a lock.
- Data-corruption bugs that only reproduce under load or with specific timing.
## What to do
- Identify every piece of shared mutable state. Draw the boundary: who reads it, who writes it, from which contexts.
- Replace check-then-act with atomic operations: compare-and-swap, `INSERT ... ON CONFLICT`, unique indexes, `setnx`.
- Prefer immutable data or message-passing over shared mutation. Actor-style patterns remove most races by construction.
- When a lock is unavoidable, hold it for the shortest possible span and document what state it protects.
- Test concurrency explicitly. A single-threaded test proves nothing about a multi-threaded code path. Use stress tests or `pytest-asyncio` / concurrent harnesses.
Code returned as "done" is actually a stub — a placeholder body, a TODO comment, or a function that claims completion without real logic.
---
name: partial-implementation
description: Code returned as "done" is actually a stub — a placeholder body, a TODO comment, or a function that claims completion without real logic.
emoji: 🚧
metadata:
clawdis:
os: [macos, linux, windows]
---
# partial-implementation
A function or module is declared complete, but the body is a stub. The most common form is a function with `pass`, `return None`, `throw NotImplementedError`, or a single `TODO:` comment in place of real logic.
## Symptoms
- Function signature exists but the body contains only a comment, `pass`, `return`, `throw new Error("not implemented")`, or similar.
- Placeholder values returned (`return 0`, `return {}`, `return null`) where real computation was requested.
- Tests pass only because the test is also a stub, or because the function always returns the fixture value.
- The agent claims a change is "complete" or "implemented" but no meaningful lines of logic were added.
## What to do
- Before declaring a task done, re-read every function you added or modified. If the body is a placeholder, the task is not done.
- Search the diff for `TODO`, `FIXME`, `XXX`, `NotImplementedError`, `unimplemented!`, `pass`, lone `return` or `return null`. Investigate each hit.
- Run the code end-to-end, not just the type-checker. A stub satisfies the type checker but fails at runtime.
- Compare the implementation against the task description: every bullet of the task should map to concrete lines of logic, not comments.
- If part of the task is genuinely out of scope, say so explicitly rather than stubbing silently.
External input flows into sensitive operations without being checked for type, shape, range, or sanitization.
---
name: missing-input-validation
description: External input flows into sensitive operations without being checked for type, shape, range, or sanitization.
emoji: 🛡️
metadata:
clawdis:
os: [macos, linux, windows]
---
# missing-input-validation
Any data from outside the process — HTTP request bodies, CLI args, file contents, third-party API responses, user messages — should be treated as untrusted until proven otherwise. Code that uses it directly opens injection, crash, and security paths.
## Symptoms
- HTTP handler uses `request.body.x` with no type check.
- CLI flag value passed straight into `exec`, `SQL`, or a file path.
- Third-party API response fields accessed without confirming they exist.
- Numeric input used in array indexing or arithmetic with no bounds check.
- String input concatenated into SQL, shell commands, or file paths.
## What to do
- At every trust boundary, validate type, shape, and range before using the value. Reject early with a clear error message.
- For structured payloads, use a schema validator (Zod, Pydantic, ArkType, etc.) — don't hand-write "if field exists".
- For values used in SQL, shell, or file paths, use parameterized queries, `execFile` with an argv array, or explicit path joins — never string concatenation.
- When an invariant is checked, include the unexpected value in the error so debugging is possible.
- Third-party responses are *not* trustworthy. Validate them the same way you'd validate user input.
Code uses a symbol that isn't imported, or imports a symbol that doesn't exist in the source module.
---
name: missing-imports
description: Code uses a symbol that isn't imported, or imports a symbol that doesn't exist in the source module.
emoji: 📦
metadata:
clawdis:
os: [macos, linux, windows]
---
# missing-imports
The generated code uses a name that hasn't been brought into scope, or imports from a module that doesn't export the named symbol. A guaranteed runtime `NameError` / `ReferenceError` / `ImportError`.
## Symptoms
- Code uses `Foo` but `Foo` is never imported.
- `from mod import X` where `mod` exists but does not export `X`.
- `import { x } from "pkg"` with no matching named export.
- Static analysis flags `unused-import` alongside `undefined-name` — common when the agent copy-pastes between files.
## What to do
- For every symbol used in the diff, confirm there is a corresponding import in the same file or that the symbol is defined locally.
- For every new import, verify the target module actually exports that name. Open the module if needed.
- Don't guess at package layout. When unsure, read the package's `package.json` exports, `__init__.py`, or equivalent.
- Run the static checker (tsc, mypy, pyright, etc.) after every non-trivial change. Missing imports almost always surface there.
- Remove unused imports in the same change so the surface stays honest — stale imports mask real failures.
Code handles only the happy path — external calls, I/O, and parsing have no failure handling and crash on anything unexpected.
---
name: missing-error-handling
description: Code handles only the happy path — external calls, I/O, and parsing have no failure handling and crash on anything unexpected.
emoji: ⚠️
metadata:
clawdis:
os: [macos, linux, windows]
---
# missing-error-handling
Every external interaction is a source of failure: network, disk, subprocess, parsing, third-party API. If the code assumes they always succeed, a production run will hit the first unexpected condition and crash unhelpfully.
## Symptoms
- HTTP calls without status-code checks and without timeout.
- File I/O with no handling for missing files, permission denied, or partial reads.
- Subprocess calls that ignore non-zero exit codes.
- `JSON.parse` / `yaml.load` with no handling of malformed input.
- Broad `except:` / `catch (e) {}` that swallows everything without logging.
## What to do
- For each external call, list the failure modes explicitly: timeout, non-2xx status, missing resource, malformed payload, permissions. Handle each with specific recovery or a loud failure.
- Add a timeout to every network call. No exceptions.
- When catching, catch the specific exception types you can actually recover from. Let unknown errors propagate with context.
- When swallowing is unavoidable, log the full error with context — at minimum, the operation that failed and the arguments.
- Distinguish "user-visible error" (explain, ask them to retry or adjust) from "internal error" (log with stack, fail fast). Don't leak internal errors to users.
Reply cites file paths, directories, or module locations that do not exist in the current project.
---
name: hallucinated-paths
description: Reply cites file paths, directories, or module locations that do not exist in the current project.
emoji: 🗺️
metadata:
clawdis:
os: [macos, linux, windows]
---
# hallucinated-paths
The reply references files or directories that aren't on disk. The agent invented a plausible-sounding location (e.g., `src/utils/helpers.ts`) because similar paths usually exist in projects like this one.
## Symptoms
- A quoted path doesn't exist when you check the filesystem.
- The reply uses a path structure that matches convention but the specific file is absent (e.g., `src/components/Button.tsx` in a project that actually puts components elsewhere).
- Imports reference modules that cannot be resolved.
- "Edit X file at path Y" instructions fail because Y is not there.
## What to do
- Before quoting a path, verify it with a real file-existence check (`ls`, `stat`, a glob search). Do not rely on memory or convention.
- When unsure where something lives, search first: grep for the symbol, glob for the filename, read the repo layout.
- If the answer requires a path that doesn't exist, say so explicitly — don't fabricate. "I couldn't find a file for X" is correct; inventing one is not.
- When proposing to create a new file, state clearly that it is new, and justify why it belongs at that path given the repo's actual conventions.
- After editing, verify the edited file is the one that exists, not a hallucinated sibling.
Code calls functions, classes, or methods that don't exist — either on project types or on third-party library APIs.
---
name: fabricated-symbols
description: Code calls functions, classes, or methods that don't exist — either on project types or on third-party library APIs.
emoji: 👻
metadata:
clawdis:
os: [macos, linux, windows]
---
# fabricated-symbols
The agent invokes a symbol that isn't defined. Most often this is a plausible-looking method on a third-party object, or a utility "I'm sure we have one of those" that the project actually lacks.
## Symptoms
- Generated code calls `someLibrary.convenientHelper(...)` where the library has no such method.
- Invented method signatures on framework objects (wrong argument order, wrong return type).
- References to utility functions the project doesn't have.
- Runtime `AttributeError` / `TypeError: X is not a function` / `undefined is not a function`.
## What to do
- For every symbol you invoke on a third-party library, check the library's real API — docs, source, or type definitions — before writing code.
- For every symbol you invoke on a project type, grep the codebase to confirm it exists. Don't assume.
- If a helper is missing, either add it explicitly (and say you're adding it) or use what the project actually has.
- Prefer the library's documented API over clever-looking shortcuts. Invented methods often look like what the library "should" have.
- When refactoring, run the type-checker after every meaningful change. Invented methods sometimes type-check against `any` but fail at runtime.
A fix is applied without a reproduction test, leaving no proof the bug is fixed and no regression coverage.
---
name: bugfix-without-test
description: A fix is applied without a reproduction test, leaving no proof the bug is fixed and no regression coverage.
emoji: 🧪
metadata:
clawdis:
os: [macos, linux, windows]
---
# bugfix-without-test
Fixing a bug without a test means (a) you don't know the fix actually works, and (b) there's nothing to stop the bug from coming back next refactor. A fix without a regression test is provisional at best.
## Symptoms
- Diff contains code changes but no test changes.
- Existing tests still pass, but none of them would have failed under the original bug.
- PR description describes a bug scenario that no test exercises.
- The fix is a one-liner and no one will remember why it exists six months later.
## What to do
- Reproduce the bug as a failing test first. Run it. Confirm it fails for the right reason.
- Apply the fix. Run the test again. Confirm it passes.
- Keep the test in the suite. It becomes the regression guard.
- If the bug is hard to test (timing, environment, flaky), say so explicitly and describe what manual verification was done. Don't silently skip.
- For bugs discovered in production, add the test at the lowest level that reproduces the issue — unit if possible, integration if not.
A fix is proposed without first identifying the root cause; the symptom is masked rather than resolved.
---
name: bugfix-without-diagnosis
description: A fix is proposed without first identifying the root cause; the symptom is masked rather than resolved.
emoji: 🩹
metadata:
clawdis:
os: [macos, linux, windows]
---
# bugfix-without-diagnosis
When a fix goes in without understanding why the bug occurred, the symptom disappears but the cause lingers. It will return under a different shape, or the "fix" will mask a more serious problem upstream.
## Symptoms
- Fix adds a null check without explaining why the value was null.
- Retry loop wrapped around a flaky call with no investigation into why it was failing.
- Try/except swallowing a specific exception without stating what conditions produce it.
- Condition tweaked (`>` → `>=`) to make a test pass, with no explanation of the underlying off-by-one.
- PR description says "fix X" with no "because Y".
## What to do
- Before proposing a fix, write one sentence stating the root cause. If you can't, you don't understand the bug well enough to fix it.
- Explain how the symptom follows from the cause — the chain of events from "bad thing happened" to "user saw this".
- Confirm the fix addresses the cause, not just the symptom. A null check is valid only if you know why the value was null and concluded that null is acceptable.
- Where the cause is upstream, fix it upstream. Only patch downstream if upstream is genuinely out of reach, and say so.
- Leave a comment linking the symptom to the cause so future readers don't misread the fix as superficial.
Analysis compares options thoroughly but doesn't pick one — the decision is punted to the reader without guidance.
---
name: analysis-no-recommendation
description: Analysis compares options thoroughly but doesn't pick one — the decision is punted to the reader without guidance.
emoji: 🎯
metadata:
clawdis:
os: [macos, linux, windows]
---
# analysis-no-recommendation
A comparison without a recommendation makes the reader do the work. It looks thorough but leaves the decision where it started, and often signals that the author didn't want to commit.
## Symptoms
- Analysis ends with "here are the options" and nothing further.
- Recommendation buried in hedges: "it depends", "either could work", "teams may prefer".
- Criteria listed but never applied to pick a winner.
- Author avoids stating a view because they fear being wrong.
## What to do
- After the comparison, name the recommended option in one sentence. No hedging.
- Give the one-line reason the recommendation wins under the stated criteria.
- Call out the key uncertainty that would flip the recommendation — "if latency matters less than consistency, pick B instead".
- If the right answer genuinely depends on context the author doesn't have, ask for that context rather than punting.
- Being wrong with a specific recommendation is more useful than being vague. A wrong recommendation is correctable; a non-answer leaves the reader stuck.
Analysis presents a single option without comparing alternatives or articulating the costs of the chosen approach.
---
name: analysis-missing-tradeoffs
description: Analysis presents a single option without comparing alternatives or articulating the costs of the chosen approach.
emoji: ⚖️
metadata:
clawdis:
os: [macos, linux, windows]
---
# analysis-missing-tradeoffs
An analysis that skips comparison reads as advocacy, not analysis. The reader can't tell whether you considered and rejected alternatives or simply didn't see them, so they can't trust the recommendation.
## Symptoms
- Analysis proposes one approach and frames it as obviously correct.
- Costs and limitations of the chosen approach are not discussed.
- No mention of alternatives that a knowledgeable reader would have considered.
- Conclusion reads "we should do X" with no "rather than Y because Z".
## What to do
- Enumerate at least two viable options. If only one is viable, say why the others were eliminated.
- For each option, list what you gain and what you give up. Costs include complexity, risk, cost of reversal, team unfamiliarity — not just performance numbers.
- State the decision criteria up front: what matters most here (latency? cost? time to ship? blast radius?). Apply the criteria consistently across options.
- Show your work. The reader should be able to change one assumption and see which option wins.
- When the right answer is genuinely obvious, still name the alternatives and dismiss them briefly. Obvious-to-you is not obvious-to-everyone.