Change Layer Docs
    Checking session...

    Getting Started

    Most teams start with a simple workflow: create a team, add a product, launch a changelog, and begin publishing updates. Over time, that same product can also grow into a home for release notes, roadmap planning, and developer-facing workflows.

    Typical setup flow

    1. Create or join a team workspace.
    2. Add a product for the app, platform, or business surface you want to document.
    3. Create a changelog for that product.
    4. Add a version manually or generate one from GitHub activity.
    5. Add or refine the individual changes inside that version.
    6. Publish the version and make sure the changelog itself is visible.
    7. Expand into release notes, roadmap planning, and developer integrations as your workflow matures.

    A useful mental model

    A product is the container. Changelogs, release notes, and roadmaps are the layers of communication around that product. Versions and changes are the release-level details your customers and teammates actually consume.

    Create your first changelog

    When a product does not have a changelog yet, create one from the product page. Once it exists, the changelog becomes the place where your published versions are shown in reverse chronological order.

    From there, your team usually manages three things:

    • Visibility: whether the changelog is still a draft or visible to readers.
    • Branding: the changelog logo and linked product website.
    • Content: the versions and changes readers will see.

    Add versions

    You can add versions in two ways:

    • Manual entry: create a version number, set a release date, and write the changes yourself.
    • GitHub-assisted generation: connect the GitHub app and generate a draft from a branch, pull request, or release.

    Generated versions are meant to save time, not replace editorial review. Teams should still review change wording before publishing.

    Publish with confidence

    Readers only see published content:

    • The changelog itself must be published.
    • Each version you want visible must also be published.
    • Private teams still require authentication even if content is marked as published.

    Common team workflow

    1. Product or engineering drafts a version.
    2. Marketing, support, or product reviews the wording.
    3. The team publishes the version.
    4. Customer-facing teams link to the hosted changelog in release emails, support replies, or in-app announcements.

    Growing into AI-assisted workflows

    As Change Layer expands, the product is also being positioned for AI and agent workflows. The roadmap includes a CLI and MCP support so product context can be used more directly by internal tooling, scripts, and autonomous agents.

    What to read next