setup-project
Skill0 starsChanged 7 days agoMITView on GitHub
Initialize or update a repo's 2build configuration, QA target, architecture and release documents, and project pointers. Use for onboarding or requested configuration changes; use harness-audit to inspect existing AGENTS.md, CLAUDE.md and related harness files.
- Reads credentials
20 other projects use a version of this.
Adopted by
Most recently taken up by
- roedyrustam/doku-gemini-mcptheir own version, first seen Nov 8, 2026
- ok-oldking/ok-scripttheir own version, first seen Nov 1, 2026
- OlliTapio/claude_skillstheir own version, first seen Oct 26, 2026
- MacroMan5/autotrain-yolotheir own version, first seen Oct 25, 2026
- boonkgim/setup-projecttheir own version, first seen Oct 20, 2026
- BinayakDotel/skills-marketplacetheir own version, first seen Oct 17, 2026
Used with
Projects with it also use research, tdd and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
NVIDIASkillresearch
Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.
Also in 5 projects that use this
GoogleSkilltdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Also in 3 projects that use this
GoogleSkillcode-review
Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.
Also in 3 projects that use this
Other versions20 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 20
- ok-oldking/ok-script★ 831same name
- gricha/dangerous-skills★ 38same name
- MacroMan5/autotrain-yolo★ 8same name
- phatysddev/skills★ 8same name
- chav0/UnityFigmaMCP★ 7same name
- ByronFinn/dev-skills★ 4same name
- otaviobarros/agent-engineering★ 3same name
- beeltec/skills★ 2same name
- r2rka1/skills★ 2same name
- roedyrustam/doku-gemini-mcp★ 2same name
10 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository27 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- agent-first-docsSkill
- analytics-reviewSkill
- autopilotSkill
- browseSkill
- create-prSkill
- design-uiSkill
- foremanSkill
- harness-auditSkill
- image-genSkill
- implementSkill
- investigateSkill
- marketing-videoSkill
- plan-draftSkill
- qaSkill
- reconSkill
- release-prdSkill
- releaseSkill
- review-prSkill
- semantic-decisionSkill
- teamSkill
- telemetry-reviewSkill
- testSkill
- token-auditSkill
- triageSkill
- ui-auditSkill
The file
We split this skill into the rules it gives an agent
12 rules. 0 are common, 4 are distinctive, and 8 are very specific to this project.
0
Common
Most of the 18 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 7
Create the minimum configuration future runs need.
- Distinctive: line 10
Follow preamble for bootstrap and telemetry, and Auto-Decision Framework for decisions.
- Very specific: line 16
Read applicable AGENTS.md / CLAUDE.md, existing .babysit configuration, remote/default branches, package scripts, lockfiles, …
- Very specific: line 53
If login is needed, keep credential names in QA config and values in ignored files or environment variables.
- Very specific: line 57
Never replace values or invent accounts.
- Distinctive: line 66
Follow project context links.
- Very specific: line 72
If no equivalent owner exists, create RELEASE.md from observed version files, scripts, CI and runbooks — a greenfield repo too, with …
- Very specific: line 82
Only a repo with no release surface at all records Release: N/A — <reason> in the entrypoint instead of a file.
- Distinctive: line 84
Add one concise 2build pointer section to the existing instruction entrypoint (AGENTS.md preferred when both exist.
- Very specific: line 103
Add prepare / revert only for an established, safe local lifecycle.
- Very specific: line 107
Use harness-audit's checks scoped to the files and services configured here.
- Very specific: line 128
Do not branch, commit, push, tag, publish, deploy, suspend workflows or upgrade local tools as part of this skill.
“Common” is measured: kept by at least 6 in 10 of the 18 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
setup-project
Create the minimum configuration future runs need. Re-running preserves valid settings and fills gaps; it is not an implicit profile switch or repo-wide audit.
Follow preamble for bootstrap and telemetry, and
Auto-Decision Framework for decisions.
Shared refs are filesystem paths beside this skill's directory, so read them
by path, not as skill://.
Discover before writing
Read applicable AGENTS.md / CLAUDE.md, existing .babysit configuration,
remote/default branches, package scripts, lockfiles, Makefile/compose and CI.
Discover the architecture owner of every service (nested docs and entrypoints
included, per project docs)
and, where applicable, design, deployment and release guidance, including
version sources, package publication and automatic pipelines. Derive service
working directories, runtime, local target and useful checks.
Preserve explicit user choices, intentional overrides, named environments and
credential variable names. Do not copy template ports or commands as facts.
For an inspection-only request, use harness-audit. Setup owns configuration writes; that skill owns the evidence checklist. Setup creates missing architecture/release owners and patches links, headings and verified facts; it does not rewrite existing content or unrelated instructions unless asked.
Configure only missing or requested settings
- Git needs no configuration (git flow). Verify
the base branch resolves to the branch the repo releases from (
origin/HEADby default); if not, report the one-line fix (git remote set-head origin <branch>) instead of writing a policy file. A leftover.babysit/git-flow.yamlis ignored; mention it, never extend it. .babysit/qa.yaml: use the smallest supported local configuration. Preserve service check maps and named environments when present. Record actual start and check commands with their working directories, a health/page target, and critical flows including a validation, error or empty-state case. A hosted URL cannot substitute for a missing local target. For CLI/library projects, document their real check commands; do not fabricate a web app..gitignore: ignore.babysit/.envand any machine-local.babysit/qa.local.yaml. Verify they are also untracked; an ignore rule does not remove an already tracked secret. Never print secret values..claude/settings.json(project, committed), when Claude Code is a harness: mergeenv.CLAUDE_CODE_SUBAGENT_MODEL: "sonnet"andsubagentPromptCacheTtl: "1h"if absent, so subagents run on Sonnet and keep their prompt cache warm across long tool waits. Keep every other key; an existing value is a deliberate choice. Never writesettings.local.jsonor~/.claude/.- If login is needed, keep credential names in QA config and values in
ignored files or environment variables. Preserve environment-specific names;
use
QA_USER/QA_PASSonly for a new single-target harness. Seed only missing placeholders withbbs secrets seed --repo-root <repo> <names...>. Never replace values or invent accounts. Multiple GitHub accounts may needGH_ACCOUNT; use a known login, never guess one. - Architecture owners: per project docs, every
service has an architecture document and a multi-service repo also has a
system document limited to what sits between services. Create a missing one
from the skeleton, filled with repository facts and a
TODO(2build):line under each heading the repository cannot answer yet. - Make
AGENTS.mda project map: link architecture guidance, plus design and deployment/release guidance when applicable, with service scope and when to read each. Follow project context links; these project characteristics belong alongside the tooling configuration. - Release profile: for a releasable app, CLI, library or pack, reuse the profile
linked by the instruction entrypoint, otherwise existing
.babysit/release.md,RELEASE.mdor a maintained inline section. Fill missing/requested facts using the release skill's profile contract. If no equivalent owner exists, createRELEASE.mdfrom observed version files, scripts, CI and runbooks — a greenfield repo too, with placeholders (project docs § Release profile) — then link it fromAGENTS.md/CLAUDE.md. Separate independent components/submodules and distinguish normal pipeline ownership from the local execution path. Mark non-applicable distribution/deploy/update stages N/A with reasons; record unresolved commands, thresholds or authority asTODO(2build):placeholders rather than inventing them. Preserve existing landing/publication policy; setup does not grant workflow suspension or release permission. A local path that still invokes Actions/Cloud Build is not--localsupport. Only a repo with no release surface at all recordsRelease: N/A — <reason>in the entrypoint instead of a file. - Add one concise 2build pointer section to the existing instruction entrypoint
(
AGENTS.mdpreferred when both exist; create it if neither exists). Read project pointers for the section and, only when related repos are in scope, workspace registration. Update existing sections in place and preserve imports/symlinks. The template's browser bullets (including browser hygiene) are part of the pointer; add a missing one. Machine-local workspace mappings belong in~/.babysit/config.yaml, never.babysit/config.yaml.
For a new single-target app, adapt this shape to observed commands:
version: 1
url: http://localhost:5173
start: npm run dev
check: npm test
flows: primary journey, validation error, empty state
# credentials: # only when login is required
# username_env: QA_USER
# password_env: QA_PASSAdd prepare / revert only for an established, safe local lifecycle. Do not
seed generic migrate/rollback commands: reversal is not necessarily safe.
Verify and hand off
Use harness-audit's checks scoped to the files and
services configured here; reuse the facts already gathered. Parse YAML and
inspect bbs secrets qa probe --env <local-name> without executing its
output; treat deliberate overrides as valid. Audit the architecture and
release owners — reachability, coverage, scope, truth and remaining
placeholders — per project docs § Audit,
for existing files as well as ones created here.
Inspect start/prepare commands before running them. Probe the local app when
available; start only the intended local service when safe within this task.
Report a missing service, credentials or infrastructure as unverified, not a
passing QA run. Configuration validation does not prove application journeys;
use browse / qa when actual UI verification is requested.
STATUS: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
CONFIG: <files/keys changed, or already configured; workspace registration if any>
DOCS: <architecture/release owners per service: created | linked | audited; findings; TODO(2build) count per file>
VERIFY: <config checks and local probe results; explicit unverified items>
NEXT: <remaining prerequisite or /bbs:autopilot "<feature>">Do not branch, commit, push, tag, publish, deploy, suspend workflows or upgrade
local tools as part of this skill. Creating a release profile prepares future
delivery; an execution request belongs to release.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

