The gitea-workflow documentation named a gitea_edit_issue tool that no
namespace had ever registered. There was no sanctioned MCP path to change an
issue title or body at all: the only edit tool, gitea_edit_pr, PATCHes the
pull-request endpoint. An authorized body correction on issue #780 therefore
had to be recorded as a discussion comment instead.
Add edit_issue.py as the authoritative rule and gitea_edit_issue as the tool
built on it:
- Only the fields the caller names are sent, so labels, state, assignee, and
milestone cannot be overwritten from a stale read.
- A pull-request number is refused. Gitea serves pull requests from the same
/issues/{n} collection, so without that check the issue path would quietly
become a second, ungated PR edit path. gitea_edit_pr stays PR-only.
- Structurally invalid requests raise before any credential or network work;
a request that would change nothing is reported as an explicit no-op with a
next action rather than a silent success.
- Read-after-write proves the applied title/body and proves that state,
labels, assignees, and milestone did not move. Transport failures on the
pre-read, the PATCH, and the read-back are each reported, redacted, with
the correct performed/verified state.
Gates match every other issue mutation: profile permission via the shared
capability map (resolver task edit_issue, gitea.issue.comment), preflight
purity, branches worktree validation, anti-stomp inventory membership, and
audited mutation.
Fix the drift that hid this. docs/mcp-tool-inventory.md is now the canonical
registered-tool list, and mcp_tool_inventory.py compares it to the live
registry in both directions, plus checks that every tool named under skills/
is registered. The new guard immediately found a second instance of the same
defect: gitea_record_pre_review_command had lost its @mcp.tool() decorator
while the canonical review workflow still instructed reviewers to call it, so
that registration is restored.
Validation:
PASSED: venv/bin/python -m pytest tests/test_issue_781_edit_issue_tool.py -s -q
— 50 passed
FAILED: venv/bin/python -m pytest -s -q — 4095 passed, 11 failed, 6 skipped.
The identical 11 tests fail on clean master 8e149e6 with no changes applied
(254 passed, 11 failed across those five files), so they are pre-existing
and proven by a baseline run rather than asserted.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
1.5 KiB
1.5 KiB
name, description
| name | description |
|---|---|
| gitea-workflow | Canonical alias for the Gitea/LLM project workflow router. Same skill as llm-project-workflow. Use at the start of any Gitea-Tools author, review, merge, reconcile, or issue-filing task. Trigger terms: gitea-workflow, llm-project-workflow, git-pr-workflows, gitea, PR review, work-issue. |
gitea-workflow (canonical alias)
This directory is the stable name for controller prompts and Codex mounts
(gitea-workflow). The portable implementation lives at:
../llm-project-workflow/SKILL.md
Required action
- Open and follow
skills/llm-project-workflow/SKILL.md(router). - Load the matching workflow under
skills/llm-project-workflow/workflows/. - Do not mutate git/Gitea until the workflow is loaded.
Multi-runtime names (must resolve identically)
| Name | Role |
|---|---|
gitea-workflow |
Canonical controller / Codex skill name |
llm-project-workflow |
Portable in-repo skill package |
git-pr-workflows |
Legacy alias |
Install for Codex:
./scripts/install-codex-workflow-skill.sh
Preflight via MCP: mcp_check_workflow_skill_preflight.
Tool inventory
Which tools actually exist is documented in
docs/mcp-tool-inventory.md, which a test
holds equal to the registered set. Never plan a mutation against a tool that is
not listed there — that is the #781 failure mode, where a documented
gitea_edit_issue did not exist until execution time.