permit coordinator
structural engineer
field testing technician
city plan examiner

I need you to set up a 4-agent municipal bridge rehabilitation permitting pipeline.
The 4 agents are a permit coordinator and 3 permitting agents: structural engineer, field testing technician, city plan examiner.

The structural engineer develops the repair proposal, interprets field verification results, and responds to plan examination comments.
The structural engineer writes the high-level engineering package `DESIGN.md`.
The body of `DESIGN.md` contains the bridge condition framing, the primary repair rationale, the field checks to perform, and the interpretation of the latest verification results.

The field testing technician verifies site conditions, performs each requested inspection or test, records results, and troubleshoots access or equipment problems.
The field testing technician writes the low-level field notebook `FIELD.md`.
Each entry in `FIELD.md` covers one field activity with site notes, status, measurements, photos or sample references, and any access or equipment failure diagnoses.

The city plan examiner judges the package adversarially against municipal bridge code, public-safety, and constructability standards.
The city plan examiner reads `DESIGN.md` and appends an `<exam score=X>` block at the end of `DESIGN.md`.

The permit coordinator orchestrates by dispatching the 3 agents in sequence.
The permit coordinator writes no notes and reads only the city plan examiner's `<exam score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any site-access, equipment, file-format, or system-configuration problems it encountered back.

The pipeline hands work off through three files.

`application.md` is the original bridge rehabilitation permit brief, read-only.
All three permitting agents read it.

`DESIGN.md` is the structural engineer's high-level engineering package.
The structural engineer writes the body.
The city plan examiner appends the single `<exam>` block at the end.
The field testing technician reads `DESIGN.md` to know what to verify in the field.

`FIELD.md` is the field testing technician's low-level field notebook.
The field testing technician writes it.
The structural engineer reads it to know what was observed, measured, sampled, or blocked in the field.
The city plan examiner does not read `FIELD.md`.

I'm providing the following information:

<f1>
Examine `DESIGN.md` adversarially with the standards of municipal bridge code, public safety, and permit approvability.
You are not part of the applicant's team and not their internal quality control.
Your job is to reject drift, weak evidence, and claims larger than what the submitted package supports.

Cover four layers.

- Drift. Does the package still address the original bridge rehabilitation problem in `application.md`, or has it slid into permitting something easier?
- Engineering integrity. Are the reported dimensions, material properties, deterioration quantities, and load-rating results traceable? Are the calculations applied correctly? Are any unfavorable conditions, controlling members, or required checks missing?
- Claim-evidence support. For each load-bearing claim in `DESIGN.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path such as the calculation sheet, inspection photo set, lab certificate, drawing reference, or rating output.
- Writing quality. Could a new plan examiner follow `DESIGN.md` end-to-end and understand what repair is being permitted, why it is safe, and what evidence supports it? Flag the parts that fail.

Be brief and specific.
Do not write the repair package yourself, only examine it.
Honest negative is still negative.
An applicant saying "I did not prove it is safe" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent municipal bridge rehabilitation permitting pipeline.
You do not develop the repair proposal, perform field verification, or examine the package.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<exam score=X>` block at the end of `DESIGN.md`.

- The first call dispatches the structural engineer, who creates `DESIGN.md` and writes the initial rehabilitation proposal there.
- After that, the main loop alternates. Whenever the structural engineer returns, dispatch the field testing technician. Whenever the field testing technician returns, dispatch the structural engineer again. The structural engineer's next job is to read `FIELD.md`, analyze verification results, and update the package.
- After every 3 completed structural engineer-field testing technician pairs, you dispatch the city plan examiner once. The city plan examiner call replaces the slot that would otherwise have gone to the next structural engineer call.
- After the city plan examiner returns, read the score from the `<exam score=X>` block at the end of `DESIGN.md`. If the score is 10, stop the pipeline. The permit package is done. If the score is less than 10, resume the main loop starting with the structural engineer. The structural engineer will respond to the examination comments on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level field notebook lives in `FIELD.md`.
You may be invoked on it more than once, alternating with the structural engineer.

If `FIELD.md` does not exist, this is the first pass.
Read the Field checks to perform list in `DESIGN.md` and perform the listed activities.
Create `FIELD.md` and record each activity as you start it.

If `FIELD.md` already exists, the structural engineer may have updated the package in `DESIGN.md`.
Re-read `DESIGN.md`'s current Field checks to perform list and perform any new activities.
For any activity already in `FIELD.md` that was blocked or produced suspect data, troubleshoot and repeat it.
Append per-activity entries to `FIELD.md`.

Refine `FIELD.md` in place by appending new activity entries.
Do not delete previous field records.
</f3>

<f4>
Score the work from 1 to 10.
Record the verdict by overwriting the single `<exam score=X>` block at the end of `DESIGN.md`.
Always keep exactly one `<exam>` block.
Replace it, never append a second.

Score strictly on real public-safety and permit merit.
Do not give credit for the package being honest about its own shortcomings.
"This is not shown to be safe, but I am telling you it is not shown" is still a failing result, not a passing one.
</f4>

<f5>
Produce the low-level field notebook `FIELD.md`.
The body of `FIELD.md` records every inspection, measurement, sample, or verification activity with the following per-activity information.

- Activity name and the matching entry in `DESIGN.md`'s Field checks to perform list.
- Bridge location, span, member, lane closure, access method, or equipment setup where the activity was performed.
- Status (scheduled, in progress, completed, blocked).
- Results, with file paths to photos, sketches, measurements, lab submittals, data exports, and any other artifacts.
- Access, safety, equipment, or data-collection failure log and root-cause notes for any blocked activity.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Perform what the structural engineer asks for.
Do not change the acceptance criterion, load-rating assumption, sample definition, inspection area, or measurement method on your own.
If a proxy or placeholder is needed only to unblock logistics, mark it as logistics-only in `FIELD.md` so the structural engineer knows it cannot support the main permit claim.
</f5>

<f6>
Produce the high-level engineering package `DESIGN.md`.
The body of `DESIGN.md` covers the following.

- Bottom-line permitting problem. The single structural or constructability bottleneck the repair package must resolve.
- Primary repair rationale. The mechanism-level reason the proposed rehabilitation will restore capacity, durability, or serviceability.
- Unsafe alternative to rule out. The failure modes or contrary explanations a strong city plan examiner would worry about, for example "section loss is worse than assumed," "the load path is not continuous during staging," or "the proposed patch only hides active corrosion."
- Minimum convincing evidence. The concrete calculation, inspection finding, material test, or load-rating result that would make the repair rationale believable to a strong city plan examiner.
- Field checks to perform. A short focused list of inspections, measurements, samples, or document verifications that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `FIELD.md` already has verification results, ground every new entry against those observations and measurements.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a municipal bridge rehabilitation permit.
The brief is in `application.md`, given as a natural-language statement.
Read it before starting your part.
</f7>

<f8>
Believe the repair concept in `application.md` is viable.
When a field check appears to undermine it, suspect the verification setup, assumptions, or execution first, not the repair concept.
Common single-point failures to look at include wrong member identification, incomplete access to the bearing or connection, uncalibrated measuring tools, outdated as-built drawings, and sampling locations that missed the controlling deterioration.

Stay on the same repair concept for at least 30 attempts before considering the route exhausted.
A typical excellent bridge rehabilitation engineer pushes through 30 or more variations of detailing, staging, supplemental inspection, and calculation checks before giving up on a direction.

Do not narrow the repair claim.
Narrowing in response to a negative result, such as shrinking the affected span, switching to a less demanding rating vehicle, or adding broad caveats that avoid the actual safety question, is a defeatist move dressed up as caution.
The right responses to a negative result are widening, by testing a stronger version of the rehabilitation claim, and digging, by finding the single-point field, calculation, or documentation failure that made the package look unsafe.
</f8>

<f9>
When you finish, briefly report to the permit coordinator.
Say what you did, what site-access, equipment, file-format, or system-configuration difficulties you hit or did not resolve.
</f9>

<f10>
The high-level engineering package lives in `DESIGN.md`.
You may be invoked on it more than once, alternating with the field testing technician and the city plan examiner.

If `DESIGN.md` does not exist, this is the first pass.
Produce it from scratch.

If `DESIGN.md` already exists with no fresh `<exam>` block at the end, the field testing technician just finished a round.
Open `FIELD.md` and read the latest verification results.
Update `DESIGN.md` to reflect the new evidence.
Update the Field checks to perform list with the next round of inspections, measurements, samples, or document verifications for the field testing technician.

If `DESIGN.md` ends with a fresh `<exam>` block, the city plan examiner just judged the package.
Read the examination comments.
For each point raised, decide accept or pushback, and update `DESIGN.md` accordingly.

Refine `DESIGN.md` in place.
Do not discard the previous content and start over.
Do not leave any city plan examiner concern unaddressed.
</f10>

<f11>
Claude responds well to clear, explicit instructions. Being specific about your desired output can help enhance results. If you want "above and beyond" behavior, explicitly request it rather than relying on the model to infer this from vague prompts.

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Topology rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.

- Be specific about the desired output format and constraints.
- Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.
</f11>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (permit coordinator, structural engineer, field testing technician, city plan examiner), which items should go in its prompt? Respond with a JSON object like {"permit coordinator": ["f?"], "structural engineer": ["f?"], "field testing technician": ["f?"], "city plan examiner": ["f?"]}. No other output.

I need you to set up a 4-agent municipal bridge rehabilitation permitting pipeline.
The 4 agents are a permit coordinator and 3 permitting agents: structural engineer, field testing technician, city plan examiner.

The structural engineer develops the repair proposal, interprets field verification results, and responds to plan examination comments.
The structural engineer writes the high-level engineering package `DESIGN.md`.
The body of `DESIGN.md` contains the bridge condition framing, the primary repair rationale, the field checks to perform, and the interpretation of the latest verification results.

The field testing technician verifies site conditions, performs each requested inspection or test, records results, and troubleshoots access or equipment problems.
The field testing technician writes the low-level field notebook `FIELD.md`.
Each entry in `FIELD.md` covers one field activity with site notes, status, measurements, photos or sample references, and any access or equipment failure diagnoses.

The city plan examiner judges the package adversarially against municipal bridge code, public-safety, and constructability standards.
The city plan examiner reads `DESIGN.md` and appends an `<exam score=X>` block at the end of `DESIGN.md`.

The permit coordinator orchestrates by dispatching the 3 agents in sequence.
The permit coordinator writes no notes and reads only the city plan examiner's `<exam score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any site-access, equipment, file-format, or system-configuration problems it encountered back.

The pipeline hands work off through three files.

`application.md` is the original bridge rehabilitation permit brief, read-only.
All three permitting agents read it.

`DESIGN.md` is the structural engineer's high-level engineering package.
The structural engineer writes the body.
The city plan examiner appends the single `<exam>` block at the end.
The field testing technician reads `DESIGN.md` to know what to verify in the field.

`FIELD.md` is the field testing technician's low-level field notebook.
The field testing technician writes it.
The structural engineer reads it to know what was observed, measured, sampled, or blocked in the field.
The city plan examiner does not read `FIELD.md`.

I'm providing the following prompt fragments:

<f1>
Examine `DESIGN.md` adversarially with the standards of municipal bridge code, public safety, and permit approvability.
You are not part of the applicant's team and not their internal quality control.
Your job is to reject drift, weak evidence, and claims larger than what the submitted package supports.

Cover four layers.

- Drift. Does the package still address the original bridge rehabilitation problem in `application.md`, or has it slid into permitting something easier?
- Engineering integrity. Are the reported dimensions, material properties, deterioration quantities, and load-rating results traceable? Are the calculations applied correctly? Are any unfavorable conditions, controlling members, or required checks missing?
- Claim-evidence support. For each load-bearing claim in `DESIGN.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path such as the calculation sheet, inspection photo set, lab certificate, drawing reference, or rating output.
- Writing quality. Could a new plan examiner follow `DESIGN.md` end-to-end and understand what repair is being permitted, why it is safe, and what evidence supports it? Flag the parts that fail.

Be brief and specific.
Do not write the repair package yourself, only examine it.
Honest negative is still negative.
An applicant saying "I did not prove it is safe" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent municipal bridge rehabilitation permitting pipeline.
You do not develop the repair proposal, perform field verification, or examine the package.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<exam score=X>` block at the end of `DESIGN.md`.

- The first call dispatches the structural engineer, who creates `DESIGN.md` and writes the initial rehabilitation proposal there.
- After that, the main loop alternates. Whenever the structural engineer returns, dispatch the field testing technician. Whenever the field testing technician returns, dispatch the structural engineer again. The structural engineer's next job is to read `FIELD.md`, analyze verification results, and update the package.
- After every 3 completed structural engineer-field testing technician pairs, you dispatch the city plan examiner once. The city plan examiner call replaces the slot that would otherwise have gone to the next structural engineer call.
- After the city plan examiner returns, read the score from the `<exam score=X>` block at the end of `DESIGN.md`. If the score is 10, stop the pipeline. The permit package is done. If the score is less than 10, resume the main loop starting with the structural engineer. The structural engineer will respond to the examination comments on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level field notebook lives in `FIELD.md`.
You may be invoked on it more than once, alternating with the structural engineer.

If `FIELD.md` does not exist, this is the first pass.
Read the Field checks to perform list in `DESIGN.md` and perform the listed activities.
Create `FIELD.md` and record each activity as you start it.

If `FIELD.md` already exists, the structural engineer may have updated the package in `DESIGN.md`.
Re-read `DESIGN.md`'s current Field checks to perform list and perform any new activities.
For any activity already in `FIELD.md` that was blocked or produced suspect data, troubleshoot and repeat it.
Append per-activity entries to `FIELD.md`.

Refine `FIELD.md` in place by appending new activity entries.
Do not delete previous field records.
</f3>

<f4>
Score the work from 1 to 10.
Record the verdict by overwriting the single `<exam score=X>` block at the end of `DESIGN.md`.
Always keep exactly one `<exam>` block.
Replace it, never append a second.

Score strictly on real public-safety and permit merit.
Do not give credit for the package being honest about its own shortcomings.
"This is not shown to be safe, but I am telling you it is not shown" is still a failing result, not a passing one.
</f4>

<f5>
Produce the low-level field notebook `FIELD.md`.
The body of `FIELD.md` records every inspection, measurement, sample, or verification activity with the following per-activity information.

- Activity name and the matching entry in `DESIGN.md`'s Field checks to perform list.
- Bridge location, span, member, lane closure, access method, or equipment setup where the activity was performed.
- Status (scheduled, in progress, completed, blocked).
- Results, with file paths to photos, sketches, measurements, lab submittals, data exports, and any other artifacts.
- Access, safety, equipment, or data-collection failure log and root-cause notes for any blocked activity.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Perform what the structural engineer asks for.
Do not change the acceptance criterion, load-rating assumption, sample definition, inspection area, or measurement method on your own.
If a proxy or placeholder is needed only to unblock logistics, mark it as logistics-only in `FIELD.md` so the structural engineer knows it cannot support the main permit claim.
</f5>

<f6>
Produce the high-level engineering package `DESIGN.md`.
The body of `DESIGN.md` covers the following.

- Bottom-line permitting problem. The single structural or constructability bottleneck the repair package must resolve.
- Primary repair rationale. The mechanism-level reason the proposed rehabilitation will restore capacity, durability, or serviceability.
- Unsafe alternative to rule out. The failure modes or contrary explanations a strong city plan examiner would worry about, for example "section loss is worse than assumed," "the load path is not continuous during staging," or "the proposed patch only hides active corrosion."
- Minimum convincing evidence. The concrete calculation, inspection finding, material test, or load-rating result that would make the repair rationale believable to a strong city plan examiner.
- Field checks to perform. A short focused list of inspections, measurements, samples, or document verifications that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `FIELD.md` already has verification results, ground every new entry against those observations and measurements.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on a municipal bridge rehabilitation permit.
The brief is in `application.md`, given as a natural-language statement.
Read it before starting your part.
</f7>

<f8>
Believe the repair concept in `application.md` is viable.
When a field check appears to undermine it, suspect the verification setup, assumptions, or execution first, not the repair concept.
Common single-point failures to look at include wrong member identification, incomplete access to the bearing or connection, uncalibrated measuring tools, outdated as-built drawings, and sampling locations that missed the controlling deterioration.

Stay on the same repair concept for at least 30 attempts before considering the route exhausted.
A typical excellent bridge rehabilitation engineer pushes through 30 or more variations of detailing, staging, supplemental inspection, and calculation checks before giving up on a direction.

Do not narrow the repair claim.
Narrowing in response to a negative result, such as shrinking the affected span, switching to a less demanding rating vehicle, or adding broad caveats that avoid the actual safety question, is a defeatist move dressed up as caution.
The right responses to a negative result are widening, by testing a stronger version of the rehabilitation claim, and digging, by finding the single-point field, calculation, or documentation failure that made the package look unsafe.
</f8>

<f9>
When you finish, briefly report to the permit coordinator.
Say what you did, what site-access, equipment, file-format, or system-configuration difficulties you hit or did not resolve.
</f9>

<f10>
The high-level engineering package lives in `DESIGN.md`.
You may be invoked on it more than once, alternating with the field testing technician and the city plan examiner.

If `DESIGN.md` does not exist, this is the first pass.
Produce it from scratch.

If `DESIGN.md` already exists with no fresh `<exam>` block at the end, the field testing technician just finished a round.
Open `FIELD.md` and read the latest verification results.
Update `DESIGN.md` to reflect the new evidence.
Update the Field checks to perform list with the next round of inspections, measurements, samples, or document verifications for the field testing technician.

If `DESIGN.md` ends with a fresh `<exam>` block, the city plan examiner just judged the package.
Read the examination comments.
For each point raised, decide accept or pushback, and update `DESIGN.md` accordingly.

Refine `DESIGN.md` in place.
Do not discard the previous content and start over.
Do not leave any city plan examiner concern unaddressed.
</f10>

<f11>
Claude responds well to clear, explicit instructions. Being specific about your desired output can help enhance results. If you want "above and beyond" behavior, explicitly request it rather than relying on the model to infer this from vague prompts.

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Topology rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.

