Team — can others build on it?
Brief 14

New-Dev Onboarding Audit

Walk clone → install → run → change → PR like a brand-new developer and log every stumble on the way to a first contribution.

DX.md4 phases7 lenses~2.5k chars

Free & open · no signup · read-only — it ends by asking · nothing leaves your machine

What it does

You are working inside this repo. Mission: experience this repo as a brand-new developer would — clone, install, run, make a change, open a PR — and log every stumble between them and a first contribution.

Read-only toward the codebase; you may exercise setup steps in a sandbox. Your only write is the report file.

What it looks for

7 lenses it looks through

Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.

1

Docs vs reality

every README step that fails, lies, or assumes tribal knowledge

2

Secrets bootstrap

the path from zero to working config; blockers requiring another human

3

Seed data

can a new dev see the product working, or a blank screen?

4

Loop speed

edit → see result: how many seconds; test cycle time

5

Error quality

when setup is wrong, do errors say what to do next?

6

Contribution path

branch conventions, CI feedback time, review expectations: written anywhere?

7

Tribal knowledge

decisions and gotchas that live only in someone's head; list what you had to infer

The deliverable

What lands in your repo

One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.

DX.md
1
Time-to-first-PR estimate
today, honestly, with the breakdown
2
Stumble log
the walk, step by step, with findings inline
3
Fixes
each: what · file to change · effort; ordered by stage
4
The one-hour fix
the single improvement that saves the most time for every future developer
One file. Evidence-backed. It ends by asking before touching anything. · see a real DX.md ↗
How it works

What it makes the agent do

Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.

1
Phase 1

Walk the path literally

Follow the README exactly as written, noting where reality diverges.

2
Phase 2

Audit through 7 lenses

Docs vs reality — every README step that fails, lies, or assumes tribal knowledge.

3
Phase 3

Curate

Rank friction by where it lands.

4
Phase 4

Report

Create DX.md at repo root.

Get started

Three ways to run this Goal Prompt

01 · COPY

Paste it in

Copy it and paste it into your agent inside the repo you want checked.

02 · INSTALL

As a slash command

Install the goal plugin once — two commands — then just type /goal:onboarding-audit.

1/plugin marketplace add GhostlyGawd/goal-prompts
2/plugin install goal@goal-prompts

Or install only this Goal Prompt as /goal-onboarding-audit:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=14 sh
03 · AGENT

From an agent (MCP)

Let an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.

https://goal-prompts.vercel.app/raw/14.md
Transparency

The exact prompt

Nothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.

Read the full brief (2,540 characters)
# Goal: New-Dev Onboarding Audit

You are working inside this repo. Mission: experience this repo as a brand-new developer would — clone, install, run, make a change, open a PR — and log every stumble between them and a first contribution.

Read-only toward the codebase; you may exercise setup steps in a sandbox. Your only write is the report file.

## Phase 1 — Walk the path literally
Follow the README exactly as written, noting where reality diverges:
- Clone → install: missing prerequisites, undocumented versions, failing steps
- Configure: env vars and secrets — where does a new dev get them; is there an example file?
- Run: does the app start; is there seed data or an empty shell?
- Verify: do the tests pass out of the box?

## Phase 2 — Audit through 7 lenses
1. **Docs vs reality** — every README step that fails, lies, or assumes tribal knowledge
2. **Secrets bootstrap** — the path from zero to working config; blockers requiring another human
3. **Seed data** — can a new dev see the product working, or a blank screen?
4. **Loop speed** — edit → see result: how many seconds; test cycle time
5. **Error quality** — when setup is wrong, do errors say what to do next?
6. **Contribution path** — branch conventions, CI feedback time, review expectations: written anywhere?
7. **Tribal knowledge** — decisions and gotchas that live only in someone's head; list what you had to infer

## Phase 3 — Curate
- Rank friction by where it lands: earlier stumbles cost every future hire
- Every finding: exact step, what happened, what should happen

## Phase 4 — Report
Create `DX.md` at repo root:
1. **Time-to-first-PR estimate** — today, honestly, with the breakdown
2. **Stumble log** — the walk, step by step, with findings inline
3. **Fixes** — each: what · file to change · effort; ordered by stage
4. **The one-hour fix** — the single improvement that saves the most time for every future developer

Start the report with today's date. If `DX.md` already exists from a previous run, read it first and lead with what changed since.

## Rules
- Report what actually happened when steps were followed, not what docs claim
- A setup script beats a setup document
- No expected contributors beyond the author in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
- If a `reports/` directory exists at the repo root, write the report there instead of the root.
- Before asking, present the top findings as a ranked list in plain words
- Report only — end by asking which fixes to make

House rules for this Goal Prompt

  • Report what actually happened when steps were followed, not what docs claim
  • A setup script beats a setup document
  • No expected contributors beyond the author in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
  • If a reports/ directory exists at the repo root, write the report there instead of the root.
  • Before asking, present the top findings as a ranked list in plain words
  • Report only — end by asking which fixes to make
Keep exploring

More Team briefs

Runs inside these playbooks — curated sequences you can launch with one paste: