Command Registry

The Prismatic Platform Command Registry is the authoritative catalog of all slash commands available within the AIAD ecosystem. With 228 commands organized across 16 operational categories, the registry provides the structured interface through which operators and automated systems invoke platform capabilities. Every command is defined by a machine-readable command-spec YAML specification that captures its parameters, authority requirements, output formats, and enforcement policies.

Overview

Slash commands are the primary operator interface to the Prismatic Platform. While agents provide the execution capability, commands provide the invocation mechanism -- the structured entry points through which operators trigger agent deployment, system operations, and platform management tasks. When an operator types /orchestrate or /investigate or /evolve, they are invoking a command that resolves to one or more agents through the registry's dispatch pipeline.

The distinction between commands and agents is architectural. Agents are autonomous execution units with their own state, coordination graphs, and lifecycle. Commands are stateless invocation contracts that define how operators interact with the platform. A single command may trigger multiple agents (the /orchestrate command selects and deploys entire agent teams), and a single agent may be invocable through multiple commands (the archer-supreme agent responds to both /archer-supreme and /emergency commands depending on context).

The Command Registry maintains the full specification of every command: its name, parameters with types and validation rules, required authority level, output format, category classification, and the mandatory enforcement block that connects it to the platform's NO MERCY NO DOUBTS doctrine. This specification-first approach ensures that every command is documented, validated, and discoverable before it can be deployed.

Command Categories

Commands are organized into 16 functional categories that reflect the platform's operational domains. Each category groups related commands by their primary purpose.

Category membership reflects primary purpose. Some commands participate in multiple workflows -- for example, /quality.gates is categorized under Quality Enforcement but is invoked as part of Development, Evolution, and Operations workflows.

Command Architecture

Specification Schema

Every command in the registry is defined by a command-spec YAML block embedded in its .cmd.md file. The schema captures identity, parameters, authority requirements, output formats, and enforcement policies.

command-spec:
  name: "evolve"
  description: "Self-evolving AIAD ecosystem intelligence"
  authority: "supreme"
  version: "5.1.0"
  classification:
    - "meta-evolution"
    - "self-recursive"
    - "living-intelligence"

  parameters:
    - name: "mode"
      type: "enum"
      required: false
      default: "intelligent"
      values: ["intelligent", "self-evolve", "meta-analyze", "recursive", "full"]
      description: "Evolution mode with AI-powered intelligence selection"

    - name: "scope"
      type: "array"
      required: false
      default: ["intelligent-auto"]
      values: ["intelligent-auto", "self", "aiad", "ecosystem", "all"]
      description: "Intelligent scope selection"

    - name: "meta-level"
      type: "integer"
      required: false
      default: 1
      min: 1
      max: 5
      description: "Meta-evolution recursion depth"

  outputs:
    - type: "meta_analysis_report"
      format: "structured_intelligence"
      description: "AI-powered meta-analysis of evolution effectiveness"

  enforcement:
    doctrine: "no-mercy-no-doubts"
    version: "2.0.0"
    compliance: mandatory

The specification enforces several invariants. Every command must declare a unique name, a valid authority level, at least one output type, and the mandatory enforcement block referencing the NO MERCY doctrine. Parameters must declare their type, and enum/array types must provide the complete set of valid values.

Parameter Type System

Command parameters support six types with validation rules:

All parameters support required (boolean), default (type-appropriate value), and description (human-readable documentation) attributes. Required parameters without defaults cause the dispatch engine to prompt the operator for input before execution.

Authority Levels

Commands declare an authority level that determines which operators can invoke them and what system resources the command can access:

Authority enforcement is non-bypassable. A command invoked without sufficient authority returns an authorization error with no fallback or escalation path available to the operator. Authority delegation must be configured through the platform's RBAC system before invocation.

Execution Engine

The command execution engine translates operator input into agent deployment through a multi-stage dispatch pipeline.

Dispatch Pipeline

When an operator invokes a command, the execution engine processes it through five stages:

1. Parsing: The command string is parsed into a command name and parameter map. Parameter types are validated against the command specification.

2. Authorization: The operator's authority level is checked against the command's declared authority requirement. Insufficient authority halts execution.

3. Resolution: The command specification is used to determine which agent or agents should handle the execution. Simple commands map directly to a single agent. Complex commands like /orchestrate use the Agent Registry to select an optimal agent team based on the parsed parameters and current platform state.

4. Dispatch: The resolved agent(s) are deployed with the parsed parameters as input context. For multi-agent commands, the orchestration layer manages coordination and sequencing.

