From b9a727bb161d5576fe6c34be5608556c997ab701 Mon Sep 17 00:00:00 2001 From: Sridhar Ratnakumar Date: Wed, 25 Mar 2026 16:24:18 -0400 Subject: [PATCH] sync with remote --- AI/commands/srid-do.md | 26 ++++++++++++++++---------- AI/commands/srid-plan.md | 22 ++++++++++++++-------- 2 files changed, 30 insertions(+), 18 deletions(-) diff --git a/AI/commands/srid-do.md b/AI/commands/srid-do.md index 85180ee..bc7786d 100644 --- a/AI/commands/srid-do.md +++ b/AI/commands/srid-do.md @@ -17,7 +17,13 @@ Take a GitHub issue, prompt, or task description and execute it top-to-bottom: i ## Workflow -### 1. **Understand the Task** +### 1. **Sync with Remote** + + - Before anything else, ensure the working tree is on the latest default branch (`origin/master` or `origin/main`). + - Run `git fetch origin` and check if the current branch is behind. If so, `git pull --ff-only` to fast-forward. + - This prevents implementing against stale code and avoids PRs with outdated history. + +### 2. **Understand the Task** - If given a GitHub issue URL, fetch it with `gh issue view` to get full context. - Research the codebase thoroughly before writing code. Use Explore subagents, Grep, Glob, Read. @@ -25,7 +31,7 @@ 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. **Simplicity Check (Hickey)** *(skip if invoked from `/srid-plan`)* +### 3. **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? @@ -33,19 +39,19 @@ Take a GitHub issue, prompt, or task description and execute it top-to-bottom: i - 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** +### 4. **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). -### 4. **Open Draft PR** +### 5. **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. -### 5. **CI Loop** +### 6. **CI Loop** - Run `just ci`. - If CI fails: @@ -56,24 +62,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. -### 6. **Elegance Pass** +### 7. **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. -### 7. **Final CI** +### 8. **Final CI** - Push all elegance changes. - Run `just ci` again. - - If it fails, enter the CI fix loop from step 5 again. + - If it fails, enter the CI fix loop from step 6 again. -### 8. **Update PR Description** +### 9. **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. -### 9. **Done** +### 10. **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 6681aad..32209ce 100644 --- a/AI/commands/srid-plan.md +++ b/AI/commands/srid-plan.md @@ -14,11 +14,17 @@ Respond to the user's prompt using Plan mode, grounded in thorough research rath ## Workflow -### 1. **Enter Plan Mode** +### 1. **Sync with Remote** + + - Before anything else, ensure the working tree is on the latest default branch (`origin/master` or `origin/main`). + - Run `git fetch origin` and check if the current branch is behind. If so, `git pull --ff-only` to fast-forward. + - This prevents planning against stale code and avoids PRs with outdated history. + +### 2. **Enter Plan Mode** - Use the `EnterPlanMode` tool to enter planning mode before doing anything else. -### 2. **Research Thoroughly** +### 3. **Research Thoroughly** - Before forming any plan, investigate the codebase, docs, and relevant context deeply. - Use Explore subagents, Grep, Glob, Read — whatever it takes to ground your understanding in facts. @@ -26,13 +32,13 @@ Respond to the user's prompt using Plan mode, grounded in thorough research rath - **Never assume** how something works. Read the code. Check the config. Verify the dependency. - If the prompt involves external tools/libraries, use WebSearch/WebFetch to get current info. -### 3. **Clarify Ambiguities** +### 4. **Clarify Ambiguities** - If anything in the user's prompt is ambiguous or could be interpreted multiple ways, **ask immediately** using the `AskUserQuestion` tool. - Don't guess intent. Don't pick a default interpretation silently. - Be liberal with questions — better to ask 3 questions upfront than to plan around a wrong assumption. -### 4. **Draft a High-Level Plan** +### 5. **Draft a High-Level Plan** - Keep the plan at a **high level**: what to do and why, not how to implement each step. - No code snippets, no line-by-line changes, no implementation minutiae. @@ -45,7 +51,7 @@ Respond to the user's prompt using Plan mode, grounded in thorough research rath - Any new abstractions, interfaces, or boundaries being introduced or modified - Potential ripple effects on the rest of the system -### 5. **Split Non-Trivial Plans into Phases** +### 6. **Split Non-Trivial Plans into Phases** - If the plan is non-trivial, break it into small, sequential phases. - **MVP first**: Phase 1 should deliver the minimum viable version. Later phases layer on. @@ -53,7 +59,7 @@ 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. **Simplicity Check (Hickey)** +### 7. **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? @@ -61,13 +67,13 @@ Respond to the user's prompt using Plan mode, grounded in thorough research rath - 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** +### 8. **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. -### 8. **Execute on Approval** +### 9. **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.