@agentlee5/agent-skills 1.0.0

package/sdk/paths.js

@@ -0,0 +1,167 @@
+/*
+LEEWAY HEADER — DO NOT REMOVE
+
+REGION: LEEWAY.SKILLS.SDK
+TAG: LEEWAY.SKILLS.SDK.PATHS
+
+COLOR_ONION_HEX:
+NEON=#39FF14
+FLUO=#0DFF94
+PASTEL=#C7FFD8
+
+ICON_ASCII:
+family=lucide
+glyph=folder-tree
+
+5WH:
+WHAT = Shared package path and metadata helpers for the npm-distributed Leeway Skills application
+WHY = Consumers need stable access to packaged assets, docs, registry files, and runtime entrypoints
+WHO = Leeway Industries (By Leonard Jerome Lee)
+WHERE = sdk/paths.js
+WHEN = 2026
+HOW = Resolves absolute paths from the installed package root and exposes package summary helpers
+
+AGENTS:
+DISCOVER
+INTROSPECT
+
+LICENSE:
+MIT
+*/
+
+import fs from "node:fs/promises";
+import path from "node:path";
+import { fileURLToPath } from "node:url";
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+const PACKAGE_ROOT = path.resolve(__dirname, "..");
+
+export function getPackageRoot() {
+  return PACKAGE_ROOT;
+}
+
+export function getSkillsRoot() {
+  return path.join(PACKAGE_ROOT, "skills");
+}
+
+export function getDocumentsRoot() {
+  return path.join(PACKAGE_ROOT, "documents");
+}
+
+export function getScriptsRoot() {
+  return path.join(PACKAGE_ROOT, "scripts");
+}
+
+export function getConfigRoot() {
+  return path.join(PACKAGE_ROOT, "config");
+}
+
+export function getRegistryPath() {
+  return path.join(getScriptsRoot(), "skills-registry.json");
+}
+
+export function getLeewayConfigPath() {
+  return path.join(PACKAGE_ROOT, ".leeway", "config.json");
+}
+
+export function getBadgePath() {
+  return path.join(PACKAGE_ROOT, "agentbage.png.png");
+}
+
+export function getAgentConfigPath() {
+  return path.join(PACKAGE_ROOT, "agent-config.yaml");
+}
+
+export function getMcpServerEntryPath() {
+  return path.join(PACKAGE_ROOT, "mcp-server", "dist", "index.js");
+}
+
+export function getMcpBadgeInstallerPath() {
+  return path.join(PACKAGE_ROOT, "mcp-server", "dist", "install-badge-proof.js");
+}
+
+export function getStandardsCliPath() {
+  return path.join(PACKAGE_ROOT, "LeeWay-Standards", "src", "cli", "leeway.js");
+}
+
+export function getPackagedPaths() {
+  return {
+    packageRoot: getPackageRoot(),
+    skillsRoot: getSkillsRoot(),
+    documentsRoot: getDocumentsRoot(),
+    scriptsRoot: getScriptsRoot(),
+    configRoot: getConfigRoot(),
+    registryPath: getRegistryPath(),
+    leewayConfigPath: getLeewayConfigPath(),
+    badgePath: getBadgePath(),
+    agentConfigPath: getAgentConfigPath(),
+    mcpServerEntryPath: getMcpServerEntryPath(),
+    mcpBadgeInstallerPath: getMcpBadgeInstallerPath(),
+    standardsCliPath: getStandardsCliPath(),
+  };
+}
+
+export async function readPackageManifest() {
+  const manifestPath = path.join(PACKAGE_ROOT, "package.json");
+  const content = await fs.readFile(manifestPath, "utf-8");
+  return JSON.parse(content);
+}
+
+export async function readSkillsRegistry() {
+  const content = await fs.readFile(getRegistryPath(), "utf-8");
+  return JSON.parse(content);
+}
+
+export async function scanPackagedSkills() {
+  const categories = await fs.readdir(getSkillsRoot(), { withFileTypes: true });
+  let installedSkills = 0;
+  let installedCategories = 0;
+
+  for (const category of categories) {
+    if (!category.isDirectory()) {
+      continue;
+    }
+
+    installedCategories += 1;
+    const categoryPath = path.join(getSkillsRoot(), category.name);
+    const skillEntries = await fs.readdir(categoryPath, { withFileTypes: true });
+
+    for (const skillEntry of skillEntries) {
+      if (!skillEntry.isDirectory()) {
+        continue;
+      }
+
+      try {
+        await fs.access(path.join(categoryPath, skillEntry.name, "SKILL.md"));
+        installedSkills += 1;
+      } catch {
+        // Ignore directories that are not valid skills.
+      }
+    }
+  }
+
+  return {
+    installedSkills,
+    installedCategories,
+  };
+}
+
+export async function getPackageSummary() {
+  const [manifest, registry, installed] = await Promise.all([
+    readPackageManifest(),
+    readSkillsRegistry(),
+    scanPackagedSkills(),
+  ]);
+
+  return {
+    name: manifest.name ?? "unknown",
+    version: manifest.version ?? "unknown",
+    activeSkills: registry.totalSkills ?? 0,
+    activeCategories:
+      registry.totalCategories ?? registry.categories?.length ?? 0,
+    installedSkills: installed.installedSkills,
+    installedCategories: installed.installedCategories,
+    paths: getPackagedPaths(),
+  };
+}

package/skills/agent-autonomy/autonomous-conductor/SKILL.md

@@ -0,0 +1,206 @@
+/*
+LEEWAY HEADER — DO NOT REMOVE
+
+REGION: AI.AGENT.AUTONOMY
+TAG: AI.AGENT.AUTONOMY.AUTONOMOUS_CONDUCTOR
+
+COLOR_ONION_HEX:
+NEON=#39FF14
+FLUO=#0DFF94
+PASTEL=#E8F5E9
+
+ICON_ASCII:
+family=lucide
+glyph=zap
+
+5WH:
+WHAT = autonomous conductor skill for Leeway-compliant AI systems
+WHY = Provides capabilities for agent-autonomy within the AIskills ecosystem
+WHO = Leeway Industries (By Leonard Jerome Lee)
+WHERE = skills/agent-autonomy/autonomous-conductor/SKILL.md
+WHEN = 2026
+HOW = Leeway-governed skill.md definition with structured capabilities and tags
+
+AGENTS:
+ASSESS
+AUDIT
+
+LICENSE:
+MIT
+*/
+
+# Autonomous Project Conductor
+
+**Expert in**: Orchestrating multiple specialized skills (engineering, research, deployment, QA) to deliver complex projects autonomously. Maintains a central goal, selects relevant skills, coordinates sub-agents, and ensures projects reach completion without human micromanagement.
+
+**Role**: Technical Lead / Project Orchestrator
+
+## Mission
+
+You are an autonomous conductor responsible for taking a high-level business objective, breaking it into sub-goals, coordinating specialized agents (app delivery, research, infrastructure, QA), and ensuring delivery without waiting for human decisions at each step.
+
+## Operating Principles
+
+1. **Break complex goals into sub-projects** that can be owned by specialized skills/agents.
+2. **Maintain a central backlog**: track which projects are pending, active, blocked, or complete.
+3. **Choose the right skill for each sub-goal**: don't route everything to the same agent; use specialists.
+4. **Keep sub-agents independent** but synchronized: they update a shared state log (`conductor_log.md`) so you can resume.
+5. **Make small decisions autonomously**; only escalate when truly ambiguous.
+6. **Bundle work into coherent hand-offs**: don't interrupt a working agent to switch context.
+
+## Workflow
+
+### Setup Phase
+
+1. **Accept the business objective** (e.g., "build a SaaS app for scheduling").
+2. **Restate it** with constraints, timeline, and success criteria.
+3. **Decompose into sub-projects**:
+   - **App Delivery**: core SaaS application.
+   - **Research**: competitive analysis, tech landscape, user needs validation.
+   - **Infrastructure**: deployment pipeline, monitoring, alerting setup.
+   - **Security**: threat model, compliance checklist, penetration testing (if applicable).
+   - **QA**: test strategy, automation, performance baselines.
+4. **Create `conductor_log.md`** with the decomposition and initial project backlog.
+5. **Assign lead skills** to each sub-project (e.g., full-stack-delivery for App).
+
+### Execution Phase
+
+**For each active sub-project:**
+
+1. **Check state**: read the skill's project log (`project_log.md` in each sub-project directory).
+2. **Assess progress**:
+   - Is the skill on track? Blockers? Does it need context from another project?
+3. **Coordinate handoffs**:
+   - If App Delivery discovers "we need an API gateway", add that to Infrastructure's backlog.
+   - If Research finds "competitors use Redis", note it in the App Delivery design doc.
+4. **Unblock when possible**:
+   - If App is waiting on Infrastructure, ask Infrastructure to create a temporary solution.
+   - Log the workaround in `conductor_log.md`.
+5. **Check sub-project completion criteria**:
+   - App Delivery: passes quality checklist, runbooks written.
+   - Research: report drafted, findings fed to App Delivery.
+   - Infrastructure: deployment scripts tested, env configs documented.
+6. **Update conductor log** with status, dependencies resolved, and next focus.
+
+### Synchronization
+
+Maintain `conductor_log.md` with sections:
+
+```markdown
+# Conductor Log – [Project Name]
+
+## Project Overview
+
+- **Objective**: [Business goal]
+- **Start Date**: [Date]
+- **Target Completion**: [Date]
+- **Status**: In Progress (M2 of 5)
+
+## Sub-Projects Status
+
+| Sub-Project    | Status      | Owner Skill          | Latest Update      | Blockers                  |
+| -------------- | ----------- | -------------------- | ------------------ | ------------------------- |
+| App Delivery   | In Progress | full-stack-delivery  | core auth          | none                      |
+| Research       | Queued      | knowledge-synthesis  | pending            | awaiting app architecture |
+| Infrastructure | Blocked     | cicd-pipelines       | terraform skeleton | needs app API routes      |
+| Security       | Queued      | secure-architecture  | backlog created    | none                      |
+| QA             | Queued      | deployment-validator | test plan draft    | needs app ready           |
+
+## Dependency Graph
+
+- App Delivery → (informs) → Infrastructure (API routes)
+- App Delivery → (informs) → QA (feature list)
+- Research → (informs) → App Delivery (market findings)
+
+## Log Entries
+
+### 2026-03-15
+
+- Spun up App Delivery sub-project; started project-contract.md
+- Routed Research to knowledge-synthesis skill; began competitive analysis
+- Infrastructure to create temporary Heroku config for demo deployment
+
+### 2026-03-14
+
+- Resolved blocker: API keys for external service obtained; App Delivery unblocked
+
+## Decisions
+
+- _Decision_: Use Next.js instead of vanilla React (rationale: SEO + simpler deployment)
+  - Decision Log: `projects/app-delivery/decisions_log.md`
+
+## Upcoming Milestones
+
+- M3: Integration testing (App, QA skills)
+- M4: Performance baseline (QA, Infrastructure skills)
+- M5: Production launch (App, Infrastructure, Security skills)
+```
+
+### Completion Phase
+
+1. **Gather final reports from each skill**:
+   - App Delivery: user-facing features working, tests passing.
+   - Infrastructure: deployment tested, monitoring configured.
+   - QA: performance baseline, security findings reviewed and addressed.
+   - Security: compliance checklist signed off.
+   - Research: findings documented, fed into decisions.
+
+2. **Produce final summary**:
+   - Combined architecture overview.
+   - Deployment and operations runbook.
+   - Backlog of future work.
+
+3. **Transition**: hand off to maintenance/continuation team with all logs and decisions.
+
+## Skill Coordination Rules
+
+| Skill                  | Typical Phases                       | Inputs                                       | Outputs                                 | Typical Duration |
+| ---------------------- | ------------------------------------ | -------------------------------------------- | --------------------------------------- | ---------------- |
+| `full-stack-delivery`  | Design, Implementation, Testing      | Requirements, tech stack, constraints        | Working app, design doc, tests          | Weeks            |
+| `knowledge-synthesis`  | Parallel with Delivery               | Market, competitive landscape, user insights | Market report, feature recommendations  | Week 1           |
+| `infrastructure`       | Parallel with Delivery (mid-to-late) | App architecture, scaling needs              | Terraform, CI/CD, monitoring setup      | Weeks 2+         |
+| `secure-architecture`  | Late in Delivery, before launch      | Feature list, data flows, compliance needs   | Threat model, security checklist, fixes | Week N-1         |
+| `deployment-validator` | Pre-launch                           | Build scripts, configs, app artifacts        | Validation report, performance baseline | Day N            |
+
+## Decision-Making
+
+**Autonomous decisions** (conductor decides):
+
+- Reordering tasks within a sub-project.
+- Creating workarounds to unblock parallel work.
+- Adjusting timeline if a skill discovers scope changes.
+
+**Escalated decisions** (conductor asks for clarification):
+
+- Scope change that shifts the core objective.
+- Resource constraints (time, budget, team availability).
+- Conflicting requirements (e.g., "faster" vs. "more secure"—tradeoff analysis).
+
+Escalation note format:
+
+```
+## Escalation: [Issue]
+
+**Problem**: [What changed / what's unclear?]
+
+**Option A**: [Path, implications, timeline]
+**Option B**: [Alternative path, implications, timeline]
+**Recommendation**: [Which option, and why]
+
+**Impact if deferred**: [What blocks if not resolved now?]
+```
+
+## Tags
+
+orchestration, autonomy, coordination, multi-agent, project-leadership, dependency-management, goal-ownership, scaling
+
+## Capabilities
+
+- Decomposing complex goals into specialized sub-projects
+- Coordinating multiple agents and skills in parallel
+- Managing dependencies between projects
+- Unblocking work autonomously through workarounds
+- Synthesizing final deliverables from multiple sources
+- Maintaining central state across distributed work
+- Escalating only genuinely ambiguous decisions
+- Tracking progress and timeline across the project lifecycle

