devlyn-cli 0.6.0 → 0.7.1

package/CLAUDE.md

@@ -28,16 +28,16 @@ When investigating bugs, analyzing features, or exploring code:
    - Remaining unknowns
    - Recommended next steps
 
-For complex investigations, use `/devlyn.team-resolve` to assemble a multi-perspective investigation team, or spawn parallel Task agents to explore different areas simultaneously.
+For complex investigations, use `/devlyn:team-resolve` to assemble a multi-perspective investigation team, or spawn parallel Task agents to explore different areas simultaneously.
 
 ## UI/UX Workflow
 
 The full design-to-implementation pipeline:
 
-1. `/devlyn.design-ui` → Generate 5 style explorations
-2. `/devlyn.design-system [N]` → Extract tokens from chosen style
-3. `/devlyn.implement-ui` → Team implements or improves UI from design system
-4. `/devlyn.team-resolve [feature]` → Add features on top
+1. `/devlyn:design-ui` → Generate 5 style explorations
+2. `/devlyn:design-system [N]` → Extract tokens from chosen style
+3. `/devlyn:implement-ui` → Team implements or improves UI from design system
+4. `/devlyn:team-resolve [feature]` → Add features on top
 
 ## Feature Development
 
@@ -54,31 +54,31 @@ The recommended sequence after writing code:
 
 1. **Write code** (vibe coding)
 2. `/simplify` → Quick cleanup pass (reuse, quality, efficiency)
-3. `/devlyn.review` → Thorough solo review with security-first checklist
-4. `/devlyn.team-review` → Multi-perspective team review (for important PRs)
-5. `/devlyn.clean` → Periodic codebase-wide hygiene
-6. `/devlyn.update-docs` → Keep docs in sync
+3. `/devlyn:review` → Thorough solo review with security-first checklist
+4. `/devlyn:team-review` → Multi-perspective team review (for important PRs)
+5. `/devlyn:clean` → Periodic codebase-wide hygiene
+6. `/devlyn:update-docs` → Keep docs in sync
 
-Steps 4-6 are optional depending on the scope of changes. `/simplify` should always run before `/devlyn.review` to catch low-hanging fruit cheaply.
+Steps 4-6 are optional depending on the scope of changes. `/simplify` should always run before `/devlyn:review` to catch low-hanging fruit cheaply.
 
 ## Documentation Workflow
 
-- **Sync docs with codebase**: Use `/devlyn.update-docs` to clean up stale content, update outdated info, and generate missing docs
-- **Focused doc update**: Use `/devlyn.update-docs [area]` for targeted updates (e.g., "API reference", "getting-started")
+- **Sync docs with codebase**: Use `/devlyn:update-docs` to clean up stale content, update outdated info, and generate missing docs
+- **Focused doc update**: Use `/devlyn:update-docs [area]` for targeted updates (e.g., "API reference", "getting-started")
 - Preserves all forward-looking content: roadmaps, future plans, visions, open questions
 - If no docs exist, proposes a tailored docs structure and generates initial content
 
 ## Debugging Workflow
 
-- **Simple bugs**: Use `/devlyn.resolve` for systematic bug fixing with test-driven validation
-- **Complex bugs**: Use `/devlyn.team-resolve` for multi-perspective investigation with a full agent team
-- **Post-fix review**: Use `/devlyn.team-review` for thorough multi-reviewer validation
+- **Simple bugs**: Use `/devlyn:resolve` for systematic bug fixing with test-driven validation
+- **Complex bugs**: Use `/devlyn:team-resolve` for multi-perspective investigation with a full agent team
+- **Post-fix review**: Use `/devlyn:team-review` for thorough multi-reviewer validation
 
 ## Maintenance Workflow
 
-- **Codebase cleanup**: Use `/devlyn.clean` to detect and remove dead code, unused dependencies, complexity hotspots, and tech debt
-- **Focused cleanup**: Use `/devlyn.clean [category]` for targeted sweeps (dead code, deps, tests, complexity, hygiene)
-- **Periodic maintenance sequence**: `/devlyn.clean` → `/simplify` → `/devlyn.update-docs` → `/devlyn.review`
+- **Codebase cleanup**: Use `/devlyn:clean` to detect and remove dead code, unused dependencies, complexity hotspots, and tech debt
+- **Focused cleanup**: Use `/devlyn:clean [category]` for targeted sweeps (dead code, deps, tests, complexity, hygiene)
+- **Periodic maintenance sequence**: `/devlyn:clean` → `/simplify` → `/devlyn:update-docs` → `/devlyn:review`
 
 ## Context Window Management
 

package/README.md

@@ -68,46 +68,46 @@ your-project/
 
 ## Commands
 
-Slash commands are invoked directly in Claude Code conversations (e.g., type `/devlyn.resolve`).
+Slash commands are invoked directly in Claude Code conversations (e.g., type `/devlyn:resolve`).
 
 ### Debugging & Resolution
 
 | Command | Description |
 |---|---|
