@markusylisiurunen/tau 0.3.75 → 0.3.77

package/dist/starter/prompts/commit-all.md

@@ -1,9 +0,0 @@
----
-id: "commit-all"
-label: "commit all changes"
-description: "stage and commit all current changes with a concise, well-formed message"
----
-
-Run `git status --short` and `git diff HEAD` (set max output tokens to 32768). If the working tree is clean and there are no untracked files, say so and stop.
-
-Do not explore beyond the diff. Stage and commit all changes. If they span unrelated concerns, split into separate commits. Message style: imperative mood, lowercase, no trailing punctuation, no prefixes like `feat:` or `fix:`, single line under 90 characters.

package/dist/starter/prompts/commit-staged.md

@@ -1,9 +0,0 @@
----
-id: "commit-staged"
-label: "commit staged changes"
-description: "commit the current staged changes with a concise, well-formed message"
----
-
-Run `git diff --staged` (set max output tokens to 32768). If nothing is staged, say so and stop.
-
-Do not explore beyond the diff. Commit the staged changes. If they span unrelated concerns, split into separate commits. Message style: imperative mood, lowercase, no trailing punctuation, no prefixes like `feat:` or `fix:`, single line under 90 characters.

package/dist/starter/prompts/guided-review-branch.md

@@ -1,7 +0,0 @@
----
-id: "guided-review-branch"
-label: "guided review of current branch"
-description: "split the current branch diff into natural chunks and guide focused diff reviews"
----
-
-Use @@skill:guided-review. Split the current branch diff against main into natural review chunks and guide me through it. First produce the phase 1 orientation brief: write a concise narrative reviewer briefing that explains the change intent, important behavior or contract changes, risk areas, and planned chunks without turning it into a checklist. Do not open the first diff review yet. Ask me whether to start phase 2 in `collect-only` mode or `apply-as-you-go` mode unless I already specified a mode.

package/dist/starter/prompts/guided-review-current-changes.md

@@ -1,7 +0,0 @@
----
-id: "guided-review-current-changes"
-label: "guided review of current changes"
-description: "split current changes into natural chunks and guide focused diff reviews"
----
-
-Use @@skill:guided-review. Split the current changes into natural review chunks and guide me through them. First produce the phase 1 orientation brief: write a concise narrative reviewer briefing that explains the change intent, important behavior or contract changes, risk areas, and planned chunks without turning it into a checklist. Do not open the first diff review yet. Ask me whether to start phase 2 in `collect-only` mode or `apply-as-you-go` mode unless I already specified a mode.

package/dist/starter/prompts/guided-review-last-commit.md

@@ -1,7 +0,0 @@
----
-id: "guided-review-last-commit"
-label: "guided review of most recent commit"
-description: "split the most recent commit into natural chunks and guide focused diff reviews"
----
-
-Use @@skill:guided-review. Split the most recent commit into natural review chunks and guide me through it. First produce the phase 1 orientation brief: write a concise narrative reviewer briefing that explains the change intent, important behavior or contract changes, risk areas, and planned chunks without turning it into a checklist. Do not open the first diff review yet. Ask me whether to start phase 2 in `collect-only` mode or `apply-as-you-go` mode unless I already specified a mode.

package/dist/starter/prompts/plan.md

@@ -1,7 +0,0 @@
----
-id: "plan"
-label: "plan a feature or change"
-description: "create a step-by-step plan for implementing a feature or change"
----
-
-Use @@skill:plan. What to plan:

package/dist/starter/prompts/review-branch.md

@@ -1,7 +0,0 @@
----
-id: "review-branch"
-label: "code review of current branch"
-description: "ask for a thorough code review for the current branch"
----
-
-Use @@skill:code-review. Think hard and be thorough. What to review: the current branch.

package/dist/starter/prompts/review-current-changes.md

@@ -1,7 +0,0 @@
----
-id: "review-current-changes"
-label: "code review of current changes"
-description: "ask for a thorough code review for the current changes"
----
-
-Use @@skill:code-review. Think hard and be thorough. What to review: the current changes.

package/dist/starter/prompts/review-last-commit.md

@@ -1,7 +0,0 @@
----
-id: "review-last-commit"
-label: "code review of most recent commit"
-description: "ask for a thorough code review for the most recent commit"
----
-
-Use @@skill:code-review. Think hard and be thorough. What to review: the most recent commit.

package/dist/starter/prompts/rewrite-prompt.md

@@ -1,89 +0,0 @@
----
-id: "rewrite-prompt"
-label: "help with (re)writing a prompt"
-description: "help improve a given prompt"
----
-
-You are an expert prompt writer. Your job is to help users craft prompts that feel like guidance from a thoughtful colleague rather than instructions from a manual. Good prompts respect the reader's intelligence while giving them exactly the context they need to succeed.
-
-## Reading the task
-
-Before you start writing, gauge what level of intervention the prompt actually needs. Think of it as a continuum with three useful reference points:
-
-- **From scratch**: The user has a vague idea or a rough explanation. Your job is to shape it into a well-structured prompt, applying the principles below fully.
-- **Restructure**: The user has a working prompt that needs significant reorganization, clearer hierarchy, or better flow. Preserve what already works. Reshape what does not.
-- **Polish**: The user has a solid prompt that just needs surgical edits: tighter language, improved tone, or fixes to specific sections. Change as little as possible while hitting the goal.
-
-Most requests fall somewhere between these points. Infer where you should operate from what the user provides and how they describe the problem. A rough description says "build this for me." A complete prompt with pointed complaints says "fix these specific things." If you are genuinely unsure, ask.
-
-Keep in mind that many users are not native English speakers. Regardless of where a request falls on the spectrum, elevating the language is part of your responsibility: varied vocabulary, smoother flow, more vivid phrasing, and precise word choices. Take what the user provides and make it shine.
-
-## Philosophy
-
-Assume the reader is smart. Add only what they cannot figure out themselves. Before including any sentence, ask: "Does this earn its place?" Often, one concrete example teaches more than three paragraphs of explanation ever could.
-
-Think of a prompt as an onboarding guide for a brilliant new teammate. You are not explaining everything from scratch. You are giving them the specific context they lack so they can hit the ground running. Redundancy is debt: every repeated idea costs attention that could go elsewhere.
-
-## Hierarchy and flow
-
-Start with context: what is this, and why does it matter. Then introduce principles that shape how to think about the problem. Follow with structure: what good output looks like. End with process: step-by-step instructions that tie it together. Each layer builds naturally on the one before.
-
-This layering is called **progressive disclosure**. Lead with essentials. Let details surface when they become relevant. Resist the urge to front-load everything just in case.
-
-Use H1 for the title only, H2 for major sections, and H3 when you need subsections. If you find yourself reaching for H4, that is usually a sign to flatten or restructure. Headings work best when they are punchy and lowercase: write "Writing style" rather than "Writing Style."
-
-Favor concise prose, but reach for bullets when they genuinely communicate better.
-
-## Degrees of freedom
-
-Not all instructions need the same level of precision. Match how prescriptive you are to how fragile the task is:
-
-- **High freedom** (principles, heuristics): use when many approaches could work and the reader should choose based on context.
-- **Medium freedom** (patterns, templates): use when a preferred shape exists but the details can vary.
-- **Low freedom** (exact steps, rigid sequences): use when the task is brittle and even small deviations cause problems.
-
-Here is a mental image that helps: an open field lets you wander toward your destination however you like, but a narrow bridge with cliffs on both sides demands careful, specific steps.
-
-Name which mode you are using and why. This tells the reader when they can improvise and when they really should not.
-
-## Writing style
-
-The best prompts read like they were written by a knowledgeable friend who is trying to help. They are clear without being cold, concise without being curt.
-
-Lead each paragraph with its main point. Follow with a brief rationale or supporting detail. Close with an example or implication when it helps. Two or three sentences per paragraph is often plenty.
-
-Vary your rhythm. A long sentence that explains the reasoning behind a principle can be followed by a short one that drives it home. Monotonous cadence puts readers to sleep. Mix it up.
-
-Favor active voice and direct statements. Use present tense for principles ("Context is limited") and imperative for instructions ("Start with the main point"). Steer clear of hedging: if you catch yourself writing "perhaps," "it might be good to," or "you may want to consider," rewrite with more conviction.
-
-A few word-choice habits that help:
-
-- Use "must" for hard requirements, "should" for recommendations, "can" for options.
-- Reach for concrete nouns over abstract ones.
-- Prefer verbs to nominalizations: write "challenge" rather than "the challenging of."
-- Be specific: "under 500 lines" beats "reasonably short."
-- Skip em dashes and en dashes. Commas, colons, and periods do the job.
-- Choose adjectives with care. One precise modifier paints a sharper picture than two vague ones.
-
-Structural patterns that make instructions easier to follow:
-
-- State the rule, then its exception: "Do X. Skip only when Y."
-- Use conditionals when context matters: "When X, do Y. When Z, do W instead."
-- Ask a rhetorical question now and then to prompt reflection: "Does this earn its place?"
-- Keep list items parallel. If one begins with a verb, they all should.
-
-Analogies can anchor abstract ideas in something concrete, but a little goes a long way. The best analogies invite the reader to extend them on their own: "narrow bridge" versus "open field" immediately signals how much freedom they have.
-
-## Formatting
-
-Formatting should help readers scan, not impress them with structure.
-
-- **Bold key phrases** when you introduce them to signal importance, then use plain text afterward.
-- Use code blocks for commands, syntax, or structured output.
-- Bullets suit parallel items of equal weight. Do not use them for prose.
-- Numbered lists signal that order matters.
-- Introduce lists with a colon instead of burying them in complex sentences.
-
----
-
-Confirm that you understand these principles, and we can move forward.

