Skills

This page describes how skills are used inside a workspace and which controls are currently available.

Basic concept

A skill is a working instruction for recurring tasks or domains. It influences which files, rules, and review steps the assistant starts from inside the workspace.

Purpose

Skills structure recurring tasks so the assistant follows the same guidance in similar situations.

Effect during assistant runs

Skills prioritize starting points, define relevant rules, and limit change paths that should be avoided.

Visibility in the workspace

Inside the workspace, product skills and custom workspace skills appear together. Depending on policy, they can be enabled, disabled, edited, or reset.

Limits

Skills do not change business or technical responsibility. Results still need to be reviewed and approved.

Current workspace functionality

  • The skills page shows product skills and custom workspace skills together.
  • The activation state of individual skills can be changed directly for the current workspace.
  • Search, activation state, and source can be used to narrow the visible result set.
  • Custom skills and permitted product skills can be edited inside the workspace.
  • Workspace skills can be extended when additional domain guidance or working rules should be captured.
  • Edited product skills can be reset to the product default. Workspace-local skills can be removed.
  • After enabling, disabling, or creating a skill, the chat should be restarted so the assistant uses the current skill state.

Example: a workspace skill for a Z service

If a workspace contains the service `ZUI_BILLING_APPROVAL_SRV` and the core logic lives in `ZCL_SD_BILLING_APPROVAL_SERVICE`, a custom skill can define that entry point and its related rules.

Starting point

Several tasks touch the same domain: approval rules, status transitions, mappings, or validations around a specific Z service.

Defined guidance

The skill defines that the assistant starts from the central service class, keeps business rules there, and does not distribute them across UI handlers or generic helpers.

Expected effect

The assistant starts from a defined entry point and stays closer to the intended domain boundaries when making changes.

Example custom skill

---
name: sd-billing-approval-skill
description: Use when tasks affect billing approval behavior behind ZUI_BILLING_APPROVAL_SRV.
---

# SD Billing Approval

Use when tasks change approval checks, release rules, status transitions, or mappings behind `ZUI_BILLING_APPROVAL_SRV`.

Always start from `ZCL_SD_BILLING_APPROVAL_SERVICE` as the central domain service.
Keep approval rules and threshold logic in this service or its domain collaborators.
Do not move billing approval logic into UI handlers, RAP facades, or generic helper classes.
When changing behavior, also inspect:
- `ZIF_SD_BILLING_APPROVAL_TYPES`
- `ZCL_SD_BILLING_APPROVAL_REPOSITORY`
- `ZCL_SD_BILLING_APPROVAL_LOG`

Prefer extending the existing service flow over adding a parallel second implementation.

This example shows how recurring domain guidance can be captured in a skill.