devflow-kit 1.8.3 → 2.0.1

package/shared/skills/agent-teams/references/communication.md

@@ -1,122 +0,0 @@
-# Communication Protocols
-
-## Message Types
-
-### Direct Message (one-to-one)
-
-Use when challenging a specific teammate's finding:
-
-```
-To [Security Reviewer]:
-"Your finding about SQL injection at api/users.ts:42 - I disagree.
-The parameterized query at line 45 handles this. Check the query builder
-pattern used throughout this codebase."
-```
-
-### Broadcast (one-to-all)
-
-Use when sharing findings that affect all teammates:
-
-```
-Broadcast:
-"I found that the auth middleware is bypassed for /api/internal/* routes.
-This affects security, architecture, and testing perspectives."
-```
-
----
-
-## Debate Protocol
-
-### Round Structure
-
-```
-Round 1: Initial findings (each teammate shares top findings)
-Round 2: Challenge round (teammates dispute or validate)
-Round 3: Resolution (update, withdraw, or escalate)
-```
-
-**Cap: 2 challenge exchanges per topic.** If unresolved, escalate to lead.
-
-### Challenge Format
-
-When challenging another teammate:
-
-```
-CHALLENGE to [Teammate]:
-- Finding: [what they claimed]
-- Evidence against: [your counter-evidence with file:line references]
-- Suggested resolution: [what you think is correct]
-```
-
-### Concession Format
-
-When accepting a challenge:
-
-```
-UPDATED based on [Teammate]'s challenge:
-- Original: [what I originally claimed]
-- Revised: [updated finding incorporating their evidence]
-```
-
-### Escalation Format
-
-When debate is unresolved after 2 exchanges:
-
-```
-ESCALATION to Lead:
-- Topic: [what we disagree about]
-- Position A: [first perspective with evidence]
-- Position B: [second perspective with evidence]
-- Recommendation: [which has stronger evidence, or "genuinely split"]
-```
-
----
-
-## Lead Coordination Messages
-
-### Initiating Debate
-
-```
-Lead broadcast:
-"All teammates: Share your top 3-5 findings. After sharing, challenge
-any finding you disagree with. Provide evidence (file:line references).
-You have 2 exchange rounds to resolve disagreements."
-```
-
-### Ending Debate
-
-```
-Lead broadcast:
-"Debate round complete. Submit final findings with confidence levels:
-- HIGH: Unanimous or unchallenged with evidence
-- MEDIUM: Majority agreed, dissent noted
-- LOW: Split opinion, both perspectives included"
-```
-
-### Requesting Clarification
-
-```
-Lead to [Teammate]:
-"Your finding about X contradicts [Other Teammate]'s finding about Y.
-Can you address their evidence at [file:line]?"
-```
-
----
-
-## Output Aggregation
-
-### Consensus Report Structure
-
-```markdown
-## Confirmed Findings (HIGH confidence)
-[Findings all teammates agreed on or that survived challenge]
-
-## Majority Findings (MEDIUM confidence)
-[Findings most agreed on, with dissenting view noted]
-
-## Split Findings (LOW confidence)
-[Genuinely contested findings with both perspectives and evidence]
-
-## Withdrawn Findings
-[Findings that were disproved during debate]
-```

package/shared/skills/agent-teams/references/team-patterns.md

@@ -1,217 +0,0 @@
-# Team Patterns by Workflow
-
-## Task-Based Coordination
-
-All team workflows should use the shared task list for structured progress tracking:
-
-```
-1. Lead creates team
-2. Lead creates tasks (TaskCreate) for each teammate's work unit
-3. Lead spawns teammates, assigning tasks via TaskUpdate(owner)
-4. Teammates work, mark tasks completed via TaskUpdate(status: completed)
-5. Lead checks TaskList before proceeding to next phase
-6. Lead shuts down teammates, calls TeamDelete
-```
-
-**Example task creation for a review team:**
-
-```
-TaskCreate: "Security review of auth module" → assigned to Security Reviewer
-TaskCreate: "Architecture review of auth module" → assigned to Architecture Reviewer
-TaskCreate: "Performance review of auth module" → assigned to Performance Reviewer
-```
-
----
-
-## Review Team
-
-### Standard Review (4 perspectives)
-
-```
-Lead spawns:
-├── Security reviewer    → vulnerabilities, injection, auth, crypto
-├── Architecture reviewer → SOLID, coupling, layering, modularity
-├── Performance reviewer  → queries, algorithms, caching, I/O
-└── Quality reviewer      → complexity, tests, consistency, naming
-```
-
-### Extended Review (add conditionally)
-
-```
-Additional teammates based on changed files:
-├── TypeScript reviewer  → type safety, generics (if .ts/.tsx changed)
-├── React reviewer       → hooks, state, rendering (if .tsx/.jsx changed)
-├── Database reviewer    → schema, queries, migrations (if DB files changed)
-└── Dependencies reviewer → CVEs, versions, licenses (if package files changed)
-```
-
-### Review Debate Flow
-
-```
-1. Each reviewer analyzes independently
-2. Lead broadcasts: "Share top 3 findings and challenge others"
-3. Security challenges architecture: "This coupling creates attack surface"
-4. Architecture challenges performance: "Your caching suggestion breaks separation"
-5. Quality validates: "Tests don't cover the security concern raised"
-6. Lead collects consensus after max 2 exchange rounds
-```
-
----
-
-## Implementation Team
-
-### Exploration Team (4 perspectives)
-
-```
-Lead spawns:
-├── Architecture explorer  → existing patterns, module structure
-├── Integration explorer   → entry points, services, config
-├── Reusable code explorer → utilities, helpers, shared logic
-└── Edge case explorer     → error conditions, boundaries, race conditions
-```
-
-### Planning Team (3 perspectives)
-
-```
-Lead spawns:
-├── Implementation planner → step-by-step coding approach
-├── Testing planner        → test strategy and coverage plan
-└── Risk planner           → potential issues, rollback strategy
-```
-
-### Implementation Debate
-
-```
-1. Explorers share findings
-2. Architecture challenges edge cases: "This boundary isn't handled"
-3. Integration challenges reusable code: "That helper doesn't cover our case"
-4. Lead synthesizes consensus exploration
-
-5. Planners propose approaches
-6. Testing challenges implementation: "This approach is untestable"
-7. Risk challenges both: "Rollback is impossible with this migration"
-8. Lead synthesizes consensus plan
-```
-
----
-
-## Specification Team
-
-### Requirements Exploration Team (4 perspectives)
-
-```
-Lead spawns:
-├── User Perspective Explorer  → target users, goals, pain points, user journeys
-├── Similar Features Explorer  → comparable features, scope patterns, precedents
-├── Constraints Explorer       → dependencies, business rules, security, performance
-└── Failure Mode Explorer      → error states, edge cases, validation needs
-```
-
-### Requirements Debate Flow
-
-```
-1. Each explorer shares findings from their perspective
-2. Constraints challenges user perspective: "This requirement conflicts with X constraint"
-3. Failure modes challenges similar features: "That pattern failed in Y scenario"
-4. Similar features validates user perspective: "This UX pattern works well in Z"
-5. Lead collects consensus after max 2 exchange rounds
-```
-
-### Scope Planning Team (3 perspectives)
-
-```
-Lead spawns:
-├── User Stories Planner       → actors, actions, outcomes ("As X, I want Y, so that Z")
-├── Scope Boundaries Planner   → v1 MVP, v2 deferred, out of scope, dependencies
-└── Acceptance Criteria Planner → success/failure/edge case criteria (testable)
-```
-
-### Scope Debate Flow
-
-```
-1. Each planner presents their analysis
-2. Scope challenges user stories: "This story is too broad for v1"
-3. Acceptance challenges scope: "These boundaries leave this edge case uncovered"
-4. User stories challenges acceptance: "This criterion is untestable"
-5. Lead collects consensus after max 2 exchange rounds
-```
-
-**Note**: Specification teams complement (not replace) the 3 mandatory clarification gates. User still drives all decisions via Gate 0, Gate 1, and Gate 2.
-
----
-
-## Resolution Team
-
-### Cross-Validation Resolution Team
-
-```
-Lead spawns resolvers based on batches:
-├── Resolver A → Batch 1 issues (file-a cluster)
-├── Resolver B → Batch 2 issues (file-b cluster)
-└── Resolver C → Batch 3 issues (file-c cluster)
-```
-
-### Resolution Debate Flow
-
-```
-1. Each resolver independently validates + fixes their batch
-2. Lead broadcasts: "Review each other's fixes for cross-batch conflicts"
-3. Resolver A: "My fix in file-a.ts changes the interface that Resolver B depends on"
-4. Resolver B: "Confirmed — my fix in file-b.ts imports from that interface"
-5. Resolvers coordinate the fix or escalate conflict to lead
-6. Lead collects consensus after max 2 exchange rounds
-```
-
-### When Cross-Validation Adds Value
-
-- Fixes touch shared interfaces or types
-- Resolvers modify files that import from each other
-- Batch fixes could introduce conflicting patterns
-- Large resolution sets (>5 issues across multiple files)
-
-### When to Skip Cross-Validation
-
-- All fixes are in completely independent files
-- Only 1-2 batches with no shared dependencies
-- Fixes are trivial (typos, formatting, naming)
-
----
-
-## Debug Team
-
-### Hypothesis Investigation (3-5 hypotheses)
-
-```
-Lead spawns (one per hypothesis):
-├── Hypothesis A investigator → state management / race condition
-├── Hypothesis B investigator → configuration / environment
-├── Hypothesis C investigator → edge case / input validation
-└── Hypothesis D investigator → dependency / version issue
-```
-
-### Debug Debate Flow
-
-```
-1. Each investigator gathers evidence for their hypothesis
-2. Lead broadcasts: "Present evidence. Disprove each other."
-3. Investigator A: "Found race condition at file:line"
-4. Investigator B: "My config theory is disproved by A's evidence"
-5. Investigator C: "A's race condition doesn't explain the timing"
-6. Converge on surviving hypothesis with strongest evidence
-```
-
----
-
-## Team Size Guidelines
-
-| Scenario | Min | Max | Rationale |
-|----------|-----|-----|-----------|
-| Quick review | 2 | 3 | Focused, low cost |
-| Full review | 4 | 5 | Core perspectives |
-| Exploration | 3 | 4 | Diminishing returns beyond 4 |
-| Planning | 2 | 3 | Too many cooks |
-| Specification (explore) | 3 | 4 | Requirements need diverse perspectives |
-| Specification (scope) | 2 | 3 | Scope planning benefits from focus |
-| Resolution | 2 | 4 | One per independent batch |
-| Debugging | 3 | 5 | One per viable hypothesis |
-| Parallel coding | 2 | 3 | Merge complexity grows fast |

