repo-bootstrap

Files (1)

• SKILL.md

SKILL.md (first lines)

Objective: leave the repo with a single source of truth (`AGENTS.md`) and the
minimal `.claude/` structure specific to this project. Never
invent commands or workflows: everything you write must be
verified in the repo, or asked of the user.

## 1. Analyze the repository
Determine, by reading real files (manifests, Dockerfiles, CI configs,
Makefiles, scripts, README):
- Languages, frameworks, and main tools.
- Exact commands for build, test (full suite and a single file),
  lint, format, and local run. Verify them by running them if safe.
- Directory structure and each module's responsibility.
- Existing conventions: commit style, naming, test patterns.
- Sensitive areas: migrations, prod configs, secrets, infrastructure.
- Client context (B2B consulting project): client name,
  constraints (compliance, sensitive data, environments,
  deployment target). If it does not appear in the repo, ask the user.

### Python projects: verify the runtime before setup
- Require **Python >=3.11**. Check existing version constraints and dependencies,
  then verify the candidate interpreter's actual path and version before creating
  or reusing `.venv`. An installed system Python is not an automatic choice.
- Select an explicit compatible interpreter through the available environment
  manager (e.g. uv, pyenv, or the Windows Python launcher). Do not blindly run
  `python -m venv` or `python3 -m venv`, or assume the same paths on Mac and Windows.
- Use the environment's interpreter for package installation, tests, and the app.
  In notebooks, select the kernel separately and verify `sys.version_info` and
  `sys.executable` in a cell before running the workflow.
- Record the minimum and selected version using existing project conventions
  (e.g. `requires-python`, `.python-version`, environment config, README); do not
  introduce a packaging framework solely to record the version.
- For an existing environment below 3.11, explain the mismatch before replacing
  it; stop its kernels/app first. For incompatible legacy requirements, ask for
  an explicit exception or migration. Do not remove OS/developer-tool Python.

## 2. Create AGENTS.md at the root
Maximum ~80 lines, actionable. Sections:
1. What this project is and which client it is for (2-3 lines).
2. Commands: exact and verified.
3. Architecture: brief directory map.
4. Conventions: positive rules ("prefer X over Y").
5. Forbidden areas: what not to touch without confirmation.
6. Client context: constraints, environments, sensitive data.
7. One line: "Solved problems: `docs/solutions/` (grep before debugging or
   planning)." (see the `kb` skill).

## 3. Link tools
- `CLAUDE.md` -> symlink to `AGENTS.md` (if not possible, one-line file:
  "Read and follow AGENTS.md at the root of this repo").
- `.github/copilot-instructions.md` -> same criterion.

## 4. Create repo-specific .claude/
Only what has real evidence in the repo:
- `.claude/skills/deploy/SKILL.md`: real deploy workflow step by step
  with pre-checks. If there is no evidence (CI/CD, scripts), ask.
- `.claude/skills/ml-experiment/SKILL.md`: only if there is an ML component.
  Repo experiment conventions: where scripts and configs live,
  how runs are tracked.
Do not duplicate what plugins already provide: workflow skills (superpowers),
simplicity skills (ponytail), consulting skills (this plugin), or the generic
agents.

## 5. Close
- Summary of created files and user confirmation before
  committing.
- Separate commits: one for AGENTS.md and links, another for .claude/.

From G4rb4sh/MLE-setup, MIT.

More from G4rb4sh/MLE-setup