If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/c-bata/go-prompt shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 9mo ago
• 11 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 9mo ago
• ⚠ Concentrated ownership — top contributor handles 78% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live c-bata/go-prompt repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/c-bata/go-prompt.

What it runs against: a local clone of c-bata/go-prompt — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in c-bata/go-prompt | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 298 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of c-bata/go-prompt. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/c-bata/go-prompt.git
#   cd go-prompt
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of c-bata/go-prompt and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "c-bata/go-prompt(\\.git)?\\b" \\
  && ok "origin remote is c-bata/go-prompt" \\
  || miss "origin remote is not c-bata/go-prompt (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "prompt.go" \\
  && ok "prompt.go" \\
  || miss "missing critical file: prompt.go"
test -f "input.go" \\
  && ok "input.go" \\
  || miss "missing critical file: input.go"
test -f "render.go" \\
  && ok "render.go" \\
  || miss "missing critical file: render.go"
test -f "buffer.go" \\
  && ok "buffer.go" \\
  || miss "missing critical file: buffer.go"
test -f "key_bind.go" \\
  && ok "key_bind.go" \\
  || miss "missing critical file: key_bind.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 298 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~268d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/c-bata/go-prompt"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

go-prompt is a Go library for building interactive command-line interfaces with auto-completion, inspired by python-prompt-toolkit. It provides cross-platform terminal input handling (POSIX via input_posix.go and Windows via input_windows.go), real-time suggestion filtering, and history management—enabling developers to build sophisticated CLIs like kube-prompt and evans without terminal control complexity. Flat single-package architecture: core library code (buffer.go, document.go, completion.go, history.go, input.go, emacs.go, filter.go) lives at root level with platform-specific variants (input_posix.go, input_windows.go). Supporting subpackages: completer/ for file completion (completer/file.go), internal/bisect/ for search utilities, internal/debug/ for logging. Examples in _example/ (simple-echo, exec-command, http-prompt, live-prefix) demonstrate usage patterns. Tools in _tools/ for debugging (vt100_debug, sigwinch, complete_file).

Go developers building interactive CLI tools who need auto-completion, history, and cross-platform terminal handling without wrestling with raw terminal control codes. Specifically suits maintainers of command-line utilities targeting both Unix and Windows users.

Actively maintained and production-ready: the project has established usage across ~15 real-world projects (kube-prompt, Evans, Rancher CLI, kafka-prompt, etc.), comprehensive test coverage (buffer_test.go, completion_test.go, document_test.go, history_test.go, input_test.go, filter_test.go), CI/CD via GitHub Actions (.github/workflows/test.yml), and Go 1.14+ support in go.mod. Last activity appears recent with established CHANGELOG.md versioning.