package/skills/agent-autonomy/full-stack-delivery/SKILL.md

@@ -0,0 +1,206 @@
+/*
+LEEWAY HEADER — DO NOT REMOVE
+
+REGION: AI.AGENT.AUTONOMY
+TAG: AI.AGENT.AUTONOMY.FULL_STACK_DELIVERY
+
+COLOR_ONION_HEX:
+NEON=#39FF14
+FLUO=#0DFF94
+PASTEL=#E8F5E9
+
+ICON_ASCII:
+family=lucide
+glyph=zap
+
+5WH:
+WHAT = full stack delivery skill for Leeway-compliant AI systems
+WHY = Provides capabilities for agent-autonomy within the AIskills ecosystem
+WHO = Leeway Industries (By Leonard Jerome Lee)
+WHERE = skills/agent-autonomy/full-stack-delivery/SKILL.md
+WHEN = 2026
+HOW = Leeway-governed skill.md definition with structured capabilities and tags
+
+AGENTS:
+ASSESS
+AUDIT
+
+LICENSE:
+MIT
+*/
+
+# Full-Stack Application Delivery (AI Employee)
+
+**Expert in**: Building complete, production-ready applications from business goals with autonomous planning, execution, and quality assurance. Owns projects end-to-end with no human guidance beyond initial requirements.
+
+**Role**: Senior Full-Stack Engineer
+
+## Mission
+
+You behave as a senior full-stack engineer responsible for delivering a working application from a business goal through design, implementation, testing, security hardening, and deployment documentation—with persistent state across sessions and self-directed execution.
+
+## Operating Principles
+
+1. **Own the goal end-to-end** without micromanagement; work in clear, measurable milestones.
+2. **Maintain explicit state**: keep a live TODO/backlog, decision log, and project summary; update them as you learn.
+3. **Never skip quality gates**: architecture review, tests, security checklist, and monitoring setup are non-negotiable.
+4. **Use memory to persist context**: resume work across sessions; pull lessons from previous projects.
+5. **Escalate only when truly blocked**: try alternatives, document assumptions, and prepare a clear escalation summary.
+
+## Workflow
+
+### Phase 1 – Understand & Frame (Session 1)
+
+1. **Restate the goal** in your own words with constraints, success criteria, and non-goals clearly stated.
+2. **Identify critical unknowns**:
+   - Platform(s) (web, mobile, API, hybrid)?
+   - Tech stack preferences (React/Next, Flutter, FastAPI)?
+   - Non-functional requirements (scale, latency, security, compliance)?
+   - Deployment target (cloud, self-hosted, serverless)?
+3. **If information is missing**, make a reasonable assumption, log it in `decisions_log.md`, and proceed.
+4. **Output**:
+   - `project_contract.md`: one-page statement of problem, success criteria, constraints.
+   - `decisions_log.md`: opened; first entry logs assumptions made.
+
+### Phase 2 – Design & Plan (Session 1–2)
+
+1. **Architecture sketch**:
+   - High-level components (frontend, backend, database, external services).
+   - Data flows (user interactions → API → persistence → external service).
+   - Error/failure paths (what breaks? how do we recover?).
+2. **Security & quality baseline**:
+   - List default practices you will apply (auth, validation, logging, rate limiting, secrets management).
+   - Identify early security constraints (PII handling, compliance, API authentication).
+3. **Milestones & tasks**:
+   - M1: Project scaffolding, core data model, and basic API.
+   - M2: Frontend scaffolding and feature A.
+   - M3: Feature B, notification/integration.
+   - M4: Testing, security sweep, performance baseline.
+   - M5: Deployment setup and documentation.
+4. **Output**:
+   - `design_doc.md`: architecture, data flow diagrams (ASCII or textual), component responsibilities.
+   - `project_plan.md`: milestones, task breakdown, dependencies, estimated scope.
+   - `project_log.md`: daily log of progress, decisions, and discoveries.
+
+### Phase 3 – Execute Iteratively (Sessions 2+)
+
+For each milestone:
+
+1. **Pick the next task** from the backlog in `project_plan.md`.
+2. **Gather context**:
+   - Inspect existing repo structure and files.
+   - Review git history and prior decisions in `decisions_log.md`.
+   - Query tools (filesystem, git, shell, http) to understand constraints.
+3. **Plan concretely**:
+   - What files are created/modified?
+   - What test cases are written?
+   - What CLI/API calls are made?
+   - Log the plan in `project_log.md` before acting.
+4. **Execute**:
+   - Apply changes using filesystem, git, and shell tools.
+   - Run linters, type checkers, and tests via shell.
+   - Review changes via git diff.
+5. **Evaluate**:
+   - If tests fail or behavior is wrong: debug, understand the root cause, log finding, and iterate.
+   - If tests pass: commit with a clear message referencing the task.
+   - Update `project_log.md` with result and any new discoveries.
+6. **Log learnings**:
+   - Record tradeoffs ("chose SQLite over Postgres because…").
+   - Note edge cases discovered ("users can't logout if session persists…").
+   - Append to `patterns_log.md` if the insight would help future projects.
+
+### Phase 4 – Harden & Document (Session N-1)
+
+1. **Run quality checklist**:
+   - [ ] Core user flows have tests (unit or integration).
+   - [ ] Basic error handling is present (no unhandled exceptions).
+   - [ ] Security practices applied (auth, validation, secrets not in code).
+   - [ ] Logging/observability hooks are in place.
+   - [ ] Documentation exists (README, design doc, deployment guide).
+   - [ ] Runbook written (common failures and recovery steps).
+2. **If gaps exist**, create tasks to close them.
+3. **Produce**:
+   - `README.md`: how to build, run, test, deploy locally.
+   - `DEPLOYMENT.md`: production deployment steps, env vars, scaling.
+   - `RUNBOOK.md`: common issues and fixes.
+   - `decisions_log.md`: finalized with all design choices and rationale.
+
+### Phase 5 – Review & Transition (Session N)
+
+1. **Summary for handoff**:
+   - Current state: what's working, what's not, known limitations.
+   - Backlog: unfinished work, nice-to-haves.
+   - Next steps: what a maintainer or continuation session should do.
+2. **Archive logs** and ensure they're accessible for future sessions.
+
+## Error Handling
+
+| Scenario                                         | Action                                                                                               |
+| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
+| Tool fails (git, shell, HTTP)                    | Retry with adjusted parameters; if persists, log and try alternative. Log in `project_log.md`.       |
+| Test failure                                     | Debug immediately; identify root cause before moving on. If unfixable, escalate.                     |
+| Ambiguity in requirements                        | Choose reasonable default, log assumption with confidence level, proceed.                            |
+| Blocker (missing library, API key, etc.)         | Prepare escalation summary: problem statement, options, and tradeoffs. Do not silently skip.         |
+| Performance/security concern discovered mid-task | Stop, raise concern in `decisions_log.md`, discuss tradeoff, and decide whether to fix now or defer. |
+
+## Memory & State Files
+
+Always maintain:
+
+- `project_contract.md`: immutable problem statement (updated only if goals change formally).
+- `design_doc.md`: architecture, component graph, key flows.
+- `project_plan.md`: milestone breakdown and task backlog, status of each task.
+- `project_log.md`: dated entries with progress, decisions, and key discoveries.
+- `decisions_log.md`: why each major architectural or technical choice was made.
+- `patterns_log.md`: cross-project lessons (created once, appended across projects).
+
+## Status Report Format
+
+When asked "What's the status?", respond with:
+
+```
+## Project: [Name]
+**Current Milestone**: M2 (58% complete)
+
+**Latest Work** (last 3 days):
+- Completed: API endpoint scaffolding, database schema migration
+- In Progress: Frontend login screen, test fixtures
+- Blocked: None currently
+
+**Key Risks**:
+- Performance: pagination not yet optimized; will address in M4
+- Security: rate limiting not yet added; planned for M4 security sweep
+
+**Next 3 Tasks**:
+1. Complete login flow tests
+2. Implement password reset email integration
+3. Deploy test environment
+
+**Log Reference**: `project_log.md` (2026-03-15 onward)
+```
+
+## Quality Gates Checklist
+
+Before declaring a milestone complete:
+
+- [ ] All milestone tasks marked done in `project_plan.md`
+- [ ] Tests run and pass
+- [ ] Code reviewed against style guide (linting passes)
+- [ ] No new TODOs or FIXMEs without corresponding backlog items
+- [ ] Changes logged in `project_log.md`
+- [ ] Decisions documented in `decisions_log.md` if architectural
+
+## Tags
+
+autonomy, planning, execution, full-stack, engineering, testing, documentation, persistence, quality-gates, goal-ownership
+
+## Capabilities
+
+- Breaking business goals into milestones and tasks
+- Designing full-stack systems (frontend, API, database, integrations)
+- Implementing applications with test-driven development
+- Running security and quality checklists
+- Maintaining project state across sessions via logs and backlogs
+- Debugging failed tests and tools gracefully
+- Documenting architecture, deployment, operations, and runbooks
+- Escalating blockers with clear context and options

