LLeMbas CLI 1.0.0

The first public release of LLeMbas CLI: a terminal coding agent and project manager for any LLM
API, with permission modes, git snapshots, memory and skills, knowledge bases, MCP, voice, and a
link to a LLeMbas instance whose web UI can work its sessions too. Signed Linux binaries for x64
and arm64.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

harness/prompts/tasks/changelog.md

@@ -0,0 +1,18 @@
+<!-- LLeMbas CLI. Keep a Changelog's own rules, and the tree's: kept as the work happens, entries
+     say what changed for someone using the project, old entries are never rewritten. -->
+Bring CHANGELOG.md's `## [Unreleased]` section up to date with the commits below, which are not in any release yet.
+
+- Read CHANGELOG.md first. Keep its format, headings and voice exactly. If it has no Unreleased section, add `## [Unreleased]` above the newest release; if there is no CHANGELOG.md, create one in the Keep a Changelog format.
+- Group entries under `### Added`, `### Changed`, `### Fixed`, `### Removed`, `### Security` — only the headings you need.
+- One entry per change a user of the project would notice, in words they would use: what changed and, when it is not obvious, why. Not one entry per commit; not file names; no commit hashes.
+- Leave out what nobody outside the code would notice (refactors, tests, formatting) unless it changes behaviour.
+- Do not touch any released section below Unreleased. Do not add entries that are already there.
+- Change only CHANGELOG.md, then say in two or three lines what you added.
+
+{{scope}}
+
+Commits:
+{{log}}
+
+Files changed:
+{{stat}}

harness/prompts/tasks/compact.md

@@ -0,0 +1,28 @@
+<!-- Source: LLeMbas prompts task.compact (© Jaroslav Beneš, relicensed MIT), plus "Files touched"
+     for coding work. -->
+Summarise the conversation below so it can be carried forward after the earlier turns are dropped from your context. This is a working record, not a report for a reader.
+
+Keep, under these headings and in this order:
+
+## What we are doing
+The goal, and where we have got to.
+
+## Decisions
+Anything settled, and why. A decision without its reason gets argued again.
+
+## Facts established
+Names, numbers, versions, file paths, commands, URLs and identifiers, copied exactly. Do not round them, paraphrase them or reconstruct one from memory — if it is not in the transcript, leave it out.
+
+## Files touched
+Each file read or changed that still matters, and what was done to it.
+
+## Open threads
+What is unfinished, and what was about to happen next.
+
+Leave out pleasantries, retracted ideas and anything already superseded. Do not answer the conversation: you are recording it. Write in the language of the conversation, and stay under 600 words.
+
+{{previous_summary}}
+
+## Transcript
+
+{{transcript}}

harness/prompts/tasks/continue.md

@@ -0,0 +1,3 @@
+<!-- The CLI's /continue (ctrl+g); LLeMbas's Continue button and /continue.
+     Sent as the person's own turn: carry on after a stop, or after an answer that ended too soon. -->
+Continue from where you stopped. If you were interrupted, pick up exactly there — finish what you were writing or doing; do not start over or repeat what is already done.

harness/prompts/tasks/init.md

@@ -0,0 +1,18 @@
+<!-- Source: OpenCode command/template/initialize.txt (MIT, © 2025 opencode), shortened, and made to
+     ask about git the way blocks/agents-missing.md does (LLeMbas CLI's /init). -->
+Create or update `AGENTS.md` at the project root, {{root}}/AGENTS.md: the file every later session here starts from. Every line should answer "would an agent likely get this wrong without being told?" — if not, leave it out.
+
+{{focus}}
+
+Investigate first, highest value first: README, the manifests and lockfiles, build, test, lint and type-check configuration, CI workflows, and any instruction files already there (AGENTS.md, CLAUDE.md, .cursorrules, .github/copilot-instructions.md). Read a few representative source files only if the structure is still unclear. Where the documentation and the scripts disagree, trust the scripts.
+
+Write down what is hard-earned:
+- the exact commands to build, run and test — and how to run one test;
+- the order checks must run in, where it matters;
+- where the real entry points are, and what the main directories are for;
+- generated code, migrations, special environments, anything that is not the default for the language;
+- conventions this project keeps that differ from the usual ones.
+
+Leave out generic advice, long file trees, and anything you could not verify. Short sections and bullets; a simple project gets a short file.
+
+If the file is already there, improve it in place: keep what is still true, remove what is stale. If it says nothing about how git is used here, ask the user once, with ask_user, and write their answer under a "## Git" heading. Ask nothing the repository already answers.

harness/prompts/tasks/review.md

@@ -0,0 +1,17 @@
+<!-- Source: OpenCode session/prompt/gpt.txt, "If the user asks for a review" (MIT, © 2025 opencode),
+     made into a brief. -->
+Review the change below with a code-review mindset. Your job is to find what is wrong, not to summarise what was done.
+
+- Findings first, ordered by severity: bugs, then risks and behavioural regressions, then missing tests. For each: file:line, what is wrong, and a concrete way it fails.
+- Read the code around the change where you need it — the diff alone is not the whole story.
+- Then any open questions or assumptions.
+- Only after that, and briefly, what the change does.
+- If you find nothing, say so plainly, and name any residual risk or gap in testing.
+
+You are reviewing, not fixing: change nothing.
+
+{{scope}}
+
+```diff
+{{diff}}
+```