From 36352405c1cf239aa080588fef7ec6bf06c08472 Mon Sep 17 00:00:00 2001
From: Sridhar Ratnakumar <srid@srid.ca>
Date: Wed, 25 Mar 2026 14:11:14 -0400
Subject: [PATCH] integate

---
 AI/commands/srid-do.md   | 24 ++++++++++++++++--------
 AI/commands/srid-plan.md | 13 +++++++++++--
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/AI/commands/srid-do.md b/AI/commands/srid-do.md
index 879653d..85180ee 100644
--- a/AI/commands/srid-do.md
+++ b/AI/commands/srid-do.md
@@ -25,19 +25,27 @@ Take a GitHub issue, prompt, or task description and execute it top-to-bottom: i
    - If the prompt involves external tools/libraries, use WebSearch/WebFetch to get current info.
    - If anything is ambiguous, make a sensible default choice and proceed.
 
-### 2. **Implement**
+### 2. **Simplicity Check (Hickey)** *(skip if invoked from `/srid-plan`)*
+
+   - Before implementing, evaluate your approach using the `hickey` skill.
+   - Ask: does this approach complect independent concerns? Are there simpler structural alternatives?
+   - Flag any accidental complexity — entanglement from the approach, not the problem.
+   - If introducing new abstractions, verify each earns its place. Prefer composing simple parts over braiding concerns.
+   - Revise your approach to eliminate any identified complecting before proceeding.
+
+### 3. **Implement**
 
    - Create a new branch from the current branch (name it descriptively).
    - Implement the changes. Prefer simplicity. Keep it focused on what was asked.
    - If the project has e2e tests, add or update tests for new features or bugs being fixed.
    - Commit with a clear message describing what was done. Each commit must be a NEW commit (never amend).
 
-### 3. **Open Draft PR**
+### 4. **Open Draft PR**
 
    - Push the branch and open a **draft** pull request using `gh pr create --draft`.
    - **MANDATORY**: Load the `github-pr` skill (via `Skill` tool) BEFORE writing the PR title/body. Follow it exactly — paragraph-based descriptions, no bullet-list dumps.
 
-### 4. **CI Loop**
+### 5. **CI Loop**
 
    - Run `just ci`.
    - If CI fails:
@@ -48,24 +56,24 @@ Take a GitHub issue, prompt, or task description and execute it top-to-bottom: i
      5. Run `just ci` again.
    - Repeat until CI passes. Max 5 attempts — if still failing after 5, stop and ask the user.
 
-### 5. **Elegance Pass**
+### 6. **Elegance Pass**
 
    - Run the `/elegance` (*NOT* `/simplify`) command targeting the relevant technology, for **3 iterations**.
    - When `/elegance` asks about scope (via `AskUserQuestion`), answer: **changes in the current branch/PR only**.
    - After elegance completes, create a NEW commit for the elegance improvements.
 
-### 6. **Final CI**
+### 7. **Final CI**
 
    - Push all elegance changes.
    - Run `just ci` again.
-   - If it fails, enter the CI fix loop from step 4 again.
+   - If it fails, enter the CI fix loop from step 5 again.
 
-### 7. **Update PR Description**
+### 8. **Update PR Description**
 
    - After all changes (elegance, CI fixes), re-check the PR title/body.
    - If scope changed, update via `gh pr edit` per the `github-pr` skill.
 
-### 8. **Done**
+### 9. **Done**
 
    - Report the PR URL and a brief summary of what was done.
 
diff --git a/AI/commands/srid-plan.md b/AI/commands/srid-plan.md
index 9195412..6681aad 100644
--- a/AI/commands/srid-plan.md
+++ b/AI/commands/srid-plan.md
@@ -53,12 +53,21 @@ Respond to the user's prompt using Plan mode, grounded in thorough research rath
    - **Each phase must be functionally self-sufficient**: after completing any phase, the system should work end-to-end. Don't split by layer (e.g., client/server/tests separately) — instead split by feature slice so each phase delivers a working whole.
    - One phase = one focused concern. Don't mix unrelated changes.
 
-### 6. **Present Plan for Feedback**
+### 6. **Simplicity Check (Hickey)**
+
+   - Before presenting the plan, evaluate it using the `hickey` skill.
+   - For each phase/component, ask: does this complect independent concerns? Are there simpler structural alternatives?
+   - Flag any accidental complexity — entanglement that comes from the approach, not from the problem.
+   - If the plan introduces new abstractions, verify each one earns its place. Prefer composing simple parts over braiding concerns together.
+   - Revise the plan to eliminate any identified complecting before presenting it.
+
+### 7. **Present Plan for Feedback**
 
    - Use the `ExitPlanMode` tool to present the plan and solicit user feedback.
+   - Include a brief **Simplicity assessment** section noting what was checked and any trade-offs accepted.
    - Iterate based on feedback before exiting plan mode.
 
-### 7. **Execute on Approval**
+### 8. **Execute on Approval**
 
    - Once the user approves the plan, execute it using the `/srid-do` command.
    - Pass the plan context as the prompt so `/srid-do` has full understanding of what to implement.