onboard

Name: onboard
Author: tomevault-io

Security Community

Repo stars 0
Author updated Live
Author repo skills-registry

Fluxly profile Facts only: domain, agents, trust score, runtime, permissions and network

Domain: Security
Compatible agents: Claude Code
Cursor
Cline
Codex
Windsurf
Gemini CLI

+20
Trust score: 88 / 100 · community maintained
Author / version / license: @tomevault-io · no license declared
Token usage: Lean
Setup complexity: Guided setup
External API key: Not required
Operating systems: macOS · Linux · Windows
Runtime requirements: Python >=3.11
Permissions: Read-only
Write / modify
Shell exec
Network behavior: Local-only
Install commands: 26 variants

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview onboard.preview

---
name: onboard
description: Agent-driven cold-start onboarding. Use the repo shell entrypoint to find or install Python 3.11…
category: security
runtime: Python
---

# onboard output preview

## PART A: Task fit
- Use case: Agent-driven cold-start onboarding. Use the repo shell entrypoint to find or install Python 3.11+, then run the shared bootstrap audit/plan/apply flow and configure WRDS only if the user has it. Use when this capability is needed..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Hard Rules / Workflow / 1. Start With The Shell Entry Point” and do not present inference as author intent.

## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Agent-driven cold-start onboarding. Use the repo shell entrypoint to find or install Python 3.11+, then run the shared bootstrap audit/plan/apply flow and configure WRDS only if the user has it. Use when this capability is needed.”.
- **02** When the source has headings, the agent prioritizes “Hard Rules / Workflow / 1. Start With The Shell Entry Point” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.

## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.

SKILL.md SKILL.md

---
name: onboard
description: Agent-driven cold-start onboarding. Use the repo shell entrypoint to find or install Python 3.11…
category: security
source: tomevault-io/skills-registry
---

# onboard

## When to use
- Agent-driven cold-start onboarding. Use the repo shell entrypoint to find or install Python 3.11+, then run the shared…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.

## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.

## Execution rules
- Organize steps around “Hard Rules / Workflow / 1. Start With The Shell Entry Point” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.

## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.

Evidence boundary and execution chain

The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.

skill "onboard" {
  input      -> user goal + target files + boundaries + acceptance criteria
  context    -> Hard Rules / Workflow / 1. Start With The Shell Entry Point
  rules      -> SKILL.md triggers / order / output contract
  runtime    -> Python | read files, write/modify files, run shell commands | mostly runs locally
  guardrails -> usually needs no extra API key + small-sample validation + diff/log review
  output     -> copyable result + checklist + next iteration
}

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Agent-driven cold-start onboarding. Use the repo shell entrypoint to find or install Python 3.11+, then run the shared bootstrap…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Hard Rules”, “Workflow”, “1. Start With The Shell Entry Point”, “2. Resolve WRDS Scope Once”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name onboard directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Hard Rules / Workflow / 1. Start With The Shell Entry Point” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write / shell-exec; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

User Onboarding

Use the shared repo-local onboarding flow:

tools/onboard.ps1 or tools/onboard.sh for the pre-Python cold-start step
tools/onboard_driver.py for agent orchestration once Python exists
tools/bootstrap.py as the shared Python-level audit/plan/apply engine

Do not duplicate bootstrap logic here when the repo scripts already handle it.

Hard Rules

Print Scanning your environment... before discovery.
Print Testing WRDS connectivity... before live psql checks.
Never assume bare python or bare pip are valid on Windows.
Prefer uv pip install --python "<PYTHON>" when uv is available; fall back to "<PYTHON>" -m pip install.
Prefer tools/bootstrap.py audit, the emitted bootstrap_plan, and tools/bootstrap.py apply over ad hoc local-file generation.
Treat canonical local state as external to the repo. Repo-root LOCAL_ENV.md, CLAUDE.local.md, and .claude/settings.local.json are compatibility shims only.
Let tools/bootstrap.py apply manage canonical local state. Use --write-compat-shims only for private single-user backward compatibility.
If an install path needs admin privileges or a missing package manager, stop and give exact instructions.
If a bootstrap-plan command needs approval, request it and continue with that exact command.
Ask once whether the user has a WRDS account and wants it configured now. If the answer is no, skip WRDS setup and still treat onboarding as complete once the base repo is ready.
Treat SSH key setup as optional for basic PostgreSQL access.
Never use conda install for system tools (psql, pdflatex, R, git). Use the OS package manager (winget/brew/apt). Conda is for Python packages only.

Workflow

1. Start With The Shell Entry Point

Use the repo-local shell entrypoint, not tools/bootstrap.py directly, when the machine may not have Python yet.

powershell -ExecutionPolicy Bypass -File tools/onboard.ps1

bash tools/onboard.sh

Those entrypoints should:

find a usable Python 3.11+ interpreter
install Miniforge automatically when no acceptable Python exists and a supported installer path is available
hand off to tools/onboard_driver.py

If the package manager or installer path is unavailable, stop and give the exact manual Miniforge command for the current platform.

2. Resolve WRDS Scope Once

If the user already answered in chat, pass that through to the driver. If not, ask once:

Do you have a WRDS account and want it configured now?

Outcomes:

yes: collect username when needed, create WRDS files, and run live WRDS checks
no: skip WRDS setup entirely
later / declined: also skip WRDS setup entirely

WRDS is optional. Lack of a WRDS account must not make onboarding fail.

3. Audit With The Shared Engine

Once Python exists, run the shared audit:

"<PYTHON>" tools/bootstrap.py audit --json --wrds yes|no

Read the audit output and summarize the gaps before changing anything.

4. Execute The Bootstrap Plan

Read bootstrap_plan.steps from the audit payload and execute each step with auto_run=true for the current shell in order.

The plan is the source of truth for:

blocking base-repo setup
optional WRDS setup
optional writing and R setup
tools/bootstrap.py apply
the final rerun of tools/bootstrap.py audit

If direct command execution is not available because you are running in a plain local terminal without agent approvals, you may use the best-effort convenience fallback:

"<PYTHON>" tools/bootstrap.py repair --write-canonical-state --wrds yes|no

5. Manual Gaps The Shared Engine Cannot Finish Alone

If the bootstrap plan or fallback repair step cannot install Python packages automatically:

# With uv (preferred):
uv pip install --no-compile --python "<PYTHON>" pandas psycopg2-binary pyarrow numpy matplotlib statsmodels
# Without uv:
"<PYTHON>" -m pip install --no-compile pandas psycopg2-binary pyarrow numpy matplotlib statsmodels

If the bootstrap plan or fallback repair step cannot reinstall repo packages automatically:

# With uv (preferred):
uv pip install --no-compile --python "<PYTHON>" -e .
cd packages/PyBondLab && uv pip install --no-compile --python "<PYTHON>" -e ".[performance]"
# Without uv:
"<PYTHON>" -m pip install --no-compile -e .
cd packages/PyBondLab && "<PYTHON>" -m pip install --no-compile -e ".[performance]"

If psql is missing and the user said no to WRDS, onboarding can still be complete. psql is only needed for WRDS data extraction.

If the user wants WRDS access later, recommend:

Windows: Download the PostgreSQL zip archive from postgresql.org and extract to ~/tools/pgsql/ (the probe already checks this path).
macOS: brew install libpq
Linux: apt install postgresql-client or dnf install postgresql

Then rerun:

"<PYTHON>" tools/bootstrap.py audit --wrds yes

NEVER use conda to install psql, PostgreSQL, LaTeX, or other system tools. Conda's dependency solver hangs on these packages and can corrupt the Python environment. Conda is for Python packages only.

If WRDS is enabled and files are missing, create or repair:

~/.pg_service.conf
~/.pgpass
~/.ssh/config entry for Host wrds if SSH or TAQ workflows are needed

Use the username from $ARGUMENTS if provided, otherwise ask once. If ~/.pgpass is missing, ask for the WRDS password and do not echo it back. Prefer the shared helper:

AI_ASSET_PRICING_WRDS_PASSWORD="<SECRET>" "<PYTHON>" tools/bootstrap.py wrds-files --username THEIR_USERNAME

DUO 2FA: The first psql service=wrds connection from a new IP triggers a DUO push notification. Tell the user to check their phone and approve it. The connection will time out if not approved.

When testing WRDS connectivity, use a date range guaranteed to have data (for example 2022). Do not use the current year. A query returning 0 rows is not a valid connectivity confirmation.

Example:

psql service=wrds -c "SELECT COUNT(*) FROM crsp.dsi WHERE date >= '2022-01-01' AND date < '2023-01-01';"

Expected result: about 251 rows.

6. Refresh Local Files Only

If you only need to refresh canonical local state after environment changes, run:

"<PYTHON>" tools/bootstrap.py apply

This writes or refreshes canonical external files:

local_env.md
claude.local.md
settings.local.json

7. Final Summary

End with a short status table covering:

base repo
WRDS
writing
R
Python
repo packages

If WRDS shows as skipped because the user has no account, say clearly that onboarding is still complete once the base repo is ready.

Then list the files written and any remaining manual steps.

Post-Onboard Note

Tools like psql may not be on the shell PATH even when installed. After onboarding, always use the absolute paths recorded in canonical local state (or a repo-root compatibility shim if one was explicitly generated) rather than bare command names. The bootstrap engine discovers these paths automatically and writes them to the local files.

Source: Alexander-M-Dickerson/ai-asset-pricing — distributed by TomeVault.

Install command

One-click installPick a runner, click Copy, paste into your terminal, press enter

npx skills add tomevault-io/skills-registry/alexander-m-dickerson--ai-asset-pricing--onboard -y

Open general install guide

View skill source

Works with

Claude Code
Cursor
Cline
Codex
Windsurf
Gemini
OpenCode
Roo Code
AAide
+Augment
GitHub Copilot
OpenClaw
KKiro
Junie
WWarp
Goose
Trae
Kilo Code
OpenHands
Amp
Zencoder
CContinue
AIAider
CodeBuddy
CodeGeeX
Replit Agent

Security audit

88 / 100

Community

未声明 license/许可。
未声明 version。
未限定 allowed-tools，默认拥有全部工具权限。

Metadata

Source: github
tomevault-io/skills-registry
中文

More by @tomevault-io

Category & tags

Category Security