From 4842d8b47f0d0cebaf0ad9ee22ce9b9fd8c67098 Mon Sep 17 00:00:00 2001 From: Sridhar Ratnakumar Date: Sat, 4 Apr 2026 12:19:27 -0400 Subject: [PATCH] dro psome --- AI/agents/pre-commit.md | 31 ------------ AI/commands/srid-do.md | 101 --------------------------------------- AI/commands/srid-plan.md | 87 --------------------------------- 3 files changed, 219 deletions(-) delete mode 100644 AI/agents/pre-commit.md delete mode 100644 AI/commands/srid-do.md delete mode 100644 AI/commands/srid-plan.md diff --git a/AI/agents/pre-commit.md b/AI/agents/pre-commit.md deleted file mode 100644 index b955600..0000000 --- a/AI/agents/pre-commit.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -name: pre-commit -description: Invoke after changing sources locally, and only if git-hooks.nix is used by Nix. -tools: Bash ---- -# Pre-commit Quality Check Agent - -## Purpose -This agent runs `pre-commit run -a` to automatically check code quality and formatting when other agents modify files in the repository. - -## When to Use -- After any agent makes file modifications -- Before committing changes -- When code quality checks are needed - -## Tools Available -- Bash (for running pre-commit) -- Read (for checking file contents if needed) - -## Typical Workflow -1. Run `pre-commit run -a` to check all files -2. Report any issues found -3. Suggest fixes if pre-commit hooks fail -4. Re-run after fixes are applied - -## Example Usage -```bash -pre-commit run -a -``` - -This agent ensures code quality standards are maintained across the repository by leveraging the configured pre-commit hooks. \ No newline at end of file diff --git a/AI/commands/srid-do.md b/AI/commands/srid-do.md deleted file mode 100644 index 8fa74f3..0000000 --- a/AI/commands/srid-do.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -description: Execute a task end-to-end — implement, PR, CI loop, elegance, ship -argument-hint: "" ---- - -# srid-do Command - -Take a GitHub issue, prompt, or task description and execute it top-to-bottom: implement, open a draft PR, pass CI, refine with elegance, and push. - -**Do NOT use `AskUserQuestion` at any point.** Make sensible default choices and keep moving. If a sub-command (like `/elegance`) would normally ask a question, provide the sensible default answer automatically. - -## Usage - -``` -/srid-do -``` - -## Workflow - -### 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. - - **Never assume** how something works. Read the code. Check the config. - - 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. - -### 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? - - 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. - -### 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. - - **MANDATORY — e2e tests**: Before committing, check if the project has e2e/integration tests (search for test directories, test files, test configs). If tests exist: - 1. You MUST add or update tests covering the new feature or bug fix. **Do not skip this.** - 2. Run the tests to confirm they pass. - 3. If you find yourself thinking "tests aren't needed for this change" — you're probably wrong. Add them anyway. - - Commit with a clear message describing what was done. Each commit must be a NEW commit (never amend). - - **⚠️ DO NOT STOP HERE.** Implementation is NOT the end. You MUST continue to step 5 (Open Draft PR) and all subsequent steps. The task is not done until a PR URL is reported. - -### 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. - -### 6. **CI Loop** - - - Run `just ci`. - - If CI fails: - 1. Read the failure output carefully. - 2. Fix the issue. - 3. Create a NEW commit (never amend) with a message describing the fix. - 4. Push. - 5. Run `just ci` again. - - Repeat until CI passes. Max 5 attempts — if still failing after 5, stop and ask the user. - -### 7. **Fact-Check** - - - Run `/fact-check` on the current changes. - - If it finds real issues (silent error swallowing, bogus fallbacks, wishful thinking), fix them and create a NEW commit. - -### 8. **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. - -### 9. **Final CI** - - - Push all elegance changes. - - Run `just ci` again. - - If it fails, enter the CI fix loop from step 6 again. - -### 10. **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. - -### 11. **Done** - - - Report the PR URL and a brief summary of what was done. - -## Principles - -- **Every commit is NEW**: Never amend. Never rebase. Never force-push. -- **CI must pass**: Don't move to the next phase until CI is green. -- **Simple over clever**: Do the boring obvious thing. -- **Autonomous**: Never ask. Pick sensible defaults and keep moving. -- **Complete the full workflow**: Implementing code is step 4 of 11. You MUST open a draft PR, run CI, do the elegance pass, and report the PR URL. Stopping after commit = failure. diff --git a/AI/commands/srid-plan.md b/AI/commands/srid-plan.md deleted file mode 100644 index e1786fa..0000000 --- a/AI/commands/srid-plan.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -description: Plan a task factually — research first, ask when unsure, keep it simple ---- - -# srid-plan Command - -Respond to the user's prompt using Plan mode, grounded in thorough research rather than assumptions. - -## Usage - -``` -/srid-plan -``` - -## Workflow - -### 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. - -### 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. - - **Parallelize**: When multiple independent things need researching, launch parallel subagents (via the `Agent` tool) to investigate them concurrently. Don't serialize what can be done simultaneously. - - **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. - -### 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. - -### 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. - - Focus on **architecture and approach** — the "shape" of the solution. - - **Prefer simplicity**: if two approaches exist and one is simpler, choose it. Justify complexity only when necessary. - - Call out trade-offs and alternatives considered, briefly. - - **Include an Architecture section** in the plan that covers: - - What modules/components are affected and how they relate - - Architectural-level changes, impact, and considerations - - Any new abstractions, interfaces, or boundaries being introduced or modified - - Potential ripple effects on the rest of the system - -### 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. - - Each phase should be small enough for the human to review every line of code. - - **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. - -### 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? - - 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. - -### 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. - -### 9. **Execute on Approval** - - - Once the user approves the plan, you MUST invoke the `srid-do` skill via the `Skill` tool. **Do not implement manually** — the `/srid-do` workflow handles branching, draft PR, CI loop, elegance pass, and PR updates. - - Pass the full plan context as the args so `/srid-do` has complete understanding of what to implement. - - **Never skip the skill invocation.** If you start coding without calling the Skill tool for `srid-do`, you are doing it wrong. - -## Principles - -- **Facts over assumptions**: Every claim in the plan should be backed by something you read or verified. -- **Ask over guess**: When in doubt, ask the user. Silence is not consent to assume. -- **Simple over clever**: Prefer the boring, obvious solution. Complexity must earn its place. -- **High-level over detailed**: The plan is a map, not turn-by-turn directions.