/opfor-setup

name: opfor-setup
description: Set up an agent or chatbot target for Opfor red-teaming.

Opfor — target configuration

Configure a target for an Opfor assessment. When this skill is **installed in the user’s repo**, prefer **reading that repo** (endpoints, `opfor.config*`, env examples, telemetry) **before** a long questionnaire; then collect **only** what is still unknown.

1. Target Information

Ask the user about their target (or pre-fill from repo scan when obvious):

• **Name** — what do they call it? (e.g., "Support Bot")
• **Type** — what kind of system? (`chatbot`, `api`, `agent`, `rag-pipeline`)
• **Endpoint** — how to reach it? (URL, `local`, or a description)
• **Model** — what model powers it, if known? (optional)

2. Target Type

Ask the user which integration method they want to use. Discover available options by scanning `./targets/` for `.md` files. Default to `http-endpoint`.

3. Auto-Detect Application Context (Optional)

End users often **pull this skill into their own repo**. Treat that repo as the source of truth: **scan it first**, then **only ask for what you cannot infer** (and never ask anyone to paste **secret** API keys, tokens, or passwords into chat).

**Capabilities vary by environment:**

With filesystem access (Claude Code, Cursor, Windsurf, local agents):

Full code repo scanning available:

1. **Markdown documentation** (highest priority):

• `Agents.md` — architecture and design docs
• `README.md` — project overview
• `ARCHITECTURE.md` — system design
• `docs/`, `docs/system-prompt.md` — system prompt docs

2. **Code scanning** (if no markdown docs found):

• System prompts in comments (e.g., `// SYSTEM_PROMPT:`, `<!-- SYSTEM PROMPT -->`)
• Configuration files (`.env`, `config.json`, `config.yaml`)
• Constants and docstrings defining purpose, scope, permissions
• Comments explaining sensitive data handling
• Risk/security sections in code comments
• Environment variables and their meanings

3. **File structure analysis**:

• Endpoint patterns (for API targets)
• Package names and descriptions
• Database models (to infer sensitive data)
• Permission/role definitions

4. **Telemetry and observability (scan before asking the user)** Assume the project may already export traces (Langfuse, Netra, OpenTelemetry, Sentry, etc.). **Discover; do not interrogate** unless something is ambiguous or missing.

**Where to look:**

• `opfor.config.json`, `opfor.config.yml`, `opfor.config.yaml` — any `telemetry` block (provider, Langfuse/Netra options, propagation config, trace list limits, etc.)
• `.env`, `.env.local`, `.env.development`, `.env.example`, `docker-compose*.yml`, Helm charts, Terraform, `.github/workflows/*` — variable **names** such as `LANGFUSE_PUBLIC_KEY`, `LANGFUSE_SECRET_KEY`, `LANGFUSE_BASE_URL`, `NETRA_API_KEY`, `NETRA_BASE_URL`, `OTEL_*`, `SENTRY_*` (read examples for docs; avoid echoing real secret values into the transcript)
• `package.json` / lockfiles — packages like `@langfuse/tracing`, `langfuse`, `netra-sdk`, OpenTelemetry SDKs
• Application code — imports and init of Langfuse/Netra/OTEL, middleware that sets trace or correlation headers, exporters, `trace.getActiveSpan`, `startActiveSpan`
• Service READMEs or runbooks mentioning observability dashboards or trace IDs

**What to extract (for later config / attack grounding):**

• Which observability product appears in use (if any): `"langfuse"`, `"netra"`, or `"none"`
• Base URL or which **env var name** holds the API origin (not the secret value)
• Which **env var names** hold credentials (never ask the user to type secrets into chat; instruct them to set vars locally or in CI)
• Whether the target accepts a `trace_id` field in request body (or similar propagation field) — if so, note the field name for `propagation.traceIdBodyField`. If no such field exists in the target's request schema, note this: tell the user that judge enrichment from traces won't work unless they add trace ID propagation to their agent (reading the injected field and forwarding it to the telemetry SDK as the active OTel trace ID)
• Any Opfor-specific limits already in `opfor.config` (`listLimit`, `listMaxPages`, trace summary size caps, etc.)

Without filesystem access (web Claude, API-only agents, etc.):

Limited to what the user has already shared in the conversation:

• Documentation they've pasted into chat
• Code snippets they've shown
• System prompts they've described
• Context from previous messages
• If they mention Langfuse/telemetry, ask for **redacted** config snippets or env **names** only — not live secrets

**Graceful degradation:** If no auto-detectable information is found (regardless of environment), the skill simply falls back to asking the user interactively.

**Extract information about:**

• What the system does (purpose, scope)
• User types and access levels
• Types of sensitive data handled
• Critical or dangerous operations
• Forbidden topics or constraints
• System prompt (if documented or found in code)
• **Telemetry**: provider, how auth is wired (env var names), trace propagation hints (from repo scan above)

**Confirmation Flow:** If auto-detection found any information (from docs or code), present it as prefilled:

🔍 I scanned your repo and found documentation.

Pre-filled Application Context:
  Purpose:        [extracted from Agents.md line 5]
  User Types:     [extracted from README.md line 23]
  Sensitive Data: [extracted from code comments]
  Dangerous Ops:  [extracted from config]
  Forbidden:      [extracted from README.md]
  System Prompt:  [extracted from system-prompt.md]

Pre-filled Telemetry (from repo — no secret values shown):
  Observability:    [detected provider, e.g. "langfuse" or "netra" — from opfor.config + package.json]
  API origin:       [env var name holding the base URL, e.g. LANGFUSE_BASE_URL or NETRA_BASE_URL]
  Auth:             [env var name(s) holdin