Skip to content

Read the pull request draft, template and prose policy in Go instead of shell #910

Description

@tbhb-agent

Problem

Every pull request script re-reads the draft PR_AGENTDESC.md its own way. description.sh reads the frontmatter (scalars, flow sequences, ~ and null as empty), the level 1 title, the body and the base ref, and resolves the template path. pr-checks.sh holds the repository prose policy: the required log entry (pr_log_entry) and the Related grammar (pr_related_pattern). The validator, the publisher, the review script and the unattended wrappers all source that shell. The shell freeze in #588 rules out porting any of them until one tested reader of the draft and its prose policy exists.

Part of #588 and #323. Delivers in Go the behavior of packages/agents/source/skills/pr/shared/scripts/description.sh and pr-checks.sh. This change adds Go behavior only and switches no caller.

Acceptance criteria

  1. AC1: Given a draft with frontmatter base, draft, labels, reviewers, assignees and milestone, when it is read, then each key's value is returned as the shell returns it: surrounding whitespace trimmed, one matched pair of quotes removed, and a comma-separated flow sequence such as [a, "b c"] split into its entries with quotes removed and empty entries dropped.
  2. AC2: Given a key written as a block sequence (the entries on the following lines), when it is read, then the key reads as empty, exactly as the shell reads it, and the entries are not returned for that key.
  3. AC3: Given base: ~, null, Null, NULL, "" or '', when the draft is read, then the value is empty; given the quoted string "null", then the value is the word null.
  4. AC4: Given a draft that opens with frontmatter and has a level 1 heading after it, when the title and body are read, then the title is the first heading's text, and the body is every line after the title line with the blank lines directly after the title dropped and later blank lines kept; given a draft with no opening frontmatter fence, then the title and body are both empty.
  5. AC5: Given the repository pr_template is set, when the template path is resolved, then it is that value, whatever the PR_TEMPLATE environment variable holds; given it is unset and PR_TEMPLATE is set to a nonempty value, then it is the environment value; given it is unset and PR_TEMPLATE is unset or empty, then it is .github/pull_request_template.md, as the shell's :- default gives; given a repository value that is set but empty, or a nonempty value from either source that is absolute, .., begins with ../, contains /../ or ends in /.., then the read refuses with the shell's message "pr_template must name a file inside the repository"; given a name such as notes..md or docs/a..b.md, then it is accepted.
  6. AC6: Given pr_log_entry is required, when the prose policy is checked, then a draft whose last nonblank line is not Log entry: * **Label**: text yields the finding "The description must end with Log entry: * Label: text" and one that ends so yields none; given optional or no value, then no log-entry finding is made; given any other value, then the check refuses with "pr_log_entry must be required or optional".
  7. AC7: Given pr_related_pattern is set, when the prose policy is checked, then the Related section (from ## Related to the next ## heading or the Log entry: line) must hold at least one item, each comma-separated item (after an optional * or - bullet) must match the pattern, and None or None. is accepted only as the sole item, yielding the findings "Related must contain configured items or None" and "Related contains an invalid item" as the shell does; given an invalid regular expression, then the check refuses with "Invalid pr_related_pattern"; given no pattern, then Related is not checked.
  8. AC8: Non-functional: reading the draft and the policy writes no file and makes no network connection.

Scope and non-goals

Scope: reading the draft, resolving the template path, and checking the prose policy, as behavior later children and the shell wrappers call.

Non-goal: validating the draft's frontmatter, title or body rules, which children 02 and 03 do. Non-goal: scaffolding a new draft, which child 04 does. Non-goal: changing which keys the frontmatter accepts. Non-goal: switching any shell caller to the Go behavior, which children 12 and 13 do.

Approach

Meet AC1 to AC8 with failing table-driven cases first, using the draft fixtures the Bats suite already builds, and compare each value with output captured from the shell on the same fixtures. The package layout is the implementer's choice within those outcomes.

Dependencies

Blocked by: #753, for the protection of new Go enforcement paths (this change adds none to the owner-tier lists).

Prerequisite: the repository configuration reader delivered under #321.

Size

S. One pull request.

Verify plan

  • AC1, AC2, AC3, AC4: Go tests over fixture drafts compare each value with the captured shell output.
  • AC5, AC6, AC7: Go tests over scratch repositories with a configuration file for each case, checking message text.
  • AC8: a test runs the built command with the network denied at the operating system (a network-less namespace on Linux, a sandbox profile that denies network access on macOS) and asserts the read succeeds and no file is written; on Windows an in-process dialer and resolver that fail the test on any connection attempt replace the operating system denial.
  • AC5 (precedence): a case sets the repository value and the environment variable to different names, then only the environment variable, then neither, then an empty PR_TEMPLATE with the repository value unset (expecting .github/pull_request_template.md), then an explicitly empty repository value (expecting the refusal), comparing each with the shell's result; the existing template case in tests/skills/pr/scripts/pr-workflow.bats is the oracle.
  • Go tests run in the existing Go CI on macOS, Linux and Windows.
  • Definition of done: D1 each AC is verified at the merged head, with the commands and results cited in the pull request's Verification. D2 an independent review approves the exact merged head, and every finding has a recorded disposition. D3 required checks pass with no gate loosened. D4 the leak scans the repository specifies are clean, and every post made for this work passes the per-post leak review before it is posted. D5 every commit is signed. D6 the documentation matches the change or the Verification says why there is no impact. D7 every commit has an Assisted-by trailer and the pull request has the provenance:agent-assisted label. D8 the pull request stays within the size limits. D9 follow-ups are filed as issues and listed under Related. D10 the merge closes the issue through a closing reference, the board shows Done, and the final Status: comment names the merge commit.

Risks

A frontmatter edge case the shell handles by accident (a trailing space, a CRLF line) would read differently in Go, and the validator would then judge a different draft than the publisher. The shared fixtures are the control. Undo: revert the change; nothing calls the Go behavior yet and the shell reads the draft as before.

Operator authority

None.

Activity

  1. tbhb-agent commented on Oct 27, 2026

    @tbhb-agent
    ContributorAuthor

    Refinement: READY — Read the pull request draft, template and prose policy in Go instead of shell
    Model: gpt-6-astra

    Child 01 Read the pull request draft, template and prose policy in Go instead of shell

    Verdict: READY

    Checked: AC5 now correctly distinguishes an empty PR_TEMPLATE environment value, which selects the default, from an explicitly empty repository value, which refuses. Verification explicitly covers both cases and compares against the shell. This matches packages/agents/source/skills/pr/shared/scripts/description.sh:104 and packages/agents/source/skills/pr/shared/scripts/description.sh:106.

    The problem, scope, prerequisites, AC verification, non-functional checks and undo remain adequate. No new layout prescription or authority change was introduced.

    Gaps: None.

    Split: S remains plausible; no further split needed.

    Definition of done

    The definition of done for this issue (Feature). Tick each item and give its evidence.

    • D1 The author verified each AC on the merged head, and the Verification section of the pull request cites each AC ID with its evidence: the command and its result, or a link.
    • D2 An independent reviewer approved the exact merged head, and the author resolved each finding or filed it as a follow-up.
    • D3 The required checks pass on that head, and any loosened gate has the owner's approval of that exact head.
    • D4 The leak scans come back clean: gitleaks, devtools' check-leaks.sh with the repository's private-strings list, and the leak review of each post.
    • D5 The author signed each commit, the squash included.
    • D6 The docs match the change (README, docs/, CHANGELOG or help text), or the Verification section says "No doc impact" and why.
    • D7 The commits and the squash have Assisted-by trailers, and the pull request has the provenance:agent-assisted label.
    • D8 The pull request stays within the size limits, or the owner approved its exact head over the hard limit.
    • D9 The author files follow-ups and deferred findings as issues with at least a Problem and numbered AC and lists them under the Related section of the pull request. Any work left in the code links its issue.
    • D10 The merge closes the issue through a closing reference and the board shows Done. The final Status: comment names the merge commit.
    • devtools-1 mise run check is green, and so are the coverage floors mise run cover-go-check and mise run cover-py-check, which check doesn't run.
    • devtools-2 A change to skill sources under packages/agents/source/ commits what mise run generate-skills, then mise run skill-tokens, then apm install rewrite, in that order, and check-generated-skills (part of lint) passes.
    • devtools-3 A consumer-visible change (the vendored payload, a skill, a reusable workflow, a task or a pin) has its consumer steps in docs/agent-skills-migration.md or the adoption docs, or the PR's Verification says "No consumer impact" and why.

    Round: 1 of 3

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    refinement:readyPassed the Definition of Ready; may be picked up

    Fields

    Priority

    None yet

    Work type

    None yet

    Projects

    • Status
      Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions