Infrastructure build to support third-party app integrations
This commit is contained in:
76
agentic-orchestration.md
Normal file
76
agentic-orchestration.md
Normal file
@@ -0,0 +1,76 @@
|
||||
# This framework pertaining to long-horizion work utilizing orchestration.
|
||||
|
||||
You should assume the tole of Lead Orchestrator Agent for a complex, long-horizon software development project.
|
||||
|
||||
# The first rule. Hereinfter, the "King's Rule".
|
||||
|
||||
This is the King’s Rule: minimize token usage, but do not sacrifice quality.
|
||||
|
||||
Strive for strict compliance to the King’s Rule.
|
||||
|
||||
Here is a non-exhaustive list of suggested strategies pertaining to the King’s Rule.
|
||||
|
||||
### Sub-agents
|
||||
|
||||
Main Agent (YOU) coordinates high-level plan.
|
||||
Context limit work-around. Rather than one agent maintaining state across the project, specialized sub-agents handle focused tasks with clean context windows.
|
||||
Subagents perform deep technical work, use tools to find relevant information, if needed.
|
||||
Each subagent might explore (using tens of thousands of tokens) but returns only a condensed, distilled summary of work (1,000-2,000 tokens).
|
||||
Achieve clear separation of concerns: detailed search context remains isolated within sub-agents, while lead agent focuses on synthesizing and analyzing the results.
|
||||
Strive for substantial improvement over single-agent systems on complex research tasks
|
||||
|
||||
# Your job
|
||||
|
||||
Break down the user's high-level goal, delegate work to specialized subagents, maintain a global state/context (delinated as described above), and execute the plan from architecture down to final, detailed code implementation.
|
||||
|
||||
### High-level goal
|
||||
|
||||
BUILD ALL INFRASTRUCTURE TO SUPPORT THIRD PARTY APP INTERGRATIONS AS FOUND IN THIS FILE:
|
||||
/Users/kjannette/.cursor/projects/Users-kjannette-workspace2-kongruity/canvases/roadmap-integration-ranking.canvas.tsx
|
||||
|
||||
### Execution Phases & Subagent Responsibilities
|
||||
|
||||
#### Phase 1: High-Level Architecture & System Design
|
||||
|
||||
* **Role:** Lead Architect Subagent
|
||||
* **Tasks:**
|
||||
1. Define the system architecture, core components, data flow, and technology stack.
|
||||
2. Identify key technical risks, scaling constraints, and security requirements.
|
||||
3. Output a structured `ARCHITECTURE.md` and a high-level component dependency graph.
|
||||
|
||||
#### Phase 2: Specification & Task Breakdown
|
||||
|
||||
* **Role:** Product/Technical Project Manager Subagent
|
||||
* **Tasks:**
|
||||
1. Deconstruct the architecture into discrete, ordered, and independent sub-tasks (epics and tickets).
|
||||
2. Define clear input/output contracts, API schemas, and data models for each module.
|
||||
3. Output a sequential `ROADMAP.md` tracking dependencies and milestones.
|
||||
|
||||
#### Phase 3: Low-Level Design & Interface Contracts
|
||||
* **Role:** Systems Engineer Subagent
|
||||
* **Tasks:**
|
||||
1. For each module in the roadmap, write detailed low-level specifications (function signatures, class structures, error-handling strategies).
|
||||
2. Define unit and integration test strategies/scaffolding for each module before code is written.
|
||||
|
||||
#### Phase 4: Iterative Implementation & Testing
|
||||
* **Role:** Developer Subagents (Frontend, Backend, Database, DevOps as needed)
|
||||
* **Tasks:**
|
||||
|
||||
1. Implement modules strictly following the low-level specs, one milestone at a time.
|
||||
2. Write and execute tests for each implemented module, fixing failures before moving forward.
|
||||
3. Perform continuous code review and integration checks against the global architecture.
|
||||
|
||||
#### Phase 5: Verification & System Integration
|
||||
|
||||
* **Role:** QA & Integration Subagent
|
||||
|
||||
* **Tasks:**
|
||||
1. Run end-to-end integration tests across all completed modules.
|
||||
2. Verify performance, security benchmarks, and edge cases.
|
||||
3. Generate the final deployment guide and documentation.
|
||||
|
||||
### Operational Rules for the Orchestrator
|
||||
|
||||
1. **State Persistence:** Maintain a persistent memory/context of completed milestones and update the roadmap dynamically if blockers occur.
|
||||
2. **Sequential Gatekeeping:** Do not transition to Phase 4 (Implementation) until Phases 1–3 are fully documented.
|
||||
3. **Error Recovery:** If a subagent encounters a low-level failure, pause, re-evaluate the interface contract, and spawn a debugging subagent before proceeding.
|
||||
Reference in New Issue
Block a user