Minimal dependency risk: only 5 external dependencies (mattn's go-colorable, go-runewidth, go-tty; pkg/term; golang.org/x/sys) which are stable, well-maintained libraries. Single maintainer (c-bata) is a potential bus-factor risk, but the mature codebase and active downstream projects mitigate abandonment risk. No obvious breaking changes visible in the structure.

No active PR/issue data visible in the provided file list, but the stable structure and mature examples suggest maintenance mode rather than active feature development. CHANGELOG.md indicates version history exists. Focus appears to be on stability and cross-platform compatibility given the explicit input_posix.go and input_windows.go implementations.

git clone https://github.com/c-bata/go-prompt.git
cd go-prompt
go mod download
cd _example/simple-echo
go run main.go

Daily commands:

make                    # (review Makefile for available targets)
go test ./...          # Run all tests
cd _example/simple-echo && go run main.go  # Run simplest example

• prompt.go — Main entry point and core Prompt struct—defines the public API and orchestrates the entire interactive prompt lifecycle.
• input.go — Abstracts keyboard input handling across platforms; every keystroke flows through here before being processed.
• render.go — Core rendering engine that translates buffer state into terminal output; responsible for all visual updates.
• buffer.go — Manages the text buffer and cursor state; central data structure that all editing operations mutate.
• key_bind.go — Key binding registry and dispatcher; maps user input to editing actions and custom handlers.
• output.go — Platform-agnostic output abstraction with POSIX and Windows implementations; controls terminal state.
• document.go — Wraps buffer content to provide cursor-relative text operations used by completers and filters.

Add a Custom Key Binding

1. Define a new key binding function in key_bind_func.go (e.g., myCustomAction) that mutates the buffer and returns action flags. (key_bind_func.go)
2. Register the binding in prompt.go's defaultBindings or pass a custom OptionKeyBinds via option.go. (option.go)
3. Test by creating a simple example that calls prompt.Input() and verifying the key triggers your action. (_example/simple-echo/main.go)

Implement a Custom Completer

1. Write a function matching the signature func(prompt.Document) []prompt.Suggest in your main.go or a separate file. (_example/simple-echo/main.go)
2. Use document.GetWordBeforeCursor() to extract the partial word; query your data source (e.g., database, API). (document.go)
3. Return filtered suggestions using prompt.FilterHasPrefix() or FilterContains() from filter.go. (filter.go)
4. Pass your completer to prompt.Input() or Prompt.Run() via OptionCompleter. (option.go)

Add a New Terminal Output Implementation

1. Create output_newplatform.go and implement the Output interface (Write, Flush, SetColor, Clear, CursorGoTo, etc.). (output.go)
2. Add platform detection logic in NewOutput() function to instantiate your implementation based on GOOS/GOARCH. (output.go)
3. If needed, implement platform-specific input handling by creating input_newplatform.go following the Input interface. (input.go)

Extend History Search or Navigation

1. Add a new method to History struct in history.go (e.g., SearchBackward, SearchForward with custom predicates). (history.go)
2. Create a corresponding key binding function in key_bind_func.go that calls your history method and updates the buffer. (key_bind_func.go)
3. Bind the key sequence (e.g., Ctrl+R) by adding to defaultBindings or via OptionKeyBinds. (prompt.go)

• termios (POSIX) / Console API (Windows) — Enables raw mode terminal control for real-time keystroke capture without line-buffering; essential for interactive prompts.
• VT100 escape sequences — Cross-platform way to control cursor position, colors, and text erasing in POSIX terminals; abstracts away platform-specific codes.
• goroutines + channels for signal handling — Allows non-blocking capture of SIGWINCH (terminal resize) on POSIX; enables responsive UI updates without polling.
• UTF-8 / rune processing with go-runewidth — Handles multi-byte characters (CJK, Cyrillic) and variable-width glyphs; ensures accurate cursor positioning and rendering.

• Single-threaded render loop with event-driven architecture

  • Why: Simplifies state consistency (no data races on buffer); avoids complexity of concurrent buffer mutations.
  • Consequence: Cannot parallelize I/O; blocking input read can delay render updates, but latency is negligible (~5–15ms).

• History stored in memory as []string; no persistence by default

  • Why: Keeps the library lightweight and portable; avoids filesystem dependencies.
  • Consequence: History is lost on process exit; users must implement persistence if needed.

• Completion suggestions rendered in a simple dropdown menu; no incremental/streaming results

  • Why: Keeps rendering logic simple and deterministic; matches python-prompt-toolkit's synchronous model.
  • Consequence: Long-running completers (e.g., network calls) will block the UI; applications should pre-cache or use async wrappers.

• Platform-specific input/output implementations duplicated (POSIX vs Windows)

  • Why: Avoids abstraction overhead; allows platform-optimal implementations (termios for POSIX, Console API for Windows).
  • Consequence: Code duplication; new platforms require separate implementations.

• Does not provide built-in authentication, credential handling, or secure input masking.
• Not a full TUI framework—no layout engine, no multi-window support, no advanced state management.
• Does not handle SSH or remote terminal scenarios; operates only on local tty.
• No real-time data streaming or async completion; completers must return results synchronously.
• Does

1. Terminal raw mode: input_posix.go sets terminal to raw mode (tcsetattr); if your program crashes without restoring normal mode, terminal becomes unusable—use defer cleanup. 2) Signal handling: SIGWINCH (window resize) is trapped internally; custom signal handlers may interfere. 3) TTY detection: go-tty dependency may fail in non-TTY environments (pipes, redirects); code must handle fallback. 4) CJK/Cyrillic rendering: go-runewidth is essential for proper display of multi-byte characters (_example/simple-echo/cjk-cyrillic demonstrates this); width calculations fail without it. 5) Windows console mode: golang.org/x/sys version constraints in go.mod (v0.0.0-20200918174421-af09f7315aff) are pinned; newer sys versions may break Windows I/O.

