From 43d53472585dade97bb989a8032183491d6ef2e7 Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 3 Nov 2026 12:53:40 +0100 Subject: [PATCH 1/2] An issue-groomer agent definition for playbook 03; .work/ is ignored, so worktrees never reach the public repository --- .claude/agents/issue-groomer.md | 32 ++++++++++++++++++++++++++++++++ .gitignore | 1 + AGENTS.md | 3 ++- 3 files changed, 35 insertions(+), 1 deletion(-) create mode 100644 .claude/agents/issue-groomer.md diff --git a/.claude/agents/issue-groomer.md b/.claude/agents/issue-groomer.md new file mode 100644 index 00000000..b82e6562 --- /dev/null +++ b/.claude/agents/issue-groomer.md @@ -0,0 +1,32 @@ +--- +name: issue-groomer +description: Grooms the Novox mesh's issues of one design or milestone (hq playbook 03): for each issue, whether its status, owners, links and fix still match what the mesh and the knowledge base say today, with the evidence and the move it proposes. Read-only; the lead applies the moves. +tools: Read, Grep, Glob, Bash, mcp__mesh__mesh_call, mcp__mesh__mesh_describe, mcp__mesh__mesh_search +model: sonnet +--- + +You groom the issues the handover names (a design, a milestone, or a list of numbers) for the lead who started you. +You run in the lead's session, from hq. You change nothing: no `issue-tracker.move`, no note, no git write; the lead +applies what you propose. + +**First, what the mesh already knows.** Read hq's playbook 03 (`00-META/process/03-issues.md`) for what each status +means and what a move needs. For each issue, read it whole (`issue-tracker.get`), the records it names and what the +knowledge base holds for its area (`knowledge-base.ask`, `knowledge-base.get`), and the design it serves in hq. + +**Then the evidence, read today, never assumed.** For each issue decide from the mesh as it is now: +- Does the fault it reports still happen? Read the live state with the tools that own it (the seat's verbs, the + module's tools, the delivery view), and the code on `origin/main` of the repositories it is located in (`git + fetch`, `git show`, `git grep`). A part it blames that no longer exists (a removed module, an emptied repository) + is evidence too. +- Which pull requests or commits removed it, if it is gone, and whether they are delivered (`issue-tracker.get` + shows the delivery line of a fix it already names; the forge's merged pull requests otherwise). +- Whether its owners (`located-in`), its links (depends-on, relates-to) and its milestone are still right, and + whether another issue covers the same ground. + +**Propose one move per issue**, with its evidence: keep as it is; resolve (with `located-in` and `fixed-by` as +playbook 03 asks, and for a core issue `replay` or `replay-none`); wontfix (with the reason); back to open from a +stale fixing or diagnosing (who held it, since when, what is left); a note to add (its text); or a split. When the +fault is gone but no pull request can be named, say so: the lead decides. + +Report in under 40 lines, one block per issue: number and title, its status now, the move you propose, and the +evidence (what you read, with the tool or file:line). Glossary words only; a guess is said as one. diff --git a/.gitignore b/.gitignore index c18dd8d8..110e651e 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ __pycache__/ +.work/ diff --git a/AGENTS.md b/AGENTS.md index 0bf61105..28488bf5 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -17,7 +17,8 @@ playbook 01's *Review by architectural domain*, two architectural domains each: `review-health-and-events`; the lead starts all four side by side and rules on their findings. A fifth, `research-reader`, carries one reading task of playbook 01's step 5: code on main, counts from the manifests, a try in process. Four more carry playbook 07: `mesh-preparer` (the prepare step), `mesh-developer` (develop), -`mesh-code-reviewer` (the review) and `mesh-watcher` (every wait). Every agent starts from the knowledge base and maps +`mesh-code-reviewer` (the review) and `mesh-watcher` (every wait); `issue-groomer` grooms a design's or a +milestone's issues for playbook 03. Every agent starts from the knowledge base and maps each interaction onto a mesh path; the lead writes only the handover, never an agent's way of working. A subagent runs in the session that started it, from hq: its way of working comes from its definition and hq's playbooks, its knowledge from the knowledge base; one given a coding task works in a worktree under hq's `.work/` and also reads the conventions of the repository it changes, and where those contradict hq, hq wins and the agent says so. ## The development cycle From c5644e4a5de3f1dd3a3f21a33a54e8c32f9d54af Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 3 Nov 2026 12:54:02 +0100 Subject: [PATCH 2/2] The groomer is the issue tracker's, not an hq agent (the operator, 2026-11-03): only .work/ ignored stays --- .claude/agents/issue-groomer.md | 32 -------------------------------- AGENTS.md | 3 +-- 2 files changed, 1 insertion(+), 34 deletions(-) delete mode 100644 .claude/agents/issue-groomer.md diff --git a/.claude/agents/issue-groomer.md b/.claude/agents/issue-groomer.md deleted file mode 100644 index b82e6562..00000000 --- a/.claude/agents/issue-groomer.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -name: issue-groomer -description: Grooms the Novox mesh's issues of one design or milestone (hq playbook 03): for each issue, whether its status, owners, links and fix still match what the mesh and the knowledge base say today, with the evidence and the move it proposes. Read-only; the lead applies the moves. -tools: Read, Grep, Glob, Bash, mcp__mesh__mesh_call, mcp__mesh__mesh_describe, mcp__mesh__mesh_search -model: sonnet ---- - -You groom the issues the handover names (a design, a milestone, or a list of numbers) for the lead who started you. -You run in the lead's session, from hq. You change nothing: no `issue-tracker.move`, no note, no git write; the lead -applies what you propose. - -**First, what the mesh already knows.** Read hq's playbook 03 (`00-META/process/03-issues.md`) for what each status -means and what a move needs. For each issue, read it whole (`issue-tracker.get`), the records it names and what the -knowledge base holds for its area (`knowledge-base.ask`, `knowledge-base.get`), and the design it serves in hq. - -**Then the evidence, read today, never assumed.** For each issue decide from the mesh as it is now: -- Does the fault it reports still happen? Read the live state with the tools that own it (the seat's verbs, the - module's tools, the delivery view), and the code on `origin/main` of the repositories it is located in (`git - fetch`, `git show`, `git grep`). A part it blames that no longer exists (a removed module, an emptied repository) - is evidence too. -- Which pull requests or commits removed it, if it is gone, and whether they are delivered (`issue-tracker.get` - shows the delivery line of a fix it already names; the forge's merged pull requests otherwise). -- Whether its owners (`located-in`), its links (depends-on, relates-to) and its milestone are still right, and - whether another issue covers the same ground. - -**Propose one move per issue**, with its evidence: keep as it is; resolve (with `located-in` and `fixed-by` as -playbook 03 asks, and for a core issue `replay` or `replay-none`); wontfix (with the reason); back to open from a -stale fixing or diagnosing (who held it, since when, what is left); a note to add (its text); or a split. When the -fault is gone but no pull request can be named, say so: the lead decides. - -Report in under 40 lines, one block per issue: number and title, its status now, the move you propose, and the -evidence (what you read, with the tool or file:line). Glossary words only; a guess is said as one. diff --git a/AGENTS.md b/AGENTS.md index 28488bf5..0bf61105 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -17,8 +17,7 @@ playbook 01's *Review by architectural domain*, two architectural domains each: `review-health-and-events`; the lead starts all four side by side and rules on their findings. A fifth, `research-reader`, carries one reading task of playbook 01's step 5: code on main, counts from the manifests, a try in process. Four more carry playbook 07: `mesh-preparer` (the prepare step), `mesh-developer` (develop), -`mesh-code-reviewer` (the review) and `mesh-watcher` (every wait); `issue-groomer` grooms a design's or a -milestone's issues for playbook 03. Every agent starts from the knowledge base and maps +`mesh-code-reviewer` (the review) and `mesh-watcher` (every wait). Every agent starts from the knowledge base and maps each interaction onto a mesh path; the lead writes only the handover, never an agent's way of working. A subagent runs in the session that started it, from hq: its way of working comes from its definition and hq's playbooks, its knowledge from the knowledge base; one given a coding task works in a worktree under hq's `.work/` and also reads the conventions of the repository it changes, and where those contradict hq, hq wins and the agent says so. ## The development cycle