ideal-agentic-workflow 1.0.0

package/skills/s4-plan-review/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: "S4 Plan Review"
+description: "Executes the critical quality gate, spawning specialized subagents to evaluate the implementation plan against architectural constraints and audit findings."
+---
+
+# S4 Plan Review
+
+## 1. Introduction and Purpose
+This document defines the strict execution protocol for the S4 Plan Review phase within the `ideal-agentic-workflow` plugin. 
+The S4 phase acts as the primary defense mechanism against flawed logic, preventing poorly conceived implementation plans from reaching the coding stage. 
+The orchestrating agent MUST execute the protocols defined below to guarantee that autonomous plan-critic subagents thoroughly evaluate the proposed architecture.
+Skipping this phase in Standard or Duolithic modes violates the core invariant that all generated plans MUST be peer-reviewed before execution.
+This rigorous review cycle mimics the human pull request process, ensuring that multiple expert personas validate the strategy against project constraints.
+The orchestrating agent MUST prepare the exact inputs required by the subagents and handle the resulting feedback deterministically.
+Failure to properly orchestrate this review will result in the deployment of brittle, non-compliant code that degrades the repository's health.
+The S4 phase explicitly determines whether the workflow advances to coding or loops back to planning for necessary revisions.
+
+## 2. Modal Execution Protocols
+The exact behavior of the S4 phase is strictly governed by the operating mode established during the S1 Orchestration phase. 
+The agent MUST evaluate the current mode from the `.agents/session-[SHA]/mode.txt` file (or its internal state) and execute the corresponding protocol branch.
+Applying the wrong protocol wastes time spawning unnecessary subagents or dangerously bypasses the review for complex, high-risk changes.
+The Fast Mode and Trivial Protocol explicitly trust the developer's initial scoping and skip this phase entirely to maximize execution speed.
+Conversely, the Standard and Duolithic modes mandate a rigorous, multi-agent review process to guarantee architectural safety.
+The agent MUST strictly adhere to the mutually exclusive branches of logic defined below based on the active session mode.
+The agent MUST NOT attempt to blend these instructions; a session is either fully reviewed or explicitly bypassed based on the mode.
+If the operating mode is unclear, the agent MUST default to the Standard mode protocol to guarantee that safety is never compromised.
+
+### 2.1 Fast and Trivial Mode Bypass
+When the session is explicitly marked as `/fast mode` or `/trivial`, the agent MUST completely bypass the entire S4 Plan Review phase. 
+These modes are designed for low-risk, tightly scoped changes where the developer's initial direction does not require secondary validation.
+Spawning plan-critic subagents for a trivial documentation fix or a single-line bug patch constitutes a massive waste of AI quota and wall-clock time.
+The agent MUST NOT prepare a `submit(n).md` file or spawn any reviewers under these specific protocols.
+The agent MUST immediately advance the workflow directly to the S6 Coding phase, trusting the inline plan generated during S3.
+
+### 2.2 Standard Mode Protocol
+When operating in Standard Mode, the agent MUST execute the native, multi-agent review process within the current conversation context. 
+This protocol guarantees that the proposed plan is scrutinized by objective subagents dedicated solely to architectural compliance.
+The agent MUST prepare the `.agents/session-[SHA]/code-review/submit/submit(n).md` file containing the `plan.md` contents and the `plan-review-guide.md` instructions.
+The agent MUST spawn exactly two (2) plan-reviewer subagents utilizing the `plan-critic.md` persona defined in the persona bank.
+The agent MUST wait for both subagents to generate their respective `.agents/session-[SHA]/code-review/review/review(n).md` output files before proceeding to evaluation.
+
+### 2.3 Duolithic Mode Protocol
+When operating in Duolithic Mode, the orchestrating M-Agent MUST delegate the entire review process to the R-Agent operating in a parallel conversation. 
+This protocol balances the superior reasoning capabilities of the primary model against the higher quota limits required for parallel subagent spawning.
+The M-Agent MUST NOT spawn any plan-critic subagents directly within its own execution context.
+The M-Agent MUST generate the specific handoff prompt defined below, present it to the user, and explicitly pause its own execution until the R-Agent completes the task.
+The M-Agent MUST execute the following exact sequence to guarantee a seamless transition across the dual-conversation architecture.
+- **Prompt Generation**: The M-Agent MUST generate the exact R-Agent Onboarding Prompt template defined in PRD Section 4.4.
+- **Context Injection**: The M-Agent MUST insert the precise string: `"Read plan.md at [PATH]. Spawn 3 plan-reviewer subagents."` into the `[TASK-SPECIFIC CONTEXT]` block of the prompt.
+- **Explicit Pause**: The M-Agent MUST explicitly halt execution and instruct the user to paste the prompt into the R-Agent conversation.
+- **Completion Signal**: The M-Agent MUST strictly wait for the user to return the exact completion signal: `RAGENT_DONE: [OUTPUT_FILE_PATH]` before resuming operations and reading the generated review files.
+
+## 3. Transition Logic and Evaluation
+Regardless of whether the reviews were generated via Standard Mode or Duolithic Mode, the orchestrating agent MUST rigorously evaluate the final `review(n).md` outputs. 
+This evaluation determines the immediate next step in the workflow lifecycle, enforcing the rule that unapproved plans cannot proceed to execution.
+The agent MUST read the conclusions of all spawned plan-critics and aggregate their final verdicts.
+If the reviewers reach a consensus, the agent MUST advance the workflow; if a single reviewer objects, the plan MUST be revised.
+The agent MUST strictly follow the transition logic defined below based on the aggregated review status.
+Failure to enforce this logic breaks the fundamental invariant of the agentic engineering process.
+This explicit transition gate prevents subjective interpretation of the review results.
+The agent MUST execute one of the following two transition pathways.
+
+### 3.1 Approval Transition (S6 Code One Task)
+If all plan-reviewer subagents explicitly approve the implementation plan without requesting mandatory changes, the plan is considered verified. 
+The orchestrating agent MUST mark the S4 phase as complete and immediately transition the workflow to the S6 Coding phase.
+The agent MUST select the first incomplete task from the `task.md` file and begin generating production code.
+The agent MUST ensure the `task.md` file is accurately updated as the coding phase commences.
+The agent MUST NOT modify the approved `plan.md` file after this transition occurs.
+
+### 3.2 Rejection Transition (S5 Plan Fix)
+If any single plan-reviewer subagent requests changes or rejects the proposed architecture, the plan is considered flawed. 
+The orchestrating agent MUST explicitly transition the workflow to the S5 Plan Fix phase to remediate the identified issues.
+The agent MUST read the specific criticisms from the `review(n).md` files, revise the `plan.md` and `task.md` artifacts accordingly, and loop back to the beginning of S4 to request a fresh review cycle.
+This cyclical process MUST continue indefinitely until all architectural concerns are fully resolved.
+The agent MUST NOT proceed to S6 until a flawless approval is secured from all designated reviewers.

