strix-agent 0.4.0__py3-none-any.whl → 0.6.2__py3-none-any.whl

strix/runtime/tool_server.py

@@ -2,11 +2,9 @@ from __future__ import annotations
 
 import argparse
 import asyncio
-import logging
 import os
 import signal
 import sys
-from multiprocessing import Process, Queue
 from typing import Any
 
 import uvicorn
@@ -23,17 +21,22 @@ parser = argparse.ArgumentParser(description="Start Strix tool server")
 parser.add_argument("--token", required=True, help="Authentication token")
 parser.add_argument("--host", default="0.0.0.0", help="Host to bind to")  # nosec
 parser.add_argument("--port", type=int, required=True, help="Port to bind to")
+parser.add_argument(
+    "--timeout",
+    type=int,
+    default=120,
+    help="Hard timeout in seconds for each request execution (default: 120)",
+)
 
 args = parser.parse_args()
 EXPECTED_TOKEN = args.token
+REQUEST_TIMEOUT = args.timeout
 
 app = FastAPI()
 security = HTTPBearer()
-
 security_dependency = Depends(security)
 
-agent_processes: dict[str, dict[str, Any]] = {}
-agent_queues: dict[str, dict[str, Queue[Any]]] = {}
+agent_tasks: dict[str, asyncio.Task[Any]] = {}
 
 
 def verify_token(credentials: HTTPAuthorizationCredentials) -> str:
@@ -65,60 +68,19 @@ class ToolExecutionResponse(BaseModel):
     error: str | None = None
 
 
-def agent_worker(_agent_id: str, request_queue: Queue[Any], response_queue: Queue[Any]) -> None:
-    null_handler = logging.NullHandler()
-
-    root_logger = logging.getLogger()
-    root_logger.handlers = [null_handler]
-    root_logger.setLevel(logging.CRITICAL)
-
-    from strix.tools.argument_parser import ArgumentConversionError, convert_arguments
+async def _run_tool(agent_id: str, tool_name: str, kwargs: dict[str, Any]) -> Any:
+    from strix.tools.argument_parser import convert_arguments
+    from strix.tools.context import set_current_agent_id
     from strix.tools.registry import get_tool_by_name
 
-    while True:
-        try:
-            request = request_queue.get()
-
-            if request is None:
-                break
-
-            tool_name = request["tool_name"]
-            kwargs = request["kwargs"]
-
-            try:
-                tool_func = get_tool_by_name(tool_name)
-                if not tool_func:
-                    response_queue.put({"error": f"Tool '{tool_name}' not found"})
-                    continue
-
-                converted_kwargs = convert_arguments(tool_func, kwargs)
-                result = tool_func(**converted_kwargs)
-
-                response_queue.put({"result": result})
+    set_current_agent_id(agent_id)
 
-            except (ArgumentConversionError, ValidationError) as e:
-                response_queue.put({"error": f"Invalid arguments: {e}"})
-            except (RuntimeError, ValueError, ImportError) as e:
-                response_queue.put({"error": f"Tool execution error: {e}"})
+    tool_func = get_tool_by_name(tool_name)
+    if not tool_func:
+        raise ValueError(f"Tool '{tool_name}' not found")
 
-        except (RuntimeError, ValueError, ImportError) as e:
-            response_queue.put({"error": f"Worker error: {e}"})
-
-
-def ensure_agent_process(agent_id: str) -> tuple[Queue[Any], Queue[Any]]:
-    if agent_id not in agent_processes:
-        request_queue: Queue[Any] = Queue()
-        response_queue: Queue[Any] = Queue()
-
-        process = Process(
-            target=agent_worker, args=(agent_id, request_queue, response_queue), daemon=True
-        )
-        process.start()
-
-        agent_processes[agent_id] = {"process": process, "pid": process.pid}
-        agent_queues[agent_id] = {"request": request_queue, "response": response_queue}
-
-    return agent_queues[agent_id]["request"], agent_queues[agent_id]["response"]
+    converted_kwargs = convert_arguments(tool_func, kwargs)
+    return await asyncio.to_thread(tool_func, **converted_kwargs)
 
 
 @app.post("/execute", response_model=ToolExecutionResponse)
@@ -127,20 +89,42 @@ async def execute_tool(
 ) -> ToolExecutionResponse:
     verify_token(credentials)
 
-    request_queue, response_queue = ensure_agent_process(request.agent_id)
+    agent_id = request.agent_id
+
+    if agent_id in agent_tasks:
+        old_task = agent_tasks[agent_id]
+        if not old_task.done():
+            old_task.cancel()
 
-    request_queue.put({"tool_name": request.tool_name, "kwargs": request.kwargs})
+    task = asyncio.create_task(
+        asyncio.wait_for(
+            _run_tool(agent_id, request.tool_name, request.kwargs), timeout=REQUEST_TIMEOUT
+        )
+    )
+    agent_tasks[agent_id] = task
 
     try:
-        loop = asyncio.get_event_loop()
-        response = await loop.run_in_executor(None, response_queue.get)
+        result = await task
+        return ToolExecutionResponse(result=result)
+
+    except asyncio.CancelledError:
+        return ToolExecutionResponse(error="Cancelled by newer request")
+
+    except TimeoutError:
+        return ToolExecutionResponse(error=f"Tool timed out after {REQUEST_TIMEOUT}s")
+
+    except ValidationError as e:
+        return ToolExecutionResponse(error=f"Invalid arguments: {e}")
 
-        if "error" in response:
-            return ToolExecutionResponse(error=response["error"])
-        return ToolExecutionResponse(result=response.get("result"))
+    except (ValueError, RuntimeError, ImportError) as e:
+        return ToolExecutionResponse(error=f"Tool execution error: {e}")
 
-    except (RuntimeError, ValueError, OSError) as e:
-        return ToolExecutionResponse(error=f"Worker error: {e}")
+    except Exception as e:  # noqa: BLE001
+        return ToolExecutionResponse(error=f"Unexpected error: {e}")
+
+    finally:
+        if agent_tasks.get(agent_id) is task:
+            del agent_tasks[agent_id]
 
 
 @app.post("/register_agent")
@@ -148,8 +132,6 @@ async def register_agent(
     agent_id: str, credentials: HTTPAuthorizationCredentials = security_dependency
 ) -> dict[str, str]:
     verify_token(credentials)
-
-    ensure_agent_process(agent_id)
     return {"status": "registered", "agent_id": agent_id}
 
 
@@ -160,35 +142,16 @@ async def health_check() -> dict[str, Any]:
         "sandbox_mode": str(SANDBOX_MODE),
         "environment": "sandbox" if SANDBOX_MODE else "main",
         "auth_configured": "true" if EXPECTED_TOKEN else "false",
-        "active_agents": len(agent_processes),
-        "agents": list(agent_processes.keys()),
+        "active_agents": len(agent_tasks),
+        "agents": list(agent_tasks.keys()),
     }
 
 
-def cleanup_all_agents() -> None:
-    for agent_id in list(agent_processes.keys()):
-        try:
-            agent_queues[agent_id]["request"].put(None)
-            process = agent_processes[agent_id]["process"]
-
-            process.join(timeout=1)
-
-            if process.is_alive():
-                process.terminate()
-                process.join(timeout=1)
-
-            if process.is_alive():
-                process.kill()
-
-        except (BrokenPipeError, EOFError, OSError):
-            pass
-        except (RuntimeError, ValueError) as e:
-            logging.getLogger(__name__).debug(f"Error during agent cleanup: {e}")
-
-
 def signal_handler(_signum: int, _frame: Any) -> None:
-    signal.signal(signal.SIGPIPE, signal.SIG_IGN) if hasattr(signal, "SIGPIPE") else None
-    cleanup_all_agents()
+    if hasattr(signal, "SIGPIPE"):
+        signal.signal(signal.SIGPIPE, signal.SIG_IGN)
+    for task in agent_tasks.values():
+        task.cancel()
     sys.exit(0)
 
 
@@ -199,7 +162,4 @@ signal.signal(signal.SIGTERM, signal_handler)
 signal.signal(signal.SIGINT, signal_handler)
 
 if __name__ == "__main__":
-    try:
-        uvicorn.run(app, host=args.host, port=args.port, log_level="info")
-    finally:
-        cleanup_all_agents()
+    uvicorn.run(app, host=args.host, port=args.port, log_level="info")

strix/skills/README.md

