Run any Skill in Manus with one click

diagnose-from-raw-symptom

Use when Mark reports a bug by pasting a raw artifact with little or no prose — a stack trace, an HTTP request/response trace (URL + method + status like 500/403/404/502), a console/React/Prisma error, a ChunkLoadError, a shell error, or a screenshot of a visual defect — or when he says things like 'still failing', 'clicking X does nothing', 'no inline editor on the rendered page', 'do we have local postgres/pgvector?', or 'identify the true error'. This is the front-to-back debugging procedure — extract the trigger and reproduction from terse input, probe whether the underlying plumbing even exists, localize by contrasting known-good vs broken, and drive to a durable root cause rather than a workaround. Reach for this BEFORE proposing any fix.

Run Skill in Manus

Overview

Install command

npx skills add https://github.com/artsmc/claude-dev-agents --skill diagnose-from-raw-symptom

Copy and paste this command into Claude Code to install the skill

Source

artsmc/claude-dev-agents

Stars3

Forks0

UpdatedMay 30, 2026 at 12:10

File Explorer

2 files

SKILL.md

readonly

More from this repository

same repository

fleet-dispatch-and-watch

artsmc/claude-dev-agents

Use when Mark wants large or mechanical work fanned out across his machine fleet, or wants long-running/background/remote agents monitored. Triggers on 'distribute among the fleet', 'delegate with tmux and worktrees', 'kick it off fan them out', 'offload to mac-mini, desktop just orchestrate', 'check on the agents every 5 min', 'is it done its been some hours', 'are we ready to delegate', or any dispatch to background workers. This is Mark's dispatch→snapshot→poll→escalate→checkpoint loop — fan independent work to workers (local box orchestrates), hand each a precise state snapshot, then poll on a fixed cadence with trustworthy liveness proxies, error-signature buckets, and hard stop/escalation thresholds — never blocking or assuming success.

2026-05-313

research-gated-build-plan

artsmc/claude-dev-agents

Use at the START of anything sizable, before writing code — when Mark says 'want to work out the full plan', 'I want to do some deep research', 'lets start the planning', 'what does complete look like?', 'what tickets/tasks remain', 'how close are we / what are our current gaps', 'do we already have a harness for this', or 'is there a system we can use?'. This is Mark's front-loaded decision discipline — inventory what already exists before building, scope the gap against a concrete target, research and persist the approach as an artifact, sequence prerequisites, and bake quality bars + phase gates with human checkpoints directly into the go-ahead. It decides WHETHER and HOW to enter the execution skills (start-phase-plan, feature-new); run it first.

2026-05-313

scope-question-and-delegate

artsmc/claude-dev-agents

Use when work is genuinely ambiguous in a way that changes the plan, or big/multi-part/underspecified enough to balloon context — or when the orchestrator's window is trending toward the ~200k cliff where quality and cost degrade. Fires when Mark says 'this is a big one', 'what do you need from me before you start', 'dont drag the whole context through this', 'should we split this up', or 'keep the main thread lean' — or when one thread is doing both the planning AND the execution. This is Mark's triage-then-delegate discipline — decide fast whether real ambiguity or context cost warrants a stop, ask only the few DECISIVE questions, treat the window as a finite budget, and hand each worker a minimal scoped snapshot so the orchestrator plans and synthesizes without accumulating execution detail. Not a hard gate — small clear tasks just proceed.

2026-05-313

enumerated-menu-pick-and-sweep

artsmc/claude-dev-agents

Use whenever you're about to present Mark with consequential choices, questions, or tradeoffs — structure them as a numbered or lettered menu so a bare reply counts as a full selection, and use this to read his terse picks. Triggers on one-token replies that only resolve against a labeled list you just gave ('go with B', 'lets go with 2', 'run option B', 'c one big commit'), picks carrying a rider ('option 1 and update envs when your done', '1. yes, and execute it'), multi-item sweeps answering every numbered point at once ('1. yes 2. thats fine 3. just aws 4. whats the mcp server? 5. minimal'), ranged picks with a because-clause scope-cut ('do 1-3, 4 wont be needed because...'), and Mark authoring his own numbered decision list to apply across a spec. Format choices as a menu — a bare letter is uninterpretable unless you offered the list first.

2026-05-303

prove-it-live-before-done

artsmc/claude-dev-agents

Use whenever an agent (or you) is about to claim work is done/fixed/shipped/passing, or when Mark says 'ready?', 'done?', 'did it work?', 'still failing', 'is the live URL responding?', 'check the deploy status', or wants to confirm a fix before pushing. Treat every completion claim, green CI, and passing test as UNPROVEN until the real artifact is exercised end-to-end — drive the actual running app at its real URL/UI/API, confirm the deployed revision is actually live, verify the mutating side-effect (email/queue/DB row) truly fired, gate every forward step on an explicit green signal, audit coverage across the whole surface, and reconcile against the system of record. Then name the specific residual defect with expected-vs-actual.

2026-05-303

reference-as-executable-spec

artsmc/claude-dev-agents

