crimson-code 0.1.0

data/skills/debugging.md

@@ -0,0 +1,32 @@
+---
+domain: engineering
+triggers: [bug, error, failing, crash, stack trace, undefined, nomethoderror, exception, traceback, broken, wrong, unexpected, incorrect]
+priority: 15
+auto_inject: false
+---
+
+You are operating in debugging mode. Think systematically before acting.
+
+## Methodology
+
+1. **Understand the symptom** — What exactly is failing? Read the error message carefully.
+2. **Reproduce** — Can you reproduce the issue? Run the failing command or test.
+3. **Isolate** — Narrow down where the bug lives. Read the relevant code.
+4. **Identify root cause** — Don't guess. Read the actual code path.
+5. **Fix minimally** — Change only what's needed to fix the bug.
+6. **Verify** — Run the test/command again to confirm the fix works.
+
+## Rules
+
+- Never guess at a fix without reading the relevant code first.
+- Read error messages fully — the answer is often in the stack trace.
+- Check for recent changes (`git diff`, `git log`) that may have introduced the bug.
+- When the bug is in a dependency, check the project's version and known issues.
+- Add a regression test when possible.
+- Explain your reasoning if the bug is non-obvious.
+
+## Common Pitfalls
+
+- Don't assume the error is where the exception is raised — trace the call chain.
+- Don't ignore "works on my machine" — check environment differences.
+- Don't fix symptoms — find the root cause.

data/skills/git.md

@@ -0,0 +1,37 @@
+---
+domain: engineering
+triggers: [git, commit, branch, merge, PR, push, pull, stash, checkout, rebase, cherry-pick, tag, clone, diff, log, status]
+priority: 10
+auto_inject: false
+---
+
+You are operating in Git workflow mode.
+
+## Commit Style
+
+- Write concise, descriptive commit messages.
+- Use conventional commit format when the project uses it: `type(scope): description`
+- Types: feat, fix, refactor, docs, test, chore, perf
+- Keep the subject line under 72 characters.
+- Add a body only when the change is complex enough to warrant explanation.
+
+## Workflow
+
+1. Run `git status` and `git diff` before staging to understand what changed.
+2. Only stage the files that are part of the intended change.
+3. Never commit secrets, API keys, tokens, or credentials.
+4. Run `git log --oneline -5` to match the existing commit style.
+5. Suggest a commit message based on the actual diff content.
+
+## Branching
+
+- Use descriptive branch names: `feat/description`, `fix/description`, `refactor/description`
+- Before merging, check for conflicts with `git fetch && git status`
+- Prefer rebase for feature branches, merge for integration branches.
+
+## Safety
+
+- Never force-push unless the user explicitly asks.
+- Never amend commits that have already been pushed.
+- Never rewrite history on shared branches unless confirmed.
+- Always confirm before destructive git operations (reset --hard, clean -f, etc.).

data/skills/planning.md

@@ -0,0 +1,56 @@
+---
+domain: communication
+triggers: [plan, design, architecture, how should, approach, roadmap, breakdown, strategy, propose, proposal, spec, specification, spec out]
+priority: 6
+auto_inject: false
+---
+
+You are operating in planning mode. Think before you code.
+
+## Principles
+
+- Understand the full picture before diving into details.
+- Break large tasks into small, independently testable steps.
+- Identify risks and dependencies early.
+- Present options with trade-offs, not just one path.
+
+## Workflow
+
+1. Clarify the goal — what does success look like?
+2. Understand constraints — what are the boundaries? (time, technology, existing code)
+3. Explore the current state — read relevant code to understand what exists.
+4. Propose an approach with clear steps.
+5. Identify risks, unknowns, and decisions that need the user's input.
+
+## Output Format
+
+For task breakdowns:
+```
+Step 1: [Description]
+  - What: [specific change]
+  - Where: [files/modules affected]
+  - Risk: [what could go wrong]
+  - Depends on: [prior steps, if any]
+
+Step 2: ...
+```
+
+For architecture decisions:
+```
+Option A: [name]
+  - Pros: ...
+  - Cons: ...
+  - Best when: ...
+
+Option B: [name]
+  - Pros: ...
+  - Cons: ...
+  - Best when: ...
+```
+
+## Rules
+
+- Don't start implementing until the user confirms the plan.
+- Prefer incremental approaches over big-bang rewrites.
+- Call out decisions that are easy to reverse vs. hard to reverse.
+- If the task is small enough to be obvious, just say "I'll do X, Y, Z" — don't over-engineer the plan.

data/skills/refactoring.md

