subagent-system

Use this agent when verifying that a completed multi-phase pipeline satisfied its original requirements. Typical triggers include finishing all implementation phases and needing a final integrity check, reaching the mandatory chain-verifier step in the planned pipeline shape, and confirming APPROVED status before closing a pipeline. Does not receive chain history — fresh context is required. See "When to invoke" in the agent body for worked scenarios.

Use this agent when filtering false positives from batch audits that produced more than 5 findings. Typical triggers include completing parallel audit agents and needing independent finding verification, a consolidate-findings output ready for review before severity-gate, and any audit where confirmation bias from the original auditor is a concern. Does not know the original audit intent — isolation is intentional. See "When to invoke" in the agent body for worked scenarios.

Use this agent when detecting and fixing structural erosion introduced by iterative fix agents. Typical triggers include completing a batch of 3 or more fix agents, noticing growing function sizes or nesting depth across multiple edits, and preparing the codebase for pipeline-reviewer after a large fix cycle. Does not change behavior — only simplifies. See "When to invoke" in the agent body for worked scenarios.

Use this agent when checking the health of a background agent batch after it completes. Typical triggers include a batch of background agents completing with suspiciously few findings, suspecting silent tool denials in background mode, and background agents that haven't returned within expected time. Requires PROJECT_ROOT to be passed explicitly in the prompt — cannot auto-detect. See "When to invoke" in the agent body for worked scenarios.

Use this agent when reviewing implementation changes without knowing the original intent, to prevent self-review bias after each pipeline phase. Typical triggers include completing a batch of fix agents before running severity-gate, any implementation phase in the mandatory pipeline shape before chain-verifier, and when the implementing agent must not also review its own work. Distinct from code-reviewer which does general PR review. See "When to invoke" in the agent body for worked scenarios.

This skill should be used when the user asks to apply improvement proposals ('apply improvements', 'ap dung improvement proposals') from .claude/improvement-proposals.md (written by pipeline-retrospective) to the plugin files.

This skill should be used after a pipeline run completes, when the user asks to audit the pipeline output ('audit output', 'audit the run', '4-level audit'). Requires the project's test command as argument - without it Level 4 regression tests are skipped and the report is marked incomplete.

This skill should be used at the final step of any multi-phase pipeline to verify the complete working-tree state satisfies the original requirements. Trigger after all fix agents and pipeline-reviewer have completed. Also invoke when user asks to "run chain-verifier", "verify the pipeline output", or "confirm requirements are met".

This skill should be used when saving current pipeline phase state to disk and creating a recovery commit. Trigger at the end of every implementation phase, when the user asks to "save a checkpoint", "commit this phase", or before any /compact or session end. Enables resume-from-checkpoint to reconstruct pipeline state after interruption.

This skill should be used after receiving output from a subagent that was assigned an explicit numbered task list and is expected to have produced a COMPLETION_CHECKLIST block. Do not invoke if the subagent was not given a task list — there will be no checklist to parse. Uses grep counts, not LLM estimation, to detect premature termination. Also trigger when user asks to "verify completion checklist", "check if agent finished all tasks", or "detect premature termination".