devlyn-cli 0.7.0 → 0.7.1

package/config/skills/devlyn-resolve/SKILL.md

@@ -30,7 +30,7 @@ When escalating, output your partial findings first so the team lead has context
 </escalation>
 
 <investigate_before_answering>
-Read and inspect relevant files before forming hypotheses. Do not speculate about code you have not opened.
+Never speculate about code you have not opened. If the user references a specific file, you MUST read the file before answering. Make sure to investigate and read relevant files BEFORE answering questions about the codebase. Never make any claims about code before investigating unless you are certain of the correct answer — give grounded and hallucination-free answers.
 
 1. Read the issue/error message and identify the symptom
 2. Run `git log --oneline -20` and `git blame` on the suspected file — establish when the regression was introduced and by what change
@@ -45,10 +45,10 @@ Entry: `file.ts:123` functionName()
       → potential issue here
 ```
 
-5. Find related test files that cover this area
-6. Verify each assumption with actual code inspection
+6. Find related test files that cover this area
+7. Verify each assumption with actual code inspection
 
-Evidence-based reasoning only. Every claim must reference specific file:line.
+Evidence-based reasoning only. Every claim must reference specific file:line. Never use placeholders or guess missing details — use tools to discover them.
 </investigate_before_answering>
 
 <analysis_approach>
@@ -80,19 +80,48 @@ If fix doesn't work, revert completely before trying next approach. Never layer
 </test_driven_validation>
 
 <no_fallbacks_or_workarounds>
-Implement a robust fix that addresses the actual root cause. Do not:
-- Add defensive fallbacks that mask problems (e.g., `|| defaultValue`)
-- Hard-code values for the specific failing case
-- Suppress errors without resolving the cause
-- Use optional chaining (?.) to bypass null when null is the bug
+Write a high-quality, general-purpose solution that addresses the actual root cause.
+
+Do not create helper scripts or workarounds to accomplish the task more efficiently.
+Do not hard-code values or create solutions that only work for specific failing cases.
+Instead, implement the actual logic that solves the problem generally.
+
+Workaround indicators (if you catch yourself doing any of these, STOP):
+- Adding `|| defaultValue` to mask null/undefined
+- Adding `try/catch` that swallows errors silently
+- Using optional chaining (?.) to bypass null when null IS the bug
+- Hard-coding a value for the specific failing case
+- Adding a "just in case" check that shouldn't be needed
+- Suppressing warnings/errors instead of fixing them
+- Adding retry logic instead of fixing why it fails
 
 Instead:
 - Fix the code path that produces incorrect state
-- Ensure solution works for all valid inputs
-- Follow codebase's existing patterns
+- Ensure solution works correctly for all valid inputs, not just the failing case
+- Follow codebase's existing patterns and idioms
 - Escalate blockers rather than shipping fragile patches
+
+If the task is unreasonable or infeasible, or if any of the tests are incorrect, inform the user rather than working around them. The solution should be robust, maintainable, and extendable.
 </no_fallbacks_or_workarounds>
 
+<code_quality_standards>
+Every fix must be **production-grade**. This is not a prototype — treat every fix as code that ships to real users at scale.
+
+**Non-negotiable standards**:
+- **Root cause fixes only** — never workarounds, never "good enough for now"
+- **Graceful error handling** — errors are caught, surfaced to the user with actionable context, and logged. No silent swallowing. No raw stack traces in UI. Every failure path has a recovery or clear error state.
+- **Robust edge case coverage** — handle nulls, empty states, concurrent access, network failures, partial data, and boundary conditions. If it can happen in production, handle it.
+- **Optimized for performance** — no unnecessary re-renders, no N+1 queries, no unbounded loops, no blocking I/O on hot paths.
+- **Scalable patterns** — solutions must work at 10x the current load. Avoid patterns that degrade with data size (O(n²) where O(n) is possible, in-memory aggregation of unbounded datasets, missing pagination).
+- **Best practice adherence** — follow the language/framework idioms of the codebase. Use established patterns over novel approaches. Leverage the type system.
+- **Clean interfaces** — clear contracts between modules. No leaky abstractions. Inputs validated at boundaries. Return types are explicit, not `any`.
+- **Defensive but not paranoid** — validate external inputs rigorously, trust internal interfaces. Don't add guards for impossible states — instead, make impossible states unrepresentable through types.
+</code_quality_standards>
+
+<commit_to_approach>
+When deciding how to approach a problem, choose an approach and commit to it. Avoid revisiting decisions unless you encounter new information that directly contradicts your reasoning. If you're weighing two approaches, pick the one with stronger evidence and see it through. Do not oscillate between strategies — diagnose, decide, execute.
+</commit_to_approach>
+
 <use_parallel_tool_calls>
 Read multiple potentially relevant files in parallel. If the issue might involve 3 modules, read all 3 simultaneously.
 </use_parallel_tool_calls>

package/config/skills/devlyn-team-resolve/SKILL.md

@@ -26,6 +26,10 @@ Every teammate should evaluate their findings and recommendations against these
 
 Before spawning any teammates, do your own investigation:
 
+<investigate_before_answering>
+Never speculate about code you have not opened. If the issue references a specific file, you MUST read the file before forming hypotheses. Make sure to investigate and read relevant files BEFORE classifying the issue or assembling a team. Never make any claims about code before investigating unless you are certain of the correct answer — give grounded and hallucination-free answers. Never use placeholders or guess missing details — use tools to discover them.
+</investigate_before_answering>
+
 1. Read the issue/task description carefully
 2. Read relevant files and error logs in parallel (use parallel tool calls)
 3. Trace the initial code path from entry point to likely source
@@ -479,7 +483,11 @@ Present the synthesis to the user before implementing.
 ## Phase 5: IMPLEMENTATION (You, Team Lead)
 
 <no_workarounds>
-Every fix must address the root cause. Do not implement workarounds.
+Write a high-quality, general-purpose solution that addresses the actual root cause. Do not implement workarounds.
+
+Do not create helper scripts or workarounds to accomplish the task more efficiently.
+Do not hard-code values or create solutions that only work for specific failing cases.
+Instead, implement the actual logic that solves the problem generally.
 
 Workaround indicators (if you catch yourself doing any of these, STOP):
 - Adding `|| defaultValue` to mask null/undefined
@@ -490,6 +498,8 @@ Workaround indicators (if you catch yourself doing any of these, STOP):
 - Suppressing warnings/errors instead of fixing them
 - Adding retry logic instead of fixing why it fails
 
+If the task is unreasonable or infeasible, or if any of the tests are incorrect, inform the user rather than working around them. The solution should be robust, maintainable, and extendable.
+
 If the true fix requires significant refactoring:
 1. Document why in the root cause analysis
 2. Call the `EnterPlanMode` tool to present the scope to the user and get approval before proceeding
@@ -497,6 +507,10 @@ If the true fix requires significant refactoring:
 4. Never ship a workaround "for now"
 </no_workarounds>
 
+<commit_to_approach>
+When deciding how to approach a problem, choose an approach and commit to it. Avoid revisiting decisions unless you encounter new information that directly contradicts your reasoning. If you're weighing two approaches, pick the one with stronger evidence and see it through. Do not oscillate between strategies — diagnose, decide, execute.
+</commit_to_approach>
+
 Implementation order:
 1. Write a failing test based on the Test Engineer's findings
 2. Implement the fix addressing the true root cause

package/config/skills/root-cause-analysis/SKILL.md

@@ -34,7 +34,7 @@ Continue until you reach something **actionable** — a code change that prevent
 
 ## Evidence Standards
 
-Every claim MUST reference a specific `file:line`. No speculation about code you haven't read.
+Every claim MUST reference a specific `file:line`. Never speculate about code you have not opened. Never make any claims about code before investigating unless you are certain of the correct answer — give grounded and hallucination-free answers. Never use placeholders or guess missing details — use tools to discover them.
 
 1. Read the actual code before forming hypotheses
 2. Trace the execution path: entry → intermediate calls → issue location
@@ -44,6 +44,8 @@ Every claim MUST reference a specific `file:line`. No speculation about code you
 
 ## No-Workaround Rule
 
+Write a high-quality, general-purpose solution that addresses the actual root cause. Do not create helper scripts or workarounds. Do not hard-code values or create solutions that only work for specific failing cases. Instead, implement the actual logic that solves the problem generally.
+
 Every fix MUST address the root cause. Stop immediately if you catch yourself:
 
 - Adding `|| defaultValue` to mask null/undefined
@@ -54,6 +56,8 @@ Every fix MUST address the root cause. Stop immediately if you catch yourself:
 - Suppressing warnings/errors instead of fixing them
 - Adding retry logic instead of fixing why it fails
 
+If the task is unreasonable or infeasible, or if any of the tests are incorrect, inform the user rather than working around them. The solution should be robust, maintainable, and extendable.
+
 If the real fix requires significant refactoring, present the scope to the user — never ship a workaround "for now".
 
 ## Routing

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "devlyn-cli",
-  "version": "0.7.0",
+  "version": "0.7.1",
   "description": "Claude Code configuration toolkit for teams",
   "bin": {
     "devlyn": "bin/devlyn.js"