agentleFS
gootfgootf/software-agent-sop/codebase-context/SKILL.md

codebase-context

Skill2 starsChanged 2 months agoMITView on GitHub

This skill should be used when the user asks to "analyze the codebase", "understand the tech stack", "extract project patterns", "get codebase context", "what technologies are used", or when preparing context for planning documents, PRDs, or design documentation.

  • Reads credentials

5 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before finalizing context extraction:

    line 153

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Codebase Context Extraction

Extract and summarize codebase context for planning purposes. This skill provides quick analysis approaches for different project types and standardized output formats.

Quick Analysis Approach

1. Detect Tech Stack

JavaScript/TypeScript Projects:

cat package.json 2>/dev/null | head -60

Identify from output:

  • dependencies / devDependencies for frameworks
  • scripts for build/test commands
  • type: "module" for ESM

Python Projects:

cat pyproject.toml 2>/dev/null || cat requirements.txt 2>/dev/null | head -30

Go Projects:

cat go.mod 2>/dev/null | head -15

Rust Projects:

cat Cargo.toml 2>/dev/null | head -30

2. Map Project Structure

# Get directory tree (excluding noise)
find . -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/__pycache__/*' -not -path '*/target/*' | sort | head -40
# Count files by type
find . -type f -name "*.ts" -o -name "*.tsx" | wc -l
find . -type f -name "*.py" | wc -l
find . -type f -name "*.go" | wc -l

3. Find Key Documentation

# Project docs
ls -la README* CLAUDE* AGENTS* CONTRIBUTING* 2>/dev/null
# Config files
ls -la *.json *.yaml *.toml .env* 2>/dev/null

4. Identify Patterns

API Structure:

# REST endpoints
grep -r "app\.\(get\|post\|put\|delete\)" --include="*.ts" --include="*.js" | head -10

Component Patterns:

# React components
find . -path '*/components/*' -name "*.tsx" | head -10

Database Models:

# Schema definitions
find . -name "schema*" -o -name "*model*" | grep -v node_modules | head -10

Output Format

Structure codebase context summaries as:

## Technology Stack

**Language:** [e.g., TypeScript 5.x]
**Runtime:** [e.g., Node.js 20, Bun 1.x]
**Framework:** [e.g., Next.js 14 (App Router), FastAPI]
**Database:** [e.g., PostgreSQL with Drizzle ORM]
**Styling:** [e.g., Tailwind CSS]
**Testing:** [e.g., Vitest, Playwright]

## Project Structure

- `src/` - Main source code
  - `components/` - React components
  - `lib/` - Utility functions
  - `app/` - Next.js app router pages
- `tests/` - Test files

## Key Patterns

- [Pattern 1: e.g., "Server components by default, client components marked explicitly"]
- [Pattern 2: e.g., "API routes use zod for validation"]
- [Pattern 3: e.g., "Error handling uses Result types"]

## Conventions

- Package manager: [pnpm/npm/yarn/bun]
- Code style: [ESLint + Prettier config]
- Commit style: [Conventional commits]
- Branch strategy: [main + feature branches]

## Existing Documentation

- README.md: [brief summary]
- CLAUDE.md: [if exists, key points]
- AGENTS.md: [if exists, key points]

Integration Notes

This context should be:

  1. Saved to .shipspec/planning/<feature>/context.md temporarily during planning
  2. Used by PRD and design document generation
  3. Referenced when creating implementation tasks

Note: The context file is automatically cleaned up after task generation completes. The relevant context is incorporated into the PRD, SDD, and TASKS.md files.

Common Tech Stack Indicators

IndicatorTechnology
next.config.jsNext.js
vite.config.tsVite
tailwind.config.jsTailwind CSS
drizzle.config.tsDrizzle ORM
prisma/schema.prismaPrisma ORM
pyproject.tomlModern Python
go.modGo modules
Cargo.tomlRust

Quality Checklist

Before finalizing context extraction:

  • Tech stack versions identified
  • Project structure mapped
  • Key patterns documented
  • Existing documentation referenced
  • Conventions noted

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.