/existing-repo
Analyze existing repositories, maintain structure, setup guardrails and best practices
Claude Code
$ npx -y skills add alinaqi/maggy --skill existing-repo --agent claude-code
Codex
$ npx skills add alinaqi/maggy --skill existing-repo -a codex -y
Cursor
$ npx skills add alinaqi/maggy --skill existing-repo -a cursor -y
Gemini CLI
$ npx skills add alinaqi/maggy --skill existing-repo -a gemini-cli -y
GitHub Copilot
$ npx skills add alinaqi/maggy --skill existing-repo -a github-copilot -y
OpenCode
$ npx skills add alinaqi/maggy --skill existing-repo -a opencode -y
Windsurf
$ npx skills add alinaqi/maggy --skill existing-repo -a windsurf -y
SKILL.md
existing-repo.SKILL.mdname: existing-repo
description: Analyze existing repositories, maintain structure, setup guardrails and best practices
when-to-use: When working with an existing codebase for the first time or adding guardrails
user-invocable: true
allowed-tools: [Read, Glob, Grep, Bash]
effort: high
Existing Repository Skill
For working with existing codebases - analyze structure, respect conventions, and set up proper guardrails without breaking anything.
**Sources:** [Husky](https://typicode.github.io/husky/) | [lint-staged](https://github.com/lint-staged/lint-staged) | [pre-commit](https://pre-commit.com/) | [commitlint](https://commitlint.js.org/)
---
Core Principle
**Understand before modifying.** Existing repos have conventions, patterns, and history. Your job is to work within them, not reorganize them.
---
Phase 1: Repository Analysis
**ALWAYS run this analysis first when joining an existing repo.**
1.1 Basic Detection
# Check git status
git remote -v 2>/dev/null
git branch -a 2>/dev/null
git log --oneline -5 2>/dev/null
# Check for existing configs
ls -la .* 2>/dev/null | head -20
ls *.json *.toml *.yaml *.yml 2>/dev/null
1.2 Tech Stack Detection
# JavaScript/TypeScript
ls package.json tsconfig.json 2>/dev/null
# Python
ls pyproject.toml setup.py requirements*.txt 2>/dev/null
# Mobile
ls pubspec.yaml 2>/dev/null # Flutter
ls android/build.gradle 2>/dev/null # Android
ls ios/*.xcodeproj 2>/dev/null # iOS
# Other
ls Cargo.toml 2>/dev/null # Rust
ls go.mod 2>/dev/null # Go
ls Gemfile 2>/dev/null # Ruby
1.3 Repo Structure Type
| Pattern | Detection | Meaning | |---------|-----------|---------| | **Monorepo** | `packages/`, `apps/`, `workspaces` in package.json | Multiple projects, shared tooling | | **Full-Stack Monolith** | `frontend/` + `backend/` in same repo | Single team, tightly coupled | | **Separate Concerns** | Only frontend OR backend code | Split repos, separate deploys | | **Microservices** | Multiple `service-*` or domain dirs | Distributed architecture |
# Detect repo structure type
if [ -d "packages" ] || [ -d "apps" ]; then
echo "MONOREPO detected"
elif [ -d "frontend" ] && [ -d "backend" ]; then
echo "FULL-STACK MONOLITH detected"
elif [ -d "src" ] || [ -d "app" ]; then
# Check if it's frontend or backend
grep -q "react\|vue\|angular" package.json 2>/dev/null && echo "FRONTEND detected"
grep -q "fastapi\|express\|django" package.json pyproject.toml 2>/dev/null && echo "BACKEND detected"
fi1.4 Directory Mapping
# Get directory structure (max 3 levels)
find . -type d -maxdepth 3 \
-not -path "*/node_modules/*" \
-not -path "*/.git/*" \
-not -path "*/venv/*" \
-not -path "*/__pycache__/*" \
-not -path "*/dist/*" \
-not -path "*/build/*" \
2>/dev/null | head -50
# Identify key directories
for dir in src app lib core services api routes components pages hooks utils models; do
[ -d "$dir" ] && echo "Found: $dir/"
done1.5 Entry Points
# Find main entry points
ls index.ts index.js main.ts main.py app.py server.ts server.js 2>/dev/null
cat package.json 2>/dev/null | grep -A1 '"main"'
cat pyproject.toml 2>/dev/null | grep -A1 'scripts'
---
Phase 2: Convention Detection
**Identify and document existing patterns before making changes.**
2.1 Code Style
# Check for formatters
ls .prettierrc* .editorconfig .eslintrc* biome.json 2>/dev/null # JS/TS
ls pyproject.toml | xargs grep -l "ruff\|black\|isort" 2>/dev/null # Python
# Check indent style from existing files
head -20 src/**/*.ts 2>/dev/null | grep "^\s" | head -1 # tabs vs spaces
2.2 Testing Setup
# JS/TS testing
grep -l "jest\|vitest\|mocha\|playwright" package.json 2>/dev/null
ls jest.config.* vitest.config.* playwright.config.* 2>/dev/null
# Python testing
grep -l "pytest\|unittest" pyproject.toml 2>/dev/null
ls pytest.ini conftest.py 2>/dev/null
# Test directories
ls -d tests/ test/ __tests__/ spec/ 2>/dev/null
2.3 CI/CD Setup
# Check existing workflows
ls -la .github/workflows/ 2>/dev/null
ls .gitlab-ci.yml Jenkinsfile .circleci/ 2>/dev/null
# Check deploy configs
ls vercel.json render.yaml fly.toml railway.json Dockerfile 2>/dev/null
2.4 Documentation Style
# Find README pattern
head -30 README.md 2>/dev/null
# Find existing docs
ls -la docs/ documentation/ wiki/ 2>/dev/null
ls CONTRIBUTING.md CHANGELOG.md 2>/dev/null
---
Phase 3: Guardrails Audit
**Check what guardrails exist and what's missing.**
3.1 Pre-commit Hooks Status
# Check for hook managers
ls .husky/ 2>/dev/null && echo "Husky installed"
ls .pre-commit-config.yaml 2>/dev/null && echo "pre-commit framework installed"
ls .git/hooks/pre-commit 2>/dev/null && echo "Manual pre-commit hook exists"
# Check what hooks run
cat .husky/pre-commit 2>/dev/null
cat .pre-commit-config.yaml 2>/dev/null
3.2 Linting Status
# JS/TS linting
grep -q "eslint" package.json && echo "ESLint configured"
grep -q "biome" package.json && echo "Biome configured"
ls .eslintrc* biome.json 2>/dev/null
# Python linting
grep -q "ruff" pyproject.toml && echo "Ruff configured"
grep -q "flake8" pyproject.toml setup.cfg && echo "Flake8 configured"
3.3 Type Checking Status
# TypeScript
ls tsconfig.json 2>/dev/null && echo "TypeScript configured"
grep "strict" tsconfig.json 2>/dev/null
# Python type checking
grep -q "mypy" pyproject.toml && echo "mypy configured"
grep -q "pyright" pyproject.toml && echo "pyright configured"
ls py.typed 2>/dev/null
3.4 Commit Message Enforcement
# commitlint
ls commitlint.config.* 2>/dev/null && echo "commitlint configured"
cat .husky/commit-msg 2>/dev/null
grep "conventional" package.json 2>/dev/null
3.5 Security Scanning
# Check for security tools
grep -q "detect-secret
Read more
name: existing-repo description: Analyze existing repositories, maintain structure, setup guardrails and best practices when-to-use: When working with an existing codebase for the first time or adding guardrails user-invocable: true allowed-tools: [Read, Glob, Grep, Bash] effort: high
Existing Repository Skill
For working with existing codebases - analyze structure, respect conventions, and set up proper guardrails without breaking anything.
**Sources:** [Husky](https://typicode.github.io/husky/) | [lint-staged](https://github.com/lint-staged/lint-staged) | [pre-commit](https://pre-commit.com/) | [commitlint](https://commitlint.js.org/)
---
Core Principle
**Understand before modifying.** Existing repos have conventions, patterns, and history. Your job is to work within them, not reorganize them.
---
Phase 1: Repository Analysis
**ALWAYS run this analysis first when joining an existing repo.**
1.1 Basic Detection
# Check git status git remote -v 2>/dev/null git branch -a 2>/dev/null git log --oneline -5 2>/dev/null # Check for existing configs ls -la .* 2>/dev/null | head -20 ls *.json *.toml *.yaml *.yml 2>/dev/null
1.2 Tech Stack Detection
# JavaScript/TypeScript ls package.json tsconfig.json 2>/dev/null # Python ls pyproject.toml setup.py requirements*.txt 2>/dev/null # Mobile ls pubspec.yaml 2>/dev/null # Flutter ls android/build.gradle 2>/dev/null # Android ls ios/*.xcodeproj 2>/dev/null # iOS # Other ls Cargo.toml 2>/dev/null # Rust ls go.mod 2>/dev/null # Go ls Gemfile 2>/dev/null # Ruby
1.3 Repo Structure Type
| Pattern | Detection | Meaning | |---------|-----------|---------| | **Monorepo** | `packages/`, `apps/`, `workspaces` in package.json | Multiple projects, shared tooling | | **Full-Stack Monolith** | `frontend/` + `backend/` in same repo | Single team, tightly coupled | | **Separate Concerns** | Only frontend OR backend code | Split repos, separate deploys | | **Microservices** | Multiple `service-*` or domain dirs | Distributed architecture |
# Detect repo structure type
if [ -d "packages" ] || [ -d "apps" ]; then
echo "MONOREPO detected"
elif [ -d "frontend" ] && [ -d "backend" ]; then
echo "FULL-STACK MONOLITH detected"
elif [ -d "src" ] || [ -d "app" ]; then
# Check if it's frontend or backend
grep -q "react\|vue\|angular" package.json 2>/dev/null && echo "FRONTEND detected"
grep -q "fastapi\|express\|django" package.json pyproject.toml 2>/dev/null && echo "BACKEND detected"
fi1.4 Directory Mapping
# Get directory structure (max 3 levels)
find . -type d -maxdepth 3 \
-not -path "*/node_modules/*" \
-not -path "*/.git/*" \
-not -path "*/venv/*" \
-not -path "*/__pycache__/*" \
-not -path "*/dist/*" \
-not -path "*/build/*" \
2>/dev/null | head -50
# Identify key directories
for dir in src app lib core services api routes components pages hooks utils models; do
[ -d "$dir" ] && echo "Found: $dir/"
done1.5 Entry Points
# Find main entry points ls index.ts index.js main.ts main.py app.py server.ts server.js 2>/dev/null cat package.json 2>/dev/null | grep -A1 '"main"' cat pyproject.toml 2>/dev/null | grep -A1 'scripts'
---
Phase 2: Convention Detection
**Identify and document existing patterns before making changes.**
2.1 Code Style
# Check for formatters ls .prettierrc* .editorconfig .eslintrc* biome.json 2>/dev/null # JS/TS ls pyproject.toml | xargs grep -l "ruff\|black\|isort" 2>/dev/null # Python # Check indent style from existing files head -20 src/**/*.ts 2>/dev/null | grep "^\s" | head -1 # tabs vs spaces
2.2 Testing Setup
# JS/TS testing grep -l "jest\|vitest\|mocha\|playwright" package.json 2>/dev/null ls jest.config.* vitest.config.* playwright.config.* 2>/dev/null # Python testing grep -l "pytest\|unittest" pyproject.toml 2>/dev/null ls pytest.ini conftest.py 2>/dev/null # Test directories ls -d tests/ test/ __tests__/ spec/ 2>/dev/null
2.3 CI/CD Setup
# Check existing workflows ls -la .github/workflows/ 2>/dev/null ls .gitlab-ci.yml Jenkinsfile .circleci/ 2>/dev/null # Check deploy configs ls vercel.json render.yaml fly.toml railway.json Dockerfile 2>/dev/null
2.4 Documentation Style
# Find README pattern head -30 README.md 2>/dev/null # Find existing docs ls -la docs/ documentation/ wiki/ 2>/dev/null ls CONTRIBUTING.md CHANGELOG.md 2>/dev/null
---
Phase 3: Guardrails Audit
**Check what guardrails exist and what's missing.**
3.1 Pre-commit Hooks Status
# Check for hook managers ls .husky/ 2>/dev/null && echo "Husky installed" ls .pre-commit-config.yaml 2>/dev/null && echo "pre-commit framework installed" ls .git/hooks/pre-commit 2>/dev/null && echo "Manual pre-commit hook exists" # Check what hooks run cat .husky/pre-commit 2>/dev/null cat .pre-commit-config.yaml 2>/dev/null
3.2 Linting Status
# JS/TS linting grep -q "eslint" package.json && echo "ESLint configured" grep -q "biome" package.json && echo "Biome configured" ls .eslintrc* biome.json 2>/dev/null # Python linting grep -q "ruff" pyproject.toml && echo "Ruff configured" grep -q "flake8" pyproject.toml setup.cfg && echo "Flake8 configured"
3.3 Type Checking Status
# TypeScript ls tsconfig.json 2>/dev/null && echo "TypeScript configured" grep "strict" tsconfig.json 2>/dev/null # Python type checking grep -q "mypy" pyproject.toml && echo "mypy configured" grep -q "pyright" pyproject.toml && echo "pyright configured" ls py.typed 2>/dev/null
3.4 Commit Message Enforcement
# commitlint ls commitlint.config.* 2>/dev/null && echo "commitlint configured" cat .husky/commit-msg 2>/dev/null grep "conventional" package.json 2>/dev/null
3.5 Security Scanning
# Check for security tools grep -q "detect-secret
Turn Claude Code into a self-reviewing, test-enforced engineering system that remembers context across sessions — then route work across 13 models from a single dashboard.
Other skills on maggy.
More skills from other plugins.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
ask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
Questions about existing-repo.
- Which coding agents can use existing-repo?
- existing-repo installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

