01
Script folder
You need at least the executable main entry and the minimum folder structure that lets the platform understand what the capability is for.
Onboarding Checklist
Onboarding Checklist
Before DeliveryWhat slows onboarding down is often not missing features. It is incomplete scripts, documentation, samples, dependencies, and boundary information.
This page lists the information that should be prepared before onboarding so customers, presales, and delivery can align faster.
Before a real scenario moves into onboarding, it is better to make the script folder, README, sample files, runtime dependencies, result shape, and risk boundary clear first. That makes later customer delivery, file processing, and CLI / local-bridge discussions much smoother.
script folderREADMEsample filesrisk boundary
EXECFABRIC // ONBOARDING CHECKLISTDOC 11
const requiredPack = ['script_folder', 'readme', 'sample_file', 'runtime_dep']const boundaryInfo = ['ai_allowed', 'manual_confirm', 'result_format']const onboardingGoal = 'delivery_ready_handoff'
BETTER INPUTS MAKE ONBOARDING FASTER
02
README explanation
Tell the platform what the script does, what it takes in, what it returns, and what prerequisites it needs.
03
Sample files
If the script depends on input files or generates output files, it is better to provide example input and example output.
04
Risk boundary
It is best to say early whether AI may call it, whether manual execution is allowed, and whether manual confirmation is required.
Checklist Table
These are the inputs you should ideally provide together at least once
| Preparation item | Should it be provided early | Why it matters | Recommended explanation |
|---|---|---|---|
| Script folder | Required | There is no onboarding path without the actual execution content | At minimum, make the main entry and the minimum folder structure explicit. |
README.md | Required | It helps review, naming, and later maintenance | It should explain purpose, input, output, prerequisites, and result form. |
| Sample input | Strongly recommended | It makes onboarding effects much faster to verify | If file processing is involved, provide example files. |
| Sample output | Strongly recommended | It helps confirm whether the result matches expectation | This can be a sample output file, screenshot, or result-field explanation. |
| Runtime dependencies | Strongly recommended | They affect deployment and onboarding method | For example Python version, third-party packages, system tools, or external services. |
| Whether AI may call it | Recommended | It decides whether the intelligent brain may recommend this capability | Not every script enters AI recommendation scope by default. |
| Whether manual execution is allowed | Recommended | It decides whether the page opens a manual entry | This can be controlled separately from AI invocation. |
| Whether manual confirmation is required | Recommended | It controls the confirmation step for higher-risk actions | This fits scenarios such as rewriting data, sending messages, or triggering external actions. |
| Result form | Recommended | It affects result display and the result-download entry | The result can be text, a table, Excel, a zip package, or another artifact. |
| Expected execution duration | Recommended | It affects frontend experience and result-return method | Short tasks and long tasks usually need different user experience design. |
| Data-security boundary | Recommended | It affects whether the path should run in cloud execution or local bridging | When intranet or private resources are involved, the CLI / Agent route is usually needed. |
If Not Ready Yet
If the materials are not complete yet, start with these first
- You can start with the public experience entry to feel the platform path first
- You can begin a discussion with only a minimal script folder and a README
- If you are still deciding where the platform fits, start from the product overview and FAQ
- If the task clearly depends on files, adding sample files and expected results early will save time
What This Avoids
Why this checklist is worth reading early
- It avoids the vague "I have a script" discussion where nobody can say how it should connect
- It avoids discovering the result shape too late and having to rework the result page or file-download path
- It avoids adding safety boundaries late because risky actions were not declared up front
- It avoids treating a scenario as a pure web capability when it should really go through local bridging
Path Matching
According to your current state, which page should you read next
| Current state | Best next page | Why | Notes |
|---|---|---|---|
| You are only learning the platform for the first time | Getting Started | Start by judging the platform position and the real entry points | You do not need a full delivery checklist on day one. |
| You are already preparing for a customer or a real project | Customer Flow / Delivery | Understand the formal delivery path and hot-update flow first | This fits joint review by presales, delivery, and the customer. |
| The task depends on input files and result files | File Upload & Result Delivery | Clarify the file chain first | This is especially useful for reporting, export, and batch data-processing scenarios. |
| The script depends on a local environment or intranet resources | CLI Guide | Local bridging is more likely to be needed | These scenarios are usually not solved only through a browser page. |
Next Read
Read the checklist, delivery flow, and file path together
Once a real onboarding stage begins, the more effective move is usually not to stay in abstract vision. It is to align delivery flow, the file path, and the local-bridge boundary together once.