devlyn-cli 0.0.7 → 0.1.0

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

@@ -0,0 +1,70 @@
+# Root Cause Analysis
+
+Standard methodology for investigating bugs, issues, and unexpected behavior. Apply this framework whenever diagnosing a problem.
+
+## Trigger
+
+- User reports a bug or unexpected behavior
+- 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`
+
+## 5 Whys Protocol
+
+For every issue, trace from symptom to root cause:
+
+**Why 1**: Why did [symptom] happen?
+→ Because [cause 1]. Evidence: [file:line]
+
+**Why 2**: Why did [cause 1] happen?
+→ Because [cause 2]. Evidence: [file:line]
+
+**Why 3**: Why did [cause 2] happen?
+→ Because [cause 3]. Evidence: [file:line]
+
+Continue until you reach something **actionable** — a code change that prevents the entire chain.
+
+### Stop Criteria
+- You've reached a design decision or architectural choice that caused the issue
+- You've found a missing validation, wrong assumption, or incorrect logic
+- Further "whys" leave the codebase (external dependency, infrastructure)
+
+**NEVER stop at "the code does X"** — always ask WHY the code does X.
+
+## Evidence Standards
+
+Every claim MUST reference a specific `file:line`. No speculation about code you haven't read.
+
+1. Read the actual code before forming hypotheses
+2. Trace the execution path: entry → intermediate calls → issue location
+3. Check git blame for when/why the problematic code was introduced
+4. Find related tests that cover (or miss) the affected area
+5. Generate 2-3 hypotheses, each with supporting evidence
+
+## No-Workaround Rule
+
+Every fix MUST address the root cause. Stop immediately if you catch yourself:
+
+- Adding `|| defaultValue` to mask null/undefined
+- Adding `try/catch` that swallows errors silently
+- Using `?.` to skip over 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
+
+If the real fix requires significant refactoring, present the scope to the user — never ship a workaround "for now".
+
+## Test-Driven Validation
+
+1. Write a failing test that reproduces the issue
+2. Implement the fix
+3. Run the test — if it still fails, **revert completely** and try the next hypothesis
+4. Never layer fixes on top of failed attempts
+5. Run the full test suite for regressions
+
+## 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

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

@@ -0,0 +1,74 @@
+# UI Implementation Standards
+
+Quality framework for building and improving UI from design systems. Apply these standards whenever implementing or modifying visual components.
+
+## Trigger
+
+- 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`
+- Frontend development tasks involving visual design
+
+## Design System Fidelity
+
+When a design system exists at `docs/design-system.md`:
+
+- **Always use design tokens** — never hardcode color, spacing, typography, shadow, or motion values
+- **Match component patterns exactly** — structure, variants, hover/interactive states as defined
+- **Apply interactive states** — use exact easing, duration, and transform values from the design system
+- **Preserve design character** — maintain the theme, shape language, density, and energy defined in the system
+
+If a value isn't in the design system, derive it from existing tokens (e.g., a new spacing value should follow the spacing scale pattern).
+
+## Accessibility (Non-Negotiable)
+
+Every UI component must meet WCAG 2.1 AA:
+
+- **Semantic HTML first**: Use `nav`, `main`, `section`, `article`, `button`, `a` — not `div` for everything
+- **Color contrast**: Text on backgrounds must meet 4.5:1 (normal text) or 3:1 (large text). If design tokens fail contrast, adjust while staying close to design intent
+- **Keyboard navigation**: All interactive elements reachable and operable via keyboard. Logical focus order. Visible focus indicators
+- **Screen readers**: Meaningful alt text, ARIA labels for icon-only buttons, aria-live for dynamic content, heading hierarchy (h1→h2→h3, no skipping)
+- **Reduced motion**: Wrap all animations in `prefers-reduced-motion` media query. Decorative animations → remove. Functional animations → simplify to opacity-only
+- **Touch targets**: Minimum 44x44px for all interactive elements on touch devices
+
+## UI State Coverage
+
+Every interactive component or data-dependent view needs all states:
+
+| State | What to show | Common pattern |
+|-------|-------------|----------------|
+| Loading | Skeleton screens or contextual spinner | Skeleton preferred over spinner |
+| Empty | Illustration + descriptive message + CTA | Guide user to populate |
+| Error | Inline error with retry action | Never dead-end the user |
+| Success | Confirmation feedback | Toast, inline message, or redirect |
+| Disabled | Visually muted, cursor not-allowed | Explain why if possible |
+
+## Animation Quality
+
+- **Page load**: Orchestrated staggered reveals — vary `animation-delay` by 0.05-0.1s increments
+- **Scroll**: `IntersectionObserver` for scroll-triggered reveals (threshold 0.1)
+- **Hover**: Transform + shadow transitions, not just color. Use design system easing
+- **Transitions**: Custom `cubic-bezier` from design system, never default `ease` or `linear`
+- **Restraint**: One dramatic animation sequence beats many small ones. If everything moves, nothing stands out
+
+## Responsive Strategy (Web)
+
+- **Mobile-first**: Write base styles for mobile, override at larger breakpoints
+- **Fluid where possible**: Use `clamp()` for typography and spacing that scales smoothly
+- **Layout shifts**: Define how grids, navigation, and cards adapt at each breakpoint
+- **Touch adaptation**: Larger tap targets, adequate spacing, no hover-dependent interactions on mobile
+
+## Code Quality
+
+- Follow the project's existing patterns and conventions
+- Components should be composable and reusable
+- No inline styles — use the token/theme system
+- Server components where possible (Next.js), client components only for interactivity
+- Keep component files focused — one component per file
+
+## 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

