{"id":52070723,"url":"https://github.com/zillionare/louke","last_synced_at":"2026-08-03T09:01:09.978Z","repository":{"id":359735579,"uuid":"1247219415","full_name":"zillionare/louke","owner":"zillionare","description":"Beyond vibes, into louke (craft)","archived":false,"fork":false,"pushed_at":"2026-07-21T10:19:57.000Z","size":4836,"stargazers_count":6,"open_issues_count":138,"forks_count":1,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-07-21T12:10:26.099Z","etag":null,"topics":["agentic-coding","agentic-workflow","ai","development","engineering","spec","spec-driven-development","subagent-driven-development","tdd"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/zillionare.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-05-23T03:23:41.000Z","updated_at":"2026-07-16T08:16:07.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/zillionare/louke","commit_stats":null,"previous_names":["zillionare/specforge","zillionare/holdpoint"],"tags_count":30,"template":false,"template_full_name":null,"purl":"pkg:github/zillionare/louke","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zillionare%2Flouke","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zillionare%2Flouke/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zillionare%2Flouke/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zillionare%2Flouke/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/zillionare","download_url":"https://codeload.github.com/zillionare/louke/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zillionare%2Flouke/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":36228519,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-07-20T02:08:10.276Z","status":"online","status_checked_at":"2026-08-03T02:00:06.975Z","response_time":56,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agentic-coding","agentic-workflow","ai","development","engineering","spec","spec-driven-development","subagent-driven-development","tdd"],"created_at":"2026-08-03T09:01:08.817Z","updated_at":"2026-08-03T09:01:09.964Z","avatar_url":"https://github.com/zillionare.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Lòukè - beyond vibes, into Lòukè(craft)\n\n![Lòukè pipeline](docs/hero.png)\n\n[🇨🇳 中文](README.zh.md) · [🇺🇸 English](README.md)\n\n**Lòukè is a spec-first, test-driven, tool-aligned multi-agent collaborative development method.**\n\n**louke has not yet reached a level suitable for official release. Please refrain from installing and using it in your projects for now. It is expected to become fully functional within two weeks.**\n\n---\n\n## 1. Why Lòukè?\n\nYou can't build real software with a one-line vibe-coding prompt. When vibecoding:\n\n- You haven't figured out what you want, yet you expect the agent to know\n- Words are suggestive and leave too much room for imagination, but software must be precise\n- You tell many Stories, but neither the AI nor you has formed a complete blueprint\n\nReal software has hundreds to thousands of sub-requirements and tens of thousands of execution paths and boundary conditions.\n\nWe must rely on concrete, detailed specs, acceptance criteria, and test plans. Humans must participate in and guide the production of these documents; tools must break them into traceable sub-items so agent code maps one-to-one to those items. Only then can we build a retractable, traceable, trustworthy software production process.\n\nThat is the value of Lòukè. Beyond vibecoding — agent programming becomes precision manufacturing, executing every detail you specified perfectly.\n\nEven spec-kit / superpowers / oh-my-openagent don't turn spec into a \"programming contract.\" For spec to be a contract, three things must hold simultaneously:\n\n- **Sub-requirements are orthogonal** — non-conflicting and non-overlapping, already pruned by Occam's razor.\n- **Right-sized granularity** — an agent cannot read a 10,000-word document and still grasp every small detail, unless you break items into tasks that fit cleanly into a PR.\n- **Traceable** — every thread from requirement to code to test must be bidirectionally traceable: forward to find the source, backward to find the landing. Any requirement without matching code and tests is a blank check hanging on the wall.\n\nAnd Lòukè differs from these frameworks in philosophy: Lòukè turns this into **Infrastructure-as-Checkpoint** — the traceable loop is not in the AI's self-discipline, but in the forced execution of external CLIs at commit-time. `exit 0/1` is an OS process return value; you can't bypass it. The engineering world only recognizes this one language.\n\nProgrammers make mistakes — that's why we have tests. Agents make mistakes too. Don't rely on AI self-discipline; rely on rigorously aligned specs and tools.\n\n## 2. How Does Lòukè Achieve This?\n\nLòukè turns the contract's three principles into five observable things. Each maps to an `lk` command or a traceable artifact — not just prompts, but tools:\n\n- **spec → GitHub issue, commits must reference issue** — Lex converts each FR into an issue; Devon's commit message enforces `#NNN` format. Requirement to code, one-way trace, never lost\n\n- **test ↔ AC-FRXXXX-YY auto-association, CI static validation closes both directions** — every test docstring must carry an `AC-FRXXXX-YY` ID. `lk agent archer ci-scan` validates at commit-time: every AC must be referenced by a test, every test must reference an AC. If the loop doesn't close, merge is blocked\n\n- **Anti-pattern CI gate + identity consistency check** — `lk agent keeper gate` statically scans 8 anti-patterns (`assert True` / `try/except: pass` / no-issue skip / mock framework core / ...). `lk agent scout identity-check` locks gh/git identity consistency before workflow start. Violations block\n\n- **Project wiki auto-distillation** — based on LLM compounding engineering, `.louke/raw/` (each agent's session records) → `.louke/wiki/` (structured knowledge). Facts, decisions, current state at a glance, lint-checkable\n\n- **Socratic requirement interrogation** — Sage asks multiple rounds of questions around a vague story until it produces traceable `spec.md` + `acceptance.md`\n\nLòukè defines 12 specialized agents, a 10-stage pipeline, and an `lk` CLI — so every transition is a real check, not the soft \"agents review each other.\" Each agent has its own dedicated toolbox; at every hold point, work is gated for verification.\n\n## 3. Lòukè vs Others\n\n| Framework                                 | Is spec a contract?                                                          | Who reviews                                                                   | Enforcement layer                           | spec → code → test loop                                     |\n| ----------------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------- | ----------------------------------------------------------- |\n| **spec-kit** (GitHub)                     | spec.md is the source, but no MECE / granularity / traceability constraints | No review                                                                     | None                                        | Manual + social                                             |\n| **superpowers** (obra, 240k★)             | plan.md is plain text, no AC numbering, no commit-time validation            | subagent review (same model reviewing itself)                                 | prompt-level self-discipline               | TDD indirect guarantee (no ID binding between test and spec) |\n| **oh-my-openagent** (code-yeongyu, 64k★)  | agents digest spec themselves                                                | team of agents (same LLM, different prompts)                                  | hooks / middleware                          | task self-defined, no FR ↔ test binding                      |\n| **Lòukè**                                 | FR-XXXX / AC-FRXXXX-YY + `lk agent archer ci-scan`                                  | 12 different personas (implementer ≠ reviewer, cross-stage context disjoint)  | `lk` CLI exit 0/1 (OS process return value) | FR ↔ issue ↔ commit ↔ AC ↔ test end-to-end                   |\n\n## 4. Architecture\n\n![](docs/arch.png)\n\n- **12 Agents** = implementer ≠ reviewer; cross-stage context is disjoint\n- **`lk` CLI** = OS-process-level contract; `exit 0/1` is unbypassable\n- **Two-tier memory** = `raw/` (episodic) + `wiki/` (distilled), maintained by Librarian\n- **Promise** = spec → code → test three-segment bidirectional reachability; breakage at any node can be traced to its source\n\n## 5. Pipeline\n\n| Stage        | Implementer     | Reviewer              | Notes                                                     |\n| ------------ | --------------- | --------------------- | --------------------------------------------------------- |\n| M-FOUND      | Scout           | Warden                | Project setup + permission gate                           |\n| M-SPEC       | Sage            | Lex                   | spec + FR → issue                                         | Lex reviews + 100% verifies |\n| M-TESTPLAN   | Archer          | Sage                  | Test plan (Sage has unique spec context)                  |\n| M-ARCH       | Archer          | Prism                 | Architecture + interfaces                                 |\n| M-LOCK       | Maestro         | User                  | 3-signal lock                                             |\n| M-DEV        | Devon           | **Prism → Keeper ★**  | Code + unit tests                                         |\n| M-E2E        | Shield          | **Prism → Keeper ★**  | e2e tests                                                 |\n| M-BUGFIX     | Devon           | **Keeper ★**          | Bug fixes                                                 |\n| M-SECURITY   | Judge (S-level) | User                  | Deep security audit                                       |\n| M-MILESTONE  | Librarian       | Maestro               | raw → wiki distillation                                   |\n\n★ **HOLD POINT** — tool-enforced check (`lk` CLI returns 0/1; pipeline doesn't advance until it passes). `★` only marks the PROD gate that blocks merge at commit-time; stage-transition hold points are not separately marked.\n\n**Principle: implementer ≠ reviewer. Always.**\n\n### 5.1 M-SPEC Internal: Sage ↔ Lex Three-Phase Interaction\n\nM-SPEC is **not** \"Sage produces spec → Lex reviews once at the end.\" Lex runs three phases at three distinct trigger points. Maestro must actively trigger Phase 1 and Phase 3 (Phase 2 is handed off by Sage Step 6, but still routed through Maestro). Skipping any phase makes the M-LOCK Lex signal invalid.\n\n```mermaid\nsequenceDiagram\n    participant U as User\n    participant M as Maestro\n    participant S as Sage\n    participant L as Lex\n\n    U-\u003e\u003eM: Story (\"add user auth\")\n    M-\u003e\u003eS: M-SPEC start\n    S-\u003e\u003eU: Step 1: ≤7 questions in chat\n    S-\u003e\u003eS: Step 2: draft spec.md + acceptance.md\n    S-\u003e\u003eU: Step 3: inline quote clarification (≤5 rounds)\n    S-\u003e\u003eS: Step 4: add HTML anchors\n    S-\u003e\u003eS: Step 5: create GitHub issues + link Project\n    Note over M: Maestro triggers Lex Phase 1\n    M-\u003e\u003eL: verify-acceptance (L1-L5) + quote-check\n    L--\u003e\u003eM: [pass] / [reject]\n    alt Phase 1 rejected\n        M-\u003e\u003eS: fix spec.md (forward tool stderr)\n        S-\u003e\u003eS: fix\n        M-\u003e\u003eL: re-run Phase 1\n    end\n    S-\u003e\u003eS: Step 6: quote-check exit 0 → handoff\n    Note over S: Sage Step 6 notifies Lex Phase 2 (via Maestro)\n    M-\u003e\u003eL: issue coverage + Project link check\n    L--\u003e\u003eM: [pass] / [reject]\n    alt Phase 2 rejected\n        M-\u003e\u003eS: create/link missing issues\n        S-\u003e\u003eS: fix\n        M-\u003e\u003eL: re-run Phase 2\n    end\n    Note over M: Maestro triggers Lex Phase 3\n    M-\u003e\u003eL: verify-issue (L1-L8 schema)\n    L--\u003e\u003eM: [pass] / [reject]\n    alt Phase 3 rejected\n        M-\u003e\u003eS: fix issue schema fields\n        S-\u003e\u003eS: fix\n        M-\u003e\u003eL: re-run Phase 3\n    end\n    Note over M: 3 signals: Sage quote-check ✓ + Lex 3 phases ✓\n    M-\u003e\u003eU: M-LOCK: confirm spec lock\n    U--\u003e\u003eM: confirmed\n    M-\u003e\u003eM: advance to M-TESTPLAN\n```\n\n**Key rules**:\n- Phase 1 failure → fix spec only; Phase 2 failure → fix issues only; Phase 3 failure → fix issue schema fields only\n- If a fix reveals an upstream root cause → regress to M-SPEC and re-run from Phase 1\n- Maestro forwards tool raw output (stderr/stdout) to Sage on rejection — never paraphrases\n\n## 6. The 12 Agents\n\nEach agent has a default primary model (with an in-tier fallback). Override via `~/.louke/models.json` (user-level) or `.louke/models.json` (project-level); use `lk models list` / `lk models doctor` to check current bindings, `lk models bind \u003cabstract\u003e \u003cfull\u003e` to override.\n\n### 6.1 Agent Permissions (v0.6-009)\n\n5 agents have explicit `permission:` blocks (YAML object, 11-13 keys) constraining their tool access. The other 7 also have explicit blocks (11 keys each) — all 12 agents declare their permissions explicitly. **All 11 subagents have `task: deny`** to enforce \"Maestro is the sole orchestrator\" design.\n\n| Agent | Mode | `question` | `edit` | Notes |\n|---|---|---|---|---|\n| **Maestro** | `primary` | ❌ | ✅ | Conductor; `task: allow` to dispatch subagents; `external_directory: ask`; 13 keys |\n| **Warden** | `subagent` | ❌ | ❌ | Read-only auditor; 11 keys |\n| **Judge** | `subagent` | ✅ | ❌ | Read-only security auditor; 11 keys; can ask user clarifying questions |\n| **Archer** | `subagent` | ✅ | ✅ | Writes spec artifacts; 11 keys; path restriction via prompt |\n| **Librarian** | `subagent` | ❌ | ✅ | Writes wiki; 11 keys; path restriction via prompt |\n| **Sage** | `subagent` | ✅ | (default) | Interactive spec clarification |\n| **Scout** | `subagent` | ✅ | (default) | Interactive project foundation |\n| Lex / Devon / Shield / Keeper / Prism / Warden / Librarian | `subagent` | ❌ | `task: deny`, `question: deny` | Non-interactive; explicit permission block |\n\n\u003e Run `lk agent lint` to verify all agent frontmatter conforms.\n\n### 6.2 Layered Orchestration (v0.6-009)\n\n**Maestro is the only `mode: primary` agent.** The other 11 agents are `mode: subagent` — they do not appear in OpenCode's `\u003cLeader\u003ea` list and cannot be selected as primary. Maestro orchestrates them via the `task` tool.\n\n- Users see **only** Maestro in `\u003cLeader\u003ea`\n- Maestro dispatches work to subagents in isolated child sessions\n- Subagent `question` calls bubble to the **main window** (verified 2026-07-03)\n- Users never need to press `\u003cLeader\u003ea` to switch primary agents\n- After a subagent completes, focus auto-returns to Maestro\n- For viewing a subagent's context, press `\u003cLeader\u003e+Down` to enter / `\u003cLeader\u003e+Up` to return\n\n### 6.3 The 12 Agents (reference)\n\n| Agent          | Role                                             | Tier    | Open-source example  | Closed-source example (reference)           |\n| -------------- | ------------------------------------------------ | :-----: | -------------------- | ------------------------------------------- |\n| **Maestro**    | Conductor — orchestrates the pipeline            | A       | `minimax-m3`         | `gpt-5.6`, `fable`                         |\n| **Sage**       | The wise — Socratic requirement interrogation   | A       | `glm-5.2`            | `gpt-5.6`, `fable`                         |\n| **Judge**      | Arbiter — S-level deep security audit           | S       | `minimax-m3`         | `gpt-5.6`, `fable`                         |\n| **Archer**     | Marksman/architect — test-plan + architecture   | S/A     | `glm-5.2`            | `gpt-5.6`, `fable`                         |\n| **Devon**      | Smith — R-G-R coding                            | A       | `kimi-2.7-code`      | `opus-4.8`, `gpt-5.5`                      |\n| **Prism**      | Prism — multi-angle code review (anti-pattern + security) | A | `deepseek-v4-pro` | `opus-4.8`, `gpt-5.5`                   |\n| **Shield**     | Shield — writes e2e test scripts                | A       | `kimi-2.6`           | `opus-4.8`, `gpt-5.5`                      |\n| **Lex**        | The law — spec-level structural validation      | B       | `deepseek-v4-flash`  | `gpt-5.4-mini`, `gpt-5.4`, `sonnet-4.6`    |\n| **Warden**     | Gatekeeper — guards exit conditions             | B       | `glm-5`              | `gpt-5.4-mini`, `gpt-5.4`, `sonnet-4.6`    |\n| **Keeper**     | Warden of gates — enforces quality gates        | B       | `minimax-2.7`        | `gpt-5.4-mini`, `gpt-5.4`, `sonnet-4.6`    |\n| **Scout**      | Pathfinder — scouts preconditions               | B       | `glm-5`              | `gpt-5.4-mini`, `gpt-5.4`, `sonnet-4.6`    |\n| **Librarian**  | Librarian — distills Wiki, preserves memory     | B       | `minimax-2.7`        | `gpt-5.4-mini`, `gpt-5.4`, `sonnet-4.6`    |\n\n## 7. Usage Guide\n### 7.1. Install\n\n\u003e **Platform**: macOS / Linux. Windows users: please use [WSL2](https://learn.microsoft.com/en-us/windows/wsl/) or Docker. `install.sh` self-checks `uname -s` and exits with a clear error on unsupported platforms.\n\n```bash\n# Standard pip-based install (recommended): auto-creates venv, sets PATH, links lk to ~/.local/bin\ncurl -sSL https://raw.githubusercontent.com/zillionare/louke/main/install.sh | bash\n\n# Or pin a version\ncurl -sSL https://raw.githubusercontent.com/zillionare/louke/main/install.sh | bash -s -- v0.3.0\n\n# Or dev mode (clone + editable install)\ngit clone https://github.com/zillionare/louke\ncd louke\n./install.sh --editable\n\n# Verify\nlk --help\n```\n\n`install.sh` does four things:\n\n1. Creates an isolated venv at `~/.louke/venv/` (no system-Python pollution)\n2. `pip install louke` into that venv\n3. `~/.local/bin/lk` → symlink to venv's `lk`, and appends PATH to your shell rc\n4. Verifies the install + prints uninstall instructions\n\nUninstall: `rm -rf ~/.louke/venv ~/.local/bin/lk`\n\n### 7.2. 30-Second Start\n\n```bash\n# New project (creates \u003cname\u003e/ dir with .louke/ skeleton + OpenCode agents + issue template + CI workflow)\nlk init my-project\ncd my-project\n\n# Adopt existing git repo (non-destructive, adds .louke/ alongside your code)\ncd ~/work/my-existing-repo \u0026\u0026 lk init .\n```\n\n`lk init` does:\n\n1. Scaffolds the project layout (`.louke/{templates,project,project/specs,wiki/pages,wiki/decisions,raw}/`)\n2. Copies louke's bundled templates (spec / acceptance / prd / bug-fix / …) into `.louke/templates/`\n3. Installs `.github/ISSUE_TEMPLATE/feature.yml` (4-digit FR schema) + `.github/ISSUE_TEMPLATE/bug.yml`\n4. Writes `default_agent: maestro` to project-level `opencode.json`\n5. Generates `.opencode/agents/*.md` from the louke package's installed agent prompts (each agent with its resolved `model:` field). Re-run with `lk board opencode` any time you upgrade louke.\n6. Optionally installs the daily wiki-distillation cron (`--no-cron` to skip)\n\n\u003e **Agents are package-owned.** The 12 agent prompts live inside the installed `louke` Python package — there is intentionally no project-side copy you can (or should) edit. `lk board opencode` materialises them into `.opencode/agents/` so OpenCode can consume them. Past attempts to let projects override agents were removed because they caused stale-format drift.\n\nThen start OpenCode — the default primary agent is **Maestro**. Just tell it what you want in chat, for example:\n\n\u003e \"We want to add user authentication — username/password login, plus Google login.\"\n\nFrom here on, Maestro orchestrates the entire pipeline. You don't need to switch agents manually; Sage's follow-up questions and Judge's security findings all flow back to you through Maestro.\n\n### 7.3. What a Full Session Looks Like\n\nUsing \"add user authentication\" as an example, the timeline unfolds linearly:\n\n1. **M-FOUND** — `lk agent scout foundation` creates repo, GitHub Project, Test Issue to verify permissions\n2. **M-SPEC** — Sage asks follow-ups in chat (MFA? session timeout? rate limiting?); Lex finds 3 structural issues; Sage fixes them. Locked when **3 signals align**: `lk agent sage quote-check` exit 0 + Lex 3 stages pass + your IDE confirmation\n3. **M-TESTPLAN** — Archer writes `test-plan.md` (3-layer strategy + AC traceability + anti-pattern rules); Sage reviews (holds M-SPEC's unique context)\n4. **M-ARCH** — Archer writes `architecture.md` + `interfaces.md`; Prism checks spec/code consistency\n5. **M-LOCK** — Spec locked. Implementation begins\n6. **M-DEV** — Devon codes R-G-R. Each commit prefixed `test: red` / `feat: green` / `refactor`. Prism reviews (anti-patterns + security quick scan); `lk agent keeper gate` checks commit format + tests\n7. **M-E2E** — Shield writes e2e (B-level, fixed methods: Playwright/testclient/DB); same Prism + Keeper\n8. **M-SECURITY** — `lk agent judge security-audit` does pattern scan + S-level semantic review. **You** make the final call\n9. **M-MILESTONE** — `lk agent librarian distill` distills the session to wiki; `lk agent maestro advance --stage M-MILESTONE` closes the milestone\n\nEach step is a different agent; each hold point is tool-enforced; each handoff is an explicit trace.\n\nThe above flow is automatically orchestrated by Maestro — you just tell Maestro in OpenCode \"do user authentication,\" and it will sequentially invoke Scout/Sage/Lex/Archer/Devon/Shield/Judge/Librarian. Below is what you see (through your conversation with Maestro) at each step.\n\n### 7.4. Configuring Agent Models\n\nNew models are released every month. You may need to dynamically adjust agent models. Each agent has a default model; switching coding agents to local small models in day-to-day development saves most of the tokens.\n\n```bash\n# View current bindings\nlk models list\nlk models doctor            # Check for missing/failed resolutions\n\n# Temporarily switch an agent to a cheaper model\nlk models bind devon kimi-2.7-code\nlk models unbind devon       # Restore default\n```\n\n`models.json` priority: **project-level** (`.louke/models.json`) \u003e **user-level** (`~/.louke/models.json`).\n\n### 7.5. Sage's Requirement Discussion — Back to Inline Email!\n\nAfter receiving the Story, Sage immediately starts a round of requirement clarification in the chat window, but will ask fewer than 7 questions. Deeper questions are better clarified outside of chat. Lòukè brings back the inline comment style from email.\n\nWe use Markdown quote blocks to start the discussion:\n\n````markdown\n### FR-0100 Draw a circle\n\n| Valid | Testable | Decided |\n| ----- | -------- | ------- |\n| ✅     | ✅        | ⚠️       |\n\nYou shall draw a circle with a radius of 0.5m.\n\n\u003e Sage: How should the pen color and stroke width be determined?\n````\n\nSage thinks this requirement is not clear enough to verify. So he asks: how should the pen color and stroke width be determined?\n\nYou reply with **one more level of `\u003e`** indentation:\n\n````markdown\n\u003e Sage: How should the pen color and stroke width be determined?\n\u003e\u003e Aaron: Provide a toolbar and let the user choose\n\u003e\u003e\u003e Sage: Requirement confirmed.\n````\n\nThis is standard email threading syntax. If you think the spec wording is wrong and doesn't need discussion, you can directly edit the spec; Sage will find your changes through git diff, and if there are any questions, will open a session.\n\n### 7.6. GitHub Projects: Managing Releases\n\nLòukè uses GitHub Projects to manage releases. A release starts with a Story. Sage breaks down the requirements, creates GitHub issues, and automatically links them to the GitHub Project. Release Notes naturally derive from this project.\n\nWe also throw in a small gift — by creating a project named `{repo}-backlog`, we give you an idea collection box. If you have an inspiration that can't fit into the current release, you'll find this project surprisingly useful. Future releases start their planning from here.\n\n`lk agent scout foundation` creates two Projects per repo:\n\n- **`{repo}-{version}`** — per-release, tracks the current milestone's issues\n- **`{repo}-backlog`** — per-repo (permanent), holds unscheduled ideas\n\nIssues created with `gh issue create --no-milestone` naturally land in the backlog; during planning, pull backlog issues into the current release with `gh project item-add`.\n\n### 7.7. pre-commit Quality Gate\n\nLint, format, typecheck, and tests run automatically at commit time via the project's `.pre-commit-config.yaml` — no tokens spent, no manual invocation. Bypassing hooks with `--no-verify` is an anti-pattern because it breaks the Infrastructure-as-Checkpoint contract. See `louke/templates/pre-commit/README.md` for the bundled templates.\n\n## 8. Quick Command Reference\n\n### 8.1. Project Initialization\nlk init my-project                         # New project\nlk init .                                  # Adopt existing repo\nlk agent scout foundation --repo owner/repo --version v0.1 --spec-id v0.1-001-init\nlk agent scout identity-check --repo owner/repo\nlk agent scout invite-owner owner/repo --version v0.1\n\n### 8.2. Pipeline Advancement\nlk agent maestro status                          # View current stage\nlk agent maestro advance --stage M-DEV           # Advance to next stage\nlk agent maestro regress --stage M-SPEC --reason \"spec missing NFR\"\nlk agent maestro escalate --reason \"user unresponsive for 3 rounds\"\n\n### 8.3. Code Quality\nlk agent archer ci-scan --spec ID                # AC traceability validation\nlk agent keeper gate                             # commit format + R-G-R order + anti-pattern scan\nlk agent judge security-audit --release releases/v0.1\n\n### 8.4. Model Management\nlk models list                             # View agent→model bindings\nlk models doctor                           # Diagnose missing/failed resolutions\nlk models bind devon kimi-2.7-code         # Temporary override\nlk models unbind devon\n\n### 8.5. Wiki\nlk agent librarian lint                          # Health check\nlk agent librarian distill                       # Distill raw sessions to wiki pages\n\n## 9. Troubleshooting\n\n**`lk: command not found`** — `~/.local/bin` is not in PATH. Add `export PATH=$HOME/.local/bin:$PATH` to your shell rc and `source` it (or restart your terminal).\n\n**`lk agent scout foundation` fails with `gh not authenticated`** — Run `gh auth login` first, then `lk agent scout identity-check` to verify.\n\n**Sage keeps asking about the same requirement** — Possible causes:\n- Your reply didn't use an extra level of `\u003e` indentation, so Sage didn't recognize it as a new reply\n- You directly edited the text — Sage will discover the change through git diff and ask for confirmation. Reply with \"✓ resolved\" on the changed section\n\n**Commit blocked by `lk agent keeper gate`** — The terminal prints which anti-pattern was hit. Common causes:\n\n- Commit message doesn't follow R-G-R prefix conventions (e.g., wrote `feat: add login` instead of `feat: green add login`)\n- `feat: green` appears before `test: red` (R-G-R order violation)\n- Test docstring missing `AC-FRXXXX-YY`\n- Wrote `assert True` / `try/except: pass` / mocked framework core\n\n**OpenCode doesn't show the 12 agents after launch** — Check the `.opencode/agents/` directory and `opencode.json`'s `default_agent` field; rerun `lk init --force` if needed.\n\n**Wondering \"where are we now\"** — `lk agent maestro status` tells you in one line.\n\n## 10. Future Enhancements (Not in v0.6-008 Scope)\n\n- **[#78](https://github.com/zillionare/louke/issues/78)** — `.louke/project` as a standalone private GitHub repo (via git submodule), separating spec/wiki from public code\n- **[#79](https://github.com/zillionare/louke/issues/79)** — `louke serve` web UI for browsing/editing wiki / spec / acceptance / test-plan\n\n## 11. License\n\nMIT\n\n## 12. Release History\n\nLouke releases follow [Semantic Versioning](https://semver.org/). The CLI (`lk`) self-updates via `pip install --upgrade louke`; project-local state (`.louke/`, `~/.louke/models.json`) is preserved across upgrades. Agent prompts come from the installed package, so upgrading louke automatically ships any agent-prompt changes — re-run `lk board opencode` to refresh `.opencode/agents/`.\n\n### v0.6.0 — v0.6.13 (2026-07-04)\n\n| Version | Highlights |\n|---|---|\n| **v0.6.13** | `lk models doctor` critical bugfix: `ok` variable shadowed imported `ok` function (same pattern as v0.6.8 fix in `set-model`, but missed in `doctor`). Crash on any aliased model. Regression test added. |\n| v0.6.12 | Cleanup: removed internal spec references (`(v0.6-008 FR-0710)`, `(FR-0070)`, etc.) from 6 agent prompts shipped to users. |\n| v0.6.11 | Cleanup: removed redundant `(实测确认 2026-07-03 14:00 by Aaron)` annotations from 4 interactive subagent prompts. |\n| v0.6.10 | Subagent dispatch clarification: `louke/agents/Maestro.md` now explicitly says \"只**用 `task` 工具调子 agent, 不要用 `opencode run`\". Spec FR-0070.7 documents the two invocation modes (production TUI vs CLI test). |\n| v0.6.9 | `lk agent set-model` redesign: writes directly to `.opencode/agents/\u003cname\u003e.md` (output) instead of the package source. **Temporary** — next `lk board opencode` regenerates from the package source. |\n| v0.6.8 | `lk agent set-model` bugfix: `ok` variable shadowed imported `ok` function → `TypeError: 'bool' object is not callable`. |\n| v0.6.7 | `lk agent list-models` — table view of all agents' `models:` chain + current resolved model. `--unbound-only` flag. |\n| v0.6.6 | `lk agent set-model \u003cname\u003e \u003cabstract\u003e` — change an agent's primary model in one command. Interactive bind + probe before save. |\n| v0.6.5 | `lk models bind` probes the selected model via `opencode run --model \u003cm\u003e \"ping\"` before saving. Prompts `[r]etry / [s]kip / [a]ssign-force` on failure. |\n| v0.6.4 | `lk board opencode` requires a git repository (or explicit `--root \u003cpath\u003e`). Prevents accidental file creation in random directories. |\n| v0.6.3 | `lk models bind` ranking: Levenshtein distance over substring matching. Better top-1 candidates for naming-style mismatches (e.g. `kimi-2.6` ↔ `kimi-k2.6`). |\n| v0.6.2 | Progress output for `lk board opencode` and `lk models doctor`: 5-step / 4-step numbered output with ANSI colors (✓/✗/⚠) and Spinner on subprocess calls. |\n| v0.6.1 | Source `louke/agents/*.md` updated to v0.6.0 style (`mode: primary/subagent`, `permission:` block). |\n| v0.6.0 | Agent permission tightening + layered orchestration. 4 roles (Warden / Judge / Archer / Librarian) + Maestro get explicit `permission:` blocks (11-13 keys). 11 agents set to `mode: subagent`; Maestro is the sole `mode: primary`. |\n\n### v0.3.0 (2026-06-29) — Initial public release\n\n12 specialized agents, 10-stage pipeline (M-FOUND → M-MILESTONE), `lk init` / `lk agent scout foundation` / `lk agent archer ci-scan` / `lk agent keeper gate`, OpenSpec-style YAML issue template, 129 bats tests.\n\n---\n\nFor older (pre-v0.6) release notes, see `.github/RELEASE_NOTES_v0.X.md`.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzillionare%2Flouke","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fzillionare%2Flouke","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzillionare%2Flouke/lists"}