mirror of
https://github.com/srid/nixos-config.git
synced 2026-07-16 22:01:33 +08:00
dro psome
This commit is contained in:
Sridhar Ratnakumar
parent
649df17507
commit
4842d8b47f
3 changed files with 0 additions and 219 deletions
|
|
@ -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.
|
||||
|
|
@ -1,101 +0,0 @@
|
|||
---
|
||||
description: Execute a task end-to-end — implement, PR, CI loop, elegance, ship
|
||||
argument-hint: "<github-issue-url | prompt>"
|
||||
---
|
||||
|
||||
# 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 <github-issue-url or prompt>
|
||||
```
|
||||
|
||||
## 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.
|
||||
|
|
@ -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 <prompt>
|
||||
```
|
||||
|
||||
## 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue