Building a capability

Tell the platform agent what you’d like packaged. It runs a short research pass, sends back a written proposal, and — once you approve — writes the capability, validates it, and hands it back ready to use. A few minutes of conversation, no manifest editing, no scaffolding decisions you don’t want to make.

01 Describe 02 Approve 03 Try 04 Iterate 05 Publish

› I'd like to build a capability for Android APK vulnerability hunting at scale.

· skill creating-capabilities

· skill research-capabilities

· bash dn capability list --search "android apk" --include-public

· web_search OWASP MASVS MASTG Android app security testing static analysis

· read builtin_capabilities/dreadnode/capability.yaml

Got it — you want a reusable Dreadnode capability for Android APK vulnerability hunting at scale, not just one-off APK reversing. I treated this as a ship-it capability request, so I did Phase 1: Gather & Propose only and did not write files yet.

PREMISE: build an android-apk-vuln-hunter capability that batch-triages APKs with OWASP MASVS/MASTG groundings, surfaces semantic logic bugs that rule-based scanners miss, and ships skills for corpus prep, targeted assessment, and scanner baselines.

› Open to approach, but I'm primarily interested in impactful logical bugs identified at scale in common APKs that would have been missed by traditional scanners.

· web_search Android app business logic vulnerability deep link account takeover

· web_extract oversecured.com/blog/android-deep-link-vulnerabilities

That changes the center of gravity a lot. I would not make MobSF/APKHunt-style scanner aggregation the main capability anymore. For your goal, the capability should be an agentic semantic vulnerability discovery pipeline — corpus-scale APK inventory, targeted assessment with jadx/apktool/semgrep, and triage skills that grade findings by impact, not by signature count.

@dreadnode · dreadnode session Opus 4 (Medium)

^A agent^O show more ^K model^⇧K reasoning

>

62.8k/1M tok · $0.40 · ? help

✓ local · demo/default ^P^B^W^R^T^E

What you're trading

You’re spending a few minutes of conversation in exchange for an installable artifact your whole team can dn capability install <org>/<name>. The agent does the manifest, the skills, the checks, the validation, and the push — you steer the brief.

The hero above walks the first phase end to end; here’s what happens behind each beat and how to steer it.

Describe

goal → research → proposal

You type a one- or two-sentence goal and stop. The agent loads two built-in skills — creating-capabilities and research-capabilities — and works from those playbooks instead of improvising. It checks the public catalog so it doesn’t rebuild something you could install, reads a few existing capabilities for shape, and runs a parallel research pass across the domain. When it comes back, it announces the contract in its own words — Phase 1: Gather & Propose only — and hands you a written brief: capability name, skills, scripts, host-CLI checks.

If the framing matches your intent, approve. If not, redirect with one sentence. The cost of a redirect is another research round — a handful of focused searches and an article fetch or two — not a rewrite. Iterate until the premise lands. Nothing has been written.

Sometimes the answer is install, not build

If the catalog check surfaces a public capability that already does your job, the agent will say so. Don’t build parallel infrastructure when dn capability install <org>/<name> is one command away.

Approve

files written + validated + loaded

A short approval is enough. The agent re-opens the capability skill’s own references, scaffolds the directory in your workspace, exercises what it wrote, and symlinks it into the runtime’s capability dir on the way out.

› sounds good

· read creating-capabilities/references/manifest.md

· read creating-capabilities/references/writing-skills.md

· read creating-capabilities/references/quality-bar.md

· bash mkdir -p android-apk-research/{skills,scripts,tools,references}

· write android-apk-research/capability.yaml

· write skills/android-semantic-vuln-hunting/SKILL.md

· write scripts/run_corpus_inventory.py

· write tools/apk_semantic.py

