코드에 영향을 미치기 전에 Claude에게 프로젝트 맵을 제공하세요.

Don't lose control of growing code. Then stop needing control at all. Winkers solves two problems: - For developers — as a codebase grows, it becomes impossible to hold the full picture in your head. Winkers builds a function-level dependency graph, calculates tech debt metrics, and gives you a browser dashboard to see dependencies and problem areas at a glance. - For AI agents — coding agents make bad decisions when they lack project context. Winkers is a search for the optimal protocol to deliver architectural knowledge to agents so they make correct decisions autonomously, without human oversight. The graph is built locally via tree-sitter. The semantic layer (why zones exist, what constraints matter, how to add features) is generated by Claude API in one call. Both are served to agents via MCP and visualized in a local dashboard. I've been using Claude Code on a business task (~150 functions) and kept hitting the same problem: the agent would confidently refactor a function called from 12 places, or merge code into files I'd rather keep untouched. So I built Winkers — a tree-sitter based MCP server that gives the agent a structured project map in one call before it writes anything. map() returns zones, hotspot functions, constraints (~500 tokens). An optional semantic layer (one Claude API call) adds business constraints and conventions that aren't visible from code structure alone — the "why" behind the architecture. Early results are encouraging: - Haiku + map ~ Sonnet without map, at 2-3x lower cost. The graph compensates for the weaker model's lack of exploration. - More context != better results. Forcing the full function list (~9K tokens) performed worse than the focused map (~500 tokens). Constraints got lost in noise. - The real design problem isn't building the graph — it's finding the right balance between MCP strictness and agent autonomy. There are several code graph MCP servers already (CodeGraphContext, codebase-memory-mcp). Winkers doesn't compete with them. What I think is missing across all tools is the steering layer: how much context to give, when to give it, and when to let the agent figure things out on its own. That balance determines whether the code agents produce actually holds up over time, or quietly turns into a patchwork of brittle fixes that pass tests but resist any change. pip install git+https://github.com/n1cke1/winkers.git cd your-project winkers init Auto-detects Claude Code or Cursor and registers the MCP server. Set ANTHROPIC_API_KEY for semantic enrichment (without it, graph still works). | MCP Tool | Context | |---|---| map | Zones, intents, constraints, conventions, before_writing_code checklist | functions_graph | Every function indexed with caller references and complexity | hotspots | Functions with 5+ callers — who calls them and how | scope | Full context for one function: callers, callees, related constraints | The agent is told: call map first before any code changes. It gets the constraints and checklist, then makes informed decisions. winkers init # graph + semantic + register MCP winkers init --no-semantic # graph only, no API call winkers serve # MCP server (stdio, called by IDE automatically) winkers dashboard # browser graph at localhost:7420 Interactive dependency graph with zone colors, caller-based sizing, and two layers: - Default — architecture overview with hover tooltips - Tech Debt — highlights complex functions, long functions, monster files Right-click any function to view its source code. Python, TypeScript, JavaScript, Java, Go, Rust, C# - Windows 11 + VS Code + Claude Code extension - Python 3.11 / 3.12 - MCP SDK 1.26 Linux/Mac should work but hasn't been tested in production yet. Issues welcome. MIT