Run any Skill in Manus with one click

diagnose-bundle

Stars16

Forks2

UpdatedJuly 20, 2026 at 15:18

Maintainer/dev skill that triages an anonymised diagnostic bundle (appsec-diag-*.tgz, produced by scripts/diagnostic_bundle.py) a user sent after a pipeline failure. Runs the deterministic inspect, then cross-references the plugin source (scripts/, agents/phases/, AGENTS.md) and known-bug history to produce a grounded root-cause hypothesis. Does NOT re-run the pipeline and never needs the user's repo.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

matthiasrohr

matthiasrohr/appsec-advisor

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name

diagnose-bundle

description

diagnose-bundle

A user hit a pipeline error and sent you an anonymised diagnostic bundle (appsec-diag-<id>.tgz). It contains only versions, run shape (phases reached, stage timings, aggregate counts), a metadata-only file inventory, and scrubbed logs — never their results, findings, or source (see scripts/diagnostic_bundle.py). Your job: turn those facts into a root-cause hypothesis by binding them to this plugin's code and bug history.

The leverage is that you run inside the appsec-advisor repo: the bundle gives the symptom (where/what), the repo gives the mechanism (which producer, which contract). Keep the diagnosis anchored to the structured fields — never invent a cause the bundle does not support.

This is a maintainer/dev skill — never auto-triggered, not part of create-threat-model, and it needs no new permissions (read-only triage of a file the maintainer chose to open).

Step 1 — Parse arguments

BUNDLE (required) — path to the appsec-diag-*.tgz (or an already-unpacked bundle dir). If absent, ask the user for it and stop.

Step 2 — Resolve `CLAUDE_PLUGIN_ROOT`

if [ -z "$CLAUDE_PLUGIN_ROOT" ]; then
  CLAUDE_PLUGIN_ROOT=$(find /root /home /opt -maxdepth 6 \
    -path "*/appsec-advisor/skills/diagnose-bundle/SKILL.md" \
    2>/dev/null | head -1 | xargs -r dirname | xargs -r dirname | xargs -r dirname)
fi
export CLAUDE_PLUGIN_ROOT
if [ -z "$CLAUDE_PLUGIN_ROOT" ] || [ ! -d "$CLAUDE_PLUGIN_ROOT" ]; then
  echo "Error: CLAUDE_PLUGIN_ROOT could not be resolved." >&2
  exit 2
fi

Step 3 — Deterministic inspect (facts into context)

Read the bundle in memory — do NOT tar -x it to disk; a hand-crafted bundle could path-traverse on extraction. inspect reads it safely.

python3 "$CLAUDE_PLUGIN_ROOT/scripts/diagnostic_bundle.py" inspect \
  --bundle "$BUNDLE" --logs 40
INSPECT_EXIT=$?
[ "$INSPECT_EXIT" -ne 0 ] && { echo "diagnose-bundle: inspect failed ($INSPECT_EXIT)"; exit "$INSPECT_EXIT"; }

This prints: environment (plugin version / platform / config), where it stopped (last progress, error count, scrubbed last error, stage count), anonymised counts, the file inventory (with byte sizes), and the last 40 scrubbed log lines. These are your only inputs — treat them as the ground truth.

Step 4 — Cross-reference the plugin source

Bind the symptom to the mechanism. From the inspect output, take the last error, the stopping phase/component, and any anomalous inventory entry (a finding sidecar that is 0 B, missing, or implausibly large), then:

Phase/component → producer. Map the phase to its phase-group file under agents/phases/ and the script that runs there (e.g. Phase 9/merge → scripts/build_threat_model_yaml.py; compose → compose_threat_model.py). Use AGENTS.md → "Phase and stage map", the phase-group headings, and each agent's frontmatter for its role and turn budget.
Error signature → code. Grep the repo for the distinctive tokens of the scrubbed last error (schema enum names, function names, event names) across scripts/, schemas/, agents/. The <str>/<path> placeholders are redactions — match on the unredacted skeleton around them.
Known-bug history. Check the auto-memory index (MEMORY.md) for a prior occurrence of this signature (e.g. schema-drift FATALs, STRIDE inline-shortcut → empty output, budget-flag poisoning). A match is strong evidence and usually carries the fix location.

Step 5 — Report (print, do not write files)

Emit exactly these fields, each grounded in a bundle fact or a repo file:line:

WHERE         <phase> / <component> / <producer script:line>
ROOT CAUSE    <hypothesis, tied to the last_error + an inventory/counts anomaly>
EVIDENCE      <the bundle fact(s)> + <repo file:line or memory entry>
CHECK NEXT    <the producer file/function to read to confirm>
REPRO         <smallest way to reproduce — e.g. threat_fixture replay, a crafted sidecar, a unit test>
CONFIDENCE    high | medium | low  (low if the bundle underdetermines the cause)

Rules:

If the bundle underdetermines the cause, say so and state which additional non-sensitive field would disambiguate (so we can widen collect) — do not guess past the evidence.
Never ask the user for their source or results; the bundle is deliberately finding-free and the diagnosis must work without them.

More from this repository

same repository

create-threat-model

matthiasrohr/appsec-advisor

Perform a threat assessment of a repository and produce a threat-model.md. Supports --repo to analyze external repos and --output to set the output directory. Optionally also writes threat-model.yaml with --yaml flag.

2026-07-2516

ask-threat-model

matthiasrohr/appsec-advisor

Answer ANY question about the threat model in this repo — read-only Q&A over the committed threat-model.yaml. The default surface for every natural-language query about the model, however simple: does one exist at all ("is there a threat model here?", "gibt es hier ein bedrohungsmodell?"), how it stands ("how bad is it?", "is it still current?"), anything about its contents ("what are the critical findings?", "does it cover SSRF / IDOR / auth?", "which findings touch the payment service?", "is there a fix for F-003?", "welche kritischen findings gibt es?", "deckt mein bedrohungsmodell XSS ab?"), and meta questions ("what does P1 mean?", "what is STRIDE here?"). Grounds every data answer in the model and cites F-ids; never analyzes code, re-scores, spawns agents, or writes files. Prefer this over show-threat-model for anything phrased as a question — show only prints a fixed summary block on explicit request. To act on findings use review-threat-model; to (re)generate use create-threat-model.

2026-07-1916

show-threat-model

matthiasrohr/appsec-advisor

Print the standard summary block of the current threat model — scan identity, findings by severity, the remediation backlog (P1/P2/P3) and mitigation coverage, the worst-case scenarios, control posture, and whether the model is still up to date. A DISPLAY command, not a question-answering surface: use it only for an explicit request to see that block ("show me the threat model summary", "zeig mir die threat-model-uebersicht", "print the overview"). Reuses the same change detection that decides if an incremental scan is needed. Does not analyze code, write files, or compose prose — it prints a rendered block verbatim and cannot answer anything the block does not already contain. Do NOT route a natural-language question here, not even "is there a threat model?" / "gibt es hier ein bedrohungsmodell?" — every question goes to ask-threat-model, which answers directly and can produce this block too.

2026-07-1816

review-threat-model

matthiasrohr/appsec-advisor

User-facing triage of an existing threat model — an overview-first console over an already-generated threat-model.yaml (backlog by priority, severity mix, worst-case scenarios), then one of three modes. "Just look around" browses findings read-only by severity, security aspect, requirement, or control posture. "Fix or accept findings now" applies the code fix for findings you pick — or accepts the risk instead — one at a time for review. "Build a remediation plan" decides mitigate / accept-risk per finding and emits a remediation-plan.md without code changes. Within a session you can also discuss a single finding by id (F-/T-/M-/W-), a read-only aside that changes nothing. Runs later and independently of create-threat-model; reads the model, never regenerates or re-scores it. Not an artifact-quality check (that is eval-threat-model). To only *ask* about the model without acting on it, use ask-threat-model.

2026-07-1816

update-threat-model

matthiasrohr/appsec-advisor

Convenience alias for create-threat-model in incremental mode — re-analyzes only the components that changed since the last run. Unlike the bare create-threat-model, it does NOT bootstrap — it aborts with a clear message when no threat model exists yet, so an "update" can never silently turn into a first full assessment. An explicit mode flag the user passes (--full, --rebuild, --rerender, --resume) is honored instead of the injected --incremental. Everything else (flags, --repo, --output, behavior, output) is identical to create-threat-model.

2026-07-1816

audit-security-requirements

matthiasrohr/appsec-advisor

Audit the current repository against a security requirements catalog and verify whether each requirement is implemented. Requirement IDs follow your catalog's own naming scheme (e.g. SEC-CSP-1, SCG-HARDENXML, or anything your YAML defines); tagging code with those IDs is optional and not required. Prints open requirements to the conversation with color-coded status and concise evidence. Optionally saves Markdown/PDF reports. With --json or --gate it also persists a deterministic structured verdict (.requirements-audit.json) and can act as a CI gate.

