Add outside contributor intake policy

[justin808]

Summary

• document that substantial contributions should start from an accepted issue or maintainer discussion
• add a pull request template that asks for scope, issue context, validation, and contributor ownership of AI-assisted content
• pin the trusted GitHub host and repository used by the outside-contributor intake workflow

Why

This gives contributors clear expectations and lets maintainers close low-signal drive-by changes consistently without spending review and CI time rediscovering the policy. The trusted-origin configuration also allows read-only fork intake to fail closed against the intended repository.

Validation

• git diff --check
• parsed .agents/agent-workflow.yml with Ruby YAML.safe_load_file
• attempted .agents/bin/validate; the existing full suite fails broadly because CPLN_ORG is not configured in this credential-free worktree, before any failure related to these documentation/configuration-only changes

[coderabbitai]

Warning

Review limit reached

@justin808, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 47 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c120db1b-0a9d-46f3-a539-60aeb0c00bbe

📥 Commits

Reviewing files that changed from the base of the PR and between e73d848 and cb50ce2.

📒 Files selected for processing (3)

• .agents/agent-workflow.yml
• .github/pull_request_template.md
• CONTRIBUTING.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch agent/oss-maintainer-policy

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Review: Add outside contributor intake policy

Overview

Small, low-risk, docs/config-only PR: adds a "Before Opening a Pull Request" section to CONTRIBUTING.md, a new .github/pull_request_template.md, and an untrusted_contributor_intake block (trusted_github_host/trusted_github_scheme/trusted_github_repo) to .agents/agent-workflow.yml. No application code (lib/, spec/) is touched, so runtime behavior of cpflow is unaffected.

Code quality / correctness

• The YAML addition is a well-formed nested mapping appended after the existing flat keys — no syntax issues, consistent with the file's "canonical source of policy" role described in its header comment.
• CONTRIBUTING.md prose is clear and consistent in tone with the rest of the doc, and the PR-template checklist language mirrors the new CONTRIBUTING.md guidance closely (focused PRs, no unrelated churn, tests/docs/CHANGELOG, contributor ownership of AI-assisted content), so the two artifacts reinforce each other rather than drift.
• trusted_github_host: github.com, trusted_github_scheme: https, trusted_github_repo: shakacode/control-plane-flow correctly match this repo's actual origin.

Observations (non-blocking)

1. No in-repo consumer of the new YAML keys. I couldn't find any script under .agents/bin/, GitHub Actions workflow, or Ruby code in this repo that reads untrusted_contributor_intake.*. That's consistent with how .agents/trusted-github-actors.yml is also only consumed by external/portable agent skills rather than this repo's own code, so it's likely intentional — but worth confirming that the downstream "outside-contributor intake workflow" mentioned in the PR description actually reads these exact key names before relying on it to fail closed.
2. Unverifiable label references. CONTRIBUTING.md tells contributors to start from an issue labeled good first issue or help wanted. I wasn't able to confirm both labels currently exist on the repo (tool access was restricted in this session) — worth a quick check so the guidance doesn't point contributors at labels that aren't in use.
3. Nice touch that the PR template checklist and CONTRIBUTING.md policy text stay in sync — reduces the chance of the two documents drifting apart over time.

Security / performance / tests

• No security-sensitive code paths are touched; the "fail closed against the intended repository" intent behind pinning host/scheme/repo is reasonable, contingent on point (1) above.
• No test coverage needed/added — appropriate for a docs/policy-only change.
• Performance: not applicable.

Overall: straightforward, well-scoped policy change. No blocking issues found.

[greptile-apps]

Greptile Summary

This PR adds an outside-contributor intake policy and supporting repository configuration. The main changes are:

• Contribution guidance requiring accepted issue or maintainer context for substantial changes.
• A default pull request template covering scope, validation, and contributor responsibility.
• Trusted GitHub host, scheme, and repository values for contributor intake.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed configuration or documentation.
• The contributor policy and pull request template give consistent guidance.
• The pull request template uses GitHub's standard default location.

Important Files Changed

Filename	Overview
.agents/agent-workflow.yml	Adds trusted GitHub origin values for the outside-contributor intake policy.
.github/pull_request_template.md	Adds a default pull request template at GitHub's standard repository path.
CONTRIBUTING.md	Documents issue-first contribution expectations, validation requirements, and responsibility for submitted content.

