refactor: enforce layer responsibilities across all skills

Rewrote docs/standard.md as the single source of truth for skill
structure (menu/tools/recipes/manual analogy). Trimmed all SKILL.md
files to pure routers, moved recruitment workflow out of SKILL.md
into workflows/recruitment.md, removed duplicated standards from
workflow files.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
zhi
2026-04-17 20:40:16 +00:00
parent fd0f84d6b8
commit 795a710376
9 changed files with 238 additions and 301 deletions

View File

@@ -1,71 +1,34 @@
--- ---
name: claw-skills name: claw-skills
description: ClawSkills management and collaboration suite — scripts and workflows for using and improving skills. description: ClawSkills management — update, improve, create, and fix skills.
--- ---
# claw-skills > All skill documentation must be written in English.
ClawSkills management and collaboration suite — scripts and workflows for using and improving skills.
> **All skill-related documentation must be written in English.**
> When creating, improving, or correcting skills, always use English for all documentation, descriptions, and guides.
For additional guidance, see `{baseDir}/docs/standard.md`.
## Skill Structure
A skill is a directory with the following layout:
```
{skill-name}/SKILL.md # Required — skill description and usage
{skill-name}/scripts/ # Optional — executable scripts
{skill-name}/workflows/ # Optional — process guides
{skill-name}/docs/ # Optional — supplementary documentation
```
## Writing Requirements
**SKILL.md should be concise.** It serves as a table of contents for workflows — list each workflow file path with the scenario that triggers it. For supplementary documentation, use `docs/`.
## Scripts ## Scripts
### update-skills ### update-skills
Pull latest ClawSkills from git-hangman-lab, then run learn.sh to install/update skills to `{AGENT_WORKSPACE}/skills`. Pull latest ClawSkills and install/update skills to the agent workspace.
```bash ```bash
claw-skills/scripts/update-skills {baseDir}/scripts/update-skills
``` ```
### promote-improvements ### promote-improvements
Create and force-push a branch named after the agent (via `ego-mgr get name`) from `{AGENT_WORKSPACE}`. Create a branch named after the agent and force-push local changes for review.
```bash ```bash
claw-skills/scripts/promote-improvements {baseDir}/scripts/promote-improvements
``` ```
## Workflows ## Workflows
### fix-skills - `{baseDir}/workflows/create-skills.md` — When you notice a reusable pattern with no existing skill covering it.
- `{baseDir}/workflows/fix-skills.md` — When a skill or its scripts fail or produce unexpected results.
- `{baseDir}/workflows/improve-skills.md` — When a skill has misleading descriptions, missing coverage, or suboptimal behavior.
When a skill or its scripts fail to produce expected results, or throw errors: ## Reference
> **Do not resort to workarounds lightly.** - `{baseDir}/docs/standard.md` — Skill structure, layer responsibilities, and writing requirements.
> Follow `{baseDir}/workflows/fix-skills.md` — identify the root cause first, then fix properly.
### improve-skills
When using a skill and you find:
- Misleading or ambiguous descriptions
- Missing coverage for your use case
- Suboptimal or confusing behavior
> Follow `{baseDir}/workflows/improve-skills.md` to improve it.
### create-skills
When you notice patterns or workflows that could improve efficiency but have no skill covering them:
> Follow `{baseDir}/workflows/create-skills.md` to create a new skill.

View File

