flounder

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: flounder
description: >
  Operates Flounder, an autonomous white-hat security auditor. Use when a user
  asks for a security audit, bug-bounty review, vulnerability investigation, or
  exploit proof for a public-source or authorized repository, source tree, package, smart
  contract, Solidity/EVM project, ZK or proof-system code, deployed address,
  transaction, project link, or prior Flounder run; to run Flounder prepare,
  map, dig, audit, verify, confirm, or report workflows; to configure Flounder server,
  daemon, provider profiles, model auth, sandboxed execution, corpus paths,
  source paths, build roots, coverage, or budgets; to monitor live audit activity, continue
  pending scopes, verify suspected vulnerabilities, reproduce findings, or
  collect execution-backed bug reports; or when a Flounder maintainer asks an
  agent to improve auditor recall, analyze Evaluation failures, run governed
  Harness experiments, modify Flounder source in an isolated branch, or prepare
  a candidate improvement PR.
---

# Flounder

This skill is the operating manual for Flounder-driven security audits.

Flounder is an autonomous white-hat security auditor. The agent prepares the
target, audits source, constructs exploit paths, runs local proof tests,
confirms real findings, and packages reports. The framework provides the
daemon, sandbox, command policy, run tracking, live activity, and execution
gates.

## Skill Files

| File | When to read |
| --- | --- |
| `SKILL.md` | Always after this skill triggers. It is the operating playbook. |
| `reference/commands.md` | Exact CLI, REST, provider, daemon, budget, output, and pi extension details. |
| `reference/examples.md` | Concrete Solidity/EVM and ZK examples. |
| `reference/product.md` | Dashboard, project lifecycle, run phases, tracking, and artifact model. |
| `reference/safety.md` | White-hat policy, sandbox boundary, evidence ladder, and public-release hygiene. |
| `reference/maintainer-harness.md` | Maintainer-only agent workflow for Evaluation-driven source improvement and candidate PRs. |

Use progressive disclosure: open only the reference file needed for the current
task. Do not duplicate long command references into the conversation when a
short command and status summary is enough.

## What This Skill Must Do

- Turn a security-audit request into a public-source or authorized Flounder project or run.
- Keep the operator on the current workflow: `run <clue>` lets Flounder prepare
  the target, then map/dig/synthesize/verify, confirm, and report; `run --source`
  is the source-provided entry path for sealed map/dig/synthesize/verify.
- Prefer the dashboard/API control plane for project work so state, daemon
  ownership, live logs, findings, and reports stay durable.
- Preserve the evidence ladder: suspected, locally confirmed, real-target
  reproduced, submission-ready. Do not collapse these into one "bug" bucket.
- Use run health and discovery backlog rows when judging progress: a shallow
  or resource-blocked zero-finding run is not a negative result, and follow-up
  scopes should stay as pending coverage rather than becoming findings.
- Separate machine noise from active work by marking dismissed findings
  `ignored`, never by deleting them.
- Stop with a clear next action or blocker; do not call an audit complete just
  because a command exited.

## Core Audit Modes

Choose the mode from the user's intent before launching anything:

| User intent | Mode | Preparation path | Guardrail |
| --- | --- | --- | --- |
| "Do a blind audit / test Flounder's capability / no hints" | Blind capability audit | Recommended: `flounder run <project-or-repo-or-package-link>` or a dashboard project with a factual target clue. If source is already staged or external preparation is explicitly unwanted, use `flounder run --source <paths...> --build-root <root>`. | Do not add incident docs, known bug names, exploit theories, or answer-bearing corpus. Official target docs are allowed onl