ideal-agentic-workflow 1.0.0

package/skills/s1-orchestrator/SKILL.md

@@ -0,0 +1,193 @@
+---
+name: s1-orchestrator
+description: Initializes the ideal-agentic-workflow session, reads GEMINI.md, generates the session SHA, detects the operating mode, and prepares the workspace for the S2 Audit phase.
+---
+
+# S1 Orchestrator
+
+## What This Skill Does
+
+This skill is the absolute entry point for the `ideal-agentic-workflow` plugin. 
+
+It executes the "S1 Context Ingestion" phase defined in the PRD. 
+
+The reader of this document is the AI agent initiating a new workflow session. 
+
+The purpose of this skill is to establish the foundation for all subsequent steps. 
+
+It creates the isolated session environment where all temporary state will reside. 
+
+It also detects the project's technology stack and the user's requested operating mode. 
+
+Without executing this skill first, the rest of the workflow will fail due to missing context.
+
+We MUST run this skill successfully before opening any source code files.
+
+## Senior Developer Mindset
+
+Before executing any other action in this skill, the agent MUST adopt the Senior Developer Mindset. 
+
+You are joining a real engineering team, not a hackathon. 
+
+Speed is not the goal; correctness, architecture-fit, and maintainability are paramount. 
+
+You MUST deliberately review and plan before making changes. 
+
+Rushing to write code without full context is a violation of this plugin's core philosophy.
+
+For example, a Vibe Coding approach would immediately start modifying files to fix a reported bug. 
+
+In contrast, the Senior Developer approach mandates reading `GEMINI.md` to understand the system invariants before even opening the buggy file.
+
+This deliberate pacing prevents the creation of brittle workarounds that violate established patterns.
+
+## First Action: Context Ingestion
+
+The very first action the agent MUST take is reading the project's `GEMINI.md` file. 
+
+This file is the single source of truth for the repository's architecture and rules. 
+
+We MUST NOT assume anything about the codebase that is not documented here. 
+
+Reading source files before reading `GEMINI.md` is a critical violation of the workflow invariants.
+
+This guarantees that the agent adopts the correct context before making any decisions.
+
+Precondition: The user has initiated a new workflow session in a project root containing `GEMINI.md`.
+
+1. Execute the `view_file` tool targeting the absolute path to `GEMINI.md` in the project root.
+   - Expected Output: The full contents of `GEMINI.md` are loaded into the agent's context.
+2. Parse Section 2.3 (Technology Stack) to identify all technologies explicitly listed in the Stack section.
+   - Expected Output: A list of detected stacks (e.g., "Next.js", "Spring Boot") is held in memory for later steps.
+
+Postcondition: The agent possesses complete knowledge of the project's rules, directory structure, and technology stack.
+
+## Session Resume Logic
+
+Before initializing a completely new session, the agent MUST check if a previous, incomplete session exists. 
+
+This prevents abandoning work halfway and cluttering the `.agents/` directory with orphaned tasks. 
+
+If a previous session's `task.md` contains uncompleted items, the agent MUST give the user the choice to resume. 
+
+We MUST NOT automatically overwrite or ignore past incomplete sessions. 
+
+The user is the final arbiter of whether to continue past work or start fresh.
+
+Precondition: The `.agents/` directory exists in the project root.
+
+1. Scan the `.agents/` directory for any subdirectories starting with `session-`.
+   - Expected Output: A list of existing session directories is identified.
+2. If any exist, check their internal `task.md` file for any tasks that are not marked as `[x]`.
+   - Expected Output: The agent determines if any session is incomplete.
+3. If an incomplete session is found, output a message to the user: "Resume session [SHA] or start fresh?".
+   - Expected Output: The workflow pauses, waiting for the user's decision on how to proceed.
+
+Postcondition: The agent either resumes the specified previous session or proceeds to generate a new session SHA.
+
+## Session SHA Generation and Directory Initialization
+
+To isolate the current workflow from past or parallel sessions, we MUST generate a unique identifier. 
+
+This identifier is used to create a dedicated working directory. 
+
+All temporary files, plans, and review artifacts will be stored here. 
+
+This prevents state corruption and allows for clean session resumption.
+
+We MUST follow the specific SHA generation algorithm provided in the resources.
+
+Precondition: Context ingestion is complete and no past session is being resumed.
+
+1. Read the `resources/session-init.md` file to obtain the SHA generation algorithm.
+   - Expected Output: The agent understands the timestamp-based SHA1 logic.
+2. Execute the generation algorithm to produce a 6-character lowercase hex string.
+   - Expected Output: A unique string like `e3f9a2` is generated.
+3. Run the directory creation commands specified in `resources/session-init.md`.
+   - Expected Output: The `.agents/session-[SHA]/` directory tree is created with all required subdirectories and stub files.
+
+Postcondition: A pristine, isolated workspace is ready for the current session's artifacts.
+
+## Mode Detection
+
+The user MAY specify a specific operating mode by including a keyword in their prompt. 
+
+These modes alter how subsequent phases behave. 
+
+If no keyword is detected, the agent MUST default to Standard Mode. 
+
+It is critical to detect this early so that downstream subagents are configured correctly.
+
+We MUST record the detected mode in the session directory for persistence.
+
+Precondition: The session directory tree has been initialized.
+
+1. Analyze the user's initial prompt for mode trigger keywords (`/fast mode`, `/trivial`, `/duolithic mode`).
+   - Expected Output: The requested mode (or the default Standard Mode) is identified.
+2. Write the identified mode to `.agents/session-[SHA]/mode.txt`.
+   - Expected Output: A file containing the mode string (e.g., "fast") exists.
+3. Depending on the detected mode, read the corresponding resource file (`resources/duolithic-mode.md`, `resources/fast-mode.md`, or `resources/trivial-mode.md`).
+   - Expected Output: The agent explicitly loads and understands the specific protocol rules for the requested mode.
+
+Postcondition: The operating mode is permanently recorded and the agent knows which protocol to follow.
+
+## Stack Detection and Persistence
+
+The detected technology stack MUST be recorded so that S2 subagents can load the correct rules. 
+
+This prevents downstream subagents from having to parse `GEMINI.md` independently. 
+
+It ensures all agents in the session agree on the environment they are auditing. 
+
+We MUST store this in a standardized format.
+
+The `context.md` file serves as the communication medium for this state.
+
+Precondition: The technology stack was identified during Context Ingestion and the session directory exists.
+
+1. Create a `.agents/session-[SHA]/context.md` file.
+   - Expected Output: A new Markdown file is created in the session root.
+2. Write the detected stack keywords into this file (e.g., `Stack: web-nextjs-turborepo`).
+   - Expected Output: The file contains the structured stack data.
+
+Postcondition: The project's stack context is persisted for use by S2 auditors.
+
+## Terminal Usage Rules
+
+The following rules govern all terminal interactions during the session. 
+
+They exist to prevent state corruption, avoid path resolution errors, and ensure user safety. 
+
+Running destructive commands without oversight can result in unrecoverable data loss. 
+
+We MUST adhere to these constraints whenever executing bash commands.
+
+Failure to follow these rules is a severe safety violation.
+
+- Temp files MUST go in `.agents/session-SHA/` ONLY. Never in project root or system temp.
+- Always use absolute paths in terminal commands to prevent silent failures.
+- Do NOT run destructive commands (`rm -rf`, `git reset --hard`) without explicit user approval.
+- Background commands MUST always set a schedule timer if waiting > 30 seconds.
+
+## Completion Criteria
+
+When S1 finishes, it MUST report its status to the user and prepare for S2. 
+
+This transition relies on verifying that all expected artifacts exist. 
+
+If any artifact is missing, S2 will crash or behave unpredictably. 
+
+We MUST output a summary to confirm readiness.
+
+This hands control back to the user or transitions to the next automated step.
+
+Precondition: All previous S1 procedures have been executed.
+
+1. Verify the existence of `.agents/session-[SHA]/mode.txt` and `context.md`.
+   - Expected Output: Confirmation that persistent state files exist.
+2. Verify the existence of the `audit/bin/`, `code-review/submit/`, and `code-review/review/` subdirectories.
+   - Expected Output: Confirmation that the directory tree is complete.
+3. Output a summary message to the user stating that S1 is complete and the agent is ready for S2.
+   - Expected Output: The user sees a confirmation message in the chat interface.
+
+Postcondition: The S1 Orchestrator has successfully completed its lifecycle and the workflow is ready for the S2 Codebase Audit.

