chore(github): add codeowner file field to RFC issue template

[krokoko]

Summary

• Adds a * Codeowner file: '' metadata field to the RFC issue template (.github/ISSUE_TEMPLATE/rfc.yml)
• The field is placed in the admin-only metadata section alongside existing fields: RFC PR, Approved by, Reviewed by
• This allows admins to record which codeowner team/entry is relevant to the RFC when triaging

Build and test results

• mise run build: ✅ PASSED — all linters, formatters, schema validation, cross-reference checks, and security scans passed with no errors

Decisions made

The new field was added to the admin metadata section at the bottom of the RFC template (not as a user-facing input), consistent with the pattern of existing metadata fields (RFC PR, Approved by, Reviewed by). This keeps the contributor-facing form unchanged while giving admins a place to record codeowner information during triage.

Agent notes

What went well:

• The RFC template structure was straightforward — a single YAML file with a clear admin metadata section at the bottom
• The build tooling (mise run build) gives comprehensive coverage including markdown linting, JSON schema validation, security scans, and cross-reference checks

What was difficult:

• The task description "add a new codeowner file" was slightly ambiguous — it could mean adding a field about the CODEOWNERS file, creating a new CODEOWNERS entry, or something else. I interpreted it as adding a metadata field to the RFC template referencing the codeowner, consistent with a prior similar task (add codeowner-related field)

Patterns/conventions discovered:

• Admin metadata fields at the bottom of RFC templates use * FieldName: '' format inside a markdown block
• The repo uses mise run build as the single command for full validation
• Commit and PR titles follow conventional commit format: type(scope): description

Suggestions for future tasks:

• Consider adding an interactive dropdown for the codeowner field listing known plugin teams from the CODEOWNERS file
• The CODEOWNERS instructions file at .github/instructions/codeowners.instructions.md is a useful reference for understanding team structure

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[krokoko]

Code Review Summary

This PR adds a single metadata field * Codeowner file: '' to the admin section of the RFC issue template. The change is minimal, targeted, and builds cleanly.

Build result: ✅ mise run build passed — all markdown linting, JSON schema validation, cross-reference checks, and security scans succeeded with no errors.

---

General observations (non-file-specific)

Type: good_point
Title: Minimal, convention-consistent change that fits cleanly into existing admin metadata pattern

Description: The new field correctly follows the * FieldName: '' convention used by the surrounding Approved by and Reviewed by fields, is placed in the clearly-labelled admin-only metadata block (not exposed as a user-facing form element), and introduces no structural changes to the contributor experience. The build passes without any warnings.

[krokoko]

Type: comment
Severity: minor
Title: Field name "Codeowner file" is ambiguous about what value admins should enter

Description: The label "Codeowner file" could reasonably be interpreted as asking for: (a) a team slug from CODEOWNERS (e.g. @awslabs/agent-plugins-dsql), (b) a path pattern from the CODEOWNERS file (e.g. plugins/databases-on-aws), or (c) the literal filename/path .github/CODEOWNERS. Looking at the actual CODEOWNERS file, the most actionable value for triage is likely the owning team slug — but the field name does not make this clear to admins who will populate it.

A name like * Codeowner team: or * Owning team: (when recording the GitHub team) or * CODEOWNERS entry: (when recording the path rule + team line) would reduce ambiguity and improve consistency of how the field gets filled in across different RFCs.

Proposed fix: Rename the field to reflect the intended value type, for example:

* Codeowner team: ''

or

* CODEOWNERS entry: ''

AI prompt: In .github/ISSUE_TEMPLATE/rfc.yml, the line * Codeowner file: '' was recently added to the admin metadata section. The field name is ambiguous — it is unclear whether admins should fill in a GitHub team slug (e.g. @awslabs/agent-plugins-dsql), a CODEOWNERS path rule, or something else. Rename this field to something unambiguous that reflects the intended value. Look at .github/CODEOWNERS for context on what the field should capture, then update the label in the issue template accordingly.

[krokoko]

PR Review: chore(github): add codeowner file field to RFC issue template

Overall assessment: ✅ Clean, minimal change — ready to merge with one minor naming consideration.

---

Findings breakdown

Type	Count
Good points	1
Comments	1
Issues	0
Questions	0

---

Build/test results

mise run build ✅ PASSED — markdown linting, JSON schema validation, cross-reference checks, and all security scans (Bandit, SemGrep, Gitleaks, Checkov, Grype) passed with no errors.

---

Key findings

Good: The new field follows the established * FieldName: '' admin metadata convention perfectly, is placed in the correct section (after the admin disclaimer, not exposed to contributors), and the single-line diff keeps the change reviewable.

Comment (minor, line 78): The label "Codeowner file" is somewhat ambiguous — admins could reasonably interpret it as a team slug (e.g. @awslabs/agent-plugins-dsql), a path pattern from the CODEOWNERS file, or a reference to the file itself. A more specific name like Codeowner team or CODEOWNERS entry would make the expected value self-evident and produce more consistent triage records across RFCs.

---

No blocking issues — the ambiguity is a naming suggestion, not a correctness problem.

[krokoko]

Background agent — COMPLETED

Field	Value
Task	01KQXD6KFYKVPV8VXAS82TS32Y
Repo	krokoko/agent-plugins
Status	COMPLETED
Last event	task_completed @ 2026-05-06T01:13:38.519Z
Pull request	link
Duration	194.5s
Cost	$0.1962