package/shared/skills/ambient-router/SKILL.md

@@ -1,145 +0,0 @@
----
-name: ambient-router
-description: This skill should be used when classifying user intent for ambient mode, auto-loading relevant skills without explicit command invocation. Used by the always-on UserPromptSubmit hook.
-user-invocable: false
-# No allowed-tools: orchestrator requires unrestricted access (Skill, Agent, Edit, Write, Bash)
----
-
-# Ambient Router
-
-Classify user intent and auto-load relevant skills. Zero overhead for simple requests, skill loading + optional agent orchestration for substantive work.
-
-## Iron Law
-
-> **PROPORTIONAL RESPONSE MATCHED TO SCOPE**
->
-> QUICK gets zero overhead. GUIDED gets skill loading + main session implementation
-> with Simplifier cleanup. ORCHESTRATED gets full skill loading via the Skill tool plus
-> agent pipeline execution. Misclassification in either direction is a failure —
-> false-positive ORCHESTRATED is expensive (5-6 agent spawns), false-negative
-> GUIDED leaves quality on the table.
-
----
-
-## Step 1: Classify Intent
-
-Determine what the user is trying to do from their prompt.
-
-| Intent | Signal Words / Patterns | Examples |
-|--------|------------------------|---------|
-| **IMPLEMENT** | "add", "create", "implement", "build", "write", "make" | "add a login form", "create an API endpoint" |
-| **DEBUG** | "fix", "bug", "broken", "failing", "error", "why does" | "fix the auth error", "why is this test failing" |
-| **REVIEW** | "check", "look at", "review", "is this ok", "any issues" | "check this function", "any issues with this?" |
-| **PLAN** | "how should", "design", "architecture", "approach", "strategy" | "how should I structure auth?", "what's the approach for caching?" |
-| **EXPLORE** | "what is", "where is", "find", "show me", "explain", "how does" | "where is the config?", "explain this function" |
-| **CHAT** | greetings, meta-questions, confirmations, short responses | "thanks", "yes", "what can you do?" |
-
-**Ambiguous prompts:** Default to the lowest-overhead classification. "Update the README" → QUICK. Git operations like "commit this" → QUICK.
-
-## Step 2: Classify Depth
-
-Determine how much enforcement the prompt warrants.
-
-| Depth | Criteria | Action |
-|-------|----------|--------|
-| **QUICK** | CHAT intent. EXPLORE intent. Git/devops operations (commit, push, merge, branch, pr, deploy, reinstall). Single-word continuations. Small edits, config changes, trivial single-file tweaks. | Respond normally. Zero overhead. Do not state classification. |
-| **GUIDED** | IMPLEMENT with small scope (≤2 files, single module). DEBUG with clear error location (stack trace, specific file, known function). PLAN for focused design questions (specific area/pattern). REVIEW (always GUIDED). | Load skills via Skill tool. Main session implements directly. Spawn Simplifier after code changes. State classification. |
-| **ORCHESTRATED** | IMPLEMENT with larger scope (>2 files, multi-module, complex). DEBUG with vague/cross-cutting bug (no clear location, multiple possible causes). PLAN for system-level architecture (caching layer, auth system, multi-module design). | Load skills via Skill tool, then orchestrate agents per Step 5. State classification. |
-
-**Scope-based decision criteria:**
-
-| Intent | GUIDED (small scope) | ORCHESTRATED (large scope) |
-|--------|---------------------|---------------------------|
-| **IMPLEMENT** | ≤2 files, single module, clear task | >2 files, multi-module, complex |
-| **DEBUG** | Clear error with known location (stack trace, specific file) | Vague/cross-cutting bug, multiple possible causes |
-| **PLAN** | Focused question about specific area/pattern | System-level architecture, multi-module design |
-| **REVIEW** | Always GUIDED | — |
-
-**Classification conservatism:** Default to QUICK. Only classify GUIDED/ORCHESTRATED when the prompt has clear task scope. When choosing between GUIDED and ORCHESTRATED, prefer GUIDED — escalate only when scope clearly exceeds main-session capacity.
-
-## Step 3: Select Skills
-
-Based on classified intent and depth, invoke each selected skill using the Skill tool.
-
-### GUIDED-depth skills
-
-| Intent | Primary Skills | Secondary (if file type matches) |
-|--------|---------------|----------------------------------|
-| **IMPLEMENT** | test-driven-development, implementation-patterns, search-first | typescript (.ts), react (.tsx/.jsx), go (.go), java (.java), python (.py), rust (.rs), frontend-design (CSS/UI), input-validation (forms/API), security-patterns (auth/crypto) |
-| **DEBUG** | core-patterns, test-patterns | git-safety (if git operations involved) |
-| **PLAN** | implementation-patterns, core-patterns | — |
-| **REVIEW** | self-review, core-patterns | test-patterns |
-
-### ORCHESTRATED-depth skills
-
-| Intent | Primary Skills | Secondary (if file type matches) |
-|--------|---------------|----------------------------------|
-| **IMPLEMENT** | implementation-orchestration, implementation-patterns | typescript (.ts), react (.tsx/.jsx), go (.go), java (.java), python (.py), rust (.rs), frontend-design (CSS/UI), input-validation (forms/API), security-patterns (auth/crypto) |
-| **DEBUG** | debug-orchestration, core-patterns | git-safety (if git operations involved) |
-| **PLAN** | plan-orchestration, implementation-patterns, core-patterns | — |
-
-**Excluded from ambient** (review-command-only): review-methodology, complexity-patterns, consistency-patterns, database-patterns, dependencies-patterns, documentation-patterns, regression-patterns, architecture-patterns, accessibility, performance-patterns.
-
-See `references/skill-catalog.md` for the full skill-to-intent mapping with file pattern triggers.
-
-## Step 4: Apply
-
-<IMPORTANT>
-When classification is GUIDED or ORCHESTRATED, skill loading is NON-NEGOTIABLE.
-Do not rationalize skipping skills. Do not respond without loading them first.
-BLOCKING REQUIREMENT: Your FIRST tool calls MUST be Skill tool invocations — before
-writing ANY text about the task. Invoke all selected skills, THEN state classification,
-THEN proceed with work. Do NOT write implementation text before all Skill tools return.
-For IMPLEMENT intent, enforce TDD: write the failing test before ANY production code.
-NOTE: Skills loaded in the main session via ambient mode are reference patterns only —
-their allowed-tools metadata does NOT restrict your tool access. You retain full access
-to all tools (Edit, Write, Bash, Agent, etc.) for implementation work.
-</IMPORTANT>
-
-- **QUICK:** Respond directly. No preamble, no classification statement.
-- **GUIDED:** First, invoke each selected skill using the Skill tool. After all Skill tools return, state classification briefly: `Ambient: IMPLEMENT/GUIDED. Loading: implementation-patterns, search-first.` Then work directly in main session. After code changes, spawn Simplifier on changed files.
-- **ORCHESTRATED:** First, invoke each selected skill using the Skill tool. After all Skill tools return, state classification briefly: `Ambient: IMPLEMENT/ORCHESTRATED. Loading: implementation-orchestration, implementation-patterns.` Then follow Step 5 for agent orchestration.
-
-### GUIDED Behavior by Intent
-
-| Intent | Main Session Work | Post-Work |
-|--------|------------------|-----------|
-| **IMPLEMENT** | Implement directly with loaded skills. Follow TDD cycle. | Spawn Simplifier on changed files. |
-| **DEBUG** | Investigate directly — reproduce bug, diagnose from stack trace/error, fix. | Spawn Simplifier on changed files. |
-| **PLAN** | Explore relevant code and design directly. The area is focused enough for main session. | No Simplifier (no code changes). |
-| **REVIEW** | Review directly with loaded skills. | No Simplifier. |
-
-## Step 5: Orchestrate Agents (ORCHESTRATED depth only)
-
-After loading skills via Step 3-4, execute the agent pipeline for the classified intent:
-
-| Intent | Pipeline |
-|--------|----------|
-| **IMPLEMENT** | Follow implementation-orchestration skill pipeline: pre-flight → plan synthesis → Coder → quality gates |
-| **DEBUG** | Follow debug-orchestration skill pipeline: hypotheses → parallel Explores → convergence → report → offer fix |
-| **PLAN** | Follow plan-orchestration skill pipeline: Skimmer → Explores → Plan agent → gap validation |
-| **EXPLORE** | No agents — respond in main session |
-| **CHAT** | No agents — respond in main session |
-
----
-
-## Transparency Rules
-
-1. **QUICK → silent.** No classification output.
-2. **GUIDED → brief statement + full skill enforcement.** One line: intent, depth, skills loaded. Then implement in main session with skill patterns applied.
-3. **ORCHESTRATED → brief statement + full skill enforcement + agent orchestration.** One line: intent, depth, skills loaded. Then follow every skill requirement and orchestrate agents per Step 5.
-4. **Never lie about classification.** If uncertain, say so.
-5. **Never over-classify.** When in doubt, go one tier lower.
-6. **Never under-apply.** Rationalization is the enemy of quality. If a skill requires a step, do the step.
-
-## Edge Cases
-
-| Case | Handling |
-|------|----------|
-| Mixed intent ("fix this bug and add a test") | Use the higher-overhead intent (IMPLEMENT > DEBUG) |
-| Continuation of previous conversation | Inherit previous classification unless prompt clearly shifts |
-| User explicitly requests no enforcement | Respect immediately — classify as QUICK |
-| Prompt references specific DevFlow command | Skip ambient — the command has its own orchestration |
-| Scope ambiguous between GUIDED and ORCHESTRATED | Default to GUIDED; escalate if complexity emerges during work |
-| REVIEW intent | Always GUIDED — single Reviewer focus, no orchestration pipeline |
-| Multiple triggers per session | Each runs independently; context compaction handles accumulation |

