---
name: Skills operating guide
version: 1.1.0
status: active
owner: Stoirm Arnold
last_updated: 15-Sep-2026
---

# Skills operating guide

## Purpose

A Skill is a portable maintained specification for a repeatable AI capability. It defines what a workflow should achieve, when it should be used, how it should behave, what context or systems it may need, and what successful completion looks like.

Skills should be usable across AI systems where the required capabilities are available. The current canonical Skill is the source of truth; chat threads are working sessions, not durable workflow instructions.

This module follows `arco-system-manual.md` for universal naming, metadata, versioning, changelog, archive, rollback and maintained-file rules. This file defines only Skills-specific behaviour.

## Module contract

- **Boundary** — Skills owns reusable workflow/capability specifications and their discovery/state. It does not own universal maintained-file rules, deployment-specific paths, shared Governance mechanics, Personas, or the domain data and outputs that individual Skills operate on.
- **Outputs** — maintained Skill definitions and Skills Register state; when a Skill is invoked, the work product belongs to the workflow/domain defined by that Skill rather than becoming a second Skills-system record.
- **Dependencies** — `arco-module-manual.md` for the universal module contract; `arco-system-manual.md` for maintained-file behaviour; deployment/local configuration for paths, Register identifiers and selected module controls; Governance for permissions and consent where required.
- **Access scope** — `Skills` at module level, with any finer-grained rights resolved through Permissions and the stable identifiers owned by Skills.
- **Deployment/local requirements** — the deployed operating copy, local Skills location, Skills Register, archive location and selected module/governance configuration described below.
- **Lifecycle state** — **Live**, as recorded in `arco-modules.md`.
- **Maintenance route** — maintained Skills files follow `arco-system-manual.md`; the universal module controls are inherited from `arco-module-manual.md`, while deployment/System Setup owns their selected values.

## Core principles

1. Skills use stable, concise canonical filenames.
2. Users should normally invoke Skills through natural-language intent rather than knowing filenames or versions.
3. Skills should contain only the instructions needed to perform their workflow reliably.
4. Preserve correct existing behaviour when improving a Skill.
5. Skills may improve through real use when evidence exposes a material problem or useful repeatable improvement.
6. Do not manufacture improvements. If a run reveals no meaningful change, finish normally.
7. When a Skill changes, tell the user briefly what changed and why.
8. Every current Skill must appear in the deployment's Skills Register.
9. The register supports discovery and governance; it does not duplicate Skill instructions.
10. Do not rely on information that exists only in the chat where the Skill was created.

## Deployment requirements

A deployment using Skills must provide:
- a deployed `readme-skills.md` operating copy;
- a local Skills location;
- a central Skills Register;
- an archive location for released Skills;
- the deployment's applicable governance and approval configuration.

Deployment-specific paths, IDs and storage details belong in `readme-skills-local.md`, not in this Core module guide.

Do not create empty per-Skill archive folders. Create a Skill's archive folder only when a released version first needs an explicit archived snapshot under the system manual.

## Skills Register

Maintain a central structured register for all current Skills.

At minimum, record:

| Field | Purpose |
|---|---|
| Skill ID | Stable identifier, e.g. `SKL-001` |
| Skill | Human-readable Skill name |
| Canonical file | Current stable filename |
| Version | Current released version |
| Owner | Individual responsible for the Skill |
| Status | Draft, active, paused or retired |
| Last updated | Date of current version |

The register is governance and discovery data. The canonical Skill file remains the source of truth for workflow behaviour.

When a Skill is created, updated, paused, retired or restored, keep the register in sync. When updating the register:
1. find the existing row by Skill ID;
2. update that row rather than creating a duplicate;
3. assign the next unused `SKL-###` ID only for a genuinely new Skill;
4. keep canonical filename, version, owner, status and last-updated aligned with the current Skill;
5. verify the saved row after writing.

## Skill file standard

Skills follow the deployed system manual for universal maintained-file rules.

Use a stable lowercase kebab-case Markdown filename without the version number, for example `process-this-blog.md`, not `process-this-blog-v1.2.0.md`.

Skills may add metadata where it materially helps discovery or execution, but do not add fields without a reason.

## Recommended Skill structure

Use only sections the workflow needs. A Skill commonly includes:
1. Purpose
2. Trigger or intended use
3. Required context or inputs
4. Workflow
5. Decision rules
6. System or file references
7. Boundaries
8. Output or completion test
9. Changelog

