From 4315bb6307c12d3aef41ce5507eb025bc6aa356a Mon Sep 17 00:00:00 2001 From: jochen Date: Tue, 3 Nov 2026 12:46:24 +0100 Subject: [PATCH] A subagent works from hq; a coding one in a worktree under hq's .work, also reading its repository's conventions (the operator, 2026-11-03) --- 00-META/process/07-feature-branches.md | 2 +- AGENTS.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/00-META/process/07-feature-branches.md b/00-META/process/07-feature-branches.md index a1085920..41f7637e 100644 --- a/00-META/process/07-feature-branches.md +++ b/00-META/process/07-feature-branches.md @@ -106,7 +106,7 @@ issue whether it is being fixed in between, after the delivery, or waits, and on `.claude/agents/`: `mesh-preparer` for this step, `mesh-developer` for step 1, `mesh-code-reviewer` for step 2, `mesh-watcher` for every wait, and the four reviewers by architectural domain and `research-reader` of playbook 01. The lead writes only the handover: what the agent works on (issue, records, branch, worktrees, commits) and where it -reports. How it works, what it reads first and what it judges come from its definition, and so does its model: a +reports. 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. How it works, what it reads first and what it judges come from its definition, and so does its model: a `mesh-developer` runs on the smaller model, and the lead starts one on the larger model only for work whose parts meet at an interface still being designed, written with its reason in the milestone file; a lesson about how an agent works goes into its definition by an hq pull request (the operator, 2026-11-03: "please don't write prompts by hand, diff --git a/AGENTS.md b/AGENTS.md index 131949ed..0bf61105 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -18,7 +18,7 @@ playbook 01's *Review by architectural domain*, two architectural domains each: `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 -each interaction onto a mesh path; the lead writes only the handover, never an agent's way of working. +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