· bash python3 -m py_compile scripts/*.py tools/*.py

· bash dn capability validate ./android-apk-research --strict

· bash python3 tools/apk_semantic.py --help

· bash dn capability install ./android-apk-research

Built, validated, and installed android-apk-research at ~/.dreadnode/capabilities/android-apk-research → ./android-apk-research. Manifest checks pass, scripts compile, the tool answers --help. Ready to load.

What lands on disk is a single self-contained directory:

android-apk-research/

├── capability.yaml manifest + host CLI checks

├── skills/ methodology, loaded by name

├── scripts/ orchestration

├── references/ docs the agent reads on demand

└── tools/ Python functions, exposed to the agent

“Installed” means more than “files exist.” Before the agent stops, it runs the validation chain on what it wrote — python3 -m py_compile on the scripts, dn capability validate ./<name> --strict on the manifest, and a quick --help execution on at least one tool against a fixture. The final dn capability install ./<name> symlinks the source directory into ~/.dreadnode/capabilities/ so the runtime discovers it on the next load — and so your edits to the source pick up live, no re-install needed.

Most of the time the agent runs install as the last step on its own. If it stops at “built and validated” without installing, ask it to — install it is enough.

Pick it up in the TUI without restarting:

› /reload

Open the capability manager (Ctrl+P), find it on the Installed tab, and press Enter for the detail view — every skill, every host-CLI check, and the path the manager is reading from.

A failing check renders with a red ✗ next to the component name. Fix the host (install the missing CLI), don’t fix the check — checks are a contract with the runtime, not a CI substitute.

Try

skill loads → methodology runs

Start a fresh session, enable the capability, and hand the agent something real. The skill loads and the methodology runs — no further prompting needed.

› Will you use all of our latest materials and tools against the corpus we have downloaded?

· skill android-apk-research:android-semantic-vuln-hunting

· read skills/android-semantic-vuln-hunting/SKILL.md

· bash ls corpus/androzoo/apks-84/*.apk | wc -l

· apk_semantic_attack_surface paths=corpus/androzoo/apks-84/

· bash jadx -d /tmp/jadx-out --no-res ./corpus/androzoo/apks-84/com.example.apk

Phase 1 inventory: 97 APKs in 62s. Ranking by semantic_priority and shortlisting the top three banking/payment targets for the targeted-assessment skill next.

Watch what the agent reaches for. If it skips a step you’d take, runs a tool with defaults that don’t match how you’d use it, or grades a finding more aggressively than you would — note it. You’ll address it in the next phase.

Checks belong on host CLIs, not bundled code

Good checks ask whether a CLI is installed (command -v jadx) and run in milliseconds. Don’t ask checks to compile your bundled scripts — that’s a CI job. Checks fail loud at runtime; CI fails noisy at the right time.

Iterate

talk → backprop → reload

When something’s off, say it in any session. The agent edits the capability files in place — you don’t open the directory.

› Backprop the lessons we learned about JADX heap sizing and React Native runtime detection into the capability. Stay focused on the most impactful triage at scale.

· read skills/android-semantic-vuln-hunting/SKILL.md

· read references/android-scanner-baseline/scanners.md

· multiedit skills/android-semantic-vuln-hunting/SKILL.md

· multiedit skills/android-targeted-assessment/SKILL.md

· edit references/android-scanner-baseline/scanners.md

· write scripts/detect_runtime_kind.sh

· bash chmod +x scripts/detect_runtime_kind.sh && ./scripts/detect_runtime_kind.sh fixtures/trust-wallet.apk

Folded the runtime-detection helper into android-targeted-assessment Step 7.5 and bumped the JADX heap tier table in android-semantic-vuln-hunting. Smoke run against the Trust Wallet fixture passes.

The skills, manifest, scripts, and references grow in place as you find gaps. Each session picks up the updated capability the same way the first one picked up the original — /reload and you’re on the new version.

Publish

bump → push → install by name

Once the capability is doing what you want, push it to the registry so teammates can install it by name. Tell the agent and it bumps the version, validates, and pushes for you.

› Bump to 0.2.0 and push it to our org registry.

· edit capability.yaml — version: 0.1.0 → 0.2.0

· bash dn capability validate ./android-apk-research --strict

· bash dn capability push ./android-apk-research

Pushed acme/[email protected] (sha256:8c2a…). Visibility is org-only — anyone in acme can dn capability install acme/[email protected]. Add --publish if you want it in the public catalog.

Three things to know about what just happened:

• Versions are immutable. Once 0.2.0 is on the registry, that bundle never changes. Iterating after a push means bumping to 0.2.1 and pushing again — the old version stays installable for anyone pinned to it.
• Visibility is per name, not per version. Private to your org by default. --publish flips the whole capability family into the public Dreadnode catalog; dn capability unpublish <name> flips it back. There is no per-team or per-workspace scope — it’s org-only or public.
• Anyone pulling from the registry gets a validated, frozen snapshot. The push runs the same dn capability validate your agent did locally, and the manifest paths it references must exist on disk or the push fails.

If you prefer the keyboard:

dn capability push ./android-apk-research              # private to your org
dn capability push ./android-apk-research --publish    # public catalog
dn capability install acme/[email protected]

See Publishing for the full visibility model, --force rules, and SDK push, and Installing for the three install paths (local symlink, frozen copy, registry pull).

Branches and decisions

• proposal close but not right — refine in conversation; don’t open the capability directory and start editing files, you’ll lose the agent’s context about why a skill is shaped a certain way
• agent surfaces an existing public capability that covers your job — install it; the proposal phase is the right time to make this call
• a check fails on your machine but the workflow runs by hand — look at the check command first; command -v <tool> is robust, relative-path commands are not
• you want to share with a single team, not the whole org — there is no team scope; keep it private to the org and share the install command, or publish public if the workflow isn’t sensitive

What’s next

You have a working capability. The next move is putting it in front of more inputs to harden the methodology — and eventually, against a pinned dataset so the improvements compound.

Capabilities

Quickstart by hand

Manifest reference

Writing skills

Publishing

Installing