5. Collection: Agent outputs are collected, formatted according to the command's declared output specification, and returned to the operator.

Implementation in Elixir

The dispatch pipeline is implemented as a series of Elixir modules within the prismatic_claude application:

defmodule PrismaticClaude.CommandDispatch do
  @moduledoc """
  Resolves slash commands to agent deployments through
  the AIAD command specification registry.
  """

  @spec dispatch(String.t(), map()) :: {:ok, CommandResult.t()} | {:error, term()}
  def dispatch(command_name, params) do
    with {:ok, spec} <- Registry.get_command(command_name),
         {:ok, validated} <- validate_params(spec, params),
         {:ok, _auth} <- check_authority(spec.authority),
         {:ok, agents} <- resolve_agents(spec, validated),
         {:ok, result} <- execute_agents(agents, validated) do
      {:ok, format_output(spec.outputs, result)}
    end
  end

  defp resolve_agents(spec, params) do
    case spec.resolution_strategy do
      :direct -> {:ok, [spec.primary_agent]}
      :orchestrated -> Orchestrator.select_team(spec, params)
      :dynamic -> DynamicResolver.resolve(spec, params)
    end
  end
end

The dispatch module uses the with construct for clean error propagation through the pipeline stages. Each stage returns {:ok, value} on success or {:error, reason} on failure, following Elixir conventions for result tuples.

Error Handling

Command execution errors are categorized and reported with structured context:

Command Lifecycle

Commands follow a structured lifecycle from initial specification through deployment and eventual retirement.

Creation

New commands are created by adding a command-spec YAML block to a new .cmd.md file in the .aiad/commands/ directory. The specification must include all required fields: name, description, authority, version, at least one parameter or explicit declaration of parameterless invocation, output specification, and the mandatory enforcement block.

After creation, the .aiad/bin/aiad index command regenerates the Command Registry, and .aiad/bin/aiad-doctor validates that no specification violations exist. The pre-commit hook ensures that invalid command specifications cannot be committed to the repository.

Testing

Every command must be testable through the platform's validation framework. Testing occurs at three levels:

1. Specification validation: The command-spec YAML is checked for schema compliance, type consistency, and cross-reference integrity.

2. Parameter validation: Each parameter type is tested with valid values, boundary values, and invalid values to verify the validation rules behave correctly.

3. Integration testing: The full dispatch pipeline is exercised with real agent resolution and execution to verify end-to-end behavior. Integration tests use the platform's test infrastructure built on ExUnit.

defmodule PrismaticClaude.CommandDispatchTest do
  use ExUnit.Case, async: true

  describe "dispatch/2" do
    test "validates enum parameters against declared values" do
      assert {:error, {:parameter_validation, _}} =
        CommandDispatch.dispatch("evolve", %{mode: "invalid_mode"})
    end

    test "rejects commands with insufficient authority" do
      assert {:error, {:authorization_failure, _}} =
        CommandDispatch.dispatch("emergency", %{},
          authority: :standard)
    end

    test "resolves orchestrated commands to agent teams" do
      assert {:ok, result} =
        CommandDispatch.dispatch("orchestrate", %{
          task: "fix compilation warnings"
        })
      assert length(result.agents_deployed) >= 1
    end
  end
end

Versioning

Command specifications follow semantic versioning. Major version bumps indicate breaking changes to parameters or output formats. Minor version bumps indicate new optional parameters or additional output fields. Patch version bumps indicate documentation corrections or internal implementation changes that do not affect the operator interface.

The registry tracks version history and flags breaking changes for review. Operators can query the registry for version-specific documentation when migrating between command versions.

Deprecation and Retirement

When a command is superseded or its functionality is absorbed by another command, it follows the platform's standard deprecation process:

1. The command specification is updated with a deprecated: true flag and a successor field pointing to the replacement command.
2. Invocations of the deprecated command emit a warning with migration guidance.
3. After two evolution cycles, the command is removed from the active registry.
4. The specification is preserved in git history for audit purposes.

Quality Standards

Every command in the registry must meet the platform's zero-tolerance quality requirements, enforced by the Quality Gates pipeline and the NO MERCY doctrine.

Mandatory Requirements

• Complete specification: All required fields present and valid in the command-spec block
• Enforcement block: Must include doctrine: "no-mercy-no-doubts" with version 2.0.0
• Parameter documentation: Every parameter must have a human-readable description field
• Output specification: At least one output type with format and description
• Authority declaration: Explicit authority level appropriate for the command's scope
• Version compliance: Specification version must follow semantic versioning
• Cross-reference integrity: All agent references must resolve to existing agents in the Agent Registry

