feat: create a standalone rule

Author: matscode

rules/holistic-workflow.rules.md

@@ -1,11 +1,13 @@
 # Holistic Workflow: A Guide to Your Thought Process
+Authored by matscode
 
 ## 1. Purpose of This Guide
-This document is your "mental map." You may read the various `.rules.md` files in any order, but this guide provides the **chronological sequence** in which you should apply them. It orchestrates the individual rule sets into a single, coherent workflow, ensuring you approach every problem logically and efficiently.
+This document is your "mental map." You may read the various `.rules.md` files in any order, but this guide provides the **chronological sequence** in which you should apply them. It orchestrates the individual rule sets into a single, coherent workflow, ensuring you approach every problem logically and efficiently. This workflow should be considered at all times as your primary operational guide.
 
 This is not just a set of rules; it is a framework for your thinking.
 
 ## 2. The Recommended Workflow
+Authored by matscode
 
 ### Step 1: First, Understand Who You're Working With
 *   **Objective:** Know your user's background and communication preferences.
@@ -18,7 +20,7 @@ This is not just a set of rules; it is a framework for your thinking.
 
 ### Step 3: Third, Consult Existing Decisions
 *   **Objective:** Avoid re-inventing the wheel and maintain consistency.
-*   **Action:** Before creating a new solution, always check for existing architectural and design decisions.
+*   **Action:** Before creating a new solution, you **MUST** follow the "Step 1: Specification Selection and Reuse Protocol" outlined in `rules/spec-management.rules.md`.
 *   **Detailed Instructions:** `rules/spec-management.rules.md`
 
 ### Step 4: Fourth, Collaborate and Clarify
@@ -38,3 +40,5 @@ This is not just a set of rules; it is a framework for your thinking.
 For example, if you are in the **"Implement"** step and you discover an unexpected technical challenge, you should not "push through." Instead, you should immediately return to the **"Collaborate and Clarify"** step to discuss the issue with the user and adjust the plan.
 
 Always be ready to adapt. The goal is not to rigidly follow the steps, but to use them as a framework for intelligent, adaptive problem-solving.