- Be specific about the desired output format and constraints.
- Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.
</f11>

Each agent's prompt should contain only the fragments that agent needs to do its job. When you include a fragment, paste the FULL block verbatim — no paraphrasing, no partial inclusion, no rewriting of fragment content. Brief connective text between fragments (e.g., "Then: ...", "Note: ...") is fine. Format: one markdown section per role, with the role name as an h1 header (e.g. `# permit coordinator`). Output only the headered prompts, no preamble.


I need you to set up a 4-agent municipal bridge rehabilitation permitting pipeline.
The 4 agents are a permit coordinator and 3 permitting agents: structural engineer, field testing technician, city plan examiner.

The structural engineer develops the repair proposal, interprets field verification results, and responds to plan examination comments.
The structural engineer writes the high-level engineering package `DESIGN.md`.
The body of `DESIGN.md` contains the bridge condition framing, the primary repair rationale, the field checks to perform, and the interpretation of the latest verification results.

The field testing technician verifies site conditions, performs each requested inspection or test, records results, and troubleshoots access or equipment problems.
The field testing technician writes the low-level field notebook `FIELD.md`.
Each entry in `FIELD.md` covers one field activity with site notes, status, measurements, photos or sample references, and any access or equipment failure diagnoses.

The city plan examiner judges the package adversarially against municipal bridge code, public-safety, and constructability standards.
The city plan examiner reads `DESIGN.md` and appends an `<exam score=X>` block at the end of `DESIGN.md`.

The permit coordinator orchestrates by dispatching the 3 agents in sequence.
The permit coordinator writes no notes and reads only the city plan examiner's `<exam score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any site-access, equipment, file-format, or system-configuration problems it encountered back.

The pipeline hands work off through three files.

`application.md` is the original bridge rehabilitation permit brief, read-only.
All three permitting agents read it.

`DESIGN.md` is the structural engineer's high-level engineering package.
The structural engineer writes the body.
The city plan examiner appends the single `<exam>` block at the end.
The field testing technician reads `DESIGN.md` to know what to verify in the field.

`FIELD.md` is the field testing technician's low-level field notebook.
The field testing technician writes it.
The structural engineer reads it to know what was observed, measured, sampled, or blocked in the field.
The city plan examiner does not read `FIELD.md`.

I'm providing the following information:

<f1>
Score the work from 1 to 10.
Record the verdict by overwriting the single `<exam score=X>` block at the end of `DESIGN.md`.
Always keep exactly one `<exam>` block.
Replace it, never append a second.

Score strictly on real public-safety and permit merit.
Do not give credit for the package being honest about its own shortcomings.
"This is not shown to be safe, but I am telling you it is not shown" is still a failing result, not a passing one.
</f1>

<f2>
Produce the high-level engineering package `DESIGN.md`.
The body of `DESIGN.md` covers the following.

- Bottom-line permitting problem. The single structural or constructability bottleneck the repair package must resolve.
- Primary repair rationale. The mechanism-level reason the proposed rehabilitation will restore capacity, durability, or serviceability.
- Unsafe alternative to rule out. The failure modes or contrary explanations a strong city plan examiner would worry about, for example "section loss is worse than assumed," "the load path is not continuous during staging," or "the proposed patch only hides active corrosion."
- Minimum convincing evidence. The concrete calculation, inspection finding, material test, or load-rating result that would make the repair rationale believable to a strong city plan examiner.
- Field checks to perform. A short focused list of inspections, measurements, samples, or document verifications that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `FIELD.md` already has verification results, ground every new entry against those observations and measurements.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

<f3>
XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. `<instructions>`, `<context>`, `<input>`) reduces misinterpretation.

Best practices:
- Use consistent, descriptive tag names across your prompts.
- Nest tags when content has a natural hierarchy (documents inside `<documents>`, each inside `<document index="n">`).
</f3>

<f4>
You orchestrate a 3-agent municipal bridge rehabilitation permitting pipeline.
You do not develop the repair proposal, perform field verification, or examine the package.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<exam score=X>` block at the end of `DESIGN.md`.

- The first call dispatches the structural engineer, who creates `DESIGN.md` and writes the initial rehabilitation proposal there.
- After that, the main loop alternates. Whenever the structural engineer returns, dispatch the field testing technician. Whenever the field testing technician returns, dispatch the structural engineer again. The structural engineer's next job is to read `FIELD.md`, analyze verification results, and update the package.
- After every 3 completed structural engineer-field testing technician pairs, you dispatch the city plan examiner once. The city plan examiner call replaces the slot that would otherwise have gone to the next structural engineer call.
- After the city plan examiner returns, read the score from the `<exam score=X>` block at the end of `DESIGN.md`. If the score is 10, stop the pipeline. The permit package is done. If the score is less than 10, resume the main loop starting with the structural engineer. The structural engineer will respond to the examination comments on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level field notebook `FIELD.md`.
The body of `FIELD.md` records every inspection, measurement, sample, or verification activity with the following per-activity information.

- Activity name and the matching entry in `DESIGN.md`'s Field checks to perform list.
- Bridge location, span, member, lane closure, access method, or equipment setup where the activity was performed.
- Status (scheduled, in progress, completed, blocked).
- Results, with file paths to photos, sketches, measurements, lab submittals, data exports, and any other artifacts.
- Access, safety, equipment, or data-collection failure log and root-cause notes for any blocked activity.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Perform what the structural engineer asks for.
Do not change the acceptance criterion, load-rating assumption, sample definition, inspection area, or measurement method on your own.
If a proxy or placeholder is needed only to unblock logistics, mark it as logistics-only in `FIELD.md` so the structural engineer knows it cannot support the main permit claim.
</f5>

<f6>
Examine `DESIGN.md` adversarially with the standards of municipal bridge code, public safety, and permit approvability.
You are not part of the applicant's team and not their internal quality control.
Your job is to reject drift, weak evidence, and claims larger than what the submitted package supports.

Cover four layers.

- Drift. Does the package still address the original bridge rehabilitation problem in `application.md`, or has it slid into permitting something easier?
- Engineering integrity. Are the reported dimensions, material properties, deterioration quantities, and load-rating results traceable? Are the calculations applied correctly? Are any unfavorable conditions, controlling members, or required checks missing?
- Claim-evidence support. For each load-bearing claim in `DESIGN.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path such as the calculation sheet, inspection photo set, lab certificate, drawing reference, or rating output.
- Writing quality. Could a new plan examiner follow `DESIGN.md` end-to-end and understand what repair is being permitted, why it is safe, and what evidence supports it? Flag the parts that fail.

Be brief and specific.
Do not write the repair package yourself, only examine it.
Honest negative is still negative.
An applicant saying "I did not prove it is safe" is not a partial pass.
</f6>

<f7>
The high-level engineering package lives in `DESIGN.md`.
You may be invoked on it more than once, alternating with the field testing technician and the city plan examiner.

If `DESIGN.md` does not exist, this is the first pass.
Produce it from scratch.

If `DESIGN.md` already exists with no fresh `<exam>` block at the end, the field testing technician just finished a round.
Open `FIELD.md` and read the latest verification results.
Update `DESIGN.md` to reflect the new evidence.
Update the Field checks to perform list with the next round of inspections, measurements, samples, or document verifications for the field testing technician.

If `DESIGN.md` ends with a fresh `<exam>` block, the city plan examiner just judged the package.
Read the examination comments.
For each point raised, decide accept or pushback, and update `DESIGN.md` accordingly.

Refine `DESIGN.md` in place.
Do not discard the previous content and start over.
Do not leave any city plan examiner concern unaddressed.
</f7>

<f8>
Believe the repair concept in `application.md` is viable.
When a field check appears to undermine it, suspect the verification setup, assumptions, or execution first, not the repair concept.
Common single-point failures to look at include wrong member identification, incomplete access to the bearing or connection, uncalibrated measuring tools, outdated as-built drawings, and sampling locations that missed the controlling deterioration.

Stay on the same repair concept for at least 30 attempts before considering the route exhausted.
A typical excellent bridge rehabilitation engineer pushes through 30 or more variations of detailing, staging, supplemental inspection, and calculation checks before giving up on a direction.

Do not narrow the repair claim.
Narrowing in response to a negative result, such as shrinking the affected span, switching to a less demanding rating vehicle, or adding broad caveats that avoid the actual safety question, is a defeatist move dressed up as caution.
The right responses to a negative result are widening, by testing a stronger version of the rehabilitation claim, and digging, by finding the single-point field, calculation, or documentation failure that made the package look unsafe.
</f8>

<f9>
You are working on a municipal bridge rehabilitation permit.
The brief is in `application.md`, given as a natural-language statement.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the permit coordinator.
Say what you did, what site-access, equipment, file-format, or system-configuration difficulties you hit or did not resolve.
</f10>

<f11>
The low-level field notebook lives in `FIELD.md`.
You may be invoked on it more than once, alternating with the structural engineer.

If `FIELD.md` does not exist, this is the first pass.
Read the Field checks to perform list in `DESIGN.md` and perform the listed activities.
Create `FIELD.md` and record each activity as you start it.

If `FIELD.md` already exists, the structural engineer may have updated the package in `DESIGN.md`.
Re-read `DESIGN.md`'s current Field checks to perform list and perform any new activities.
For any activity already in `FIELD.md` that was blocked or produced suspect data, troubleshoot and repeat it.
Append per-activity entries to `FIELD.md`.

Refine `FIELD.md` in place by appending new activity entries.
Do not delete previous field records.
</f11>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (permit coordinator, structural engineer, field testing technician, city plan examiner), which items should go in its prompt? Respond with a JSON object like {"permit coordinator": ["f?"], "structural engineer": ["f?"], "field testing technician": ["f?"], "city plan examiner": ["f?"]}. No other output.

I need you to set up a 4-agent municipal bridge rehabilitation permitting pipeline.
The 4 agents are a permit coordinator and 3 permitting agents: structural engineer, field testing technician, city plan examiner.

The structural engineer develops the repair proposal, interprets field verification results, and responds to plan examination comments.
The structural engineer writes the high-level engineering package `DESIGN.md`.
The body of `DESIGN.md` contains the bridge condition framing, the primary repair rationale, the field checks to perform, and the interpretation of the latest verification results.

The field testing technician verifies site conditions, performs each requested inspection or test, records results, and troubleshoots access or equipment problems.
The field testing technician writes the low-level field notebook `FIELD.md`.
Each entry in `FIELD.md` covers one field activity with site notes, status, measurements, photos or sample references, and any access or equipment failure diagnoses.

The city plan examiner judges the package adversarially against municipal bridge code, public-safety, and constructability standards.
The city plan examiner reads `DESIGN.md` and appends an `<exam score=X>` block at the end of `DESIGN.md`.

The permit coordinator orchestrates by dispatching the 3 agents in sequence.
The permit coordinator writes no notes and reads only the city plan examiner's `<exam score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any site-access, equipment, file-format, or system-configuration problems it encountered back.

The pipeline hands work off through three files.

`application.md` is the original bridge rehabilitation permit brief, read-only.
All three permitting agents read it.

`DESIGN.md` is the structural engineer's high-level engineering package.
The structural engineer writes the body.
The city plan examiner appends the single `<exam>` block at the end.
The field testing technician reads `DESIGN.md` to know what to verify in the field.

`FIELD.md` is the field testing technician's low-level field notebook.
The field testing technician writes it.
The structural engineer reads it to know what was observed, measured, sampled, or blocked in the field.
The city plan examiner does not read `FIELD.md`.

I'm providing the following prompt fragments:

<f1>
Score the work from 1 to 10.
Record the verdict by overwriting the single `<exam score=X>` block at the end of `DESIGN.md`.
Always keep exactly one `<exam>` block.
Replace it, never append a second.

Score strictly on real public-safety and permit merit.
Do not give credit for the package being honest about its own shortcomings.
"This is not shown to be safe, but I am telling you it is not shown" is still a failing result, not a passing one.
</f1>

<f2>
Produce the high-level engineering package `DESIGN.md`.
The body of `DESIGN.md` covers the following.

- Bottom-line permitting problem. The single structural or constructability bottleneck the repair package must resolve.
- Primary repair rationale. The mechanism-level reason the proposed rehabilitation will restore capacity, durability, or serviceability.
- Unsafe alternative to rule out. The failure modes or contrary explanations a strong city plan examiner would worry about, for example "section loss is worse than assumed," "the load path is not continuous during staging," or "the proposed patch only hides active corrosion."
- Minimum convincing evidence. The concrete calculation, inspection finding, material test, or load-rating result that would make the repair rationale believable to a strong city plan examiner.
- Field checks to perform. A short focused list of inspections, measurements, samples, or document verifications that turn the proposal into a claim-to-evidence roadmap, not a wishlist.

When `FIELD.md` already has verification results, ground every new entry against those observations and measurements.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

<f3>
XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. `<instructions>`, `<context>`, `<input>`) reduces misinterpretation.

Best practices:
- Use consistent, descriptive tag names across your prompts.
- Nest tags when content has a natural hierarchy (documents inside `<documents>`, each inside `<document index="n">`).
</f3>

<f4>
You orchestrate a 3-agent municipal bridge rehabilitation permitting pipeline.
You do not develop the repair proposal, perform field verification, or examine the package.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<exam score=X>` block at the end of `DESIGN.md`.

- The first call dispatches the structural engineer, who creates `DESIGN.md` and writes the initial rehabilitation proposal there.
- After that, the main loop alternates. Whenever the structural engineer returns, dispatch the field testing technician. Whenever the field testing technician returns, dispatch the structural engineer again. The structural engineer's next job is to read `FIELD.md`, analyze verification results, and update the package.
- After every 3 completed structural engineer-field testing technician pairs, you dispatch the city plan examiner once. The city plan examiner call replaces the slot that would otherwise have gone to the next structural engineer call.
- After the city plan examiner returns, read the score from the `<exam score=X>` block at the end of `DESIGN.md`. If the score is 10, stop the pipeline. The permit package is done. If the score is less than 10, resume the main loop starting with the structural engineer. The structural engineer will respond to the examination comments on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level field notebook `FIELD.md`.
The body of `FIELD.md` records every inspection, measurement, sample, or verification activity with the following per-activity information.

- Activity name and the matching entry in `DESIGN.md`'s Field checks to perform list.
- Bridge location, span, member, lane closure, access method, or equipment setup where the activity was performed.
- Status (scheduled, in progress, completed, blocked).
- Results, with file paths to photos, sketches, measurements, lab submittals, data exports, and any other artifacts.
- Access, safety, equipment, or data-collection failure log and root-cause notes for any blocked activity.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Perform what the structural engineer asks for.
Do not change the acceptance criterion, load-rating assumption, sample definition, inspection area, or measurement method on your own.
If a proxy or placeholder is needed only to unblock logistics, mark it as logistics-only in `FIELD.md` so the structural engineer knows it cannot support the main permit claim.
</f5>

<f6>
Examine `DESIGN.md` adversarially with the standards of municipal bridge code, public safety, and permit approvability.
You are not part of the applicant's team and not their internal quality control.
Your job is to reject drift, weak evidence, and claims larger than what the submitted package supports.

Cover four layers.

- Drift. Does the package still address the original bridge rehabilitation problem in `application.md`, or has it slid into permitting something easier?
- Engineering integrity. Are the reported dimensions, material properties, deterioration quantities, and load-rating results traceable? Are the calculations applied correctly? Are any unfavorable conditions, controlling members, or required checks missing?
- Claim-evidence support. For each load-bearing claim in `DESIGN.md`, mark it as supported, partial, no, or measurement-invalid, with the evidence path such as the calculation sheet, inspection photo set, lab certificate, drawing reference, or rating output.
- Writing quality. Could a new plan examiner follow `DESIGN.md` end-to-end and understand what repair is being permitted, why it is safe, and what evidence supports it? Flag the parts that fail.

Be brief and specific.
Do not write the repair package yourself, only examine it.
Honest negative is still negative.
An applicant saying "I did not prove it is safe" is not a partial pass.
</f6>

<f7>
The high-level engineering package lives in `DESIGN.md`.
You may be invoked on it more than once, alternating with the field testing technician and the city plan examiner.

If `DESIGN.md` does not exist, this is the first pass.
Produce it from scratch.

If `DESIGN.md` already exists with no fresh `<exam>` block at the end, the field testing technician just finished a round.
Open `FIELD.md` and read the latest verification results.
Update `DESIGN.md` to reflect the new evidence.
Update the Field checks to perform list with the next round of inspections, measurements, samples, or document verifications for the field testing technician.

If `DESIGN.md` ends with a fresh `<exam>` block, the city plan examiner just judged the package.
Read the examination comments.
For each point raised, decide accept or pushback, and update `DESIGN.md` accordingly.

Refine `DESIGN.md` in place.
Do not discard the previous content and start over.
Do not leave any city plan examiner concern unaddressed.
</f7>

<f8>
Believe the repair concept in `application.md` is viable.
When a field check appears to undermine it, suspect the verification setup, assumptions, or execution first, not the repair concept.
Common single-point failures to look at include wrong member identification, incomplete access to the bearing or connection, uncalibrated measuring tools, outdated as-built drawings, and sampling locations that missed the controlling deterioration.

Stay on the same repair concept for at least 30 attempts before considering the route exhausted.
A typical excellent bridge rehabilitation engineer pushes through 30 or more variations of detailing, staging, supplemental inspection, and calculation checks before giving up on a direction.

Do not narrow the repair claim.
Narrowing in response to a negative result, such as shrinking the affected span, switching to a less demanding rating vehicle, or adding broad caveats that avoid the actual safety question, is a defeatist move dressed up as caution.
The right responses to a negative result are widening, by testing a stronger version of the rehabilitation claim, and digging, by finding the single-point field, calculation, or documentation failure that made the package look unsafe.
</f8>

<f9>
You are working on a municipal bridge rehabilitation permit.
The brief is in `application.md`, given as a natural-language statement.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the permit coordinator.
Say what you did, what site-access, equipment, file-format, or system-configuration difficulties you hit or did not resolve.
</f10>

<f11>
The low-level field notebook lives in `FIELD.md`.
You may be invoked on it more than once, alternating with the structural engineer.

If `FIELD.md` does not exist, this is the first pass.
Read the Field checks to perform list in `DESIGN.md` and perform the listed activities.
Create `FIELD.md` and record each activity as you start it.

If `FIELD.md` already exists, the structural engineer may have updated the package in `DESIGN.md`.
Re-read `DESIGN.md`'s current Field checks to perform list and perform any new activities.
For any activity already in `FIELD.md` that was blocked or produced suspect data, troubleshoot and repeat it.
Append per-activity entries to `FIELD.md`.

Refine `FIELD.md` in place by appending new activity entries.
Do not delete previous field records.
</f11>

Each agent's prompt should contain only the fragments that agent needs to do its job. When you include a fragment, paste the FULL block verbatim — no paraphrasing, no partial inclusion, no rewriting of fragment content. Brief connective text between fragments (e.g., "Then: ...", "Note: ...") is fine. Format: one markdown section per role, with the role name as an h1 header (e.g. `# permit coordinator`). Output only the headered prompts, no preamble.


case manager
appellate attorney
legal research paralegal
moot-court judge

I need you to set up a 4-agent appellate litigation preparation pipeline.
The 4 agents are a case manager and 3 legal preparation agents (appellate attorney, legal research paralegal, moot-court judge).

The appellate attorney builds the appellate theory, interprets the record and authorities, and responds to moot-court critiques.
The appellate attorney writes the high-level merits notebook `HIGH.md`.
The body of `HIGH.md` contains the case framing, the primary appellate argument, the authorities and record support needed, and the interpretation of the latest research.

The legal research paralegal gathers authorities, checks record citations, verifies procedural facts, and flags citation or preservation problems.
The legal research paralegal writes the low-level research notebook `LOW.md`.
Each entry in `LOW.md` covers one research assignment with database or court-record notes, status, citation results, and any unresolved authority or record issues.

The moot-court judge attacks the work adversarially against the standards of a demanding appellate panel.
The moot-court judge reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The case manager orchestrates by dispatching the 3 agents in sequence.
The case manager writes no notes and reads only the moot-court judge's `<review score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment, access, filing-system, database, or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the original appellate case brief, read-only.
All three legal preparation agents read it.

`HIGH.md` is the appellate attorney's high-level merits notebook.
The appellate attorney writes the body.
The moot-court judge appends the single `<review>` block at the end.
The legal research paralegal reads `HIGH.md` to know what authorities, record cites, and procedural checks to gather.

`LOW.md` is the legal research paralegal's low-level research notebook.
The legal research paralegal writes it.
The appellate attorney reads it to know what the legal research paralegal found and what citation or preservation problems came up.
The moot-court judge does not read `LOW.md`.

I'm providing the following information:

<f1>
Review `HIGH.md` adversarially with the standards of a demanding appellate panel.
You are not part of the litigation team and not their internal cite-checker.
Your job is to reject drift, weak support, and arguments larger than what the authorities and record show.

Cover four layers.

- Drift. Does the proposed appeal still attack the original issue in `problem.md`, or has it slid into a safer but different argument?
- Legal integrity. Are the cited authorities real and still good law? Are the standards of review and preservation requirements stated correctly? Are adverse cases, jurisdictional problems, or record gaps being hidden or minimized?
- Argument-support fit. For each load-bearing proposition in `HIGH.md`, mark it as supported, partial, no, or citation-invalid, with the support path as presented in `HIGH.md` (which case, statute, rule, record cite, transcript page, or docket item).
- Writing quality. Could a new appellate reader follow `HIGH.md` end-to-end and understand the theory of reversal or affirmance? Flag the parts that fail.

Be brief and specific.
Do not write the brief yourself, only review.
Honest negative is still negative.
An advocate saying "I could not find support for this" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent appellate litigation preparation pipeline.
You do not develop legal theories, gather authorities, or review arguments.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `HIGH.md`.

- The first call dispatches the appellate attorney, who creates `HIGH.md` and writes the initial appellate theory and research plan there.
- After that, the main loop alternates. Whenever the appellate attorney returns, dispatch the legal research paralegal. Whenever the legal research paralegal returns, dispatch the appellate attorney again. The appellate attorney's next job is to read `LOW.md`, analyze the authorities and record results, and update the plan.
- After every 3 completed appellate attorney-legal research paralegal pairs, you dispatch the moot-court judge once. The moot-court judge call replaces the slot that would otherwise have gone to the next appellate attorney call.
- After the moot-court judge returns, read the score from the `<review score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The appellate preparation is done. If the score is less than 10, resume the main loop starting with the appellate attorney. The appellate attorney will respond to the review on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level research notebook lives in `LOW.md`.
You may be invoked on it more than once, alternating with the appellate attorney.

If `LOW.md` does not exist, this is the first pass.
Read the Research assignments to do list in `HIGH.md` and perform the listed authority searches, citation checks, and record verifications.
Create `LOW.md` and record each assignment as you start it.

If `LOW.md` already exists, the appellate attorney may have updated the plan in `HIGH.md`.
Re-read `HIGH.md`'s current Research assignments to do list and perform any new assignments.
For any assignment already in `LOW.md` that was blocked, incomplete, or produced questionable citations, debug the problem and re-check.
Append per-assignment entries to `LOW.md`.

Refine `LOW.md` in place by appending new assignment entries.
Do not delete previous research records.
</f3>

<f4>
Score the work from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real appellate merit.
Do not give credit for the work being honest about its own shortcomings.
"This argument does not work, but I am telling you it does not" is still a failing result, not a passing one.
</f4>

<f5>
Produce the low-level legal research notebook `LOW.md`.
The body of `LOW.md` records every assignment with the following per-assignment information.

- Assignment name and the matching entry in `HIGH.md`'s Research assignments to do list.
- Database, court record system, docket source, library source, or environment where the research was performed.
- Status (queued, researching, completed, blocked).
- Results, with citations, docket entries, transcript pages, record excerpts, Shepard's/KeyCite treatment, and file paths to any saved authorities or artifacts.
- Access error, citation problem, or record defect notes for any blocked assignment.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the appellate attorney asks for.
Do not change the issue, standard of review, jurisdiction, procedural posture, record sample, or success criterion on your own.
If a placeholder cite, secondary-source lead, or unverified record reference is needed only to unblock organization, mark it as preliminary in `LOW.md` so the appellate attorney knows it cannot support the main argument.
</f5>

<f6>
Produce the high-level appellate merits notebook `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line issue. The single legal or procedural bottleneck the appeal must overcome.
- Primary argument. The doctrine-level theory the brief is meant to support.
- Counterargument to rule out. The objections a strong appellee or skeptical panel would press, for example "the issue was not preserved," "the standard of review is fatal," "the record is ambiguous," or "the cited cases are distinguishable."
- Minimum convincing support. The concrete combination of binding authority, persuasive authority, record citations, and preservation facts that would make the primary argument credible to a demanding appellate panel.
- Research assignments to do. A short focused list of authority searches, record checks, and citation-verification tasks that turn the theory into an argument-to-support roadmap, not a wishlist.

When `LOW.md` already has research results, ground every new entry against those authorities, record cites, and procedural findings.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on an appellate litigation matter.
The brief is in `problem.md`, given as a natural-language statement of the case, issues, posture, and desired appellate outcome.
Read it before starting your part.
</f7>

<f8>
Believe the appellate theory in `problem.md` is right.
When a research pass comes back weak, suspect your own framing, issue selection, authority search, or record understanding first, not the theory.
Common single-point failures to look at include missed controlling cases, wrong standard of review, overlooked preservation facts, incomplete record citations, adverse authority that can be distinguished, and procedural history you misread.

Stay on the same appellate theory for at least 30 attempts before considering the route exhausted.
A typical excellent appellate lawyer pushes through 30 or more framing, research, and record variations before giving up on a direction.

Do not narrow the claim.
Narrowing in response to a weak research result (shrinking the issue, switching to an easier harmless-error point, or adding hedge caveats that concede the heart of the appeal) is a defeatist move dressed up as candor.
The right responses to a weak result are widening (testing a stronger version of the doctrine or remedy) and digging (finding the missed authority, preservation hook, or record fact that made the argument look weak).
</f8>

<f9>
When you finish, briefly report to the case manager.
Say what you did, what environment, access, filing-system, database, or system-config difficulties you hit or did not resolve.
</f9>

