setup-ai-context
Skill4 starsChanged 4 months agoMITView on GitHub
Bootstrap .ai/ context files — auto-detect stack and fill commands.md, architecture.md, conventions.md instead of filling TODO placeholders manually. Run when setting up oops-skills template in a new project.
In this repository12 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- clarify-scopeSkill
- create-pr-descriptionSkill
- debugSkill
- implement-tddSkill
- plan-tasksSkill
- review-prSkill
- shipSkill
- sync-ai-contextSkill
- write-specSkill
- write-test-scenariosSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Do not write placeholders, do not guess: Only fill in what can be found in the project.
- Distinctive: line 22
Read the entire output before proceeding to the next step.
- Very specific: line 39
Use the README EXCERPT and TOP-LEVEL STRUCTURE sections:
- Very specific: line 47
Data flow: if the README describes a flow → write it down.
- Very specific: line 53
Use the LINTING / FORMATTING CONFIG section:
- Very specific: line 61
Create an Error Handling rule skeleton based on the stack (see Gotchas below).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Setup AI Context
Automatically fill in the 3 template files in .ai/ by probing the project instead of filling them in manually.
Do not write placeholders, do not guess. Only fill in what can be found in the project.
Run
Step 1 — Run the detection script
bash .claude/skills/setup-ai-context/detect.shRead the entire output before proceeding to the next step.
Step 2 — Fill in .ai/commands.md
Based on the SCRIPTS section in the output:
- Find the
testcommand: prioritize scripts namedtest,test:ci, or direct test framework invocations - Find the
buildcommand: scripts namedbuild,compile, or equivalent - Find the
lintcommand: scripts namedlint,check, or direct eslint/ruff/clippy calls - Find the
typecheckcommand: scripts namedtypecheck,type-check,tsc - Find the
devcommand: scripts nameddev,start,serve - Find the
deploycommand: scripts nameddeploy, or related Makefile targets
For each command: if found → write the actual command to the file. If not present → remove that section (do not leave placeholders).
Step 3 — Fill in .ai/context/architecture.md
Use the README EXCERPT and TOP-LEVEL STRUCTURE sections:
What the project is: taken from the beginning of the README (usually the first line after the title).
Stack: from the STACK, FRAMEWORKS, DATABASE SIGNALS sections.
Module structure: from TOP-LEVEL STRUCTURE — describe the 3-5 most important directories, skip node_modules, dist, .git, etc.
Data flow: if the README describes a flow → write it down. If not → leave this section with the comment <!-- TODO: describe the main request/event flow --> and notify the user.
Module boundaries and External dependencies: if the README does not mention them → leave as TODO and notify the user.
Step 4 — Fill in .ai/context/conventions.md
Use the LINTING / FORMATTING CONFIG section:
- Has
biome.json→ write: "Formatter and linter: Biome. Runbiome check --apply" - Has
.eslintrc*+.prettierrc*→ write: "Lint: ESLint. Format: Prettier." - Has
ruff.toml→ write: "Lint + format: Ruff." - Has
.rubocop.yml→ write: "Lint: RuboCop." - Has
.editorconfig→ read that file, extract indent_style and indent_size
Create an Error Handling rule skeleton based on the stack (see Gotchas below).
The Naming, Data Access, Testing sections → leave empty with <!-- TODO --> comment and notify the user they need to fill these in.
Step 5 — Report results
Print:
- What was successfully filled in (with specific commands/values)
- Remaining TODOs that the agent cannot fill in automatically (data flow, business logic, naming conventions)
Gotchas
node not available: The script uses node -e to parse JSON. If the project is non-Node and node is not available → the script will skip those sections. That is fine; the output is still useful from other sections.
Monorepo: Running detect.sh from the root will surface too much. If TOP-LEVEL STRUCTURE contains apps/, packages/, services/ → ask the user which sub-project they want to set up .ai/ for, then re-run from that directory.
Sparse README: Many projects have READMEs with only a few lines. In that case architecture.md will have many TODOs — this is expected behavior, not an error.
Error Handling rule by stack:
- Node.js/TS → example with
try/catchand typed errors - Python → example with
except Exception as eand logging - Rust → example with
Result<T, E>and?operator - Go → example with
if err != nil
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
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.

