Skip to content

docs: add OSS governance artifacts and PR-based contribution workflow #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Reederey87 merged 3 commits into from
Jul 11, 2026
Merged

docs: add OSS governance artifacts and PR-based contribution workflow #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
0207906
docs: add OSS governance artifacts and PR-based contribution workflow
Jul 11, 2026
94d9692
chore: trigger CI on PR (fork first-run enablement)
Jul 11, 2026
7cd1b4d
chore: add dependency-review workflow
Jul 11, 2026
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
85 changes: 85 additions & 0 deletions .github/ISSUE_TEMPLATE/bug_report.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
name: 🐛 Bug report
description: Report something broken in this fork's plugins (Codex/Grok for Claude Code)
title: "bug: "
labels: ["bug", "triage"]
body:
- type: markdown
attributes:
value: |
Thanks for taking the time to file a bug report for **Coding CLI Companions**
(`Reederey87/codex-plugin-cc`).

- For bugs in the **upstream Codex CLI or plugin**, file them at
[openai/codex-plugin-cc](https://github.com/openai/codex-plugin-cc/issues) instead.
- For **security-sensitive** issues, do **not** use this form. See
[SECURITY.md](https://github.com/Reederey87/codex-plugin-cc/blob/main/SECURITY.md).
- type: dropdown
id: plugin
attributes:
label: Affected plugin
description: Which plugin is affected?
options:
- Codex (`/codex:*`)
- Grok (`/grok:*`)
- Both / unsure
- Repo / packaging / docs
validations:
required: true
- 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
Comment on lines +28 to +35

@coderabbitai coderabbitai Bot Jul 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🎯 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.

- type: textarea
id: what-happened
attributes:
label: What happened?
description: A clear description of the buggy behavior. Paste the relevant output or error message.
placeholder: "When I ran /codex:rescue, it ..."
validations:
required: true
- type: textarea
id: expected
attributes:
label: What did you expect?
description: What you expected to happen instead.
validations:
required: true
- type: textarea
id: repro
attributes:
label: Steps to reproduce
description: Minimal, ordered steps so a maintainer can recreate the issue.
placeholder: |
1. ...
2. ...
3. ...
validations:
required: true
- type: textarea
id: env
attributes:
label: Environment
description: Output of `node -v`, the Claude Code version, and the wrapped CLI version (`codex --version` or `grok --version`). OS/arch too.
placeholder: |
Claude Code: 2.1.x
Node: v22.x
Codex CLI: 0.142.x (or Grok Build: ...)
OS: macOS 15 / arm64
render: shell
validations:
required: true
- type: checkboxes
id: checks
attributes:
label: Pre-flight checks
options:
- label: I searched existing issues and found no duplicate.
required: true
- label: This is a bug in this fork's code, not the upstream Codex CLI/plugin.
required: true
- label: This is not a security vulnerability (I used SECURITY.md for that).
required: true
11 changes: 11 additions & 0 deletions .github/ISSUE_TEMPLATE/config.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
blank_issues_enabled: false
contact_links:
- name: 🔒 Report a security vulnerability
url: https://github.com/Reederey87/codex-plugin-cc/security/advisories/new
about: Do not open public issues for security reports. Use GitHub Private Vulnerability Reporting.
- name: 📖 Contributing guide
url: https://github.com/Reederey87/codex-plugin-cc/blob/main/CONTRIBUTING.md
about: Read the contributing guide before opening a pull request.
- name: 🧭 Upstream Codex issues
url: https://github.com/openai/codex-plugin-cc/issues
about: Bugs or features for the upstream Codex CLI/plugin belong on the upstream repo.
57 changes: 57 additions & 0 deletions .github/ISSUE_TEMPLATE/feature_request.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
name: ✨ Feature request
description: Suggest a new capability for this fork's plugins (Codex/Grok for Claude Code)
title: "feat: "
labels: ["enhancement", "triage"]
body:
- type: markdown
attributes:
value: |
Thanks for suggesting a feature for **Coding CLI Companions**
(`Reederey87/codex-plugin-cc`)!

- Features that apply to the **upstream Codex plugin** should go to
[openai/codex-plugin-cc](https://github.com/openai/codex-plugin-cc/issues).
- Fork-specific ideas (Grok plugin, fork install paths, fork packaging) belong here.
- type: dropdown
id: plugin
attributes:
label: Target plugin
description: Which plugin should this feature affect?
options:
- Codex (`/codex:*`)
- Grok (`/grok:*`)
- Both
- Repo / packaging / docs
validations:
required: true
- type: textarea
id: problem
attributes:
label: Problem
description: What problem does this solve, or what's currently hard to do?
validations:
required: true
- type: textarea
id: solution
attributes:
label: Proposed solution
description: What you'd like to happen. A command shape, flag, or behavior is ideal.
placeholder: "A new /codex:foo --bar flag that ..."
validations:
required: true
- type: textarea
id: alternatives
attributes:
label: Alternatives considered
description: Other ways you considered solving this, and why they fall short.
validations:
required: false
- type: checkboxes
id: checks
attributes:
label: Pre-flight checks
options:
- label: I searched existing issues and found no duplicate.
required: true
- label: This is specific to this fork (not an upstream-only Codex feature).
required: true
45 changes: 45 additions & 0 deletions .github/pull_request_template.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
<!--
Thanks for opening a pull request! Please fill in the sections below.
Read CONTRIBUTING.md for the full workflow. Keep the PR focused on one
logical change. All checks (npm test + npm run build) must pass before merge.
-->

## Summary

<!-- One or two sentences: what does this PR do? -->

## Motivation

<!-- Why is this change needed? What problem does it solve? Link any related issue: Closes #123 / Refs #456 -->

## What changed

<!-- Bulleted list of the meaningful changes. Call out anything reviewers should look at closely. -->

-

## Change type

<!-- Check one. Use Conventional Commits in your commit messages (feat:, fix:, docs:, refactor:, chore:). -->

- [ ] `feat` — new capability
- [ ] `fix` — bug fix
- [ ] `refactor` — no behavior change
- [ ] `docs` — documentation only
- [ ] `chore` — tooling/packaging/ci
- [ ] `breaking` — breaking change (call it out below)

## Checklist

- [ ] Branch is named by type (e.g. `feat/...`, `fix/...`, `docs/...`).
- [ ] Commits follow [Conventional Commits](https://www.conventionalcommits.org/).
- [ ] `npm test` passes locally.
- [ ] `npm run build` passes locally (requires `codex` CLI on PATH for the prebuild step).
- [ ] Tests added/updated for the new behavior (under `tests/`, `*.test.mjs`).
- [ ] No secrets, tokens, or credentials committed.
- [ ] Shell `!`-commands quote `"$ARGUMENTS"` (no unquoted user input).
- [ ] User-facing change? Updated the relevant `plugins/<plugin>/CHANGELOG.md`.

## Notes for reviewer

<!-- Anything the maintainer should know before approving. -->
31 changes: 31 additions & 0 deletions .github/workflows/dependency-review.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
name: Dependency Review

on:
pull_request:
paths:
- '**/package.json'
- '**/package-lock.json'
- '**/npm-shrinkwrap.json'
- '**/yarn.lock'
- '**/pnpm-lock.yaml'

permissions:
contents: read
pull-requests: read

jobs:
dependency-review:
name: Dependency Review
runs-on: ubuntu-latest
timeout-minutes: 5
steps:
- name: Check out repository
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
- name: Dependency Review
uses: actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294 # v5.0.0
with:
# 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
Comment on lines +27 to +30

@coderabbitai coderabbitai Bot Jul 11, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔒 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 . || true

Repository: 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:

🏁 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:

🏁 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}")
PY

Repository: 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
fi

Repository: 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:

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

comment-summary-in-pr: false
129 changes: 129 additions & 0 deletions CODE_OF_CONDUCT.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,129 @@
# Contributor Covenant Code of Conduct

## Our Pledge

We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, caste, color, religion, or sexual
identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.

## Our Standards

Examples of behavior that contributes to a positive environment for our
community include:

* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall
community

Examples of unacceptable behavior include:

* The use of sexualized language or imagery, and sexual attention or advances of
any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email address,
without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting

## Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.

Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.

## Scope

This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a community may
be further defined and clarified by community leaders.

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
**Reederey87@users.noreply.github.com**. All complaints will be reviewed and
investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the
reporter of any incident.

## Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:

### 1. Correction

**Community Impact:** Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.

**Consequence:** A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.

### 2. Warning

**Community Impact:** A violation through a single incident or series of
actions.

**Consequence:** A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or permanent
ban.

### 3. Temporary Ban

**Community Impact:** A serious violation of community standards, including
sustained inappropriate behavior.

**Consequence:** A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this ban. Violating
these terms may lead to a permanent ban.

### 4. Permanent Ban

**Community Impact:** Demonstrating a pattern of violation of community
standards, sustained inappropriate behavior, harassment of an individual, or
aggression toward or disparagement of classes of individuals.

**Consequence:** A permanent ban from any sort of public interaction within the
community.

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.1, available at
<https://www.contributor-covenant.org/version/2/1/code_of_conduct.html>.

Community Impact Guidelines were inspired by
[Mozilla's code of conduct enforcement ladder](https://www.mozilla.org/en-US/about/governance/policies/participation/).

[homepage]: https://www.contributor-covenant.org

For answers to common questions about this code of conduct, see the FAQ at
<https://www.contributor-covenant.org/faq>. Translations are available at
<https://www.contributor-covenant.org/translations>.
Loading
Loading