2026-07-1716

name

diagnose-bundle

description

diagnose-bundle

This is a maintainer/dev skill — never auto-triggered, not part of create-threat-model, and it needs no new permissions (read-only triage of a file the maintainer chose to open).

Step 1 — Parse arguments

BUNDLE (required) — path to the appsec-diag-*.tgz (or an already-unpacked bundle dir). If absent, ask the user for it and stop.

Step 2 — Resolve `CLAUDE_PLUGIN_ROOT`

if [ -z "$CLAUDE_PLUGIN_ROOT" ]; then
  CLAUDE_PLUGIN_ROOT=$(find /root /home /opt -maxdepth 6 \
    -path "*/appsec-advisor/skills/diagnose-bundle/SKILL.md" \
    2>/dev/null | head -1 | xargs -r dirname | xargs -r dirname | xargs -r dirname)
fi
export CLAUDE_PLUGIN_ROOT
if [ -z "$CLAUDE_PLUGIN_ROOT" ] || [ ! -d "$CLAUDE_PLUGIN_ROOT" ]; then
  echo "Error: CLAUDE_PLUGIN_ROOT could not be resolved." >&2
  exit 2
fi

Step 3 — Deterministic inspect (facts into context)

Read the bundle in memory — do NOT tar -x it to disk; a hand-crafted bundle could path-traverse on extraction. inspect reads it safely.

python3 "$CLAUDE_PLUGIN_ROOT/scripts/diagnostic_bundle.py" inspect \
  --bundle "$BUNDLE" --logs 40
INSPECT_EXIT=$?
[ "$INSPECT_EXIT" -ne 0 ] && { echo "diagnose-bundle: inspect failed ($INSPECT_EXIT)"; exit "$INSPECT_EXIT"; }

Step 4 — Cross-reference the plugin source

Phase/component → producer. Map the phase to its phase-group file under agents/phases/ and the script that runs there (e.g. Phase 9/merge → scripts/build_threat_model_yaml.py; compose → compose_threat_model.py). Use AGENTS.md → "Phase and stage map", the phase-group headings, and each agent's frontmatter for its role and turn budget.
Error signature → code. Grep the repo for the distinctive tokens of the scrubbed last error (schema enum names, function names, event names) across scripts/, schemas/, agents/. The <str>/<path> placeholders are redactions — match on the unredacted skeleton around them.
Known-bug history. Check the auto-memory index (MEMORY.md) for a prior occurrence of this signature (e.g. schema-drift FATALs, STRIDE inline-shortcut → empty output, budget-flag poisoning). A match is strong evidence and usually carries the fix location.

Step 5 — Report (print, do not write files)

Emit exactly these fields, each grounded in a bundle fact or a repo file:line:

WHERE         <phase> / <component> / <producer script:line>
ROOT CAUSE    <hypothesis, tied to the last_error + an inventory/counts anomaly>
EVIDENCE      <the bundle fact(s)> + <repo file:line or memory entry>
CHECK NEXT    <the producer file/function to read to confirm>
REPRO         <smallest way to reproduce — e.g. threat_fixture replay, a crafted sidecar, a unit test>
CONFIDENCE    high | medium | low  (low if the bundle underdetermines the cause)

Rules:

If the bundle underdetermines the cause, say so and state which additional non-sensitive field would disambiguate (so we can widen collect) — do not guess past the evidence.
Never ask the user for their source or results; the bundle is deliberately finding-free and the diagnosis must work without them.

diagnose-bundle

diagnose-bundle

Step 1 — Parse arguments

Step 2 — Resolve CLAUDE_PLUGIN_ROOT

Step 3 — Deterministic inspect (facts into context)

Step 4 — Cross-reference the plugin source

Step 5 — Report (print, do not write files)

More from this repository

More from this repository

diagnose-bundle

Step 1 — Parse arguments

Step 2 — Resolve CLAUDE_PLUGIN_ROOT

Step 3 — Deterministic inspect (facts into context)

Step 4 — Cross-reference the plugin source

Step 5 — Report (print, do not write files)

Step 2 — Resolve `CLAUDE_PLUGIN_ROOT`

Step 2 — Resolve `CLAUDE_PLUGIN_ROOT`