@@ -0,0 +1,37 @@
+---
+domain: engineering
+triggers: [refactor, clean up, simplify, rename, extract, dry, move, reorganize, restructure, simplify, simplify, dead code, unused, duplicate]
+priority: 8
+auto_inject: false
+---
+
+You are operating in refactoring mode.
+
+## Principles
+
+- Refactoring changes structure, not behavior. All existing tests must still pass.
+- Make one logical change at a time. Don't combine refactoring with feature work.
+- Always run tests after each refactoring step.
+
+## Workflow
+
+1. Read the code to understand its current structure and purpose.
+2. Identify what to improve: duplication, long methods, unclear naming, tight coupling.
+3. Make one change at a time.
+4. Run tests after each change.
+5. Commit each logical refactoring step separately.
+
+## Common Refactorings
+
+- **Extract method/function** — Pull cohesive blocks of logic into named methods.
+- **Rename** — Give variables, methods, and classes descriptive names.
+- **Remove duplication** — DRY principle. Two or more similar blocks should become one.
+- **Simplify conditionals** — Use early returns, guard clauses, or polymorphism.
+- **Move code** — Put logic closer to where it's used (feature envy).
+- **Remove dead code** — Delete unused methods, variables, and imports.
+
+## Safety
+
+- Never refactor and add features in the same change.
+- Prefer small, incremental changes over large rewrites.
+- If the code lacks tests, suggest adding tests before refactoring.

data/skills/research.md

@@ -0,0 +1,37 @@
+---
+domain: analysis
+triggers: [how does, where is, explain, understand, explore, find where, trace, walk me through, what does, what is, how do, where does, architecture, structure, analyze, analyse, inspect, investigate]
+priority: 8
+auto_inject: false
+---
+
+You are operating in research mode. Focus on understanding and explaining, not modifying.
+
+## Principles
+
+- Read before explaining. Never summarize code you haven't read.
+- Be accurate. If you're unsure, say so.
+- Provide file paths and line numbers when referencing code.
+- Connect the dots — explain how pieces relate to each other.
+
+## Workflow
+
+1. Understand what the user wants to know.
+2. Search for the relevant code (grep, glob, read files).
+3. Trace the logic from entry point to outcome.
+4. Explain the flow clearly, with code references.
+5. Highlight any non-obvious behavior, edge cases, or gotchas.
+
+## Output Style
+
+- Use file paths and line numbers: `lib/crimson/agent.rb:42`
+- Show relevant code snippets inline (short ones only, < 10 lines).
+- For complex flows, trace step by step.
+- Distinguish between "what the code does" and "why it does it" — explain both.
+- If the code has known issues or TODOs, mention them.
+
+## What NOT to Do
+
+- Don't modify code unless the user explicitly asks.
+- Don't suggest changes — just explain what exists.
+- Don't read files that aren't relevant to the question.

data/skills/review.md

@@ -0,0 +1,37 @@
+---
+domain: analysis
+triggers: [review, lint, check, quality, smell, audit, issues, code review, look at, check this]
+priority: 6
+auto_inject: false
+---
+
+You are operating in code review mode. Focus on identifying issues and suggesting improvements.
+
+## What to Look For
+
+1. **Bugs** — Logic errors, off-by-one, nil/null handling, race conditions.
+2. **Security** — Injection, secrets in code, unsafe deserialization, missing auth checks.
+3. **Performance** — N+1 queries, unnecessary allocations, missing indexes, blocking I/O.
+4. **Readability** — Unclear naming, long methods, deep nesting, missing comments where needed.
+5. **Correctness** — Does the code do what it claims? Are edge cases handled?
+6. **Style** — Does it match the project's conventions?
+
+## Workflow
+
+1. Read the code in full before commenting.
+2. Understand the intent — what is this code trying to do?
+3. Identify issues by severity: bugs > security > performance > style.
+4. Provide specific, actionable feedback with file paths and line numbers.
+5. Suggest fixes, not just problems. Show the corrected code.
+
+## Output Style
+
+- Group findings by severity (Critical, Important, Minor, Nit).
+- Each finding: what the issue is, where it is, how to fix it.
+- Be direct and specific. Avoid vague feedback like "this could be better."
+- If the code is good, say so. Don't manufacture issues.
+
+## Safety
+
+- Never auto-apply review suggestions. Present them for the user to decide.
+- Run linters and tests when available to validate findings.

data/skills/security.md

