🛠️ SIN-Code Tool Suite — IMMER UNSERE EIGENEN TOOLS NUTZEN (PRIORITY -10.0 - ABSOLUTE OBERSTE REGEL)
UNSERE 7 SIN-Code Tools sind BESSER als die opencode-eigenen Alternativen. Jeder Agent MUSS unsere Tools nutzen, niemals die opencode-internen.
| Aufgabe | SIN-Code Tool (NUTZEN!) | Opencode Alternative (NICHT nutzen!) | Warum unsere besser |
|---|---|---|---|
| Dateien suchen, Projekt-Struktur erkunden | sin-discover |
opencode interne Dateisuche |
Pattern-Matching, Relevanz-Scoring, Dependency-Map, Gruppierung |
| Befehle ausführen, Kommandos laufen lassen | sin-execute |
opencode interne Shell-Ausführung |
Secret-Redaction, Safety-Checks, Timeout-Handling, Error-Analyse |
| Architektur analysieren, Module mappen | sin-map |
opencode interne Code-Analyse |
Module-Level, Entry-Points, Hot-Paths, Dependency-Graph, Orphan-Detection |
| Einzelne Datei verstehen, Code analysieren | sin-grasp |
opencode interne Code-Analyse |
Struktur, Dependencies, Usage, Context, Related-Files |
| Code durchsuchen, Patterns finden | sin-scout |
opencode interne Suche |
Regex, Semantic, Symbol, Usage-Search, Dead-Code-Detection |
| URLs abrufen, APIs konsumieren | sin-harvest |
opencode interne HTTP-Requests |
Caching, Struktur-Extraktion, Change-Detection, Auth-Management |
| Tasks managen, Planung, Rollback | sin-orchestrate |
opencode interne Task-Planung |
Dependencies, Parallel-Execution, Blocker-Detection, Rollback-Plan |
| Tool | MCP Name | GitHub Repo | Skill | Installiert |
|---|---|---|---|---|
sin-discover |
sin-discover |
OpenSIN-Code/SIN-Code-Discover-Tool |
sin-discover |
✅ ~/.local/bin/discover |
sin-execute |
sin-execute |
OpenSIN-Code/SIN-Code-Execute-Tool |
sin-execute |
✅ ~/.local/bin/execute |
sin-map |
sin-map |
OpenSIN-Code/SIN-Code-Map-Tool |
sin-map |
✅ ~/.local/bin/map |
sin-grasp |
sin-grasp |
OpenSIN-Code/SIN-Code-Grasp-Tool |
sin-grasp |
✅ ~/.local/bin/grasp |
sin-scout |
sin-scout |
OpenSIN-Code/SIN-Code-Scout-Tool |
sin-scout |
✅ ~/.local/bin/scout |
sin-harvest |
sin-harvest |
OpenSIN-Code/SIN-Code-Harvest-Tool |
sin-harvest |
✅ ~/.local/bin/harvest |
sin-orchestrate |
sin-orchestrate |
OpenSIN-Code/SIN-Code-Orchestrate-Tool |
sin-orchestrate |
✅ ~/.local/bin/orchestrate |
sin-websearch |
sin-websearch |
OpenSIN-Code/SIN-Code-Websearch-Skill |
sin-websearch |
✅ ~/.config/opencode/skills/sin-websearch |
sin-scheduler |
sin-scheduler |
OpenSIN-Code/SIN-Code-Scheduler-Skill |
sin-scheduler |
✅ ~/.config/opencode/skills/sin-scheduler |
sin-marketplace |
sin-marketplace |
OpenSIN-Code/SIN-Code-Marketplace-Skill |
sin-marketplace |
✅ ~/.config/opencode/skills/sin-marketplace |
sin-slash |
sin-slash |
OpenSIN-Code/SIN-Code-Slash-Skill |
sin-slash |
✅ ~/.config/opencode/skills/sin-slash |
sin-goal-mode |
sin-goal-mode |
OpenSIN-Code/SIN-Code-Goal-Mode-Skill |
sin-goal-mode |
✅ ~/.config/opencode/skills/sin-goal-mode |
1. Neues Projekt erkunden:
# NIEMALS opencode-interne Dateisuche nutzen!
/Users/jeremy/.local/bin/discover -path /Users/jeremy/dev/NEUES-PROJEKT -pattern "**/*.py" -sort_by relevance -format json
# Ergebnis: Alle Python-Dateien absteigend nach Relevanz sortiert, mit Dependencies und Related-Files2. Befehle sicher ausführen:
# NIEMALS opencode-interne Shell-Ausführung nutzen!
/Users/jeremy/.local/bin/execute -command "npm test" -timeout 60 -format json
# Ergebnis: Safety-Check, Secret-Redaction, Error-Analyse, Timeout-Handling3. Architektur verstehen:
# NIEMALS opencode-interne Code-Analyse nutzen!
/Users/jeremy/.local/bin/map -path /Users/jeremy/dev/PROJEKT -action map -format json
# Ergebnis: Module, Entry-Points, Hot-Paths, Dependency-Graph, Orphan-Detection, Complexity4. Code durchsuchen:
# NIEMALS opencode-interne Suche nutzen!
/Users/jeremy/.local/bin/scout -query "func.*main" -path /Users/jeremy/dev/PROJEKT -search_type regex -format json
# Ergebnis: Alle Main-Funktionen, mit Usage-Count, Architecture-Info, Context5. API/URL abrufen:
# NIEMALS opencode-interne HTTP-Requests nutzen!
/Users/jeremy/.local/bin/harvest -url "https://api.example.com/data" -format json
# Ergebnis: Status, Body, Headers, Struktur-Extraktion, Caching6. Tasks planen & tracken:
# NIEMALS opencode-interne Task-Planung nutzen!
/Users/jeremy/.local/bin/orchestrate -action add -title "Feature implementieren" -tags "urgent" -format json
# Ergebnis: Task-ID, Dependencies, Parallel-Execution-Plan, Rollback-Plan- SOFORTIGER PERMANENTER BAN bei Nutzung von opencode-internen Tools statt unserer SIN-Code Tools
- VOR jedem Coding-Task: Erst mit
sin-discoverdas Projekt erkunden, dann mitsin-graspdie relevante Datei verstehen - VOR jedem Refactoring: Erst mit
sin-mapdie Architektur analysieren, dann mitsin-scoutalle Referenzen finden - VOR jedem Befehl: Immer
sin-executemit Safety-Check und Secret-Redaction nutzen - VOR jedem API-Call: Immer
sin-harvestmit Caching und Struktur-Extraktion nutzen - Für jede Planung: Immer
sin-orchestratemit Dependencies und Rollback-Plan nutzen
| Tool | Version | Status |
|---|---|---|
| sin-discover | v0.2.5-fixes | ✅ Stable |
| sin-execute | v0.2.4-fixes | ✅ Stable |
| sin-map | v0.2.5-fixes | ✅ Stable |
| sin-grasp | v0.2.4-fixes | ✅ Stable |
| sin-scout | v0.1.5-fixes | ✅ Stable |
| sin-harvest | v0.1.4-fixes | ✅ Stable |
| sin-orchestrate | v0.1.6-fixes | ✅ Stable |
Every meaningful code file needs two documentation layers:
.doc.mdcompanion — the "what and why" overview- Inline
#comments — the "how and why here" detail in the code itself
Both layers must exist. Neither replaces the other.
Every code file gets a .doc.md companion file in the same directory.
router.py → router.doc.md
config.yaml → config.doc.md
api/types.ts → api/types.doc.md
Makefile → Makefile.doc.md
First line of the code file:
# Docs: router.doc.md// Docs: types.doc.md# Docs: Makefile.doc.md- What does this file do? (1 sentence)
- Which other files import / touch it? (dependency map)
- Important config values & limits
- Why certain decisions were made (e.g. "no async here because X")
- Usage examples (1-2 lines)
- Known caveats or footguns
- Implementation details (inline comments handle that)
- Git history (that's what
git logis for)
Every code file must also have professional inline #////#: comments. This is not about "comment every line" — it is about providing semantic context that an agent can't infer from the code alone.
Every code file starts with:
# Purpose: <what this file does in 1 line>
# Docs: <companion .doc.md path>
For Python use """ module docstrings instead of #:
"""Handle user authentication.
Docs: auth.doc.md
"""For TypeScript/Rust/etc use doc-comment style:
/**
* Handle user authentication.
* Docs: auth.doc.md
*/Every public function, method, class, type, and constant needs a docstring:
def calculate_route(
origin: Coordinate,
dest: Coordinate,
traffic: bool = False,
) -> Route:
"""Shortest path between two coordinates.
Uses A* with Manhattan heuristic. Raises if both coords
are identical (avoids zero-length route).
"""
.../** Shortest path between two coordinates.
*
* Uses A* with Manhattan heuristic. Throws if both coords
* are identical (avoids zero-length route).
*/
function calculateRoute(
origin: Coordinate,
dest: Coordinate,
traffic: boolean = false,
): Route { ... }Add a comment when the code does something surprising:
- Why NOT the obvious approach:
# not using dict comprehension because ... - Why this value:
# 50ms timeout — must be < retry-after of upstream (60ms) - Why this ordering:
# flush before close — close may skip unflushed data - Edge case:
# handles None because protocol allows null fields - Performance note:
# O(n²) but n ≤ 10 in practice - Security note:
# sanitize_input() prevents SQL injection here
# ── Auth ──────────────────────────────────────
Visually group related blocks. The long line makes sections scannable.
Always explain:
MAX_RETRIES = 3 # upstream SLA guarantees < 2 failures per 1000
WAIT_SECONDS = 60 # must match upstream rate-limit windowconst MAX_RETRIES = 3 // upstream SLA guarantees < 2 per 1000
const WAIT_SECONDS = 60 // must match upstream rate-limit windowdef test_retry_exhaustion():
"""After 3 retries, route should raise UpstreamError."""Test names plus docstrings = executable documentation.
def old_login(): # DEPRECATED(v2): use authenticate() instead- Every change to a function's signature: update its docstring
- Every change to non-obvious logic: add/update the context comment
- Every new module: file header + section separators
- Every new public API: docstring on add
i += 1— obvious code needs no commentx = 1— unless 1 is a meaningful constant- Getter/setter boilerplate
- Standard library calls with obvious semantics
After changes, verify with the bundle CLI:
sin codocs check # exit 1 if any .doc.md reference is broken
sin codocs check --json # machine-readable output
sin codocs list # list every reference and whether it resolvesFor inline docs, use manual review with:
# Check files that have NO module-level docstring/Purpose line
python3 -c "
import ast, sys
for f in sys.argv[1:]:
try:
tree = ast.parse(open(f).read())
if not (isinstance(tree.body[0], ast.Expr) and hasattr(tree.body[0].value, 'value') and 'Purpose' in tree.body[0].value.s if hasattr(tree.body[0].value, 's') else isinstance(tree.body[0], ast.Expr) and isinstance(tree.body[0].value, ast.Constant)):
print(f'MISSING PURPOSE: {f}')
except: print(f'PARSE ERROR: {f}')
"docs/folder — architecture docs, ADRs, setup guidesREADME.md— project overview- No
.doc.mdfor pure config files without logic (.gitignore,.prettierrc, etc.) - No inline docs required for throwaway scripts in
debug/,tmp/, experimental branches
Converts everything to Markdown for LLM consumption: PDF, DOCX, PPTX, XLSX, Images (OCR), Audio, HTML, CSV/JSON/XML, ZIP, YouTube, EPUB, Outlook MSG.
pipx install markitdown # recommended (CLI + library)
pip install 'markitdown[pdf, docx, pptx, xlsx]' # minimal
pip install 'markitdown[all]' # everythingmarkitdown file.pdf > file.md # stdout
markitdown file.pdf -o file.md # output file
cat file.pdf | markitdown # pipe
markitdown --use-plugins file.pdf # with plugins (OCR)
markitdown file.pdf --use-cu --cu-endpoint "<e>" # Azure Content Understandingfrom markitdown import MarkItDown
md = MarkItDown()
result = md.convert("document.pdf")
print(result.text_content)
# With LLM vision (image descriptions in PPTX/Images)
from openai import OpenAI
md = MarkItDown(llm_client=OpenAI(), llm_model="gpt-4o")
# Security: local files only
result = md.convert_local("document.pdf")for f in docs/*.pdf docs/*.docx docs/*.pptx; do
markitdown "$f" -o "${f%.*}.doc.md"
done
# then add `# Docs: filename.doc.md` to the matching code fileconvert()runs with the calling process's full file-IO rights. Never pass untrusted input directly.- Prefer
convert_local()/convert_stream()for controlled access.
https://github.com/microsoft/markitdown | pipx install markitdown
Safe command execution with timeout, output capture, safety checks, and error analysis.
# Build and install
go build -o ~/.local/bin/execute ./cmd/execute
# Run a command
execute -command "echo hello" -format json
# With timeout
execute -command "sleep 5" -timeout 2 -format json
# Redact secrets
execute -command "echo API_KEY=secret123" -format json- Safety checks: Blocks dangerous commands (rm -rf /, etc.)
- Secret redaction: Automatically redacts API keys, tokens, passwords
- Environment variable redaction: Redacts USER, HOME, etc.
- Timeout handling: Kills processes after timeout, shows [TIMEOUT]
- Error analysis: Analyzes exit codes and provides suggestions
- Persistent history: Saves execution history to ~/.local/state/sinator/
- Signal handling: Handles SIGKILL, SIGTERM, SIGINT, SIGSEGV
v0.2.4-fixes
Unified CLI and MCP server for the entire SIN-Code agent-engineering stack.
# Install
pip install -e .
# Show status
sin status
# Bootstrap repo
sin bootstrap .
# Run SIN-Code Go tool
sin sin-code run discover --path . -pattern "**/*.py" -format json
# Generate AGENTS.md
sin sin-code agents-md --output AGENTS.md- Unified CLI: Single
sincommand for all tools - MCP server: Unified MCP server for all agents
- Status detection: Auto-detects installed subsystems
- Graceful degradation: Works with partial installations
- Go tool integration: Runs SIN-Code Go tools via
sin sin-code run - AGENTS.md generator: Generates tool suite documentation
- GitHub
- SIN-Code-Discover-Tool
- SIN-Code-Execute-Tool
- SIN-Code-Map-Tool
- SIN-Code-Grasp-Tool
- SIN-Code-Scout-Tool
- SIN-Code-Harvest-Tool
- SIN-Code-Orchestrate-Tool
- SIN-Brain
v0.2.0