@@ -1,43 +1,104 @@
# Skill Authoring Guide # Skill Authoring Standard
## Skill Structure ## Anatomy of a Skill
A skill is a directory with the following layout: A skill is a directory with up to four layers:
``` ```
{skill-name}/SKILL.md # Required — skill description and usage {skill-name}/
{skill-name}/scripts/ # Optional — executable scripts SKILL.md # Required — the menu
{skill-name}/workflows/ # Optional — process guides scripts/ # Optional — the kitchen tools
{skill-name}/docs/ # Optional — supplementary documentation workflows/ # Optional — the recipes
docs/ # Optional — the reference manual
``` ```
## Writing Requirements Each layer has a single responsibility:
**SKILL.md must start with a YAML frontmatter block:** | Layer | Role | Analogy | Contains | Does NOT contain |
|-------|------|---------|----------|------------------|
| **SKILL.md** | Router | Menu | What's available + when to use it | Process details, standards, how-tos |
| **scripts/** | Automation | Kitchen tools | Fixed-logic executables | Judgment calls, contextual decisions |
| **workflows/** | Process guide | Recipes | Step-by-step procedures requiring judgment | Standards, naming rules, structure specs |
| **docs/** | Reference | Reference manual | Facts, standards, specifications | Procedures, step-by-step instructions |
```yaml ### How they relate
```
Agent reads SKILL.md
→ finds the right script or workflow
→ workflow references docs/ for standards when needed
```
## SKILL.md — The Menu
SKILL.md is the first thing an agent reads. It answers two questions: **what's available** and **when to use it**.
### Format
```markdown
--- ---
name: {skill-name} name: {skill-name}
description: {when-to-use} description: {one-line description of when to use this skill}
--- ---
> Execution notes (e.g., "All scripts must be executed via pcexec")
## Scripts
List each script with invocation syntax and a one-line description.
Group related scripts under a subheading if needed.
## Workflows
List each workflow file path with the trigger condition (when to use it).
## Reference
Point to docs/ if the skill has reference material.
``` ```
**SKILL.md body should be concise.** It serves as a table of contents for workflows — list each workflow file path with the scenario that triggers it. For supplementary documentation, use `docs/`. ### Rules
> **All skill-related documentation must be written in English.** - **Concise.** One-line descriptions per script/workflow. No multi-paragraph explanations.
- **No process details.** Don't describe how to do something — that belongs in workflows/.
- **No standards or rules.** Don't define naming conventions or structure — that belongs in docs/.
- **Warnings and prerequisites** are allowed as short callouts (e.g., "do not run unless explicitly requested").
## When to Use Scripts vs Workflows ## scripts/ — The Kitchen Tools
Both scripts and workflows are parts of a skill — scripts live in `{skill-name}/scripts/`, workflows in `{skill-name}/workflows/`. Scripts handle operations that are **completely fixed** — the steps are predictable, the logic doesn't change based on context.
- **Scripts** — handle logic that is completely fixed. When the steps are predictable and always the same, encode them in a script. ### Rules
- **Workflows** — handle flexible situations. When context matters, decisions are needed, or the process is nuanced, describe it in a workflow document.
## Script Hint - Each script has a single responsibility
- Must be executable (`chmod +x`)
- Must be called via `pcexec` unless documented otherwise
- Use `AGENT_ID`, `AGENT_WORKSPACE` environment variables when behavior varies by agent
- Use `ego-mgr get <field>` for agent identity info inside scripts
When a script needs to behave differently based on the calling agent, use these environment variables: ## workflows/ — The Recipes
- `AGENT_ID` — the agent ID executing the script Workflows guide operations that **require judgment** — the steps vary depending on context, or decisions need to be made along the way.
- `AGENT_WORKSPACE` — the workspace of the agent executing the script
For more agent info, call `ego-mgr get <column>` inside the script. ### Rules
- Each workflow is a standalone markdown file
- Must be self-contained enough to follow independently
- Reference docs/ for standards (e.g., `> See docs/standard.md for naming conventions`) — don't repeat them inline
- Focus on **steps and decision points**, not rules
## docs/ — The Reference Manual
Docs hold **facts and standards** that don't change based on who's reading or what task they're doing.
### Rules
- Reference material only — no step-by-step procedures
- Standards, specifications, naming conventions, structure definitions
- Referenced by workflows and SKILL.md, never duplicated into them
## General Requirements
- **Language:** All skill documentation must be written in English
- **Naming:** Skill directories use kebab-case (e.g., `git-hangman-lab`)
- **Frontmatter:** SKILL.md must start with a YAML frontmatter block containing `name` and `description`

View File

@@ -1,30 +1,12 @@
# create-skills # Create Skills
Used when you notice patterns or workflows that could improve efficiency but have no skill covering them. When you notice a reusable pattern with no existing skill covering it.
> See `{baseDir}/docs/standard.md` for skill structure and layer responsibilities.
## Principle ## Principle
Not every repetitive task needs to become a skill. Ask first: is this pattern general enough to warrant abstraction? Not every repetitive task needs a skill. Ask first: is this pattern general enough to warrant abstraction?
> See `{baseDir}/docs/standard.md` for skill structure and writing requirements.
## When to Add a Script vs a Workflow to a Skill
A skill can contain scripts, workflows, or both. When extending a skill, decide which type to add:
**Add a script when:**
- The steps are fixed, results are predictable
- The operation recurs across different agents/workspaces
- Involves external system calls (git, keycloak, file ops, etc.)
**Add a workflow when:**
- Steps vary depending on context — the process needs human judgment or situational decisions
- The scenario is too nuanced for rigid logic
**Not worth abstracting:**
- One-off task
> Conversational/analytical work *can* be worth a workflow — e.g., an interview flow (`recruitment/intviewer`) that guides through questions contextually is a valid workflow.
## Process ## Process
@@ -32,23 +14,29 @@ A skill can contain scripts, workflows, or both. When extending a skill, decide
- Record the repeating sequence of operations - Record the repeating sequence of operations
- Analyze: what are you doing repeatedly across tasks? - Analyze: what are you doing repeatedly across tasks?
- Evaluate: is this operation general-purpose or a one-off special case? - Evaluate: is this general-purpose or a one-off?
### 2. Decide the Approach ### 2. Decide the Approach
Based on the criteria above, determine whether this should be a new skill, or a script/workflow added to an existing skill. Should this be a new skill, or a script/workflow added to an existing skill?
### 3. Design the Skill **Add a script when:**
- The steps are fixed and results are predictable
- The operation recurs across different agents/workspaces
- Involves external system calls (git, keycloak, file ops, etc.)
- **Name:** kebab-case (e.g., `git-clone-repo`, `keycloak-create-user`) **Add a workflow when:**
- **SKILL.md contents:** - Steps vary depending on context or require judgment
- Description: what this skill does - The scenario is too nuanced for rigid logic
- Use cases: when to use it
- Scripts: all related scripts and how to call them **Not worth abstracting:**
- **Scripts:** - One-off tasks
- Place under `scripts/`
- Each script has a single responsibility ### 3. Design
- Provide `--help` or `-h` support
- **Name:** kebab-case (e.g., `git-clone-repo`)
- **SKILL.md:** Router only — list scripts with invocation syntax, workflows with trigger conditions
- **Scripts:** Single responsibility each, placed under `scripts/`
### 4. Implement ### 4. Implement

View File

@@ -1,13 +1,13 @@
# fix-skills # Fix Skills
Used when a skill or its scripts fail to produce expected results, or throw errors. When a skill or its scripts fail to produce expected results, or throw errors.
> See `{baseDir}/docs/standard.md` for skill structure and layer responsibilities.
## Principle ## Principle
**Do not resort to workarounds lightly.** Identify the root cause first, then fix properly. **Do not resort to workarounds lightly.** Identify the root cause first, then fix properly.
> See `{baseDir}/docs/standard.md` for skill structure and writing requirements.
## Process ## Process
### 1. Gather Information ### 1. Gather Information
@@ -20,24 +20,23 @@ Used when a skill or its scripts fail to produce expected results, or throw erro
Investigate in this order: Investigate in this order:
1. **Are inputs/parameters correct?** — Do they match what the script or tool expects? 1. **Are inputs/parameters correct?** — Do they match what the script expects?
2. **Are dependencies satisfied?**Are required secrets, tokens, config files present? 2. **Are dependencies satisfied?**Required secrets, tokens, config files present?
3. **Is there a bug in the script logic?** — Read the source, add `set -x` if needed 3. **Is there a bug in the script logic?** — Read the source, add `set -x` if needed
4. **Is there a design flaw in the skill?** — Does the logic actually cover this scenario? 4. **Is there a design flaw?** — Does the logic actually cover this scenario?
### 3. Pinpoint the File ### 3. Pinpoint the File
- Identify which file and which line the problem is in - Identify which file and which line the problem is in
- If it's a skill issue → follow the [improve-skills](./improve-skills.md) workflow - If it's a skill issue → follow the improve-skills workflow
- If it's an execution environment issue → document in memory/ - If it's an environment issue → document in memory/
### 4. Fix ### 4. Fix
- Test the fix locally - Test the fix locally
- If skill files need to be modified → follow improve-skills process to PR or push to a branch - If skill files need modification → follow improve-skills process
- Avoid introducing new side effects - Avoid introducing new side effects
### 5. Verify ### 5. Verify
- Reproduce the original scenario; confirm the issue is resolved - Reproduce the original scenario; confirm the issue is resolved
- Log the fix in memory/YYYY-MM-DD.md

View File

@@ -1,24 +1,13 @@
# improve-skills # Improve Skills
Used when a skill or workflow has one of these problems: When a skill has misleading descriptions, missing coverage, or suboptimal behavior.
- Misleading or ambiguous > See `{baseDir}/docs/standard.md` for skill structure and layer responsibilities.
- Missing coverage for your use case
- Suboptimal or confusing behavior
## Principle ## Principle
Improvement is better than workaround. Fix problems when you find them, so others don't hit the same pitfall. Improvement is better than workaround. Fix problems when you find them, so others don't hit the same pitfall.
## Requirement
**All skill-related documentation must be written in English.** This applies to:
- Creating new skills or workflows
- Improving or correcting existing skills
- Any other documentation within skills
> See `{baseDir}/docs/standard.md` for skill structure and writing requirements.
## Process ## Process
### 1. Identify the Problem ### 1. Identify the Problem
@@ -29,24 +18,25 @@ Improvement is better than workaround. Fix problems when you find them, so other
### 2. Assess Impact ### 2. Assess Impact
- How many people will this affect? - How many agents will this affect?
- Is it a design issue or a documentation issue? - Is it a design issue or a documentation issue?
- What's the complexity of the fix? - What's the complexity of the fix?
### 3. Design the Fix ### 3. Design the Fix
- **Documentation issue** → update SKILL.md or related descriptions - **Documentation issue** → update SKILL.md or docs/
- **Logic flaw** → modify the script or skill logic - **Logic flaw** → modify the script
- **Missing coverage** → add a new workflow or script - **Missing coverage** → add a new workflow or script
- **Process issue** → redesign the workflow - **Process issue** → redesign the workflow
### 4. Implement ### 4. Implement
- Make changes locally or on a branch - Make changes locally
- Update SKILL.md if behavior changed - Update SKILL.md if behavior changed
- Test if the change is significant - Test if the change is significant
### 5. Submit ### 5. Submit
- Call `{baseDir}/scripts/promote-improvements` to push to your branch. Call `{baseDir}/scripts/promote-improvements` to push to your branch.
- Commit message should describe what was changed and why
Commit message should describe what was changed and why.

View File

@@ -3,86 +3,53 @@ name: git-hangman-lab
description: Git operations for hangman-lab.top - manage accounts, tokens, repositories, and Gitea settings. description: Git operations for hangman-lab.top - manage accounts, tokens, repositories, and Gitea settings.
--- ---
> ⚠️ **Note**: All scripts must be executed via the `pcexec` tool. > All scripts must be executed via the `pcexec` tool.
## Git Operations ## Scripts
### Check Git Credentials ### Account & Credentials
Verify git credentials are configured correctly. | Command | Description |
|---------|-------------|
| `{baseDir}/scripts/git-ctrl check-git-cred` | Verify git credentials are configured correctly |
| `{baseDir}/scripts/git-ctrl create-git-account` | Create a new git account and configure access |
| `{baseDir}/scripts/git-ctrl generate-access-token` | Generate an access token for the current user |
| `{baseDir}/scripts/git-ctrl reset-password` | Reset password (reads username from secret-mgr) |
```bash > **create-git-account**: Do not execute unless explicitly requested. Contact **agent-resource-director** or **hangman** first.
{baseDir}/scripts/git-ctrl check-git-cred
```
### Create Git Account
Create a new git account and configure access.
> ⚠️ **Warning**: Do not execute this command unless explicitly requested. If you don't have a git account, contact **agent-resource-director** or **hangman** to guide you through the process.
```bash
{baseDir}/scripts/git-ctrl create-git-account
```
### Generate Access Token
Generate an access token for the current user.
```bash
{baseDir}/scripts/git-ctrl generate-access-token
```
### Repository Operations ### Repository Operations
Manage repositories via `git-ctrl repo`: | Command | Description |
|---------|-------------|
```bash | `{baseDir}/scripts/git-ctrl repo create <repo-name>` | Create repo at `${AGENT_WORKSPACE}/<repo-name>` |
{baseDir}/scripts/git-ctrl repo create <repo-name> | `{baseDir}/scripts/git-ctrl repo get-latest <repo-name> [branch] [--recursive] [--force]` | Pull latest or clone if missing |
{baseDir}/scripts/git-ctrl repo add-collaborators --user <user> --repo <repo> | `{baseDir}/scripts/git-ctrl repo add-collaborators --user <user> --repo <repo>` | Add a collaborator |
{baseDir}/scripts/git-ctrl repo list-all | `{baseDir}/scripts/git-ctrl repo list-all` | List all visible repositories |
{baseDir}/scripts/git-ctrl repo config --repo-path <path> [--recursive] | `{baseDir}/scripts/git-ctrl repo config --repo-path <path> [--recursive]` | Configure repo credentials |
```
> `create` creates the repo at `${AGENT_WORKSPACE}/${repo-name}`
### Pull Request Operations ### Pull Request Operations
Manage pull requests on git.hangman-lab.top. | Command | Description |
|---------|-------------|
| `{baseDir}/scripts/git-ctrl pr create <repo-path> <head> <base> [title] [body]` | Create a PR |
| `{baseDir}/scripts/git-ctrl pr list <repo-path>` | List PRs |
| `{baseDir}/scripts/git-ctrl pr show <repo-path> <index>` | Show PR details |
| `{baseDir}/scripts/git-ctrl pr commits <repo-path> <index>` | List PR commits |
| `{baseDir}/scripts/git-ctrl pr merge <repo-path> <index> <do> [commit-id] [title] [message]` | Merge a PR |
```bash > **pr merge `<do>`**: `merge`, `squash`, `rebase`, or `manually-merged`
{baseDir}/scripts/git-ctrl pr create <repo-local-path> <head-branch> <base-branch> [pr-title] [pr-body] > Access token is auto-generated if not found.
{baseDir}/scripts/git-ctrl pr list <repo-local-path>
{baseDir}/scripts/git-ctrl pr commits <repo-local-path> <pr-index>
{baseDir}/scripts/git-ctrl pr merge <repo-local-path> <pr-index> <do> [commit-id] [title] [message]
{baseDir}/scripts/git-ctrl pr show <repo-local-path> <pr-index>
```
> **Note**: The access token will be automatically generated if not found. ### Gitea Settings
> **`<do>`** can be: `merge`, `squash`, `rebase`, `manually-merged` | Command | Description |
|---------|-------------|
| `{baseDir}/scripts/git-ctrl link-keycloak` | Link Keycloak account with Gitea (OAuth binding) |
| `{baseDir}/scripts/git-ctrl external-login-ctrl --enable/--disable` | Enable or disable local login on Gitea |
### Link Keycloak Account ### Package Publishing
Link Keycloak account with Gitea (for OAuth binding). | Command | Description |
|---------|-------------|
```bash | `{baseDir}/scripts/git-ctrl publish-package <repo-path>` | Publish a package to the Gitea registry |
{baseDir}/scripts/git-ctrl link-keycloak
```
### External Login Control
Enable or disable local login on Gitea.
```bash
{baseDir}/scripts/git-ctrl external-login-ctrl --enable
{baseDir}/scripts/git-ctrl external-login-ctrl --disable
```
### Reset Password
Reset password for the current user (reads username from secret-mgr).
```bash
{baseDir}/scripts/git-ctrl reset-password
```

View File

@@ -3,40 +3,15 @@ name: keycloak-hangman-lab
description: Keycloak operations for hangman-lab.top - manage accounts, email verification, and passwords. description: Keycloak operations for hangman-lab.top - manage accounts, email verification, and passwords.
--- ---
> ⚠️ **Note**: All scripts must be executed via the `pcexec` tool. > All scripts must be executed via the `pcexec` tool.
## Keycloak Operations ## Scripts
### Create Keycloak Account | Command | Description |
|---------|-------------|
| `{baseDir}/scripts/kc-ctrl create-keycloak-account` | Create a new Keycloak account |
| `{baseDir}/scripts/kc-ctrl verify-email` | Verify user email in Keycloak |
| `{baseDir}/scripts/kc-ctrl set-name` | Set user firstName and lastName |
| `{baseDir}/scripts/kc-ctrl reset-password` | Reset password (reads username from secret-mgr) |
Create a new Keycloak account. > **create-keycloak-account**: Do not execute unless explicitly requested. Contact **agent-resource-director** or **hangman** first.
> ⚠️ **Warning**: Do not execute this command unless explicitly requested. If you don't have a Keycloak account, contact **agent-resource-director** or **hangman** to guide you through the process.
```bash
{baseDir}/scripts/kc-ctrl create-keycloak-account
```
### Verify Email
Verify user email in Keycloak.
```bash
{baseDir}/scripts/kc-ctrl verify-email
```
### Set User Name
Set user firstName and lastName in Keycloak.
```bash
{baseDir}/scripts/kc-ctrl set-name
```
### Reset Password
Reset password for the current user (reads username from secret-mgr).
```bash
{baseDir}/scripts/kc-ctrl reset-password
```

View File

@@ -1,72 +1,18 @@
--- ---
name: recruitment name: recruitment
description: Onboard new agents into OpenClaw. Use when creating a new agent, adding an agent to the system, or setting up a new agent workspace. Triggers on requests like "new agent", "add agent", "create agent", "recruit agent", "onboard agent". description: Onboard new agents into OpenClaw. Triggers on "new agent", "add agent", "create agent", "recruit agent", "onboard agent".
--- ---
# Recruitment Skill > Scripts must be executed via `pcexec`. The onboard script uses `proxy-pcexec`.
Onboard new agents into OpenClaw with binding configuration.
## Usage
```bash
new-agent --type openclaw --agent-id <agent-id> [--model <primary-model>]
new-agent --type contractor --contractor-provider <claude|gemini> --agent-id <agent-id>
```
## Workflow
When a request to create a new agent is received, follow this workflow:
### Step 1 — Gather Requirements
Communicate with the requester to collect the following:
- New agent's `agent-id`
- New agent's primary model (`--model`)
- New agent's role and position
- Whether the agent is a contractor agent (default: not a contractor)
### Step 2 — Create Agent
Execute `{baseDir}/scripts/new-agent` with the gathered parameters:
```bash
# openclaw type
new-agent --type openclaw --agent-id <agent-id> --model <primary-model>
# contractor type
new-agent --type contractor --contractor-provider <claude|gemini> --agent-id <agent-id>
```
### Step 3 — Interview
Use the `create-discussion-channel` tool to start an interview with the new agent:
- Participant: `interviewee`
- Discussion guide: "<@YOUR_DISCORD_USER_ID> please refer to {baseDir}/workflow/interview.md"
> Note: Replace `YOUR_DISCORD_USER_ID` with your actual Discord user ID. If unsure, use `ego-mgr get discord-id` (via pcexec) to look it up.
After receiving the discussion callback, review the discussion summary:
- If it contains the agent's **name** and **gender** → proceed to Step 4
- If either field is missing → attempt to gather the missing information via another `create-discussion-channel` call
- If still unavailable → notify the requester and proceed without it
### Step 4 — Onboard
Use `proxy-pcexec` to call `{baseDir}/scripts/onboard`:
- `proxy-for`: new agent's `agent-id`
- Parameters: `--name`, `--role`, `--position`, `--gender`, `--bot-token`
### Step 5 — Report
Notify the requester that onboarding is complete.
## Scripts ## Scripts
### new-agent | Command | Description |
|---------|-------------|
| `{baseDir}/scripts/new-agent --type openclaw --agent-id <id> [--model <model>]` | Create and register an OpenClaw agent |
| `{baseDir}/scripts/new-agent --type contractor --contractor-provider <claude\|gemini> --agent-id <id>` | Create and register a contractor agent |
| `{baseDir}/scripts/onboard --name <name> --role <role> --position <pos> --gender <gender> --bot-token <token>` | Set up agent identity and Discord binding (call via `proxy-pcexec` with `proxy-for: <agent-id>`) |
Creates and registers the agent, then configures the `interviewee` Discord account binding. ## Workflows
### onboard - `{baseDir}/workflows/recruitment.md` — Full onboarding flow: gather requirements, create agent, interview, onboard, report.
Sets up ego-mgr identity fields and configures the agent's Discord account using the name/gender collected during interview.

View File

@@ -0,0 +1,48 @@
# Recruitment Workflow
Full onboarding flow for new agents. Follow these steps when a request to create a new agent is received.
> See `claw-skills/docs/standard.md` for skill structure and writing standards.
## Step 1 — Gather Requirements
Communicate with the requester to collect:
- New agent's `agent-id`
- New agent's primary model (`--model`)
- New agent's role and position
- Whether the agent is a contractor (default: no)
## Step 2 — Create Agent
Execute `{baseDir}/scripts/new-agent` with the gathered parameters:
```bash
# OpenClaw type
new-agent --type openclaw --agent-id <agent-id> --model <primary-model>
# Contractor type
new-agent --type contractor --contractor-provider <claude|gemini> --agent-id <agent-id>
```
## Step 3 — Interview
Use the `create-discussion-channel` tool to start an interview with the new agent:
- Participant: `interviewee`
- Discussion guide: `<@YOUR_DISCORD_USER_ID> please refer to {baseDir}/workflows/interviewer.md`
> Use `ego-mgr get discord-id` (via pcexec) to look up your Discord user ID if unsure.
After receiving the discussion callback, review the summary:
- Contains agent's **name** and **gender** → proceed to Step 4
- Missing either field → attempt another `create-discussion-channel` call
- Still unavailable → notify the requester and proceed without it
## Step 4 — Onboard
Use `proxy-pcexec` to call `{baseDir}/scripts/onboard`:
- `proxy-for`: new agent's `agent-id`
- Parameters: `--name`, `--role`, `--position`, `--gender`, `--bot-token`
## Step 5 — Report
Notify the requester that onboarding is complete.