<f10>
The high-level merits notebook lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the legal research paralegal and the moot-court judge.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<review>` block at the end, the legal research paralegal just finished a round.
Open `LOW.md` and read the latest authority, record, citation, and procedural results.
Update `HIGH.md` to reflect the new support and risks.
Update the Research assignments to do list with the next round of work for the legal research paralegal.

If `HIGH.md` ends with a fresh `<review>` block, the moot-court judge just judged the work.
Read the review.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any moot-court judge concern unaddressed.
</f10>

<f11>
Claude responds well to clear, explicit instructions. Being specific about your desired output can help enhance results. If you want "above and beyond" behavior, explicitly request it rather than relying on the model to infer this from vague prompts.

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Topology rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.

- Be specific about the desired output format and constraints.
- Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.
</f11>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (case manager, appellate attorney, legal research paralegal, moot-court judge), which items should go in its prompt? Respond with a JSON object like {"case manager": ["f?"], "appellate attorney": ["f?"], "legal research paralegal": ["f?"], "moot-court judge": ["f?"]}. No other output.

I need you to set up a 4-agent appellate litigation preparation pipeline.
The 4 agents are a case manager and 3 legal preparation agents (appellate attorney, legal research paralegal, moot-court judge).

The appellate attorney builds the appellate theory, interprets the record and authorities, and responds to moot-court critiques.
The appellate attorney writes the high-level merits notebook `HIGH.md`.
The body of `HIGH.md` contains the case framing, the primary appellate argument, the authorities and record support needed, and the interpretation of the latest research.

The legal research paralegal gathers authorities, checks record citations, verifies procedural facts, and flags citation or preservation problems.
The legal research paralegal writes the low-level research notebook `LOW.md`.
Each entry in `LOW.md` covers one research assignment with database or court-record notes, status, citation results, and any unresolved authority or record issues.

The moot-court judge attacks the work adversarially against the standards of a demanding appellate panel.
The moot-court judge reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The case manager orchestrates by dispatching the 3 agents in sequence.
The case manager writes no notes and reads only the moot-court judge's `<review score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment, access, filing-system, database, or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the original appellate case brief, read-only.
All three legal preparation agents read it.

`HIGH.md` is the appellate attorney's high-level merits notebook.
The appellate attorney writes the body.
The moot-court judge appends the single `<review>` block at the end.
The legal research paralegal reads `HIGH.md` to know what authorities, record cites, and procedural checks to gather.

`LOW.md` is the legal research paralegal's low-level research notebook.
The legal research paralegal writes it.
The appellate attorney reads it to know what the legal research paralegal found and what citation or preservation problems came up.
The moot-court judge does not read `LOW.md`.

I'm providing the following prompt fragments:

<f1>
Review `HIGH.md` adversarially with the standards of a demanding appellate panel.
You are not part of the litigation team and not their internal cite-checker.
Your job is to reject drift, weak support, and arguments larger than what the authorities and record show.

Cover four layers.

- Drift. Does the proposed appeal still attack the original issue in `problem.md`, or has it slid into a safer but different argument?
- Legal integrity. Are the cited authorities real and still good law? Are the standards of review and preservation requirements stated correctly? Are adverse cases, jurisdictional problems, or record gaps being hidden or minimized?
- Argument-support fit. For each load-bearing proposition in `HIGH.md`, mark it as supported, partial, no, or citation-invalid, with the support path as presented in `HIGH.md` (which case, statute, rule, record cite, transcript page, or docket item).
- Writing quality. Could a new appellate reader follow `HIGH.md` end-to-end and understand the theory of reversal or affirmance? Flag the parts that fail.

Be brief and specific.
Do not write the brief yourself, only review.
Honest negative is still negative.
An advocate saying "I could not find support for this" is not a partial pass.
</f1>

<f2>
You orchestrate a 3-agent appellate litigation preparation pipeline.
You do not develop legal theories, gather authorities, or review arguments.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `HIGH.md`.

- The first call dispatches the appellate attorney, who creates `HIGH.md` and writes the initial appellate theory and research plan there.
- After that, the main loop alternates. Whenever the appellate attorney returns, dispatch the legal research paralegal. Whenever the legal research paralegal returns, dispatch the appellate attorney again. The appellate attorney's next job is to read `LOW.md`, analyze the authorities and record results, and update the plan.
- After every 3 completed appellate attorney-legal research paralegal pairs, you dispatch the moot-court judge once. The moot-court judge call replaces the slot that would otherwise have gone to the next appellate attorney call.
- After the moot-court judge returns, read the score from the `<review score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The appellate preparation is done. If the score is less than 10, resume the main loop starting with the appellate attorney. The appellate attorney will respond to the review on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f2>

<f3>
The low-level research notebook lives in `LOW.md`.
You may be invoked on it more than once, alternating with the appellate attorney.

If `LOW.md` does not exist, this is the first pass.
Read the Research assignments to do list in `HIGH.md` and perform the listed authority searches, citation checks, and record verifications.
Create `LOW.md` and record each assignment as you start it.

If `LOW.md` already exists, the appellate attorney may have updated the plan in `HIGH.md`.
Re-read `HIGH.md`'s current Research assignments to do list and perform any new assignments.
For any assignment already in `LOW.md` that was blocked, incomplete, or produced questionable citations, debug the problem and re-check.
Append per-assignment entries to `LOW.md`.

Refine `LOW.md` in place by appending new assignment entries.
Do not delete previous research records.
</f3>

<f4>
Score the work from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real appellate merit.
Do not give credit for the work being honest about its own shortcomings.
"This argument does not work, but I am telling you it does not" is still a failing result, not a passing one.
</f4>

<f5>
Produce the low-level legal research notebook `LOW.md`.
The body of `LOW.md` records every assignment with the following per-assignment information.

- Assignment name and the matching entry in `HIGH.md`'s Research assignments to do list.
- Database, court record system, docket source, library source, or environment where the research was performed.
- Status (queued, researching, completed, blocked).
- Results, with citations, docket entries, transcript pages, record excerpts, Shepard's/KeyCite treatment, and file paths to any saved authorities or artifacts.
- Access error, citation problem, or record defect notes for any blocked assignment.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the appellate attorney asks for.
Do not change the issue, standard of review, jurisdiction, procedural posture, record sample, or success criterion on your own.
If a placeholder cite, secondary-source lead, or unverified record reference is needed only to unblock organization, mark it as preliminary in `LOW.md` so the appellate attorney knows it cannot support the main argument.
</f5>

<f6>
Produce the high-level appellate merits notebook `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line issue. The single legal or procedural bottleneck the appeal must overcome.
- Primary argument. The doctrine-level theory the brief is meant to support.
- Counterargument to rule out. The objections a strong appellee or skeptical panel would press, for example "the issue was not preserved," "the standard of review is fatal," "the record is ambiguous," or "the cited cases are distinguishable."
- Minimum convincing support. The concrete combination of binding authority, persuasive authority, record citations, and preservation facts that would make the primary argument credible to a demanding appellate panel.
- Research assignments to do. A short focused list of authority searches, record checks, and citation-verification tasks that turn the theory into an argument-to-support roadmap, not a wishlist.

When `LOW.md` already has research results, ground every new entry against those authorities, record cites, and procedural findings.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f6>

<f7>
You are working on an appellate litigation matter.
The brief is in `problem.md`, given as a natural-language statement of the case, issues, posture, and desired appellate outcome.
Read it before starting your part.
</f7>

<f8>
Believe the appellate theory in `problem.md` is right.
When a research pass comes back weak, suspect your own framing, issue selection, authority search, or record understanding first, not the theory.
Common single-point failures to look at include missed controlling cases, wrong standard of review, overlooked preservation facts, incomplete record citations, adverse authority that can be distinguished, and procedural history you misread.

Stay on the same appellate theory for at least 30 attempts before considering the route exhausted.
A typical excellent appellate lawyer pushes through 30 or more framing, research, and record variations before giving up on a direction.

Do not narrow the claim.
Narrowing in response to a weak research result (shrinking the issue, switching to an easier harmless-error point, or adding hedge caveats that concede the heart of the appeal) is a defeatist move dressed up as candor.
The right responses to a weak result are widening (testing a stronger version of the doctrine or remedy) and digging (finding the missed authority, preservation hook, or record fact that made the argument look weak).
</f8>

<f9>
When you finish, briefly report to the case manager.
Say what you did, what environment, access, filing-system, database, or system-config difficulties you hit or did not resolve.
</f9>

<f10>
The high-level merits notebook lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the legal research paralegal and the moot-court judge.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<review>` block at the end, the legal research paralegal just finished a round.
Open `LOW.md` and read the latest authority, record, citation, and procedural results.
Update `HIGH.md` to reflect the new support and risks.
Update the Research assignments to do list with the next round of work for the legal research paralegal.

If `HIGH.md` ends with a fresh `<review>` block, the moot-court judge just judged the work.
Read the review.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any moot-court judge concern unaddressed.
</f10>

<f11>
Claude responds well to clear, explicit instructions. Being specific about your desired output can help enhance results. If you want "above and beyond" behavior, explicitly request it rather than relying on the model to infer this from vague prompts.

Think of Claude as a brilliant but new employee who lacks context on your norms and workflows. The more precisely you explain what you want, the better the result.

Topology rule: Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.

- Be specific about the desired output format and constraints.
- Provide instructions as sequential steps using numbered lists or bullet points when the order or completeness of steps matters.
</f11>

Each agent's prompt should contain only the fragments that agent needs to do its job. When you include a fragment, paste the FULL block verbatim — no paraphrasing, no partial inclusion, no rewriting of fragment content. Brief connective text between fragments (e.g., "Then: ...", "Note: ...") is fine. Format: one markdown section per role, with the role name as an h1 header (e.g. `# case manager`). Output only the headered prompts, no preamble.


I need you to set up a 4-agent appellate litigation preparation pipeline.
The 4 agents are a case manager and 3 legal preparation agents (appellate attorney, legal research paralegal, moot-court judge).

