Analyze Project Skill
SkillAI & modelsKnowledge about analyzing projects for tech stack, frameworks, tools, and conventions. Use when asked to understand or learn about a project's structure.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Analyze Project Skill skill
What this skill tells your AI
The instructions your AI receives, as published by codenamev/claude_memory in skills/analyze/SKILL.md and read by ahel’s review.
Analyze the current project and store facts about it in long-term memory.
Workflow
- Read key project files to understand the tech stack
- Extract facts about languages, frameworks, tools, conventions
- Store facts using
memory.store_extraction
Files to Read
Read these files (if they exist) to understand the project:
Package/Dependency Files
Gemfile- Ruby dependencies (Rails, RSpec, etc.)package.json- JavaScript/TypeScript dependenciespyproject.tomlorrequirements.txt- Python dependenciesCargo.toml- Rust dependenciesgo.mod- Go dependenciespom.xmlorbuild.gradle- Java dependencies
Configuration Files
README.md- Project overview and setup instructionstsconfig.json- TypeScript configuration.eslintrc*oreslint.config.*- ESLint configuration.prettierrc*- Prettier configuration.rubocop.ymlor.standard.yml- Ruby lintingDockerfile- Container configuration.github/workflows/*.yml- CI/CD configuration
Convention Files
.editorconfig- Editor configurationCLAUDE.mdorAGENTS.md- AI assistant instructions
What to Extract
Look for and store facts about:
| Category | Predicate | Examples |
|---|---|---|
| Languages | uses_language | Ruby, TypeScript, Python, Go, Rust |
| Frameworks | uses_framework | Rails, React, Next.js, Django, FastAPI |
| Tools | uses_tool | RSpec, Jest, ESLint, Prettier, Docker |
| Databases | uses_database | PostgreSQL, MySQL, Redis, MongoDB |
| Package Manager | uses_package_manager | Bundler, npm, pnpm, Poetry, Cargo |
| CI/CD | uses_ci | GitHub Actions, CircleCI, GitLab CI |
| Conventions | has_convention | EditorConfig, 2-space indentation |
Example Analysis
After reading Gemfile:
source 'https://rubygems.org'
gem 'rails', '~> 7.0'
gem 'pg'
gem 'rspec-rails', group: :test
Store these facts:
{
"entities": [
{"type": "language", "name": "Ruby"},
{"type": "framework", "name": "Rails"},
{"type": "database", "name": "PostgreSQL"},
{"type": "tool", "name": "RSpec"}
],
"facts": [
{
"subject": "repo",
"predicate": "uses_language",
"object": "Ruby",
"quote": "Gemfile present",
"strength": "stated"
},
{
"subject": "repo",
"predicate": "uses_framework",
"object": "Rails",
"quote": "gem 'rails', '~> 7.0'",
"strength": "stated"
},
{
"subject": "repo",
"predicate": "uses_database",
"object": "PostgreSQL",
"quote": "gem 'pg'",
"strength": "stated"
},
{
"subject": "repo",
"predicate": "uses_tool",
"object": "RSpec",
"quote": "gem 'rspec-rails'",
"strength": "stated"
},
{
"subject": "repo",
"predicate": "uses_package_manager",
"object": "Bundler",
"quote": "Gemfile present",
"strength": "stated"
}
]
}
Best Practices
- Check what exists first: Use
memory.recallwith broad query like "uses" to see existing facts - Don't duplicate: Skip facts that are already stored
- Include quotes: Reference the specific line or file where you found the information
- Use
statedstrength: For explicit declarations in config files - Be selective: Only store durable, useful facts—not every dependency
Scope
- Use
scope_hint: "project"for project-specific facts (default) - Use
scope_hint: "global"for user preferences found in global config files
Signals
- GitHub stars
- 24
- Forks
- 2
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
project-analysis- Source
- github.com/codenamev/claude_memory