Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions .github/ISSUE_TEMPLATE/bug_report.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
name: "🐛 Bug Report"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Duplicate issue templates will appear in GitHub's picker

The repository already contains .github/ISSUE_TEMPLATE/bug_report.md and .github/ISSUE_TEMPLATE/feature_request.md. GitHub renders both .md and .yml templates as separate entries in the "New Issue" chooser, so contributors will now see two "Bug Report" options and two "Feature Request" options simultaneously. The old .md templates should be deleted if the new form-based .yml versions are intended as replacements.

Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/ISSUE_TEMPLATE/bug_report.yml
Line: 1

Comment:
**Duplicate issue templates will appear in GitHub's picker**

The repository already contains `.github/ISSUE_TEMPLATE/bug_report.md` and `.github/ISSUE_TEMPLATE/feature_request.md`. GitHub renders both `.md` and `.yml` templates as separate entries in the "New Issue" chooser, so contributors will now see two "Bug Report" options and two "Feature Request" options simultaneously. The old `.md` templates should be deleted if the new form-based `.yml` versions are intended as replacements.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

description: "Report a bug or unexpected behavior in Strix"
title: "[Bug]: "
labels: ["bug", "triage"]
body:
- type: markdown
attributes:
value: |
Please fill out this form to help us diagnose and resolve the issue.
- type: textarea
id: description
attributes:
label: "Vulnerability / Bug Description"
description: "A clear and concise description of what is happening."
placeholder: "e.g., Strix CLI crashes during local scan on port 8080..."
validations:
required: true
- type: textarea
id: reproduction
attributes:
label: "Reproduction Steps"
description: "How can we reproduce the bug?"
placeholder: |
1. Run 'uv run strix --target https://example.com'
2. Set environment variable STRIX_LLM = ...
3. See error stack trace...
validations:
required: true
- type: textarea
id: logs
attributes:
label: "Logs and Stack Traces"
description: "Copy-paste relevant terminal error logs here."
render: shell
- type: input
id: environment
attributes:
label: "System & LLM Environment"
description: "Python version, OS, target server model, LLM provider, etc."
placeholder: "e.g. Python 3.12, macOS Sonoma, OpenAI GPT-4o"
validations:
required: true
Comment on lines +1 to +42

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Missing "Expected behavior" field present in the original template

The existing bug_report.md includes an "Expected behavior" section, which is commonly the most useful field for triaging bugs (it distinguishes intent from outcome). The new .yml form omits it, so reporters have no structured place to describe what they expected to happen. Consider adding an optional textarea for this between "Reproduction Steps" and "Logs and Stack Traces".

Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/ISSUE_TEMPLATE/bug_report.yml
Line: 1-42

Comment:
**Missing "Expected behavior" field present in the original template**

The existing `bug_report.md` includes an "Expected behavior" section, which is commonly the most useful field for triaging bugs (it distinguishes intent from outcome). The new `.yml` form omits it, so reporters have no structured place to describe what they expected to happen. Consider adding an optional `textarea` for this between "Reproduction Steps" and "Logs and Stack Traces".

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

28 changes: 28 additions & 0 deletions .github/ISSUE_TEMPLATE/feature_request.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
name: "🚀 Feature Request"
description: "Suggest an improvement, new agent capability, or pentesting skill"
title: "[Feature]: "
labels: ["enhancement"]
body:
- type: markdown
attributes:
value: |
We are happy to receive suggestions to make Strix a more powerful pentesting tool.
- type: textarea
id: context
attributes:
label: "Problem / Context"
description: "Is your suggestion related to a gap in existing penetration testing capabilities?"
placeholder: "e.g., Strix struggles to analyze and attack GraphQL endpoints..."
- type: textarea
id: feature_details
attributes:
label: "Describe the Proposed Feature"
description: "What capability, tool integrations, or agent logic should be added?"
placeholder: "Add a new GraphQL schema auditor tool to Strix's agent toolkit..."
validations:
required: true
- type: textarea
id: alternatives
attributes:
label: "Describe alternatives you've considered"
description: "Any alternative solutions or features you've considered."
15 changes: 15 additions & 0 deletions SECURITY.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
# Security Policy

## Supported Versions

Only the latest stable version of Strix is supported with security updates.

## Reporting a Vulnerability

If you discover a security vulnerability in Strix, please do **not** open a public issue. We take security seriously and want to fix exploits responsibly.

Please report vulnerabilities privately by:
- Sending an email to **hi@usestrix.com** with details of the vulnerability and reproduction steps.
- Or utilizing GitHub's private vulnerability reporting feature on the repository.

We will acknowledge your report within 48 hours and work with you to release a security patch.
Comment on lines +1 to +15

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Security policy does not mention a disclosure timeline or patch SLA

The policy commits to acknowledging a report within 48 hours but sets no expectation for when a fix will be released or when the reporter may disclose publicly. For an open-source pentesting tool, a standard responsible disclosure window (e.g., 90 days) is expected by security researchers. Without it, reporters have no basis for coordinated disclosure, which can lead to premature public posts or disputes.

Prompt To Fix With AI
This is a comment left during a code review.
Path: SECURITY.md
Line: 1-15

Comment:
**Security policy does not mention a disclosure timeline or patch SLA**

The policy commits to acknowledging a report within 48 hours but sets no expectation for when a fix will be released or when the reporter may disclose publicly. For an open-source pentesting tool, a standard responsible disclosure window (e.g., 90 days) is expected by security researchers. Without it, reporters have no basis for coordinated disclosure, which can lead to premature public posts or disputes.

How can I resolve this? If you propose a fix, please make it concise.