Validation Pipeline

Quality enforcement mirrors the agent validation pipeline:

1. Pre-commit hook: Schema validation on every commit modifying .cmd.md files
2. Auto-indexing: Validation during registry regeneration via .aiad/bin/aiad index
3. Runtime loading: Specification validation during application startup
4. Continuous monitoring: The registry-syncer agent detects drift between filesystem and registry

No bypass flags are permitted. The --no-verify git option is forbidden platform-wide, ensuring that no invalid command specification can enter the codebase.

Integration with Agents

Commands and agents exist in a symbiotic relationship within the AIAD ecosystem. Understanding this relationship is essential for effective platform operation.

Resolution Strategies

Commands use three resolution strategies to connect operator invocations to agent deployments:

Direct resolution is the simplest: the command specification names a specific agent, and the dispatch engine deploys that agent with the parsed parameters. Orchestrated resolution uses the Agent Registry's query interface to assemble an optimal agent team based on the task requirements. Dynamic resolution evaluates runtime context -- current platform state, active operations, resource availability -- to select the most appropriate agent.

Coordination Patterns

Complex commands may deploy multiple agents that must coordinate during execution. The platform supports several coordination patterns:

• Sequential: Agents execute in defined order, each receiving the output of the previous agent as input. Used by /evolve which runs analysis, mutation, and validation agents in sequence.

• Parallel: Independent agents execute simultaneously. Used by /orchestrate when deploying specialists that operate on different aspects of a task.

• Pipeline: Agents form a processing pipeline where partial results flow through stages. Used by /investigate which passes raw intelligence through collection, analysis, and reporting agents.

• Supervisory: An L2 commander agent oversees the execution of multiple L3/L4 specialists, making real-time adjustments. Used by /emergency which deploys archer-supreme as the supervisory agent.

The Orchestration Loop

The /orchestrate command demonstrates the full integration between the Command and Agent registries:

defmodule PrismaticClaude.Orchestrator do
  @moduledoc """
  Implements the orchestration loop that connects
  command invocations to optimal agent team deployment.
  """

  @spec orchestrate(map()) :: {:ok, OrchestrateResult.t()} | {:error, term()}
  def orchestrate(params) do
    with {:ok, analysis} <- analyze_task(params),
         {:ok, candidates} <- query_agent_registry(analysis),
         {:ok, team} <- rank_and_select(candidates, analysis),
         {:ok, plan} <- build_execution_plan(team, params),
         {:ok, result} <- execute_plan(plan) do
      {:ok, %OrchestrateResult{
        task: analysis.task_type,
        agents_deployed: team,
        execution_plan: plan,
        result: result,
        fitness_feedback: compute_fitness(result)
      }}
    end
  end
end

The orchestration loop queries the Agent Registry based on task analysis, ranks candidates by fitness and coordination efficiency, builds an execution plan, and deploys the selected team. Fitness feedback from execution results feeds back into the evolution system, continuously improving agent selection over time.

Statistics and Metrics

The Command Registry maintains comprehensive statistics reflecting the platform's operational scope.

Current State

Category Distribution

The "Other / Uncategorized" group represents specialized commands that serve narrow operational needs -- individual agent invocations, utility functions, and domain-specific tools that do not cleanly fit the 16 primary categories.

Usage Patterns

The most frequently invoked commands across platform operations:

Cross-References

The Command Registry integrates with and is referenced by numerous platform components:

• AIAD Standard -- The specification framework defining command schemas
• NO MERCY -- The execution doctrine enforced by every command's enforcement block
• NO DOUBTS -- The investigation doctrine requiring evidence-based action
• Quality Gates -- The quality pipeline validating command specifications
• Trinity Gate -- The formal verification gate for command output validation
• Session Discipline -- The session management protocol governing command execution context
• Regression Tests -- The testing protocol ensuring command behavior stability
• Elixir -- The implementation language for the command dispatch engine
• Phoenix LiveView -- The web framework powering interactive command interfaces
• ETS -- The in-memory storage backend for runtime command resolution
• Mix -- The build tool providing mix task command implementations
• Agent Registry -- The companion catalog of agents invoked by commands

Connect & Contribute

Created by Tomáš Korcak (korczis) | Open Source under GHL

• GitHub | GitLab | LinkedIn | Contact
• Developer Portal | Architecture | Meet the Creator