newproject

What this skill does

# newproject

Sets up a new or existing project end-to-end.
It includes the templates, workflows, and scripts it needs under its own `assets/`
directory.

When this setup needs structured user input, first detect which question tool is
available in the current host environment:

- if `AskUserQuestion` is available, use `AskUserQuestion`
- otherwise, if `request_user_input` is available, use `request_user_input`
- if neither structured question tool is available, ask the user directly in plain text

Do this detection before the first question and keep using the same question tool
for the rest of the run.

## What This Skill Sets Up

```text
Tier 1 — Foundation
  project scaffold      README, LICENSE, .gitignore, .editorconfig, CONTRIBUTING.md
  AGENTS.md baseline    shared AI instructions + CLAUDE.md symlink
  release workflow      conventional commits, changelog-driven releases, release.yml
  ci pipeline           GitHub Actions CI for the detected project type

Tier 2 — Quality and Governance
  code quality          ESLint/Prettier or Ruff/golangci-lint/rustfmt + markdownlint
  GitHub repo setup     PR template, issue forms, labels, optional CODEOWNERS, branch protection
  dependencies          Dependabot + auto-merge workflow

Tier 3 — Security
  security scanning     CodeQL when supported, dependency review, secret scanning guidance
```

## Asset Layout

All required files live inside this package:

- `assets/foundation/` — README, LICENSE, CONTRIBUTING, .gitignore, .editorconfig
- `assets/quality/` — ESLint, Prettier, Ruff, markdownlint, pre-commit hook
- `assets/ci/` — GitHub Actions CI templates
- `assets/release/` — commitlint config, release workflow, extract script, references
- `assets/github/` — PR template, issue forms, labels, CODEOWNERS template, branch protection scripts
- `assets/dependencies/` — Dependabot templates and auto-merge workflow
- `assets/security/` — CodeQL and dependency review workflows

---

## Step 1: Detect the Project and Current State

Inspect the repo before asking anything:

```bash
# Project type indicators
ls package.json pyproject.toml setup.py requirements.txt go.mod Cargo.toml 2>/dev/null

# Web framework indicators
ls next.config.* nuxt.config.* vite.config.* angular.json svelte.config.* astro.config.* remix.config.* 2>/dev/null

# Existing foundation files
ls README.md LICENSE .gitignore .editorconfig CONTRIBUTING.md CHANGELOG.md AGENTS.md CLAUDE.md 2>/dev/null
file AGENTS.md CLAUDE.md 2>/dev/null

# Existing GitHub configuration
ls .github/ 2>/dev/null
ls .github/workflows/ 2>/dev/null
ls .github/pull_request_template.md .github/ISSUE_TEMPLATE/ .github/CODEOWNERS .github/dependabot.yml 2>/dev/null

# Existing tooling
ls eslint.config.* .eslintrc* prettier.config.* .prettierrc* ruff.toml .pre-commit-config.yaml .golangci.yml rustfmt.toml .markdownlint.json 2>/dev/null
ls .husky/ 2>/dev/null

# Existing release / CI / security workflows
ls .github/workflows/ci* .github/workflows/release* .github/workflows/commitlint* .github/workflows/codeql* .github/workflows/dependency-review* 2>/dev/null

# Package manager and scripts for Node projects
ls package-lock.json yarn.lock pnpm-lock.yaml bun.lockb 2>/dev/null
node -e "const p=require('./package.json'); console.log(JSON.stringify(p.scripts||{}, null, 2))" 2>/dev/null || true

# Git state
git status --short 2>/dev/null || echo "git not initialized"
git remote -v 2>/dev/null || echo "no remote"
git branch --show-current 2>/dev/null || true
```

Determine:

- **Project type**:
  - `web` if `package.json` exists and a web framework config exists
  - `node` if `package.json` exists without a web framework config
  - `python` if `pyproject.toml`, `setup.py`, or `requirements.txt` exists
  - `go` if `go.mod` exists
  - `rust` if `Cargo.toml` exists
  - `other` otherwise