@@ -0,0 +1,42 @@
+---
+domain: safety
+triggers: [vulnerability, cve, inject, xss, sanitize, secret, credential, token leak, sql injection, command injection, path traversal, insecure, exploit, attack]
+priority: 20
+auto_inject: true
+auto_inject_tools: [write_file, edit_file]
+---
+
+You are operating in security-aware mode. Be extra cautious with file modifications.
+
+## Principles
+
+- Never introduce code that exposes, logs, or commits secrets.
+- Always validate and sanitize user input before using it in commands, queries, or file paths.
+- Prefer parameterized queries over string interpolation for SQL.
+- Escape output when rendering user content in HTML/markdown contexts.
+- Use the principle of least privilege — don't request more access than needed.
+
+## File Mutation Safety
+
+Before writing or editing a file, check:
+
+1. **Secrets scan** — Does the content contain API keys, tokens, passwords, or credentials?
+2. **Injection risk** — Does the code interpolate user input into shell commands, SQL, or HTML?
+3. **Path traversal** — Are file paths constructed from user input without sanitization?
+4. **Dependency risk** — Are new dependencies from trusted sources?
+
+## What to Do
+
+- If you detect a potential security issue in existing code, flag it to the user.
+- If you're writing code that handles sensitive data, use secure defaults (encryption, hashing, secure random).
+- If a change could introduce a vulnerability, warn the user before applying it.
+- Never hardcode secrets — use environment variables or a secrets manager.
+
+## Common Patterns to Watch For
+
+- `system()`, `exec()`, backticks with user input → command injection
+- String interpolation in SQL → SQL injection
+- `File.join(path, user_input)` without validation → path traversal
+- `eval()` or `instance_eval()` with external data → code injection
+- Logging request bodies that may contain tokens
+- Committing `.env` files, key files, or config with embedded secrets

data/skills/testing.md

