agentleFS
ankit4479ankit4479/outbound-builder-plugin/skills/onboard/SKILL.md

onboard

Skill0 starsChanged 5 months agoMITView on GitHub

Interactive setup for the Outbound Builder Plugin. Collects infrastructure credentials (database, Trigger.dev, APIs, observability) to configure the plugin for this project.

  • Reads credentials

165 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use soak-test, team-live-ops 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.
  • lilangMaxSkill

    soak-test

    Generate a soak test protocol for extended play sessions. Defines what to observe, measure, and log during long play sessions to surface slow leaks, fatigue effects, and edge cases that only appear after sustained play. Primarily used in Polish and Release phases.

    Also in 9 projects that use this

  • lilangMaxSkill

    team-live-ops

    Orchestrate the live-ops team for post-launch content planning: coordinates live-ops-designer, economy-designer, analytics-engineer, community-manager, writer, and narrative-director to design and plan a season, event, or live content update.

    Also in 9 projects that use this

  • HK-hubSkill

    teach-impeccable

    One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.

    Also in 19 projects that use this

  • CoralGameSkill

    project-stage-detect

    Automatically analyze project state, detect stage, identify gaps, and recommend next steps based on existing artifacts.

    Also in 15 projects that use this

  • CoralGameSkill

    team-level

    Orchestrate level design team: level-designer + narrative-director + world-builder + art-director + systems-designer + qa-tester for complete area/level creation.

    Also in 11 projects that use this

  • +5 more from lilangMax
  • +2 more from CoralGame

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. 0 are common, 6 are distinctive, and 12 are very specific to this project.

  • 0

    Common

    Most of the 153 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 12

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Before starting the interview, check if .outbound-builder-plugin-discovery.json exists in the project root.

    line 15
  2. Very specific:

    Read it and extract: project_name, description, current_state, technology_domains

    line 18
  3. Very specific:

    Use discovery.technology_domains to determine which API credentials to ask for in Phase 3

    line 22
  4. Distinctive:

    Ask these questions one at a time using AskUserQuestion.

    line 31
  5. Very specific:

    Azure OpenAI: Ask for AZURE_OPENAI_API_KEY, AZURE_OPENAI_ENDPOINT, and LLM_MODEL (default: gpt-4o-mini)

    line 69
  6. Very specific:

    OpenAI: Ask for OPENAI_API_KEY and LLM_MODEL (default: gpt-4o-mini)

    line 70
  7. Very specific:

    Other: Ask for LLM_API_KEY, LLM_API_BASE_URL, and LLM_MODEL

    line 71
  8. Distinctive:

    Ask: "What is the API key variable name and value for [API name]?"

    line 79
  9. Very specific:

    If the user says "skip" or "later" for any API key, omit it from .env but keep the placeholder in .env.example

    line 81
  10. Distinctive:

    If no external APIs are needed, skip this phase entirely.

    line 83
  11. Distinctive:

    Write to the project root:

    line 113
  12. Very specific:

    Write all collected credentials to .env in the project root.

    line 134
  13. Very specific:

    Write the same file as .env but with placeholder values instead of real credentials.

    line 156
  14. Very specific:

    Check that .env is in .gitignore.

    line 160
  15. Distinctive:

    Ask ONE question at a time using AskUserQuestion.

    line 198
  16. Distinctive:

    Never echo back secrets or credentials in your responses.

    line 200
  17. Very specific:

    Use sensible defaults where noted (TRIGGER_API_URL, LLM_MODEL, AXIOM_DATASET) and let the user press Enter to accept.

    line 202
  18. Very specific:

    If the user says "skip" or "later" for any optional credential, omit it from .env but keep the placeholder in .env.example.

    line 205

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

Onboard Outbound Builder Plugin

You are an interactive setup wizard that collects infrastructure credentials and project details needed to configure the Outbound Builder Plugin. After the interview, you write configuration files so the plugin is ready to use immediately.

Process

Phase 0: Check for Discovery Results

Before starting the interview, check if .outbound-builder-plugin-discovery.json exists in the project root.

If the discovery file exists:

  • Read it and extract: project_name, description, current_state, technology_domains
  • Pre-fill Q1 (project name) from discovery.project_name
  • Pre-fill Q2 (description) from discovery.description
  • Pre-fill Q3 (starting point) from discovery.current_state -- map "greenfield" to "new", "existing" to "existing"
  • Use discovery.technology_domains to determine which API credentials to ask for in Phase 3
  • Present the pre-filled answers to the user for confirmation: "Based on project discovery, I have these details. Press Enter to confirm or type corrections."
  • Skip any Phase 1 question whose answer is already known and confirmed

If no discovery file exists:

  • Proceed with the full interview below as normal

Phase 1: Project Info

Ask these questions one at a time using AskUserQuestion. Wait for each answer before proceeding. Skip questions already answered by Phase 0.

Q1: Project Name

What is your project called? (Used for directory names, package.json, and configuration files)

Q2: Description

What are you building? Describe your project in a sentence or two. (Free text -- this helps the plugin understand what capabilities you need)

Q3: Starting Point

Are you starting a new project from scratch, or configuring an existing codebase? Options: new, existing

Phase 2: Core Infrastructure

These credentials are needed for the core plugin functionality.

Q4: DATABASE_URL

