Software Orchestrator
f6691b74f6
- New specialist: ui_design_specialist with iterative mockup dialog - New Phase 3 (UI Design) between Architecture and Implementation - Relay model: orchestrator passes responses verbatim in Phase 3 - Cost-control exception for UI Design phase (unlimited subagent calls) - Webspace mockup workflow with cache-buster and obscure dirs - UX states coverage (loading, empty, error, partial) - WCAG 2.1 AA accessibility guidelines - Design tokens (CSS custom properties) in design system - Component states (hover, focus, active, disabled, loading, error) - Sitemap/wireframe before mockups for complex UIs - Real content strategy (no Lorem Ipsum) - Form validation UX in mockups - Dark mode and i18n support (optional) - Design handoff support (specialist available during implementation) - Skip mechanism for non-UI projects - Mockup state file for context compression recovery - Multi-page mockup strategy with index.html - task_graph.json mockup references - Plugin version: 0.1.14 -> 0.2.0 - 47 files changed across 7 implementation blocks - 3 review rounds with 41 corrections integrated
55 lines
2.1 KiB
Markdown
55 lines
2.1 KiB
Markdown
---
|
||
name: tool-governance
|
||
description: Tool registry, capability checks, and fallback handling for the orchestrator agent.
|
||
tags: ['management', 'tools', 'registry']
|
||
---
|
||
|
||
# Tool Governance
|
||
|
||
## Purpose
|
||
Maintain a registry of available tools, verify capabilities before use, and define fallback behavior when a tool is unavailable.
|
||
|
||
## When to Use
|
||
- Before invoking any tool for the first time
|
||
- When a tool returns an unexpected error
|
||
- When the agent needs to discover what tools exist
|
||
- During phase transitions
|
||
|
||
## When Not to Use
|
||
- For well-known core tools (terminal, browser, code execution)
|
||
- For tools just confirmed working in this session
|
||
|
||
## Procedure: Tool Discovery
|
||
1. Use the `tool_registry` plugin tool to list available tools
|
||
2. Read tool documentation from help/<topic>/help.md
|
||
3. Note required inputs, expected outputs, error modes
|
||
|
||
## Procedure: Capability Check
|
||
1. Verify the tool exists in registry
|
||
2. Verify all required inputs are available
|
||
3. Verify the tool is enabled (not toggled off)
|
||
4. If any check fails: see Fallback
|
||
|
||
## Procedure: Fallback
|
||
- Tool not found: use `capability_check` to find closest alternative
|
||
- Tool disabled: ask user to enable or use alternative
|
||
- Tool errors persistently: delegate to test_debug_engineer for diagnosis
|
||
- UI design tool issues: delegate to ui_design_specialist for UI design workflow questions
|
||
|
||
## Available Specialist Profiles
|
||
- `requirements_analyst` – Requirements, acceptance criteria
|
||
- `solution_architect` – Architecture, design, task graph
|
||
- `ui_design_specialist` – UI design planning, mockup creation, design handoff support
|
||
- `implementation_engineer` – Code implementation
|
||
- `test_debug_engineer` – Tests, debugging, root cause
|
||
- `quality_reviewer` – Quality review at every phase gate
|
||
- `runtime_devops_engineer` – Runtime verification, deployment basics
|
||
- `security_data_engineer` – Security, data, migration risks
|
||
- `deploy_agent` – Coolify deployment
|
||
- `release_auditor` – Release audit, handoff
|
||
- `codebase_explorer` – Read-only codebase exploration
|
||
|
||
## See Also
|
||
- Plugin tool: `tool_registry`
|
||
- Plugin tool: `capability_check`
|