Use when Mark frames a feature by pointing at a concrete reference instead of describing behavior from scratch — when he names a live product as the target ('an inline editor like editor.js', 'a code editor like monaco-editor dark theme', 'much like openclaw.ai'), points at an internal subsystem as the literal spec to replicate ('the OTP from sentient-monorepo is the pattern we should match', 'use sentient-monorepo as the api source of truth'), or anchors a requirement on an external library as the structural model ('setups similar to CASL', 'building this same CASL boilerplate'). Whenever he says 'build it like THAT', 'same as X', or 'mimic/replicate X', treat the named reference as the executable spec — go observe it, extract its real behavior, and let THAT define correct rather than inventing requirements.

2026-05-303

Source

artsmc

artsmc/claude-dev-agents

View GitHub Repository View Creator Repositories

Install command

Download

Run Skill in Manus

Useful forSOC

Software DevelopersComputer and Mathematical Occupations15-1252L4

name

diagnose-from-raw-symptom

description

Diagnose From the Raw Symptom

Mark debugs by dropping the literal evidence and expecting the symptom itself to drive diagnosis. He reasons from a mental model of correctness, distrusts easy explanations, and wants the root cause fixed — not papered over. Run this procedure top to bottom; do not jump to a fix.

0. Read the literal artifact — do not paraphrase it away

Mark pastes the exact thing: Invalid prisma.profiles.create() invocation: User was denied access on the database, Status Code 403 Forbidden, ChunkLoadError: Failed to load chunk, or a screenshot with a terse caption (message position weird on chat). The artifact is the spec. Extract from it, verbatim:

The exact status code / error class / error string
The URL, method, and which layer emitted it
The on-screen symptom in his words (missing element, stuck loading, wrong count, weird position)

Never soften or re-interpret the symptom. If he gave a screenshot + URL, the defect is visual and lives at that URL.

1. Pin the trigger and a concrete reproduction

Narrow the search space before touching anything. Establish:

Exact action that triggers it — i get the 502 when i submit the email address in the form of the login
A real recent instance — the literal running URL, a specific account, a real example. Anchor to http://localhost:3000/..., not a hypothetical.
A volunteered hypothesis linking a preceding event — i left the app sitting overnight and had a token issue now it runs too many request. Take these seriously; he often already knows.

If the trigger is ambiguous, ask ONE blunt question to pin it. Don't fix on a guess.

2. Probe the plumbing FIRST (before guessing at a fix)

Mark's signature move: reframe a surface symptom as a yes/no interrogation of foundational wiring. Ask and ACTUALLY CHECK, don't assume:

clicking the left navigation does nothing — are the pages built and connected?
do we have local postgres and pgvector?
still seeing failed to fetch — do we have proper logging for you to watch (pino/winston)?
do we have COMPOSIO self-hosted?

Decision rule: if a UI element "does nothing" or a call fails to fetch, verify the API/DB/service behind it EXISTS and is reachable before debugging the front end. A button wired to a route that was never built is not a front-end bug.

3. Localize by contrast

Isolate the fault by comparing a known-good reference against the broken one. Find what differs:

Deployed vs local — my local chat.beta has a button to the login page, this url does not
One working surface vs the failing one — platform login is fine so lets get this one in order on chat
Parent vs child scope — its highlighting the parent but not the child
Account that succeeds vs one that fails — why is the otp reject within seconds of being created for sahil@... but not mark@...

The difference between the two cases is the bug's address.

4. Walk the error chain forward — treat each new error as progress

When a fix changes the symptom, that is forward motion, not failure. 502 → 404 → 403 → business-logic error means you are peeling layers correctly. Feed each new code back as evidence about which layer now works. An ambiguous non-2xx (Cannot link: 3 channel members cannot view this case) often proves the proxy/route works and the failure moved inward.

5. Drive to ROOT CAUSE, reject the easy explanation

Mark pushes past symptoms and demands a durable fix:

Reject default explanations using observed timing/domain reasoning: cant be stale it happens right away — why is the otp rejected within seconds of being created?
Generalize repeated incidents to one systemic cause: both incidents have the same root cause: neither backend runs DB migrations on deploy
Reason from architectural invariants when his mental model is contradicted: but a user should always be found — why is a user not found in any case?, Users are all inside cognito... everyone is first a cognito user. If your fix would violate a decision already agreed (why is it hitting monorepo, we talked about this), stop — that inconsistency IS the bug.
Verify the full causal chain end-to-end, not just that the symptom moved.

6. Distrust misleading signals

If a monitoring/liveness signal is unreliable, name the failure mode and substitute a trustworthy proxy. Mark's rule: log file empty (tee+claude TUI quirk — ignore the log, rely on git state). Don't trust a signal you've seen lie.

Red flags — you are doing it wrong if:

Anti-pattern	Mark's correction
Proposing a fix before checking the service/DB exists	`are the pages built and connected?`
Paraphrasing the error instead of reading it literally	He re-pastes the exact string
Accepting the easy/stale explanation	`cant be stale it happens right away`
Treating a new error code as a regression	It's the next layer — walk the chain forward
Fixing the symptom with a workaround	He wants the durable root-cause fix
Guessing without a reproduction	`for clarity i get the 502 when i submit the email`

Hand off to prove-it-live-before-done once you believe it's fixed — Mark will not accept a fix on your word.