Roslynk: Instructions file for Codex

Working on Roslynk

This is a source-based implementation guide for future changes. Paths below are relative to the repository root unless a section says otherwise. Re-check the affected implementation before changing it; this guide describes the architecture and its current limits, not a substitute for the source.

Start here

• The solution is Source/Morris.Roslynk.slnx (not under Source/App).
• Read git status before editing and preserve unrelated work.
• When Roslynk is connected, use its semantic tools for compiled C#, Razor and CSHTML: open the solution, use get_members/get_symbol_body to inspect implementations, and use reference/caller queries for impact analysis. Follow skills/roslynk/SKILL.md for routing; each tool's contract lives in its C# method's [Description] attribute and is published in MCP metadata. Retry Indexing while loading; do not manually reload for ordinary source edits.
• Batch related read-only questions with multi_query. Re-query after writes. A running Roslynk daemon can inspect edited source, but editing this repository does not replace the daemon's executing implementation; run tests against the checkout to validate new behavior.
• Use normal file tooling for non-source configuration, documentation, and new-file creation. Roslynk's patch tool only edits existing files, and its plain-text fallback is rooted at the solution directory (Source), not the repository root.
• The most important seams are RoslynInstance, SolutionModel, ApplyPipeline, AtomicFileWriter, SolutionFileSync, and the internal cores used by MultiQueryCatalog.

Required workflow for feature and tool changes

• When creating a new read-only tool, assess whether it is a candidate for multi_query and ask the user whether to include it, unless the user's request already explicitly says to add the tool to multi_query (then include it without asking). Otherwise do not silently include or exclude it. Continue independent implementation work while that choice is pending; if included, implement the pinned-model core, catalog/enum integration and relevant tests described below.
• Add every new feature and feature change to the # Unreleased section at the top of releases.md. Create that section at the top if it is missing, preserving existing release history. Each addition is a terse one-line bullet ending with (Fixes #xx), where xx is the GitHub issue number, e.g. - New `get_callees` tool: the inverse of `get_callers` (Fixes #58). Detail belongs in the skill/tool docs, not in releases.md. If the issue number is unknown, ask the user.
• Documentation ownership: routing guidance lives in the roslynk skill (skills/roslynk/SKILL.md); shared workflows live in McpServerRegistration.Configure as MCP server instructions; each tool's complete contract lives in its C# method's [Description] attribute and is published in MCP metadata; parameter contracts stay in code as [Description] attributes on parameters, with identical parameter contracts reusing ParameterDescriptions. Server instructions carry shared conventions once; tool descriptions contain only their own contracts. When a tool's contract or behavior changes, update its method description in the same change (and SKILL.md when routing changes), and check for contradictory or obsolete copies of the guidance.