@@ -0,0 +1,64 @@
+# 📚 Strix Skills
+
+## 🎯 Overview
+
+Skills are specialized knowledge packages that enhance Strix agents with deep expertise in specific vulnerability types, technologies, and testing methodologies. Each skill provides advanced techniques, practical examples, and validation methods that go beyond baseline security knowledge.
+
+---
+
+## 🏗️ Architecture
+
+### How Skills Work
+
+When an agent is created, it can load up to 5 specialized skills relevant to the specific subtask and context at hand:
+
+```python
+# Agent creation with specialized skills
+create_agent(
+    task="Test authentication mechanisms in API",
+    name="Auth Specialist",
+    skills="authentication_jwt,business_logic"
+)
+```
+
+The skills are dynamically injected into the agent's system prompt, allowing it to operate with deep expertise tailored to the specific vulnerability types or technologies required for the task at hand.
+
+---
+
+## 📁 Skill Categories
+
+| Category | Purpose |
+|----------|---------|
+| **`/vulnerabilities`** | Advanced testing techniques for core vulnerability classes like authentication bypasses, business logic flaws, and race conditions |
+| **`/frameworks`** | Specific testing methods for popular frameworks e.g. Django, Express, FastAPI, and Next.js |
+| **`/technologies`** | Specialized techniques for third-party services such as Supabase, Firebase, Auth0, and payment gateways |
+| **`/protocols`** | Protocol-specific testing patterns for GraphQL, WebSocket, OAuth, and other communication standards |
+| **`/cloud`** | Cloud provider security testing for AWS, Azure, GCP, and Kubernetes environments |
+| **`/reconnaissance`** | Advanced information gathering and enumeration techniques for comprehensive attack surface mapping |
+| **`/custom`** | Community-contributed skills for specialized or industry-specific testing scenarios |
+
+---
+
+## 🎨 Creating New Skills
+
+### What Should a Skill Contain?
+
+A good skill is a structured knowledge package that typically includes:
+
+- **Advanced techniques** - Non-obvious methods specific to the task and domain
+- **Practical examples** - Working payloads, commands, or test cases with variations
+- **Validation methods** - How to confirm findings and avoid false positives
+- **Context-specific insights** - Environment and version nuances, configuration-dependent behavior, and edge cases
+
+Skills use XML-style tags for structure and focus on deep, specialized knowledge that significantly enhances agent capabilities for that specific context.
+
+---
+
+## 🤝 Contributing
+
+Community contributions are more than welcome — contribute new skills via [pull requests](https://github.com/usestrix/strix/pulls) or [GitHub issues](https://github.com/usestrix/strix/issues) to help expand the collection and improve extensibility for Strix agents.
+
+---
+
+> [!NOTE]
+> **Work in Progress** - We're actively expanding the skills collection with specialized techniques and new categories.

strix/skills/__init__.py

@@ -0,0 +1,110 @@
+from jinja2 import Environment
+
+from strix.utils.resource_paths import get_strix_resource_path
+
+
+def get_available_skills() -> dict[str, list[str]]:
+    skills_dir = get_strix_resource_path("skills")
+    available_skills: dict[str, list[str]] = {}
+
+    if not skills_dir.exists():
+        return available_skills
+
+    for category_dir in skills_dir.iterdir():
+        if category_dir.is_dir() and not category_dir.name.startswith("__"):
+            category_name = category_dir.name
+            skills = []
+
+            for file_path in category_dir.glob("*.jinja"):
+                skill_name = file_path.stem
+                skills.append(skill_name)
+
+            if skills:
+                available_skills[category_name] = sorted(skills)
+
+    return available_skills
+
+
+def get_all_skill_names() -> set[str]:
+    all_skills = set()
+    for category_skills in get_available_skills().values():
+        all_skills.update(category_skills)
+    return all_skills
+
+
+def validate_skill_names(skill_names: list[str]) -> dict[str, list[str]]:
+    available_skills = get_all_skill_names()
+    valid_skills = []
+    invalid_skills = []
+
+    for skill_name in skill_names:
+        if skill_name in available_skills:
+            valid_skills.append(skill_name)
+        else:
+            invalid_skills.append(skill_name)
+
+    return {"valid": valid_skills, "invalid": invalid_skills}
+
+
+def generate_skills_description() -> str:
+    available_skills = get_available_skills()
+
+    if not available_skills:
+        return "No skills available"
+
+    all_skill_names = get_all_skill_names()
+
+    if not all_skill_names:
+        return "No skills available"
+
+    sorted_skills = sorted(all_skill_names)
+    skills_str = ", ".join(sorted_skills)
+
+    description = f"List of skills to load for this agent (max 5). Available skills: {skills_str}. "
+
+    example_skills = sorted_skills[:2]
+    if example_skills:
+        example = f"Example: {', '.join(example_skills)} for specialized agent"
+        description += example
+
+    return description
+
+
+def load_skills(skill_names: list[str], jinja_env: Environment) -> dict[str, str]:
+    import logging
+
+    logger = logging.getLogger(__name__)
+    skill_content = {}
+    skills_dir = get_strix_resource_path("skills")
+
+    available_skills = get_available_skills()
+
+    for skill_name in skill_names:
+        try:
+            skill_path = None
+
+            if "/" in skill_name:
+                skill_path = f"{skill_name}.jinja"
+            else:
+                for category, skills in available_skills.items():
+                    if skill_name in skills:
+                        skill_path = f"{category}/{skill_name}.jinja"
+                        break
+
+                if not skill_path:
+                    root_candidate = f"{skill_name}.jinja"
+                    if (skills_dir / root_candidate).exists():
+                        skill_path = root_candidate
+
+            if skill_path and (skills_dir / skill_path).exists():
+                template = jinja_env.get_template(skill_path)
+                var_name = skill_name.split("/")[-1]
+                skill_content[var_name] = template.render()
+                logger.info(f"Loaded skill: {skill_name} -> {var_name}")
+            else:
+                logger.warning(f"Skill not found: {skill_name}")
+
+        except (FileNotFoundError, OSError, ValueError) as e:
+            logger.warning(f"Failed to load skill {skill_name}: {e}")
+
+    return skill_content

strix/{prompts → skills}/frameworks/nextjs.jinja

@@ -31,6 +31,18 @@
 </high_value_targets>
 
 <advanced_techniques>
+<route_enumeration>
+- __BUILD_MANIFEST.sortedPages: Execute `console.log(__BUILD_MANIFEST.sortedPages.join('\n'))` in browser console to instantly reveal all registered routes (Pages Router and static App Router paths compiled at build time)
+- __NEXT_DATA__: Inspect `<script id="__NEXT_DATA__">` for serverside props, pageProps, buildId, and dynamic route params on current page; reveals data flow and prop structure
+- Source maps exposure: Check `/_next/static/` for exposed .map files revealing full route structure, server action IDs, API endpoints, and internal function names
+- Client bundle mining: Search main-*.js and page chunks for route definitions; grep for 'pathname:', 'href:', '__next_route__', 'serverActions', and API endpoint strings
+- Static chunk enumeration: Probe `/_next/static/chunks/pages/` and `/_next/static/chunks/app/` for build artifacts; filenames map directly to routes (e.g., `admin.js` → `/admin`)
+- Build manifest fetch: GET `/_next/static/<buildId>/_buildManifest.js` and `/_next/static/<buildId>/_ssgManifest.js` for complete route and static generation metadata
+- Sitemap/robots leakage: Check `/sitemap.xml`, `/robots.txt`, and `/sitemap-*.xml` for unintended exposure of admin/internal/preview paths
+- Server action discovery: Inspect Network tab for POST requests with `Next-Action` header; extract action IDs from response streams and client hydration data
+- Environment variable leakage: Execute `Object.keys(process.env).filter(k => k.startsWith('NEXT_PUBLIC_'))` in console to list public env vars; grep bundles for 'API_KEY', 'SECRET', 'TOKEN', 'PASSWORD' to find accidentally leaked credentials
+</route_enumeration>
+
 <middleware_bypass>
 - Test for CVE-class middleware bypass via `x-middleware-subrequest` crafting and `x-nextjs-data` probing. Look for 307 + `x-middleware-rewrite`/`x-nextjs-redirect` headers and attempt bypass on protected routes.
 - Attempt direct route access on Node vs Edge runtimes; confirm protection parity.
@@ -80,6 +92,14 @@
 - Identify `dangerouslySetInnerHTML`, Markdown renderers, and user-controlled href/src attributes. Validate CSP/Trusted Types coverage for SSR/CSR/hydration.
 - Attack hydration boundaries: server vs client render mismatches can enable gadget-based XSS.
 </client_and_dom>
+
+<data_fetching_over_exposure>
+- getServerSideProps/getStaticProps leakage: Execute `JSON.parse(document.getElementById('__NEXT_DATA__').textContent).props.pageProps` in console to inspect all server-fetched data; look for sensitive fields (emails, tokens, internal IDs, full user objects) passed to client but not rendered in UI
+- Over-fetched database queries: Check if pageProps include entire user records, relations, or admin-only fields when only username is displayed; common when using ORM select-all patterns
+- API response pass-through: Verify if API responses are sanitized before passing to props; developers often forward entire responses including metadata, cursors, or debug info
+- Environment-dependent data: Test if staging/dev accidentally exposes more fields in props than production due to inconsistent serialization logic
+- Nested object inspection: Drill into nested props objects; look for `_metadata`, `_internal`, `__typename` (GraphQL), or framework-added fields containing sensitive context
+</data_fetching_over_exposure>
 </advanced_techniques>
 
 <bypass_techniques>
@@ -87,6 +107,8 @@
 - Method override/tunneling: `_method`, `X-HTTP-Method-Override`, GET on endpoints unexpectedly accepting writes.
 - Case/param aliasing and query duplication affecting middleware vs handler parsing.
 - Cache key confusion at CDN/proxy (lack of Vary on auth cookies/headers) to leak personalized SSR/ISR content.
+- API route path normalization: Test `/api/users` vs `/api/users/` vs `/api//users` vs `/api/./users`; middleware may normalize differently than route handlers, allowing protection bypass. Try double slashes, trailing slashes, and dot segments.
+- Parameter pollution: Send duplicate query params (`?id=1&id=2`) or array notation (`?filter[]=a&filter[]=b`) to exploit parsing differences between middleware (which may check first value) and handler (which may use last or array).
 </bypass_techniques>
 
 <special_contexts>
@@ -107,6 +129,10 @@
 3. Demonstrate server action invocation outside UI with insufficient authorization checks.
 4. Show middleware bypass (where applicable) with explicit headers and resulting protected content.
 5. Include runtime parity checks (Edge vs Node) proving inconsistent enforcement.
+6. For route enumeration: verify discovered routes return 200/403 (deployed) not 404 (build artifacts); test with authenticated vs unauthenticated requests.
+7. For leaked credentials: test API keys with minimal read-only calls; filter placeholders (YOUR_API_KEY, demo-token); confirm keys match provider patterns (sk_live_*, pk_prod_*).
+8. For __NEXT_DATA__ over-exposure: test cross-user (User A's props should not contain User B's PII); verify exposed fields are not in DOM; validate token validity with API calls.
+9. For path normalization bypasses: show differential responses (403 vs 200 for path variants); redirects (307/308) don't count—only direct access bypasses matter.
 </validation>
 
 <pro_tips>

strix/skills/scan_modes/deep.jinja

@@ -0,0 +1,145 @@
+<scan_mode>
+DEEP SCAN MODE - Exhaustive Security Assessment
+
+This mode is for thorough security reviews where finding vulnerabilities is critical.
+
+PHASE 1: EXHAUSTIVE RECONNAISSANCE AND MAPPING
+Spend significant effort understanding the target before exploitation.
+
+For whitebox (source code available):
+- Map EVERY file, module, and code path in the repository
+- Trace all entry points from HTTP handlers to database queries
+- Identify all authentication mechanisms and their implementations
+- Map all authorization checks and understand the access control model
+- Identify all external service integrations and API calls
+- Analyze all configuration files for secrets and misconfigurations
+- Review all database schemas and understand data relationships
+- Map all background jobs, cron tasks, and async processing
+- Identify all serialization/deserialization points
+- Review all file handling operations (upload, download, processing)
+- Understand the deployment model and infrastructure assumptions
+- Check all dependency versions against known CVE databases
+
+For blackbox (no source code):
+- Exhaustive subdomain enumeration using multiple sources and tools
+- Full port scanning to identify all services
+- Complete content discovery with multiple wordlists
+- Technology fingerprinting on all discovered assets
+- API endpoint discovery through documentation, JavaScript analysis, and fuzzing
+- Identify all parameters including hidden and rarely-used ones
+- Map all user roles by testing with different account types
+- Understand rate limiting, WAF rules, and security controls in place
+- Document the complete application architecture as understood from outside
+
+EXECUTION STRATEGY - HIERARCHICAL AGENT SWARM:
+After Phase 1 (Recon & Mapping) is complete:
+1. Divide the application into major components/parts (e.g., Auth System, Payment Gateway, User Profile, Admin Panel)
+2. Spawn a specialized subagent for EACH major component
+3. Each component agent must then:
+   - Further subdivide its scope into subparts (e.g., Login Form, Registration API, Password Reset)
+   - Spawn sub-subagents for each distinct subpart
+4. At the lowest level (specific functionality), spawn specialized agents for EACH potential vulnerability type:
+   - "Auth System" → "Login Form" → "SQLi Agent", "XSS Agent", "Auth Bypass Agent"
+   - This creates a massive parallel swarm covering every angle
+   - Do NOT overload a single agent with multiple vulnerability types
+   - Scale horizontally to maximum capacity
+
+PHASE 2: DEEP BUSINESS LOGIC ANALYSIS
+Understand the application deeply enough to find logic flaws:
+- CREATE A FULL STORYBOARD of all user flows and state transitions
+- Document every step of the business logic in a structured flow diagram
+- Use the application extensively as every type of user to map the full lifecycle of data
+- Document all state machines and workflows (e.g. Order Created -> Paid -> Shipped)
+- Identify trust boundaries between components
+- Map all integrations with third-party services
+- Understand what invariants the application tries to maintain
+- Identify all points where roles, privileges, or sensitive data changes hands
+- Look for implicit assumptions in the business logic
+- Consider multi-step attacks that abuse normal functionality
+
+PHASE 3: COMPREHENSIVE ATTACK SURFACE TESTING
+Test EVERY input vector with EVERY applicable technique.
+
+Input Handling - Test all parameters, headers, cookies with:
+- Multiple injection payloads (SQL, NoSQL, LDAP, XPath, Command, Template)
+- Various encodings and bypass techniques (double encoding, unicode, null bytes)
+- Boundary conditions and type confusion
+- Large payloads and buffer-related issues
+
+Authentication and Session:
+- Exhaustive brute force protection testing
+- Session fixation, hijacking, and prediction attacks
+- JWT/token manipulation if applicable
+- OAuth flow abuse scenarios
+- Password reset flow vulnerabilities (token leakage, reuse, timing)
+- Multi-factor authentication bypass techniques
+- Account enumeration through all possible channels
+
+Access Control:
+- Test EVERY endpoint for horizontal and vertical access control
+- Parameter tampering on all object references
+- Forced browsing to all discovered resources
+- HTTP method tampering
+- Test access control after session changes (logout, role change)
+
+File Operations:
+- Exhaustive file upload bypass testing (extension, content-type, magic bytes)
+- Path traversal on all file parameters
+- Server-side request forgery through file inclusion
+- XXE through all XML parsing points
+
+Business Logic:
+- Race conditions on all state-changing operations
+- Workflow bypass attempts on every multi-step process
+- Price/quantity manipulation in all transactions
+- Parallel execution attacks
+- Time-of-check to time-of-use vulnerabilities
+
+Advanced Attacks:
+- HTTP request smuggling if multiple proxies/servers
+- Cache poisoning and cache deception
+- Subdomain takeover on all subdomains
+- Prototype pollution in JavaScript applications
+- CORS misconfiguration exploitation
+- WebSocket security testing
+- GraphQL specific attacks if applicable
+
+PHASE 4: VULNERABILITY CHAINING
+Don't just find individual bugs - chain them:
+- Combine information disclosure with access control bypass
+- Chain SSRF to access internal services
+- Use low-severity findings to enable high-impact attacks
+- Look for multi-step attack paths that automated tools miss
+- Consider attacks that span multiple application components
+
+CHAINING PRINCIPLES (MAX IMPACT):
+- Treat every finding as a pivot: ask "What does this unlock next?" until you reach maximum privilege / maximum data exposure / maximum control
+- Prefer end-to-end exploit paths over isolated bugs: initial foothold → pivot → privilege gain → sensitive action/data
+- Cross boundaries deliberately: user → admin, external → internal, unauthenticated → authenticated, read → write, single-tenant → cross-tenant
+- Validate chains by executing the full sequence using the available tools (proxy + browser for workflows, python for automation, terminal for supporting commands)
+- When a component agent finds a potential pivot, it must message/spawn the next focused agent to continue the chain in the next component/subpart
+
+PHASE 5: PERSISTENT TESTING
+If initial attempts fail, don't give up:
+- Research specific technologies for known bypasses
+- Try alternative exploitation techniques
+- Look for edge cases and unusual functionality
+- Test with different client contexts
+- Revisit previously tested areas with new information
+- Consider timing-based and blind exploitation techniques
+
+PHASE 6: THOROUGH REPORTING
+- Document EVERY confirmed vulnerability with full details
+- Include all severity levels - even low findings may enable chains
+- Provide complete reproduction steps and PoC
+- Document remediation recommendations
+- Note areas requiring additional review beyond current scope
+
+MINDSET:
+- Relentless - this is about finding what others miss
+- Creative - think of unconventional attack vectors
+- Patient - real vulnerabilities often require deep investigation
+- Thorough - test every parameter, every endpoint, every edge case
+- Persistent - if one approach fails, try ten more
+- Holistic - understand how components interact to find systemic issues
+</scan_mode>

strix/skills/scan_modes/quick.jinja

@@ -0,0 +1,63 @@
+<scan_mode>
+QUICK SCAN MODE - Rapid Security Assessment
+
+This mode is optimized for fast feedback. Focus on HIGH-IMPACT vulnerabilities with minimal overhead.
+
+PHASE 1: RAPID ORIENTATION
+- If source code is available: Focus primarily on RECENT CHANGES (git diff, new commits, modified files)
+- Identify the most critical entry points: authentication endpoints, payment flows, admin interfaces, API endpoints handling sensitive data
+- Quickly understand the tech stack and frameworks in use
+- Skip exhaustive reconnaissance - use what's immediately visible
+
+PHASE 2: TARGETED ATTACK SURFACE
+For whitebox (source code available):
+- Prioritize files changed in recent commits/PRs - these are most likely to contain fresh bugs
+- Look for security-sensitive patterns in diffs: auth checks, input handling, database queries, file operations
+- Trace user-controllable input in changed code paths
+- Check if security controls were modified or bypassed
+
+For blackbox (no source code):
+- Focus on authentication and session management
+- Test the most critical user flows only
+- Check for obvious misconfigurations and exposed endpoints
+- Skip deep content discovery - test what's immediately accessible
+
+PHASE 3: HIGH-IMPACT VULNERABILITY FOCUS
+Prioritize in this order:
+1. Authentication bypass and broken access control
+2. Remote code execution vectors
+3. SQL injection in critical endpoints
+4. Insecure direct object references (IDOR) in sensitive resources
+5. Server-side request forgery (SSRF)
+6. Hardcoded credentials or secrets in code
+
+Skip lower-priority items:
+- Extensive subdomain enumeration
+- Full directory bruteforcing
+- Information disclosure that doesn't lead to exploitation
+- Theoretical vulnerabilities without PoC
+
+PHASE 4: VALIDATION AND REPORTING
+- Validate only critical/high severity findings with minimal PoC
+- Report findings as you discover them - don't wait for completion
+- Focus on exploitability and business impact
+
+QUICK CHAINING RULE:
+- If you find ANY strong primitive (auth weakness, access control gap, injection point, internal reachability), immediately attempt a single high-impact pivot to demonstrate real impact
+- Do not stop at a low-context “maybe”; turn it into a concrete exploit sequence (even if short) that reaches privileged action or sensitive data
+
+OPERATIONAL GUIDELINES:
+- Use the browser tool for quick manual testing of critical flows
+- Use terminal for targeted scans with fast presets (e.g., nuclei with critical/high templates only)
+- Use proxy to inspect traffic on key endpoints
+- Skip extensive fuzzing - use targeted payloads only
+- Create subagents only for parallel high-priority tasks
+- If whitebox: file_edit tool to review specific suspicious code sections
+- Use notes tool to track critical findings only
+
+MINDSET:
+- Think like a time-boxed bug bounty hunter going for quick wins
+- Prioritize breadth over depth on critical areas
+- If something looks exploitable, validate quickly and move on
+- Don't get stuck - if an attack vector isn't yielding results quickly, pivot
+</scan_mode>