Start with one contribution you can finish.

01 · CHOOSE A PATH

There are three useful ways to help.

Star a repository, share a real use story, or send a focused patch. Pick the one that fits the time you have today.

Star a repository

Star the public Peekling repository most useful to you. Stars help interested developers find the project through GitHub.

Tell us where you use Peekling

Open a focused issue with the site, product, or experiment where a Peekling lives. A short description and a public link are enough.

Submit a focused contribution

Improve the engine, documentation, examples, tests, or character packs in the repository that owns the work.

02 · CHOOSE A PROJECT

Put the work where its contract lives.

Read the repository README, contribution guide, package guide, and recent issues. For a new public API, official character, package, cross-repository change, or large visual direction, begin with a focused issue so everyone can agree on the smallest useful outcome.

• Engine owns the browser runtime, Configuration, Plans, lifecycle, CLI, validation, compatibility, performance, examples, and engine documentation.
• Characters owns official packs, animation states, manifests, provenance, licensing, package tests, and pack documentation.
• The Peekling organization collects every public project and its current contribution guidance.
• Describe compatibility, security, accessibility, or licensing effects early.

03 · ENGINE WORKFLOW

Keep runtime changes narrow and verifiable.

The engine requires Node.js 22.14.0 or newer. Install the locked dependency graph, run the core repository gate, then run browser behavior separately when the change can affect a page.

git clone https://github.com/peekling/peekling-engine.git
cd peekling-engine
npm ci --ignore-scripts
npx --no-install playwright install chromium firefox webkit
npm run check:core
npm run test:browser

04 · CHARACTER WORKFLOW

Treat artwork, data, and rights as one deliverable.

New official characters begin with an issue so name, collection fit, provenance, and license can be discussed before extensive art work. A pack remains data-only and ships its manifest, atlas files, thumbnail, license, notice, and package documentation as one reviewed boundary.

git clone https://github.com/peekling/peekling-characters.git
cd peekling-characters
npm install
npm run build
npm run check
npm run changeset

Keep source art and development helpers beside the project workflow. The published package carries the validated runtime files. Its manifest state names, frames, timings, dimensions, density records, and hashes agree with the generated files.

05 · DOCUMENTATION CHANGES

Make the next correct action obvious.

Documentation fixes matter when they preserve the owning contract. Update the guide closest to the task, keep examples runnable, and link to a canonical source so every reader reaches the same current rule.

1. State who the page is for and what they can complete.
2. Lead with a working path, then explain options and boundaries.
3. Use current package names, versions, commands, fields, and Event names.
4. Label released behavior and planned work clearly.
5. Check links, code samples, mobile layout, and reader-facing language.

06 · SECURITY AND RIGHTS

Protect people and creative work.

Follow the security policy in the affected repository and report an exploitable vulnerability through its private disclosure path. Character art arrives with original authorship or a compatible license, plus provenance and attribution reviewers can verify.

Runtime safety

Preserve data-only packs, strict validation, bounded resources, host isolation, cleanup, dismissal, and a telemetry-free runtime.

Artwork rights

Record the creator, source, license, allowed redistribution, and required notices for every submitted asset.

Brand boundary

The code license covers its stated source. The Peekling name, logo, official mascot, and other distinctive identity follow their published brand terms.

07 · PULL REQUEST CHECKLIST

Give reviewers the evidence they need.

• Explain the problem, the chosen scope, and the visible result.
• List focused and full verification commands with their outcomes.
• Include screenshots or recordings when they help verify a visual or interaction change.
• Describe compatibility, security, accessibility, performance, and packaging effects.
• Add the required release record or Changeset for every affected package.
• Keep the patch focused on the contribution being reviewed.

08 · NEXT STEP

Your contribution becomes part of the project's history.

Accepted commits and merged pull requests remain in GitHub's public history with the identities recorded for that work. This makes each accepted contribution visible and verifiable. Start with a star, a use story, or one well-owned patch.