Agents & Skills

The orchestration agents and building-block skills that power the STAR Plugin

The STAR Plugin ships orchestration agents and reusable skills. The agents drive end-to-end workflows; the skills are the building blocks they call internally. You interact with agents — the skills run behind the scenes.

This page is the canonical inventory: the agents are listed below, the skills in the table further down. Other pages link here rather than repeating the list.

Agents

bright-application-testing

Scans the application and reports findings. Does not modify your code.

What it does:

  1. Analyzes the repository — detects languages, frameworks, routes, and API specs.
  2. Reaches the target — starts the app locally or health-checks a supplied URL.
  3. Configures Bright — resolves the project, creates a Repeater for private/local targets.
  4. Detects and configures authentication automatically.
  5. Registers the attack surface (entrypoints) safely — excludes endpoints with irreversible side effects.
  6. Runs dynamic scans and returns a structured findings report grouped by severity and endpoint.

Use when: you want to know what's exposed — during development, before a merge, or against a staging environment.


bright-remediation-loop

Scans, fixes, and proves the fix. Modifies your code.

What it does:

  1. Runs the same preparation as bright-application-testing (analyze → reach → configure → register → scan).
  2. For each confirmed finding: traces the data flow to the vulnerable sink, applies the smallest fix, restarts the app, and re-scans.
  3. Repeats up to 5 rounds until findings are gone or the round limit is reached.
  4. Reports which findings were fixed (with proof) and which remain open.

Use when: you want vulnerabilities fixed and the fix proved — not just a patch, but evidence that the same scan no longer reproduces the issue.


When to use which

bright-application-testingbright-remediation-loop
GoalScan and reportScan, fix, and verify
Touches your codeNoYes
Requires redeploy capabilityNoYes (needs to restart the app after each fix)
OutputFindings reportFindings + verified fixes + proof
Reach for it whenYou want to know what's exposedYou want it fixed and the fix proved
⚠️

The remediation loop needs a way to restart the target after applying fixes. If it can't redeploy, it stops and asks before spending a scan — rather than handing you unverified patches.

Skills

Both agents compose their workflow from these skills:

SkillPurpose
analyze-codebaseDetect tech stack, discover routes/endpoints, identify what's safe to fuzz
setup-repeaterCreate and start a Bright Repeater for private/local targets
setup-authDetect auth mechanisms (JWT, API keys, sessions, OAuth) and build a working auth object
register-entrypointsRegister discovered endpoints in Bright — manually or via discovery
run-scanSelect tests per endpoint, launch scans, monitor, and retrieve findings
fix-and-validateTrace findings to code, apply fixes, restart, and re-scan to confirm (remediation-loop only)

Workflow diagram

flowchart TD
    A[analyze-codebase] --> B[setup-repeater]
    B --> C[setup-auth]
    C --> D[register-entrypoints]
    D --> E[run-scan]
    E --> F{Findings?}
    F -->|No| G[Done — clean]
    F -->|Yes, application-testing| H[Report findings]
    F -->|Yes, remediation-loop| I[fix-and-validate]
    I --> J{Re-scan clean?}
    J -->|Yes| K[Done — fixed & proved]
    J -->|No, rounds left| I
    J -->|No, limit reached| L[Report remaining]

How skills use MCP tools

Each skill maps to one or more Bright MCP tools:

SkillMCP tools used
setup-repeatercreateRepeater, listRepeaters, deleteRepeater
setup-authaddAuth, testAuth, editAuth, listAuths
register-entrypointsaddEntrypoint, listEntrypoints, runDiscovery, uploadApiDefinition
run-scanrunScan, getScanStatus, listScanVulnerabilities, getScanVulnerability, listTests
fix-and-validateSame as run-scan + code editing via the IDE

Safety

  • Only targets the user owns or is explicitly authorized to test are scanned.
  • Endpoints with irreversible side effects are excluded from the attack surface.
  • The remediation agent keeps edits minimal — no broad refactors, no placeholder code.
  • If a fix breaks the app, the agent detects it and reverts before proposing.
  • A Repeater created for the session is cleaned up when the run finishes.

What’s Next

Did this page help you?