Repository navigation
docs: add OSS governance artifacts and PR-based contribution workflow - #1
Conversation
Establish contributor infrastructure for the fork so changes land through reviewed pull requests instead of direct pushes to main. - CONTRIBUTING.md: fork-aware PR workflow (fork -> branch -> conventional commit -> PR -> CI -> maintainer approval -> merge), build/test setup, upstream-vs-fork routing, branch-protection expectations. - CODE_OF_CONDUCT.md: Contributor Covenant v2.1. - SECURITY.md: private vulnerability reporting via GitHub Security Advisories, scope (plugin code, not the wrapped CLIs), quoting/secrets guidance. - .github/ISSUE_TEMPLATE/: bug_report and feature_request YAML forms plus config.yml (disables blank issues; contact links for security, contributing, upstream Codex issues). - .github/pull_request_template.md: PR checklist (summary, motivation, change type, tests/build green, conventional commits, no secrets, CHANGELOG). - README.md: Contributing, Code of Conduct, Security, License sections. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
📝 WalkthroughWalkthroughAdds repository issue and pull request templates, contributor and conduct documentation, a security policy, README guidance, and a pull-request dependency review workflow. ChangesRepository governance
Estimated code review effort: 2 (Simple) | ~15 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/ISSUE_TEMPLATE/bug_report.yml:
- Around line 28-35: Update the command input field with id "command" in the bug
report template so it is not required for repository, packaging, or
documentation reports. Make the field optional, or provide a clear N/A option
while preserving command capture for reports involving slash commands.
In `@CONTRIBUTING.md`:
- Around line 88-92: Update the fenced commit-message example in CONTRIBUTING.md
to specify the text language identifier, preserving the existing example
contents.
- Around line 34-39: Update the contributor setup commands in CONTRIBUTING.md to
use the contributor’s fork URL placeholder instead of the canonical Reederey87
repository, while preserving the existing directory and installation commands.
- Around line 101-108: Update the “Branch protection details” section in
CONTRIBUTING.md so the review approval requirement clearly applies only to
external contributors, while preserving the maintainer/admin self-merge bypass.
Ensure the wording consistently reflects the actual protected-branch merge rule
and does not imply maintainer approval is always required.
In `@SECURITY.md`:
- Around line 38-44: Update the excluded-dependencies guidance in SECURITY.md:
change the `@openai/codex` entry to direct reporters to OpenAI’s private security
channels, Bugcrowd or disclosure@openai.com, and change the Grok Build CLI entry
to xAI’s private vulnerability channels, HackerOne or vulnerabilities@x.ai.
Remove the generic help, documentation, and public repository references while
preserving the credential-reporting guidance.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: e43eb338-476f-4690-9d52-69ba4b479aa7
📒 Files selected for processing (8)
.github/ISSUE_TEMPLATE/bug_report.yml.github/ISSUE_TEMPLATE/config.yml.github/ISSUE_TEMPLATE/feature_request.yml.github/pull_request_template.mdCODE_OF_CONDUCT.mdCONTRIBUTING.mdREADME.mdSECURITY.md
| - type: input | ||
| id: command | ||
| attributes: | ||
| label: Command(s) involved | ||
| description: The slash command(s) you ran, e.g. `/codex:review`, `/grok:rescue --write`. | ||
| placeholder: "/codex:review --base main" | ||
| validations: | ||
| required: true |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Do not require a command for repository and documentation reports.
The form allows “Repo / packaging / docs” as the affected area, but requires a slash command. Users reporting packaging or documentation problems may have no command to provide and will be forced to enter misleading data. Make this field optional or provide an explicit N/A path.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/ISSUE_TEMPLATE/bug_report.yml around lines 28 - 35, Update the
command input field with id "command" in the bug report template so it is not
required for repository, packaging, or documentation reports. Make the field
optional, or provide a clear N/A option while preserving command capture for
reports involving slash commands.
| ```bash | ||
| git clone https://github.com/Reederey87/codex-plugin-cc.git | ||
| cd codex-plugin-cc | ||
| npm ci | ||
| npm install -g @openai/codex # required by npm run build (prebuild step) | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Clone the contributor’s fork, not the canonical repository.
This command clones Reederey87/codex-plugin-cc, despite the preceding instructions saying to clone the contributor’s fork. Following it leaves contributors pushing to the wrong remote or unable to push, blocking the documented PR workflow.
Proposed fix
-git clone https://github.com/Reederey87/codex-plugin-cc.git
+git clone https://github.com/<your-github-username>/codex-plugin-cc.git
cd codex-plugin-cc
npm ci📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ```bash | |
| git clone https://github.com/Reederey87/codex-plugin-cc.git | |
| cd codex-plugin-cc | |
| npm ci | |
| npm install -g @openai/codex # required by npm run build (prebuild step) | |
| ``` |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@CONTRIBUTING.md` around lines 34 - 39, Update the contributor setup commands
in CONTRIBUTING.md to use the contributor’s fork URL placeholder instead of the
canonical Reederey87 repository, while preserving the existing directory and
installation commands.
| ``` | ||
| feat: add grok --effort flag | ||
| fix: quote $ARGUMENTS in cancel command | ||
| docs: clarify fork install steps | ||
| ``` |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Specify the code-block language.
markdownlint-cli2 reports this fenced block because it has no language identifier. Use text for the commit-message examples.
Proposed fix
- ```
+ ```text
feat: add grok --effort flag
fix: quote $ARGUMENTS in cancel command
docs: clarify fork install steps
```📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ``` | |
| feat: add grok --effort flag | |
| fix: quote $ARGUMENTS in cancel command | |
| docs: clarify fork install steps | |
| ``` |
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 88-88: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@CONTRIBUTING.md` around lines 88 - 92, Update the fenced commit-message
example in CONTRIBUTING.md to specify the text language identifier, preserving
the existing example contents.
Source: Linters/SAST tools
| ### Branch protection details | ||
|
|
||
| - Direct pushes to `main` are blocked; a PR is required. | ||
| - At least **one review approval** is required to merge (external contributors). | ||
| - The **CI** status check is required. | ||
| - Force pushes and branch deletion are blocked. | ||
| - The maintainer (admin) may self-merge their own PRs (admin bypass) so the | ||
| fork isn't blocked when working solo. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== CONTRIBUTING.md excerpt =="
sed -n '90,120p' CONTRIBUTING.md | cat -n
echo
echo "== Related mentions =="
rg -n "approval|branch protection|admin bypass|self-merge|external contributors|protected merges|main" CONTRIBUTING.md . -g '!**/.git/**'Repository: Reederey87/codex-plugin-cc
Length of output: 10058
Clarify the approval rule for protected merges. CONTRIBUTING.md says maintainer approval is required before merging, but the branch-protection notes limit that to external contributors and call out the admin bypass. Reword it so the approval requirement matches the actual merge rule.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@CONTRIBUTING.md` around lines 101 - 108, Update the “Branch protection
details” section in CONTRIBUTING.md so the review approval requirement clearly
applies only to external contributors, while preserving the maintainer/admin
self-merge bypass. Ensure the wording consistently reflects the actual
protected-branch merge rule and does not imply maintainer approval is always
required.
| It does **not** cover: | ||
|
|
||
| - The **Codex CLI** itself (`@openai/codex`) — report to | ||
| [OpenAI](https://help.openai.com/) or the | ||
| [upstream repo](https://github.com/openai/codex-plugin-cc). | ||
| - The **Grok Build CLI** itself — report to [xAI](https://docs.x.ai/build). | ||
| - Your own API keys, tokens, or credentials — we cannot reset or rotate them. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- SECURITY.md excerpt ---'
nl -ba SECURITY.md | sed -n '32,50p'Repository: Reederey87/codex-plugin-cc
Length of output: 232
🌐 Web query:
OpenAI security vulnerability reporting channel Codex CLI upstream repo help center security disclosure
💡 Result:
To report a security vulnerability in OpenAI products, including the Codex CLI, you should use the official OpenAI Bug Bounty program hosted on Bugcrowd [1][2]. OpenAI manages its coordinated vulnerability disclosure program through Bugcrowd, which provides a structured platform for reporting security issues [2]. You can submit reports at https://bugcrowd.com/engagements/openai [1][3]. In addition to the Bugcrowd platform, OpenAI maintains a security contact email address: disclosure@openai.com [1]. While the GitHub security policy for the Codex repository specifically directs users to report validated vulnerabilities through the Bugcrowd program [2], some documentation also notes that security concerns or discovered vulnerabilities can be emailed to security@openai.com [4]. For comprehensive information on OpenAI's vulnerability disclosure policy, including in-scope and out-of-scope testing, please visit the official Coordinated Vulnerability Disclosure Policy page [5][6]. Additionally, the security.txt file located at https://openai.com/.well-known/security.txt provides the most up-to-date, machine-readable security contact information [1].
Citations:
- 1: https://openai.com/security.txt
- 2: https://github.com/openai/codex/blob/dc5cf1ff782d3f1e0c2a6fab4d8e67981c7a3772/SECURITY.md
- 3: https://bugcrowd.com/engagements/openai
- 4: https://github.com/openai/codex/blob/9a8730f3/codex-cli/README.md
- 5: https://openai.com/policies/coordinated-vulnerability-disclosure-policy/
- 6: https://help.openai.com/en/articles/6653653-how-to-report-security-vulnerabilities-to-openai
🌐 Web query:
xAI security vulnerability reporting channel Grok Build CLI security disclosure report vulnerabilities
💡 Result:
To report security vulnerabilities to xAI regarding Grok, their API, or other platform features, you should use their official channels [1][2][3]. xAI operates a bug bounty program hosted on HackerOne, which is their preferred method for handling security reports [1][4][3]. You can also contact their security team via email at vulnerabilities@x.ai [1][2]. Note that many "grok-cli" tools or plugins found on platforms like GitHub are community-developed or third-party wrappers rather than official xAI software [5][6][7][8]. If you identify a vulnerability in a third-party project, you should follow the specific SECURITY.md file associated with that repository (often involving private reporting via GitHub Security Advisories or direct email to the project maintainers) rather than contacting xAI [6][7][8]. Summary of reporting channels: - Official xAI vulnerabilities: Use the xAI HackerOne program (https://hackerone.com/x) or email vulnerabilities@x.ai [1][2][3]. - Safety/Harmful output issues: Email safety@x.ai [3]. - Third-party CLI tools/plugins: Check the specific repository's SECURITY.md for instructions (typically GitHub Security Advisories or maintainer email) [6][7][8]. For critical security disclosures involving the xAI platform, avoid public disclosure until the team has had an opportunity to triage and remediate the issue [9][7][8]. Always include detailed reproduction steps and descriptions of the impact to ensure the quickest response [6][7][8].
Citations:
- 1: https://x.ai/security
- 2: https://wraith.sh/learn/ai-bug-bounty-programs
- 3: https://x.ai/safety
- 4: https://hackerone.com/x
- 5: Security: Red Team Assessment — 16 findings (3 CRITICAL, 4 HIGH) with MCP integration superagent-ai/grok-cli#257
- 6: https://github.com/Sunwood-ai-labs/grok-cli-sandbox/blob/main/SECURITY.md
- 7: https://github.com/zhonglikui/grok-agent-kit/blob/main/SECURITY.md
- 8: https://github.com/VasiHemanth/grok-build-plugin/blob/main/SECURITY.md
- 9: https://blog.gitguardian.com/xai-secret-leak-disclosure/
Use private disclosure channels for the excluded dependencies. @openai/codex should point to OpenAI’s security channel (Bugcrowd or disclosure@openai.com), and Grok Build CLI should point to xAI’s vulnerability program (HackerOne or vulnerabilities@x.ai), not generic help/docs or a public repo.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@SECURITY.md` around lines 38 - 44, Update the excluded-dependencies guidance
in SECURITY.md: change the `@openai/codex` entry to direct reporters to OpenAI’s
private security channels, Bugcrowd or disclosure@openai.com, and change the
Grok Build CLI entry to xAI’s private vulnerability channels, HackerOne or
vulnerabilities@x.ai. Remove the generic help, documentation, and public
repository references while preserving the credential-reporting guidance.
Adds a SHA-pinned GitHub dependency-review-action workflow that runs on PRs touching lockfiles (advisory, not a required check). As a new workflow file, this also clears the fork first-time Actions enablement gate so the existing pull-request-ci workflow starts running on PRs. Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/dependency-review.yml (1)
22-23: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winDisable persisted checkout credentials.
This job performs no authenticated Git operation after checkout. Set
persist-credentials: falseto avoid retaining credentials for subsequent actions and address the reportedzizmorwarning. GitHub documents this input as the checkout opt-out. (github.com)Proposed hardening
- name: Check out repository uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 + with: + persist-credentials: false🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/dependency-review.yml around lines 22 - 23, Update the actions/checkout step in the dependency-review workflow to set persist-credentials to false, while preserving the existing pinned action version and checkout behavior.Sources: MCP tools, Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/dependency-review.yml:
- Around line 27-30: Update the comments above fail-on-severity in the
dependency review workflow to describe the setting as a vulnerability/advisory
severity threshold rather than a CVE threshold, while preserving the
moderate-or-higher behavior and advisory status-check explanation.
---
Nitpick comments:
In @.github/workflows/dependency-review.yml:
- Around line 22-23: Update the actions/checkout step in the dependency-review
workflow to set persist-credentials to false, while preserving the existing
pinned action version and checkout behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 3383c182-9f2d-4b1b-8077-c0fdfae7cf43
📒 Files selected for processing (1)
.github/workflows/dependency-review.yml
| # Fail the check if any new/modified dependency has a moderate+ CVE. | ||
| # This check is advisory (not a required status check); the maintainer | ||
| # can still merge after reviewing the report. | ||
| fail-on-severity: moderate |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the workflow snippet in context.
sed -n '1,120p' .github/workflows/dependency-review.yml
# Search for any other wording around dependency-review thresholds in the repo.
rg -n "fail-on-severity|CVE|GHSA|dependency-review" .github/workflows . || trueRepository: Reederey87/codex-plugin-cc
Length of output: 1488
🌐 Web query:
actions/dependency-review-action fail-on-severity vulnerability severity GHSA CVE documentation
💡 Result:
The fail-on-severity option in the actions/dependency-review-action is used to configure the threshold at which the action will fail a pull request [1][2]. When this option is set, the action will fail if any dependency changes introduce vulnerabilities with a severity level equal to or higher than the specified threshold [3][1]. Configuration Details: - Possible values: low, moderate, high, critical [1][4]. - Default value: low [1]. - Usage: It is specified within the with block of the workflow YAML file [1][2]. Example Configuration: yaml - name: Dependency Review uses: actions/dependency-review-action@v5 with: fail-on-severity: moderate Additional Notes: - GHSA/CVE Handling: While fail-on-severity manages vulnerability thresholds, you can also use the allow-ghsas option to specify a comma-separated list of GitHub Advisory IDs (e.g., GHSA-xxxx-xxxx-xxxx) that should be ignored or allowed by the action, regardless of their severity [4][5]. - Overrides: Setting warn-only: true will cause the action to log all vulnerabilities as warnings instead of failing the check, effectively overriding the fail-on-severity setting [1].
Citations:
- 1: https://github.com/actions/dependency-review-action/blob/main/README.md
- 2: https://github.com/github/docs/blob/main/content/code-security/tutorials/secure-your-dependencies/customize-dependency-review-action.md
- 3: https://github.com/actions/dependency-review-action
- 4: https://docs.github.com/en/enterprise-server@3.19/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-dependency-review-action
- 5: https://github.com/actions/dependency-review-action/blob/e38e634e5461cc23908576e7961f273dcb6ead59/action.yml
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Focused read of the workflow file and surrounding lines.
cat -n .github/workflows/dependency-review.yml | sed -n '1,120p'Repository: Reederey87/codex-plugin-cc
Length of output: 1299
🌐 Web query:
site:github.com/actions/dependency-review-action fail-on-severity advisories vulnerabilities severity GHSA CVE
💡 Result:
Fail-on-severity is a configuration option primarily used in the GitHub Dependency Review Action [1][2]. It defines the threshold for vulnerability severity levels that will cause a pull request check to fail [3][2]. Key details regarding this option include: 1. Functionality: When enabled, the action will fail if a pull request introduces dependencies with vulnerabilities at or above the specified severity level [3][2]. 2. Supported Severity Levels: The accepted values are low, moderate, high, and critical [4][2]. 3. Default Behavior: The default value is low, meaning the action will fail on any vulnerability found by default unless configured otherwise [3][2]. 4. Overrides: If the warn-only option is set to true, the action will report all vulnerabilities as warnings and will not fail the workflow, regardless of the fail-on-severity setting [2][5][6]. 5. Configuration: This setting can be specified directly in the workflow YAML file or within an external configuration file (where it is typically written as fail_on_severity with an underscore) [3][2][7]. The action detects vulnerabilities tracked in the GitHub Advisory Database (GHSAs) [3][6]. Users can also use the allow-ghsas option to explicitly exempt specific GitHub Advisory IDs from triggering a failure [2][6].
Citations:
- 1: https://github.com/actions/dependency-review-action
- 2: https://github.com/actions/dependency-review-action/tree/v4.2.5
- 3: https://github.com/actions/dependency-review-action/blob/f71a906c2e433d8ecc6d3ec6063155133f960d43/README.md
- 4: https://github.com/actions/dependency-review-action/blob/main/action.yml
- 5: https://github.com/actions/dependency-review-action/tree/v4.1.1
- 6: https://github.com/actions/dependency-review-action/blob/9129d7d40b8c12c1ed0f60400d00c92d437adcce/README.md
- 7: https://github.com/actions/dependency-review-action/blob/9129d7d40b8c12c1ed0f60400d00c92d437adcce/docs/examples.md
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
p = Path('.github/workflows/dependency-review.yml')
print(p.exists())
if p.exists():
text = p.read_text()
for i, line in enumerate(text.splitlines(), 1):
if 'fail-on-severity' in line or 'dependency-review' in line or 'CVE' in line or 'GHSA' in line:
print(f"{i}: {line}")
PYRepository: Reederey87/codex-plugin-cc
Length of output: 419
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Read the specific file if it exists; otherwise report gracefully.
if [ -f .github/workflows/dependency-review.yml ]; then
awk 'NR>=1 && NR<=80 {printf "%4d %s\n", NR, $0}' .github/workflows/dependency-review.yml
fiRepository: Reederey87/codex-plugin-cc
Length of output: 1268
🌐 Web query:
"dependency-review-action" "fail-on-severity" vulnerability advisory GHSA
💡 Result:
The dependency-review-action uses the fail-on-severity and allow-ghsas options to manage how vulnerabilities, identified by their GitHub Advisory Database (GHSA) IDs, affect your workflow [1][2]. fail-on-severity This option defines the threshold for the severity of vulnerabilities that will cause the action to fail [1][3]. The action checks for dependency changes in your pull requests and will return an error if any introduced vulnerabilities meet or exceed the specified severity level [1][2]. - Possible values: low, moderate, high, critical [1][4]. - Default value: low [1][3]. allow-ghsas This option allows you to explicitly skip specific vulnerabilities by providing a list of their GitHub Advisory Database IDs (GHSAs) [1][2]. Even if a vulnerability would normally cause the action to fail based on your fail-on-severity setting, adding its GHSA ID to allow-ghsas will cause the action to ignore it during detection [1][4]. - Usage: Provide a comma-separated list or a YAML list of valid GHSAs (e.g., GHSA-abcd-1234-5679) [4][3]. Additional options like warn-only can be used to set the action to log vulnerabilities as warnings without failing the job, which overrides the fail-on-severity setting [1][2]. Detailed vulnerability data, including GHSA IDs and severity, is retrieved via GitHub's API [5].
Citations:
- 1: http://github.com/actions/dependency-review-action
- 2: https://github.com/actions/dependency-review-action/tree/v4.2.3
- 3: https://github.com/actions/dependency-review-action/blob/main/README.md
- 4: https://docs.github.com/en/enterprise-server@3.19/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-dependency-review-action
- 5: Bug: High Severity alert being thrown for package version not impacted by the CVE actions/dependency-review-action#150
Describe this as a vulnerability threshold, not a CVE threshold. fail-on-severity applies to any advisory rated moderate or higher, including GHSA advisories without CVEs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/dependency-review.yml around lines 27 - 30, Update the
comments above fail-on-severity in the dependency review workflow to describe
the setting as a vulnerability/advisory severity threshold rather than a CVE
threshold, while preserving the moderate-or-higher behavior and advisory
status-check explanation.
Source: MCP tools
1 participant
Summary
Adds OSS contributor infrastructure to the fork so changes land through reviewed pull requests instead of direct pushes to
main: contributing guide, code of conduct, security policy, issue/PR templates, and README sections.Motivation
The fork had a CI workflow and an
AGENTS.mdwith build/test conventions, but no public-facing contribution path: noCONTRIBUTING.md, no issue/PR templates, noSECURITY.md/CODE_OF_CONDUCT.md, Issues disabled (fork default), and no branch protection. This PR establishes the standard OSS governance so external contributors can file issues and open PRs, and so the maintainer approves before merge. Refs the user request to apply OSS best practices + a PR-with-approval merge model.What changed
CONTRIBUTING.md— fork-aware PR workflow (fork -> branch -> conventional commit -> PR -> CI -> maintainer approval -> merge), build/test setup, upstream-vs-fork routing, branch-protection expectations.CODE_OF_CONDUCT.md— Contributor Covenant v2.1 (enforcement:Reederey87@users.noreply.github.com).SECURITY.md— private vulnerability reporting via GitHub Security Advisories; scope = plugin code (not the wrapped Codex/Grok CLIs); quoting/secrets guidance..github/ISSUE_TEMPLATE/bug_report.yml+feature_request.yml+config.yml— YAML issue forms;config.ymldisables blank issues and adds contact links (security, contributing, upstream Codex issues)..github/pull_request_template.md— PR checklist (summary, motivation, change type, tests/build green, conventional commits, no secrets, CHANGELOG).README.md— Contributing, Code of Conduct, Security, License sections.Repo settings applied alongside this PR (not in the diff):
mainbranch protection: require PR, require 1 approval (admin bypass on for solo self-merge), require theCIstatus check, block force-push and deletion.Change type
docs— documentation only (plus repo metadata templates, no runtime code)Checklist
docs/... actuallyoss/contribution-governance).docs:).npm test— unaffected (docs/yaml only); will be confirmed by CI.npm run build— unaffected (no source changes); will be confirmed by CI.README.md; no plugin CHANGELOG entries needed (no plugin behavior change).Notes for reviewer
This PR dogfoods the new workflow: once merged under the new branch-protection rules, it becomes the reference for future contributions. After merge, external PRs will require your approval to merge, and you can still self-merge your own PRs as admin.
Summary by CodeRabbit