strix-agent 0.1.12__tar.gz → 0.1.13__tar.gz

{strix_agent-0.1.12 → strix_agent-0.1.13}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: strix-agent
-Version: 0.1.12
+Version: 0.1.13
 Summary: Open-source AI Hackers for your apps
 License: Apache-2.0
 Keywords: cybersecurity,security,vulnerability,scanner,pentest,agent,ai,cli

{strix_agent-0.1.12 → strix_agent-0.1.13}/pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "strix-agent"
-version = "0.1.12"
+version = "0.1.13"
 description = "Open-source AI Hackers for your apps"
 authors = ["Strix <hi@usestrix.com>"]
 readme = "README.md"

{strix_agent-0.1.12 → strix_agent-0.1.13}/strix/agents/StrixAgent/system_prompt.jinja

@@ -24,6 +24,8 @@ USER INTERACTION:
 - NEVER be redundant or repeat information - say it once and move on
 - If you need user input, IMMEDIATELY call wait_for_message tool
 - Never ask questions without calling wait_for_message in the same response
+- Minimize user messaging: avoid redundancy and repetition; consolidate updates into a single concise message
+- If there is nothing to execute and no user query to answer any more: do NOT send filler/repetitive text — either call wait_for_message or finish your work (subagents: agent_finish; root: finish_scan)
 </communication_rules>
 
 <execution_guidelines>
@@ -114,6 +116,8 @@ VALIDATION REQUIREMENTS:
 - Independent verification through subagent
 - Document complete attack chain
 - Keep going until you find something that matters
+- A vulnerability is ONLY considered reported when a reporting agent uses create_vulnerability_report with full details. Mentions in agent_finish, finish_scan, or messages to the user are NOT sufficient
+- Do NOT patch/fix before reporting: first create the vulnerability report via create_vulnerability_report (by the reporting agent). Only after reporting is completed should fixing/patching proceed
 </execution_guidelines>
 
 <vulnerability_focus>
@@ -193,6 +197,10 @@ SIMPLE WORKFLOW RULES:
 4. **MULTIPLE VULNS = MULTIPLE CHAINS** - Each vulnerability finding gets its own validation chain
 5. **CREATE AGENTS AS YOU GO** - Don't create all agents at start, create them when you discover new attack surfaces
 6. **ONE JOB PER AGENT** - Each agent has ONE specific task only
+7. **VIEW THE AGENT GRAPH BEFORE ACTING** - Always call view_agent_graph before creating or messaging agents to avoid duplicates and to target correctly
+8. **SCALE AGENT COUNT TO SCOPE** - Number of agents should correlate with target size and difficulty; avoid both agent sprawl and under-staffing
+9. **CHILDREN ARE MEANINGFUL SUBTASKS** - Child agents must be focused subtasks that directly support their parent's task; do NOT create unrelated children
+10. **UNIQUENESS** - Do not create two agents with the same task; ensure clear, non-overlapping responsibilities for every agent
 
 WHEN TO CREATE NEW AGENTS:
 

{strix_agent-0.1.12 → strix_agent-0.1.13}/strix/tools/agents_graph/agents_graph_actions.py

@@ -53,6 +53,9 @@ def _run_agent_in_thread(
     <instructions>
         - You have {context_status}
         - Inherited context is for BACKGROUND ONLY - don't continue parent's work
+        - Maintain strict self-identity: never speak as or for your parent
+        - Do not merge your conversation with the parent's;
+        - Do not claim parent's actions or messages as your own
         - Focus EXCLUSIVELY on your delegated task above
         - Work independently with your own approach
         - Use agent_finish when complete to report back to parent

{strix_agent-0.1.12 → strix_agent-0.1.13}/strix/tools/terminal/terminal_actions_schema.xml

@@ -25,7 +25,7 @@
         Use is_input=true for regular text input to running processes.</description>
       </parameter>
       <parameter name="timeout" type="number" required="false">
-        <description>Optional timeout in seconds for command execution. If not provided, uses default timeout behavior. Set to higher values for long-running commands like installations or tests. Default is 10 seconds.</description>
+        <description>Optional timeout in seconds for command execution. CAPPED AT 60 SECONDS. If not provided, uses default wait (30s). On timeout, the command keeps running and the tool returns with status 'running'. For truly long-running tasks, prefer backgrounding with '&'.</description>
       </parameter>
       <parameter name="terminal_id" type="string" required="false">
         <description>Identifier for the terminal session. Defaults to "default". Use different IDs to manage multiple concurrent terminal sessions.</description>
@@ -63,14 +63,15 @@
   3. LONG-RUNNING COMMANDS:
      - Commands never get killed automatically - they keep running in background
      - Set timeout to control how long to wait for output before returning
+     - For daemons/servers or very long jobs, append '&' to run in background
      - Use empty command "" to check progress (waits for timeout period to collect output)
      - Use C-c, C-d, C-z to interrupt processes (works automatically, no is_input needed)
 
   4. TIMEOUT HANDLING:
-     - Timeout controls how long to wait before returning current output
+     - Timeout controls how long to wait before returning current output (max 60s cap)
      - Commands are NEVER killed on timeout - they keep running
      - After timeout, you can run new commands or check progress with empty command
-     - All commands return status "completed" - you have full control
+     - On timeout, status is 'running'; on completion, status is 'completed'
 
   5. MULTIPLE TERMINALS: Use different terminal_id values to run multiple concurrent sessions.
 
@@ -97,7 +98,7 @@
   # Run a command with custom timeout
   <function=terminal_execute>
   <parameter=command>npm install</parameter>
-  <parameter=timeout>120</parameter>
+  <parameter=timeout>60</parameter>
   </function>
 
   # Check progress of running command (waits for timeout to collect output)