Support removing issue types

[zwick]

Summary

Allow consolidated issue_write and granular update_issue_type to remove an issue type with explicit JSON null.

Why

Related: github/plan-track-agentic-org#193

What changed

• Preserve omitted/set/clear semantics with anyOf schemas (string with minLength: 1 or null), avoiding nullable type arrays for client compatibility noted in fix: use anyOf instead of nullable type array #325.
• Preserve the same tri-state intent in the issue-write MCP App: omitted values may use existing-issue prefill, strings select a type, and explicit null or “Clear selection” submits null.
• Send explicit clears as one REST PATCH containing "type": null and render schema unions as string | null in generated docs.
• Reject suggestion metadata on granular removals because backend and live validation show removal is applied immediately without creating a pending suggestion.

MCP impact

• No tool or API changes
• Tool schema or behavior changed — explicit null removes an issue type; empty strings are invalid.
• New tool added

Prompts tested (tool changes only)

• "Set this issue type to Bug"
• "Remove the type from this issue"

Security / limits

• No security or limits impact — this uses the existing issue update permission and endpoint.
• Auth / permissions considered
• Data exposure, filtering, or token/size limits considered

Tool renaming

• I am renaming tools as part of this PR (e.g. a part of a consolidation effort)
  • I have added the new tool aliases in deprecated_tool_aliases.go
• I am not renaming tools as part of this PR

Note: if you're renaming tools, you must add the tool aliases. For more information on how to do so, please refer to the official docs.

Lint & tests

• Linted locally with ./script/lint
• Tested locally with ./script/test

Focused Go tests cover omitted, string, null, empty-string rejection, exact PATCH JSON, granular suggestions, and metadata rejection without a request. The MCP App passes typecheck and production build. Existing live validation confirmed set and clear through the built server; separate backend/live validation confirmed suggested null removal clears immediately with no pending suggestion.

Docs

• Not needed
• Updated (README / docs / examples) — generated references render nullable unions.

[Copilot]

Pull request overview

Adds empty-string support for clearing issue types in consolidated and granular issue tools.

Changes:

• Sends "type": null when clearing an issue type.
• Bypasses form deferral to preserve explicit clears.
• Adds exact request-body tests and updates generated documentation.

Show a summary per file

File	Description
README.md	Documents issue-type removal.
pkg/github/issues.go	Implements consolidated clear behavior.
pkg/github/issues_test.go	Tests set, omit, clear, and form bypass.
pkg/github/issues_granular.go	Implements granular clear behavior.
pkg/github/granular_tools_test.go	Tests granular clear and validation.
pkg/github/__toolsnaps__/update_issue_type.snap	Updates granular schema snapshot.
pkg/github/__toolsnaps__/issue_write.snap	Updates consolidated schema snapshot.
docs/insiders-features.md	Updates generated insiders documentation.
docs/feature-flags.md	Updates generated feature documentation.

Review details

• Files reviewed: 9/9 changed files
• Comments generated: 0
• Review effort level: Balanced

[tommaso-moro]

Suggested clears are supported by the API using {"type" {"value":null,"suggest":true}}. However, looking at issues_granolar.go it seems to be that {"issue_type":"","is_suggestion":true} currently sends {"type":null} and clears the type immediately? Is this intentional or should we preserve the suggestion flag here?

[alirezainanlosalehi7-lgtm]

1✨✨✨✨✨✨✨✨✨✨✨✨

…

On Wed, Aug 5, 2026, 5:17 PM Tommaso Moro ***@***.***> wrote: ***@***.**** commented on this pull request. Suggested clears are supported by the API using {"type" {"value":null,"suggest":true}}. However, looking at issues_granolar.go it seems to be that {"issue_type":"","is_suggestion":true} currently sends {"type":null} and clears the type immediately? Is this intentional or should we preserve the suggestion flag here? — Reply to this email directly, view it on GitHub <#2999?email_source=notifications&email_token=B5TQM2MVYDVTZYZ2PZKVXB35IM3GJA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIOBWGUYDIOBTGMZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#pullrequestreview-4865048333>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5TQM2P6XPSYP2IFWBVJ6L35IM3GJAVCNFSNUABFKJSXA33TNF2G64TZHM4TIMRXG4YTEOBUHNEXG43VMU5TKMBVGA4DCMZYGMY2C5QC> . You are receiving this because you commented.Message ID: ***@***.***>

[tommaso-moro]

Looking at issues.go I think something like {"type":null,"state":"closed","state_reason":"duplicate"} currently clears the type first (due to "type":null,) , and then returns an error because duplicate_of is missing, but I think it should validate the logic and fail before making any API request?

[zwick]

@tommaso-moro Very nice catch. Adding a validation to prevent this from making the API call accompanied with a test

[tommaso-moro]

lgtm 🚀