القائمة
When adding a new command or event that changes the task DAG and the secretary should know about it immediately (not wait for the 3-minute ContextRefresher poll).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
How the multi-backend adapter system works — AgentAdapter interface, ACP protocol, session resume, and how to add new provider adapters
When debugging why an agent has the wrong provider/model, or when modifying agent creation or delegation flows.
How to get agents to use group chats for peer coordination in flightdeck-based crews. Covers hub-and-spoke anti-pattern, auto-grouping triggers, and file-lock-linked groups. Use when setting up multi-agent crews with 3+ agents or diagnosing why agents aren't collaborating directly.
When fetching from the `/coordination/activity` API and you only need specific action types (e.g., `progress_update`, `task_completed`, `delegated`).
When fetching activity data for UI display, or debugging why activity-based features show empty/stale data.
Architecture decisions and patterns from Flightdeck development (Phases 2–4). Covers feature architecture, state management, component patterns, and API design.
| name | secretary-realtime-notifications |
| description | When adding a new command or event that changes the task DAG and the secretary should know about it immediately (not wait for the 3-minute ContextRefresher poll). |
When adding a new command or event that changes the task DAG and the secretary should know about it immediately (not wait for the 3-minute ContextRefresher poll).
Use the notifySecretary() helper to send a system message to the secretary agent:
import { notifySecretary } from './secretaryNotifier.js';
// After a DAG-changing event:
notifySecretary(ctx, leadId, `[System] Task "${taskId}" completed by ${role} (${agentId}): ${summary}`);
parentId === leadId && role.id === 'secretary')secretary.sendMessage() to deliver immediately| Event | File | Location |
|---|---|---|
| Task completed | TaskCommands.ts | After ctx.emit('dag:updated') in COMPLETE_TASK |
| Task assigned | TaskCommands.ts | After ctx.emit('dag:updated') in ASSIGN_TASK |
| Task reassigned | TaskCommands.ts | After reassignment in REASSIGN_TASK |
| Task delegated | AgentLifecycle.ts | After ctx.emit('agent:delegated') in DELEGATE and CREATE_AGENT |
[System] Task "{taskId}" completed by {roleName} ({shortAgentId}): {summary}
[System] Task "{taskId}" assigned to {roleName} ({shortAgentId})
[System] Task "{taskId}" reassigned from @{oldShortId} to {roleName} ({newShortId})
[System] Task delegated to {roleName} ({shortAgentId}): {taskDescription}
const secretary = ctx.getAllAgents().find(a =>
a.parentId === leadId &&
a.role.id === 'secretary' &&
a.status !== 'terminated' && a.status !== 'failed' && a.status !== 'completed'
);
This same pattern is used by requestSecretaryDependencyAnalysis() in AgentLifecycle.ts (line 769) for a different purpose (requesting dependency analysis for auto-DAG tasks).
packages/server/src/agents/commands/secretaryNotifier.tspackages/server/src/__tests__/secretaryNotifier.test.tspackages/server/src/coordination/agents/ContextRefresher.ts (3-minute polling fallback)