agent-manager-skill ยท diff
git:20260827.e9312a3 to git:20260827.ebd5ea3
27 added, 1 removed. Audit A to A.
---
name: agent-manager-skill
- description: "Manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling."
+ description: Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.
category: bdb-core
risk: unknown
source: community
date_added: "2026-02-27"
---
# Agent Manager Skill
## When to Use
Use this skill when you need to:
- run multiple local CLI agents in parallel (separate tmux sessions)
- start/stop agents and tail their logs
- assign tasks to agents and monitor output
- schedule recurring agent work (cron)
## Prerequisites
Install `agent-manager-skill` in your workspace:
```bash
git clone https://github.com/fractalmind-ai/agent-manager-skill.git
```
## Common commands
```bash
python3 agent-manager/scripts/main.py doctor
python3 agent-manager/scripts/main.py list
python3 agent-manager/scripts/main.py start EMP_0001
python3 agent-manager/scripts/main.py monitor EMP_0001 --follow
python3 agent-manager/scripts/main.py assign EMP_0002 <<'EOF'
Follow teams/fractalmind-ai-maintenance.md Workflow
EOF
```
## Notes
- Requires `tmux` and `python3`.
- Agents are configured under an `agents/` directory (see the repo for examples).
## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
+
+ ## 1. Overview
+ This skill provides domain-specific logic and rules for its respective BDB pipeline component to ensure standardization across multi-agent workflows.
+
+ ## 3. Core Process
+ 1. Read the provided context and ensure preconditions are met.
+ 2. Run the required script or tool and confirm the state change.
+ 3. Verify exit codes, file modifications, or DB counts to guarantee success before reporting completion.
+
+ ## 4. Common Rationalizations
+ | Rationalization | Reality |
+ |---|---|
+ | "The code change was small, so I skipped updating OpenWiki docs." | Every state change must be reflected in the relevant system records. |
+ | "The ingest script exited without an error, so the memB index must be updated." | Silent failures happen; explicit verification of the side effect is mandatory. |
+ | "I'll let the /startcycle proceed without a defined rollback path." | Proceeding without a rollback path corrupts the workflow integrity and safety. |
+ | "I trust the cached agent registry instead of rescanning after a skill change." | Caches stale out quickly; explicit rescans prevent ghost failures. |
+
+ ## 5. Red Flags
+ - Bypassing the verification step after a script execution.
+ - Proceeding to the next pipeline stage without confirming the previous stage's side effects.
+ - Ignoring domain-specific constraints listed in this skill.
+
+ ## 6. Verification
+ - [ ] Verified script exit codes are explicitly checked.
+ - [ ] Confirmed target files or database records reflect the expected change.
+ - [ ] Ensured no silent failures were ignored before reporting success.