Brood

---
name: brood
description: "Turn accepted Hoard findings into project improvements and scoped harness nominations, on explicit request."
disable-model-invocation: true
user-invocable: true
argument-hint: "<project-repository> [harness=<repository>]"
---

# Brood — evidence into improvements

Brood is a separately requested post-Hoard task. Resolve the project repository,
its instructions and integration policy, the authorized scope and destination.
An installed skill path is not a destination. Roar captures facts and Hoard
consolidates memory; neither invokes Brood or grants its authority. A memory merge request,
repetition or general usefulness alone does not authorize crystallisation.

## Judge the evidence

Read accepted Hoard reports and their exact source revisions, relevant
consolidated topics, preserved journal episodes and unresolved conflicts.
Record the revisions examined and unavailable/encrypted sources without guessing
contents. Acceptance means reviewed consolidation, not proven effectiveness.

Look for a specific improvement, including simplifying or removing a bad rule.
Compare observed benefit with costs of context, maintenance and exceptions.
Implementation feasibility is not benefit evidence. Trace common origins:
copies, shared prompts and repeated reports of one event are not independent
confirmations. Seek counterexamples and explain conditions where the proposal
fails. There is no repetition threshold or automatic promotion score. Proceed
when the evidence supports the scoped change and its validation; otherwise
report no change or a bounded experiment with its remaining uncertainty.
Current rules govern execution but are not evidence that those rules work.

## Project-to-harness lifecycle

Sequential-blocking: evidence precedes dependent writes; nomination follows the
local proof, and adoption precedes reconciliation. Stop at the authorized scope.

**Project improvement.** Open a project ticket stating the problem, provenance,
benefit hypothesis, costs, exceptions and observable acceptance conditions.
Implement and validate the smallest useful proof of concept in an isolated
project branch, then submit an implementation merge request under that project's policy.
Report actual outcomes separately from proposals and untested expectations.

**Harness nomination.** The project implementation is the proof of concept.
Only when the explicit request names the harness destination and nomination
scope, file a detailed nomination ticket there. This mode writes only that
ticket, never harness rules, skills or shared memory. Include the local ticket
and implementation merge request, tested revisions/results, remaining uncertainties,
conditions, costs, counterexamples, origin relationships and suggested validation
across projects. An unavailable local submission is a disclosed incomplete
prerequisite, not an invented submission. Check clearance for the harness audience before
copying evidence; use an authorized sanitized reproducer or withhold the
nomination and report the missing clearance. Do not expose private source text
or identifying provenance in a public ticket.

**Harness implementation.** This is a separate task explicitly assigning the
harness as the project and authorizing implementation. Examine nominations
across projects and their local implementations, discount common origins,
judge whether they work, generalize only the supported scope and validate in
relevant project contexts, including exceptions. Open a harness ticket and
implementation merge request. On adoption, link the accepted change back to originating
local tickets: replace local copies or document justified retained exceptions
through each project's authorized integration flow. If return writes are not
authorized, record the concrete follow-up destinations and pending actions;
do not claim reconciliation is complete.

## Preserve memory and coordinate revisions

Within the assigned project and scope, Brood implementors may annotate,
simplify or decay consolidated topics and the index when replacement evidence
warrants it. Keep source references, counterexamples and the reason for each
change in the ticket/merge request. Age or rule authority alone cannot justify decay.
Preserve the journal append-only; corrections are new linked entries.

Immediately before writing, compare source revisions with those examined.
Re-read and reconcile concurrent Hoard changes before applying dependent edits;
never overwrite their conclusions from a stale snapshot. Unresolved conflicts
stay visible. Keep the memory index within its project limit (v8: 100 lines).

Use the project's existing ticket, Git and review surfaces; no parallel store.
Check destination diffs, source preservation and actual validation outcomes.
Submit for review without automatic merge. If tools, permissions or submission
are unavailable, preserve the branch and report exactly what remains undone.