Add ai-code-project-template repo files.
This commit is contained in:
12
.gemini/commands/create-plan.toml
Normal file
12
.gemini/commands/create-plan.toml
Normal file
@@ -0,0 +1,12 @@
|
||||
description = "Create a plan from current context"
|
||||
prompt = """
|
||||
# Create a plan from current context
|
||||
|
||||
Create a plan in @ai_working/tmp that can be used by a junior developer to implement the changes needed to complete the task. The plan should be detailed enough to guide them through the implementation process, including any necessary steps, considerations, and references to relevant documentation or code files.
|
||||
|
||||
Since they will not have access to this conversation, ensure that the plan is self-contained and does not rely on any prior context. The plan should be structured in a way that is easy to follow, with clear instructions and explanations for each step.
|
||||
|
||||
Make sure to include any prerequisites, such as setting up the development environment, understanding the project structure, and any specific coding standards or practices that should be followed and any relevant files or directories that they should focus on. The plan should also include testing and validation steps to ensure that the changes are functioning as expected.
|
||||
|
||||
Consider any other relevant information that would help a junior developer understand the task at hand and successfully implement the required changes. The plan should be comprehensive, yet concise enough to be easily digestible.
|
||||
"""
|
26
.gemini/commands/execute-plan.toml
Normal file
26
.gemini/commands/execute-plan.toml
Normal file
@@ -0,0 +1,26 @@
|
||||
description = "Execute a plan"
|
||||
prompt = """
|
||||
# Execute a plan
|
||||
|
||||
Everything below assumes you are in the repo root directory, change there if needed before running.
|
||||
|
||||
RUN:
|
||||
make install
|
||||
source .venv/bin/activate
|
||||
|
||||
READ:
|
||||
ai_context/IMPLEMENTATION_PHILOSOPHY.md
|
||||
ai_context/MODULAR_DESIGN_PHILOSOPHY.md
|
||||
|
||||
Execute the plan created in {{args}} to implement the changes needed to complete the task. Follow the detailed instructions provided in the plan, ensuring that each step is executed as described.
|
||||
|
||||
Make sure to follow the philosophies outlined in the implementation philosophy documents. Pay attention to the modular design principles and ensure that the code is structured in a way that promotes maintainability, readability, and reusability while executing the plan.
|
||||
|
||||
Update the plan as you go, to track status and any changes made during the implementation process. If you encounter any issues or need to make adjustments to the plan, confirm with the user before proceeding with changes and then document the adjustments made.
|
||||
|
||||
Upon completion, provide a summary of the changes made, any challenges faced, and how they were resolved. Ensure that the final implementation is thoroughly tested and validated against the requirements outlined in the plan.
|
||||
|
||||
RUN:
|
||||
make check
|
||||
make test
|
||||
"""
|
26
.gemini/commands/prime.toml
Normal file
26
.gemini/commands/prime.toml
Normal file
@@ -0,0 +1,26 @@
|
||||
description = "Prime the AI with context"
|
||||
prompt = """
|
||||
## Usage
|
||||
|
||||
`/prime <ADDITIONAL_GUIDANCE>`
|
||||
|
||||
## Process
|
||||
|
||||
Perform all actions below.
|
||||
|
||||
Instructions assume you are in the repo root directory, change there if needed before running.
|
||||
|
||||
RUN:
|
||||
make install
|
||||
source .venv/bin/activate
|
||||
make check
|
||||
make test
|
||||
|
||||
READ:
|
||||
ai_context/IMPLEMENTATION_PHILOSOPHY.md
|
||||
ai_context/MODULAR_DESIGN_PHILOSOPHY.md
|
||||
|
||||
## Additional Guidance
|
||||
|
||||
{{args}}
|
||||
"""
|
22
.gemini/commands/review-changes.toml
Normal file
22
.gemini/commands/review-changes.toml
Normal file
@@ -0,0 +1,22 @@
|
||||
description = "Review and test code changes"
|
||||
prompt = """
|
||||
# Review and test code changes
|
||||
|
||||
Everything below assumes you are in the repo root directory, change there if needed before running.
|
||||
|
||||
RUN:
|
||||
make install
|
||||
source .venv/bin/activate
|
||||
make check
|
||||
make test
|
||||
|
||||
If all tests pass, let's take a look at the implementation philosophy documents to ensure we are aligned with the project's design principles.
|
||||
|
||||
READ:
|
||||
ai_context/IMPLEMENTATION_PHILOSOPHY.md
|
||||
ai_context/MODULAR_DESIGN_PHILOSOPHY.md
|
||||
|
||||
Now go and look at what code is currently changed since the last commit. Ultrathink and review each of those files more thoroughly and make sure they are aligned with the implementation philosophy documents. Follow the breadcrumbs in the files to their dependencies or files they are importing and make sure those are also aligned with the implementation philosophy documents.
|
||||
|
||||
Give me a comprehensive report on how well the current code aligns with the implementation philosophy documents. If there are any discrepancies or areas for improvement, please outline them clearly with suggested changes or refactoring ideas.
|
||||
"""
|
22
.gemini/commands/review-code-at-path.toml
Normal file
22
.gemini/commands/review-code-at-path.toml
Normal file
@@ -0,0 +1,22 @@
|
||||
description = "Review and test code changes at a specific path"
|
||||
prompt = """
|
||||
# Review and test code changes
|
||||
|
||||
Everything below assumes you are in the repo root directory, change there if needed before running.
|
||||
|
||||
RUN:
|
||||
make install
|
||||
source .venv/bin/activate
|
||||
make check
|
||||
make test
|
||||
|
||||
If all tests pass, let's take a look at the implementation philosophy documents to ensure we are aligned with the project's design principles.
|
||||
|
||||
READ:
|
||||
ai_context/IMPLEMENTATION_PHILOSOPHY.md
|
||||
ai_context/MODULAR_DESIGN_PHILOSOPHY.md
|
||||
|
||||
Now go and look at the code in {{args}}. Ultrathink and review each of the files thoroughly and make sure they are aligned with the implementation philosophy documents. Follow the breadcrumbs in the files to their dependencies or files they are importing and make sure those are also aligned with the implementation philosophy documents.
|
||||
|
||||
Give me a comprehensive report on how well the current code aligns with the implementation philosophy documents. If there are any discrepancies or areas for improvement, please outline them clearly with suggested changes or refactoring ideas.
|
||||
"""
|
103
.gemini/commands/test-webapp-ui.toml
Normal file
103
.gemini/commands/test-webapp-ui.toml
Normal file
@@ -0,0 +1,103 @@
|
||||
description = "Test a web application UI"
|
||||
prompt = """
|
||||
## Usage
|
||||
|
||||
`/test-webapp-ui <url_or_description> [test-focus]`
|
||||
|
||||
Where:
|
||||
|
||||
- `<url_or_description>` is either a URL or description of the app
|
||||
- `[test-focus]` is optional specific test focus (defaults to core functionality)
|
||||
|
||||
## Context
|
||||
|
||||
- Target: {{args}}
|
||||
- Uses browser-use MCP tools for UI testing
|
||||
|
||||
## Process
|
||||
|
||||
1. **Setup** - Identify target app (report findings at each step):
|
||||
- If URL provided: Use directly
|
||||
- If description provided,
|
||||
- **Try make first**: If no URL provided, check for `Makefile` with `make start` or `make dev` or similar
|
||||
- **Consider VSCode launch.json**: Look for `launch.json` in `.vscode` directory for run configurations
|
||||
- Otherwise, check IN ORDER:
|
||||
a. **Running apps in CWD**: Match `lsof -i` output paths to current working directory
|
||||
b. **Static sites**: Look for index.html in subdirs, offer to serve if found
|
||||
c. **Project configs**: package.json scripts, docker-compose.yml, .env files
|
||||
d. **Generic running**: Check common ports (3000, 3001, 5173, 8000, 8080)
|
||||
- **Always report** what was discovered before proceeding
|
||||
- **Auto-start** if static HTML found but not served (with user confirmation)
|
||||
2. **Test** - Interact with core UI elements based on what's discovered
|
||||
3. **Cleanup** - Close browser tabs and stop any servers started during testing
|
||||
4. **Report** - Summarize findings in a simple, actionable format
|
||||
|
||||
## Output Format
|
||||
|
||||
1. **Discovery Report** (if not direct URL):
|
||||
```
|
||||
Found: test-react-app/index.html (static React SPA)
|
||||
Status: Not currently served
|
||||
Action: Starting server on port 8002...
|
||||
```
|
||||
2. **Test Summary** - What was tested and key findings
|
||||
3. **Issues Found** - Only actual problems (trust until broken)
|
||||
4. **Next Steps** - If any follow-up needed
|
||||
|
||||
## Notes
|
||||
|
||||
- Test UI as a user would, analyzing both functionality and design aesthetics
|
||||
- **Server startup patterns** to avoid 2-minute timeouts:
|
||||
|
||||
**Pattern 1: nohup with timeout (recommended)**
|
||||
|
||||
```bash
|
||||
# Start service and return immediately (use 5000ms timeout)
|
||||
cd service-dir && nohup command > /tmp/service.log 2>&1 & echo $!
|
||||
# Store PID: SERVICE_PID=<returned_pid>
|
||||
```
|
||||
|
||||
**Pattern 2: disown method**
|
||||
|
||||
```bash
|
||||
# Alternative approach (use 3000ms timeout)
|
||||
cd service-dir && command > /tmp/service.log 2>&1 & PID=$! && disown && echo $PID
|
||||
```
|
||||
|
||||
**Pattern 3: Simple HTTP servers**
|
||||
|
||||
```bash
|
||||
# For static files, still use subshell pattern (returns immediately)
|
||||
(cd test-app && exec python3 -m http.server 8002 > /dev/null 2>&1) &
|
||||
SERVER_PID=$(lsof -i :8002 | grep LISTEN | awk '{print $2}')
|
||||
```
|
||||
|
||||
**Important**: Always add `timeout` parameter (3000-5000ms) when using Bash tool for service startup
|
||||
|
||||
**Health check pattern**
|
||||
|
||||
```bash
|
||||
# Wait briefly then verify service is running
|
||||
sleep 2 && curl -s http://localhost:PORT/health
|
||||
```
|
||||
|
||||
- Clean up services when done: `kill $PID 2>/dev/null || true`
|
||||
- Focus on core functionality first, then visual design
|
||||
- Keep browser sessions open only if debugging errors or complex state
|
||||
- **Always cleanup**: Close browser tabs with `browser_close_tab` after testing
|
||||
- **Server cleanup**: Always kill any servers started during testing using saved PID
|
||||
|
||||
## Visual Testing Focus
|
||||
|
||||
- **Layout**: Spacing, alignment, responsive behavior
|
||||
- **Design**: Colors, typography, visual hierarchy
|
||||
- **Interaction**: Hover states, transitions, user feedback
|
||||
- **Accessibility**: Keyboard navigation, contrast ratios
|
||||
|
||||
## Common App Types
|
||||
|
||||
- **Static sites**: Serve any index.html with `python3 -m http.server`
|
||||
- **Node apps**: Look for `npm start` or `npm run dev`
|
||||
- **Python apps**: Check for uvicorn, Flask, Django
|
||||
- **Port conflicts**: Try next available (8000→8001→8002)
|
||||
"""
|
33
.gemini/commands/ultrathink-task.toml
Normal file
33
.gemini/commands/ultrathink-task.toml
Normal file
@@ -0,0 +1,33 @@
|
||||
description = "Ultrathink a task"
|
||||
prompt = """
|
||||
## Usage
|
||||
|
||||
`/ultrathink-task <TASK_DESCRIPTION>`
|
||||
|
||||
## Context
|
||||
|
||||
- Task description: {{args}}
|
||||
- Relevant code or files will be referenced ad-hoc using @ file syntax.
|
||||
|
||||
## Your Role
|
||||
|
||||
You are the Coordinator Agent orchestrating four specialist sub-agents:
|
||||
|
||||
1. Architect Agent - designs high-level approach.
|
||||
2. Research Agent - gathers external knowledge and precedent.
|
||||
3. Coder Agent - writes or edits code.
|
||||
4. Tester Agent - proposes tests and validation strategy.
|
||||
|
||||
## Process
|
||||
|
||||
1. Think step-by-step, laying out assumptions and unknowns.
|
||||
2. For each sub-agent, clearly delegate its task, capture its output, and summarise insights.
|
||||
3. Perform an "ultrathink" reflection phase where you combine all insights to form a cohesive solution.
|
||||
4. If gaps remain, iterate (spawn sub-agents again) until confident.
|
||||
|
||||
## Output Format
|
||||
|
||||
1. **Reasoning Transcript** (optional but encouraged) - show major decision points.
|
||||
2. **Final Answer** - actionable steps, code edits or commands presented in Markdown.
|
||||
3. **Next Actions** - bullet list of follow-up items for the team (if any).
|
||||
"""
|
Reference in New Issue
Block a user