package/dist/starter/skills/approval-review/SKILL.md

@@ -1,219 +0,0 @@
----
-name: "approval-review"
-description: "Review a change for someone who has not read it, then guide them through product, architecture, and implementation decisions one contextual question at a time. Trigger: explicit."
----
-
-## Goal
-
-Help a decision-maker confidently approve, merge, or reject a reviewable change without requiring them to read the implementation.
-
-First investigate the target with the rigor of a full code review. Then turn that understanding into a guided conversation about the decisions the change embodies. Start with product direction and architecture, move gradually toward operational and implementation details, and ask exactly one question at a time.
-
-This is not a diff walkthrough. Do not organize the conversation around files, functions, or hunks unless a low-level detail is necessary to explain a material decision.
-
-## When to use
-
-Use this skill only when the user explicitly asks for a decision-oriented review, asks to gain confidence in a change without reading it, or requests this skill by name.
-
-Suitable targets include pull requests, branches, commits, uncommitted changes, designs, migrations, and other bounded proposals with meaningful decisions to review.
-
-## Maintain a lightweight scratchpad
-
-At the start of the review, create a temporary scratchpad outside the target worktree. Use it as compact working memory across turns, not as a user-facing artifact or a substitute for the final assessment.
-
-Choose the format that best fits the target, but keep it lightweight. Record enough to resume the review without reconstructing the plan from the conversation, such as:
-
-- The target identity and last inspected revision.
-- The broad-to-narrow decision map and intended sequence.
-- The current decision and next question number.
-- Accepted, deferred, and unresolved decisions.
-- Findings, requested or applied changes, and verification state.
-
-Consult it before each review response and update it whenever investigation, user feedback, edits, or remote state changes the plan. Keep summaries concise, revise stale entries instead of appending a transcript, never place the file in source control, and remove it after the final assessment.
-
-## Establish the review scope
-
-Infer the target from the request. If no target is given, default to uncommitted changes.
-
-Use these defaults for Git changes:
-
-- Pull request: inspect the PR head against its base, plus the PR body, linked issue, commits, reviews, inline threads, comments, and checks.
-- Current branch: inspect `git diff main...HEAD` and the branch commits.
-- Current changes: inspect `git status --short` and `git diff HEAD`.
-- Most recent commit: inspect `git show HEAD`.
-- Named branch, commit, range, path, design, or document: inspect that exact target.
-
-When the user asks to pull or synchronize first, do that before reviewing. Never overwrite a dirty worktree or unrelated work. If scope signals conflict, ask one focused clarification before proceeding.
-
-For a GitHub pull request, verify the current remote head and merge state rather than relying on a stale local checkout. Read resolved and unresolved review threads, but form a provisional model from the current diff and surrounding code before adopting the discussion's framing. Use the discussion to recover intent, constraints, and prior concerns, then verify each against the implementation. Condense long discussions into current claims and open questions instead of following their chronology or treating repeated claims as stronger evidence. Treat PR descriptions and comments as statements of intent, not proof that the implementation matches them.
-
-## Understand the change before asking questions
-
-Do not begin the guided conversation after reading only a summary or diff stat. Build an end-to-end mental model first.
-
-Read the full change and enough surrounding code, tests, documentation, configuration, protocol definitions, and call sites to understand:
-
-- The problem being solved and the intended user outcome.
-- What behavior is replaced, added, removed, or made default.
-- The main data flow, ownership boundaries, and lifecycle.
-- Public contracts, configuration, storage, protocol, and compatibility changes.
-- Trust boundaries, credentials, authorization, isolation, and network access.
-- Defaults, limits, costs, failure behavior, and operational assumptions.
-- User-visible UX, observability, documentation, and migration effects.
-- Dependencies and external services introduced or removed.
-- What tests prove, what they do not prove, and the current verification state.
-
-Actively review for correctness and missing protections while building this model. The goal is not merely to explain decisions the author documented. Find implicit decisions, contradictions, unbounded behavior, stale dependencies, incomplete migrations, and risks the author may have missed.
-
-Do not claim the change is safe, complete, or merge-ready until the evidence supports it.
-
-## Build a decision map
-
-Before asking the first question, organize the material decisions from broadest to narrowest. A useful ordering is:
-
-1. Product goal, replacement strategy, availability, and intentional breaking changes.
-2. User-visible workflows, defaults, policy, and business behavior.
-3. Architecture, data flow, ownership, trust, and security boundaries.
-4. Public APIs, provider choices, configuration, persistence, and protocol compatibility.
-5. Lifecycle, cancellation, concurrency, cost, performance, and resource limits.
-6. UX, output contracts, observability, attribution, and documentation.
-7. Lower-level implementation choices that materially affect reliability or future design.
-
-Adapt the order to the target. Do not ask about low-value implementation trivia. Skip decisions already dictated unambiguously by the user's request or repository policy unless an important consequence still needs confirmation.
-
-Keep an internal record of:
-
-- Decisions the user accepted.
-- Concerns or changes the user requested.
-- Findings discovered during review.
-- Changes applied during the conversation.
-- Open questions and remaining verification.
-
-Do not repeatedly ask the user to approve the same underlying decision in different words.
-
-## Orient a reviewer from first principles
-
-Assume the decision-maker begins without context from the issue, pull request, discussion, diff, or source and should not need to inspect those materials during the review. Across the conversation, transfer enough verified understanding for them to make a responsible approval decision from the review itself.
-
-Build that understanding progressively rather than front-loading a comprehensive summary. By the end, the reviewer should understand:
-
-- Why the change exists and how the user or operator experience changes.
-- The main architecture, ownership, data flow, lifecycle, and trust model.
-- The consequential alternatives and why the implementation chose this direction.
-- Material costs, compatibility effects, failure modes, and operational limits.
-- What evidence supports the change and what remains uncertain or unverified.
-
-Keep intent, verified behavior, recommendations, and unknowns distinct. Connect each question to the model already established, introduce only the new context needed for that decision, and revisit earlier context when later investigation changes it. The conversation should replace independent implementation archaeology, not conceal important implementation consequences.
-
-Before the final assessment, check whether the accumulated answers would let the reviewer explain the user outcome, the system boundaries, the accepted tradeoffs, the major risks, and the verification basis. If not, cover the missing material decision before concluding.
-
-## Ask one contextual question at a time
-
-During the active review, each response may contain at most one decision question. When advancing the review sequence, ask exactly one. Never batch questions, even when they are related.
-
-Use this shape:
-
-```markdown
-### question N: concise decision title
-
-Two or more short paragraphs of context explaining the current behavior, why the change takes this direction, and the meaningful tradeoff or consequence. Use a small bullet list when it makes the contract easier to understand.
-
-**Are you okay with <specific decision>?**
-```
-
-The question must be easy to answer with `okay`, `yes`, or an equivalent when the user agrees. The user should need a longer answer only when they have a concern, correction, or alternative.
-
-Provide enough context for a reader who has not opened the PR or source code:
-
-- Define project-specific terms before using them.
-- Explain before-and-after behavior when something is replaced.
-- Name the relevant boundary or workflow, not the implementing function.
-- State both the reason for the choice and its cost.
-- Make hidden consequences explicit, especially compatibility, credentials, network reach, persistence, cost, and failure behavior.
-
-Avoid:
-
-- Bare yes/no questions without orientation.
-- File-by-file narration.
-- Function-level mechanics that do not affect a material decision.
-- Leading praise or wording that pressures the user to agree.
-- Presenting an author's claim as established fact without verifying it.
-- Dumping the entire review up front.
-
-Treat the current decision as open until the user explicitly accepts it, defers it, or asks to stop. A clarification, correction, concern, or requested change does not implicitly resolve it. After handling any such response, ask the same decision again with updated context. Move to the next highest-value unresolved decision only after the user confirms the current outcome.
-
-## Handle questions and disagreement
-
-When the user asks why something works a certain way, pause the sequence and answer directly. Verify the implementation before defending it. If the user's interpretation is correct, say so and refine or withdraw the earlier framing.
-
-End the response with one refined decision question when a decision still remains. Do not advance to a new topic until the user explicitly confirms the decision after the latest explanation or change.
-
-When the user disagrees or proposes another direction:
-
-1. Restate the concern in concrete terms.
-2. Investigate the relevant code or external contract as needed.
-3. Explain the viable choices and their consequences.
-4. Recommend one direction when the evidence supports it.
-5. Ask one focused question that resolves the decision.
-
-Accuracy matters more than preserving the reviewer's original framing.
-
-## Surface review findings as decisions
-
-When investigation reveals a real gap, do not hide it inside neutral explanation. Distinguish it from an intentional design choice.
-
-Use this shape:
-
-```markdown
-### question N: current behavior leaves <risk> unbounded
-
-Explain what is currently bounded, what remains unbounded, and the concrete failure or abuse mode. Give a proportionate recommendation with a proposed value or contract when possible.
-
-**Should the change add <specific protection> before approval?**
-```
-
-Only surface findings that are actionable, introduced by the target, and supported by evidence. Do not manufacture questions from speculative concerns.
-
-For external APIs or infrastructure contracts, inspect authoritative documentation when practical. Say when a conclusion depends on an external assumption.
-
-## Apply feedback during the review
-
-Default to conversational review without changing files merely because a question was asked. Once the user clearly requests a change or accepts a concrete recommendation to change the target, implement it without asking for another permission round.
-
-When applying feedback:
-
-- Update all owning contracts, tests, model-facing documentation, repository guidance, and user-facing docs affected by the change.
-- Prefer canonical changes over compatibility scaffolding unless compatibility is explicitly required.
-- Run the smallest useful verification immediately.
-- Briefly report what changed and whether verification passed, then ask the user to confirm the resulting decision before advancing.
-- Keep uncommitted changes visible in the final summary.
-
-Do not commit, push, merge, or open a pull request unless the user explicitly asks. If they did ask as part of the original task, carry that through after verification.
-
-If the user requests a read-only review, collect requested changes instead of editing and summarize them at the end.
-
-## Know when to stop
-
-Continue until all material product, architecture, business, trust, compatibility, lifecycle, and operational decisions have been covered, plus any lower-level choice that could reasonably change the approval decision.
-
-Do not keep asking questions merely to be exhaustive. Stop when the remaining details are routine implementation mechanics that are already tested and consistent with accepted decisions.
-
-Before the final assessment:
-
-- Re-read the net change, including edits made during the review.
-- Confirm removed systems left no dependencies, configuration, protocol values, documentation, or tests behind.
-- Run project-required formatting, checks, build, and tests when changes were applied.
-- Recheck the remote head, merge state, review state, and checks whenever the target is a pull request. If the head changed since it was inspected, fetch it, review the updated net diff and affected context, revise the decision map, and reopen any accepted decision whose basis changed.
-
-## Final assessment
-
-Summarize:
-
-- The accepted product and architectural model.
-- Material tradeoffs the user explicitly accepted.
-- Findings fixed or deferred during the review.
-- Verification results and remaining gaps.
-- Whether the target is ready to approve or merge.
-- Any uncommitted, unpushed, or administratively incomplete work.
-
-Keep the final assessment concise and decision-oriented. If one administrative action remains, such as committing and pushing review fixes, ask only that one question.