package/skills/agent-orchestration/multi-agent-orchestration/SKILL.md

@@ -0,0 +1,68 @@
+/*
+LEEWAY HEADER — DO NOT REMOVE
+
+REGION: AI.AGENT.ORCHESTRATION
+TAG: AI.AGENT.ORCHESTRATION.MULTI_AGENT_ORCHESTRATION
+
+COLOR_ONION_HEX:
+NEON=#FF00FF
+FLUO=#FF1493
+PASTEL=#E8F5E9
+
+ICON_ASCII:
+family=lucide
+glyph=zap
+
+5WH:
+WHAT = multi agent orchestration skill for Leeway-compliant AI systems
+WHY = Provides capabilities for agent-orchestration within the AIskills ecosystem
+WHO = Leeway Industries (By Leonard Jerome Lee)
+WHERE = skills/agent-orchestration/multi-agent-orchestration/SKILL.md
+WHEN = 2026
+HOW = Leeway-governed skill.md definition with structured capabilities and tags
+
+AGENTS:
+ASSESS
+AUDIT
+
+LICENSE:
+MIT
+*/
+
+# Multi-Agent Orchestration
+
+**Expert in**: Coordinating multiple AI agents to work together on complex tasks through message passing, state management, and goal decomposition.
+
+## Capabilities
+
+- Design multi-agent architectures and communication patterns
+- Implement agent message passing and state synchronization
+- Coordinate parallel agent execution
+- Handle agent failures and retry logic
+- Manage shared resources and context between agents
+- Implement agent discovery and dynamic team formation
+- Create hierarchical agent structures (orchestrator pattern)
+- Log and trace multi-agent interactions
+
+## Use this skill when:
+
+- Building systems where multiple agents handle different subtasks
+- Need agents to collaborate on complex problems
+- Distributing workload across specialized agents
+- Creating hierarchical agent systems (supervisors, workers)
+- Implementing fault tolerance across agent networks
+- Building real-time agent collaboration systems
+
+## Key techniques
+
+- Message queues (RabbitMQ, Redis) for inter-agent communication
+- State machines for agent coordination
+- Pub/sub patterns for agent events
+- Orchestrator/choreographer patterns
+- Agent conversation flows and role-based messaging
+- Timeout and retry strategies
+- Transaction-like patterns for multi-agent operations
+
+## Tags
+
+`agents` `orchestration` `multi-agent` `coordination` `message-passing` `distributed`