devlyn-cli 0.0.6 → 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/optional-skills/pyx-scan/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: pyx-scan
+description: >
+  Check whether an AI agent skill is safe before installing or using it.
+  Calls the PYX Scanner API to retrieve trust status, risk score, and safety
+  recommendation. Use when agent needs to verify skill safety, or user says
+  "is this safe", "check skill", "scan skill", "verify tool", "pyx scan".
+allowed-tools: WebFetch, Bash(curl *)
+argument-hint: "[owner/name]"
+---
+
+# PYX Scan — Agent Skill Safety Check
+
+Verify whether an AI agent skill is safe before installing or using it by querying the PYX Scanner API.
+
+## Workflow
+
+### Step 1: Parse Input
+
+Extract `owner` and `name` from `$ARGUMENTS`.
+
+- Expected format: `owner/name` (e.g., `anthropic/web-search`)
+- If `$ARGUMENTS` is empty or missing the `/` separator, ask the user:
+  *"Which skill do you want to check? Provide it as `owner/name` (e.g., `anthropic/web-search`)."*
+- Trim whitespace. Reject if either part is empty after trimming.
+
+### Step 2: Call the PYX Scanner API
+
+Fetch the safety data:
+
+```
+WebFetch URL: https://scanner.pyxmate.com/api/v1/check/{owner}/{name}
+Prompt: "Return the full JSON response body exactly as-is. Do not summarize."
+```
+
+If `WebFetch` fails (tool unavailable, network error), fall back to:
+
+```bash
+curl -s "https://scanner.pyxmate.com/api/v1/check/{owner}/{name}"
+```
+
+### Step 3: Handle Errors
+
+| HTTP Status | Meaning | Action |
+|---|---|---|
+| **200** | Skill found | Proceed to Step 4 |
+| **404** | Skill not in database | Verdict = **UNSCANNED** |
+| **429** | Rate limited | Verdict = **ERROR** — "Rate limited. Try again shortly." |
+| **5xx** | Server error | Verdict = **ERROR** — "PYX Scanner is temporarily unavailable." |
+| Network failure | Cannot reach API | Verdict = **ERROR** — "Could not connect to PYX Scanner." |
+
+### Step 4: Determine Verdict
+
+Use the JSON response fields to determine the verdict:
+
+| Condition | Verdict |
+|---|---|
+| `recommendation == "safe"` AND `is_outdated == false` | **SAFE** |
+| `recommendation == "safe"` AND `is_outdated == true` | **OUTDATED** |
+| `recommendation == "caution"` | **CAUTION** |
+| `recommendation == "danger"` | **FAILED** |
+| `recommendation == "unknown"` | **UNSCANNED** |
+
+### Step 5: Output Report
+
+Format the report as structured markdown. Omit any section where the data is null or empty.
+
+**For SAFE verdict:**
+
+```
+## PYX Scan: {owner}/{name}
+
+**Verdict: SAFE** — This skill has been scanned and verified safe.
+
+**Trust Score:** {trust_score}/10 | **Risk Score:** {risk_score}/10 | **Confidence:** {confidence}%
+**Intent:** {intent} | **Status:** {status}
+
+### Summary
+{summary}
+
+### About
+**Purpose:** {about.purpose}
+**Capabilities:** {about.capabilities as bullet list}
+**Permissions Required:** {about.permissions_required as bullet list}
+
+[View full report]({detail_url}) | [Badge]({badge_url})
+```
+
+**For OUTDATED verdict:**
+
+```
+## PYX Scan: {owner}/{name}
+
+**Verdict: OUTDATED** — Last scan was safe, but the skill has been updated since.
+
+The scanned commit (`{scanned_commit}`) no longer matches the latest (`{latest_commit}`).
+The new version has NOT been reviewed. Proceed with caution.
+
+**Trust Score:** {trust_score}/10 | **Risk Score:** {risk_score}/10
+**Last Safe Commit:** {last_safe_commit}
+
+### Summary
+{summary}
+
+[View full report]({detail_url})
+```
+
+**For CAUTION verdict:**
+
+```
+## PYX Scan: {owner}/{name}
+
+**Verdict: CAUTION** — This skill has potential risks that need your attention.
+
+**Trust Score:** {trust_score}/10 | **Risk Score:** {risk_score}/10 | **Confidence:** {confidence}%
+**Intent:** {intent} | **Status:** {status}
+
+### Summary
+{summary}
+
+### About
+**Purpose:** {about.purpose}
+**Permissions Required:** {about.permissions_required as bullet list}
+**Security Notes:** {about.security_notes}
+
+**Do you want to proceed despite the caution rating?** Please confirm before installing or using this skill.
+
+[View full report]({detail_url})
+```
+
+**For FAILED verdict:**
+
+```
+## PYX Scan: {owner}/{name}
+
+**Verdict: FAILED** — This skill has been flagged as dangerous. Do NOT install or use it.
+
+**Trust Score:** {trust_score}/10 | **Risk Score:** {risk_score}/10 | **Confidence:** {confidence}%
+**Intent:** {intent} | **Status:** {status}
+
+### Summary
+{summary}
+
+### About
+**Security Notes:** {about.security_notes}
+
+[View full report]({detail_url})
+```
+
+**For UNSCANNED verdict:**
+
+```
+## PYX Scan: {owner}/{name}
+
+**Verdict: UNSCANNED** — This skill has not been scanned by PYX Scanner.
+
+No safety data is available. You should:
+1. Review the skill's source code manually before use
+2. Check the skill's repository for known issues
+3. Request a scan at https://scanner.pyxmate.com
+```
+
+**For ERROR verdict:**
+
+```
+## PYX Scan: {owner}/{name}
+
+**Verdict: ERROR** — {error_message}
+
+Safety could not be verified. Treat this skill as unverified until you can confirm its safety.
+```
+
+## Behavioral Rules
+
+1. **Always call the API** — never skip the check or return a cached/assumed result.
+2. **Never soften a FAILED verdict** — if the scan says danger, report danger. Do not add qualifiers like "but it might be fine."
+3. **Always ask user confirmation on CAUTION** — the user must explicitly agree before proceeding.
+4. **Keep reports concise** — omit null/empty sections rather than showing "N/A."
+5. **No raw JSON** — always format the response as the structured markdown report above.
+
+## Self-Scan Awareness
+
+When `$ARGUMENTS` is `pyxmate/pyx-scan`, `pyxmate/pyx-scanner`, or refers to this skill itself, still call the API honestly and report whatever comes back. If the result is UNSCANNED, append:
+
+> *"Yes, even the security scanner's own skill hasn't been scanned yet. We practice what we preach — treat unscanned skills with caution."*

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "devlyn-cli",
-  "version": "0.0.6",
+  "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