clawteam-dev: Скилл для локальной разработки и отладки

--- name: clawteam-dev description: > Use this skill when working inside the ClawTeam repository itself: local development, debugging, reviewing, testing, validating multi-agent flows, or checking whether a code change actually works end-to-end. Use the repository bootstrap scripts to standardize the local `clawteam` command and to wire project-local `.agents` and `.claude` skills back to this repository. This skill is repository-development oriented, not a general end-user usage guide. version: 0.2.0 --- # ClawTeam Local Development This skill is for developing and validating ClawTeam inside the ClawTeam repository. Use it when the task is about changing ClawTeam itself, testing local behavior, or verifying multi-agent workflows against the current checkout. ## Development Bootstrap Standardize the local development environment with the bootstrap script: ```bash bash scripts/bootstrap_clawteam_dev.sh ``` This script lives in `scripts/bootstrap_clawteam_dev.sh` inside this skill folder. This script does all of the following: - Creates a fixed uv environment at `~/.clawteam-venv` - Installs the current repository into that environment with dev dependencies - Writes `~/.local/bin/clawteam` to point at the fixed environment - Adds a `clawteam()` shell function block to `~/.bashrc` After it finishes: ```bash source ~/.bashrc clawteam --version ``` Use this bootstrap whenever you want the same `clawteam` command across different Python environments on the machine. ## Project Skill Wiring To wire another local project so its `./.agents` and `./.claude` directories use this repository's local ClawTeam skills directly: ```bash bash scripts/link_local_clawteam_skills.sh /path/to/project ``` This script lives in `scripts/link_local_clawteam_skills.sh` inside this skill folder. This creates these symlinks inside the target project: - `./.agents/skills/clawteam` - `./.claude/skills/clawteam` Run the same script again any time you want to refresh or recreate those links. ## Typical Uses - Run targeted local validation after code changes - Reproduce a spawn / board / task / inbox / harness bug - Smoke-test the real CLI in tmux or subprocess mode - Review ClawTeam workflows end-to-end from the current repository checkout ## Fast Validation Prefer the smallest validation that proves the change. ```bash ruff check clawteam/ tests/ pytest tests/<target_file>.py -q ``` Use broader runs only when the change crosses modules: ```bash pytest tests/test_cli_commands.py -q pytest tests/test_spawn_backends.py -q pytest tests/test_harness.py tests/test_event_bus.py -q ``` ## Prerequisites - `clawteam` command available - `tmux` available - A supported CLI agent such as `claude` or `codex` if you are spawning real workers - Current directory is the ClawTeam git repo when testing worktree isolation or local source changes ## Local Smoke Test Use this when you need a real multi-agent workflow check instead of unit tests. ```bash clawteam team spawn-team dev-smoke -d "Local ClawTeam smoke test" -n leader clawteam task create dev-smoke "Smoke test worker" -o worker1 -p high clawteam spawn --team dev-smoke --agent-name worker1 --task "Report your status to leader and mark the task completed when done." clawteam board show dev-smoke clawteam task wait dev-smoke --timeout 300 --poll-interval 5 ``` If you are validating harness behavior specifically: ```bash clawteam harness conduct dev-harness --goal "Create a small implementation plan and execute it with one worker" --cli codex --agents 1 ``` ## Cleanup Use the real ClawTeam commands instead of ad-hoc directory assumptions whenever possible: ```bash clawteam team cleanup dev-smoke clawteam team cleanup dev-harness ``` If a crashed tmux session or worktree is left behind, clean it up explicitly after inspecting it. ## Development Rules - Prefer `clawteam` commands over editing state files directly. - Prefer targeted tests over broad end-to-end runs unless the change crosses spawn/runtime/workflow boundaries. - Use `board`, `task wait`, and `team status` to observe behavior before assuming a bug is in the spawn layer. - When testing agent coordination, keep the team small first: one leader and one or two workers. - Only escalate to harness or full swarm tests when the lower-level task/spawn/inbox path already works.