You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge branch 'dev' into feature/acp-sacp-tee-tracing
Resolved conflicts by preserving both feature sets:
- ACP traffic tracing (current branch via sacp-tee proxy)
- Message history persistence (dev branch)
Changes:
- Added both trace_config and nori_home/history_persistence fields to AcpBackendConfig
- Added both acp_trace_enabled and history_persistence to config types
- Preserved enhanced error handling from dev in connection spawning
- Added environment variable support (.envs) to subprocess spawning
- Merged documentation for both features in tui/docs.md
Both features are independent and now work together:
- Trace config enables debugging of ACP JSON-RPC traffic
- History persistence enables message history storage and navigation
🤖 Generated with [Nori](https://nori.ai)
Co-Authored-By: Nori <contact@tilework.tech>
Description: Use when design is complete and you need detailed implementation tasks for engineers with zero codebase context - creates comprehensive implementation plans with exact file paths, complete code examples, and verification steps assuming engineer has minimal domain knowledge
Description: Use when writing or changing tests, adding mocks, or tempted to add test-only methods to production code - prevents testing mock behavior, production pollution with test-only methods, and mocking without understanding dependencies
Description: Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
Description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes - four-phase framework (root cause investigation, pattern analysis, hypothesis testing, implementation) that ensures understanding before attempting solutions
Description: Use when implementing any feature or bugfix, before writing implementation code - write the test first, watch it fail, write minimal code to pass; ensures tests actually verify behavior by requiring failure first
Description: Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior
Description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Description: Use this skill to split large plans into smaller chunks. This skill manages your context window for large tasks. Use it when a task will take a long time and cause context issues.
Description: Use when you need to create a new custom skill for a profile - guides through gathering requirements, creating directory structure, writing SKILL.md, and optionally adding bundled scripts
Description: Use this skill when faced with a difficult debugging task where you need to replicate some bug or behavior in order to see what is going wrong.
Description: Use when implementing user interfaces or user experiences - guides through exploration of design variations, frontend setup, iteration, and proper integration
Description: IMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
Copy file name to clipboardExpand all lines: .claude/skills/test-driven-development/SKILL.md
-1Lines changed: 0 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,6 @@ Place marker on the line immediately before the test function/block definition.<
18
18
<system-reminder>If you have more than one test that you need to write, you should write all of them before moving to the GREEN phase.</system-reminder>
19
19
3. Write the minimal amount of code necessary to make the test pass (GREEN phase)
20
20
4. Verify the test now passes due to the behavior of the application.
21
-
- If you go through three loops without making progress, switch to running `/home/clifford/Documents/source/nori/cli/skills/creating-debug-tests-and-iterating`
Copy file name to clipboardExpand all lines: .claude/skills/writing-plans/SKILL.md
+9-4Lines changed: 9 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,20 +13,18 @@ description: Use when design is complete and you need detailed implementation ta
13
13
- Think about questions or areas that require clarity. Add them to the plan.
14
14
- Emphasize how you will test your plan.
15
15
- Present plan to user.
16
-
</required>
16
+
</required>
17
17
18
18
# Guidelines
19
19
20
20
## Overview
21
21
22
-
Create a comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD.
22
+
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD.
23
23
24
24
Assume they are a talented developer. However, assume that they know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
25
25
26
26
Do not add code, but include enough detail that the necessary code is obvious.
27
27
28
-
Do not write a file to disk unless explicitly asked.
29
-
30
28
## Bite-Sized Task Granularity
31
29
32
30
**Each step is one action (2-5 minutes):**
@@ -91,3 +89,10 @@ types. Your tests should NOT simply test mocks. Always test actual behavior.</sy
91
89
92
90
---
93
91
```
92
+
93
+
## Remember
94
+
95
+
- Exact file paths always, taking into account worktrees
Copy file name to clipboardExpand all lines: README.md
+7-5Lines changed: 7 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,8 +6,7 @@
6
6
7
7
**One CLI, multiple AI providers.** Nori is a local AI coding agent that lets you switch between Claude, Gemini, and Codex. All from the same native CLI.
@@ -23,23 +22,24 @@ Or download binaries from [GitHub Releases](https://github.com/tilework-tech/nor
23
22
nori
24
23
```
25
24
26
-
That's it. Nori launches an interactive TUI where you can chat, run commands, and let the AI assist with your codebase.
25
+
That's it. The agent you choose will rely on existing auth if you have previously been using Claude Code, Codex, or Gemini on this system (and if not, login instructions are below). Nori launches an interactive TUI where you can chat, run commands, and let the AI assist with your codebase.
27
26
28
27
## Providers
29
28
30
29
Each provider you plan to use needs to be authenticated separately before use. Switch between AI providers with the `/agent` command:
31
30
32
31
| Provider | Command | Authentication |
33
32
|----------|---------|----------------|
34
-
| Claude |`npm i -g @zed-industries/claude-code-acp` (default) |`npx @anthropic-ai/claude-code setup-token`|
33
+
| Claude |`npm i -g @zed-industries/claude-code-acp` (default) |`npx @anthropic-ai/claude-code` and then follow the login flow|
35
34
| Gemini |`npm i -g @google/gemini-cli --experimental-acp`|`npx @google/gemini-cli` and then `/auth`|
36
35
| OpenAI |`npm i -g @zed-industries/codex-acp`|`npx @openai/codex login`|
37
36
38
37
## Features
39
38
40
39
-**Multi-provider**: Anthropic's Claude Code, Google DeepMind's Gemini, and OpenAI's Codex
41
-
-**Sandboxed execution**: Commands run in OS-level security sandboxes
40
+
-**Improved terminal interface**: Fast incremental renders in Ratatui, double buffered scrollback history, and built in Rust for performance
42
41
-**Coming Soon!**
42
+
-**Sandboxed execution**: Commands run in OS-level security sandboxes
43
43
-**MCP integration**: Connect to Model Context Protocol servers for extended tools
44
44
-**Session persistence**: Save and resume conversations with `nori resume`
45
45
-**Multi-agent orchestration**: Alternate between multiple agent sessions
@@ -48,6 +48,8 @@ Each provider you plan to use needs to be authenticated separately before use. S
48
48
49
49
Nori CLI is built on the great work within [OpenAI Codex CLI](https://github.com/openai/codex).
50
50
51
+
Nori CLI is working with the great protocol led by [Zed Industries](https://github.com/agentclientprotocol/agent-client-protocol) for orchestrating agents.
0 commit comments