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:
@@ -1,71 +1,34 @@
|
||||
---
|
||||
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
|
||||
|
||||
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/`.
|
||||
> All skill documentation must be written in English.
|
||||
|
||||
## Scripts
|
||||
|
||||
### 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
|
||||
claw-skills/scripts/update-skills
|
||||
{baseDir}/scripts/update-skills
|
||||
```
|
||||
|
||||
### 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
|
||||
claw-skills/scripts/promote-improvements
|
||||
{baseDir}/scripts/promote-improvements
|
||||
```
|
||||
|
||||
## 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.**
|
||||
> 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.
|
||||
- `{baseDir}/docs/standard.md` — Skill structure, layer responsibilities, and writing requirements.
|
||||
|
||||
@@ -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}/scripts/ # Optional — executable scripts
|
||||
{skill-name}/workflows/ # Optional — process guides
|
||||
{skill-name}/docs/ # Optional — supplementary documentation
|
||||
{skill-name}/
|
||||
SKILL.md # Required — the menu
|
||||
scripts/ # Optional — the kitchen tools
|
||||
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}
|
||||
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.
|
||||
- **Workflows** — handle flexible situations. When context matters, decisions are needed, or the process is nuanced, describe it in a workflow document.
|
||||
### Rules
|
||||
|
||||
## 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
|
||||
- `AGENT_WORKSPACE` — the workspace of the agent executing the script
|
||||
Workflows guide operations that **require judgment** — the steps vary depending on context, or decisions need to be made along the way.
|
||||
|
||||
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`
|
||||
|
||||
@@ -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
|
||||
|
||||
Not every repetitive task needs to become 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.
|
||||
Not every repetitive task needs a skill. Ask first: is this pattern general enough to warrant abstraction?
|
||||
|
||||
## Process
|
||||
|
||||
@@ -32,23 +14,29 @@ A skill can contain scripts, workflows, or both. When extending a skill, decide
|
||||
|
||||
- Record the repeating sequence of operations
|
||||
- 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
|
||||
|
||||
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`)
|
||||
- **SKILL.md contents:**
|
||||
- Description: what this skill does
|
||||
- Use cases: when to use it
|
||||
- Scripts: all related scripts and how to call them
|
||||
- **Scripts:**
|
||||
- Place under `scripts/`
|
||||
- Each script has a single responsibility
|
||||
- Provide `--help` or `-h` support
|
||||
**Add a workflow when:**
|
||||
- Steps vary depending on context or require judgment
|
||||
- The scenario is too nuanced for rigid logic
|
||||
|
||||
**Not worth abstracting:**
|
||||
- One-off tasks
|
||||
|
||||
### 3. Design
|
||||
|
||||
- **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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
**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
|
||||
|
||||
### 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:
|
||||
|
||||
1. **Are inputs/parameters correct?** — Do they match what the script or tool expects?
|
||||
2. **Are dependencies satisfied?** — Are required secrets, tokens, config files present?
|
||||
1. **Are inputs/parameters correct?** — Do they match what the script expects?
|
||||
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
|
||||
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
|
||||
|
||||
- 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 an execution environment issue → document in memory/
|
||||
- If it's a skill issue → follow the improve-skills workflow
|
||||
- If it's an environment issue → document in memory/
|
||||
|
||||
### 4. Fix
|
||||
|
||||
- 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
|
||||
|
||||
### 5. Verify
|
||||
|
||||
- Reproduce the original scenario; confirm the issue is resolved
|
||||
- Log the fix in memory/YYYY-MM-DD.md
|
||||
|
||||
@@ -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
|
||||
- Missing coverage for your use case
|
||||
- Suboptimal or confusing behavior
|
||||
> See `{baseDir}/docs/standard.md` for skill structure and layer responsibilities.
|
||||
|
||||
## Principle
|
||||
|
||||
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
|
||||
|
||||
### 1. Identify the Problem
|
||||
@@ -29,24 +18,25 @@ Improvement is better than workaround. Fix problems when you find them, so other
|
||||
|
||||
### 2. Assess Impact
|
||||
|
||||
- How many people will this affect?
|
||||
- How many agents will this affect?
|
||||
- Is it a design issue or a documentation issue?
|
||||
- What's the complexity of the fix?
|
||||
|
||||
### 3. Design the Fix
|
||||
|
||||
- **Documentation issue** → update SKILL.md or related descriptions
|
||||
- **Logic flaw** → modify the script or skill logic
|
||||
- **Documentation issue** → update SKILL.md or docs/
|
||||
- **Logic flaw** → modify the script
|
||||
- **Missing coverage** → add a new workflow or script
|
||||
- **Process issue** → redesign the workflow
|
||||
|
||||
### 4. Implement
|
||||
|
||||
- Make changes locally or on a branch
|
||||
- Make changes locally
|
||||
- Update SKILL.md if behavior changed
|
||||
- Test if the change is significant
|
||||
|
||||
### 5. Submit
|
||||
|
||||
- Call `{baseDir}/scripts/promote-improvements` to push to your branch.
|
||||
- Commit message should describe what was changed and why
|
||||
Call `{baseDir}/scripts/promote-improvements` to push to your branch.
|
||||
|
||||
Commit message should describe what was changed and why.
|
||||
|
||||
@@ -3,86 +3,53 @@ name: git-hangman-lab
|
||||
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
|
||||
{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
|
||||
```
|
||||
> **create-git-account**: Do not execute unless explicitly requested. Contact **agent-resource-director** or **hangman** first.
|
||||
|
||||
### Repository Operations
|
||||
|
||||
Manage repositories via `git-ctrl repo`:
|
||||
|
||||
```bash
|
||||
{baseDir}/scripts/git-ctrl repo create <repo-name>
|
||||
{baseDir}/scripts/git-ctrl repo add-collaborators --user <user> --repo <repo>
|
||||
{baseDir}/scripts/git-ctrl repo list-all
|
||||
{baseDir}/scripts/git-ctrl repo config --repo-path <path> [--recursive]
|
||||
```
|
||||
|
||||
> `create` creates the repo at `${AGENT_WORKSPACE}/${repo-name}`
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `{baseDir}/scripts/git-ctrl repo create <repo-name>` | Create repo at `${AGENT_WORKSPACE}/<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>` | Add a collaborator |
|
||||
| `{baseDir}/scripts/git-ctrl repo list-all` | List all visible repositories |
|
||||
| `{baseDir}/scripts/git-ctrl repo config --repo-path <path> [--recursive]` | Configure repo credentials |
|
||||
|
||||
### 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
|
||||
{baseDir}/scripts/git-ctrl pr create <repo-local-path> <head-branch> <base-branch> [pr-title] [pr-body]
|
||||
{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>
|
||||
```
|
||||
> **pr merge `<do>`**: `merge`, `squash`, `rebase`, or `manually-merged`
|
||||
> Access token is auto-generated if not found.
|
||||
|
||||
> **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).
|
||||
|
||||
```bash
|
||||
{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
|
||||
```
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `{baseDir}/scripts/git-ctrl publish-package <repo-path>` | Publish a package to the Gitea registry |
|
||||
|
||||
@@ -3,40 +3,15 @@ name: keycloak-hangman-lab
|
||||
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.
|
||||
|
||||
> ⚠️ **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
|
||||
```
|
||||
> **create-keycloak-account**: Do not execute unless explicitly requested. Contact **agent-resource-director** or **hangman** first.
|
||||
|
||||
@@ -1,72 +1,18 @@
|
||||
---
|
||||
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
|
||||
|
||||
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 must be executed via `pcexec`. The onboard script uses `proxy-pcexec`.
|
||||
|
||||
## 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
|
||||
|
||||
Sets up ego-mgr identity fields and configures the agent's Discord account using the name/gender collected during interview.
|
||||
- `{baseDir}/workflows/recruitment.md` — Full onboarding flow: gather requirements, create agent, interview, onboard, report.
|
||||
|
||||
48
recruitment/workflows/recruitment.md
Normal file
48
recruitment/workflows/recruitment.md
Normal 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.
|
||||
Reference in New Issue
Block a user