package/shared/skills/ambient-router/references/skill-catalog.md

@@ -1,74 +0,0 @@
-# Ambient Router — Skill Catalog
-
-Full mapping of DevFlow skills to ambient intents and file-type triggers. The ambient-router SKILL.md references this for detailed selection logic.
-
-## Skills Available for Ambient Loading
-
-These skills may be loaded during GUIDED and ORCHESTRATED-depth ambient routing.
-
-### IMPLEMENT Intent
-
-| Skill | When to Load | Depth | File Patterns |
-|-------|-------------|-------|---------------|
-| implementation-orchestration | ORCHESTRATED only | ORCHESTRATED | Any — orchestrates agent pipeline |
-| test-driven-development | Always for IMPLEMENT | GUIDED + ORCHESTRATED | Any code file — enforces RED-GREEN-REFACTOR |
-| implementation-patterns | Always for IMPLEMENT | GUIDED + ORCHESTRATED | Any code file |
-| search-first | Always for IMPLEMENT | GUIDED + ORCHESTRATED | Any — enforces research before building |
-| typescript | TypeScript files in scope | GUIDED + ORCHESTRATED | `*.ts`, `*.tsx` |
-| react | React components in scope | GUIDED + ORCHESTRATED | `*.tsx`, `*.jsx` |
-| frontend-design | UI/styling work | GUIDED + ORCHESTRATED | `*.css`, `*.scss`, `*.tsx` with styling keywords |
-| input-validation | Forms, APIs, user input | GUIDED + ORCHESTRATED | Files with form/input/validation keywords |
-| go | Go files in scope | GUIDED + ORCHESTRATED | `*.go` |
-| java | Java files in scope | GUIDED + ORCHESTRATED | `*.java` |
-| python | Python files in scope | GUIDED + ORCHESTRATED | `*.py` |
-| rust | Rust files in scope | GUIDED + ORCHESTRATED | `*.rs` |
-| security-patterns | Auth, crypto, secrets | GUIDED + ORCHESTRATED | Files with auth/token/crypto/password keywords |
-
-### DEBUG Intent
-
-| Skill | When to Load | Depth | File Patterns |
-|-------|-------------|-------|---------------|
-| debug-orchestration | ORCHESTRATED only | ORCHESTRATED | Any — orchestrates investigation pipeline |
-| core-patterns | Always for DEBUG | GUIDED + ORCHESTRATED | Any code file |
-| test-patterns | Always for DEBUG (GUIDED) | GUIDED | Any code file |
-| git-safety | Git operations involved | GUIDED + ORCHESTRATED | User mentions git, rebase, merge, etc. |
-
-### REVIEW Intent
-
-| Skill | When to Load | Depth | File Patterns |
-|-------|-------------|-------|---------------|
-| self-review | Always for REVIEW | GUIDED | Any code file |
-| core-patterns | Always for REVIEW | GUIDED | Any code file |
-| test-patterns | Test files in scope | GUIDED | `*.test.*`, `*.spec.*` |
-
-### PLAN Intent
-
-| Skill | When to Load | Depth | File Patterns |
-|-------|-------------|-------|---------------|
-| plan-orchestration | ORCHESTRATED only | ORCHESTRATED | Any — orchestrates design pipeline |
-| implementation-patterns | Always for PLAN | GUIDED + ORCHESTRATED | Any planning context |
-| core-patterns | Always for PLAN | GUIDED + ORCHESTRATED | System design discussions |
-
-## Skills Excluded from Ambient
-
-These skills are loaded only by explicit DevFlow commands (primarily `/code-review`):
-
-- review-methodology — Full review process (6-step, 3-category classification)
-- complexity-patterns — Cyclomatic complexity, deep nesting analysis
-- consistency-patterns — Naming convention, pattern deviation detection
-- database-patterns — Index analysis, query optimization, migration safety
-- dependencies-patterns — CVE detection, license audit, outdated packages
-- documentation-patterns — Doc drift, stale comments, missing API docs
-- regression-patterns — Lost functionality, broken exports, behavioral changes
-- architecture-patterns — SOLID analysis, coupling detection, layering issues
-- accessibility — WCAG compliance, ARIA roles, keyboard navigation
-- performance-patterns — N+1 queries, memory leaks, caching opportunities
-
-## Selection Limits
-
-- **Maximum 3 knowledge skills** per ambient response (primary + up to 2 secondary)
-- **Orchestration skills** (implementation-orchestration, debug-orchestration, plan-orchestration) are loaded only at ORCHESTRATED depth — they don't count toward the knowledge skill limit
-- **Primary skills** are always loaded for the classified intent at both GUIDED and ORCHESTRATED depth
-- **Secondary skills** are loaded only when file patterns match conversation context
-- **GUIDED depth** loads knowledge skills only (no orchestration skills) — main session works directly
-- **ORCHESTRATED depth** loads orchestration skill + knowledge skills — agents execute the pipeline