Conversion and lifecycle
Technical quickstart
Build a small, verifiable path to a useful technical result, including prerequisites, recovery and cleanup.
Open-source skill · format validated
When this is useful
Create, test, or diagnose a runnable quickstart for a developer tool, API, SDK, connector, or data product. Use for the first working technical task, prerequisites, expected output, troubleshooting, and cleanup; not for a complete onboarding program.
What to bring
Supported product version and environment, task, approved sandbox or sample, documented interfaces, credential needs, and permitted execution scope.
What you can work toward
A runnable guide, expected outputs and success checks, failure recovery, cleanup, and a precise tested-versus-untested record.
Developer-tool version
Use one supported engineering task with sanitized input, exact prerequisites, expected output, deterministic success assertion, recovery, and cleanup. Disclose credentials or hosted costs before commands and distinguish verified execution from plausible instructions.
Data-product version
Use synthetic or authorized records with explicit schema, expected keys/values, reconciliation checks, connector permissions, resource caps, and cleanup. A green connection or sample dashboard alone is not the success assertion.
How to use it
Choose the version for your product type and follow its repository installation instructions. Keep the skill folder, references and any assets together. Each skill works on its own; reuse a shared brief when helpful rather than repeating a full intake.
The source follows the open Agent Skills format and is MIT licensed. Live research and execution depend on the tools and permissions available in your host. Preparing a plan or draft does not itself authorize publishing, messaging, spending or production changes.
A starting prompt
Use the technical quickstart skill for our developer tool or data product. Our task is [specific task], our supported environment is [environment], and the decision is [decision]. Use these facts and sources: [evidence]. Produce the requested artifact, label unknowns, and do not invent results or perform external actions beyond my authorization.
How to judge the result
Never claim a command was tested because it looks plausible. A sample working once does not prove production reliability, security, or scale.
Check that the product-specific version changes the recommendation, the requested deliverable is complete, and proposed tests are distinguished from observed results. Format validation does not establish how a model will perform on your product.
From input to reviewed output
Put it to work
- Choose the collection for your product type and install the relevant skill with its bundled references and assets.
- Supply the task, supported behavior, existing evidence and constraints that affect the decision. Reuse context already available.
- Ask for the concrete deliverable, distinguishing facts, hypotheses, unknowns and any untested instructions.
- Check the product-specific acceptance criteria, source claims and next steps before using or publishing the output.
Limits and tradeoffs
Never claim a command was tested because it looks plausible. A sample working once does not prove production reliability, security, or scale. No fresh-host model performance is claimed; verify output against your product, evidence and authorized environment.