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
- ggoosen/Digital-Workforcetheir own version, first seen Nov 8, 2026
- joeldevz/skynex-pitheir own version, first seen Nov 8, 2026
- eggs-gd/career-spacetheir own version, first seen Nov 8, 2026
- Codename-11/SubFrametheir own version, first seen Nov 8, 2026
- passion4it-gmbh/passionfruit-sitetheir own version, first seen Nov 5, 2026
- striderZA/OpenCodeGameStudiostheir own version, first seen Nov 4, 2026
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.
lilangMaxSkillsoak-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
lilangMaxSkillteam-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-hubSkillteach-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
CoralGameSkillproject-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
CoralGameSkillteam-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
Other versions165 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 165
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- parcadei/Continuous-Claude★ 3.9ksame name
- parcadei/Continuous-Claude-v2★ 3.9ksame name
- parcadei/Continuous-Claude-v3★ 3.9ksame name
- nateherkai/AIS-OS★ 1.4ksame name
- poshan0126/dotclaude★ 871same name
- talesofai/cohub★ 585same name
- me2resh/apexyard★ 542same name
- nexmoe/DayBee★ 424same name
- nexmoe/eve★ 424same name
155 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 repository8 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- browseSkill
- discoverSkill
- rememberSkill
- scaffold-clientSkill
- scaffold-projectSkill
- scaffold-taskSkill
- scaffold-viewerSkill
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
- Very specific: line 15
Before starting the interview, check if .outbound-builder-plugin-discovery.json exists in the project root.
- Very specific: line 18
Read it and extract: project_name, description, current_state, technology_domains
- Very specific: line 22
Use discovery.technology_domains to determine which API credentials to ask for in Phase 3
- Distinctive: line 31
Ask these questions one at a time using AskUserQuestion.
- Very specific: line 69
Azure OpenAI: Ask for AZURE_OPENAI_API_KEY, AZURE_OPENAI_ENDPOINT, and LLM_MODEL (default: gpt-4o-mini)
- Very specific: line 70
OpenAI: Ask for OPENAI_API_KEY and LLM_MODEL (default: gpt-4o-mini)
- Very specific: line 71
Other: Ask for LLM_API_KEY, LLM_API_BASE_URL, and LLM_MODEL
- Distinctive: line 79
Ask: "What is the API key variable name and value for [API name]?"
- Very specific: line 81
If the user says "skip" or "later" for any API key, omit it from .env but keep the placeholder in .env.example
- Distinctive: line 83
If no external APIs are needed, skip this phase entirely.
- Distinctive: line 113
Write to the project root:
- Very specific: line 134
Write all collected credentials to .env in the project root.
- Very specific: line 156
Write the same file as .env but with placeholder values instead of real credentials.
- Very specific: line 160
Check that .env is in .gitignore.
- Distinctive: line 198
Ask ONE question at a time using AskUserQuestion.
- Distinctive: line 200
Never echo back secrets or credentials in your responses.
- Very specific: line 202
Use sensible defaults where noted (TRIGGER_API_URL, LLM_MODEL, AXIOM_DATASET) and let the user press Enter to accept.
- Very specific: line 205
If the user says "skip" or "later" for any optional credential, omit it from .env but keep the placeholder in .env.example.
“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.
Files
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_domainsto 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_ortr_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, andLLM_MODEL(default:gpt-4o-mini) - OpenAI: Ask for
OPENAI_API_KEYandLLM_MODEL(default:gpt-4o-mini) - Other: Ask for
LLM_API_KEY,LLM_API_BASE_URL, andLLM_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
.envbut 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_TOKENAXIOM_DATASET(default: project name)
Discord Alerts:
Do you want Discord notifications for system alerts? If yes:
DISCORD_BOT_TOKENDISCORD_CHANNEL_ID
GitHub Issue Creation:
Do you want automated GitHub Issue creation for tracking? If yes:
GITHUB_TOKENGITHUB_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 taskIf 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 taskIf Axiom was enabled, also print:
Axiom enabled -- uncomment the @trigger.dev/axiom instrumentation in trigger.config.tsIf 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
.envfile must be gitignored. The.env.examplefile must NOT be gitignored. - Real credentials go in
.envonly. The.env.exampleuses<YOUR_*>placeholders exclusively. - If the user says "skip" or "later" for any optional credential, omit it from
.envbut keep the placeholder in.env.example. - The
onboarded_byfield should use the current OS username (fromwhoamior$USER).
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.

