Skill Creator

Create a reusable skill

Turn a recurring workflow into real skill files. Complete a version that handles a representative task, then improve it using execution results and user feedback.

Communicate with the user in their language. For a new skill, write the description, instruction prose, and supporting guidance in English unless the user explicitly requests another authoring language. A conversation in Chinese or a request for Chinese deliverables does not change this default. Preserve an existing skill's instruction language unless asked to change it.

Define the skill's output language separately. Keep required output headings, literal values, localized trigger phrases, and example input/output in the appropriate language; do not translate exact strings required by the user. English instructions can produce Chinese deliverables.

Identify the workflow to reuse

Use the current conversation to establish the trigger, inputs, deliverables, essential steps, required tools, and success criteria. Proceed when enough information is available. Ask only for missing information that would change the scope or delivery; do not require a technical questionnaire.

• Create a new skill: start with a concrete recurring task. If the request is vague, use a representative input and expected output to narrow the scope.
• Capture a conversation: extract methods, corrections, and acceptance criteria the user actually accepted. Remove one-off data, temporary paths, failed attempts, and unconfirmed preferences. Do not turn permission for one task into standing authorization for future tasks.
• Improve an existing skill: read its source, supporting resources, and failing examples first. Locate problems in its trigger description, steps, resources, or runtime requirements. Preserve its name and working behavior; rename it only when the user wants a separate copy.

A skill supplies instructions and resources; it does not add tools, permissions, or product features. Use plugin authoring for workbench interfaces, persistent controls, or plugin commands. State missing external dependencies instead of inventing callable interfaces.

Write the source

Read Authoring guidance, then create a dedicated directory in the current writable workspace, such as skills/meeting-summary/. Put SKILL.md at its root and match the directory name to the frontmatter name. Inspect existing files before editing and preserve user content.

Start with one clear entry point. Carry the user's acceptance criteria into explicit output requirements using the authoring guidance. Add references/, scripts/, or assets/ only when needed. Do not generate empty directories, placeholder scripts, generic READMEs, or a fixed evaluation project. A Markdown-only skill needs no Python, Node, or dependency installation.

Prefer the original source when editing an existing skill. Built-in skills and installed copies are not writable source directories. If the source is unavailable, use files supplied by the user or already authorized for reading and maintain a copy in the workspace. Do not bypass file permissions to access private application directories.

Validate and try the skill

Read Validation and iteration and choose checks proportional to the risk. Discover lexora_skill_prepare through lexora_tool_search, then validate the format and resources of one skill directory:

{ "source": "skills/meeting-summary" }

Fix issues using the returned code and diagnostics, then validate again. The tool checks document format, resource packaging, and installation conflicts. It does not run scripts, install dependencies, or prove that the skill can complete a real task. runtimeTested: false indicates neither a passed nor a failed behavior test.

Try the workflow on a representative task and inspect the actual output against the acceptance criteria. Run newly added executable scripts on permitted, isolated inputs. External communication, publishing, payments, and data changes remain subject to the current task's authorization. Distinguish static review, a trial in the same conversation, and independent execution; report what actually ran and what remains untested. Do not invent evaluation scores or multi-agent results.