What a pull request needs
1
An issue, opened before you write the code
Search the open issues first.
If it is already filed, add what you know to that thread instead of opening
a second. If it is not, open a
bug report,
an improvement
or a feature request,
and link it from the pull request. A field has to mean something on
Pipecat, on LiveKit and on SLNG, or be refused by name where it
cannot. Settling that on the issue takes a day. Finding it out on a
finished branch costs you the branch.
2
An example package that uses your feature
Ship a package in the same branch, shaped like the ones in
examples/, that
uses the thing you added. Your new key appears in its authored files,
the code path runs on a real call, and the package declares every target
the feature claims. A package that compiles but never touches your new
field cannot be reviewed. Extending an existing example counts.3
A video of that example working
Record your screen with sound while you talk to the agent. Drive it to the
point where the feature fires. Say which target and which route, and what
to listen for. Audio is the part that matters: the pause, the interruption,
the value the agent did not have to ask for. A minute or two is enough.
4
A README for that example
What the agent does, which targets and transports it declares, what it
needs before it runs, how to run it, and which part of it is your feature.
Every example already carries one. Copy the closest.
5
Updated docs that explain the logic
A feature nobody can find is a feature nobody uses. Write the page in
docs-site/ in the same pull request, and update the coding agent skill so
an assistant knows the feature exists.Explain the logic, not just the key
A page that lists a field name and its type has not explained anything. Write what somebody needs in order to predict the behaviour:
A change to emitted behaviour touches four surfaces in the same commit: the
generated runbook template, the example’s own README, the page here that
teaches it, and the coding agent skill. A fact that is only true in generated
output is a fact no reader ever sees.
Where the package goes
Adding a directory under
examples/ fails the suite until its name is written
into the hardcoded list in internal/generate/examples_test.go. That is the
moment somebody decides the public set grew.
Run the checks before you push
make test is the gate. make smoke proves the emitted Python actually runs,
needs Python installed, and is opt-in. Run it yourself if you changed what
gets emitted.