• Terminal Raw Mode — go-prompt's core behavior relies on putting the terminal in raw mode (via tcsetattr on POSIX in input_posix.go) to capture every keystroke without buffering; understanding raw mode is essential for debugging terminal behavior and cleanup
• ANSI/VT100 Escape Codes — Completion UI rendering uses VT100 escape sequences (cursor positioning, colors, clearing lines); the _tools/vt100_debug tool exists specifically to debug these codes, and filter.go/completion.go emit them
• Unicode Rune Width Calculation — go-runewidth dependency is critical because CJK and combining characters have display widths ≠ byte/rune count; buffer.go and document.go rely on accurate width calculations for cursor positioning
• Signal-Driven I/O (SIGWINCH) — input_posix.go uses SIGWINCH (terminal resize signal) to detect window dimension changes and redraw the UI; this is a non-blocking notification pattern unique to Unix terminal programming
• Trie-Based Prefix Matching — filter.go implements FilterHasPrefix for efficient suggestion filtering; understanding prefix trees helps optimize custom completers for large suggestion sets
• Cross-Platform Terminal Abstraction — go-prompt's power comes from input_posix.go (using POSIX ioctl/tcsetattr) vs input_windows.go (using Windows Console API); both implement the same buffer/document contract, hiding platform differences
• History Cyclic Buffer — history.go implements command history with prev/next navigation; the implementation pattern (internal data structure + index pointer) is worth understanding for similar stateful UI features

• chzyer/readline — Go readline implementation; similar goal (interactive input) but lower-level; go-prompt wraps readline-like functionality at a higher level with built-in completion UI
• manifoldco/promptui — Go library for building interactive prompts with select/input types; complementary (more form-like) vs go-prompt's shell-like experience; no auto-completion
• c-bata/kube-prompt — Reference implementation by same author; real-world use of go-prompt for Kubernetes CLI; shows patterns for stateful completion and command history
• jonathanslenders/python-prompt-toolkit — Spiritual predecessor (mentioned in README); Python library that inspired go-prompt's design philosophy and API surface; useful for understanding feature intent
• urfave/cli — Complementary Go CLI framework; urfave/cli handles command parsing and structure, go-prompt handles the interactive input layer

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for output_vt100.go with escape sequence validation

The output_vt100.go file handles VT100 terminal escape sequences for cross-platform rendering, but output_vt100_test.go is minimal. This is critical functionality that needs thorough testing of escape codes, cursor positioning, color output, and edge cases like CJK character width handling (already in codebase). New contributors can add tests covering Write(), WriteRaw(), and all escape sequence generation methods.

• [ ] Review output_vt100.go and identify all public methods and escape sequence generation logic
• [ ] Add test cases for WriteRaw() with various escape sequences
• [ ] Add test cases for Write() with mixed ASCII and CJK characters (reference: _example/simple-echo/cjk-cyrillic/main.go)
• [ ] Add test cases for cursor movement, color codes, and edge cases
• [ ] Ensure coverage includes Windows/POSIX differences by checking output_windows.go patterns

Add integration tests for key binding functionality (key_bind.go, key_bind_func.go, emacs.go)

The repo has key_bind.go, key_bind_func.go, and emacs.go with emacs_test.go, but integration tests are missing. These modules handle keyboard input processing and editor keybindings - critical for the interactive prompt experience. New contributors can create integration tests that simulate key sequences and verify correct handler execution across different input scenarios.

• [ ] Review key_bind.go and key_bind_func.go to understand handler registration and execution
• [ ] Review emacs.go to understand Emacs keybinding defaults
• [ ] Create key_binding_integration_test.go with test cases for key sequence handling
• [ ] Add tests for conflicting keybindings, custom keybindings override defaults, and handler execution order
• [ ] Test edge cases like modifier keys (Ctrl, Alt) and special keys (arrows, backspace)

Add unit tests for completer/file.go file completion logic

The completer/file.go module provides file path completion functionality but has no corresponding test file. This is a user-facing feature that needs validation for path handling, hidden files, directory traversal, and edge cases (symlinks, permission errors, special characters). New contributors can create completer/file_test.go with comprehensive coverage.

• [ ] Review completer/file.go to understand FilePathCompleter logic and filtering
• [ ] Create completer/file_test.go with test cases for valid file paths
• [ ] Add tests for directory traversal (.., .), hidden files handling, and relative vs absolute paths
• [ ] Add tests for edge cases: non-existent directories, permission denied, symlinks, and special characters in filenames
• [ ] Add benchmark tests for performance validation with large directories

• Add test coverage for completer/file.go—currently no completer_test.go exists; write tests for file path completion edge cases (empty paths, relative vs absolute, symlinks)
• Document the Emacs keybindings in README.md with a table mapping keys to actions (Ctrl+A → start of line, Ctrl+E → end of line, etc.) visible in emacs.go but not well-documented for users
• Implement a new example in _example/ for password input (masked echo) using the buffer.go and input_posix.go/input_windows.go APIs; this is a common CLI pattern not currently demonstrated

The codebase has moderate security concerns primarily related to outdated dependencies and Go version. The project targets Go 1.14 (2020) and uses dependencies with 2020 timestamps, creating potential exposure to known vulnerabilities. The use of a beta version dependency (pkg/term) and lack of a security policy are additional concerns. The library itself focuses on interactive prompts with no obvious injection vulnerabilities in the core functionality, but users must implement proper input validation when using it. Immediate action recommended: upgrade Go version to 1.21+, update all dependencies to latest stable versions, and establish a security policy.

• High · Outdated Go Version — go.mod. The project targets Go 1.14, which was released in February 2020 and is no longer supported. Go 1.14 has known security vulnerabilities that have been patched in newer versions. Fix: Update the go version to at least 1.21 or the latest stable version. Run 'go mod tidy' and test thoroughly after upgrading.
• High · Outdated Dependencies with Known Vulnerabilities — go.mod. Several dependencies have pinned versions from 2020 that are significantly outdated: golang.org/x/sys v0.0.0-20200918174421-af09f7315aff, github.com/pkg/term v1.2.0-beta.2, and github.com/mattn/go-tty v0.0.3. These may contain known security vulnerabilities. Fix: Run 'go get -u ./...' to update all dependencies to their latest versions. Review the CHANGELOG for each dependency to understand breaking changes. Consider using 'go list -u -m all' to identify outdated modules and 'go mod tidy' to clean up.
• Medium · Beta Dependency in Production — go.mod - github.com/pkg/term v1.2.0-beta.2. The dependency github.com/pkg/term is pinned to v1.2.0-beta.2, which is a beta version. Beta versions may have incomplete features, edge cases, and security issues not yet discovered. Fix: Upgrade to the latest stable release of github.com/pkg/term. If no stable version exists, consider using an actively maintained alternative or evaluate the risk of using beta software.
• Low · No Security Policy — Repository root. The repository does not appear to have a SECURITY.md file for reporting security vulnerabilities responsibly. This makes it difficult for security researchers to report issues privately. Fix: Create a SECURITY.md file in the repository root documenting how to report security vulnerabilities. Reference: https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
• Low · Limited Input Validation in Examples — _example/ directory. The example files (_example directory) demonstrate interactive prompt usage but may not demonstrate proper input validation for production use. If users follow these examples without adding validation, they may be vulnerable to injection attacks. Fix: Add security-focused examples or documentation highlighting input validation, sanitization, and safe handling of user input, especially for use cases involving external systems or command execution.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.