package/skills/s1-orchestrator/resources/duolithic-mode.md

@@ -0,0 +1,114 @@
+# Duolithic Mode Protocol
+
+## What This Resource Does
+
+This document details the operational protocol for Duolithic Mode within the workflow. 
+
+The reader of this document is the M-Agent (the primary Claude agent orchestrating the session). 
+
+The purpose of this protocol is to define how the M-Agent delegates heavy review tasks to the R-Agent. 
+
+The R-Agent is a secondary Gemini agent running in a separate, parallel conversation. 
+
+By splitting the workload, we leverage Claude's superior reasoning for implementation while using Gemini's higher quota for parallel subagent spawning. 
+
+This prevents quota exhaustion during intensive audit and review phases. 
+
+The M-Agent MUST follow this protocol exactly when `/duolithic mode` is detected. 
+
+Failure to follow this protocol will result in a breakdown of inter-agent communication.
+
+## The Handoff Mechanism
+
+The M-Agent and R-Agent do not communicate directly via an API. 
+
+Instead, they use the user as a bridge and the filesystem as a shared state repository. 
+
+The M-Agent generates an Onboarding Prompt that the user pastes into the R-Agent's conversation. 
+
+The R-Agent executes its subagents, writes the output to the filesystem, and signals completion. 
+
+The M-Agent then reads the output file and resumes the workflow. 
+
+This asynchronous handoff MUST be strictly managed to avoid race conditions.
+
+We MUST rely on precise file paths to ensure the R-Agent writes exactly where the M-Agent expects to read.
+
+### Generating the Onboarding Prompt
+
+When the workflow reaches a phase delegated to the R-Agent (S2, S4, or S8), the M-Agent MUST generate a specific prompt. 
+
+This prompt instructs the R-Agent on its exact responsibilities. 
+
+It MUST be presented to the user in a clearly demarcated code block. 
+
+The prompt MUST include absolute paths to prevent resolution errors in the R-Agent's context.
+
+Without this prompt, the user cannot correctly instruct the R-Agent.
+
+Precondition: The M-Agent has reached S2, S4, or S8 in a Duolithic session.
+
+1. Determine the current task type (`AUDIT`, `PLAN_REVIEW`, or `CODE_REVIEW`).
+   - Expected Output: The correct context string is selected based on the phase.
+2. Compile the `R-AGENT ONBOARDING PROMPT` using the template provided below, substituting all bracketed variables with actual absolute paths and SHA values.
+   - Expected Output: A fully resolved prompt text block.
+3. Output the prompt to the user inside a code block, accompanied by instructions to paste it into the R-Agent conversation and return when finished.
+   - Expected Output: The workflow pauses, waiting for the user's return signal.
+
+Postcondition: The M-Agent is paused, waiting for the R-Agent's output file to appear on the filesystem.
+
+## R-Agent Onboarding Prompt Template
+
+The following template MUST be used verbatim, replacing only the bracketed variables. 
+
+It ensures the R-Agent receives all necessary constraints and context. 
+
+The template strictly forbids the R-Agent from modifying source code. 
+
+It also mandates the exact completion signal the R-Agent must output.
+
+Any deviation from this template MAY cause the R-Agent to hallucinate or misbehave.
+
+```text
+--- R-AGENT ONBOARDING PROMPT ---
+
+You are the Reviewer Agent (R-Agent) in a Duolithic Agentic Engineering session.
+
+## Your Role
+You are operating as a specialized review coordinator. You do NOT write production code.
+Your ONLY job is to execute the review/audit task described below and write the output file to the exact path specified.
+
+## Session Context
+- Project root: [ABSOLUTE_PROJECT_PATH]
+- Session SHA: [6_CHAR_SHA]
+- GEMINI.md path: [PROJECT_ROOT]/GEMINI.md
+- Session dir: [PROJECT_ROOT]/.agents/session-[SHA]/
+
+## Your Task
+[TASK_TYPE: AUDIT | PLAN_REVIEW | CODE_REVIEW]
+
+[TASK-SPECIFIC CONTEXT]:
+- For AUDIT: "Read every source file listed in GEMINI.md's directory structure. Spawn 5 audit subagents using the personas defined in the persona-library."
+- For PLAN_REVIEW: "Read plan.md at [PATH]. Spawn 3 plan-reviewer subagents."
+- For CODE_REVIEW: "Read submit([N]).md at [PATH]. Spawn 4 code-reviewer subagents."
+
+## Subagent Count
+Spawn [N] subagents as specified above. Do NOT reduce this count.
+
+## Output
+Write your compiled output to: [EXACT_OUTPUT_PATH]
+Follow the template schema exactly (audit-template / review-template).
+
+## Completion Signal
+When all subagents have successfully returned their review files, output EXACTLY this line (nothing else):
+RAGENT_DONE: [OUTPUT_FILE_PATH]
+
+## Strict Rules
+- Do not write any production code.
+- Do not modify any source files.
+- Do not modify GEMINI.md.
+- Output file must match the template schema exactly.
+--- END ONBOARDING PROMPT ---
+```
+
+This prompt block acts as the payload for the R-Agent, ensuring it receives all context before launching subagents.