The appellate attorney builds the appellate theory, interprets the record and authorities, and responds to moot-court critiques.
The appellate attorney writes the high-level merits notebook `HIGH.md`.
The body of `HIGH.md` contains the case framing, the primary appellate argument, the authorities and record support needed, and the interpretation of the latest research.

The legal research paralegal gathers authorities, checks record citations, verifies procedural facts, and flags citation or preservation problems.
The legal research paralegal writes the low-level research notebook `LOW.md`.
Each entry in `LOW.md` covers one research assignment with database or court-record notes, status, citation results, and any unresolved authority or record issues.

The moot-court judge attacks the work adversarially against the standards of a demanding appellate panel.
The moot-court judge reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The case manager orchestrates by dispatching the 3 agents in sequence.
The case manager writes no notes and reads only the moot-court judge's `<review score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment, access, filing-system, database, or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the original appellate case brief, read-only.
All three legal preparation agents read it.

`HIGH.md` is the appellate attorney's high-level merits notebook.
The appellate attorney writes the body.
The moot-court judge appends the single `<review>` block at the end.
The legal research paralegal reads `HIGH.md` to know what authorities, record cites, and procedural checks to gather.

`LOW.md` is the legal research paralegal's low-level research notebook.
The legal research paralegal writes it.
The appellate attorney reads it to know what the legal research paralegal found and what citation or preservation problems came up.
The moot-court judge does not read `LOW.md`.

I'm providing the following information:

<f1>
Score the work from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real appellate merit.
Do not give credit for the work being honest about its own shortcomings.
"This argument does not work, but I am telling you it does not" is still a failing result, not a passing one.
</f1>

<f2>
Produce the high-level appellate merits notebook `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line issue. The single legal or procedural bottleneck the appeal must overcome.
- Primary argument. The doctrine-level theory the brief is meant to support.
- Counterargument to rule out. The objections a strong appellee or skeptical panel would press, for example "the issue was not preserved," "the standard of review is fatal," "the record is ambiguous," or "the cited cases are distinguishable."
- Minimum convincing support. The concrete combination of binding authority, persuasive authority, record citations, and preservation facts that would make the primary argument credible to a demanding appellate panel.
- Research assignments to do. A short focused list of authority searches, record checks, and citation-verification tasks that turn the theory into an argument-to-support roadmap, not a wishlist.

When `LOW.md` already has research results, ground every new entry against those authorities, record cites, and procedural findings.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

<f3>
XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. `<instructions>`, `<context>`, `<input>`) reduces misinterpretation.

Best practices:
- Use consistent, descriptive tag names across your prompts.
- Nest tags when content has a natural hierarchy (documents inside `<documents>`, each inside `<document index="n">`).
</f3>

<f4>
You orchestrate a 3-agent appellate litigation preparation pipeline.
You do not develop legal theories, gather authorities, or review arguments.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `HIGH.md`.

- The first call dispatches the appellate attorney, who creates `HIGH.md` and writes the initial appellate theory and research plan there.
- After that, the main loop alternates. Whenever the appellate attorney returns, dispatch the legal research paralegal. Whenever the legal research paralegal returns, dispatch the appellate attorney again. The appellate attorney's next job is to read `LOW.md`, analyze the authorities and record results, and update the plan.
- After every 3 completed appellate attorney-legal research paralegal pairs, you dispatch the moot-court judge once. The moot-court judge call replaces the slot that would otherwise have gone to the next appellate attorney call.
- After the moot-court judge returns, read the score from the `<review score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The appellate preparation is done. If the score is less than 10, resume the main loop starting with the appellate attorney. The appellate attorney will respond to the review on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level legal research notebook `LOW.md`.
The body of `LOW.md` records every assignment with the following per-assignment information.

- Assignment name and the matching entry in `HIGH.md`'s Research assignments to do list.
- Database, court record system, docket source, library source, or environment where the research was performed.
- Status (queued, researching, completed, blocked).
- Results, with citations, docket entries, transcript pages, record excerpts, Shepard's/KeyCite treatment, and file paths to any saved authorities or artifacts.
- Access error, citation problem, or record defect notes for any blocked assignment.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the appellate attorney asks for.
Do not change the issue, standard of review, jurisdiction, procedural posture, record sample, or success criterion on your own.
If a placeholder cite, secondary-source lead, or unverified record reference is needed only to unblock organization, mark it as preliminary in `LOW.md` so the appellate attorney knows it cannot support the main argument.
</f5>

<f6>
Review `HIGH.md` adversarially with the standards of a demanding appellate panel.
You are not part of the litigation team and not their internal cite-checker.
Your job is to reject drift, weak support, and arguments larger than what the authorities and record show.

Cover four layers.

- Drift. Does the proposed appeal still attack the original issue in `problem.md`, or has it slid into a safer but different argument?
- Legal integrity. Are the cited authorities real and still good law? Are the standards of review and preservation requirements stated correctly? Are adverse cases, jurisdictional problems, or record gaps being hidden or minimized?
- Argument-support fit. For each load-bearing proposition in `HIGH.md`, mark it as supported, partial, no, or citation-invalid, with the support path as presented in `HIGH.md` (which case, statute, rule, record cite, transcript page, or docket item).
- Writing quality. Could a new appellate reader follow `HIGH.md` end-to-end and understand the theory of reversal or affirmance? Flag the parts that fail.

Be brief and specific.
Do not write the brief yourself, only review.
Honest negative is still negative.
An advocate saying "I could not find support for this" is not a partial pass.
</f6>