Do not create empty sections merely to follow a template.

## Writing Skills

Skills should be operational, clear enough for another capable AI system to follow, explicit about important constraints and decisions, concise enough to remain usable, resilient to likely ambiguity and common failure modes, and clear about successful completion.

Use numbered steps where order matters. Do not prescribe implementation detail that the executing system can safely determine unless it is required behaviour.

## Invocation

Skills are capabilities, not commands users should have to memorise. Infer the appropriate Skill from natural-language intent where reasonably clear.

Before executing a Skill:
1. identify the relevant Skill;
2. read the current canonical Skill file;
3. reuse relevant context already established in the conversation;
4. ask only for genuinely missing information;
5. execute the workflow.

If multiple Skills could reasonably apply and the distinction matters, resolve the ambiguity before proceeding.

## Using and improving Skills

During a run, follow the current Skill rather than improvising a replacement workflow.

If a run exposes a material weakness, missing rule or repeatable improvement, identify the relevant Skill instruction that should change. Evidence may include repeated requests for already-available information, outputs that fail their purpose, incorrect decision rules, recurring edge cases, user corrections that should persist, or materially changed dependencies.

Do not update a Skill merely because alternative wording or another possible approach exists.

When no improvement is identified, complete the requested workflow normally and do not ask whether the Skill should be updated.

When an improvement is identified, follow the deployment's current approval policy. If approval is required, explain what was observed, what should change and why, then wait for approval. If approval is not required, make the appropriate update and briefly report what changed and why.

## Approval policy

Approval requirements belong to the wider deployment, not to Skills generally. Skills follow the deployment's current approval configuration. Individual Skills should only add specific approval rules where genuinely required by that Skill.

## Updating a Skill

When a Skill needs to change:
1. read the current canonical Skill;
2. identify the specific behaviour or instruction that needs changing;
3. preserve behaviour that remains correct;
4. determine the appropriate semantic version change under the system manual;
5. follow the deployment approval policy;
6. archive the outgoing released version when required by the system manual;
7. update the canonical stable file;
8. update its YAML version and `last_updated`;
9. add the changelog entry;
10. update the Skills Register;
11. validate the revised workflow where practical;
12. verify the saved files;
13. briefly report the material change.

Do not make unnecessary wholesale rewrites.

## Creating a new Skill

Before creating a Skill:
1. read the deployed `readme-skills.md`;
2. check the Skills Register;
3. search for an existing capability that already covers the requirement;
4. update an existing Skill rather than create a near-duplicate where practical.

Create a Skill when the workflow is repeatable and likely to be useful again. Do not create a Skill merely because a prompt is long.

A new Skill should establish what it is for, when it should run, what context or inputs it needs, the default workflow, important decision rules, relevant systems/files/tools, meaningful boundaries, and the expected completion test.

Untested Skills should normally start as `draft`. A tested and accepted first release should normally become `1.0.0` and `active`. Add every new Skill to the Skills Register.

## Skills working together

Keep separate capabilities as separate Skills when they can usefully evolve independently. A Skill may invoke another Skill rather than duplicate its instructions. When one Skill calls another, use the current canonical version unless a historical version is deliberately required.

## External actions and verification

When a Skill creates, publishes, moves or materially updates external content:
- use the intended source-of-truth destination;
- respect the deployment's approval policy;
- verify that the action succeeded;
- never claim success solely because an attempted write returned no obvious error.

Use dry-runs where they materially reduce risk or help review a consequential action. Do not require dry-runs for harmless read-only work.

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 15-Sep-2026 | 1.1.0 | Aligned Skills with the Module Manual by explicitly defining its boundary, outputs, dependencies, access scope, deployment requirements, lifecycle state and maintenance route without duplicating universal module controls. | Stoirm Arnold | GPT-5.6 Sol |
| 14-Sep-2026 | 1.0.1 | Corrected Core lifecycle status from draft to active following successful Skills promotion. | Stoirm Arnold | GPT-5.6 Sol (Medium) |
| 14-Sep-2026 | 1.0.0 | Extracted the organisation-agnostic Skills operating standard from the Stoirm Ltd deployment, delegating universal maintained-file rules to the Arco system manual and deployment-specific paths/IDs to local configuration. | Stoirm Arnold | GPT-5.6 Sol (Medium) |