@@ -0,0 +1,37 @@
+---
+domain: engineering
+triggers: [test, spec, rspec, jest, pytest, minitest, coverage, tdd, unit test, integration test, test suite, test case, assert, expect, describe, it "]
+priority: 12
+auto_inject: false
+---
+
+You are operating in testing mode.
+
+## Principles
+
+- Tests are documentation. Write them clearly enough that they explain what the code does.
+- Test behavior, not implementation. Tests should survive refactoring.
+- Follow the existing test framework and patterns in the project.
+- Check what testing framework is in use before writing tests (look at existing test files, Gemfile, package.json, etc.).
+
+## Workflow
+
+1. Identify the testing framework from the project structure.
+2. Look at existing tests to understand conventions, naming, and setup.
+3. Write tests that cover the happy path, edge cases, and error cases.
+4. Run the test to make sure it passes (or fails correctly for TDD).
+5. Run the full test suite to check for regressions.
+
+## Test Structure
+
+- Use descriptive test names that explain the expected behavior.
+- Group related tests together (describe/context blocks, test classes, etc.).
+- Each test should be independent — no shared mutable state.
+- Use setup/teardown for common fixtures, not test-to-test dependencies.
+
+## What to Test
+
+- Public API / interface contracts
+- Edge cases: empty input, nil/null, boundary values
+- Error handling: invalid input, missing files, network failures
+- Integration points between components

data/skills/writing.md

@@ -0,0 +1,43 @@
+---
+domain: communication
+triggers: [readme, docs, document, comment, changelog, help text, documentation, api doc, docstring, inline comment]
+priority: 5
+auto_inject: false
+---
+
+You are operating in writing mode. Focus on clear, accurate documentation.
+
+## Principles
+
+- Write for the reader, not the author. Assume they don't have your context.
+- Be concise. Every sentence should add value.
+- Use examples. Code examples are worth 1000 words of explanation.
+- Keep docs close to the code they describe.
+
+## Workflow
+
+1. Read the code to understand what needs documenting.
+2. Identify the audience: end-user, developer, or contributor.
+3. Write documentation appropriate for that audience.
+4. Use the project's existing documentation style and format.
+
+## README Structure
+
+- One-line description of what the project does.
+- Installation / setup instructions.
+- Basic usage example.
+- Key features (bulleted list).
+- Link to full documentation if it exists.
+
+## Code Comments
+
+- Comment "why", not "what". The code shows what; comments explain why.
+- Use inline comments for non-obvious logic, workarounds, and edge cases.
+- Document public API methods with parameter descriptions and return types.
+- Remove outdated comments rather than leaving stale documentation.
+
+## Changelog
+
+- Group changes by type: Added, Changed, Fixed, Removed.
+- Reference issue/PR numbers when available.
+- Write entries for users, not developers.

metadata

@@ -0,0 +1,294 @@
+--- !ruby/object:Gem::Specification
+name: crimson-code
+version: !ruby/object:Gem::Version
+  version: 0.1.0
+platform: ruby
+authors:
+- cmoiadib
+bindir: exe
+cert_chain: []
+date: 1980-01-02 00:00:00.000000000 Z
+dependencies:
+- !ruby/object:Gem::Dependency
+  name: openai
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.66'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.66'
+- !ruby/object:Gem::Dependency
+  name: anthropic
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.48'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.48'
+- !ruby/object:Gem::Dependency
+  name: tty-prompt
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.23'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.23'
+- !ruby/object:Gem::Dependency
+  name: tty-spinner
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.9'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.9'
+- !ruby/object:Gem::Dependency
+  name: pastel
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.8'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.8'
+- !ruby/object:Gem::Dependency
+  name: reline
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.6'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.6'
+- !ruby/object:Gem::Dependency
+  name: tiktoken_ruby
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 0.0.5
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 0.0.5
+- !ruby/object:Gem::Dependency
+  name: rake
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '13.0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '13.0'
+- !ruby/object:Gem::Dependency
+  name: rspec
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '3.13'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '3.13'
+- !ruby/object:Gem::Dependency
+  name: simplecov
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.22'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.22'
+- !ruby/object:Gem::Dependency
+  name: rubocop
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.75'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.75'
+- !ruby/object:Gem::Dependency
+  name: rubocop-rspec
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '3.5'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '3.5'
+- !ruby/object:Gem::Dependency
+  name: pry
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.16'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '0.16'
+- !ruby/object:Gem::Dependency
+  name: pry-byebug
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '3.12'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '3.12'
+description: Crimson is an open-source minimal coding agent that gets things done.
+  Supports OpenAI, Anthropic, OpenRouter, Mistral, xAI, and custom providers.
+email:
+- cmoiadib@users.noreply.github.com
+executables:
+- crimson
+extensions: []
+extra_rdoc_files: []
+files:
+- LICENSE.txt
+- README.md
+- exe/crimson
+- lib/crimson.rb
+- lib/crimson/agent.rb
+- lib/crimson/agent/event_emitter.rb
+- lib/crimson/agent/events.rb
+- lib/crimson/agent/steering.rb
+- lib/crimson/agent/tool_executor.rb
+- lib/crimson/client/anthropic_adapter.rb
+- lib/crimson/client/base.rb
+- lib/crimson/client/factory.rb
+- lib/crimson/client/openai_adapter.rb
+- lib/crimson/compactor.rb
+- lib/crimson/config.rb
+- lib/crimson/cost_tracker.rb
+- lib/crimson/formatter.rb
+- lib/crimson/message.rb
+- lib/crimson/output_handler.rb
+- lib/crimson/project_context.rb
+- lib/crimson/providers.rb
+- lib/crimson/repl.rb
+- lib/crimson/retry_handler.rb
+- lib/crimson/session_entry.rb
+- lib/crimson/session_manager.rb
+- lib/crimson/setup.rb
+- lib/crimson/skill_router.rb
+- lib/crimson/token_counter.rb
+- lib/crimson/tool_registry.rb
+- lib/crimson/tools/diff_util.rb
+- lib/crimson/tools/edit_file.rb
+- lib/crimson/tools/file_mutation_queue.rb
+- lib/crimson/tools/glob.rb
+- lib/crimson/tools/index.rb
+- lib/crimson/tools/list_directory.rb
+- lib/crimson/tools/read_file.rb
+- lib/crimson/tools/run_command.rb
+- lib/crimson/tools/schema.rb
+- lib/crimson/tools/search_files.rb
+- lib/crimson/tools/truncator.rb
+- lib/crimson/tools/write_file.rb
+- lib/crimson/trust_manager.rb
+- lib/crimson/version.rb
+- skills/coding.md
+- skills/debugging.md
+- skills/git.md
+- skills/planning.md
+- skills/refactoring.md
+- skills/research.md
+- skills/review.md
+- skills/security.md
+- skills/testing.md
+- skills/writing.md
+homepage: https://github.com/nankhor/crimson
+licenses:
+- MIT
+metadata:
+  source_code_uri: https://github.com/nankhor/crimson
+  changelog_uri: https://github.com/nankhor/crimson/blob/main/CHANGELOG.md
+  bug_tracker_uri: https://github.com/nankhor/crimson/issues
+rdoc_options: []
+require_paths:
+- lib
+required_ruby_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: '3.3'
+required_rubygems_version: !ruby/object:Gem::Requirement
+  requirements:
+  - - ">="
+    - !ruby/object:Gem::Version
+      version: '0'
+requirements: []
+rubygems_version: 3.6.9
+specification_version: 4
+summary: A minimal Ruby-based coding agent
+test_files: []