القائمة
Factory worker guide for task execution in CAS multi-agent sessions. Use when acting as a worker to execute assigned tasks, report progress, handle blockers, and communicate with the supervisor.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
How to store and retrieve persistent memories using CAS. Use for facts, preferences, learnings, and context that should persist across sessions. Trigger when discovering patterns, fixing bugs, resolving config issues, or learning how unfamiliar code works.
Search across CAS content (memories, tasks, rules, skills, code). Use when needing to find information, understand codebase, or locate specific patterns. Supports hybrid BM25+semantic search, code symbol search, grep, context, and entity operations.
Coding Agent System - unified memory, tasks, rules, and skills. Use when you need to remember something, track work, search past context, or manage tasks. (project)
Quick startup checklist for factory supervisors. Use at the beginning of a factory session to load context, check EPICs, and confirm worker availability.
Factory supervisor guide for multi-agent EPIC orchestration. Use when acting as supervisor to plan EPICs, spawn and coordinate workers, assign tasks, monitor progress, and merge completed work. Covers worker count strategy, conflict-free task coordination, epic branch workflow, and completion verification.
How to track work using CAS tasks instead of built-in TodoWrite. Use for persistent task tracking with priorities, dependencies, structured notes, and cross-session continuity.
| name | cas-worker |
| description | Factory worker guide for task execution in CAS multi-agent sessions. Use when acting as a worker to execute assigned tasks, report progress, handle blockers, and communicate with the supervisor. |
| managed_by | cas |
You execute tasks assigned by the Supervisor. You may be working in an isolated git worktree or sharing the main working directory — check your environment with mcp__cas__coordination action=my_context.
mcp__cas__task action=minemcp__cas__task action=start id=<task-id>mcp__cas__task action=show id=<task-id>mcp__cas__task action=notes id=<task-id> notes="..." note_type=progressmcp__cas__task action=close id=<task-id>If close returns verification-required guidance, message the supervisor to handle it.
Report immediately — don't spend time stuck:
mcp__cas__task action=notes id=<task-id> notes="Blocked: <reason>" note_type=blocker
mcp__cas__task action=update id=<task-id> status=blocked
Never use SendMessage. It is blocked in factory mode. Always use CAS coordination:
mcp__cas__coordination action=message target=supervisor message="<response>" summary="<brief summary>"
Use task notes for ongoing updates (note_type=progress|blocker|decision|discovery). The supervisor sees these in the TUI.
Message the supervisor when you complete a task or need help.
Before running mcp__cas__task action=close, verify your own work. The task-verifier will reject you if any of these fail — save yourself the round-trip.
# Must return zero results in your changed files
rg 'TODO|FIXME|XXX|HACK|unimplemented!|todo!' <changed_files>
rg 'for now|temporarily|placeholder|stub|workaround' <changed_files>
For every new function, struct, module, route, or handler you created:
# Verify it's actually called/imported somewhere outside its definition
rg 'your_new_function' src/
ast-grep --lang rust -p 'your_new_function($$$)' src/
If zero external references → you built it but didn't wire it in. Fix before closing.
Registration checklist:
Commands enum + match arm?# If you changed a function signature, verify all call sites compile
ast-grep --lang rust -p 'changed_function($$$)' src/
cargo test # or equivalent for the project
# Check for allow(dead_code) on your new code
rg '#\[allow\(dead_code\)\]' <changed_files>
Only close after all checks pass. The verifier will catch what you miss — but rejections cost time.
Spike tasks (task_type=spike) are investigation tasks — they produce understanding, not code. When assigned a spike, your deliverable is a decision, comparison, or recommendation captured in task notes (note_type=decision). Spike acceptance criteria are question-based (e.g., "Which approach handles our constraints?").
Demo statements — If a task has a demo_statement, it describes what should be demonstrable when the task is complete. Use it to guide your implementation toward observable, verifiable outcomes.
note_type=decisionIf the supervisor asks you to sync, safely rebase without losing WIP:
git stash # save uncommitted work
git rebase <branch> # use the branch name the supervisor gives you (e.g. master, epic/<slug>)
git stash pop # restore WIP
Important: Use the local branch name the supervisor specifies (e.g. master, epic/<slug>), NOT origin/master. In factory mode, the supervisor merges into the local branch directly, so origin/master is stale.
If the rebase has conflicts, resolve them before popping the stash. Message the supervisor if you're stuck.
Submodule not initialized: Worktrees don't include submodules. Symlink from the main repo:
ln -s /path/to/main/repo/vendor/<submodule> vendor/<submodule>
Build errors in code you didn't touch: Another worker may be changing related files. Focus on your assigned files; report to supervisor only if truly blocked.