configs/skills/init-profile/SKILL.md
Generate `.claude/PROJECT_PROFILE.md` — the project-specific facts that should be loaded into every session (deployment topology, host mapping, env file locations, verification commands). Run once per project after clone.
npx skillsauth add shenxingy/claude-code-kit init-profileInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Capture project-specific facts that the SessionStart hook will inject every time. Pairs with the Environment Fingerprint block (host-level facts) by adding the Project Profile block (project-level facts).
Writes .claude/PROJECT_PROFILE.md with five sections, filled in interactively. The session-context.sh hook auto-loads this file on every SessionStart, so the agent has the facts upfront and stops guessing.
Without a profile, the agent re-discovers the same facts each session ("where does prod run?", "is this hostname local or remote?", "where are the env secrets?"). With a profile, those facts live in the system prompt from session 1.
Detect what already exists. Read these for clues:
CLAUDE.md (deployment URLs, commands).env, .env.example, .env.*.local, brands/*.local.envpackage.json, Dockerfile, docker-compose.yml, vercel.json, netlify.toml~/.profile / ~/.zshrc for project-specific env varsgit log for clues on dev workflowAsk the user (one question per section, skip if already obvious from step 1):
a. Hosts & topology
b. Service URLs
c. Secret/env file locations
d. Verification commands
gh api repos/x/y/actions/runs --jq '.workflow_runs[0].conclusion'e. Aliases the user uses for this project
brands/*.local.env)Write .claude/PROJECT_PROFILE.md in this format:
# Project Profile — <project name>
## Hosts
- <hostname>: <role> (this machine | remote)
- <hostname>: <role> (this machine | remote)
## URLs
- Production: <url>
- Local dev: <url(s)>
## Env / secrets
- <path>: <what's in it>
## Verify commands
- <env>: `<command>`
## Aliases
- "<phrase user uses>" → <what it actually maps to>
Confirm — show the file content, ask the user to approve before writing.
Do NOT git-commit. The user decides what's safe to commit. .claude/PROJECT_PROFILE.md may contain internal hostnames or URLs that shouldn't be public — recommend .gitignore if the project is public.
.claude/PROJECT_PROFILE.md/init-profile.Environment Fingerprint block in session-context.sh — don't duplicate them here.development
Orchestrate a fleet of parallel `codex exec` workers with you (Claude Code) as the supervisor — spawn one per isolated git worktree, dispatch headless, verify each INDEPENDENTLY, PR/merge. The manual "codex-ultracode" pattern for fanning out real implementation, research, or review work onto Codex. Bakes in the hard gotchas (stdin blocking, background tracking, don't-trust-self-reports, writer isolation). Triggers on — orchestrate codex, codex workers, codex fleet, spawn codex, delegate to codex in parallel, manual ultracode, 开 codex 小弟, 派 codex worker — NOT for a single cross-vendor opinion (use the `second-opinion-codex` agent), NOT for web-UI worker decomposition (use `/orchestrate`).
development
Create and manage git worktrees for parallel Codex sessions
development
Verify project behavior anchors — compilation, tests, and interaction checks after autonomous runs. NOT the Codex built-in /verify (which runs the app to observe a single change working) — this one walks the AGENTS.md "Features (Behavior Anchors)" list.
documentation
End-of-session documentation sync — updates TODO.md and PROGRESS.md only (run /commit after to commit everything)