
Strix
- 228 installs
- 40 repo stars
- Updated August 4, 2026
- akillness/oh-my-skills
Run pre-ship security review and hardening for game clients, backends, or agent tools before public Steam or web release.
About
Security-focused oh-my-skills entry for Strix-style pre-ship audits: map trust boundaries in game or agent stacks, test auth and API endpoints, flag secret leaks, review third-party dependencies, and produce actionable fixes before launch approval.
- Pre-release threat modeling
- Client and API attack-surface review
- Secrets and credential hygiene
- Dependency and supply-chain checks
- Ship gate security recommendations
Strix by the numbers
- 228 all-time installs (skills.sh)
- Ranked #724 of 2,203 Security skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/akillness/oh-my-skills --skill strixAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 228 |
|---|---|
| repo stars | ★ 40 |
| Last updated | August 4, 2026 |
| Repository | akillness/oh-my-skills ↗ |
What it does
Run pre-ship security review and hardening for game clients, backends, or agent tools before public Steam or web release.
Files
strix - AI-Driven Application Security Testing
Keyword:strix·ai pentest·vulnerability scan cli·strix ci
>
Only use Strix against systems you own or are explicitly authorized to test.
Strix is an AI-driven application security CLI. It runs scans inside a Docker-backed sandbox, uses an LLM provider for reasoning, and can assess local directories, GitHub repositories, live URLs, domains, and multi-target combinations.
When to use this skill
- Install Strix and verify Docker plus sandbox readiness
- Configure
STRIX_LLM,LLM_API_KEY, optionalLLM_API_BASE, and related runtime settings - Run local white-box scans against a repository or directory
- Run black-box or grey-box scans against staging or production-like URLs you are authorized to test
- Pass credentials, scope, or rules of engagement with
--instructionor--instruction-file - Choose the right scan depth:
quick,standard, ordeep - Run Strix headlessly in CI/CD and interpret exit codes
- Understand Strix's internal security "skills" and how they differ from this repo's skills
Instructions
Step 1: Install and preflight
1. Run bash scripts/install.sh 2. Confirm strix --version succeeds 3. Ensure Docker is installed and the daemon is running 4. Let the installer pull the sandbox image on first setup unless you intentionally skip it 5. For manual installation alternatives and direct commands, see references/commands.md
Step 2: Configure the model provider
Set the minimum required environment variables before running a scan:
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"Optional runtime variables:
LLM_API_BASEfor OpenAI-compatible proxies or local endpointsPERPLEXITY_API_KEYfor web search during scansSTRIX_REASONING_EFFORTto tune model effortSTRIX_DISABLE_BROWSER=truewhen UI automation is unnecessarySTRIX_TELEMETRY=0to disable telemetry defaults
Provider examples, config-file format, and optional environment variables are in references/providers-and-config.md.
Step 3: Pick the target and scan mode
Strix accepts these target types:
- Local directory:
./app - GitHub repository URL:
https://github.com/org/repo - Live web app URL:
https://staging.example.com - Domain or IP
- Multi-target scans via repeated
--targetor-t
Scan modes:
quick: PR checks, smoke tests, fast CI feedbackstandard: routine security reviewsdeep: default full assessment and longer bug-bounty-style exploration
Detailed mode and CI guidance lives in references/scan-modes-and-ci.md.
Step 4: Run the scan
Use bash scripts/run-scan.sh for a repeatable wrapper or call strix directly.
Common direct commands:
strix --target ./app
strix --target https://github.com/org/repo
strix --target https://staging.example.com --instruction-file ./instruction.md
strix -t https://github.com/org/repo -t https://staging.example.comWhen authenticated or scoped testing matters, prefer --instruction-file over long inline prompts so credentials, exclusions, and rules of engagement stay explicit and reviewable.
Step 5: Review outputs and iterate
Strix stores results under strix_runs/<run-name>.
Exit codes to remember:
0: completed without findings1: execution or environment error2: vulnerabilities found in headless mode
Use the run artifacts to confirm what Strix tested, what it found, and what needs revalidation after fixes.
Step 6: Automate in CI/CD
Use headless mode in automation:
strix -n --target ./ --scan-mode quickCI runners need Docker access. For pull requests, default to quick; reserve standard or deep for scheduled or release-stage jobs. See references/scan-modes-and-ci.md and scripts/ci-scan.sh.
Step 7: Understand Strix internal skills
Strix has its own internal security knowledge packs under strix/skills/. They are not the same as this repo's agent skills.
- Strix auto-selects up to 5 relevant internal skills per task
- Categories include vulnerabilities, frameworks, technologies, protocols, and tooling
- These internal skills enrich Strix agent behavior during the scan itself
See references/built-in-skills.md before assuming "skill" means the same thing across both ecosystems.
Examples
Example 1: Quick PR scan of a local repository
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"
strix -n --target ./ --scan-mode quickExample 2: Standard scan of a GitHub repository
strix --target https://github.com/acme/payments --scan-mode standardExample 3: Grey-box scan of a staging URL
strix --target https://staging.example.com \
--instruction-file ./instruction.md \
--scan-mode deepExample 4: Combined repo plus live target
strix -t https://github.com/acme/payments \
-t https://staging.example.com \
--instruction "Correlate source paths with exposed runtime issues"Example 5: Browser-disabled API-focused scan
STRIX_DISABLE_BROWSER=true \
strix --target https://api.example.com --scan-mode standardExample 6: Scripted run wrapper
bash scripts/run-scan.sh \
--target ./app \
--scan-mode quick \
--non-interactiveBest practices
1. Only test assets you own or are explicitly permitted to assess. 2. Start with quick in CI and widen depth only when signal justifies the extra runtime. 3. Keep secrets in environment variables, secret stores, or instruction files under your control instead of scattering them inline. 4. Use both source and live targets together when you need better reproduction and remediation context. 5. Expect the first run to be slower because Strix may pull its sandbox image. 6. Treat strix_runs/ as evidence: archive useful runs, especially when findings are heading into triage or remediation. 7. Be explicit about scope, exclusions, credentials, and rate limits so Strix does not waste time exploring irrelevant surfaces. 8. Distinguish this repo's strix skill from Strix internal skills to avoid instruction confusion.
References
- references/commands.md
- references/providers-and-config.md
- references/scan-modes-and-ci.md
- references/built-in-skills.md
- scripts/install.sh
- scripts/run-scan.sh
- scripts/ci-scan.sh
- Strix GitHub Repository
- Strix Documentation
{
"skill_name": "strix",
"evals": [
{
"id": 1,
"prompt": "Strix로 우리 로컬 저장소를 빠르게 PR 보안 점검하고 싶어.",
"expected_output": "The skill installs or verifies Strix, requires Docker, configures STRIX_LLM, and uses headless quick scan syntax.",
"assertions": [
"The response includes `strix -n --target ./ --scan-mode quick` or an equivalent quick CI command",
"The response requires Docker to be available",
"The response mentions `STRIX_LLM` configuration"
]
},
{
"id": 2,
"prompt": "GitHub 리포지토리랑 스테이징 URL을 같이 넣어서 Strix로 검사하고 싶어.",
"expected_output": "The skill supports repeated targets and shows a multi-target command with both source and runtime surfaces.",
"assertions": [
"The response uses repeated `--target` or `-t` arguments",
"The response supports both a GitHub repository URL and a live URL in the same workflow"
]
},
{
"id": 3,
"prompt": "인증 필요한 테스트라 계정 정보랑 제외 범위를 Strix에 넘기고 싶어.",
"expected_output": "The skill recommends `--instruction` or `--instruction-file` and keeps scope explicit.",
"assertions": [
"The response mentions `--instruction` or `--instruction-file`",
"The response treats credentials and exclusions as explicit scoped input"
]
},
{
"id": 4,
"prompt": "GitHub Actions에서 Strix 돌릴 건데 취약점 나오면 실패하게 하고 싶어.",
"expected_output": "The skill explains CI headless mode, exit codes, and provides a GitHub Actions-friendly command.",
"assertions": [
"The response mentions exit code `2` for findings",
"The response uses headless mode with `-n` or `--non-interactive`",
"The response is compatible with GitHub Actions or CI runners"
]
},
{
"id": 5,
"prompt": "Strix 내부 skill이랑 여기 jeo-skills의 skill이 같은 개념이야?",
"expected_output": "The skill clearly distinguishes Strix internal markdown knowledge packs from this repo's agent skills.",
"assertions": [
"The response states they are different systems",
"The response mentions Strix internal skill categories or examples"
]
}
]
}
Strix Built-In Skills
Source: strix/skills/ and https://docs.strix.ai/advanced/skillsLast reviewed: 2026-03-28
Important distinction
This repo's strix skill teaches an external AI agent how to operate the Strix CLI.
Strix itself also has internal skills. Those live inside the Strix project and are injected into Strix agents during a scan. They are not installed through jeo-skills.
How Strix uses internal skills
- Strix selects up to 5 relevant internal skills for a task
- The selected skill files are injected into the agent context
- This gives Strix specialized tactics, payloads, and validation guidance for the target
Confirmed categories
Vulnerabilities
Examples:
authentication_jwtidorsql_injectionxssssrfcsrfxxebusiness_logicrace_conditions
Frameworks
Examples:
fastapinextjs
Technologies
Examples:
supabasefirebase_firestore
Protocols
Examples:
graphql
Tooling
Examples:
nmapnucleihttpxffufsubfindernaabukatanasqlmap
Related runtime tool model
Strix agents can combine internal skills with these runtime tools:
- Browser automation via Playwright-powered Chrome
- HTTP proxying and replay through a Caido-backed proxy
- Persistent bash terminals in the sandbox
- Python runtime for custom validation or exploit code
- File editing, notes, reporting, and optional web search
Why this matters for this skill
When you prepare a Strix scan, give it targets, scope, credentials, exclusions, and focus areas. Do not try to manually micromanage every vulnerability trick that Strix internal skills already provide.
Instead:
1. Set the correct target mix 2. Pick the right scan mode 3. Provide precise instructions and authorization boundaries 4. Let Strix choose the internal skills that match the task
Strix Commands
Source: https://docs.strix.ai and https://github.com/usestrix/strix
Last reviewed: 2026-03-28
Prerequisites
- Docker installed and running
- Strix CLI installed
STRIX_LLMconfigured- Provider authentication available through
LLM_API_KEYor provider-native auth
Installation
Official install script
curl -sSL https://strix.ai/install | bashpipx install
pipx install strix-agentVerify installation
strix --versionMinimum environment
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"Core scan commands
Local directory
strix --target ./app-directoryGitHub repository
strix --target https://github.com/org/repoLive web app
strix --target https://your-app.comMulti-target
strix -t https://github.com/org/repo -t https://your-app.comAuthenticated or scoped testing
strix --target https://app.com --instruction "Use credentials from the approved test account"
strix --target https://app.com --instruction-file ./instruction.mdHeadless CI run
strix -n --target ./ --scan-mode quickKey flags
| Flag | Meaning |
|---|---|
--target, -t | Add a target. Can be repeated. |
--instruction | Inline scope, credentials, or focus hints. |
--instruction-file | File-based instructions. Prefer this for longer scope documents. |
--scan-mode, -m | quick, standard, or deep. |
--non-interactive, -n | Headless mode for CI/CD. |
--config | Use a custom JSON config file instead of ~/.strix/cli-config.json. |
Output and exit codes
- Results are written under
strix_runs/<run-name> 0: no vulnerabilities found1: execution or environment error2: vulnerabilities found in headless mode
Notes
- The first run may pull the sandbox image and take longer
- Keep credentials and scope restrictions explicit
- Only use Strix against authorized targets
Strix Providers And Configuration
Source: https://docs.strix.ai/advanced/configuration and provider docs
Last reviewed: 2026-03-28
Required variables
| Variable | Purpose |
|---|---|
STRIX_LLM | LiteLLM-style model selector such as openai/gpt-5.4 |
LLM_API_KEY | API key for the chosen provider when required |
Common optional variables
| Variable | Purpose |
|---|---|
LLM_API_BASE | OpenAI-compatible proxy or local endpoint |
PERPLEXITY_API_KEY | Enables Strix web search during scans |
STRIX_REASONING_EFFORT | none, minimal, low, medium, high, xhigh |
STRIX_DISABLE_BROWSER | Disable browser automation when UI testing is unnecessary |
STRIX_TELEMETRY | Global telemetry toggle |
STRIX_IMAGE | Override sandbox image |
STRIX_RUNTIME_BACKEND | Runtime backend, default docker |
LLM_TIMEOUT | LLM request timeout in seconds |
OpenAI example
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="sk-..."Anthropic example
export STRIX_LLM="anthropic/claude-sonnet-4-6"
export LLM_API_KEY="sk-ant-..."Vertex AI example
export STRIX_LLM="vertex_ai/gemini-3-pro-preview"Use your cloud environment's standard Google auth instead of LLM_API_KEY when applicable.
Local or proxy-hosted model example
export STRIX_LLM="ollama/llama4"
export LLM_API_BASE="http://localhost:11434"Config file
Default config path:
~/.strix/cli-config.jsonCustom config example:
{
"env": {
"STRIX_LLM": "openai/gpt-5.4",
"LLM_API_KEY": "sk-...",
"STRIX_REASONING_EFFORT": "high"
}
}Run with a custom file:
strix --target ./app --config /path/to/config.jsonLocal telemetry artifacts
Even without remote OTEL export, Strix keeps run telemetry locally:
strix_runs/<run-name>/events.jsonlRecommendations
1. Pin STRIX_LLM explicitly in CI instead of relying on a saved local config. 2. Store LLM_API_KEY in a secret manager or CI secret store. 3. Disable the browser only when you are sure UI navigation is not needed. 4. Keep telemetry and remote trace settings intentional, especially on regulated targets.
Strix Scan Modes And CI
Source: https://docs.strix.ai/usage/scan-modes and CI integration docs
Last reviewed: 2026-03-28
Scan modes
| Mode | Typical duration | Best for |
|---|---|---|
quick | Minutes | Pull requests, smoke tests, fast CI gates |
standard | ~30 to 60 minutes | Routine security reviews, pre-release validation |
deep | ~1 to 4 hours | Comprehensive audits, release reviews, longer assessments |
deep is the upstream default. In automation, do not inherit that default blindly; choose the mode deliberately.
Recommended policy
- PR or per-commit checks:
quick - Nightly or milestone scans:
standard - Release candidate or high-risk review:
deep
Headless mode
Use headless mode in automation:
strix -n --target ./ --scan-mode quickCI requirements
- Docker access is required
STRIX_LLMmust be set- Provider auth must be available through environment variables or cloud auth
Exit codes
| Code | Meaning |
|---|---|
0 | Completed without findings |
1 | Execution or environment error |
2 | Findings detected in headless mode |
GitHub Actions example
name: Strix Security Scan
on:
pull_request:
jobs:
strix-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install Strix
run: curl -sSL https://strix.ai/install | bash
- name: Run Strix
env:
STRIX_LLM: ${{ secrets.STRIX_LLM }}
LLM_API_KEY: ${{ secrets.LLM_API_KEY }}
run: strix -n -t ./ --scan-mode quickGeneric CI checklist
1. Install Strix non-interactively 2. Ensure Docker is usable on the runner 3. Export STRIX_LLM 4. Inject provider auth securely 5. Run strix -n with an explicit scan mode 6. Archive strix_runs/ if you need run evidence
Common mistakes
- Running
deepon every PR and turning feedback into a bottleneck - Forgetting Docker on the runner
- Treating exit code
2like a crash instead of a findings signal - Passing long credentials inline when an instruction file or CI secret is safer
#!/usr/bin/env bash
set -euo pipefail
TARGET="${1:-./}"
MODE="${STRIX_SCAN_MODE:-quick}"
if [[ -z "${STRIX_LLM:-}" ]]; then
echo "STRIX_LLM must be set in CI." >&2
exit 1
fi
if ! command -v strix >/dev/null 2>&1; then
echo "Strix is not installed on this runner." >&2
exit 1
fi
if ! command -v docker >/dev/null 2>&1 || ! docker info >/dev/null 2>&1; then
echo "Docker must be available on the CI runner." >&2
exit 1
fi
exec strix -n --target "$TARGET" --scan-mode "$MODE"
#!/usr/bin/env bash
set -euo pipefail
VERSION_VALUE=""
SKIP_IMAGE=false
SKIP_DOCKER_CHECK=false
STRIX_IMAGE_DEFAULT="${STRIX_IMAGE:-ghcr.io/usestrix/strix-sandbox:0.1.13}"
usage() {
cat <<'EOF'
Usage: bash scripts/install.sh [options]
Options:
--version <version> Install a specific Strix release version
--skip-image Skip pulling the sandbox image
--skip-docker-check Skip Docker preflight checks
-h, --help Show this help
EOF
}
need_cmd() {
if ! command -v "$1" >/dev/null 2>&1; then
echo "Missing required command: $1" >&2
exit 1
fi
}
while [[ $# -gt 0 ]]; do
case "$1" in
--version)
VERSION_VALUE="${2:-}"
if [[ -z "$VERSION_VALUE" ]]; then
echo "--version requires a value" >&2
exit 1
fi
shift 2
;;
--skip-image)
SKIP_IMAGE=true
shift
;;
--skip-docker-check)
SKIP_DOCKER_CHECK=true
shift
;;
-h|--help)
usage
exit 0
;;
*)
echo "Unknown argument: $1" >&2
usage >&2
exit 1
;;
esac
done
need_cmd curl
if ! command -v strix >/dev/null 2>&1; then
echo "Installing Strix..."
if [[ -n "$VERSION_VALUE" ]]; then
env VERSION="$VERSION_VALUE" bash -lc 'curl -sSL https://strix.ai/install | bash'
else
bash -lc 'curl -sSL https://strix.ai/install | bash'
fi
else
echo "Strix already present on PATH; skipping binary install."
fi
if ! command -v strix >/dev/null 2>&1; then
echo "Strix installation failed or the binary is not on PATH." >&2
exit 1
fi
echo "Installed version:"
strix --version || true
if [[ "$SKIP_DOCKER_CHECK" == true ]]; then
exit 0
fi
need_cmd docker
if ! docker info >/dev/null 2>&1; then
echo "Docker is installed but the daemon is not running." >&2
exit 1
fi
if [[ "$SKIP_IMAGE" == false ]]; then
if docker image inspect "$STRIX_IMAGE_DEFAULT" >/dev/null 2>&1; then
echo "Sandbox image already present: $STRIX_IMAGE_DEFAULT"
else
echo "Pulling sandbox image: $STRIX_IMAGE_DEFAULT"
docker pull "$STRIX_IMAGE_DEFAULT"
fi
fi
cat <<'EOF'
Next steps:
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"
bash scripts/run-scan.sh --target ./app --scan-mode quick --dry-run
EOF
#!/usr/bin/env bash
set -euo pipefail
MODE=""
NON_INTERACTIVE=false
BROWSER_OFF=false
DRY_RUN=false
CONFIG_FILE=""
INSTRUCTION=""
INSTRUCTION_FILE=""
declare -a TARGETS=()
declare -a EXTRA_ARGS=()
usage() {
cat <<'EOF'
Usage: bash scripts/run-scan.sh --target <target> [options] [-- extra strix args]
Options:
--target, -t <target> Add a target. Repeat for multi-target scans.
--scan-mode, -m <mode> quick | standard | deep
--instruction <text> Inline scope or credential instructions
--instruction-file <file> File-based instructions
--config <file> Custom Strix config file
--non-interactive, -n Headless mode
--browser-off Export STRIX_DISABLE_BROWSER=true for this run
--dry-run Print the command without executing
-h, --help Show this help
EOF
}
while [[ $# -gt 0 ]]; do
case "$1" in
--target|-t)
TARGETS+=("${2:-}")
shift 2
;;
--scan-mode|-m)
MODE="${2:-}"
shift 2
;;
--instruction)
INSTRUCTION="${2:-}"
shift 2
;;
--instruction-file)
INSTRUCTION_FILE="${2:-}"
shift 2
;;
--config)
CONFIG_FILE="${2:-}"
shift 2
;;
--non-interactive|-n)
NON_INTERACTIVE=true
shift
;;
--browser-off)
BROWSER_OFF=true
shift
;;
--dry-run)
DRY_RUN=true
shift
;;
--)
shift
EXTRA_ARGS+=("$@")
break
;;
-h|--help)
usage
exit 0
;;
*)
echo "Unknown argument: $1" >&2
usage >&2
exit 1
;;
esac
done
if ! command -v strix >/dev/null 2>&1; then
echo "Strix is not installed. Run bash scripts/install.sh first." >&2
exit 1
fi
if [[ ${#TARGETS[@]} -eq 0 ]]; then
echo "At least one --target is required." >&2
exit 1
fi
if ! command -v docker >/dev/null 2>&1 || ! docker info >/dev/null 2>&1; then
echo "Docker must be available and running before invoking Strix." >&2
exit 1
fi
if [[ -z "${STRIX_LLM:-}" ]]; then
echo "Warning: STRIX_LLM is not set. Strix may fail without an explicit model configuration." >&2
fi
declare -a CMD=(strix)
for target in "${TARGETS[@]}"; do
CMD+=(--target "$target")
done
if [[ -n "$MODE" ]]; then
CMD+=(--scan-mode "$MODE")
fi
if [[ -n "$INSTRUCTION" ]]; then
CMD+=(--instruction "$INSTRUCTION")
fi
if [[ -n "$INSTRUCTION_FILE" ]]; then
CMD+=(--instruction-file "$INSTRUCTION_FILE")
fi
if [[ -n "$CONFIG_FILE" ]]; then
CMD+=(--config "$CONFIG_FILE")
fi
if [[ "$NON_INTERACTIVE" == true ]]; then
CMD+=(--non-interactive)
fi
if [[ ${#EXTRA_ARGS[@]} -gt 0 ]]; then
CMD+=("${EXTRA_ARGS[@]}")
fi
if [[ "$BROWSER_OFF" == true ]]; then
export STRIX_DISABLE_BROWSER=true
fi
printf 'Running:' >&2
for part in "${CMD[@]}"; do
printf ' %q' "$part" >&2
done
printf '\n' >&2
if [[ "$DRY_RUN" == true ]]; then
exit 0
fi
exec "${CMD[@]}"
Experiment 0 - baseline
Score: 5/6 Change: Initial draft only. Reasoning: Establish the starting point before any prompt mutation. Result: Covered install, scan modes, and target types, but CI outcome handling was not explicit enough. Remaining failures: Exit-code behavior needed to be stated directly, not implied.
Experiment 1 - keep
Score: 6/6 Change: Added explicit exit-code guidance, stronger CI defaults, and a dedicated Strix internal-skills distinction. Reasoning: The main risk was operator confusion around CI outcomes and the overloaded word "skill." Result: All six binary evals passed. Remaining failures: None in the current eval suite.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Strix Skill Autoresearch</title>
<style>
:root {
color-scheme: light;
--bg: #f7f3ec;
--panel: #fffdf9;
--ink: #1f1f1f;
--muted: #6c665d;
--line: #ddd2c2;
--accent: #0f766e;
--warn: #a16207;
}
body {
margin: 0;
font-family: ui-sans-serif, system-ui, sans-serif;
background: radial-gradient(circle at top, #fffaf1 0%, var(--bg) 60%);
color: var(--ink);
}
main {
max-width: 960px;
margin: 0 auto;
padding: 32px 20px 48px;
}
h1, h2 {
margin: 0 0 12px;
}
p {
color: var(--muted);
}
.grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
gap: 16px;
margin: 24px 0;
}
.card {
background: var(--panel);
border: 1px solid var(--line);
border-radius: 16px;
padding: 16px;
box-shadow: 0 10px 30px rgba(31, 31, 31, 0.06);
}
table {
width: 100%;
border-collapse: collapse;
background: var(--panel);
border: 1px solid var(--line);
border-radius: 16px;
overflow: hidden;
}
th, td {
text-align: left;
padding: 12px 14px;
border-bottom: 1px solid var(--line);
vertical-align: top;
}
th {
background: #f2eadf;
}
.pill {
display: inline-block;
border-radius: 999px;
padding: 4px 10px;
font-size: 12px;
font-weight: 700;
}
.keep {
background: rgba(15, 118, 110, 0.12);
color: var(--accent);
}
.baseline {
background: rgba(161, 98, 7, 0.12);
color: var(--warn);
}
code {
font-family: ui-monospace, SFMono-Regular, monospace;
}
</style>
</head>
<body>
<main>
<h1>Strix Skill Autoresearch</h1>
<p>Baseline versus final mutation log for <code>.agent-skills/strix/SKILL.md</code>.</p>
<div id="summary" class="grid"></div>
<h2>Experiments</h2>
<table>
<thead>
<tr>
<th>Experiment</th>
<th>Status</th>
<th>Score</th>
<th>Description</th>
</tr>
</thead>
<tbody id="rows"></tbody>
</table>
</main>
<script type="application/json" id="fallback-data">
{
"skill_name": "strix",
"status": "complete",
"updated_at": "2026-03-28T03:15:00Z",
"experiments": [
{
"experiment": 0,
"score": 5,
"max_score": 6,
"pass_rate": 0.8333,
"status": "baseline",
"description": "Initial draft emphasized install, targets, and scan modes but only implied CI exit-code behavior and internal-skill separation."
},
{
"experiment": 1,
"score": 6,
"max_score": 6,
"pass_rate": 1.0,
"status": "keep",
"description": "Kept mutation: added explicit exit codes, CI framing, and a dedicated internal-skills step with its own reference file."
}
]
}
</script>
<script>
const fallback = JSON.parse(document.getElementById("fallback-data").textContent);
async function loadData() {
try {
const response = await fetch("results.json", { cache: "no-store" });
if (!response.ok) throw new Error("Failed to load results.json");
return await response.json();
} catch {
return fallback;
}
}
function metric(label, value) {
const el = document.createElement("section");
el.className = "card";
el.innerHTML = `<strong>${label}</strong><div>${value}</div>`;
return el;
}
function render(data) {
const summary = document.getElementById("summary");
const rows = document.getElementById("rows");
const first = data.experiments[0];
const last = data.experiments[data.experiments.length - 1];
summary.append(
metric("Skill", data.skill_name),
metric("Status", data.status),
metric("Baseline", `${first.score}/${first.max_score}`),
metric("Final", `${last.score}/${last.max_score}`)
);
for (const exp of data.experiments) {
const tr = document.createElement("tr");
tr.innerHTML = `
<td>${exp.experiment}</td>
<td><span class="pill ${exp.status === "keep" ? "keep" : "baseline"}">${exp.status}</span></td>
<td>${exp.score}/${exp.max_score} (${Math.round(exp.pass_rate * 100)}%)</td>
<td>${exp.description}</td>
`;
rows.appendChild(tr);
}
}
loadData().then(render);
</script>
</body>
</html>
{
"skill_name": "strix",
"status": "complete",
"updated_at": "2026-03-28T03:15:00Z",
"evals": [
{
"id": "authorized-use",
"question": "Does the skill restrict Strix usage to authorized targets?"
},
{
"id": "docker-and-provider",
"question": "Does the skill require Docker and explain provider configuration?"
},
{
"id": "target-coverage",
"question": "Does the skill cover local paths, GitHub repositories, live URLs, and multi-target scans?"
},
{
"id": "ci-and-exit-codes",
"question": "Does the skill explain headless CI usage and exit codes 0, 1, and 2?"
},
{
"id": "reference-support",
"question": "Does the skill point to scripts and detailed references instead of burying everything in one file?"
},
{
"id": "internal-skills-distinction",
"question": "Does the skill explain that Strix internal skills are different from jeo-skills?"
}
],
"experiments": [
{
"experiment": 0,
"score": 5,
"max_score": 6,
"pass_rate": 0.8333,
"status": "baseline",
"description": "Initial draft emphasized install, targets, and scan modes but only implied CI exit-code behavior and internal-skill separation.",
"kept": true,
"per_eval": {
"authorized-use": true,
"docker-and-provider": true,
"target-coverage": true,
"ci-and-exit-codes": false,
"reference-support": true,
"internal-skills-distinction": true
}
},
{
"experiment": 1,
"score": 6,
"max_score": 6,
"pass_rate": 1.0,
"status": "keep",
"description": "Kept mutation: added explicit exit codes, CI framing, and a dedicated internal-skills step with its own reference file.",
"kept": true,
"per_eval": {
"authorized-use": true,
"docker-and-provider": true,
"target-coverage": true,
"ci-and-exit-codes": true,
"reference-support": true,
"internal-skills-distinction": true
}
}
]
}
experiment score max_score pass_rate status description
0 5 6 0.8333 baseline Initial draft covered install and execution but under-specified exit-code handling and the distinction between Strix internal skills and jeo-skills.
1 6 6 1.0000 keep Added explicit exit-code guidance, stronger CI recommendations, and a dedicated step plus reference for Strix internal skills.
---
name: strix
description: >
Install and use Strix for AI-driven security scans against local projects,
repositories, and authorized web targets. Use when you need Strix setup, scan
mode selection, or CI execution guidance. Triggers on: strix, appsec scan,
vulnerability scan cli, strix ci, ai pentest.
allowed-tools: Bash Read Write Edit Glob Grep WebFetch
compatibility: Requires Docker access and an LLM provider or compatible endpoint.
license: Apache-2.0
metadata:
tags: strix, appsec, pentest, vulnerability-scan, ci-cd, docker, llm
version: "0.1-baseline"
source: https://github.com/usestrix/strix
---
# strix - AI-Driven Application Security Testing
Only use Strix against systems you own or are explicitly authorized to test.
## When to use this skill
- Install Strix and verify Docker access
- Configure a model provider for Strix
- Run scans against local directories, repositories, or URLs
- Use quick, standard, or deep scan modes
- Run Strix in CI
## Instructions
1. Install Strix with `bash scripts/install.sh` or `curl -sSL https://strix.ai/install | bash`
2. Configure `STRIX_LLM` and `LLM_API_KEY`
3. Run `strix --target ./app`
4. Use `--scan-mode quick|standard|deep` as needed
5. Use `-n` for CI/CD
6. Review results in `strix_runs/<run-name>`
## Examples
### Local scan
```bash
strix --target ./app
```
### GitHub repository
```bash
strix --target https://github.com/org/repo
```
### CI scan
```bash
strix -n --target ./ --scan-mode quick
```
## Best practices
1. Keep Docker running before you start.
2. Prefer quick scans in CI.
3. Keep credentials explicit when a target requires authentication.
## References
- [references/commands.md](../references/commands.md)
- [references/providers-and-config.md](../references/providers-and-config.md)
N:strix
D:[strix] Install, configure, and operate Strix for AI-driven application security testing. Covers local directories, GitHub repositories, live URLs, multi-target scans, LLM provider setup, Docker sandbox preflight, scan modes, headless CI/CD, and Strix internal skill awareness.
G:strix appsec pentest vulnerability-scan ci-cd docker llm security-testing bug-bounty browser-automation
U[8]:
Install Strix and verify Docker plus sandbox readiness
Configure STRIX_LLM, LLM_API_KEY, LLM_API_BASE, and optional runtime flags
Run white-box scans against local repos or directories
Run black-box or grey-box scans against authorized URLs, domains, or IPs
Pass credentials and scope using --instruction or --instruction-file
Choose quick, standard, or deep based on speed versus coverage
Run headless scans in CI/CD and interpret exit codes 0, 1, and 2
Explain Strix internal skills and how they differ from jeo-skills
S[6]{n,action,details}:
1,Install,bash scripts/install.sh OR curl -sSL https://strix.ai/install | bash
2,Configure,export STRIX_LLM=openai/gpt-5.4 && export LLM_API_KEY=your-api-key
3,Target,choose local path GitHub repo URL live URL domain IP or repeated --target entries
4,Scan,run strix directly or bash scripts/run-scan.sh with --scan-mode quick|standard|deep
5,Review,inspect strix_runs/<run-name> and use exit codes 0=no findings 1=error 2=findings
6,Automate,use -n in CI and prefer quick for pull requests with Docker-enabled runners
R[8]:
Only test assets you own or are explicitly authorized to assess
Docker is mandatory for the local CLI workflow and first run may pull the sandbox image
Use --instruction-file for credentials scope exclusions and rules of engagement
Default CI scans to quick; reserve standard or deep for scheduled or release gates
Keep secrets in env vars or CI secrets instead of scattering them inline
Combine source and live targets when you need better remediation context
Distinguish this repo's strix skill from Strix internal skills under strix/skills
Optional flags worth knowing: PERPLEXITY_API_KEY STRIX_DISABLE_BROWSER STRIX_REASONING_EFFORT STRIX_TELEMETRY
E[6]{type,command}:
Install,bash scripts/install.sh
Local repo,strix --target ./app --scan-mode standard
GitHub repo,strix --target https://github.com/org/repo
Authenticated target,strix --target https://staging.example.com --instruction-file ./instruction.md
Multi-target,strix -t https://github.com/org/repo -t https://staging.example.com
CI quick scan,strix -n --target ./ --scan-mode quick