Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="commands/santa-loop.md">

<violation number="1" location="commands/santa-loop.md:51">
P1: Reviewer B is invoked in autonomous `full-auto` mode inside the repo, which can mutate state during a step intended to be a pure independent review.</violation>

<violation number="2" location="commands/santa-loop.md:51">
P1: Reviewer B uses a predictable fixed file path in `/tmp`, creating avoidable clobber/race and prompt leakage risk for review content.</violation>

<violation number="3" location="commands/santa-loop.md:87">
P1: Santa-loop allows direct push after NICE verdicts without requiring automated checks/CI to pass, violating the team’s review gate expectations.</violation>
</file>

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@commands/santa-loop.md`:
- Around line 1-3: The Markdown file "santa-loop.md" is missing required YAML
frontmatter; add a YAML frontmatter block at the top of the file (between ---
markers) containing at minimum a descriptive "description" field (and any other
required metadata per project guidelines) so the command file is recognized as a
command; ensure the frontmatter precedes the existing content ("# Santa
Loop...") and is valid YAML.
- Around line 38-42: The code-reviewer agent's native verdict
("Approve"/"Warning"/"Block") is incompatible with the Verdict Gate and
santa_verdict() which expect PASS/FAIL per criterion aggregated into
NICE/NAUGHTY; fix by either (A) overriding the code-reviewer prompt (when
launching the agent in the santa-loop) to require structured PASS/FAIL per
rubric criterion (or explicit NICE/NAUGHTY final label) so output matches
skills/santa-method expectations, or (B) adding a small translation layer after
the code-reviewer output that maps its native labels to the expected format
(e.g., Approve -> PASS/NICE, Warning -> FAIL/NAUGHTY, Block -> FAIL/NAUGHTY)
and/or converts per-criterion approvals into PASS/FAIL before calling
santa_verdict(); update the santa-loop launch logic where the code-reviewer
agent is created and the decision path through the Verdict Gate to use the
chosen approach.

---

Nitpick comments:
In `@commands/santa-loop.md`:
- Around line 17-30: The rubric under "Step 2: Build the Rubric" duplicates the
code-reviewer agent's built-in criteria; update this section to either
explicitly reference the agent's criteria document (agents/code-reviewer.md) or
state that the rubric will be supplied as an override/supplement to the agent
prompt. Concretely, modify the "Step 2: Build the Rubric" text and the rubric
table to (a) add a single-line pointer: "Aligns with code-reviewer agent
criteria (see agents/code-reviewer.md)" OR (b) add a metadata line like
"rubric_override: true" and note that this rubric is an override to be passed to
the code-reviewer agent, and ensure the rubric rows (Correctness, Security,
Error handling, Completeness, Internal consistency, No regressions) remain
unchanged while adding that explicit reference/override.
- Line 80: Clarify and implement a concrete escalation when the santa-loop
reaches its "Maximum 3 iterations" limit: ensure the loop that enforces the cap
(santa-loop / loop controller) calls the existing escalate_to_human(output,
issues) helper from the santa-method skill when iterations are exhausted, and
define the output as a short prose summary plus a machine-readable JSON payload
of remaining issues (issues array with id, severity, reviewer, and
short_description); send the prose to stdout and write the JSON to a timestamped
file for audit, and emit a structured log entry via the same logging facility
(include action="escalate", method="santa-loop", iteration_count=3, file_path)
so tracking and downstream tooling can pick it up.
- Around line 32-34: The Step 3 description "Launch two reviewers in parallel"
is ambiguous—update the "Dual Independent Review" section to specify how to run
reviewers concurrently and ensure completion before the verdict gate: explicitly
mention example mechanisms such as using background processes and wait in a
shell script, spawning concurrent tasks or threads in an agent/orchestration
system, or using async/promises with join/wait in code; state that both reviewer
processes must be awaited/joined before proceeding to the verdict gate
(reference the Step 3 header "Dual Independent Review", the phrase "Launch two
reviewers in parallel", and the "verdict gate") so implementers know to both
start concurrently and block until both finish.
- Around line 86-88: Replace the simple git push with a safer push sequence: run
git fetch origin, check divergence with git merge-base --is-ancestor combined
with git rev-parse --abbrev-ref HEAD to ensure the remote branch is an ancestor
of your HEAD, and only then run git push; if it has diverged print an error and
exit instead of pushing, or if your workflow rebases use git push
--force-with-lease to avoid accidentally clobbering remote changes.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="commands/santa-loop.md">

<violation number="1" location="commands/santa-loop.md:83">
P2: Temp prompt file cleanup is not failure-safe; if the CLI invocation is interrupted, the file with full source contents can remain in /tmp. Add an EXIT trap to ensure cleanup even on failure.</violation>

<violation number="2" location="commands/santa-loop.md:99">
P2: Avoid passing the full review payload through `-p "$(cat ...)"`; large prompts can exceed OS argument-length limits and cause this reviewer step to fail. Use stdin or a prompt-file mechanism so large PR contexts remain supported.</violation>
</file>