[mabry1985]

Summary

Added two gated write tools to write_tools.py:

• github_edit_issue(number, repo="", title="", body="") — runs gh issue edit <n> --repo … [--title] [--body], the issue-side counterpart of github_edit_pr. Refuses with an Error: string (and runs nothing) when neither title nor body is given.
• github_create_label(name, repo="", color="", description="") — runs gh label create <name> --repo … [--color] [--description] with no --force, so an existing label returns a readable "already exists" message instead of an error trace. Empty name is refused.

Both validate the repo via bad_repo(), read config live through the existing default_repo getter, return readable Error: strings (never raise), and use plain-string @tool docstrings. They register only when github.write is true. Since this adds two tools, the inventory counts were bumped in lockstep (10→12 write, 29→31 total) across test_register.py, test_no_raise_sweep.py's _ARGS, PROTO.md §3/§5, and README.md — otherwise the inventory-coherence gate fails. Version intentionally not bumped.

Fixes #39

[protoreview]

QA panel review — WARN

code-review-structural · head 1566414f8f13 · formal

Clean additive PR with one confirmed minor conventions finding: github_create_label classifies a gh failure tool-side rather than extending check_gh_error, violating PROTO.md §5. Verification confirmed the finding (n=1, no refutations). No prior requests to disposition. No coverage gaps — every changed file was read by at least two finders.

Findings

	Severity	Location	Finding	Verified
🟡	minor	write_tools.py:420	github_create_label classifies a gh failure tool-side (matching 'already exists' in stderr and returning a custom message) instead of adding that category to g…	confirmed

findings JSON (machine-readable)

[
  {
    "file": "write_tools.py",
    "line": 420,
    "severity": "minor",
    "category": "conventions",
    "claim": "github_create_label classifies a gh failure tool-side (matching 'already exists' in stderr and returning a custom message) instead of adding that category to gh_cli.check_gh_error, violating PROTO.md \u00a75's 'Add a category here, not in a tool' rule.",
    "evidence": "low = (serr or \"\").lower()\n        if rc != 0 and (\"already exists\" in low or \"already_exists\" in low):\n            return f\"Label {name!r} already exists in {repo} \u2014 not overwritten (github_create_label never forces).\"\n        if gh_err := check_gh_error(rc, serr, repo=repo):",
    "verdict": "confirmed",
    "note": "Code at write_tools.py:420-423 matches verbatim; PROTO.md \u00a75 (line ~163) states 'Add a category here, not in a tool.' The tool-side 'already exists' check bypasses check_gh_error's classification, violating that rule.",
    "line_original": 419,
    "line_corrected": true
  }
]

[protoreview]

Promoting the WARN verdict for head 1566414f8f13: all checks terminal-green, zero unresolved review threads. (approve-on-green)

Open findings carried by this approval — non-blocking, but they did not go away:

• minor write_tools.py:420 — github_create_label classifies a gh failure tool-side (matching 'already exists' in stderr and returning a custom message) instead of adding that category to gh_cli.check_gh_error, violating PROTO.md

Approving a WARN does not resolve its findings (issue #22).