Agents & Skills

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 — health-checks a URL if you supplied one, follows the startup or deploy method if you described one, and otherwise works the startup out from the repository, brings the app up locally, and tells you which method it picked.
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), and establishes how a fix will reach the running target before scanning anything.
2. For each confirmed finding: traces the data flow to the vulnerable sink, applies the smallest fix, gets it into the running target — a restart, or a rebuild-and-redeploy where the target runs a built artifact — confirms the target actually carries the change, and re-runs the same scan.
3. Repeats up to 5 rounds until findings are gone or the round limit is reached.
4. Reports which findings were fixed (with proof), which fixes went unvalidated, and which findings 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

Can the loop close?

The remediation loop's product is a proved fix, which means the edited code has to reach the running target before the validation scan. The agent works out whether that's possible before spending the baseline scan:

When the loop can't close, the agent stops before the baseline scan, says validation will be skipped, and lets you choose: supply a redeploy command, point it at an instance you control, continue with fixes explicitly labelled unverified, or stop after the scan and take the findings without any code changes.

⚠️

Validation is never skipped silently. A finding that stopped appearing is only reported as fixed when the same scan ran against the fixed code; anything else is labelled unverified.

Skills

Both agents compose their workflow from these skills:

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:

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.
• After each fix round the agent health-checks the target and re-verifies auth, so a change that breaks the application surfaces before the validation scan rather than being reported as a fix.
• Auth objects are verified in unsaved form and only written to the project once they work, so failed attempts leave nothing behind.
• A Repeater created for the session, and any process the agent started, are cleaned up when the run finishes.