package/skills/s1-orchestrator/resources/fast-mode.md

@@ -0,0 +1,170 @@
+# Fast Mode Protocol
+
+## What This Resource Does
+
+This document defines the strict operational protocol for Fast Mode within the S1-S11 workflow. 
+
+The reader is the AI agent orchestrating the session after `/fast mode` has been detected. 
+
+The purpose of this protocol is to safely accelerate the workflow for well-scoped, low-risk tasks. 
+
+It explicitly outlines which phases are modified, reduced, or skipped entirely. 
+
+By following this protocol, the agent avoids unnecessary overhead while maintaining strict safety invariants. 
+
+The agent MUST follow these rules exactly, as they override the Standard Mode defaults. 
+
+Failure to follow these rules could result in unchecked scope creep or unreviewed code.
+
+It is absolutely forbidden to skip phases not explicitly authorized by this document.
+
+## S2 Codebase Audit Modification
+
+In Fast Mode, the codebase audit is conditionally reduced to save time and quota. 
+
+We assume that for a fast fix, a full 5-agent audit is unnecessary if recent context exists. 
+
+However, we MUST still ensure the architecture and domain logic are respected. 
+
+This prevents the agent from making isolated fixes that break global patterns.
+
+We MUST check the timestamp of the existing `audit.md` before making a decision.
+
+Precondition: The S2 phase is starting in a Fast Mode session.
+
+1. Check for the existence of `audit.md` in the project root or previous sessions.
+   - Expected Output: The agent determines if a prior audit exists.
+2. If `audit.md` exists and is less than 7 days old, skip the S2 phase entirely.
+   - Expected Output: The workflow proceeds directly to S3 without spawning auditors.
+3. If it does not exist or is older than 7 days, run S2 with exactly 2 auditors (Architecture + the domain auditor matching the stack's primary technology).
+   - Expected Output: A targeted, reduced-scope audit is generated.
+
+Postcondition: The S2 phase is either skipped based on recency or executed with a minimal team.
+
+## S3 Planning Modification
+
+The planning phase MUST be simplified to match the reduced scope of the task. 
+
+In Standard Mode, the agent calculates priority rubrics and handles multiple tasks. 
+
+In Fast Mode, we assume the user has provided a single, specific issue to fix. 
+
+The agent MUST write a minimal, single-task plan inline without the full rubric calculation.
+
+We MUST restrict the session to exactly one task.
+
+Precondition: The S3 phase is starting in a Fast Mode session.
+
+1. Create the `plan.md` artifact inline, focusing only on the immediate fix.
+   - Expected Output: A minimal implementation plan is drafted.
+2. Create the `task.md` artifact containing exactly one task item.
+   - Expected Output: The task list is restricted to a single objective.
+
+Postcondition: A simplified plan and single-item task list are ready for execution.
+
+## Skipping S4 Plan Review
+
+The Plan Review phase (S4) is explicitly skipped in Fast Mode. 
+
+This mode inherently trusts the developer's scoping and the agent's initial plan. 
+
+Because the task is trivial or highly isolated, peer review of the plan itself is unnecessary overhead. 
+
+The agent MUST proceed directly from S3 to S5/S6.
+
+We MUST NOT spawn any Plan Critic subagents.
+
+Precondition: The S3 phase has completed successfully.
+
+1. Skip the generation of `submit(n).md` for the plan.
+   - Expected Output: No submit file is generated.
+2. Skip spawning the plan-reviewer subagents.
+   - Expected Output: The workflow transitions immediately to the coding phase.
+
+Postcondition: The agent proceeds to code generation without waiting for plan approval.
+
+## S8 Code Review Modification
+
+The Code Review phase (S8) MUST still execute, but with reduced reviewer count. 
+
+While the plan may skip review, the actual implementation MUST always be verified. 
+
+In Fast Mode, we reduce the reviewer count from 2 to 1 to speed up the loop. 
+
+This single reviewer MUST be the `implementation-reviewer` persona.
+
+We MUST ensure tests pass (S7) before invoking this reviewer.
+
+Precondition: The S7 automated testing phase has passed successfully.
+
+1. Prepare the `submit(n).md` file containing the task's code changes.
+   - Expected Output: The submission file is ready for review.
+2. Spawn exactly 1 code-reviewer subagent using the `implementation-reviewer` persona.
+   - Expected Output: A single reviewer evaluates the code against the rules.
+
+Postcondition: The code is reviewed by a single specialized agent.
+
+## Strict Escalation Guard
+
+Fast Mode is not a license for silent scope creep or massive refactoring. 
+
+If the agent discovers during S6 (Coding) that the change is larger than anticipated, it MUST halt. 
+
+This prevents the agent from hiding massive architectural changes inside a "fast" loop. 
+
+The threshold for escalation is touching more than 3 files or writing more than 100 lines of code.
+
+We MUST ask the user before proceeding if this threshold is crossed.
+
+Precondition: The agent is actively modifying files in the S6 Coding phase.
+
+1. Monitor the number of files modified and the total lines changed.
+   - Expected Output: The agent tracks the current delta size.
+2. If the delta exceeds 3 files or 100 lines, immediately pause execution.
+   - Expected Output: The coding phase is halted.
+3. Prompt the user: "This change is larger than expected (>3 files or >100 lines). Escalate to Standard Mode?"
+   - Expected Output: The user decides whether to continue in Fast Mode or escalate.
+
+Postcondition: The agent either escalates to Standard Mode or receives explicit permission to continue in Fast Mode.
+
+## S10 Commit Target Modification
+
+In Fast Mode, the standard guidelines for commit sizing do not apply. 
+
+Normally, the agent aims for 50-150 lines per commit to ensure atomic units. 
+
+Since Fast Mode is designed for very small, single-issue fixes, there is no size target. 
+
+The agent MUST commit whatever changes the fix requires as a single logical unit. 
+
+We MUST still use the Conventional Commits format for the commit message.
+
+Precondition: The S9 Bug Fix loop (if any) is complete and all tasks are `[x]`.
+
+1. Stage all files related to the Fast Mode fix.
+   - Expected Output: The git index contains all necessary changes.
+2. Formulate a single Conventional Commit message covering the entire fix without splitting it.
+   - Expected Output: The commit message is generated correctly.
+
+Postcondition: The codebase is updated with a single, properly formatted commit.
+
+## S11 GEMINI.md Lightweight Update
+
+The final phase of the workflow is updated to reflect the targeted nature of Fast Mode. 
+
+Instead of scanning all of `GEMINI.md` for potential updates, the agent MUST perform a lightweight update. 
+
+The update MUST strictly be limited to Section 5 (Open Features) if the fix resolves a tracked issue. 
+
+This saves time and prevents unintended modifications to the broader project architecture documentation. 
+
+If the fix was completely unmentioned in Section 5, `GEMINI.md` is left untouched.
+
+Precondition: The S10 commit has been successfully created.
+
+1. Check if the task resolved an issue explicitly listed in `GEMINI.md` Section 5.
+   - Expected Output: The agent determines if documentation needs updating.
+2. If yes, remove or update the corresponding entry in Section 5 only.
+   - Expected Output: Section 5 reflects the completed feature or fix.
+
+Postcondition: The project documentation is accurately maintained with minimal overhead.

package/skills/s1-orchestrator/resources/session-init.md

@@ -0,0 +1,65 @@
+# Session Initialization Protocol
+
+## What This Resource Does
+
+This document defines the exact procedure for generating a session SHA and creating the workspace tree. 
+
+The reader is the AI agent executing the S1 Orchestrator skill. 
+
+The purpose of this protocol is to ensure that every workflow session is cleanly isolated. 
+
+It provides the mathematical algorithm for the SHA and the shell commands for the directory structure. 
+
+By following this strictly, we prevent file collisions between concurrent or resumed sessions. 
+
+The agent MUST execute these steps verbatim during S1. 
+
+Failure to follow this protocol will result in scattered artifacts and broken downstream skills.
+
+It is absolutely forbidden to create any files or folders before this initialization completes successfully.
+
+## SHA Generation Algorithm
+
+The session SHA is a 6-character hexadecimal string derived from the current system timestamp. 
+
+It serves as the unique identifier for the entire session lifecycle. 
+
+It MUST be pseudo-random enough to prevent collisions within a single project. 
+
+Using a hash of the timestamp ensures uniqueness even if multiple sessions start on the same day.
+
+The agent MUST implement this logic internally before creating any files.
+
+Precondition: The S1 skill has reached the SHA generation phase.
+
+1. Obtain the current system time in milliseconds since the UNIX epoch (e.g., `1752419345892`).
+   - Expected Output: An integer representation of the current time.
+2. Compute the SHA-1 hash of the string representation of that integer.
+   - Expected Output: A full 40-character hexadecimal SHA-1 string.
+3. Extract the first 6 characters of the resulting hex string.
+   - Expected Output: A 6-character string (e.g., `e3f9a2`) that will act as the `[SHA]`.
+
+Postcondition: The agent holds a valid 6-character session SHA in its active memory.
+
+## Directory Tree Creation
+
+Once the SHA is generated, the physical workspace MUST be initialized. 
+
+This involves creating a nested directory structure within the `.agents/` folder. 
+
+All paths MUST be absolute, anchored to the project root, to prevent execution context errors. 
+
+We MUST create empty stub files for `plan.md` and `task.md` so that S3 has a valid target to write to.
+
+The agent MUST verify that these commands succeed without throwing permission errors.
+
+Precondition: The `[SHA]` has been generated and the project root path is known.
+
+1. Execute a shell command to create the root session directory: `mkdir -p [PROJECT_ROOT]/.agents/session-[SHA]/`.
+   - Expected Output: The root session folder exists.
+2. Execute shell commands to create the subdirectories: `mkdir -p [PROJECT_ROOT]/.agents/session-[SHA]/audit/bin/`, `mkdir -p [PROJECT_ROOT]/.agents/session-[SHA]/code-review/submit/`, and `mkdir -p [PROJECT_ROOT]/.agents/session-[SHA]/code-review/review/`.
+   - Expected Output: All nested directories exist.
+3. Execute shell commands to create the stub files: `touch [PROJECT_ROOT]/.agents/session-[SHA]/plan.md` and `touch [PROJECT_ROOT]/.agents/session-[SHA]/task.md`.
+   - Expected Output: The empty stub files are created in the session root.
+
+Postcondition: The complete directory tree is present on the filesystem, ready for S2 and S3 operations.

package/skills/s1-orchestrator/resources/trivial-mode.md

@@ -0,0 +1,113 @@
+# Trivial Mode Protocol
+
+## What This Resource Does
+
+This document defines the strict operational protocol for the Trivial Change Protocol. 
+
+The reader is the AI agent orchestrating the session after `/trivial` has been detected. 
+
+The purpose of this protocol is to optimize the workflow for changes that have absolutely zero logic impact. 
+
+It explicitly outlines which phases are skipped to allow for immediate commits of trivial fixes. 
+
+By following this protocol, the agent bypasses heavy audits and reviews for safe documentation changes. 
+
+The agent MUST follow these rules exactly, as they drastically bypass the normal workflow. 
+
+Failure to follow these rules could result in unreviewed, broken code being committed.
+
+It is absolutely forbidden to use this protocol for any logic-bearing changes.
+
+## Defining Trivial Changes
+
+The defining criterion for this mode is that no production logic is added, modified, or removed. 
+
+The agent MUST strictly enforce this definition before executing any changes. 
+
+Qualifying examples include README typo fixes, Markdown formatting corrections, or updating a version number in docs. 
+
+Adding a missing license header or fixing a comment that references a wrong file name also qualify.
+
+If the request falls outside these examples, the agent MUST escalate to a higher mode.
+
+Precondition: The user has requested `/trivial` mode.
+
+1. Analyze the user's request against the definition of a trivial change.
+   - Expected Output: The agent confirms the request has zero logic impact.
+2. If the request involves logic, configuration, or source code modifications, reject the `/trivial` flag.
+   - Expected Output: The agent escalates to Fast or Standard Mode.
+
+Postcondition: The agent confirms the change is genuinely trivial.
+
+## Skipped Phases
+
+To maximize speed for documentation fixes, almost the entire standard workflow is skipped. 
+
+The agent MUST bypass S2, S3, S4, S5, and S6. 
+
+No audit, no plan, and no code review cycle are necessary for correcting a typo. 
+
+The agent makes the documentation or trivial change directly. 
+
+Furthermore, S8 (Code Review) and S11 (Update GEMINI.md phase) are also completely skipped.
+
+We MUST proceed directly to S7 and S10.
+
+Precondition: The change is confirmed to be trivial.
+
+1. Skip S2, S3, S4, S5, and S6 entirely.
+   - Expected Output: No audit or plan artifacts are generated.
+2. Apply the requested documentation or formatting change directly to the file.
+   - Expected Output: The change is made on the filesystem.
+3. Skip S8 (Code Review) and S11 (Update GEMINI.md phase).
+   - Expected Output: No peer review is invoked, and the PRD is untouched.
+
+Postcondition: The trivial change is applied and ready for validation and commit.
+
+## S7 Build and S10 Commit
+
+Even for trivial changes, basic sanity checks and strict commit hygiene apply. 
+
+The agent MUST run the build step in S7 to ensure a Markdown typo didn't break a generator. 
+
+However, running the full test suite is NOT required unless the file is test-adjacent. 
+
+The commit MUST strictly follow Conventional Commits format, using `docs` or `chore` types.
+
+We MUST maintain a clean git history, even for tiny fixes.
+
+Precondition: The trivial change has been applied.
+
+1. Run the project's build command to verify structural integrity.
+   - Expected Output: The build passes successfully.
+2. Group the change into a single atomic unit.
+   - Expected Output: The files are staged for commit.
+3. Write a single commit with type `docs` or `chore`.
+   - Expected Output: The change is committed to the repository history.
+
+Postcondition: The trivial change is safely integrated into the project.
+
+## Hard Source File Guard
+
+This guard is the ultimate safety mechanism for the Trivial Change Protocol. 
+
+If the agent detects that the change requires modifying ANY source file, it MUST immediately exit. 
+
+This includes files like `.ts`, `.js`, `.java`, `.rs`, `.py`, `.kt`, or `.json` (config files). 
+
+Trivial Protocol is for documentation and non-source files ONLY. 
+
+Attempting to modify a source file under this protocol is a critical safety violation.
+
+We MUST escalate to Fast Mode or Standard Mode instantly if this rule is breached.
+
+Precondition: The agent is about to modify a file.
+
+1. Check the file extension and directory of the target file.
+   - Expected Output: The file type is identified.
+2. If the file is a source file or configuration file, halt the operation.
+   - Expected Output: The modification is blocked.
+3. Escalate the session to Fast Mode or Standard Mode and notify the user.
+   - Expected Output: The workflow resets to Fast Mode or Standard Mode.
+
+Postcondition: Source files are protected from unreviewed modifications.