Skill System Overview

This overview explains how Achilles Agents organises skills, repositories, and execution layers into a coherent orchestration platform.

Design Philosophy

The library embraces a declarative skill graph approach: skills declare their capabilities, orchestration scripts or planners compose them, and agents interpret user intent through iterative, human-in-the-loop conversations.

High-Level Architecture

The ecosystem revolves around four collaborating layers:

  1. Skill Registry: Maintains metadata, argument schemas, enumerators, and access policies.
  2. Interactive Skill Flow: Guides conversational argument acquisition and validation.
  3. Orchestration Skills: Translate LightSOPLang scripts or LLM plans into sequenced actions.
  4. Execution Agents: LLMAgent mediates with language models; RecursiveSkilledAgent supervises nested plans and cancellations.

The flow aligns with the runtime architecture:

RecursiveSkilledAgent
  ├─ Skill Discovery: scan .AchillesSkills/* for skill.md, cgskill.md, iskill.md, mskill.md, oskill.md, tskill.md
  ├─ Subsystem Router: claude | code | interactive | mcp | orchestrator | dbtable
  ├─ LLMAgent: shared completion/review + session memory
  └─ Execution: plan (LightSOPLang or LLM) → run skill → record history

Skill Repository Conventions

Achilles Agents skills are stored as Markdown descriptors inside a .AchillesSkills/ directory. Each skill lives in its own folder and is identified by the folder name:

.AchillesSkills/<domain>/<skill_name>/
    ├── skill.md | iskill.md | oskill.md | mskill.md | cgskill.md | tskill.md   (descriptor)
    └── <skill_name>.mjs / .js                          (entrypoint when the family supports it)

The descriptor suffix maps to the skill family:

Interactive skills require a JavaScript module exporting specs and action; other families may provide optional modules (for example, cgskill modules supply an action executor, while tskill code is generated into tskill.generated.mjs). Modules can also export a roles array which is recorded for future policy hooks, but it is not enforced by the runtime today.

Skill Lifecycle

  1. Declaration: Skill descriptors capture arguments, hints, and optional LightSOPLang sections; modules add executable hooks and optional (currently informational) roles metadata.
  2. Registration: Metadata is normalised; enumerators, validators, and resolvers are bound.
  3. Selection: Requests route to orchestration scripts, static mappings, or LLM planners.
  4. Execution: Skill engines govern runtime behaviour (interactive prompts, MCP tool invocations, code evaluation).
  5. Post-processing: Presenters shape confirmations, and results feed session memories or review pipelines.

Skill Families

Each family focuses on a distinct flavour of work:

These components are composable—an orchestration script may trigger interactive skills for data gathering, then execute MCP skills for external calls or code skills for verification.

Dive deeper into each family: explore Interactive Skills, learn how table descriptors become CRUD workflows in DBTable Skills, continue with Orchestration Skills, review MCP Skills, and finish with the Code Generation Skills guide.

ReAct-Aligned Planning

The system embraces the ReAct pattern (Reasoning + Acting) by isolating reasoning inside LightSOPLang or LLM plan selection, then performing atomic actions via explicit commands. This separation makes debugging easier, ensures deterministic replay, and keeps all external calls auditable.