package/package.json

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

package/config/skills/feature-gap-analysis/SKILL.md

@@ -1,111 +0,0 @@
-# Feature Gap Analysis Skill
-
-Use this skill to systematically identify missing features and functionality gaps in the codebase.
-
-## Trigger
-
-- "What features are missing?"
-- "Analyze gaps in [feature area]"
-- Feature comparison requests
-- "What should we build next?"
-
-## Workflow
-
-### Phase 1: Define Scope
-1. Identify the feature area to analyze
-2. Establish comparison baseline (competitor, spec, user needs)
-3. Define what "complete" means for this analysis
-
-### Phase 2: Parallel Analysis
-Spawn Task agents to investigate simultaneously:
-
-```markdown
-Agent 1: Current State Analysis
-- What exists today?
-- How is it implemented?
-- What are its limitations?
-
-Agent 2: Standard/Competitor Analysis
-- What do similar products offer?
-- What's the industry standard?
-- What do users expect?
-
-Agent 3: User-Facing Gaps
-- What's missing from user perspective?
-- What are common complaints/requests?
-- What workflows are incomplete?
-
-Agent 4: Technical Debt
-- What technical limitations block features?
-- What refactoring would enable new capabilities?
-- What dependencies are outdated?
-```
-
-### Phase 3: Synthesize Findings
-Compile findings into prioritized analysis:
-
-```markdown
-## Feature Gap Analysis: [Area]
-
-### Current State
-| Feature | Status | Implementation | Notes |
-|---------|--------|----------------|-------|
-| Feature A | Complete | `path/to/file.ts` | |
-| Feature B | Partial | `path/to/file.ts` | Missing X |
-| Feature C | Missing | - | Needed for Y |
-
-### Gap Prioritization
-
-#### High Priority (User Impact + Feasibility)
-1. **[Gap]**
-   - Impact: [Why it matters]
-   - Complexity: S/M/L
-   - Dependencies: [What's needed first]
-   - Suggested approach: [Brief technical direction]
-
-#### Medium Priority
-2. **[Gap]**
-   - ...
-
-#### Low Priority / Nice-to-Have
-3. **[Gap]**
-   - ...
-
-### Technical Debt Blocking Progress
-- [ ] Debt item 1 - blocks [features]
-- [ ] Debt item 2 - blocks [features]
-
-### Recommended Roadmap
-1. Phase 1: [Quick wins]
-2. Phase 2: [Core features]
-3. Phase 3: [Advanced features]
-```
-
-### Phase 4: Generate Implementation Plans
-For top priority gaps, draft initial implementation plans:
-
-```markdown
-## Implementation Plan: [Top Gap]
-
-### Files to Create/Modify
-- `new/file.ts` - [purpose]
-- `existing/file.ts` - [changes needed]
-
-### Key Decisions Needed
-- Decision 1: Option A vs Option B
-- Decision 2: ...
-
-### Draft Implementation Steps
-1. Step 1
-2. Step 2
-3. ...
-```
-
-## Rules
-
-- ALWAYS output prioritized, actionable findings
-- Include complexity estimates (S/M/L) for each gap
-- Provide file:line references to existing implementations
-- Don't just list gaps - provide implementation direction
-- Use TodoWrite to checkpoint analysis progress
-- If interrupted, output whatever analysis exists so far

package/config/skills/investigate/SKILL.md

@@ -1,71 +0,0 @@
-# Investigation Skill
-
-Use this skill for code investigation, feature gap analysis, or understanding existing functionality.
-
-## Trigger
-
-- User asks to investigate, analyze, or understand code
-- Feature gap analysis requests
-- "How does X work?" questions
-- Code exploration tasks
-
-## Workflow
-
-### Phase 1: Define Scope
-Before starting, clarify:
-- What specific question needs answering?
-- What does "complete" look like for this investigation?
-- Are there time constraints?
-
-### Phase 2: Parallel Exploration
-Spawn Task agents to explore different areas simultaneously:
-```
-Use Task tool to spawn parallel agents:
-1. Agent for data layer analysis
-2. Agent for API/service layer
-3. Agent for UI/component layer
-```
-
-### Phase 3: Checkpoint Progress
-Every significant finding, use TodoWrite to record:
-- Files examined
-- Patterns discovered
-- Questions raised
-- Hypotheses formed
-
-### Phase 4: Synthesize & Report
-ALWAYS output a structured summary before ending:
-
-```markdown
-## Investigation Summary: [Topic]
-
-### Files Examined
-- `path/to/file.ts` - [what it does]
-- `path/to/other.ts` - [what it does]
-
-### Key Findings
-1. [Finding with file:line reference]
-2. [Finding with file:line reference]
-
-### Architecture/Flow
-[Brief description or diagram of how components interact]
-
-### Gaps/Issues Identified
-- [ ] Gap 1
-- [ ] Gap 2
-
-### Remaining Unknowns
-- Question that needs more investigation
-
-### Recommended Next Steps
-1. Actionable step
-2. Actionable step
-```
-
-## Rules
-
-- NEVER end mid-investigation without a summary
-- ALWAYS provide file:line references for findings
-- Use TodoWrite to checkpoint progress every 5-10 minutes
-- If interrupted, output whatever findings exist so far
-- Prefer parallel Task agents for large codebases