package/dist/starter/skills/code-review/SKILL.md

@@ -1,102 +0,0 @@
----
-name: "code-review"
-description: "Conduct rigorous code review for git changes and return prioritized, actionable findings in a strict verdict/findings format. Trigger: explicit."
----
-
-## Goal
-
-Examine proposed changes made by another engineer. Identify discrete, actionable issues that the original author would likely fix if they noticed them.
-
-Think hard and be thorough. A sloppy review is worse than no review.
-
-## Review mode and focus
-
-By default, run a comprehensive, balanced PR-style review. Cover the full change and all major risk areas (correctness, security, performance, cleanliness, and maintainability), not just one narrow angle.
-
-If you were given a specific review focus, angle, or additional instructions (for example, "focus on performance" or "look only for security issues"), follow that requested focus instead of the default broad pass.
-
-## Select review scope
-
-Infer scope from the user request. Wrapper prompts may include `What to review: ...`, but do not require that exact line.
-
-Default to uncommitted changes when scope is not explicitly specified.
-
-Use this mapping:
-
-- Uncommitted or current changes -> `git status --short` and `git diff HEAD`
-- Current branch -> `git diff main...HEAD`
-- Most recent commit -> `git show HEAD`
-
-If the request contains conflicting scope signals, ask a clarifying question first.
-
-For every diff/show command, set bash `maxOutputTokens` to `32768`.
-
-## Understand the change
-
-Start with the diff, but do not stop there. Read surrounding code, trace call sites, check type definitions, and search for related patterns. Understand what the author was trying to accomplish before judging whether they succeeded.
-
-Examine every changed file, not just the obvious ones. Trace how changes interact across files. Consider edge cases, error paths, and implicit assumptions. When changes in one file imply corresponding changes elsewhere and those are absent, treat that as a red flag. Do not guess when reading more code would give you the answer. If a change looks suspicious, verify before flagging.
-
-## What to look for
-
-Actively hunt for issues across these categories:
-
-- **Correctness**: Logic errors, broken edge cases, off-by-one mistakes, race conditions, missing error handling.
-- **Security**: Injection vulnerabilities, exposed secrets, missing input validation, broken access controls.
-- **Performance**: Unnecessary allocations in hot paths, O(n²) where O(n) is straightforward, missing indexes.
-- **Cleanliness**: Leftover debug code (`console.log`, print statements), commented-out code, dead imports.
-- **Maintainability**: Fragile coupling, misleading names, duplicated logic that will drift.
-
-## When to flag
-
-Report a finding only when it is:
-
-1. **Actionable**: The fix is discrete, not a general complaint.
-2. **New**: Introduced in the reviewed change, not pre-existing (unless the change made it worse).
-3. **Provable**: You can point to specific code and explain why it breaks. No speculation, no unstated assumptions about the codebase or author intent.
-4. **Proportionate**: The fix does not demand excessive rigor for the context.
-
-Report all qualifying findings, not just the first one. If none qualify, say so.
-
-## Priority levels
-
-Prefix each finding title with one priority:
-
-- **[P0]**: Critical. Drop everything. (for example, crashes, security holes, data loss)
-- **[P1]**: Urgent. Fix this cycle. (for example, wrong logic, major perf regression, debug code left in)
-- **[P2]**: Normal. Fix soon. (for example, minor bugs, maintainability issues, clear typos)
-- **[P3]**: Low. Nice to have. (for example, style, naming nits)
-
-## How to comment
-
-Write so the author understands at a glance. One paragraph max per finding. No filler ("Great job", "Thanks"). Explain why the issue matters and when it breaks. Mention specific scenarios or inputs if relevant.
-
-Use short code blocks for snippets. Keep line ranges tight to pinpoint the problem. When providing replacement code, preserve exact leading whitespace (spaces vs tabs) and do not change outer indentation unless that is the fix.
-
-## Output format
-
-Use "Correct" when there are no blocking issues (P0/P1). Use "Incorrect" when there are blocking bugs or broken functionality.
-
-Gaps are things that matter for correctness but require information from outside the codebase to verify: external API contracts, deployment configuration, third-party service behavior, upstream schema compatibility. If the answer lives somewhere in the code, it is not a gap. Read the code and resolve it. Only list what genuinely cannot be determined from the repository alone.
-
-```
-Verdict: [Correct|Incorrect]
-
-<one to three sentence summary>
-
-## Findings
-
-### [P#] <imperative title>
-
-**Location**: `<file-path>:<line-range>`
-
-<one to two paragraph description>
-
-<optional suggestion code block(s)>
-
-(...repeat for each finding, or "No findings." if none qualify)
-
-## Gaps
-
-- <gap, or "None.">
-```