@bincat/cli 0.1.0-beta.1

package/LICENSE

@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2026 bincat contributors
+Copyright (c) 2026 DeepSeek
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,18 @@
+# bincat
+
+An open-source, TUI-first coding-agent harness, tuned for DeepSeek models.
+
+## Install
+
+```sh
+npm i -g @bincat/cli@beta
+bincat
+```
+
+The first interactive run asks for your DeepSeek API key. To check the local installation and configuration at any time, run:
+
+```sh
+bincat doctor
+```
+
+License: MIT (see [`LICENSE`](LICENSE) and [`THIRD_PARTY_NOTICES.md`](THIRD_PARTY_NOTICES.md)).

package/THIRD_PARTY_NOTICES.md

@@ -0,0 +1,27 @@
+# Third-party notices
+
+bincat is derived from and inspired by several projects. This file records every
+source whose **code** is included (in original or modified form). Projects used
+only as a design reference are listed separately and contribute no code.
+
+## Code included
+
+| Source | License | What | Where in bincat |
+|---|---|---|---|
+| [deepseek-ai/deepseek-harness](https://github.com/deepseek-ai/deepseek-harness) (via fork `l1nxuan-du/deepseek-harness` @ `b760c13cc1`) | MIT, © 2026 DeepSeek | Base codebase: agent loop, tools, LLM adapters, sandbox, session, Cordis vendoring | throughout `packages/`, `vendor/`, `native/` |
+| [cordiverse/cordis](https://github.com/cordiverse/cordis), cosmokit, schemastery (vendored through DSH; manifest in `vendor/README.md`) | MIT, © 2021-present Shigma | DI / plugin kernel and foundation libs | `vendor/` |
+
+Rows are added whenever code is ported. For Apache-2.0 sources (e.g.
+[openai/codex](https://github.com/openai/codex), [anthropics/sandbox-runtime](https://github.com/anthropics/sandbox-runtime),
+[anthropics/claude-plugins-official](https://github.com/anthropics/claude-plugins-official)) the ported file must also keep
+a header comment naming the origin file, and the upstream NOTICE text is reproduced below.
+
+## Design references only (no code, no prompt text)
+
+- Claude Code (proprietary). The reconstructed sourcemap is read for architecture
+  only. Never copy its code, system prompts or tool descriptions.
+- OpenAI Codex CLI, when used for design only.
+
+## Upstream NOTICE texts
+
+_(none yet)_

package/builtin-skills/init/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: init
+description: Create or improve a project AGENTS.md so future agent sessions begin with durable, project-specific guidance. Use when setting up a repository or refreshing its contributor instructions.
+argument-hint: "[extra instructions]"
+---
+
+You are responsible for producing a concise `AGENTS.md` at the project root. Treat it
+as durable onboarding for future coding-agent sessions, not as a README replacement.
+If `$ARGUMENTS` contains extra scope or preferences, honor them.
+
+Begin by surveying the repository. Read the root and nested package manifests, lockfiles,
+workspace configuration, CI configuration, and release scripts. Identify the exact
+commands for building, testing, linting, type-checking, and running one focused test.
+Verify command names from scripts instead of guessing.
+
+Map the top-level layout in only enough detail to explain where major responsibilities
+live. Note package boundaries, generated directories, runtime entry points, and
+important data or migration locations when they are not obvious from filenames.
+
+Look for existing instruction sources before drafting: `AGENTS.md`, `CLAUDE.md`,
+`.cursorrules`, `.github/copilot-instructions.md`, README files, contributor guides,
+and relevant nested documentation. Extract reusable project facts from them. Do not
+silently discard user-authored guidance, especially workflow rules or environment
+requirements.
+
+Write the essentials: exact commands; the relationship between major modules; the
+supported runtimes and package manager; required local services; and non-obvious
+conventions, such as generated files, import rules, fixture policy, or commit rules.
+Prefer direct, testable statements over broad principles.
+
+Leave out generic engineering advice, exhaustive file-by-file inventories, copied API
+documentation, and facts that can be derived cheaply from the code. Omit secrets,
+personal paths, and instructions that apply only to the current task. If a rule is
+enforced by tooling, point to the command that enforces it.
+
+If `AGENTS.md` already exists, preserve its structure and voice where practical.
+Suggest focused edits rather than replacing the whole file. Keep useful sections,
+repair stale commands, remove duplication, and fold in facts from the other instruction
+files only when they still apply.
+
+Check every command and path you include. When a command cannot be run safely, say how
+it was verified from configuration instead. Avoid claims about behavior you did not
+inspect.
+
+Finish by showing a summary of what you changed, including any assumptions and any
+sections you intentionally left untouched. The final `AGENTS.md` should be short enough
+for future sessions to read completely.

package/builtin-skills/review/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: review
+description: Review a code change for correctness, security, regressions, and missing tests, reporting only actionable findings. Use when the user asks for a code review and does not want files edited.
+argument-hint: "[ref range, branch, or paths]"
+---
+
+Review the requested change without modifying files. `$ARGUMENTS` may contain a Git ref
+range, a branch name, a pull-request branch, a commit, or a set of paths. When it names
+a range or branch, inspect that range against its appropriate base. When it names paths,
+review the relevant working-tree changes in those paths.
+
+If `$ARGUMENTS` is empty, review the uncommitted working tree and staged changes against
+`HEAD` using `git diff HEAD`. State clearly near the start what revision, range, or files
+you reviewed so the scope is unambiguous.
+
+Read the surrounding implementation before judging a hunk. Inspect callers, callees,
+types, invariants, tests, configuration, and error paths that the diff depends on. A
+change can look correct in isolation and still break a contract elsewhere.
+
+Apply project guidance such as `AGENTS.md` while reviewing. Respect repository-specific
+rules for generated files, compatibility, dependency boundaries, testing, and API design.
+
+Focus on defects introduced or exposed by the change:
+
+- correctness bugs and violated invariants;
+- unhandled edge cases, empty states, races, and partial failures;
+- error handling, cleanup, retries, and resource ownership;
+- security, trust-boundary, injection, path, permission, and secret-handling issues;
+- compatibility regressions across supported runtimes or platforms;
+- missing tests for newly reachable behavior and important failure modes.
+
+Also notice performance or maintainability risks when they have a concrete failure mode,
+not when they are merely preferences.
+
+Report only findings you can point to. For each finding, give a `file:line` reference,
+a severity of high, medium, or low, what goes wrong, and a focused suggested fix. Explain
+the triggering scenario when it is not obvious. Order findings from highest severity to
+lowest.
+
+Do not report style nits unless the project's rules require the style. Do not invent
+issues, and do not dilute the report with praise. If you find no actionable problems,
+say plainly that no findings were found and identify any areas you could not verify.
+
+Do not edit, format, commit, or stage files. This skill produces a review report only.

package/builtin-skills/simplify/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: simplify
+description: Simplify recently changed code by removing duplication, dead paths, and needless indirection while preserving behavior. Use after an implementation works and the user wants a focused cleanup.
+argument-hint: "[paths]"
+---
+
+Simplify the code identified by `$ARGUMENTS`. When arguments name files or directories,
+limit your work to those paths. When arguments are empty, inspect the files changed in
+the working tree, including staged and unstaged edits, and choose the smallest coherent
+set to improve.
+
+Start by understanding the behavior that must remain unchanged. Read nearby callers,
+tests, types, and project guidance. Run the relevant tests before editing when they are
+available and reasonably fast.
+
+Look for concrete simplification opportunities:
+
+- duplicated logic that should use one implementation;
+- dead code, unreachable branches, and unused exports introduced by the change;
+- wrappers or abstractions that add no useful boundary;
+- helpers that already exist elsewhere in the codebase;
+- conditionals that can be reduced or made exhaustive;
+- temporary scaffolding that should disappear now that the implementation is complete.
+
+Do not chase stylistic preferences or rewrite stable code merely because a different
+design is possible. Keep the scope close to the requested change.
+
+Make only changes that are clearly better. Preserve public behavior, error semantics,
+side-effect ordering, and compatibility unless the user explicitly asked otherwise.
+Prefer a small direct edit over a broad refactor, and reuse the codebase's existing
+helpers and conventions.
+
+Keep the local style intact. Avoid introducing a new abstraction for a single caller,
+and avoid deleting comments that explain non-obvious constraints. If a simplification
+would require changing an interface or moving responsibility across modules, leave it
+alone unless the benefit is certain and the blast radius is small.
+
+After editing, run the cheapest relevant verification: focused tests first, then the
+project type checker or broader test command when practical. If a check cannot run,
+explain why and identify the residual risk.
+
+Finish by summarizing what you changed, which checks you ran, and what you deliberately
+left alone. If no safe simplification was available, say so rather than manufacturing a
+change.