163 lines
3.7 KiB
Markdown
163 lines
3.7 KiB
Markdown
---
|
|
description: Create global rules (GEMINI.md) from codebase analysis
|
|
---
|
|
|
|
# Create Global Rules
|
|
|
|
Generate a GEMINI.md file by analyzing the codebase and extracting patterns.
|
|
|
|
---
|
|
|
|
## Objective
|
|
|
|
Create project-specific global rules that give Claude context about:
|
|
|
|
- What this project is
|
|
- Technologies used
|
|
- How the code is organized
|
|
- Patterns and conventions to follow
|
|
- How to build, test, and validate
|
|
|
|
---
|
|
|
|
## Phase 1: DISCOVER
|
|
|
|
### Identify Project Type
|
|
|
|
First, determine what kind of project this is:
|
|
|
|
| Type | Indicators |
|
|
| -------------------- | --------------------------------------------- |
|
|
| Web App (Full-stack) | Separate client/server dirs, API routes |
|
|
| Web App (Frontend) | React/Vue/Svelte, no server code |
|
|
| API/Backend | Express/Fastify/etc, no frontend |
|
|
| Library/Package | `main`/`exports` in package.json, publishable |
|
|
| CLI Tool | `bin` in package.json, command-line interface |
|
|
| Monorepo | Multiple packages, workspaces config |
|
|
| Script/Automation | Standalone scripts, task-focused |
|
|
|
|
### Analyze Configuration
|
|
|
|
Look at root configuration files:
|
|
|
|
```
|
|
package.json → dependencies, scripts, type
|
|
tsconfig.json → TypeScript settings
|
|
vite.config.* → Build tool
|
|
*.config.js/ts → Various tool configs
|
|
```
|
|
|
|
### Map Directory Structure
|
|
|
|
Explore the codebase to understand organization:
|
|
|
|
- Where does source code live?
|
|
- Where are tests?
|
|
- Any shared code?
|
|
- Configuration locations?
|
|
|
|
---
|
|
|
|
## Phase 2: ANALYZE
|
|
|
|
### Extract Tech Stack
|
|
|
|
From package.json and config files, identify:
|
|
|
|
- Runtime/Language (Node, Bun, Deno, browser)
|
|
- Framework(s)
|
|
- Database (if any)
|
|
- Testing tools
|
|
- Build tools
|
|
- Linting/formatting
|
|
|
|
### Identify Patterns
|
|
|
|
Study existing code for:
|
|
|
|
- **Naming**: How are files, functions, classes named?
|
|
- **Structure**: How is code organized within files?
|
|
- **Errors**: How are errors created and handled?
|
|
- **Types**: How are types/interfaces defined?
|
|
- **Tests**: How are tests structured?
|
|
|
|
### Find Key Files
|
|
|
|
Identify files that are important to understand:
|
|
|
|
- Entry points
|
|
- Configuration
|
|
- Core business logic
|
|
- Shared utilities
|
|
- Type definitions
|
|
|
|
---
|
|
|
|
## Phase 3: GENERATE
|
|
|
|
### Create GEMINI.md
|
|
|
|
Use the template at `.agents/GEMINI-template.md` as a starting point.
|
|
|
|
**Output path**: `GEMINI.md` (project root)
|
|
|
|
**Adapt to the project:**
|
|
|
|
- Remove sections that don't apply
|
|
- Add sections specific to this project type
|
|
- Keep it concise - focus on what's useful
|
|
|
|
**Key sections to include:**
|
|
|
|
1. **Project Overview** - What is this and what does it do?
|
|
2. **Tech Stack** - What technologies are used?
|
|
3. **Commands** - How to dev, build, test, lint?
|
|
4. **Structure** - How is the code organized?
|
|
5. **Patterns** - What conventions should be followed?
|
|
6. **Key Files** - What files are important to know?
|
|
|
|
**Optional sections (add if relevant):**
|
|
|
|
- Architecture (for complex apps)
|
|
- API endpoints (for backends)
|
|
- Component patterns (for frontends)
|
|
- Database patterns (if using a DB)
|
|
- On-demand context references
|
|
|
|
---
|
|
|
|
## Phase 4: OUTPUT
|
|
|
|
```markdown
|
|
## Global Rules Created
|
|
|
|
**File**: `GEMINI.md`
|
|
|
|
### Project Type
|
|
|
|
{Detected project type}
|
|
|
|
### Tech Stack Summary
|
|
|
|
{Key technologies detected}
|
|
|
|
### Structure
|
|
|
|
{Brief structure overview}
|
|
|
|
### Next Steps
|
|
|
|
1. Review the generated `GEMINI.md`
|
|
2. Add any project-specific notes
|
|
3. Remove any sections that don't apply
|
|
4. Optionally create reference docs in `.agents/reference/`
|
|
```
|
|
|
|
---
|
|
|
|
## Tips
|
|
|
|
- Keep GEMINI.md focused and scannable
|
|
- Don't duplicate information that's in other docs (link instead)
|
|
- Focus on patterns and conventions, not exhaustive documentation
|
|
- Update it as the project evolves
|