_{Reviews (1): Last reviewed commit: "Add outside contributor intake policy" | Re-trigger Greptile}

[claude]

Review: Add outside contributor intake policy

Overview: Documentation/config-only PR that (1) adds a "Before Opening a Pull Request" section to CONTRIBUTING.md asking for an accepted issue or maintainer discussion, (2) adds a .github/pull_request_template.md requiring scope/validation/AI-content ownership, and (3) pins trusted_github_host/trusted_github_scheme/trusted_github_repo under a new untrusted_contributor_intake key in .agents/agent-workflow.yml. No runtime code paths change; scope matches the stated intent.

Code quality / correctness

• YAML addition is syntactically valid and matches the PR description's stated validation.
• Nothing in this repo currently reads the new untrusted_contributor_intake keys — consistent with AGENTS.md's model of external portable skills consuming agent-workflow.yml, but it means the wiring can't be verified from this checkout alone.
• The new nested mapping is a stylistic departure from the rest of the file, which uses flat key: "value — inline rationale" scalars. See inline comment.

Security

• Pinning trusted host/repo is a good fail-closed pattern in principle — it prevents a workflow from being redirected to an arbitrary origin via injected input.
• However, the guarantee only holds if the consuming workflow reads this file from the trusted base ref rather than the PR's head ref. If an untrusted contributor's own branch content is what gets parsed, they could edit these values in their own PR to point trust at their own fork. Flagged inline — worth confirming/documenting explicitly since this repo doesn't contain the consuming workflow to verify it directly.

Minor

• CONTRIBUTING.md references good first issue/help wanted labels; worth confirming those labels are actually in active use on this repo's issue tracker so new contributors aren't pointed at an empty label.

Test coverage / validation

• Appropriately docs-only; no tests needed. PR description notes .agents/bin/validate couldn't run cleanly in this environment due to missing CPLN_ORG, unrelated to these changes — reasonable given the change is documentation/config only.

Overall this is a low-risk, well-scoped policy change. The main thing worth double-checking before merge is the base-ref-vs-head-ref trust question above, since it's central to the security value of this PR.

[claude]

Review

Small, low-risk, docs/policy-only change (33 additions, 0 deletions, 3 files, no runtime code). Overall looks solid — clear writing, consistent with existing doc style, and no functional risk.

What it does

• Adds a "Before Opening a Pull Request" section to CONTRIBUTING.md asking for an accepted issue / maintainer discussion before non-trivial PRs.
• Adds .github/pull_request_template.md with Summary / Related issue / Validation / Checklist sections.
• Pins trusted_github_host, trusted_github_scheme, and trusted_github_repo under a new untrusted_contributor_intake key in .agents/agent-workflow.yml.

Code quality / correctness

• The YAML addition is well-formed and consistent with the existing top-level scalar keys in the file; the accompanying comment correctly documents that these values must come from the trusted base ref, not contributor-controlled PR content — good fail-closed design for whatever automation consumes it.
• trusted_github_repo: shakacode/control-plane-flow matches the hardcoded repo string used elsewhere in the codebase (.github/workflows/*, lib/github_flow_templates/**, spec/command/generate_github_actions_spec.rb), so no inconsistency there.
• CONTRIBUTING.md and the PR template checklist are consistent with each other in wording ("accepted issue... or small typo fix"), which avoids the two documents drifting apart.
• No CHANGELOG.md entry, which is correct per this repo's own convention (changelog: "CHANGELOG.md — Keep-a-Changelog; user-visible changes only") since this is contributor-facing policy, not a user-visible feature.

Minor / non-blocking suggestions

• CONTRIBUTING.md references issues "labeled good first issue or help wanted" — worth double-checking those labels actually exist and are actively used on this repo so the guidance doesn't point contributors at empty label filters.
• The new untrusted_contributor_intake block is currently unreferenced anywhere else in this repo (the consuming skill is described as "portable" / external). That's fine as forward config, just flagging so it doesn't look like dead config to a future reader — might be worth a one-line pointer to where/how it's consumed, if that skill lives in a doc somewhere.

Security

• No concerns; if anything this is a security-positive change (pins trusted host/repo for read-only fork intake so it fails closed rather than trusting values that could be spoofed from PR content).

No blocking issues found.