+
+-- Authored by [matscode](https://www.linkedin.com/in/matscode)

rules/index.rules.md

@@ -1,4 +1,5 @@
 # Interactive Coding Agent: Mandatory Onboarding
+Authored by matscode
 
 ## 🚨 CRITICAL: YOU MUST READ AND OBEY THESE ONBOARDING RULES FIRST
 
@@ -22,6 +23,7 @@ Your single, initial task is to read and understand your operational rules.
 ---
 
 ## 2. The Mandatory Reading Sequence
+Authored by matscode
 
 You are required to read the project's rule files in the following sequence:
 
@@ -43,4 +45,6 @@ This final file provides the "mental map" that connects all the other rules into
 ---
 
 ## 3. Onboarding Complete
-Once you have completed this two-step reading process, your onboarding is complete. You may then proceed to analyze the user's request and begin your work, following the process outlined in the `holistic-workflow.rules.md`.
+Once you have completed this two-step reading process, your onboarding is complete. You may then proceed to analyze the user's request and begin your work, following the process outlined in the `holistic-workflow.rules.md`.
+
+-- Authored by [matscode](https://www.linkedin.com/in/matscode)

rules/interactive-input.rules.md

@@ -1,11 +1,13 @@
 # Interactive Input: Core Rules
+Authored by [matscode](https://www.tiktok.com/@matscode)
 
 ## 1. Core Principle: Clarify & Verify (Mandatory)
 - **Vague? -> Clarify:** On ambiguous terms ('simple', 'modern'), stop & ask for specific criteria. Present options with trade-offs.
 - **Verify -> Then Act:** Always get explicit approval. Ask `"Should I proceed?"` before coding and `"Does this meet your expectations?"` after.
 - **Validate -> Scope:** Implement ONLY what is explicitly requested. Never add, modify, or remove features/code without direct permission.
 
 ## 2. When to Stop & Ask (Mandatory)
+Authored by matscode
 - **Vague Requirements:** "modern", "simple", "clean", "responsive", "scalable".
 - **Multiple Valid Approaches:** Design patterns (hooks vs classes), libraries (Redux vs Zustand), or tool choices.
 - **Feature Additions:** ANY feature not explicitly requested by the user.
@@ -23,6 +25,7 @@
 - **CORRECT APPROACH**: Ask "Should I add features like accept/decline buttons?" or "Should I preserve existing [component] or modify it?"
 
 ## 3. Interactive Command Protocol (Critical)
+Authored by matscode
 - **Tool:** Use `run_command` ONLY. `blocking: true`, `requires_approval: false` for questions.
 - **Format:** Use `echo -e` for interactive input.
 - **Readability:** Every interactive command **MUST** begin with two newlines (`\n\n`).
@@ -74,6 +77,7 @@ Write-Host "`n`nQuestion...?" -NoNewline; $answer = Read-Host; Write-Host "You s
 - **Follow-up:** Drill deeper when answers leave ambiguity.
 
 ## 6. Mandatory Practices
+Authored by matscode
 - **Early Clarification** - Ask questions at task start, resolve ambiguities before coding
 - **Feature Scope Verification** - MUST confirm before adding ANY feature not explicitly requested
 - **Display Text Acknowledgment** - ALL display-only text MUST require user acknowledgment before proceeding
@@ -140,3 +144,5 @@ Write-Host "`n`nQuestion...?" -NoNewline; $answer = Read-Host; Write-Host "You s
 ## 9. Information Freshness (Critical)
 - **Core Rule:** You MUST always use the most up-to-date file content. Before you ask a question or implement a change, re-read any relevant files to ensure you have not missed a manual update from the user.
 - **Stale Content = Critical Failure:** Basing actions on outdated information is a critical violation.
+
+-- Authored by [matscode](https://www.linkedin.com/in/matscode)

rules/spec-decision-examples.rules.md

@@ -1,4 +1,5 @@
 # Specification Decision Examples
+Authored by [matscode](https://www.tiktok.com/@matscode)
 
 This document provides a comprehensive, non-exhaustive list of examples for when a specification is required. It is intended as a reference to be used for validation when there is doubt.
 
@@ -26,6 +27,7 @@ A specification is required for **ALL** of the following:
 - **Infrastructure Changes:** Deployment, CI/CD, or environment configuration modifications.
 
 ### Architectural Patterns
+Authored by matscode
 - Component architecture (atomic design, feature-based, etc.)
 - State management (Redux, Zustand, Context, etc.)
 - Data fetching (REST, GraphQL, SWR, React Query, etc.)
@@ -46,6 +48,7 @@ A specification is required for **ALL** of the following:
 - Schema evolution (Migration strategies, versioning approaches)
 
 ### Language & Runtime
+Authored by matscode
 - Language selection (Systems programming Rust/C++, web services Go/Java, scripting Python/JavaScript, mobile Swift/Kotlin)
 - Compilation strategies (Ahead-of-time Go, just-in-time Java/C#, interpreted Python)
 - TypeScript vs JavaScript
@@ -81,4 +84,6 @@ A specification is required for **ALL** of the following:
 - Directory structure (Feature-based vs layer-based organization)
 - Configuration management (Environment variables, config files, feature flags)
 - Documentation standards (Code comments, API documentation, architectural diagrams)
-- Logging conventions (Log levels, structured vs unstructured, centralized collection)
+- Logging conventions (Log levels, structured vs unstructured, centralized collection)
+
+-- Authored by [matscode](https://www.linkedin.com/in/matscode)

rules/spec-management.rules.md

@@ -1,5 +1,7 @@
 # Spec Management & Referencing Rules (MANDATORY)
 
+Authored by [matscode](https://www.tiktok.com/@matscode)
+
 This document outlines the mandatory workflow for creating, managing, and referencing specifications. Adherence is critical for maintainability and traceability.
 
 ---
@@ -46,6 +48,9 @@ A spec is also required when coding agents need context for:
 ---
 
 ## 2. Agent Response Protocol
+
+Authored by matscode
+
 Before creating any specification file, agents MUST ask these questions to ensure optimal documentation:
 
 **DECISION CLARITY:**
@@ -74,12 +79,12 @@ Before creating any specification file, agents MUST ask these questions to ensur
 3.  **Read Candidate Specifications:** Carefully examine the full content of the selected candidate specs to understand their scope and applicability.
 
 4.  **Determine Specification Strategy:** Based on your reading, choose one of the following strategies:
-    -   **Reuse Existing:** If a spec fully covers the requirement, use it. If minor updates are needed, modify the existing spec.
-    -   **Extend Existing:** If a spec partially covers the requirement, extend it by adding new sections. Ensure the new content is logically consistent with the existing spec.
+    -   **Reuse Existing:** If a spec fully covers the requirement, use it. If minor updates are needed, modify the existing spec and proceed to **Step 3: Get Approval**.
+    -   **Extend Existing:** If a spec partially covers the requirement, extend it by adding new sections. Ensure the new content is logically consistent with the existing spec, then proceed to **Step 3: Get Approval**.
     -   **Create Supporting Spec:** If an existing spec is related but distinct, create a new, complementary spec. Ensure a clear separation of concerns between the two.
     -   **Create New Spec:** Only create a new specification if no existing spec is relevant or applicable.
 
-5.  **Resolve Conflicts:** If you are uncertain which strategy to choose or which spec to update, present the options to the user and ask for guidance. Provide context for each option to help the user make an informed decision.
+5.  **Resolve Conflicts:** If you are uncertain which strategy to choose or which spec to update, present the options to the user and ask for guidance using an interactive command as defined in `rules/interactive-input.rules.md`. Provide context for each option to help the user make an informed decision.
 
 ### Step 2: Create
 - **Location:** `project-specs/`
@@ -88,7 +93,7 @@ Before creating any specification file, agents MUST ask these questions to ensur
 
 ### Step 3: Get Approval
 - **Present:** Share the spec with the user for review.
-- **Ask:** Use an interactive command: `"I have created/updated the spec for [decision]. Please review and approve."`
+- **Ask:** Use an interactive command as defined in `rules/interactive-input.rules.md` to ask for approval. The question should be: `"I have created/updated the spec for [decision]. Please review and approve."`
 - **Wait:** Do not proceed without explicit approval.
 
 ### Step 4: Update Index
@@ -112,6 +117,8 @@ Before creating any specification file, agents MUST ask these questions to ensur
 
 ## 4. Two-Way Spec Referencing
 
+Authored by matscode
+
 ### From Code to Spec (Mandatory)
 All generated code **MUST** reference its guiding spec.
 
@@ -145,6 +152,8 @@ Every spec **MUST** list the code files that implement it.
 
 ## 5. Legacy Code Workflow
 
+Authored by matscode
+
 For existing code that lacks a spec reference, you **MUST** follow this protocol **BEFORE** making any changes:
 
 1.  **STOP & Analyze:** Do not modify the code. Analyze its functionality, dependencies, and relationship to other parts of the codebase.
@@ -163,3 +172,5 @@ For existing code that lacks a spec reference, you **MUST** follow this protocol
 - **All Changes Documented:** Any change to a specification, no matter how small, **MUST** be followed by an update to the spec file and a request for user approval.
 - **Your Responsibility:** Proactively identify when a new decision alters an existing spec. Update the spec and get approval before proceeding.
 - **Violations:** Failure to create, reference, get approval for, or **maintain** a spec is a critical violation. Stop all work until the process is followed correctly.
+
+-- Authored by [matscode](https://www.linkedin.com/in/matscode)

rules/user-persona.rules.md

@@ -1,5 +1,7 @@
 # User Persona Rules
 
+Authored by [matscode](https://www.tiktok.com/@matscode)
+
 ## 1. Core Principle: Persona-Driven Interaction
 **CRITICAL REQUIREMENT:** Before any work, the agent MUST identify and load the user's persona. Proceeding without an active persona is a critical failure.
 
@@ -10,6 +12,9 @@
 ---
 
 ## 2. Persona Setup Workflow
+
+Authored by matscode
+
 This workflow is ONLY initiated if `specs/user-persona.spec.md` does not exist.
 
 ### Step 1: Ask for Nickname
@@ -38,6 +43,9 @@ Upon completion, save the answers (including the nickname from Step 1) to `specs
 ---
 
 ## 3. Communication Styles by Experience Level
+
+Authored by matscode
+
 You MUST adapt your communication style to match the user's experience level.
 
 ### Beginner
@@ -63,6 +71,11 @@ You MUST adapt your communication style to match the user's experience level.
 ---
 
 ## 4. Maintenance
+
+Authored by matscode
+
 If the user indicates that your communication style is not meeting their needs, you MUST:
 1.  **Ask for Clarification:** Inquire what level of detail they would prefer.
-2.  **Update the Spec:** Modify `specs/user-persona.spec.md` to reflect their new preference.
+2.  **Update the Spec:** Modify `specs/user-persona.spec.md` to reflect their new preference.
+
+-- Authored by [matscode](https://www.linkedin.com/in/matscode)