Start with the objective
The first unit of work in xmode is not a command. It is an objective. The objective says what outcome the team wants, which project it belongs to, and what success should look like.
That framing is important because automated steps can only be judged against intent. If the objective is vague, the system should not pretend the work is ready to execute. It should create or request a plan, ask for missing context, or route the work through a manual revision step.
Skills describe reusable capability
A skill captures how a type of work should be performed. It can define best practices, constraints, expected inputs, expected outputs, review standards, and failure modes.
For example, a planning skill might describe how to break a user story into implementation tasks. A dependency update skill might describe how to inspect changelogs, run tests, and identify migration risk. A code review skill might describe what security and behavior regressions to look for.
Skills are reusable because they are not tied to one pipeline. A team can use the same planning skill in an issue implementation pipeline, an incident response pipeline, or a maintenance pipeline.
Actions turn skills into executable steps
An action is the concrete pipeline step. It connects a skill to a provider, local runner, manual approval, webhook, or future integration. It declares typed input and output contracts so the pipeline can pass data between steps without relying on ambiguous prose.
This separation keeps the catalog maintainable. Teams can improve a skill without rewriting every pipeline, and they can add new actions that use the same skill in different execution contexts.
Plans make ambiguity visible
Some work can run from a default plan. Other work needs a plan generated and verified before implementation. xmode supports both paths because not every automation step has the same risk profile.
A low-risk action might run immediately with default inputs. A code-changing action might first create a plan, wait for approval, and only then execute. A manual action might ask a human to revise the objective or trigger a different branch of the pipeline.
Pipelines compose the operating model
Pipelines wrap sets of actions into repeatable workflows. They can be attached to projects, triggered manually, scheduled, or started from events. A project might have one pipeline for implementing issues, another for updating dependencies, and another for handling production errors.
The result is a system where teams define how work should happen once, then reuse that operating model without hiding the details from reviewers.