devlyn-cli 0.6.0 → 0.7.0

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
@@ -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>
@@ -154,5 +154,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

@@ -564,7 +564,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
 
@@ -58,5 +58,5 @@ If the real fix requires significant refactoring, present the scope to the user
 
 ## 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.0",
   "description": "Claude Code configuration toolkit for teams",
   "bin": {
     "devlyn": "bin/devlyn.js"