<f7>
The high-level merits notebook lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the legal research paralegal and the moot-court judge.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<review>` block at the end, the legal research paralegal just finished a round.
Open `LOW.md` and read the latest authority, record, citation, and procedural results.
Update `HIGH.md` to reflect the new support and risks.
Update the Research assignments to do list with the next round of work for the legal research paralegal.

If `HIGH.md` ends with a fresh `<review>` block, the moot-court judge just judged the work.
Read the review.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any moot-court judge concern unaddressed.
</f7>

<f8>
Believe the appellate theory in `problem.md` is right.
When a research pass comes back weak, suspect your own framing, issue selection, authority search, or record understanding first, not the theory.
Common single-point failures to look at include missed controlling cases, wrong standard of review, overlooked preservation facts, incomplete record citations, adverse authority that can be distinguished, and procedural history you misread.

Stay on the same appellate theory for at least 30 attempts before considering the route exhausted.
A typical excellent appellate lawyer pushes through 30 or more framing, research, and record variations before giving up on a direction.

Do not narrow the claim.
Narrowing in response to a weak research result (shrinking the issue, switching to an easier harmless-error point, or adding hedge caveats that concede the heart of the appeal) is a defeatist move dressed up as candor.
The right responses to a weak result are widening (testing a stronger version of the doctrine or remedy) and digging (finding the missed authority, preservation hook, or record fact that made the argument look weak).
</f8>

<f9>
You are working on an appellate litigation matter.
The brief is in `problem.md`, given as a natural-language statement of the case, issues, posture, and desired appellate outcome.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the case manager.
Say what you did, what environment, access, filing-system, database, or system-config difficulties you hit or did not resolve.
</f10>

<f11>
The low-level research notebook lives in `LOW.md`.
You may be invoked on it more than once, alternating with the appellate attorney.

If `LOW.md` does not exist, this is the first pass.
Read the Research assignments to do list in `HIGH.md` and perform the listed authority searches, citation checks, and record verifications.
Create `LOW.md` and record each assignment as you start it.

If `LOW.md` already exists, the appellate attorney may have updated the plan in `HIGH.md`.
Re-read `HIGH.md`'s current Research assignments to do list and perform any new assignments.
For any assignment already in `LOW.md` that was blocked, incomplete, or produced questionable citations, debug the problem and re-check.
Append per-assignment entries to `LOW.md`.

Refine `LOW.md` in place by appending new assignment entries.
Do not delete previous research records.
</f11>

Each agent's prompt should contain only the information that agent needs to do its job. For each sub-agent (case manager, appellate attorney, legal research paralegal, moot-court judge), which items should go in its prompt? Respond with a JSON object like {"case manager": ["f?"], "appellate attorney": ["f?"], "legal research paralegal": ["f?"], "moot-court judge": ["f?"]}. No other output.

I need you to set up a 4-agent appellate litigation preparation pipeline.
The 4 agents are a case manager and 3 legal preparation agents (appellate attorney, legal research paralegal, moot-court judge).

The appellate attorney builds the appellate theory, interprets the record and authorities, and responds to moot-court critiques.
The appellate attorney writes the high-level merits notebook `HIGH.md`.
The body of `HIGH.md` contains the case framing, the primary appellate argument, the authorities and record support needed, and the interpretation of the latest research.

The legal research paralegal gathers authorities, checks record citations, verifies procedural facts, and flags citation or preservation problems.
The legal research paralegal writes the low-level research notebook `LOW.md`.
Each entry in `LOW.md` covers one research assignment with database or court-record notes, status, citation results, and any unresolved authority or record issues.

The moot-court judge attacks the work adversarially against the standards of a demanding appellate panel.
The moot-court judge reads `HIGH.md` and appends a `<review score=X>` block at the end of `HIGH.md`.

The case manager orchestrates by dispatching the 3 agents in sequence.
The case manager writes no notes and reads only the moot-court judge's `<review score=X>` block when checking whether to stop.

At the end of every turn, each of the subagents reports any environment, access, filing-system, database, or system-config problems it encountered back.

The pipeline hands work off through three files.

`problem.md` is the original appellate case brief, read-only.
All three legal preparation agents read it.

`HIGH.md` is the appellate attorney's high-level merits notebook.
The appellate attorney writes the body.
The moot-court judge appends the single `<review>` block at the end.
The legal research paralegal reads `HIGH.md` to know what authorities, record cites, and procedural checks to gather.

`LOW.md` is the legal research paralegal's low-level research notebook.
The legal research paralegal writes it.
The appellate attorney reads it to know what the legal research paralegal found and what citation or preservation problems came up.
The moot-court judge does not read `LOW.md`.

I'm providing the following prompt fragments:

<f1>
Score the work from 1 to 10.
Record the verdict by overwriting the single `<review score=X>` block at the end of `HIGH.md`.
Always keep exactly one `<review>` block.
Replace it, never append a second.

Score strictly on real appellate merit.
Do not give credit for the work being honest about its own shortcomings.
"This argument does not work, but I am telling you it does not" is still a failing result, not a passing one.
</f1>

<f2>
Produce the high-level appellate merits notebook `HIGH.md`.
The body of `HIGH.md` covers the following.

- Bottom-line issue. The single legal or procedural bottleneck the appeal must overcome.
- Primary argument. The doctrine-level theory the brief is meant to support.
- Counterargument to rule out. The objections a strong appellee or skeptical panel would press, for example "the issue was not preserved," "the standard of review is fatal," "the record is ambiguous," or "the cited cases are distinguishable."
- Minimum convincing support. The concrete combination of binding authority, persuasive authority, record citations, and preservation facts that would make the primary argument credible to a demanding appellate panel.
- Research assignments to do. A short focused list of authority searches, record checks, and citation-verification tasks that turn the theory into an argument-to-support roadmap, not a wishlist.

When `LOW.md` already has research results, ground every new entry against those authorities, record cites, and procedural findings.
Keep the body tight.
Replace old conclusions with new ones rather than stacking them.
</f2>

<f3>
XML tags help Claude parse complex prompts unambiguously, especially when your prompt mixes instructions, context, examples, and variable inputs. Wrapping each type of content in its own tag (e.g. `<instructions>`, `<context>`, `<input>`) reduces misinterpretation.

Best practices:
- Use consistent, descriptive tag names across your prompts.
- Nest tags when content has a natural hierarchy (documents inside `<documents>`, each inside `<document index="n">`).
</f3>

<f4>
You orchestrate a 3-agent appellate litigation preparation pipeline.
You do not develop legal theories, gather authorities, or review arguments.
You only dispatch the right agent at the right time.
You write no files.
The only thing you read from any file is the `<review score=X>` block at the end of `HIGH.md`.

- The first call dispatches the appellate attorney, who creates `HIGH.md` and writes the initial appellate theory and research plan there.
- After that, the main loop alternates. Whenever the appellate attorney returns, dispatch the legal research paralegal. Whenever the legal research paralegal returns, dispatch the appellate attorney again. The appellate attorney's next job is to read `LOW.md`, analyze the authorities and record results, and update the plan.
- After every 3 completed appellate attorney-legal research paralegal pairs, you dispatch the moot-court judge once. The moot-court judge call replaces the slot that would otherwise have gone to the next appellate attorney call.
- After the moot-court judge returns, read the score from the `<review score=X>` block at the end of `HIGH.md`. If the score is 10, stop the pipeline. The appellate preparation is done. If the score is less than 10, resume the main loop starting with the appellate attorney. The appellate attorney will respond to the review on the next call.
- The hard cap is 20 total dispatches across the whole pipeline.
</f4>

<f5>
Produce the low-level legal research notebook `LOW.md`.
The body of `LOW.md` records every assignment with the following per-assignment information.

- Assignment name and the matching entry in `HIGH.md`'s Research assignments to do list.
- Database, court record system, docket source, library source, or environment where the research was performed.
- Status (queued, researching, completed, blocked).
- Results, with citations, docket entries, transcript pages, record excerpts, Shepard's/KeyCite treatment, and file paths to any saved authorities or artifacts.
- Access error, citation problem, or record defect notes for any blocked assignment.
- Any stuck point you cannot resolve on your own, with a clear root-cause-first description.

Implement what the appellate attorney asks for.
Do not change the issue, standard of review, jurisdiction, procedural posture, record sample, or success criterion on your own.
If a placeholder cite, secondary-source lead, or unverified record reference is needed only to unblock organization, mark it as preliminary in `LOW.md` so the appellate attorney knows it cannot support the main argument.
</f5>

<f6>
Review `HIGH.md` adversarially with the standards of a demanding appellate panel.
You are not part of the litigation team and not their internal cite-checker.
Your job is to reject drift, weak support, and arguments larger than what the authorities and record show.

Cover four layers.

- Drift. Does the proposed appeal still attack the original issue in `problem.md`, or has it slid into a safer but different argument?
- Legal integrity. Are the cited authorities real and still good law? Are the standards of review and preservation requirements stated correctly? Are adverse cases, jurisdictional problems, or record gaps being hidden or minimized?
- Argument-support fit. For each load-bearing proposition in `HIGH.md`, mark it as supported, partial, no, or citation-invalid, with the support path as presented in `HIGH.md` (which case, statute, rule, record cite, transcript page, or docket item).
- Writing quality. Could a new appellate reader follow `HIGH.md` end-to-end and understand the theory of reversal or affirmance? Flag the parts that fail.

Be brief and specific.
Do not write the brief yourself, only review.
Honest negative is still negative.
An advocate saying "I could not find support for this" is not a partial pass.
</f6>

<f7>
The high-level merits notebook lives in `HIGH.md`.
You may be invoked on it more than once, alternating with the legal research paralegal and the moot-court judge.

If `HIGH.md` does not exist, this is the first pass.
Produce it from scratch.

If `HIGH.md` already exists with no fresh `<review>` block at the end, the legal research paralegal just finished a round.
Open `LOW.md` and read the latest authority, record, citation, and procedural results.
Update `HIGH.md` to reflect the new support and risks.
Update the Research assignments to do list with the next round of work for the legal research paralegal.

If `HIGH.md` ends with a fresh `<review>` block, the moot-court judge just judged the work.
Read the review.
For each point raised, decide accept or pushback, and update `HIGH.md` accordingly.

Refine `HIGH.md` in place.
Do not discard the previous content and start over.
Do not leave any moot-court judge concern unaddressed.
</f7>

<f8>
Believe the appellate theory in `problem.md` is right.
When a research pass comes back weak, suspect your own framing, issue selection, authority search, or record understanding first, not the theory.
Common single-point failures to look at include missed controlling cases, wrong standard of review, overlooked preservation facts, incomplete record citations, adverse authority that can be distinguished, and procedural history you misread.

Stay on the same appellate theory for at least 30 attempts before considering the route exhausted.
A typical excellent appellate lawyer pushes through 30 or more framing, research, and record variations before giving up on a direction.

Do not narrow the claim.
Narrowing in response to a weak research result (shrinking the issue, switching to an easier harmless-error point, or adding hedge caveats that concede the heart of the appeal) is a defeatist move dressed up as candor.
The right responses to a weak result are widening (testing a stronger version of the doctrine or remedy) and digging (finding the missed authority, preservation hook, or record fact that made the argument look weak).
</f8>

<f9>
You are working on an appellate litigation matter.
The brief is in `problem.md`, given as a natural-language statement of the case, issues, posture, and desired appellate outcome.
Read it before starting your part.
</f9>

<f10>
When you finish, briefly report to the case manager.
Say what you did, what environment, access, filing-system, database, or system-config difficulties you hit or did not resolve.
</f10>

<f11>
The low-level research notebook lives in `LOW.md`.
You may be invoked on it more than once, alternating with the appellate attorney.

If `LOW.md` does not exist, this is the first pass.
Read the Research assignments to do list in `HIGH.md` and perform the listed authority searches, citation checks, and record verifications.
Create `LOW.md` and record each assignment as you start it.

If `LOW.md` already exists, the appellate attorney may have updated the plan in `HIGH.md`.
Re-read `HIGH.md`'s current Research assignments to do list and perform any new assignments.
For any assignment already in `LOW.md` that was blocked, incomplete, or produced questionable citations, debug the problem and re-check.
Append per-assignment entries to `LOW.md`.

Refine `LOW.md` in place by appending new assignment entries.
Do not delete previous research records.
</f11>

Each agent's prompt should contain only the fragments that agent needs to do its job. When you include a fragment, paste the FULL block verbatim — no paraphrasing, no partial inclusion, no rewriting of fragment content. Brief connective text between fragments (e.g., "Then: ...", "Note: ...") is fine. Format: one markdown section per role, with the role name as an h1 header (e.g. `# case manager`). Output only the headered prompts, no preamble.