ambleloftCreate with Skill Master
Build a three-step travel expense skill first. Then supply your API docs to connect the form to an existing system. Generated source stays in your project for your team to edit and maintain.
Outcome: Follow the guide to generate, check, and install a three-step travel skill, then try it in chat and optionally connect a business service.
Before you begin: A desktop version with Skill Master, a tool-calling model, and a local project folder.
On this page
01Before you start
Use an Ambleloft version with the built-in Skill Master and creation card. Configure a model that supports tool calls and choose a local project folder. Installation currently requires local output. If the creation entry is missing, check your version and enabled skills. After updating from source, fully quit and restart the app.
Set up the app and a model02Start in a local project
Create or select a local project, then create a task. Choose “Create skill / extension” below the composer. This selects Skill Master and adds a prompt to your draft. Add your goal and send it. Clicking the entry does not send a message automatically.
Create a three-step travel expense tool for colleagues to use in chat.
Step one collects the destination; step two collects the amount and expense note.
Step three lets the user review and confirm.
Send the confirmed details to chat and prepare an application draft.
Leave the finance system integration for later.
Use Skill Master to guide creation, checks, installation, and a trial.03Agree on the purpose and fields
Skill Master should reuse the details you supplied and ask only about decisions that affect the implementation. It can suggest a name, steps, and fields for you to edit. For this example, agree on CNY amounts greater than zero and a required expense note. The final step lets the user return to check earlier entries and tick a confirmation box. A defined business form can ship as a standalone skill. Confirm company rules before adopting the model’s suggestions.
04Compare the output with a complete example
Ask Skill Master to use the linked three-step tutorial as a reference. Alternatively, save its SKILL.md and forms/travel.yaml in reference/travel-expense in your project and ask the agent to read them. You can change the name, fields, and instructions. Generated files should go into a dedicated project directory that preserves existing files.
Get the complete travel form files and configuration guide05Review the creation card and checks
Expand the plan and verification details. Check the goal, output type, source directory, and unverified requirements. When the files are ready, Skill Master asks the host to check and prepare an installation snapshot. A standalone skill should include SKILL.md and its referenced YAML file. Verify that submission uses chat. Passing this check establishes installation readiness; it does not execute generated code or prove a business integration works.
travel-expense/
SKILL.md
forms/
travel.yaml06Install the checked version
Choose “Install and enable” on the creation card after reviewing the output. If a skill name already exists, choose replacement or a separate copy. Installation uses the checked snapshot. Source files remain editable in the project; later edits require another check and installation to update the installed version.
07Understand versions and verification records
The creation details keep the purpose, environment, settings, permissions and unverified items together. Host file validation only proves that the installation snapshot passed static checks; user trial confirmation is recorded separately. Records are bound to an artifact digest. Changing the installed version, settings, credentials or permissions makes previous trial confirmation historical. Try the capability again. Saving settings does not prove connectivity; without a connection-check protocol, external connectivity remains unverified. A standalone skill does not require a Node service or business server.
08Complete a trial in chat
Choose the card’s trial action, review the prepared prompt, and send it. The standalone skill is selected for the trial. Expect a three-step business form. Leave a required field blank to check validation, then enter a destination, amount, and expense note. Return to review entries, tick confirmation, and submit. Chat should receive the confirmed details so the agent can prepare an application draft. Mark the trial passed only after completing and reviewing it.
| Check | Expected result |
|---|---|
| Fields and navigation | Steps match the agreed rules, and returning to edit works. |
| Submission timing | The first two steps collect details; final confirmation sends them to chat. |
| Result | The draft reflects confirmed data without claiming acceptance by a finance system. |
09Connect the skill to an existing system
Continue in the same creation task with a new requirement, such as submitting the confirmed travel details to your expense system. Provide the system’s API docs. Skill Master can recommend packaging the skill in an extension and generate operation code for the integration. Extensions can also adapt a CLI, device bridge, or vendor SDK. Execution location, dependencies, and operation scope determine the approach. Each adapter needs its own documentation and environment testing.
10Put API documentation in the project
Save redacted Markdown or JSON documentation to a project path such as docs/expense-api.md, then ask the agent to read it. Include purpose, authentication, field rules, and request, success, and error examples. For writes, describe idempotency keys and result lookup. Ask the agent to identify missing contracts rather than invent service addresses or business rules. Material the agent reads may enter the selected model service’s context; check what you share.
Read docs/expense-api.md and continue the travel tool.
Identify the documented submission and result lookup flow, and list missing contracts.
Keep the agreed three-step form and generate the required extension code.
Put the service address in extension settings and use the host’s supported credential flow.
Check the code and test against a clearly labeled simulation first.
Confirm real-system integration separately.11What the API documentation needs to answer
This is a documentation checklist, not a deployed demo API. Ask the business system owner for the actual contract. The existing expense-workflow example explains form-to-operation mapping, submission identity, and failure recovery. Its demonstration behavior does not define your company’s API.
| Material | Include |
|---|---|
| Business rules | Who can submit, currency and amount rules, required fields, and approvals. |
| API and authentication | Methods, paths, authentication mechanism, and scopes. Use placeholders for credentials. |
| Fields and responses | Request examples, record identifiers, status, validation errors, and authorization errors. |
| Idempotency and lookup | How the service deduplicates submissions and reports the outcome of a prior request. |
12Practice against the existing demo service
Download the brief below into your project and give Skill Master its path. It includes the expense-workflow local API, payloads, business rules, and a starting prompt. Follow its commands with Node.js ≥22.13, keep npm run service running, and set serviceUrl to http://127.0.0.1:47832. Check the local-demo health status, submit a test claim, then query the same expenseId. The reference adapter accepts only loopback HTTP. Connecting an enterprise system requires adapter changes and authentication testing; replacing it with an arbitrary remote URL is insufficient.
Download the bilingual API brief and trial steps13Configure and verify the integration
After the extension passes checks, approve installation and code trust from the creation card. Open its settings and permissions. Enter service addresses and tool paths in settings; use supported credential inputs for secrets instead of chat or source files. Grant the needed project access and operation permissions. Missing configuration should produce a clear setup message. Start with simulation or read-only tests, then authorize one test write and verify it by record ID or result lookup. Record generation, checks, installation, configuration, simulation, and real calls separately.
14Pause, repair, and continue
Stopping preserves the creation record and confirmed requirements. Return to the same task and send additional details, or use the continue action to prepare a prompt. Unanswered questions still need answers. If a check fails, ask Skill Master to fix the relevant files and check again. If no form appears, check skill enablement, model tool calls, and YAML references. When a submission times out with an unknown outcome, query its status before submitting again. Repeat checks, installation, and trial after repairs.
15Continue learning or build manually
Use the form reference to maintain YAML yourself. Move to the manual extension tutorial when you want control over the SDK, build, and packaging process. SSH projects support development on a server; remote output currently needs to be copied back before local installation.
Advanced: build an extension manuallyCheck the result and troubleshoot
Follow the guide to generate, check, and install a three-step travel skill, then try it in chat and optionally connect a business service.
Check actual results using this page’s verification steps. For business integrations, inspect UI submission, tool receipts and server records separately.
Open the error reference →