-| `/devlyn.resolve` | Systematic bug fixing with root-cause analysis and test-driven validation |
-| `/devlyn.team-resolve` | Spawns a full agent team — root cause analyst, test engineer, security auditor — to investigate complex issues |
+| `/devlyn:resolve` | Systematic bug fixing with root-cause analysis and test-driven validation |
+| `/devlyn:team-resolve` | Spawns a full agent team — root cause analyst, test engineer, security auditor — to investigate complex issues |
 
 ### Code Review & Quality
 
 | Command | Description |
 |---|---|
-| `/devlyn.review` | Post-implementation review — security, quality, best practices checklist |
-| `/devlyn.team-review` | Multi-perspective team review with specialized reviewers (security, quality, testing, performance, product) |
-| `/devlyn.clean` | Detect and remove dead code, unused dependencies, complexity hotspots, and tech debt |
+| `/devlyn:review` | Post-implementation review — security, quality, best practices checklist |
+| `/devlyn:team-review` | Multi-perspective team review with specialized reviewers (security, quality, testing, performance, product) |
+| `/devlyn:clean` | Detect and remove dead code, unused dependencies, complexity hotspots, and tech debt |
 
 ### UI Design & Implementation
 
 | Command | Description |
 |---|---|
-| `/devlyn.design-ui` | Generate 5 radically distinct UI style explorations from a spec or reference image |
-| `/devlyn.team-design-ui` | Spawns a design team — creative director, product designer, visual designer, interaction designer, accessibility designer |
-| `/devlyn.design-system` | Extract design system tokens from a chosen style for exact reproduction |
-| `/devlyn.implement-ui` | Team-based UI build — component architect, UX engineer, accessibility engineer, responsive engineer, visual QA |
+| `/devlyn:design-ui` | Generate 5 radically distinct UI style explorations from a spec or reference image |
+| `/devlyn:team-design-ui` | Spawns a design team — creative director, product designer, visual designer, interaction designer, accessibility designer |
+| `/devlyn:design-system` | Extract design system tokens from a chosen style for exact reproduction |
+| `/devlyn:implement-ui` | Team-based UI build — component architect, UX engineer, accessibility engineer, responsive engineer, visual QA |
 
 ### Product & Planning
 
 | Command | Description |
 |---|---|
-| `/devlyn.product-spec` | Generate or incrementally update product spec documents |
-| `/devlyn.feature-spec` | Transform product specs into implementable feature specifications |
-| `/devlyn.discover-product` | Scan codebase to generate feature-oriented product documentation |
-| `/devlyn.recommend-features` | Prioritize top 5 features to build next based on value and readiness |
+| `/devlyn:product-spec` | Generate or incrementally update product spec documents |
+| `/devlyn:feature-spec` | Transform product specs into implementable feature specifications |
+| `/devlyn:discover-product` | Scan codebase to generate feature-oriented product documentation |
+| `/devlyn:recommend-features` | Prioritize top 5 features to build next based on value and readiness |
 
 ### Documentation
 
 | Command | Description |
 |---|---|
-| `/devlyn.update-docs` | Sync all project docs with current codebase — cleans stale content, preserves roadmaps, generates missing docs |
+| `/devlyn:update-docs` | Sync all project docs with current codebase — cleans stale content, preserves roadmaps, generates missing docs |
 
 ## Skills
 
@@ -131,18 +131,18 @@ The full fix → polish → review → maintain cycle:
 
 | Step | Command | What It Does |
 |---|---|---|
-| 1. **Resolve** | `/devlyn.resolve` or `/devlyn.team-resolve` | Fix the issue — solo for focused bugs (1-2 modules), team for complex issues (3+ modules) |
+| 1. **Resolve** | `/devlyn:resolve` or `/devlyn:team-resolve` | Fix the issue — solo for focused bugs (1-2 modules), team for complex issues (3+ modules) |
 | 2. **Simplify** | `/simplify` | Quick cleanup pass for reuse, quality, and efficiency *(built-in Claude Code command)* |
-| 3. **Review** | `/devlyn.review` or `/devlyn.team-review` | Audit the changes — solo for small PRs (< 10 files), team for large PRs (10+ files) |
+| 3. **Review** | `/devlyn:review` or `/devlyn:team-review` | Audit the changes — solo for small PRs (< 10 files), team for large PRs (10+ files) |
 | | | *If the review finds issues, loop back to step 1* |
-| 4. **Clean** | `/devlyn.clean` | Remove dead code, unused dependencies, and complexity hotspots |
-| 5. **Document** | `/devlyn.update-docs` | Sync project documentation with the current codebase |
+| 4. **Clean** | `/devlyn:clean` | Remove dead code, unused dependencies, and complexity hotspots |
+| 5. **Document** | `/devlyn:update-docs` | Sync project documentation with the current codebase |
 
 Steps 4-5 are optional — run them periodically rather than on every PR. Steps 1-3 are the core loop.
 
-> **Tip:** Consider running `/devlyn.review` once more after steps 4-5. `/devlyn.clean` removes code and `/devlyn.update-docs` changes docs — a final review pass catches accidental regressions from cleanup.
+> **Tip:** Consider running `/devlyn:review` once more after steps 4-5. `/devlyn:clean` removes code and `/devlyn:update-docs` changes docs — a final review pass catches accidental regressions from cleanup.
 
-> **Scope matching matters.** For a simple one-file bug, `/devlyn.resolve` + `/devlyn.review` (solo) is fast. For a multi-module feature, `/devlyn.team-resolve` + `/devlyn.team-review` (team) gives you parallel specialist perspectives. Don't over-tool simple changes.
+> **Scope matching matters.** For a simple one-file bug, `/devlyn:resolve` + `/devlyn:review` (solo) is fast. For a multi-module feature, `/devlyn:team-resolve` + `/devlyn:team-review` (team) gives you parallel specialist perspectives. Don't over-tool simple changes.
 
 ### UI Design Pipeline
 
@@ -150,11 +150,11 @@ A full explore → extract → build pipeline:
 
 | Step | Command | What It Does |
 |---|---|---|
-| 1. **Explore** | `/devlyn.design-ui` | Generates 5 radically distinct style options from a spec or reference image |
-| 2. **Extract** | `/devlyn.design-system` | Pulls exact design tokens (colors, spacing, typography) from your chosen style |
-| 3. **Build** | `/devlyn.implement-ui` | Spawns a build team (component architect, UX engineer, accessibility engineer, responsive engineer, visual QA) |
+| 1. **Explore** | `/devlyn:design-ui` | Generates 5 radically distinct style options from a spec or reference image |
+| 2. **Extract** | `/devlyn:design-system` | Pulls exact design tokens (colors, spacing, typography) from your chosen style |
+| 3. **Build** | `/devlyn:implement-ui` | Spawns a build team (component architect, UX engineer, accessibility engineer, responsive engineer, visual QA) |
 
-> For design exploration with a full creative team, use `/devlyn.team-design-ui` instead of step 1.
+> For design exploration with a full creative team, use `/devlyn:team-design-ui` instead of step 1.
 
 After building, follow the [recommended workflow](#recommended-workflow) starting from step 2 (simplify) to review and polish the implementation.
 
@@ -164,12 +164,12 @@ These commands work independently, outside of the main workflow:
 
 | Command | What It Does |
 |---|---|
-| `/devlyn.clean [focus]` | Focused cleanup — e.g., `/devlyn.clean dependencies` or `/devlyn.clean dead-code` |
-| `/devlyn.update-docs [area]` | Focused doc sync — e.g., `/devlyn.update-docs API reference` |
-| `/devlyn.product-spec` | Generate or update a product specification |
-| `/devlyn.feature-spec` | Transform a product spec into an implementable feature spec |
-| `/devlyn.discover-product` | Scan codebase to auto-generate product documentation |
-| `/devlyn.recommend-features` | Prioritize top 5 features to build next |
+| `/devlyn:clean [focus]` | Focused cleanup — e.g., `/devlyn:clean dependencies` or `/devlyn:clean dead-code` |
+| `/devlyn:update-docs [area]` | Focused doc sync — e.g., `/devlyn:update-docs API reference` |
+| `/devlyn:product-spec` | Generate or update a product specification |
+| `/devlyn:feature-spec` | Transform a product spec into an implementable feature spec |
+| `/devlyn:discover-product` | Scan codebase to auto-generate product documentation |
+| `/devlyn:recommend-features` | Prioritize top 5 features to build next |
 
 ## Optional Skills & Packs
 
@@ -205,7 +205,7 @@ Installed via the [skills CLI](https://github.com/anthropics/skills) (`npx skill
 1. **Run `npx devlyn-cli`** in your project root
 2. The CLI copies config files into `.claude/` and `CLAUDE.md` to the project root
 3. Claude Code automatically reads `.claude/commands/` and `.claude/skills/` on startup
-4. Invoke commands like `/devlyn.resolve` in your Claude Code session — skills activate on their own
+4. Invoke commands like `/devlyn:resolve` in your Claude Code session — skills activate on their own
 
 The installation is **idempotent** — run it again anytime to update to the latest config.
 

package/config/skills/code-health-standards/SKILL.md

@@ -8,7 +8,7 @@ Standards for keeping codebases lean and maintainable. Apply these thresholds du
 - Adding dependencies
 - Creating new files or modules
 - Refactoring or restructuring code
-- Any use of `/devlyn.clean`, `/devlyn.resolve`, or `/devlyn.review`
+- Any use of `/devlyn:clean`, `/devlyn:resolve`, or `/devlyn:review`
 
 ## Dead Code Prevention
 
@@ -70,5 +70,5 @@ Code committed to production should not contain:
 
 ## Routing
 
-- **Active cleanup**: Use `/devlyn.clean` to scan and remove accumulated debt
-- **Focused cleanup**: Use `/devlyn.clean [category]` for targeted sweeps (dead code, deps, tests, complexity, hygiene)
+- **Active cleanup**: Use `/devlyn:clean` to scan and remove accumulated debt
+- **Focused cleanup**: Use `/devlyn:clean [category]` for targeted sweeps (dead code, deps, tests, complexity, hygiene)

package/config/skills/code-review-standards/SKILL.md

@@ -7,7 +7,7 @@ Severity framework and quality bar for reviewing code changes. Apply this framew
 - Post-implementation review
 - Code review requests
 - PR review or diff analysis
-- Any use of `/devlyn.review` or `/devlyn.team-review`
+- Any use of `/devlyn:review` or `/devlyn:team-review`
 
 ## Severity Framework
 
@@ -60,5 +60,5 @@ Severity framework and quality bar for reviewing code changes. Apply this framew
 
 ## Routing
 
-- **Quick review** (few files, straightforward changes): Use `/devlyn.review`
-- **Thorough review** (many files, security-sensitive, user-facing): Use `/devlyn.team-review` for multi-perspective coverage
+- **Quick review** (few files, straightforward changes): Use `/devlyn:review`
+- **Thorough review** (many files, security-sensitive, user-facing): Use `/devlyn:team-review` for multi-perspective coverage

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

@@ -15,7 +15,7 @@ $ARGUMENTS
 </user_input>
 
 <escalation>
-If the cleanup reveals deeply intertwined architectural debt — circular dependencies, god objects woven into multiple systems, or patterns that can't be safely removed without redesigning interfaces — escalate to `/devlyn.team-resolve` with your findings so a multi-perspective team can plan the refactor.
+If the cleanup reveals deeply intertwined architectural debt — circular dependencies, god objects woven into multiple systems, or patterns that can't be safely removed without redesigning interfaces — escalate to `/devlyn:team-resolve` with your findings so a multi-perspective team can plan the refactor.
 </escalation>
 
 <process>
@@ -221,7 +221,7 @@ Present the final summary:
 
 ### Recommendations
 - {Any follow-up actions needed}
-- Schedule: run `/devlyn.clean` periodically to prevent debt accumulation
+- Schedule: run `/devlyn:clean` periodically to prevent debt accumulation
 ```
 
 </process>
@@ -230,7 +230,7 @@ Present the final summary:
 
 ## Handling Focus Area Arguments
 
-If the user provides a focus area (e.g., `/devlyn.clean dependencies` or `/devlyn.clean tests`):
+If the user provides a focus area (e.g., `/devlyn:clean dependencies` or `/devlyn:clean tests`):
 
 1. Still run Phase 1 (codebase understanding) at reduced depth
 2. In Phase 2, only run the relevant analysis category:
@@ -266,7 +266,7 @@ When in doubt, classify as P3 (flagged) rather than P0 (auto-remove).
 
 ### Example 1: Small project cleanup
 
-Input: `/devlyn.clean`
+Input: `/devlyn:clean`
 
 Finds: 2 orphan files, 3 unused deps, 8 console.logs, 1 stale test.
 
@@ -278,7 +278,7 @@ Tests pass. 340 lines removed.
 
 ### Example 2: Focused dependency cleanup
 
-Input: `/devlyn.clean deps`
+Input: `/devlyn:clean deps`
 
 Scans only dependency hygiene. Finds `moment` (replaced by `dayjs` already in use), `lodash` (only `_.get` used — replaceable with optional chaining). Presents targeted plan.
 

package/config/skills/devlyn-design-ui/SKILL.md

@@ -7,7 +7,7 @@ source: project
 You are the **Lead Designer** with full creative authority. Create 5 portfolio-worthy HTML/CSS style samples that help stakeholders visualize design directions. These aren't mockups—they're design statements.
 
 <escalation>
-If the design task requires multi-perspective exploration (brand strategy + interaction design + accessibility + visual craft all mattering equally), consider escalating to `/devlyn.team-design-ui` for a full 5-person design team.
+If the design task requires multi-perspective exploration (brand strategy + interaction design + accessibility + visual craft all mattering equally), consider escalating to `/devlyn:team-design-ui` for a full 5-person design team.
 </escalation>
 
 <context>
@@ -347,5 +347,5 @@ Make bold choices. Each design should be portfolio-worthy—something you'd prou
 
 <next_step>
 After the user picks a style, suggest:
-→ Run `/devlyn.design-system [style-number]` to extract design tokens from the chosen style into a reusable design system reference.
+→ Run `/devlyn:design-system [style-number]` to extract design tokens from the chosen style into a reusable design system reference.
 </next_step>

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

@@ -459,7 +459,7 @@ Present the evaluation in this format:
 - [Explicitly call out things done well — balanced feedback prevents over-correction]
 
 ### Recommendation
-[Next action — e.g., "Fix the 3 CRITICAL issues, then run `/devlyn.team-review` for a full review" or "Ship it"]
+[Next action — e.g., "Fix the 3 CRITICAL issues, then run `/devlyn:team-review` for a full review" or "Ship it"]
 
 </evaluation_report>
 </output_format>

package/config/skills/devlyn-implement-ui/SKILL.md

@@ -13,9 +13,9 @@ This command expects a design system at `docs/design-system.md`. If it doesn't e
 ```
 No design system found at docs/design-system.md
 Run the pipeline first:
-  1. /devlyn.design-ui → Generate style explorations
-  2. /devlyn.design-system [style-number] → Extract design tokens
-  3. /devlyn.implement-ui → Build/improve UI (this command)
+  1. /devlyn:design-ui → Generate style explorations
+  2. /devlyn:design-system [style-number] → Extract design tokens
+  3. /devlyn:implement-ui → Build/improve UI (this command)
 ```
 </prerequisites>
 
@@ -459,8 +459,8 @@ Present the result in this format:
 - [ ] Semantic HTML throughout
 
 ### Next Steps
-- Run `/devlyn.team-review` to validate code quality
-- Run `/devlyn.team-resolve [feature]` to add features on top of this UI
+- Run `/devlyn:team-review` to validate code quality
+- Run `/devlyn:team-resolve [feature]` to add features on top of this UI
 
 </team_build_summary>
 </output_format>

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

@@ -20,7 +20,7 @@ When in doubt, enter plan mode.
 </default_to_plan_mode>
 
 <escalation>
-Escalate to `/devlyn.team-resolve` if ANY of the following are true:
+Escalate to `/devlyn:team-resolve` if ANY of the following are true:
 - Investigation reveals the issue spans 3+ modules
 - Root cause is unclear after applying 5 Whys to all plausible hypotheses
 - Competing hypotheses can't be ruled out without parallel investigation
@@ -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>
@@ -64,7 +64,7 @@ Choose the right technique based on the issue:
 1. **[Hypothesis A]** — Evidence for: [...] Evidence against: [...]
 2. **[Hypothesis B]** — Evidence for: [...] Evidence against: [...]
 - Rule out hypotheses by reading the code — do not guess
-- If hypotheses can't be ruled out solo, escalate to `/devlyn.team-resolve`
+- If hypotheses can't be ruled out solo, escalate to `/devlyn:team-resolve`
 </analysis_approach>
 
 <test_driven_validation>
@@ -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>
@@ -154,5 +183,5 @@ Analysis:
 2. In plan mode, present fix options if multiple valid solutions exist
 3. Write failing test before implementing
 4. Only mark complete after full test suite passes
-5. If stuck after 2 hypothesis attempts → escalate to `/devlyn.team-resolve`
+5. If stuck after 2 hypothesis attempts → escalate to `/devlyn:team-resolve`
 </next_steps>

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

@@ -5,7 +5,7 @@ You are a Senior Code Reviewer. You review with a security-first mindset, fix is
 Perform a comprehensive post-implementation review. After receiving tool results, carefully reflect on their quality and determine optimal next steps before proceeding.
 
 <escalation>
-If the changeset is large (10+ files), touches multiple domains (UI + API + auth), or requires multi-perspective judgment, escalate to `/devlyn.team-review` instead of solo review.
+If the changeset is large (10+ files), touches multiple domains (UI + API + auth), or requires multi-perspective judgment, escalate to `/devlyn:team-review` instead of solo review.
 </escalation>
 
 <procedure>
@@ -15,7 +15,7 @@ If the changeset is large (10+ files), touches multiple domains (UI + API + auth
 4. Fix issues directly — do not just suggest fixes
 5. Run linter (`npm run lint` or equivalent) and fix all reported lint issues
 6. Run test suite to verify changes don't break existing functionality
-7. If lint or tests fail → use `/devlyn.resolve` workflow to fix, then re-run
+7. If lint or tests fail → use `/devlyn:resolve` workflow to fix, then re-run
 8. Generate summary report with file:line references
 9. Block approval if any CRITICAL or HIGH issues remain unfixed OR tests fail
 </procedure>

package/config/skills/devlyn-team-design-ui/SKILL.md

@@ -1,8 +1,8 @@
-Assemble a world-class design team to generate 5 radically distinct, portfolio-worthy UI style explorations. Like `/devlyn.design-ui` but powered by a full team of design specialists — Creative Director, Product Designer, Visual Designer, Interaction Designer, and Accessibility Designer — who collaborate to produce 5 stunning HTML design samples that go far beyond what a single designer could achieve.
+Assemble a world-class design team to generate 5 radically distinct, portfolio-worthy UI style explorations. Like `/devlyn:design-ui` but powered by a full team of design specialists — Creative Director, Product Designer, Visual Designer, Interaction Designer, and Accessibility Designer — who collaborate to produce 5 stunning HTML design samples that go far beyond what a single designer could achieve.
 
 This is design exploration only. After the user picks a style:
-→ `/devlyn.design-system [N]` to extract tokens
-→ `/devlyn.implement-ui` to build it
+→ `/devlyn:design-system [N]` to extract tokens
+→ `/devlyn:implement-ui` to build it
 
 <brief>
 $ARGUMENTS
@@ -677,6 +677,6 @@ After all 5 HTML files are generated:
 
 <next_step>
 After the user picks a style, suggest:
-→ Run `/devlyn.design-system [style-number]` to extract design tokens from the chosen style into a reusable design system reference.
-→ Then run `/devlyn.implement-ui` to build the production UI from that design system.
+→ Run `/devlyn:design-system [style-number]` to extract design tokens from the chosen style into a reusable design system reference.
+→ Then run `/devlyn:implement-ui` to build the production UI from that design system.
 </next_step>

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
@@ -564,7 +578,7 @@ Present findings in this format:
 - [ ] Manual verification (if applicable)
 
 ### Recommendation
-Run `/devlyn.team-review` to validate the fix meets all quality standards with a full multi-perspective review.
+Run `/devlyn:team-review` to validate the fix meets all quality standards with a full multi-perspective review.
 
 </team_resolution>
 </output_format>

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

@@ -418,7 +418,7 @@ After receiving all reviewer findings:
 After all fixes are applied:
 
 1. Run the full test suite
-2. If tests fail → chain to `/devlyn.team-resolve` for the failing tests
+2. If tests fail → chain to `/devlyn:team-resolve` for the failing tests
 3. Re-read fixed files to verify fixes didn't introduce new issues
 4. Generate the final review summary
 
@@ -468,7 +468,7 @@ Present the final review in this format:
 - [MEDIUM/severity] description — [concrete reason for deferral]
 
 ### Recommendation
-If any issues were deferred or if the fix was complex, consider running `/devlyn.team-resolve` on the specific concern for deeper analysis.
+If any issues were deferred or if the fix was complex, consider running `/devlyn:team-resolve` on the specific concern for deeper analysis.
 
 </team_review_summary>
 </output_format>

package/config/skills/devlyn-update-docs/SKILL.md

@@ -220,7 +220,7 @@ Present the summary:
 ### Recommendations
 - {Any manual follow-up needed}
 - {Docs that would benefit from human review or expansion}
-- Suggestion: run `/devlyn.update-docs` periodically to keep docs in sync
+- Suggestion: run `/devlyn:update-docs` periodically to keep docs in sync
 ```
 
 </process>
@@ -239,7 +239,7 @@ Suggest structure based on project type:
 ```yaml
 web_app:
   docs/
-    - product-spec.md         # Product specification (suggest /devlyn.product-spec)
+    - product-spec.md         # Product specification (suggest /devlyn:product-spec)
     - architecture.md         # System architecture and tech decisions
     - getting-started.md      # Developer setup guide
     - deployment.md           # Deployment instructions
@@ -282,13 +282,13 @@ docs/
 └── {file4}.md    — {purpose}
 
 ### Generation Plan
-- `product-spec.md` → I recommend running `/devlyn.product-spec` separately for this
+- `product-spec.md` → I recommend running `/devlyn:product-spec` separately for this
 - `{other docs}` → I'll generate from codebase analysis
 
 Create this documentation structure?
 ```
 
-Wait for user approval, then generate initial content for each approved doc by scanning the codebase. For product specs and feature specs, recommend the dedicated commands (`/devlyn.product-spec`, `/devlyn.feature-spec`) rather than generating them inline.
+Wait for user approval, then generate initial content for each approved doc by scanning the codebase. For product specs and feature specs, recommend the dedicated commands (`/devlyn:product-spec`, `/devlyn:feature-spec`) rather than generating them inline.
 
 </no_docs_mode>
 
@@ -400,7 +400,7 @@ Read the team config at ~/.claude/teams/{team-name}/config.json to discover team
 
 ## Handling Focus Area Arguments
 
-If the user provides a focus area (e.g., `/devlyn.update-docs API docs` or `/devlyn.update-docs getting-started`):
+If the user provides a focus area (e.g., `/devlyn:update-docs API docs` or `/devlyn:update-docs getting-started`):
 
 1. Still run Phase 1 (codebase understanding) but at reduced depth — focus on the relevant area
 2. In Phase 2, only inventory docs related to the focus area
@@ -415,7 +415,7 @@ This enables quick, targeted doc updates without a full sync.
 
 ### Example 1: Small project with stale docs
 
-Input: `/devlyn.update-docs`
+Input: `/devlyn:update-docs`
 
 Phase 1-3 discovers:
 - 3 doc files: README.md, docs/api.md, docs/setup.md
@@ -434,7 +434,7 @@ Updates:
 
 ### Example 2: No docs at all
 
-Input: `/devlyn.update-docs`
+Input: `/devlyn:update-docs`
 
 No docs/ folder found. Project identified as a Next.js web app.
 
@@ -442,7 +442,7 @@ Plan:
 ```
 No documentation found. Proposed structure:
 docs/
-├── product-spec.md      -> Run /devlyn.product-spec to generate
+├── product-spec.md      -> Run /devlyn:product-spec to generate
 ├── architecture.md      -> System design overview (will generate)
 ├── getting-started.md   -> Dev setup guide (will generate)
 └── deployment.md        -> Deployment instructions (will generate)
@@ -450,13 +450,13 @@ docs/
 
 ### Example 3: Focused update
 
-Input: `/devlyn.update-docs API reference`
+Input: `/devlyn:update-docs API reference`
 
 Only inventories API-related docs. Updates endpoint signatures, request/response schemas, and auth requirements to match current code.
 
 ### Example 4: Large project triggering team mode
 
-Input: `/devlyn.update-docs`
+Input: `/devlyn:update-docs`
 
 Phase 4 discovers 14 doc files spanning API docs, user guides, architecture specs, and feature specs. Spawns 3-person team (codebase-analyst, doc-reviewer, content-organizer) for parallel analysis, then synthesizes findings into a comprehensive plan.
 

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

@@ -8,7 +8,7 @@ Standard methodology for investigating bugs, issues, and unexpected behavior. Ap
 - Error logs or stack traces need diagnosis
 - "Why does X happen?" or "What's causing X?" questions
 - Debugging sessions
-- Any use of `/devlyn.resolve` or `/devlyn.team-resolve`
+- Any use of `/devlyn:resolve` or `/devlyn:team-resolve`
 
 ## 5 Whys Protocol
 
@@ -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,9 +56,11 @@ 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
 
-- **Simple issue** (single file, obvious cause): Use `/devlyn.resolve`
-- **Complex issue** (multi-module, unclear cause, security implications): Use `/devlyn.team-resolve` for multi-perspective investigation
+- **Simple issue** (single file, obvious cause): Use `/devlyn:resolve`
+- **Complex issue** (multi-module, unclear cause, security implications): Use `/devlyn:team-resolve` for multi-perspective investigation

package/config/skills/ui-implementation-standards/SKILL.md

@@ -7,7 +7,7 @@ Quality framework for building and improving UI from design systems. Apply these
 - Building UI components or pages
 - Implementing designs from a design system
 - Improving or refactoring existing UI
-- Any use of `/devlyn.implement-ui`, `/devlyn.design-ui`, or `/devlyn.design-system`
+- Any use of `/devlyn:implement-ui`, `/devlyn:design-ui`, or `/devlyn:design-system`
 - Frontend development tasks involving visual design
 
 ## Design System Fidelity
@@ -69,6 +69,6 @@ Every interactive component or data-dependent view needs all states:
 
 ## Routing
 
-- **Build new UI or improve existing**: Use `/devlyn.implement-ui` for a full team approach
-- **Add features to existing UI**: Use `/devlyn.team-resolve` with the feature description
-- **Review UI code quality**: Use `/devlyn.team-review` for multi-perspective code review
+- **Build new UI or improve existing**: Use `/devlyn:implement-ui` for a full team approach
+- **Add features to existing UI**: Use `/devlyn:team-resolve` with the feature description
+- **Review UI code quality**: Use `/devlyn:team-review` for multi-perspective code review

package/config/skills/workflow-routing/SKILL.md

@@ -16,47 +16,47 @@ Match the user's current activity to the right command:
 ### Discovery & Planning
 | Situation | Command | Why |
 |-----------|---------|-----|
-| Need to understand what the project does | `/devlyn.discover-product` | Generates feature-oriented product documentation from code |
-| Need to define a new product | `/devlyn.product-spec` | Creates or updates product spec documents |
-| Need to plan a specific feature | `/devlyn.feature-spec` | Transforms product specs into implementable feature specs |
-| Need to decide what to build next | `/devlyn.recommend-features` | Prioritizes top 5 features by value and readiness |
+| Need to understand what the project does | `/devlyn:discover-product` | Generates feature-oriented product documentation from code |
+| Need to define a new product | `/devlyn:product-spec` | Creates or updates product spec documents |
+| Need to plan a specific feature | `/devlyn:feature-spec` | Transforms product specs into implementable feature specs |
+| Need to decide what to build next | `/devlyn:recommend-features` | Prioritizes top 5 features by value and readiness |
 
 ### Design
 | Situation | Command | Why |
 |-----------|---------|-----|
-| Need UI style exploration (solo) | `/devlyn.design-ui` | Generates 5 distinct style options |
-| Need team-based design exploration | `/devlyn.team-design-ui` | 5-person design team with diverse perspectives |
-| Need to extract design tokens | `/devlyn.design-system` | Converts chosen style into reusable token system |
-| Need to build or improve UI | `/devlyn.implement-ui` | Team-based UI implementation from design system |
+| Need UI style exploration (solo) | `/devlyn:design-ui` | Generates 5 distinct style options |
+| Need team-based design exploration | `/devlyn:team-design-ui` | 5-person design team with diverse perspectives |
+| Need to extract design tokens | `/devlyn:design-system` | Converts chosen style into reusable token system |
+| Need to build or improve UI | `/devlyn:implement-ui` | Team-based UI implementation from design system |
 
 ### Implementation & Debugging
 | Situation | Command | Why |
 |-----------|---------|-----|
-| Simple bug (single module, clear cause) | `/devlyn.resolve` | Solo root cause analysis with 5 Whys |
-| Complex bug (multi-module, unclear cause) | `/devlyn.team-resolve` | Multi-perspective investigation team |
-| Feature implementation on existing UI | `/devlyn.team-resolve [feature]` | Team approach for feature work |
+| Simple bug (single module, clear cause) | `/devlyn:resolve` | Solo root cause analysis with 5 Whys |
+| Complex bug (multi-module, unclear cause) | `/devlyn:team-resolve` | Multi-perspective investigation team |
+| Feature implementation on existing UI | `/devlyn:team-resolve [feature]` | Team approach for feature work |
 
 ### Review & Quality
 | Situation | Command | Why |
 |-----------|---------|-----|
-| Quick review (few files) | `/devlyn.review` | Solo review with severity framework |
-| Thorough review (many files, security-sensitive) | `/devlyn.team-review` | Multi-reviewer team coverage |
+| Quick review (few files) | `/devlyn:review` | Solo review with severity framework |
+| Thorough review (many files, security-sensitive) | `/devlyn:team-review` | Multi-reviewer team coverage |
 
 ### Maintenance
 | Situation | Command | Why |
 |-----------|---------|-----|
-| Remove dead code and tech debt | `/devlyn.clean` | 5-category codebase health analysis |
-| Targeted cleanup (deps, tests, etc.) | `/devlyn.clean [category]` | Focused sweep on one area |
-| Sync documentation with codebase | `/devlyn.update-docs` | Cleans stale content, preserves roadmaps |
-| Targeted doc update | `/devlyn.update-docs [area]` | Focused update on specific doc area |
+| Remove dead code and tech debt | `/devlyn:clean` | 5-category codebase health analysis |
+| Targeted cleanup (deps, tests, etc.) | `/devlyn:clean [category]` | Focused sweep on one area |
+| Sync documentation with codebase | `/devlyn:update-docs` | Cleans stale content, preserves roadmaps |
+| Targeted doc update | `/devlyn:update-docs [area]` | Focused update on specific doc area |
 
 ## Escalation Paths
 
 When a solo command isn't enough:
 
-- `/devlyn.resolve` → escalate to `/devlyn.team-resolve` if issue spans 3+ modules or root cause is unclear
-- `/devlyn.review` → escalate to `/devlyn.team-review` if changeset is 10+ files or touches multiple domains
-- `/devlyn.design-ui` → escalate to `/devlyn.team-design-ui` if design needs multi-perspective exploration
+- `/devlyn:resolve` → escalate to `/devlyn:team-resolve` if issue spans 3+ modules or root cause is unclear
+- `/devlyn:review` → escalate to `/devlyn:team-review` if changeset is 10+ files or touches multiple domains
+- `/devlyn:design-ui` → escalate to `/devlyn:team-design-ui` if design needs multi-perspective exploration
 
 ## Common Workflow Sequences
 

package/config/templates/prompt-templates.md

@@ -23,7 +23,7 @@ Start with the minimum viable solution, then improve if time allows.
 
 ## Debugging
 
-For systematic debugging, use `/devlyn.resolve [issue description]` which includes:
+For systematic debugging, use `/devlyn:resolve [issue description]` which includes:
 - Code path mapping
 - Hypothesis-driven analysis
 - Test-driven fix validation
@@ -61,7 +61,7 @@ have working, tested code ready for PR.
 For complex bugs that need autonomous resolution:
 
 ```
-/devlyn.resolve [bug description]
+/devlyn:resolve [bug description]
 
 After analysis, implement the fix autonomously:
 - Write failing test first

package/optional-skills/generate-skill/SKILL.md

@@ -124,7 +124,7 @@ After generating the skill, present:
 3. **Test invocation** — Example command to test the skill
 
 Offer to:
-- Run `/devlyn.review` on the generated skill for quality assurance
+- Run `/devlyn:review` on the generated skill for quality assurance
 - Run `pyx-scan` if the skill will be published
 
 ---

package/package.json

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