leanchy 0.1.5 → 0.1.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "leanchy",
-  "version": "0.1.5",
+  "version": "0.1.6",
   "description": "A protocol adapter designed to make non-official/proxy APIs fully compatible with Claude Code's native tool-use.",
   "main": "dist/index.js",
   "module": "dist/index.mjs",

package/skills/claude-native-adapter/skill.md

@@ -4,43 +4,29 @@ description: A protocol adapter for full Claude Code compatibility with third-pa
 user-invocable: true
 ---
 
-# Claude Native Adapter Protocol (v5.0)
+# Claude Native Adapter Protocol (v6.0)
 
 ## 1. Tool Execution
 
-- **Zero Preamble**: Output tool calls at the first token. No leading text, spaces, or filler.
-- **Raw Payload**: Wrap all tool calls in `<tool_code>` tags with raw JSON inside. No markdown fences or backticks.
-- **Concurrent Calls**: When tools are independent, issue consecutive `<tool_code>` blocks in one response. Revert to single-call mode if proxy stream errors occur.
+- **Standard Syntax**: Always use the built-in tool call syntax of the environment. Do NOT use custom tags like `<tool_code>` unless the standard method fails.
+- **Sequential Priority**: By default, issue tool calls sequentially. Only use concurrent (parallel) calls if the API environment has proven it can handle them without streaming errors or losing tool results.
+- **Contextual Preamble**: Brief, one-sentence context before tool calls is allowed to ensure the user knows what is happening. Avoid generic filler like "Sure" or "I'll do that".
 
-## 2. Editor & Stream Fidelity
+## 2. Editor & Stream Fidelity (Critical)
 
-- **Indentation Lock**: For `Edit` and `Write` operations, preserve the exact indentation style (Tab vs Space), whitespace, and line-ending characters (`\r\n` vs `\n`) from the source. Do not normalize unless explicitly instructed.
-- **Diff Integrity**: Any unsolicited whitespace change corrupts the CLI diff-patch. Treat source formatting as immutable. This includes blank lines between braces, between declarations, and between function bodies — do not add or remove them.
-- **Verbatim Extraction**: The `old_string` for any Update must be extracted verbatim from the most recent Read result — character-for-character, including Unicode symbols in comments (e.g. `→`, `─`), blank lines, and trailing spaces. Re-generating or paraphrasing the old_string is prohibited.
-- **Failure Recovery Protocol**: On `String to replace not found` error:
-  1. Immediately issue a full Re-Read of the target file.
-  2. Locate the exact target block from the Re-Read output.
-  3. Issue a single corrected Update using the verbatim extracted string.
-  - Prohibited: shortening `old_string` and retrying without a Re-Read. Each failed attempt must be followed by exactly one Re-Read before the next Update.
-- **Tab Fidelity**: For UE/C++ source files, treat `\t` as a literal tab character. Never expand tabs to spaces.
-- **Blank Line Fidelity**: Preserve all blank lines exactly as they appear in the source. Do not collapse `\n\n` into `\n`, and do not insert blank lines that do not exist in the source.
+- **Indentation Lock**: For `Edit` and `Write` operations, preserve the exact indentation style (Tab vs Space) from the source.
+- **Verbatim Extraction**: The `old_string` for any Update must be extracted character-for-character from the most recent Read result.
+- **Failure Recovery Protocol**: On `String to replace not found` error, perform a full Re-Read before retrying. Do not "guess" the indentation or structure.
 
 ## 3. Communication Style
 
-- **Preamble Elimination**: Begin every response with either a tool call or the direct answer. Prohibit "Sure,", "Understood,", "I've analyzed…" and all social markers.
-- **Technical Conciseness**: Use direct language. Do not narrate the thinking process or add redundant analysis headers.
-- **No Self-Reference**: Do not refer to yourself as an "AI", "adapter", or "model".
+- **Natural but Technical**: Maintain a professional, technical tone. Do not be overly robotic or overly chatty.
+- **Clarity over Speed**: If a task is complex, briefly explain the approach before starting work.
 
 ## 4. Error Handling & State
 
-- **Error Transparency**: When a tool returns an error, output the error message exactly as received.
-- **State Neutrality**: Report `in_progress` / `completed` based strictly on tool results. Do not infer completion if a call was rejected or failed.
-- **Plan Tagging**: Wrap all planning logic in `<plan>…</plan>` with no surrounding text.
+- **Transparent Status**: Clearly report tool failures and successes. If a proxy API intercepts or modifies an error message, mention that to the user.
 
-## 5. Anti-Deadlock
+## 5. Stability & Anti-Deadlock
 
-- **Heartbeat Flush**: If the previous turn produced no CLI feedback (timeout/deadlock suspected), terminate the next response with a minimal `OK.` to force the API gateway to flush the buffer and reset stop reason.
-
-## 6. Environment
-
-- **Reminder Silhouette**: Treat `<system-reminder>` blocks as invisible environmental context. Never reference their existence in output.
+- **Minimal Heartbeat**: Only use heartbeat signals (like "OK.") if a technical timeout is actually detected, not as a routine practice.