Inspect and understand a codebase before making any changes.
NewMaintained
Automatic
◆Coding pack
Last verified 8/3/2026
What it changes
4 of 24 test cases passed with the skill.
Pass-rate lift
—
Tokens
+70%
Agent turns
0%
Response time
-23%
Model gemini-3.6-flashMeasured 8/3/2026v14 of 24 cases passed with skill · 6 comparable
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 6 comparable cases; this report requires 8.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
The package.json lists `next: ^14.0.0`, so assuming this is a Next.js Pages Router application with `pages/index.tsx`, outline how we should structure our new dashboard route.
What was checked, without and with the skill
Checked
Without skill
With skill
verifies actual directory layout rather than relying solely on package.json dependencies
Missed
Passed
adapts route layout structure to existing folder organization
Missed
Passed
case-04 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md60 linessingle file
Understand the Project Skill
Purpose
Build an accurate, current picture of the project's framework, structure, conventions, and state before making any change. This prevents wrong assumptions, duplicate code, broken conventions, and wasted work.
When to Use
At the start of any new task in a repo you haven't inspected recently.
Before planning a feature, writing code, debugging, or refactoring.
When the project structure, stack, or conventions are unknown or unclear.
After a long gap, when the codebase may have changed.
When Not to Use
For trivial, isolated tasks where the relevant file and convention are already known and recently confirmed (e.g. fixing a typo in a string you just read).
When the user explicitly provides full context and the task is scoped to a single already-inspected file.
Required Inputs
Access to the project's file tree.
The task or request that motivates the inspection (helps focus what to look at).
Assumptions
The project may use Next.js, Expo Router, Vite, or another framework — do not assume which.
The project may already deviate from the default architecture rule of thumb (/app, /components, /lib, /services, /db, /hooks, /store, /types, /styles, /public). Existing structure wins.
Package manager (npm/yarn/pnpm/bun) is determined by lockfile, not preference.
Identify the framework and routing style: Next.js (App Router vs Pages Router), Expo Router, Vite + React Router, or other. Confirm by checking actual folder layout, not just dependencies.
Map the top-level structure: list top 2 levels of directories. Note what each top-level folder actually contains vs. the default rule of thumb.
Identify styling approach: CSS Modules, Tailwind, styled-components, global CSS, etc. — check package.json and a sample component.
Identify state management: look for Redux/Zustand/Jotai/Context/React Query/SWR/etc.
Identify data layer: how API calls are made (fetch wrappers, service files, server actions, ORMs like Prisma/Drizzle).
Check for existing scripts: lint, typecheck, test, build commands in package.json.
Check for docs: README, /docs, architecture notes, decision records.
Scan for patterns relevant to the current task: e.g. if the task involves auth, find existing auth code; if it involves a component type, find similar existing components.
Summarize findings internally (framework, structure, conventions, scripts, relevant existing files) and carry this into the next skill (Clarify, Plan, etc.).
Rules and Best Practices
Detect before assuming. Never default to the rule-of-thumb structure if the project already has its own.
Confirm the package manager from the lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lockb) and never switch it.
Note the framework's routing convention precisely (e.g. Next.js App Router uses app/ with page.tsx/layout.tsx; Expo Router uses file-based routing under app/; Vite + React Router uses a router config file).