Contributions

This section covers how matic turns worktree-bound changes into reviewable contributions on shared repositories, then pulls provider feedback back into the runtime. It matters because shared surfaces in matic are never mutated ad hoc: branch publication, review, checks, comments, and merge all need stable contracts that preserve auditability and human control. Read these pages to understand the provider-neutral model first, then the provider-specific adapters and lifecycle details.

Creation

How matic creates a contribution from a prepared branch or worktree, including the canonical request shape, metadata, and publication flow. Read more

Comment Ingestion

How provider-native comments, review notes, and discussion events are normalized back into signals matic can route, attribute, and act on. Read more

Provider Interface

The shared contract that contribution providers implement so the rest of matic can create, inspect, update, and close contributions without hard-coding GitHub or GitLab semantics. Read more

GitHub Adapter

How the provider interface maps onto GitHub pull requests, reviews, comments, check runs, and merge operations. Read more

GitLab Adapter

How the same contribution contract maps onto GitLab merge requests, discussions, pipeline state, and merge behavior. Read more

Review And Merge

The end of the contribution lifecycle: reviewer decisions, merge eligibility, human approval points, and the transition from open review to integrated change. Read more

Status Checks

How CI, validation, and other external check systems are observed and reduced into contribution status that matic can use for gating and operator visibility. Read more