package/skills/s4-plan-review/resources/plan-review-guide.md

@@ -0,0 +1,51 @@
+# Plan Review Guide
+
+## 1. Introduction and Purpose
+This document defines the strict criteria that all plan-reviewer subagents MUST utilize when evaluating an implementation plan during the S4 phase. 
+The plan review acts as an impenetrable quality gate, preventing poorly scoped or architecturally unsound logic from reaching the coding phase. 
+Without this explicit set of evaluation criteria, reviewers risk rubber-stamping the orchestrator's output without conducting a meaningful analysis.
+By enforcing these specific checks, the `ideal-agentic-workflow` plugin guarantees that every proposed code change aligns with the project's long-term health.
+Every plan-reviewer MUST cross-reference the proposed `plan.md` against the rules defined below.
+The reviewer MUST issue a rejection if the plan violates any single criterion in this document.
+Compromising on these checks inevitably leads to regressions, performance bottlenecks, and mounting technical debt.
+Reviewers MUST NOT rely on intuition; they MUST trace every proposed change back to the foundational architecture constraints.
+
+## 2. Core Review Dimensions
+The review process is divided into three non-negotiable dimensions that the critic MUST analyze simultaneously. 
+The reviewer MUST verify that the proposed logic does not violate the established stack pack rules for the repository.
+The reviewer MUST guarantee that the plan adequately addresses the critical findings identified in the previous S2 audit phase.
+The reviewer MUST scan the proposed implementation steps for known anti-patterns documented in the project's registry.
+Failing to examine all three dimensions guarantees that critical flaws will slip into the production codebase.
+Each dimension carries equal weight in the evaluation process.
+A failure in any single dimension constitutes an automatic rejection of the entire implementation plan.
+The reviewer MUST evaluate the plan against the exact criteria outlined below.
+
+### 2.1 Stack Pack Adherence
+The plan-reviewer MUST evaluate every proposed change against the specific architecture rules defined in the active stack packs (e.g., `web-nextjs-turborepo.md`). 
+The reviewer MUST ensure that the plan does not propose patterns explicitly forbidden by the chosen framework.
+If the plan introduces a direct conflict with the stack's defined best practices, the reviewer MUST reject it immediately.
+The reviewer MUST explicitly cite the violated stack pack rule in their `review(n).md` output to provide actionable feedback.
+The reviewer MUST examine the following architectural boundaries.
+- **Routing and File Structure**: Verify that the plan places files in the correct framework directories (e.g., Next.js App Router vs. Pages Router).
+- **State Management**: Verify that the plan proposes the correct state management paradigm defined for the project (e.g., Server Components vs. Client Components).
+- **Data Access Patterns**: Verify that database interactions conform to the designated ORM or query builder rules.
+
+### 2.2 Audit Report Coverage
+The plan-reviewer MUST read the `.agents/session-[SHA]/audit/audit.md` file and verify that the proposed plan addresses the high-priority vulnerabilities identified within it. 
+A plan that focuses exclusively on new features while ignoring critical security warnings from the audit MUST be rejected.
+The reviewer MUST trace the tasks in the plan back to the specific audit findings to guarantee complete coverage.
+If a critical audit finding is deliberately deferred, the reviewer MUST verify that the plan includes a valid, documented justification for the delay.
+The reviewer MUST assess the following coverage metrics.
+- **Security Mitigation**: Verify that the plan proposes explicit fixes for any active vulnerabilities flagged during S2.
+- **Performance Remediation**: Verify that the plan addresses severe performance bottlenecks or memory leaks identified by the auditors.
+- **Technical Debt Reduction**: Verify that the plan allocates time to refactor deprecated API usage or convoluted logic flows.
+
+### 2.3 Anti-Pattern Prevention
+The plan-reviewer MUST analyze the proposed logic flow to intercept any known anti-patterns before they manifest as code. 
+The reviewer MUST cross-reference the plan against the project's central anti-pattern registry located in the resources directory.
+If the plan suggests a brittle implementation, such as hardcoding environment variables or writing monolithic functions, the reviewer MUST reject it.
+The reviewer MUST mandate that the plan adopts defensive programming practices and robust error handling mechanisms.
+The reviewer MUST actively hunt for the following conceptual flaws.
+- **Simulation Code**: Verify that the plan strictly prohibits the generation of mock data, placeholders, or non-production simulation logic.
+- **Verbose Comments**: Verify that the plan does not encourage writing excessive, narrative comments inside the source files.
+- **Compiler Appeasement**: Verify that the plan does not propose suppressing warnings or bypassing type safety solely to force a successful build.

package/skills/s6-coding/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: "S6 Coding"
+description: "Executes the core code generation phase, strictly enforcing senior developer standards, stack architecture rules, and anti-pattern prevention."
+---
+
+# S6 Coding
+
+## 1. Introduction and Purpose
+This document defines the strict execution protocol for the S6 Coding phase within the `ideal-agentic-workflow` plugin. 
+The S6 phase is the critical execution engine where the theoretically sound plans from S4 are transformed into functional, production-ready software. 
+The orchestrating agent MUST execute the protocols defined below to guarantee that code is generated with a disciplined, senior-developer mindset rather than rapid, sloppy prototyping.
+Skipping this phase or ignoring its constraints violates the core invariant that all generated code MUST be robust, maintainable, and free of architectural debt.
+This rigorous approach ensures that the output is indistinguishable from code written by a highly experienced human engineer intimately familiar with the project.
+The orchestrating agent MUST strictly manage task state, enforce coding idioms, and actively hunt for anti-patterns during generation.
+Failure to properly execute this phase will result in the accumulation of technical debt, immediate rejection during S8 Code Review, and a degraded repository state.
+The S6 phase explicitly bridges the gap between approved planning and automated testing.
+
+## 2. The Senior Developer Mandate
+The quality of the output in this phase relies entirely on the agent adopting the correct persona and operational mindset. 
+The agent MUST explicitly adopt the following foundational mandate before generating any code, treating it as the highest behavioral directive.
+> "You are a senior engineer on a production team. Speed is not the goal. Correctness, architecture-fit, and maintainability are your absolute priorities. You write lean, idiomatic code that respects existing patterns."
+The agent MUST NOT generate boilerplate code; every line written MUST serve a distinct, necessary purpose for the feature.
+The agent MUST ensure that all new implementations perfectly match the existing coding idioms and stylistic conventions found within the repository.
+The agent MUST NOT invent new structural paradigms unless explicitly directed to do so by the approved `plan.md`.
+The agent MUST verify its own output against this mandate continuously throughout the execution cycle.
+The agent MUST strictly enforce the following specific execution rules and modal constraints.
+
+### 2.1 Architectural Alignment and Task Selection
+Before writing code, the agent MUST explicitly instruct itself to read `resources/stack-detector.md` and subsequently load the applicable stack packs based on the `GEMINI.md` definitions. 
+The agent MUST NOT attempt to write framework-specific logic without having the corresponding stack pack loaded into active memory.
+Once the architecture is understood, the agent MUST select the lowest-indexed incomplete task from the `.agents/session-[SHA]/task.md` file.
+The agent MUST immediately mark this selected task with the `[/]` notation to indicate that work is actively in progress.
+The agent MUST isolate its focus entirely to this single task, refusing to address unrelated issues or future steps until the current task is fully resolved.
+
+### 2.2 Anti-Pattern Enforcement and Post-Coding Check
+During the actual code generation process, the agent MUST explicitly enforce all constraints defined in the `resources/anti-patterns.md` registry. 
+The agent MUST guarantee zero simulation code, zero verbose comments, zero TODOs, and zero instances of compiler appeasement.
+Upon completing the code generation for the selected task, the agent MUST perform a rigorous self-audit before declaring the work finished.
+The agent MUST mandate and execute this precise post-coding check: "Mentally check every named anti-pattern against the code just written. If any matches, fix before proceeding to S7".
+The agent MUST NOT transition to the automated testing phase until it is absolutely certain no anti-patterns remain in the generated files.
+
+### 2.3 Fast Mode Escalation Rule
+When operating under Fast Mode, the agent is trusted to execute rapid, low-risk changes without a formal S4 plan review. 
+However, Fast Mode is strictly not a license to silently engage in scope creep or execute massive architectural shifts under the radar.
+The agent MUST constantly monitor the size and impact of its generated code during the Fast Mode execution cycle.
+The agent MUST explicitly mandate the following Fast Mode escalation rule: if the agent discovers the necessary change exceeds 3 files or 100 lines of code, it MUST explicitly pause execution.
+Upon pausing, the agent MUST ask the user whether to escalate the session to Standard Mode.
+The agent MUST NOT continue generating code beyond this threshold without explicit human authorization.

package/skills/s6-coding/resources/anti-patterns.md

@@ -0,0 +1,49 @@
+# Anti-Pattern Registry
+
+## 1. Introduction and Purpose
+This document defines the definitive registry of forbidden coding practices within the `ideal-agentic-workflow` plugin. 
+The core philosophy of this workflow dictates that speed is never a virtue if it comes at the expense of architectural integrity or maintainability. 
+Without this explicit registry, autonomous coding agents often default to generating brittle, performative code that appears functional but collapses under real-world usage.
+By strictly defining and prohibiting these specific behaviors, the workflow guarantees that all generated code adheres to the highest senior developer standards.
+The executing agent MUST cross-reference every line of generated code against these defined anti-patterns before declaring a task complete.
+The agent MUST immediately rewrite any logic that violates these constraints, regardless of whether the code compiles successfully.
+Allowing any of these anti-patterns to slip into a commit violates the fundamental behavioral rules outlined in the project's PRD.
+The agent MUST enforce the following four mandatory constraints across all generated files.
+
+## 2. Core Anti-Patterns
+The following sub-sections detail the specific coding behaviors that are strictly forbidden during the S6 Coding phase. 
+These constraints are not merely guidelines; they are non-negotiable hard rules that dictate the quality of the final output.
+The agent MUST treat the presence of any of these patterns as a critical failure requiring immediate remediation.
+The overarching goal is to produce lean, self-documenting, production-ready code that matches existing project idioms.
+The agent MUST rigorously analyze its own output against these four explicitly named anti-patterns.
+The agent MUST guarantee that the final commit contains zero instances of these prohibited structures.
+If a reviewer during S8 Code Review detects any of these patterns, the agent MUST accept the rejection and rewrite the implementation.
+The agent MUST strictly enforce the following specific prohibitions.
+
+### 2.1 AP-001: Zero Simulation or Mock Code
+The agent MUST NOT generate placeholder data, hardcoded mock responses, or simulation logic under any circumstances. 
+Writing fake implementations gives a false sense of progress while offloading the actual engineering work onto future tasks.
+If a feature requires a database query, the agent MUST write the actual query using the project's designated ORM.
+If an external API is required, the agent MUST implement the real HTTP client logic.
+The agent MUST ensure the generated code is completely production-ready.
+
+### 2.2 AP-002: Zero Verbose Comments
+The agent MUST NOT clutter the source code with narrative, conversational, or overly explanatory comments. 
+Code MUST be self-documenting through clear variable naming, well-structured functions, and explicit type definitions.
+Adding paragraphs of comments explaining basic language syntax or obvious logic flows degrades readability and creates maintenance burdens.
+The agent MUST restrict comments exclusively to documenting non-obvious business logic, complex algorithms, or necessary hacks.
+The agent MUST delete any generated comments that merely restate what the code does.
+
+### 2.3 AP-003: Zero TODO or FIXME Comments
+The agent MUST NOT leave `TODO`, `FIXME`, or `PENDING` comments in the generated codebase. 
+The purpose of the S6 phase is to complete the assigned task entirely; leaving a `TODO` is an explicit admission of incomplete work.
+If a task cannot be fully implemented due to missing dependencies, the agent MUST halt execution and request user intervention.
+The agent MUST NOT commit partial implementations that rely on future developers to finish the logic.
+The agent MUST ensure that every line of code written represents a finalized, working state.
+
+### 2.4 AP-004: Zero Compiler Appeasement
+The agent MUST NOT bypass type safety, suppress linter warnings, or violate architectural boundaries simply to force a successful compilation. 
+Using `any` types in TypeScript, `// @ts-ignore` directives, or forced unwrap operators in Swift are strictly forbidden unless explicitly authorized by the project rules.
+Compiler errors indicate a fundamental misunderstanding of the data flow or the framework's constraints.
+The agent MUST solve the underlying architectural issue rather than masking it with unsafe type casting or suppressed warnings.
+The agent MUST guarantee that the code compiles cleanly while adhering to the strictest type safety settings available.

package/skills/s6-coding/resources/stack-detector.md

@@ -0,0 +1,35 @@
+# Stack Detector Instructions
+
+## 1. Introduction and Purpose
+This document provides the mandatory protocol for identifying the current technology stack during the S6 Coding phase. 
+Because the `ideal-agentic-workflow` plugin operates across diverse projects ranging from web applications to Minecraft mods, the coding agent must adapt its architectural approach dynamically. 
+Without a mechanism to detect the active stack, the agent risks generating code that violates the project's foundational framework rules (e.g., mixing Next.js Pages router logic into an App router project).
+By enforcing this detection protocol, the workflow ensures that all generated code is highly specific, idiomatic, and framework-compliant.
+The agent MUST execute these detection steps at the very beginning of the S6 phase, before writing a single line of production code.
+The agent MUST NOT rely on internal assumptions or general language knowledge; it must strictly adhere to the rules defined in the corresponding stack pack.
+Failure to detect and apply the correct stack pack guarantees that the plan reviewers will reject the implementation.
+The agent MUST rigorously follow the detection and loading sequence defined below.
+
+## 2. Stack Detection Protocol
+The identification of the active technology stack is a deterministic process relying entirely on the project's primary knowledge base. 
+The agent MUST NOT attempt to infer the stack by arbitrarily scanning source files or package configuration files, as this is prone to error and misinterpretation.
+The definitive source of truth for the project's architecture is explicitly documented within the `GEMINI.md` file.
+The agent MUST read this central document to determine which specific architectural constraints apply to the current task.
+Once identified, the agent MUST locate and load the corresponding instruction files from the plugin's resource directory.
+The agent MUST apply these rules consistently across all code generation tasks in the current session.
+The agent MUST execute the following exact steps to secure the architectural context.
+The agent MUST NOT proceed to coding if the stack pack file cannot be located.
+
+### 2.1 Read GEMINI.md Technology Stack
+The agent MUST open and parse the `GEMINI.md` file located at the root of the project workspace. 
+The agent MUST locate the specific section detailing the "Technology Stack" or "Architecture" to identify the primary frameworks in use.
+If the project utilizes multiple frameworks (e.g., a React frontend and a Spring Boot backend), the agent MUST identify the stack relevant to the specific task at hand.
+The agent MUST extract the exact framework names and versions defined by the user in this document.
+The agent MUST use this extracted information to determine which stack pack applies.
+
+### 2.2 Load Applicable Stack Packs
+After identifying the framework from `GEMINI.md`, the agent MUST locate the corresponding file within the `resources/stacks/` directory. 
+The agent MUST read the contents of this stack pack (e.g., `web-nextjs-turborepo.md` or `mc-fabric.md`) completely into its active context.
+The agent MUST explicitly memorize the "Architecture Rules" and "Common Anti-Patterns" defined within that specific stack pack.
+The agent MUST apply these loaded rules to every line of code generated during the S6 phase, ensuring total compliance with the project's idiomatic constraints.
+The agent MUST explicitly verify its implementation against these rules before concluding the task.

package/skills/s8-code-review/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: "S8 Code Review"
+description: "Orchestrates the rigorous peer review phase, strictly gating progression based on automated test results and multi-agent consensus."
+---
+
+# S8 Code Review
+
+## 1. Introduction and Purpose
+This document defines the strict execution protocol for the S8 Code Review phase within the `ideal-agentic-workflow` plugin. 
+The S8 phase is the uncompromising quality gate designed to prevent untested, flawed, or architecturally unsound code from progressing to the commit stage.
+The orchestrating agent MUST execute the protocols defined below to guarantee that the peer review process remains objective, thorough, and completely isolated from the authoring context.
+Bypassing this phase or manipulating the review outcomes violates the core tenets of the workflow and completely invalidates the integrity of the generated codebase.
+This rigorous approach mimics a real-world engineering team where peer consensus is an absolute prerequisite for merging.
+The orchestrating agent MUST strictly manage the creation of review requests, coordinate the reviewer subagents, and enforce the absolute gating rules.
+Failure to properly execute this phase will result in the accumulation of technical debt and broken builds in the main branch.
+The S8 phase explicitly bridges the gap between verified local testing and the final commit preparation.
+
+## 2. Hard Gating and Behavioral Rules
+The integrity of the review process relies entirely on strict adherence to the project's foundational behavioral constraints. 
+The agent MUST explicitly verify the following gating rules before attempting to initiate any peer review sequence.
+The agent MUST acknowledge the absolute prohibition: "NEVER invoke S8 code review if any automated test is failing."
+If the S7 Testing phase reported any compiler errors, failing unit tests, or linter warnings, the agent MUST immediately loop back to S6 and fix the code.
+Furthermore, the agent MUST obey the core behavioral rule: "NEVER write a review file yourself. Review MUST come from real subagents or R-Agent."
+The agent MUST NOT attempt to fake a positive review to bypass the subagent invocation process.
+The agent MUST explicitly verify these prerequisites before proceeding to submit the code.
+The agent MUST enforce the following specific execution rules regarding submission and reviewer management.
+
+### 2.1 Submit File Creation Protocol
+Before spawning reviewers, the agent MUST formally document the changes by creating a `submit(N).md` file in the `.agents/session-[SHA]/code-review/submit/` directory. 
+The agent MUST format this file meticulously to ensure the reviewers have all necessary context to perform a deep semantic evaluation.
+The agent MUST include a clear task description detailing the original requirements and the implemented solution.
+The agent MUST include a comprehensive list of all files changed and a detailed diff summary of the modifications.
+The agent MUST include specific questions for the reviewers, highlighting complex logic or architectural decisions that require extra scrutiny.
+
+### 2.2 Modal Reviewer Invocation
+The agent MUST determine the exact number and type of reviewer subagents to spawn based on the active session mode. 
+For Fast Mode, the agent MUST spawn exactly 1 reviewer utilizing the `implementation-reviewer` persona.
+For Standard Mode, the agent MUST spawn exactly 2 reviewers utilizing the `implementation-reviewer` persona and one other persona specifically matched to the detected project type (e.g., `security-code-reviewer` for fullstack, or `game-performance-auditor` for minecraft).
+For Duolithic Mode, the agent MUST NOT spawn subagents directly; instead, it MUST generate the explicit onboarding prompt: "Read submit([N]).md at [PATH]. Spawn 4 code-reviewer subagents."
+After generating the Duolithic prompt, the agent MUST pause execution and wait for the exact `RAGENT_DONE` signal from the user.
+If the active mode is Trivial Protocol, the agent MUST skip the S8 phase entirely and proceed directly to S10.
+
+### 2.3 Patience Directive and Status Checking
+The peer review process is computationally intensive and may require significant time to complete deep semantic analysis. 
+The orchestrating agent MUST exhibit patience and refrain from interrupting or unnecessarily polling the reviewer subagents.
+The agent MUST explicitly use the `schedule` tool to set a 300-second timer if the subagents are particularly slow to respond.
+The agent MUST NOT spam status checks in a tight loop, as this wastes resources and clutters the session context.
+The agent MUST patiently await the explicit arrival of the completed `review(n).md` files from the subagents or the R-Agent.
+
+### 2.4 Progression and Iteration Loops
+Upon receiving all requested reviews, the agent MUST evaluate the consensus to determine the next phase of the workflow. 
+The agent MUST enforce the absolute progression gate: "LGTM from ALL reviewers required before proceeding. One CHANGES_REQUESTED blocks and loops to S9 Bug Fix."
+If any reviewer requests changes, the agent MUST enter the S9 Bug Fix phase, resolve the issues, strictly re-run the S7 automated testing suite, and then send a message to the reviewers with a detailed changelog of what was fixed before requesting a re-review.
+If ALL reviewers explicitly provide an `LGTM` (Looks Good To Me) approval, the agent MUST mark the current task as `[x]` (completed) in the `task.md` tracker.
+Following a successful approval, the agent MUST loop back to S6 if incomplete tasks remain, or proceed directly to S10 Commit if all tasks are finished.

