cc-run-library-sdk-example

name	cc-run-library-sdk-example
description	Example file for the Run app skill showing how to document building, testing, and smoke-checking a library or SDK at its public package boundary

Example: Library / SDK

Libraries don't have a "run" step in the process sense — there's no server to start, no CLI to invoke. For libraries, the run skill is about:

1. Building the library from source
2. Running the test suite
3. A minimal working example that exercises the library and proves it's installed correctly

Keep it brief. The template's Build and Test sections do most of the work.

The smoke-test example

The main library-specific addition is a tiny program (or REPL snippet) that imports the library and does one real thing. This is how an agent confirms "yes, the library is usable":

Verify

python -c '
from mylib import Client
c = Client()
print(c.ping())
'
# → pong

Or for a compiled language:

cat > /tmp/smoke.go <<GO
package main
import "example.com/mylib"
func main() { println(mylib.Version()) }
GO
go run /tmp/smoke.go
# → v1.2.3

Example snippet

---

name: run-mylib description: Build, install, and test mylib from source. Use when asked to verify mylib works, run its tests, or build a distribution.

mylib is a Python library — "running" it means building from source and executing the test suite.

Setup

pip install -e '.[dev]'

Verify

python -c 'import mylib; print(mylib.__version__)'
# → 2.1.0

Test

pytest

Subset of tests: pytest tests/unit/. With coverage: pytest --cov=mylib.

Build (distribution)

pip install build
python -m build
# → dist/mylib-2.1.0-py3-none-any.whl

Things to consider documenting

• Development mode vs installed mode. pip install -e . vs pip install . — if behavior differs, say which to use for what.
• Optional dependencies. [dev], [test], [docs] extras and when each is needed.
• Generated code. If there's a codegen step (protobuf, OpenAPI clients), document it — it's almost always missing from READMEs.