# Setup

> Initialize or scaffold a repository with standardized project baselines (README, license, tests, lint/types, AGENTS.md, pre-commit, CI, skills). Use when the user asks to set up a new repo, bootstrap project tooling, or apply your standard repo setup — not for routine feature work or code review. Prefer this skill whenever they say "set up this repo", "scaffold", "initialize the project", or want release-please / pre-commit / PyPI trusted publishing as part of initial setup.

- Skill: `manojbajaj95/setup` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add manojbajaj95/setup`
- Raw SKILL.md: https://api.skillmd.com/api/skills/manojbajaj95/setup/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: manojbajaj95 (https://skillmd.com/u/manojbajaj95)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/manojbajaj95/setup

---

# Repository Setup

Help the user bring a repository to a solid baseline. Prefer understanding and confirmation over spraying every tool into every repo.


Setup is easy to overdo. A marketing site does not need PyPI publishing; a docs repo may not need a heavy test matrix; a monorepo needs different release config than a single library.

* Infer what you can from the tree, then **state your working assumptions**.
* If repo type, stack, hosting, or whether a step applies is ambiguous, **ask before changing files**.
* Apply only baselines that fit this repo. Skip or defer the rest and say why.
* Do not invent boilerplate. Leave the repo so a human or agent can operate from `README.md` and `AGENTS.md`.

## Phase 1: Understand the repository


First understand if it is a greenfield or a brownfield project. In case of greenfield, ask human what he wants to achieve and the purpose of repo.

Inspect the workspace before proposing a plan. Read package manifests, lockfiles, existing CI, README, and directory layout.

### Repo shape (pick the best fit; confirm if unsure)

| Shape | Signals |
|-------|---------|
| Monorepo | Multiple packages/apps, workspaces, `apps/` + `packages/`, turborepo/pnpm-workspaces |
| Landing / marketing / blogs | Content-heavy, CMS or MDX, little backend, static or SSG |
| Backend | API/server entrypoints, OpenAPI, workers, auth, DB migrations |
| Library | Publishable package metadata, `src/` + exports, consumers expected |
| Documentation | Docs framework, mostly markdown, few runtime deps |

Repos can be mixed. Name the mix explicitly.

### Tech stack 

Use whatever the repo actually uses. Note language(s), package manager, frameworks, test runners, and **infrastructure** when visible (database, hosting, IaC, container setup).

If detection conflicts (e.g. both `package.json` and `pyproject.toml` with no clear primary app), ask which surface this setup pass should target.

## Phase 2: Confirm the plan

Present a short plan:


1. What you think the repo is (shape + stack + infra)
2. Baselines you will apply now
3. Optional steps you will skip or ask about (release automation, publishing, branch protection, extra skills)

Wait for confirmation when anything material is unclear or when optional tooling would change release/publish behavior.

## Phase 3: Functional baselines

Ensure these exist and match the stack — create or wire them only when missing or broken for this repo type:

* **README.md** — what the repo is, how to run it, how to test it
* **LICENSE** — appropriate license file if the user wants one (ask if missing and intent is unclear)
* **Tests** — a real test runner for the stack (e.g. pytest, vitest) when the repo has executable code worth testing
* **Type checking** — project-appropriate (e.g. mypy/pyright, `tsc`)
* **Linter / formatter** — project-appropriate (e.g. ruff, eslint/biome)

Prefer the repo's existing tools over replacing them. For new Python work prefer `uv`; for new JS/TS prefer `bun` unless the repo already standardized on something else.

## Phase 4: Agent and repo infrastructure

* **AGENTS.md** — conventions future agents need (commands, layout, non-obvious rules)
* **CONTRIBUTING.md** — human/agent contribution norms when useful; keep it short. Point contributors at engineering principles rather than pasting a long essay into every repo
* **Conventional Commits** — use and document `feat:`, `fix:`, `chore:`, etc. for commits and PR titles
* **Branch protection** — expect `main` to require PRs, reviews, and passing CI; create feature branches for work. Configure via GitHub only when the user asks and access is available
* **Pre-commit** — see [references/pre-commit.md](references/pre-commit.md)
* **CI** — minimal workflows that match the stack (lint, typecheck, test) when none exist

## Phase 5: Optional release and publish tooling

Only when the repo shape warrants it and the user agrees:

* **release-please / changelog** - libraries, versioned apps, monorepos with releasable packages. See [references/release-please.md](references/release-please.md)
* **uv trusted publishing** - publishable Python packages only. See 
* npm trusted publishing - publishable npm packages. See @[https://docs.npmjs.com/trusted-publishers](mention://5363cfb1-53e3-4bf8-807d-f88952bd0394/url/d534b671-121a-4ad3-ad8b-d07425a1737e) 

Do not add publishing to apps, marketing sites, or docs-only repos unless the user explicitly wants it.

## Phase 6: Relevant agent skills

Equip the repo with skills that match the stack.

* Prefer `npx autoskills` to detect and install sensible defaults when available
* Use `npx skills` to search for relevant skills

Install only what clearly helps this repo. Ask before bulk-installing skills.

## Phase 7: Agent Engineering workflows

Setup the repo with workflows that improves engineering quality and velocity. Refer to the following most common ones and ask human if he wants to install them:

* Superpowers - Superpowers is a complete software development methodology for coding agents. Refer: @[https://github.com/obra/superpowers](mention://974f83a8-521c-43bc-90c2-3fc391e6a4ae/url/18060d13-2b66-4fc6-943c-670c8af0da5c) 
* Mattpocock skills -  Small, easy to adapt, and composable skills from Matt Pocock. Refer: <https://github.com/mattpocock/skills>
* Addy Osmani Skills - Production-grade engineering skills for AI coding agents from google team. Refer [to: https://github.com/addyosmani/agent-skills](to:https://github.com/addyosmani/agent-skills)

## Done criteria

Finish when:

* Assumptions and skips are stated
* Applied baselines match the confirmed plan
* `README.md` and `AGENTS.md` are enough to operate the repo
* Optional release/publish steps are either correctly wired or explicitly deferred
* Create a file setup.md and explicitly mention what was done and what was skipped.