commit

The user wants to commit work done across LiteStack. Because backend/ and frontend/ are separate git repositories (submodules), a meta-level commit is a few ordered steps, not one git commit. Get the order right or the meta-repo will point at commits that were never pushed.

Step 0: Write a retrospective — only if the session earned one

Run the /retro skill only if something actually went wrong: a command failed, a change had to be rolled back, or the approach changed mid-way. A one-file documentation fix does not need one. Whether its file is staged in Step 4 depends on the mode — the retro skill's Step 4 decides.

Step 1: Detect the operating mode

Read root .agents/OPERATING-MODE.md. In short:

git config -f .gitmodules submodule.liteend-go.url
git config -f .gitmodules submodule.litefront.url

• URLs point at canonical uxname/* → TEMPLATE mode (push submodules to upstream).
• URLs point at your own repos → DERIVED mode (push submodules to your repos — every push goes to the team's remotes; the uxname/* upstreams receive only template work).

If you are unsure which mode applies or whether you should push, ask the user in plain language before pushing.

Step 2: See what changed and where

git status                  # at meta root: shows which submodules are dirty + meta files
git submodule status

Step 3: Commit inside each changed submodule

For each submodule that has changes (backend and/or frontend):

cd <submodule>
# Run that project's own gate FIRST, from its AGENTS.md:
#   backend  → task check      (and task test:cov before pushing)
#   frontend → npm run check   (verify:push runs on pre-push)
git status                     # review what is there before staging
git add <file>...              # stage by name, as in Step 4
git commit                     # conventional commits; the pre-commit hook re-runs the gate
git push                       # push to the submodule's remote (per the detected mode)
cd ..