The simplest contribution loop is: choose a narrow goal, edit locally, run the build, inspect the rendered page, and open a pull request with a clear summary. The loop is intentionally ordinary because ordinary workflows are easier to repeat.
Pull Request Flow
Code
skinparam backgroundColor transparent
start
:Create a branch;
:Edit content or code;
:Run local checks;
if(Checks pass?) then (yes)
:Open pull request;
:Respond to review;
if(Approved?) then (yes)
:Merge;
else(changes requested)
:Patch and rerun checks;
endif
else(no)
:Read the failing output;
:Fix the smallest cause;
endif
stop
Review Conversation
Code
skinparam backgroundColor transparent
actor Author
participant "Pull Request"as PR
participant Reviewer
participant "CI Checks"as CI
Author -> PR: Push focused change
PR -> CI: Run build and tests
CI --> PR: Pass/fail signal
Reviewer -> PR: Ask about scope or clarity
Author -> PR: Explain, patch, or split
Reviewer --> Author: Approve when risk is understood
Useful Local Commands
The command runner can show examples for shells and compiled languages even when they are not executed in the browser. That makes it useful for tutorials about workflows.
Local Contributor Commands
npm install
npm run build --workspace @libreuni/main
npm run dev --workspace @libreuni/main -- --host 127.0.0.1 --port 4321
Expected output
Dependencies installed
Astro build completed
Local preview available at http://127.0.0.1:4321
bash
1npm install
2npm run build --workspace @libreuni/main
3npm run dev --workspace @libreuni/main ----host 127.0.0.1--port 4321
Commit Shape
A small commit message should say what changed and why it matters.
It should have the first word in square brackets and indicate the type of change, such as [Add], [Fix], [Update], or [Refactor].
[Add] LibreUni contribution showcase courseIntroduces a project-oriented course that demonstrates MDX authoring,diagrams, code labs, quizzes, case studies, and local contribution flow.
Pull Request Scope
A contributor has three ideas: add a typo fix, add a new lesson, and redesign the course cards. They are unrelated and each has different review risk.
What should they do first?
Answer: Start with the typo fix or the new lesson as a focused pull request
Focused pull requests are easier to review and merge. Larger design work benefits from a separate discussion and a separate implementation.
Pull Request Scope
A contributor has three ideas: add a typo fix, add a new lesson, and redesign the course cards. They are unrelated and each has different review risk.
What should they do first?
Knowledge Check
Why run the local build before asking for review?
Answer: It catches syntax, routing, and rendering failures before someone else spends review time
The build cannot prove the teaching is perfect, but it catches many mechanical issues early.