package/skills/s8-code-review/resources/code-review-guide.md

@@ -0,0 +1,42 @@
+# Code Review Guide
+
+## 1. Introduction and Purpose
+This document provides the definitive evaluation framework that all code reviewer subagents MUST utilize during the S8 Code Review phase. 
+The code review phase is the final, uncompromising barrier preventing defective logic, architectural drift, and technical debt from merging into the target repository.
+Unlike standard linters, the reviewer subagents are tasked with deep semantic analysis, evaluating whether the implementation truly fulfills the task requirements robustly.
+By establishing these rigorous evaluation criteria, the workflow ensures that every line of code meets the high standards of a senior engineering team.
+Reviewers MUST strictly evaluate the submitted code against these predefined dimensions rather than relying on subjective stylistic preferences.
+Reviewers MUST immediately issue a `CHANGES_REQUESTED` status if any of the following constraints are violated, detailing the exact lines requiring modification.
+Rubber-stamping bad code fundamentally compromises the Agentic Engineering philosophy and is strictly forbidden.
+The reviewer MUST verify the implementation against the following core dimensions.
+
+## 2. Review Dimensions
+The following sub-sections define the precise technical areas that the code reviewer subagents MUST scrutinize. 
+These dimensions represent the most common failure points where autonomous agents introduce bugs, security vulnerabilities, or brittle implementations.
+Reviewers MUST approach the code with skepticism, hunting for flaws rather than assuming the original author's logic is sound.
+If the reviewer cannot definitively prove that the code is correct, they MUST reject it and demand clarification or refactoring.
+The reviewer MUST evaluate the code contextually, ensuring it aligns perfectly with the detected project persona loaded from the stack pack (e.g., fullstack web architecture versus minecraft modding paradigms).
+A fullstack web feature requires different architectural considerations (like REST API security) than a Minecraft mod feature (like tick-rate performance).
+The reviewer MUST rigorously assess the submitted diff against the following specific criteria.
+The reviewer MUST reject the submission if any of these dimensions fail.
+
+### 2.1 Anti-Pattern Verification
+The reviewer MUST actively hunt for the four explicitly banned anti-patterns defined in the S6 Coding phase (AP-001 through AP-004). 
+The reviewer MUST reject the code if it contains any simulation logic, mock data implementations, or placeholder text.
+The reviewer MUST reject the code if it includes verbose, narrative comments that simply restate obvious logic flows.
+The reviewer MUST reject the code if it contains any `TODO`, `FIXME`, or `PENDING` notes, demanding complete implementations.
+The reviewer MUST reject the code if it utilizes compiler appeasement tactics like unauthorized `any` types or suppressed warnings.
+
+### 2.2 Architectural Compliance
+The reviewer MUST verify that the submitted implementation aligns perfectly with the established architectural guidelines of the repository. 
+The reviewer MUST ensure the code does not introduce new structural paradigms, unauthorized third-party dependencies, or conflicting design patterns.
+If the project follows a strict MVC pattern, the reviewer MUST reject logic that tightly couples database queries directly to view components.
+The reviewer MUST verify that the specific constraints of the loaded stack pack (e.g., Next.js App Router rules) are strictly obeyed.
+The reviewer MUST mandate a refactor if the code deviates from the established repository idioms.
+
+### 2.3 Persona-Specific Logic Verification
+The reviewer MUST evaluate the logic specifically through the lens of the project's designated persona (e.g., fullstack versus minecraft). 
+For fullstack projects, the reviewer MUST prioritize verifying data sanitization, API security, and proper asynchronous state management.
+For Minecraft projects, the reviewer MUST prioritize verifying tick-rate efficiency, memory management, and proper mixin implementation without conflicts.
+The reviewer MUST ensure that the implementation is not just syntactically correct, but contextually robust for the target environment.
+The reviewer MUST reject the code if it fails to account for these domain-specific vulnerabilities.