domains / agent-tooling / project-init / init

init

Skill card

combined

All four skills are named init but perform unrelated initialization tasks: one sets up a task-manager works directory and Bash permissions, one creates or prunes an AGENTS.md file, one scaffolds a Playwright e2e environment, and one fills [FILL:] placeholders in a research project template. None is a reproduction of the others, so crowning one would hide real alternatives.

Repositories

Other copies

Combined skill

# Project Init

This skill covers four distinct initialization workflows. Choose the one that matches the user's request.

## Workflow A: uc-taskmanager init

Use when the user says "uctm init", "initialize uctm", or asks to set up uc-taskmanager.

1. Create a `works/` directory if it does not exist. Report whether it was created or already existed.
2. Ask the user whether to auto-configure Bash permissions in `.claude/settings.local.json` (recommended).
3. If approved, read `.claude/settings.local.json` (create if missing) and merge the required permission entries into `permissions.allow`, skipping any that already exist. Preserve existing `permissions.allow` and `permissions.deny` entries.
4. Report the number of permissions added, skipped, or already configured.
5. Show a summary confirming `works/` is ready and permissions are configured, and suggest the next command.

## Workflow B: AGENTS.md init

Use when creating, updating, or pruning an `AGENTS.md` file for a repository.

1. Treat `AGENTS.md` as a living list of non-discoverable landmines and workflow gotchas, not a codebase overview.
2. Apply a discoverability filter: before adding any line, ask whether an agent can discover it by reading the repo (README, code, config, scripts, directory tree). If yes, do not include it. If no, and it materially affects task success, cost, or safety, include it.
3. Include only guidance that is non-discoverable, operationally significant, and actionable. Typical examples include non-standard tooling choices, command caveats, hidden constraints, and critical local conventions not encoded in lint/tests/config.
4. Do not include tech stack summaries, directory structure overviews, architecture descriptions, generic best-practice advice, rules already enforced by tooling, or mandatory boilerplate headers unless the repo explicitly requires one.
5. Prefer short, high-signal sections such as Scope & routing, Non-discoverable commands, Landmines / do-not-touch areas, and Task-specific constraints. For large repos, recommend hierarchical AGENTS.md files near relevant modules.
6. Check source files first: existing AGENTS.md, README.md, PROJECT.md, Cursor rules, Copilot instructions, GEMINI.md, CI/workflow files, and package manager config. If AGENTS.md exists, improve it incrementally instead of replacing it blindly.
7. Maintain a maintenance mindset: prefer fixing the root cause in code/tooling, keep only the minimum instruction needed, and prune stale instructions aggressively.
8. Before finalizing, verify each line is non-discoverable, still accurate, and materially reduces mistakes, cost, or time. Delete any line that fails these checks.

## Workflow C: Playwright init

Use when the user says "set up playwright", "add e2e tests", "configure playwright", or asks to add test infrastructure.

1. Analyze the project: check `package.json` for the framework, check for `tsconfig.json` to choose TypeScript or JavaScript, check if Playwright is already installed, check for existing test directories, and check for existing CI config.
2. Install Playwright if not already installed, using `npm init playwright@latest -- --quiet` or manual install with `npm install -D @playwright/test` and `npx playwright install --with-deps chromium`.
3. Generate `playwright.config.ts` adapted to the detected framework, setting the correct `baseURL` and `webServer.command` for Next.js, React (Vite), Vue/Nuxt, Angular, or no framework.
4. Create the folder structure: `e2e/fixtures/`, `e2e/pages/`, `e2e/test-data/`, and `e2e/example.spec.ts`.
5. Generate an example test that verifies the homepage loads and has visible navigation.
6. Generate a CI workflow: if `.github/workflows/` exists, create `playwright.yml`; if `.gitlab-ci.yml` exists, add a Playwright stage.
7. Update `.gitignore` to exclude `/test-results/`, `/playwright-report/`, `/blob-report/`, and `/playwright/.cache/` if not already present.
8. Add npm scripts: `test:e2e`, `test:e2e:ui`, and `test:e2e:debug`.
9. Run the example test with `npx playwright test`. Report the result and diagnose any failures before completing.
10. Confirm what was created: config file path and key settings, test directory and example test, CI workflow, npm scripts, and how to run tests.

## Workflow D: Research project template init

Use when setting up a freshly cloned research project that contains `[FILL:]` placeholders.

1. Scan all tracked files for `[FILL:` patterns and group them by file. Report how many placeholders exist and in which files.
2. Ask the user for project information: project title, subtitle, authors (name, affiliation, ORCID, email, corresponding author status), abstract, keywords, project stage, data source description, repository URL, and project slug.
3. Apply the values to each file: `index.qmd` (title, subtitle, authors, abstract, keywords), `README.md` (title, description, data section, repository URL, Quick Start clone URL), `CLAUDE.md` (Project Context table), `pyproject.toml` (name, description, authors), `_quarto.yml` (verify no placeholders), and `templates/chadManuscript/manuscript.tex` (author names and keywords).
4. Re-scan for remaining `[FILL:]` placeholders and report how many remain and where.
5. Run `bash scripts/render.sh` to regenerate `latex/index.tex` with the real content.
6. Report a summary: files updated, placeholders filled, placeholders remaining, and render status.