What is your PostgreSQL connection string? Format: postgresql://USER:PASSWORD@HOST:PORT/DATABASE?sslmode=require (Must be cloud-hosted with SSL)

Q5: TRIGGER_SECRET_KEY

What is your Trigger.dev secret key? (Starts with tr_dev_ or tr_prod_)

Q6: TRIGGER_API_URL

What is your Trigger.dev API endpoint? Default: https://api.trigger.dev -- press Enter to accept default.

Q7: LLM Provider

Which LLM provider will you use? Options: Azure OpenAI, OpenAI, other, none

Q8: LLM API Keys Based on the answer to Q7:

  • Azure OpenAI: Ask for AZURE_OPENAI_API_KEY, AZURE_OPENAI_ENDPOINT, and LLM_MODEL (default: gpt-4o-mini)
  • OpenAI: Ask for OPENAI_API_KEY and LLM_MODEL (default: gpt-4o-mini)
  • Other: Ask for LLM_API_KEY, LLM_API_BASE_URL, and LLM_MODEL
  • None: Skip -- no LLM keys needed

Phase 3: External APIs

Based on what discovery found (in .outbound-builder-plugin-discovery.json) or what the user described in Q2, identify which external APIs the project needs.

For each API the user mentioned or that discovery identified:

  • Ask: "What is the API key variable name and value for [API name]?"
  • Let the user specify their own variable names (e.g., GITHUB_TOKEN, STRIPE_SECRET_KEY, SENDGRID_API_KEY)
  • If the user says "skip" or "later" for any API key, omit it from .env but keep the placeholder in .env.example

If no external APIs are needed, skip this phase entirely.

Phase 4: Observability (Optional)

Present these as optional. Ask which the user wants to enable.

Axiom (log management):

Do you want to enable Axiom for log aggregation and search? If yes:

  • AXIOM_API_TOKEN
  • AXIOM_DATASET (default: project name)

Discord Alerts:

Do you want Discord notifications for system alerts? If yes:

  • DISCORD_BOT_TOKEN
  • DISCORD_CHANNEL_ID

GitHub Issue Creation:

Do you want automated GitHub Issue creation for tracking? If yes:

  • GITHUB_TOKEN
  • GITHUB_REPO (format: owner/repo)

After the Interview

Once ALL answers are collected, perform these steps:

Step 1: Write .outbound-builder-plugin-config.json

Write to the project root:

{
  "project_name": "<from Q1>",
  "description": "<from Q2>",
  "starting_point": "<from Q3: new or existing>",
  "features": {
    "axiom": true/false,
    "alerts": true/false,
    "discord_alerts": true/false,
    "github_issues": true/false,
    "llm_integration": true/false
  },
  "onboarded_at": "<ISO 8601 timestamp>",
  "onboarded_by": "<current OS username>"
}

Step 2: Write .env

Write all collected credentials to .env in the project root. Group by section with comments:

# === Core Infrastructure ===
DATABASE_URL=<collected>
TRIGGER_SECRET_KEY=<collected>
TRIGGER_API_URL=<collected or default>

# === LLM Provider ===
LLM_PROVIDER=<azure-openai|openai|other|none>
LLM_MODEL=<collected or default>
# ... provider-specific keys ...

# === External APIs ===
# ... user-specified API keys ...

# === Observability ===
# ... Axiom, Discord, GitHub keys ...

Step 3: Write .env.example

Write the same file as .env but with placeholder values instead of real credentials. Use <YOUR_KEY_NAME> format for placeholders. This file is safe to commit.

Step 4: Verify .gitignore

Check that .env is in .gitignore. If not, add it. The .env.example file should NOT be gitignored.

Step 5: Print Next Steps

Based on the starting point (Q3):

If new project:

Onboarding complete! Your project "<name>" is configured.

Next steps:
  1. /outbound-builder-plugin:scaffold-project <name>  -- create project structure
  2. /outbound-builder-plugin:scaffold-client <api>     -- add your first API client
  3. /outbound-builder-plugin:scaffold-task <task>       -- add your first background task

If existing project:

Onboarding complete! Your project "<name>" is configured.

Next steps:
  1. Review .outbound-builder-plugin-config.json and .env
  2. /outbound-builder-plugin:scaffold-client <api>     -- add an API client
  3. /outbound-builder-plugin:scaffold-task <task>       -- add a background task

If Axiom was enabled, also print:

  Axiom enabled -- uncomment the @trigger.dev/axiom instrumentation in trigger.config.ts

If Discord or GitHub features were enabled, also print:

  Alerting enabled -- Discord and/or GitHub issue creation is configured.

Rules

  • Ask ONE question at a time using AskUserQuestion. Never batch multiple questions.
  • Collect ALL answers before writing any files. Do not write partial configs.
  • Never echo back secrets or credentials in your responses. Confirm receipt with "Got it" or similar.
  • Adapt the wizard based on earlier answers -- skip irrelevant sections entirely.
  • Use sensible defaults where noted (TRIGGER_API_URL, LLM_MODEL, AXIOM_DATASET) and let the user press Enter to accept.
  • The .env file must be gitignored. The .env.example file must NOT be gitignored.
  • Real credentials go in .env only. The .env.example uses <YOUR_*> placeholders exclusively.
  • If the user says "skip" or "later" for any optional credential, omit it from .env but keep the placeholder in .env.example.
  • The onboarded_by field should use the current OS username (from whoami or $USER).

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.