agentleFS
RealDougEubanksRealDougEubanks/ClaudeMarketplace/skills/onboarding/SKILL.md

onboarding

Skill1 starsChanged 2 months agoMITView on GitHub

Generates a comprehensive developer onboarding guide (ONBOARDING.md) by reading the codebase: directory map, entry points, environment variables, key commands, and architecture overview.

  • Reads credentials
  • Installs packages

100 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use paywalls, popups and 10 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.
  • CesarjoquinSkill

    paywalls

    When the user wants to create or optimize in-app paywalls, upgrade screens, upsell modals, or feature gates. Also use when the user mentions "paywall," "upgrade screen," "upgrade modal," "upsell," "feature gate," "convert free to paid," "freemium conversion," "trial expiration screen," "limit reached screen," "plan upgrade prompt," "in-app pricing," "free users won't upgrade," "trial to paid conversion," or "how do I get users to pay." Use this for any in-product moment where you're asking users to upgrade. Distinct from public pricing pages (see cro) — this focuses on in-product upgrade moments where the user has already experienced value. For pricing decisions, see pricing.

    Also in 19 projects that use this

  • CesarjoquinSkill

    popups

    When the user wants to create or optimize popups, modals, overlays, slide-ins, or banners for conversion purposes. Also use when the user mentions "exit intent," "popup conversions," "modal optimization," "lead capture popup," "email popup," "announcement banner," "overlay," "collect emails with a popup," "exit popup," "scroll trigger," "sticky bar," or "notification bar." Use this for any overlay or interrupt-style conversion element. For forms outside of popups, see cro. For general page conversion optimization, see cro.

    Also in 18 projects that use this

  • coreyhaines31Skill

    marketing-council

    When the user wants multiple expert perspectives on a marketing question — a simulated board of advisors staffed by legendary marketers (Seth Godin, David Ogilvy, Eugene Schwartz, April Dunford, Rory Sutherland, Alex Hormozi, Byron Sharp, and more). Also use when the user mentions 'marketing council,' 'board of advisors,' 'advisory board,' 'what would Seth Godin say,' 'what would Ogilvy think,' 'channel Hormozi,' 'get multiple perspectives,' 'debate this,' 'have the council review,' 'marketing mentors,' or asks how a famous marketer would approach their problem. The council gives each advisor's take through their documented frameworks, surfaces where they disagree, and synthesizes a recommendation. For executing the winning direction, hand off to positioning, offers, copywriting, ads, or the relevant skill.

    Also in 13 projects that use this

  • roerohanSkill

    prospecting

    When the user wants to find, qualify, and build a list of prospects to reach out to — across B2B SaaS, general B2B, or local small businesses. Also use when the user mentions "prospecting," "build a prospect list," "find prospects," "find leads," "lead gen list," "find SaaS companies that," "find B2B companies," "find local businesses," "ICP-fit accounts," "who should we go after," "outbound list," "target account list," "find clients near me," "businesses without websites," "prospect research," "qualified leads," "find my first customers," "early adopters," "design partners," "beta users," or "who has this problem." Use this for the list-building and qualification phase. For writing the outbound copy after the list is built, see cold-email. For deep competitive research on specific accounts, see competitor-profiling.

    Also in 16 projects that use this

  • roerohanSkill

    emails

    When the user wants to create or optimize an email sequence, drip campaign, automated email flow, or lifecycle email program. Also use when the user mentions "email sequence," "drip campaign," "nurture sequence," "onboarding emails," "welcome sequence," "re-engagement emails," "email automation," "lifecycle emails," "trigger-based emails," "email funnel," "email workflow," "what emails should I send," "welcome series," or "email cadence." Use this for any multi-email automated flow. For cold outreach emails, see cold-email. For in-app onboarding, see onboarding.

    Also in 18 projects that use this

  • +7 more from Cesarjoquin

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 1 is distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 85 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use Read on README.md, then attempt to read whichever of the following exist: package.json, pyproject.toml, go.mod, CLAUDE.md, …

    line 13
  2. Very specific:

    Use Glob to map the top-level directory structure (*).

    line 15
  3. Very specific:

    Use Glob to find entry points matching: index.*, main.*, server.*, app.*, cmd//*.

    line 17
  4. Very specific:

    Use Read on any Makefile, package.json (scripts section), or Taskfile.yml to identify key commands: install, run, test, build, lint.

    line 19
  5. Very specific:

    Use Glob to find .env.example or any env var documentation files.

    line 21
  6. Distinctive:

    Use Bash to count files by detected language type.

    line 25
  7. Very specific:

    Use Glob to check for docs/agentRoster.md.

    line 66
  8. Very specific:

    Write the completed onboarding guide to docs/ONBOARDING.md using Write, following the output structure below.

    line 68
  9. Very specific:

    Write the following document to docs/ONBOARDING.md:

    line 72
  10. Very specific:

    After writing the file, confirm to the user that docs/ONBOARDING.md has been created and summarize the key sections included.

    line 135

“Common” is measured: kept by at least 6 in 10 of the 85 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Onboarding

Generate a comprehensive developer onboarding guide for an unfamiliar codebase and write it to docs/ONBOARDING.md.

Instructions

  1. Use Read on README.md, then attempt to read whichever of the following exist: package.json, pyproject.toml, go.mod, CLAUDE.md, docs/assumptions.md.
  2. Use Glob to map the top-level directory structure (*). For each top-level folder found, describe its purpose based on its name and contents (e.g., src/ → application source, scripts/ → automation scripts, docs/ → project documentation).
  3. Use Glob to find entry points matching: index.*, main.*, server.*, app.*, cmd/**/*. Read the primary entry point to understand how the application starts.
  4. Use Read on any Makefile, package.json (scripts section), or Taskfile.yml to identify key commands: install, run, test, build, lint.
  5. Use Glob to find .env.example or any env var documentation files. List all required environment variables with their descriptions.

    SECURITY: Read .env.example only — never read .env or any file containing real credential values, and never include actual secret values in the generated guide. Document variable names and descriptions only.

  6. Use Bash to count files by detected language type. Adapt the command to the language detected:
    • TypeScript/JavaScript: find . -name "*.ts" -o -name "*.js" | grep -v node_modules | wc -l
    • Python: find . -name "*.py" | grep -v __pycache__ | wc -l
    • Go: find . -name "*.go" | wc -l
  7. Generate architecture diagram.

    a. Use Read on the primary entry point file identified in step 3 to understand how the application initializes and what it connects to.

    b. Use Glob to find configuration files that reveal infrastructure: docker-compose.yml, *.env.example, infrastructure/**, terraform/**, serverless.yml, .github/workflows/**.

    c. Use Grep to identify major inter-module dependencies: import/require/use statements at the top of the entry point and primary route/handler files.

    d. Generate a Mermaid diagram using the most appropriate type:

    • For web apps with a request flow: sequenceDiagram showing Client → Load Balancer → App Server → Database/Cache/Queue
    • For microservices or modular apps: graph LR showing service dependencies
    • For simple single-module apps: graph TD showing function/module call flow

    e. Include the diagram in the generated docs/ONBOARDING.md under a "## Architecture" section, wrapped in a fenced code block with mermaid syntax tag.

    f. Add a note: "This diagram was auto-generated and may not capture all relationships. Review and update as the architecture evolves."

    Example output to include in ONBOARDING.md:

    ## Architecture
    
    ```mermaid
    sequenceDiagram
        Client->>+ALB: HTTPS Request
        ALB->>+AppServer: Forward
        AppServer->>+PostgreSQL: Query
        PostgreSQL-->>-AppServer: Result
        AppServer->>+Redis: Cache write
        AppServer-->>-ALB: Response
        ALB-->>-Client: HTTPS Response
    ```
    
    > This diagram was auto-generated and may not capture all relationships. Review and update as the architecture evolves.
  8. Use Glob to check for docs/agentRoster.md. If it exists, read it and include the agent roster section in the guide.
  9. Write the completed onboarding guide to docs/ONBOARDING.md using Write, following the output structure below.

Output Structure

Write the following document to docs/ONBOARDING.md:

# Developer Onboarding Guide — <Project Name>

## What This Project Does
<1-2 sentence summary from README>

## Tech Stack
| Layer | Technology |
|-------|-----------|
| Language | ... |
| Framework | ... |
| Database | ... |
| CI/CD | ... |

## Directory Map
| Path | Purpose |
|------|---------|
| `src/` | ... |

## Getting Started
```bash
# 1. Install dependencies
npm install

# 2. Configure environment
cp .env.example .env
# Edit .env: fill in ...

# 3. Run locally
npm run dev

Key Entry Points

  • src/index.ts:1 — Application bootstrap
  • src/routes/ — API route definitions

Environment Variables

VariableRequiredDescription
DATABASE_URLYesPostgreSQL connection string

Key Commands

CommandWhat it does
npm run devStart dev server with hot reload
npm testRun test suite

Architecture Overview

<brief description of the main data/request flow>

Agent Roster

<include only if docs/agentRoster.md exists>

How to Contribute

<derive from the target project's own conventions — see note below>


For the "How to Contribute" section: read the target project's `CONTRIBUTING.md`, `CLAUDE.md`, or `.github/PULL_REQUEST_TEMPLATE.md` and summarize *that project's* branching, review, and merge rules. Do not assume any particular branch-prefix or approval policy. If no convention docs exist, fall back to generic guidance: "Create a branch, open a PR, and request review — confirm the team's specific conventions with a maintainer."

After writing the file, confirm to the user that `docs/ONBOARDING.md` has been created and summarize the key sections included.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.