- **Project state**:
  - brand new if there is no package manifest, no README, no `.github/`, and no git remote
  - existing otherwise
- **Package manager** for Node projects:
  - `npm` if `package-lock.json` exists
  - `yarn` if `yarn.lock` exists
  - `pnpm` if `pnpm-lock.yaml` exists
  - `bun` if `bun.lockb` exists
  - if none exist, default to `npm`
- **Available scripts** for Node projects:
  - note whether `lint`, `test`, and `build` exist
- **Version source of truth**:
  - `package.json` for Node and web
  - `pyproject.toml` or `setup.py` for Python
  - `Cargo.toml` for Rust
  - tag-only unless another version file already exists for Go or other projects

---

## Step 2: Choose the Run Scope

### Path A — Brand New Project

For a brand-new directory, collect the basic project context before recommending a stack.

Use the `AskUserQuestion`/`request_user_input` tool explicitly:

- if the project name is not obvious from the directory name:
  - "What is the project name?"
- always:
  - "Please provide a short description (1-2 sentences)."

Then use the project name and description to suggest the best default stack, for example:

> "Based on your description, I suggest a Node.js + TypeScript setup with Vitest,
> ESLint, and Prettier. That gives you a fast default for libraries and apps.
> Confirm this stack or tell me what you prefer."

Use the `AskUserQuestion`/`request_user_input` tool explicitly to confirm or override the stack.

Then show the checklist:

```text
New [type] project: [name]

Tier 1 — Foundation
  [x] scaffold and repo baseline
  [x] release workflow
  [x] CI pipeline

Tier 2 — Quality and Governance
  [x] code quality
  [x] GitHub repository setup
  [x] dependency management

Tier 3 — Security
  [x] security scanning
```

Use the `AskUserQuestion`/`request_user_input` tool explicitly:

- "Press Enter to run everything, or tell me what to skip: for example `skip security`, `tier1 only`, or `code quality only`."

### Path B — Existing Project

For an existing repository, do not ask for the project name or description.
Read the repository and infer the context first.

Before showing the checklist, read the most relevant files that describe the project:

- `README.md`
- `AGENTS.md`
- `CLAUDE.md` if it exists and is not just a symlink to `AGENTS.md`
- package metadata such as `package.json`, `pyproject.toml`, `go.mod`, or `Cargo.toml`
- `CHANGELOG.md`
- existing workflow files under `.github/workflows/`

Then present a short understanding summary to the user before asking for scope.
That summary should include:

- the inferred project name
- what the project appears to do
- the detected tech stack
- what setup already appears to exist
- the highest-value gaps that `newproject` could fill

After that summary, mark what already appears configured and default to the
unchecked Tier 1 items first:

```text
Project: [detected type] — [project name]

Tier 1 — Foundation
  [done or empty] scaffold and repo baseline
  [done or empty] release workflow
  [done or empty] CI pipeline

Tier 2 — Quality and Governance
  [done or empty] code quality
  [done or empty] GitHub repository setup
  [done or empty] dependency management

Tier 3 — Security
  [done or empty] security scanning
```

Use the `AskUserQuestion`/`request_user_input` tool explicitly:

- "Which parts should I run? Press Enter to run unchecked Tier 1 items, or say `all`, `tier2`, or specific parts."

Treat the selected scope as the source of truth for the rest of the run.

---

## Step 3: Foundation and Repository Baseline

Run this section when the user selected scaffold and repo baseline.

### 3.1 Initialize Git if Needed

If the directory is not a git repo:

```bash
git init
git checkout -b main
```

If git already exists, skip this step.

### 3.2 Create or Update the Foundation Files

Use only the vendored assets in this package:

- `assets/foundation/templates/README.md.template`
- `assets/foundation/templates/LICENSE-MIT.template`
- `assets/foundation/templates/CONTRIBUTING.md.template`
- `assets/foundation/gitignore/`
- `assets/foundation/editorconfig/.editorconfig`

Apply these rules:

- `README.md`
  - if missing, create it f