Skip to content

Add repository standards: Ruff & Type check CI, SECURITY policy, and structured issues#610

Open
shiva24082 wants to merge 3 commits into
usestrix:mainfrom
shiva24082:improve/repository-standards
Open

Add repository standards: Ruff & Type check CI, SECURITY policy, and structured issues#610
shiva24082 wants to merge 3 commits into
usestrix:mainfrom
shiva24082:improve/repository-standards

Conversation

@shiva24082

Copy link
Copy Markdown

This Pull Request introduces standard CI workflows, issue structures, and security policies:

  1. Security Vulnerability Reporting Policy (SECURITY.md): Configures private vulnerability disclosure details, vital for open source pentesting software.
  2. Structured Issue Templates: Adds interactive bug report and feature request forms under .github/ISSUE_TEMPLATE/.

Created using the Antigravity GitHub repository analyzer.

@greptile-apps

greptile-apps Bot commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR adds form-based GitHub issue templates (bug_report.yml, feature_request.yml) and a SECURITY.md policy to standardize contributor workflows. However, the repo already has matching .md versions of both issue templates, and all three file formats will be present simultaneously.

  • The new .yml form templates coexist with the existing bug_report.md and feature_request.md, causing GitHub to render duplicate entries ("Bug Report" × 2, "Feature Request" × 2) in the issue picker. The old .md templates should be deleted as part of this change.
  • bug_report.yml drops the "Expected behavior" field that existed in the old template — a useful triage field worth preserving.
  • SECURITY.md is a reasonable baseline but omits a coordinated disclosure timeline (e.g., 90-day window), which security researchers typically expect before public disclosure.

Confidence Score: 3/5

Safe from a code-execution standpoint, but the duplicate issue templates actively degrade the contributor experience and should be resolved before merging.

The new .yml issue templates are added without removing the existing .md counterparts, so GitHub will display two "Bug Report" and two "Feature Request" options to every contributor opening a new issue. This is a present, observable problem with the change as written.

.github/ISSUE_TEMPLATE/bug_report.yml and .github/ISSUE_TEMPLATE/feature_request.yml — they need the corresponding .md files deleted alongside them.

Important Files Changed

Filename Overview
.github/ISSUE_TEMPLATE/bug_report.yml Adds a form-based bug report template, but conflicts with the existing bug_report.md — both will appear in GitHub's issue picker, creating duplicates. Also drops the "Expected behavior" field from the original template.
.github/ISSUE_TEMPLATE/feature_request.yml Adds a form-based feature request template alongside the existing feature_request.md, producing duplicate entries in the issue chooser.
SECURITY.md Adds a SECURITY.md with a contact email and GitHub private reporting; lacks a coordinated disclosure timeline or patch SLA.
Prompt To Fix All With AI
Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
.github/ISSUE_TEMPLATE/bug_report.yml:1
**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.

### Issue 2 of 3
.github/ISSUE_TEMPLATE/bug_report.yml:1-42
**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".

### Issue 3 of 3
SECURITY.md:1-15
**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.

Reviews (1): Last reviewed commit: "Add/Update SECURITY.md to improve reposi..." | Re-trigger Greptile

@@ -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!

Comment on lines +1 to +42
name: "🐛 Bug Report"
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

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!

Comment thread SECURITY.md
Comment on lines +1 to +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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant