What does FY MultiAgent Flow Skill (FY-Flow) do?
Contract-driven Multi-Agent Collaborative Development Microkernel (FY-Flow) — Aligned with the AutoGen paradigm, effectively preventing unauthorized actions, fragmented outputs, and state suspension.
Unified Gateway Protocol
All calls to this Skill are uniformly converged to this gateway entry point, and are split and evaluated according to the following two-branch rule:
1. Two-Branch Diversion Matrix
| Branch Type | Trigger Features & Commands | Processing Mechanism & Response Contract | Typical Scenarios |
|---|---|---|---|
| Branch A: System Console Operations | /fy-flow help/fy-flow start/fy-flow status/fy-flow kanban/fy-flow trace | Direct pass-through to the underlying Ops Engine (0 pre-level gating), execute the corresponding script directly and output system status. | View help manual, initialize SOP, start kanban, dashboard health check, offline trace map |
| Branch B: Business R&D & Interaction Intent | Natural language requirements, code modifications, feature development, bug fixes, troubleshooting, /fy-flow auto | Mandatory pre-execution of [Three-Level Classification and Single-Responsibility Decomposition], and explicitly output dual header identifier on the first line of the response:`[Task Level: L0 Instant Q&A / L1 Short-Chain Task / L2 Standard R&D] | [Single Responsibility: Compliant Single Card / Compound Requirements must be decomposed into N atomic tasks]` |
2. Business Requirement [Three-Level Classification] Decision Flow
[Business Requirement Input]
|
+---> 1. Will it result in modifications to code/documentation/config/other repository files?
| +-- No ---> 2. Does the conclusion need to be traced for subsequent engineering basis?
| | +-- No ----------------> [L0 Instant Q&A] (No card, answer directly, 0ms CLI latency, draft saved to drafts)
| | +-- Yes ---------------> [L1 Lightweight Task] (Create card, stop and wait for start -> wait for human authorization, single role completes)
| |
| +-- Yes ---> 3. Does it require multi-role collaboration, modification of core business code, or changes to common base libraries?
| +-- No ---------------> [L1 Lightweight Task]
| +-- Yes ---------------> [L2 Standard R&D Task] (Create card, stop and wait for start -> wait for human authorization, multi-role collaboration)
- Gateway Classification & CCP Elastic Classification Mapping:
- [L0 Instant Q&A]: No card, answer directly, 0 state machine overhead;
- [L1 Lightweight Task]: Mapped to CCP Tier-3 (Fast-Path quick release, no physical independent report, credentials written directly back to the kanban);
- [L2 Standard R&D]: Automatically matches CCP Tier-2 (local optimization, effort ≤ 4.0h, no physical report) or CCP Tier-1 (core architecture & interface contract strong constraints) based on scale and contract.
- Any business requirement falling under L1/L2 must undergo a mandatory single-responsibility review (effort ≤ 8.0h, single atomic deliverable). Cross-orthogonal domain requirements must be decomposed into separate cards.
- Hard Red Line for Start Authorization: Card creation marks the end of the current planning session. The task card must strictly remain in the [To Do] status; without explicit authorization from the human user (e.g., "Start", "Begin development", "Confirm execution"), automatic assignment to [In Progress] is strictly prohibited.
- The execution Task ID (e.g.,
T0001) directly penetrates the gateway into the state machine for progression; secondary card creation is prohibited.
Core CLI Command Quick Reference
| Business Scenario | Unified CLI Facade (cli.py) | Underlying Dedicated Script | Core Function & Parameters |
|---|---|---|---|
| Create Task Card | python3 scripts/cli.py task create ... | python3 scripts/quick_task.py create ... | --name "..." --assignee "..." --stage "Sprint 2.1 Menu Adjustments" --type "A" --target "..." --criteria "..." [--in-scope "file # reason"] |
| Stage Gate Admission/Closure | python3 scripts/check_stage_gate.py ... | python3 scripts/check_stage_gate.py ... | --action start/close --stage "Sprint 2.1 Menu Adjustments" (admission as needed, predecessor dependencies automatically verified) |
| Codified Dispatch | python3 scripts/cli.py dispatch --task-id T00xx --format codex | python3 scripts/dispatch_task.py | Validate dependencies and concurrency, move to [In Progress], output JSON parameters that can be directly consumed by Codex sub-agent tools |
| Advance Task State | python3 scripts/transition_task.py ... | python3 scripts/transition_task.py ... | --task-id T00xx --role DEV --from-status In Progress --to-status In Review --token <token> --summary "Core change description" --remarks "..." (--summary is mandatory for submitting review, automatically injecting diff and credential snapshot) |
| Human Final Acceptance | python3 scripts/cli.py task accept ... | python3 scripts/quick_task.py accept ... | --task-id T00xx (Human user only, Agent counter-signature strictly prohibited) |
| Start Kanban | python3 scripts/cli.py kanban | python3 scripts/start_kanban_server.py | Starts by default at http://127.0.0.1:32886/ |
| Health Check | python3 scripts/cli.py status | python3 scripts/heartbeat.py | Outputs overall health dashboard, blocked cards, and efficiency metrics (including sub-agent cognitive roaming and alerts > 600s) |
| Tech Stack Sync/Profile Recalculation | - | scripts/update_agent_tech_stacks.py | --force-recalc forces recalculation of expert technical capability profile and refreshes exported Subagents, solving the problem of outdated profiles after tech stack migration |
| Continuity Check | python3 scripts/cli.py ccp ... | python3 scripts/cli.py ccp ... | --task-id T00xx --stage In Review verifies context continuity |
| Trace Map | python3 scripts/cli.py trace | python3 scripts/generate_trace_html.py | Offline parsing of session traces, generates a full-chain trace map HTML in seconds (0 Token) |
| Smart Incremental Test | python3 scripts/cli.py test | scripts/run_tests.py | Automatically detects Git changes, only executes related unit tests (seconds), document changes are automatically exempted, --all for full regression |
8 Expert Sub-Agent Write Permissions & State Transition Interval Matrix
[!IMPORTANT] Physical Isolation Iron Law & Dispatch Token Gating:
- Main Agent (PM Manager Yan) is strictly prohibited from self-role-playing as a developer to write business code in the main session! Codex hosts must use the actual sub-agent tool for dispatch; other hosts can use their respective sub-agent tools.
- Codified Dispatch & Token Gating: When dispatching a task,
cli.py dispatchgenerates a uniquedispatch_token. Professional R&D roles (DEV/FRONTEND/REVIEWER/QA) must carry--token <token>during state transitions. The state machine engine enforces strict interception at the execution layer, preventing self-role-playing that fakes green checks.
Codex Desktop Automatic Dispatch Contract
After the user explicitly authorizes the start, the Main Agent executes the following in the target project directory:
python3 .agents/skills/fy-flow/scripts/dispatch_task.py --task-id <ID> --format codex.
Standard output is a single JSON object containing tool, arguments, task_id, and role; diagnostic information goes to standard error.
The Main Agent must immediately pass arguments as-is as the parameter to a single real collaboration.spawn_agent tool call,
wait for the sub-agent to return, then continue dispatching the review and test experts according to the current task status. Do not manually rewrite, copy, or reduce the dispatch message;
do not print the JSON as a dispatch confirmation, nor have the Main Agent perform the expert's work. If the current Codex host does not
have a sub-agent tool, clearly report the host capability deficiency, keep the task in its current state, and do not forge an expert receipt.
Dispatched experts should only execute exit_contract.required_cli in the message; they must not create new cards or start work.
Since user authorization covers this execution, dispatch can continue in the same session after card creation; only cards that have not yet received authorization to start remain in [To Do].
| Sub-Agent ID | Role Name | Core Responsibilities | Legal State Transition Interval | Exit Contract |
|---|---|---|---|---|
@flow-pm | Manager Yan (Project Manager) | Requirement decomposition, classification decision, and card creation | To Do -> In Progress / Request Acceptance | For card creation scenarios, stop at [To Do] and wait for authorization to start; request human acceptance |
@flow-architect | Architect Qian (System Architect) | Overall system architecture, interface contracts, and technology selection | To Do -> In Progress -> Done | Produce ADR and architecture design documents |
@flow-dev | Developer Li (Development Engineer) | Backend/full-stack core coding and unit test implementation | To Do -> In Progress -> In Review | Must run unit tests, generate development report, provide --summary when submitting for review |
@flow-frontend | Frontend Ma (Frontend Development Engineer) | Web/UI component and frontend experience implementation | To Do -> In Progress -> In Review | Verify component rendering and interactions, generate report, provide --summary when submitting for review |
@flow-reviewer | Reviewer Zhou (Code Review Expert) | Code standards, security scanning, and quality gating | In Review -> In Test / In Review -> Done (Tier-3 credentials fresh and non-drifted, bypass QA direct pass) / In Review -> Returned | Static scanning passes without warnings, produce review comments |
@flow-qa | QA Zhang (Test Engineer) | Targeted integration tests and release qualification (only execute tests related to the current task, full scripts strictly prohibited) | In Test -> Done / In Test -> Returned | Write targeted test cases, record actual effort |
@flow-docs | Docs Li (Documentation Engineer) | Deliverable document governance and user manual | To Do -> In Progress -> Done | Follow GB/T 7713 academic and engineering standards |
@flow-devops | DevOps Lv (Operations Administrator) | Branch merging, release builds, and Git history protection | To Do -> In Progress -> Done | Verify pipeline passes, resolve PR blocking |
Modular Specification Entity Index (Refer to Specific Specification Files as Needed)
If and only when entering a specific business scenario, the Agent MUST call view_file to consult the corresponding specification's entity Markdown file:
- First Load / Cold Start SOP: See
references/02-bootstrap/01-initialization_sop.md - Create Task / Single Responsibility Determination: See
references/01-gateway/01-task_classification.md - Task State Transition / Gate Rules / Role Permissions: See
references/03-engine/01-state_flow_rules.md - Context Handoff / Cross-Agent Handoff (CCP): See
references/04-ccp/01-ccp_protocol_spec.md - Kanban Server Operations / PR Auto-Unblocking: See
references/05-kanban/01-kanban_operations.md - Git Branch Merging / Audit Logs & Metrics: See
references/06-governance/01-git_and_audit_spec.md