Built-in workflows and marketplace
open·kritt currently comes with two workflows already installed. They appear on the Workflows page when the system starts, so you can inspect their steps and run a scan without building every prompt from scratch.
Built-in workflows are starting points, not black boxes. Read their prompts and output schemas, check that their assumptions fit the codebase and configuration you are scanning, and adapt the pattern when your target needs something more specific.
External flow analysis
The included external-flow-analysis workflow follows externally controlled input from
its production entrypoint to concrete security-sensitive behavior:
Enumerate entrypoints
Scan the codebase once to identify externally reachable entrypoints and the handlers that process attacker-controlled input.
Trace reachable flows
For each entrypoint, enumerate materially different production paths, including validation outcomes, authorization boundaries, state changes, external calls, and sensitive sinks.
Investigate each flow
Give each downstream agent one reachable flow to verify against the source. It returns only concrete vulnerabilities with a supported attacker path, or a no-finding stub.
This decomposition saves context. Entrypoints and flows are mapped once, while each final agent spends its context window on one concrete path. The workflow is intentionally general; clone or edit it when a target needs explicit impact categories such as node crash, consensus failure, or loss of funds.
Cosmos ABCI panic halt review
Cosmos ABCI Panic Halt Review targets Go-based Cosmos applications where a panic in a
production ABCI path could halt consensus:
Enumerate ABCI methods
Prove which ABCI methods and phase handlers are wired into the production application, recording their runtime inputs and registration paths.
Investigate panic classes
Fan out four focused reviews for each reachable method: explicit panic calls, arithmetic panics, nil pointer panics, and bounds or type panics.
Each investigator returns only maliciously triggerable, production-reachable halt paths. Use this workflow for Cosmos SDK or CometBFT targets; the general external-flow workflow is a better starting point for other application stacks.
Open workflow marketplace
We plan to add an open workflow marketplace where researchers and teams can publish, discover, install, fork, and improve workflows. The goal is to make proven research patterns reusable while keeping every workflow inspectable and adaptable to a target.
The marketplace is upcoming. Until it is available, use the built-in workflows or create your own in the workflow builder.