# How to Suggest a New Feature for DeepSeek-Reasonix: A Complete Guide

> Suggest a new feature for DeepSeek-Reasonix. Follow our guide to open a GitHub issue, discuss your idea, and submit a pull request with a prototype and tests.

- Repository: [YHH/DeepSeek-Reasonix](https://github.com/esengine/DeepSeek-Reasonix)
- Tags: how-to-guide
- Published: 2026-08-14

---

**To suggest a new feature for DeepSeek-Reasonix, open a GitHub Issue using the feature request template, discuss the idea in Discord or discussions first, then submit a pull request from a feature branch with a minimal prototype, tests, and a cache-impact statement.**

DeepSeek-Reasonix is a modular Go-based coding assistant with a clean separation of concerns across internal packages. Understanding its architecture helps you propose features that align with the project's engineering standards and accelerates acceptance through the **cache-first review gate**.

## Understanding the DeepSeek-Reasonix Architecture

Before suggesting a feature, locate where your change fits in the codebase. The repository organizes functionality into distinct packages:

- **`internal/agent`** – Runs the main agent loop and coordinates sessions.
- **`internal/tool/builtin`** – Houses built-in tools like `bash` and `read_file`. This is the most common extension point for new capabilities.
- **`internal/provider`** – Abstracts model providers for adding new back-ends.
- **`internal/plugin`** – Implements the MCP (model-client-protocol) for external tool servers.
- **`internal/memory`** and **`internal/skill`** – Manage the hierarchical knowledge base and auto-memory systems.

Any change affecting **system prompts**, **memory prefixes**, or **tool schemas** requires a **cache-impact statement** per [`CONTRIBUTING.md`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/CONTRIBUTING.md). The project enforces a cache-first review gate to maintain performance and consistency.

## Step-by-Step Workflow to Propose a New Feature

### 1. Discuss Your Idea First

Post a brief description in the community Discord channel (linked via the "Community" badge in [`README.md`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/README.md)) or start a discussion on the repository's Issues page. Early feedback prevents wasted effort on misaligned proposals.

### 2. Open a GitHub Issue

Use the **"Feature request"** template. Include:

- Clear title and summary
- Motivation and expected user benefit
- Proposed implementation location (e.g., "Add a new built-in tool under `internal/tool/builtin`")
- **Cache impact assessment**: `none`, `low`, `medium`, or `high`

### 3. Receive Maintainer Feedback

Maintainers may request clarification, discuss design trade-offs, or ask for a proof-of-concept. Address feedback before proceeding to implementation.

### 4. Create a Feature Branch

Fork the repository and branch from `main-v2`. Follow the contribution steps in [`CONTRIBUTING.md`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/CONTRIBUTING.md) under *Submitting changes*.

### 5. Build a Minimal Prototype

Even a stub that compiles demonstrates feasibility and helps reviewers assess architecture fit.

### 6. Add Tests and Documentation

Update relevant documentation (e.g., [`docs/PLUGIN_PACKAGES.md`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/docs/PLUGIN_PACKAGES.md) for plugin changes) and write unit tests in the appropriate package.

### 7. Submit a Pull Request

Reference the original issue, fill required metadata fields (`Cache-impact`, `Cache-guard`, `System-prompt-review`), and ensure `go test ./...` passes.

## Code Example: Adding a New Built-In Tool

Here's a complete skeleton for a new tool in [`internal/tool/builtin/mytool.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/tool/builtin/mytool.go):

```go
package builtin

import (
	"fmt"
	"github.com/esengine/DeepSeek-Reasonix/internal/tool"
)

// myTool implements the tool.Tool interface.
type myTool struct{}

// Name returns the tool's identifier.
func (myTool) Name() string { return "mytool" }

// Description provides a short human-readable description.
func (myTool) Description() string { return "Demo tool for feature suggestion" }

// Schema describes the JSON-RPC parameters.
func (myTool) Schema() string { return `{"type":"object","properties":{"msg":{"type":"string"}}}` }

// ReadOnly indicates whether the tool mutates state.
func (myTool) ReadOnly() bool { return false }

// Execute runs the tool logic.
func (myTool) Execute(ctx tool.Context, params []byte) (any, error) {
	var payload struct{ Msg string `json:"msg"` }
	if err := ctx.Decode(params, &payload); err != nil {
		return nil, fmt.Errorf("decode: %w", err)
	}
	// Simple echo implementation.
	return map[string]string{"reply": payload.Msg}, nil
}

// Register the tool via init().
func init() { tool.RegisterBuiltin(myTool{}) }

```

And the corresponding test in [`internal/tool/builtin/mytool_test.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/tool/builtin/mytool_test.go):

```go
package builtin

import (
	"testing"
	"github.com/esengine/DeepSeek-Reasonix/internal/tool"
)

func TestMyToolExecute(t *testing.T) {
	tctx := tool.NewTestContext()
	result, err := myTool{}.Execute(tctx, []byte(`{"msg":"hello"}`))
	if err != nil {
		t.Fatalf("unexpected error: %v", err)
	}
	if out, ok := result.(map[string]string); !ok || out["reply"] != "hello" {
		t.Fatalf("unexpected result: %v", result)
	}
}

```

## Key Files for Feature Contributors

| File | Purpose |
|------|---------|
| [`CONTRIBUTING.md`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/CONTRIBUTING.md) | Full workflow, cache-impact guidelines, and submission requirements |
| [`README.md`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/README.md) | Community channels and high-level design overview |
| `internal/tool/builtin` | Default location for extending agent capabilities |
| `internal/provider` | Adding support for new model providers |
| `internal/plugin` | MCP implementation for external tool servers |
| [`docs/PLUGIN_PACKAGES.md`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/docs/PLUGIN_PACKAGES.md) | Documentation for plugin development |

## Summary

- **Start with discussion** in Discord or GitHub Discussions to validate your idea
- **Use the feature request template** and include cache-impact assessment
- **Target the right package**: `internal/tool/builtin` for tools, `internal/provider` for models, `internal/plugin` for external servers
- **Provide working code**: minimal prototype with tests and documentation
- **Follow metadata requirements**: `Cache-impact`, `Cache-guard`, `System-prompt-review` in your PR

## Frequently Asked Questions

### What types of features are most likely to be accepted?

Features that extend `internal/tool/builtin` with new agent capabilities have the clearest path to acceptance. The maintainers prioritize additions that don't break existing cache behavior and include thorough test coverage. Changes to `internal/agent` core loops require stronger justification and broader design review.

### How do I determine the cache impact of my feature?

Review whether your change modifies system prompts, memory prefixes, or tool schemas. If yes, assess whether the change invalidates existing cached responses. Mark `high` impact for system prompt changes, `medium` for tool schema modifications, `low` for additions that don't alter existing behavior, and `none` for purely additive changes with no cache interaction.

### Can I propose a feature without implementing it fully?

Yes. The workflow explicitly welcomes proposals at the idea stage via Discord or GitHub Issues. A detailed design document or even a description of the intended implementation location often suffices for initial feedback. The maintainers may explicitly request a proof-of-concept before approving complex architectural changes.

### What branch should I use for feature development?

Always branch from `main-v2`, not `main`. The repository uses `main-v2` as the active development branch. Check [`CONTRIBUTING.md`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/CONTRIBUTING.md) for any branch-specific requirements before starting work, as active development practices may evolve.