icl
AGENTS.md200 starsChanged 3 months agoMITView on GitHub
The build requires SBCL, ocicl, and libfixposix-devel. ICL is a frontend REPL that communicates with a backend Lisp process via the Slynk protocol (from SLY). This client-server architecture allows it to work with multiple Lisp implementations. Commands are defined using define-command in src/commands/core.lisp: Commands can have aliases (like h and ? above) and receive parsed arguments as strings. Platform-specific terminal handling: - src/terminal-posix.lisp - POSIX termios-based raw mode - src/terminal-windows.lisp - Windows console API Third-party code is vendored in: -…
- Commits and pushes
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,774 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository4 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .cursor/rules/beads.mdcCursor rule
- beadsSkill
- make-releaseSkill
The file
Show its rules and text
We split this AGENTS.md into the rules it gives an agent
13 rules. About 0 are common, 4 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 105
Use bd for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists
- Very specific: line 106
Run bd prime for detailed command reference and session close protocol
- Very specific: line 107
Use bd remember for persistent knowledge — do NOT use MEMORY.md files
- Very specific: line 115
Conservative (default): Use bd for task tracking. Do not run git commits, git pushes, or Dolt remote sync unless explicitly asked.
- Very specific: line 116
Minimal: Keep tool instruction files as pointers to bd prime.
- Distinctive: line 117
Team-maintainer: Only when the repository explicitly opts in, agents may close beads, run quality gates, commit, and push as part of …
- Distinctive: line 123
File issues for remaining work: - Create beads for anything that needs follow-up
- Distinctive: line 141
Do not commit or push without clear authority from the active profile or the current user request.
- Distinctive: line 142
If a required sync or push is blocked, stop and report the exact command and error.
- Very specific: line 148
Use Beads (bd) for durable task tracking in repositories that include it.
- Very specific: line 162
Use bd for all task tracking.
- Very specific: line 163
Run bd prime when Beads context is missing or stale.
- Very specific: line 164
Keep persistent project memory in Beads via bd remember.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
Build Commands
# Install dependencies (requires ocicl package manager)
ocicl install
# Build the icl executable
make
# Clean build artifacts
make cleanThe build requires SBCL, ocicl, and libfixposix-devel.
Running
# Start ICL with auto-detected Lisp backend
./icl
# Specify a backend
./icl --lisp sbcl
./icl --lisp ccl
# Evaluate and exit
./icl -e '(+ 1 2 3)'
# Connect to existing Slynk server
./icl --connect localhost:4005Architecture Overview
ICL is a frontend REPL that communicates with a backend Lisp process via the Slynk protocol (from SLY). This client-server architecture allows it to work with multiple Lisp implementations.
Key Components
- src/main.lisp - Entry point, CLI parsing (uses clingon)
- src/repl.lisp - Main REPL loop, coordinates input/output/eval
- src/slynk-client.lisp - Wraps the slynk-client library for backend communication
- src/backend.lisp - Backend process management, Lisp implementation detection
- src/editor.lisp - Multi-line input editor with readline-style editing
- src/buffer.lisp - Input buffer management for the editor
- src/paredit.lisp - Structural editing (auto-close parens, sexp navigation)
- src/completion.lisp - Tab completion for symbols and packages
- src/highlight.lisp - Syntax highlighting with terminal colors
- src/inspector.lisp - TUI object inspector
- src/mcp-server.lisp - HTTP server for AI CLI integration (read-only tools)
- src/browser.lisp - Web-based IDE interface (Hunchentoot + WebSockets)
- src/commands/ - Extensible comma-prefixed command system
Command System
Commands are defined using define-command in src/commands/core.lisp:
(define-command (help h ?) ()
"Show available commands."
...)Commands can have aliases (like h and ? above) and receive parsed arguments as strings.
Terminal Abstraction
Platform-specific terminal handling:
src/terminal-posix.lisp- POSIX termios-based raw modesrc/terminal-windows.lisp- Windows console API
Dependencies
Third-party code is vendored in:
3rd-party/slynk-client/- Modified slynk-client for backend communicationocicl/- Dependencies managed by ocicl (including Slynk from SLY)
Release Process
See docs/RELEASING.md. Key files to update:
icl.asd-:versionfield- Create
docs/release-notes/RELEASE-NOTES-X.Y.Z.md
Tag with vX.Y.Z to trigger GitHub Actions build.
<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:46cd31e7 -->Beads Issue Tracker
This project uses bd (beads) for issue tracking. Run bd prime to see full workflow context and commands.
Quick Reference
bd ready # Find available work
bd show <id> # View issue details
bd update <id> --claim # Claim work
bd close <id> # Complete workRules
- Use
bdfor ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists - Run
bd primefor detailed command reference and session close protocol - Use
bd rememberfor persistent knowledge — do NOT use MEMORY.md files
Architecture in one line: issues live in a local Dolt DB; sync uses refs/dolt/data on your git remote; .beads/issues.jsonl is a passive export. See https://github.com/gastownhall/beads/blob/main/docs/core-concepts/sync-concepts.md for details and anti-patterns.
Agent Context Profiles
The managed Beads block is task-tracking guidance, not permission to override repository, user, or orchestrator instructions.
- Conservative (default): Use
bdfor task tracking. Do not run git commits, git pushes, or Dolt remote sync unless explicitly asked. At handoff, report changed files, validation, and suggested next commands. - Minimal: Keep tool instruction files as pointers to
bd prime; use the same conservative git policy unless active instructions say otherwise. - Team-maintainer: Only when the repository explicitly opts in, agents may close beads, run quality gates, commit, and push as part of session close. A current "do not commit" or "do not push" instruction still wins.
Session Completion
This protocol applies when ending a Beads implementation workflow. It is subordinate to explicit user, repository, and orchestrator instructions.
- File issues for remaining work - Create beads for anything that needs follow-up
- Run quality gates (if code changed) - Tests, linters, builds
- Update issue status - Close finished work, update in-progress items
- Handle git/sync by active profile:
# Conservative/minimal/default: report status and proposed commands; wait for approval. git status # Team-maintainer opt-in only, unless current instructions forbid it: git pull --rebase bd dolt push git push git status - Hand off - Summarize changes, validation, issue status, and any blocked sync/commit/push step
Critical rules:
- Explicit user or orchestrator instructions override this Beads block.
- Do not commit or push without clear authority from the active profile or the current user request.
- If a required sync or push is blocked, stop and report the exact command and error.
<!-- END BEADS INTEGRATION --><!-- BEGIN BEADS CODEX SETUP: generated by bd setup codex -->Beads Issue Tracker
Use Beads (bd) for durable task tracking in repositories that include it. Use the beads skill at .agents/skills/beads/SKILL.md (project install) or ~/.agents/skills/beads/SKILL.md (global install) for Beads workflow guidance, then use the bd CLI for issue operations.
Quick Reference
bd ready # Find available work
bd show <id> # View issue details
bd update <id> --claim # Claim work
bd close <id> # Complete work
bd prime # Refresh Beads contextRules
- Use
bdfor all task tracking; do not create markdown TODO lists. - Run
bd primewhen Beads context is missing or stale. Codex 0.129.0+ can load Beads context automatically through native hooks; use/hooksto inspect or toggle them. - Keep persistent project memory in Beads via
bd remember; do not create ad hoc memory files.
Architecture in one line: issues live in a local Dolt DB; sync uses refs/dolt/data on your git remote; .beads/issues.jsonl is a passive export. See https://github.com/gastownhall/beads/blob/main/docs/core-concepts/sync-concepts.md for details and anti-patterns.
<!-- END BEADS CODEX SETUP -->Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

