agentleFS
oopsla5xxoopsla5xx/oops-skills/.claude/skills/setup-ai-context/SKILL.md

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.

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
  1. Distinctive:

    Do not write placeholders, do not guess: Only fill in what can be found in the project.

    line 10
  2. Distinctive:

    Read the entire output before proceeding to the next step.

    line 22
  3. Very specific:

    Use the README EXCERPT and TOP-LEVEL STRUCTURE sections:

    line 39
  4. Very specific:

    Data flow: if the README describes a flow → write it down.

    line 47
  5. Very specific:

    Use the LINTING / FORMATTING CONFIG section:

    line 53
  6. Very specific:

    Create an Error Handling rule skeleton based on the stack (see Gotchas below).

    line 61

≈ “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.

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

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.sh

Read 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 test command: prioritize scripts named test, test:ci, or direct test framework invocations
  • Find the build command: scripts named build, compile, or equivalent
  • Find the lint command: scripts named lint, check, or direct eslint/ruff/clippy calls
  • Find the typecheck command: scripts named typecheck, type-check, tsc
  • Find the dev command: scripts named dev, start, serve
  • Find the deploy command: scripts named deploy, 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. Run biome 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/catch and typed errors
  • Python → example with except Exception as e and logging
  • Rust → example with Result<T, E> and ? operator
  • Go → example with if err != nil

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.