codeply-cli 0.5.6 → 0.6.0

package/skills/make-interfaces-feel-better/SKILL.md

@@ -1,152 +1,152 @@
----
-name: make-interfaces-feel-better
-description: Apply concrete design-engineering details that make interfaces feel polished. Use when reviewing or improving UI spacing, typography, borders, shadows, motion, hit areas, icons, text wrapping, and interaction states.
-metadata:
-  origin: community
----
-
-# Make Interfaces Feel Better
-
-Use this skill for the small design-engineering details that compound into a
-more polished interface.
-
-Source: salvaged from stale community PR #1659 by `linus707`.
-
-## When to Use
-
-- The user says the UI feels off, flat, generic, cramped, jumpy, or unfinished.
-- You are building controls, cards, lists, dashboards, navigation, forms, or
-  toolbars.
-- A component needs hover, active, focus, enter, exit, loading, or empty states.
-- A frontend review needs specific before/after recommendations.
-
-## Core Principles
-
-### Concentric Radius
-
-For nearby nested rounded surfaces:
-
-```text
-outer radius = inner radius + padding
-```
-
-If padding is large, treat layers as separate surfaces instead of forcing the
-math. The point is optical coherence, not formula worship.
-
-### Optical Alignment
-
-Geometric centering is not always visual centering. Icon buttons, play
-triangles, arrows, stars, and asymmetric icons often need a small offset. Fix the
-SVG when possible; otherwise adjust with a pixel-level margin or padding change.
-
-### Shadows And Borders
-
-Use borders for separation and focus rings. Use layered shadows when a card,
-button, dropdown, or popover needs depth. Shadows should be transparent and
-subtle enough to work across backgrounds.
-
-### Text Wrapping
-
-- Use `text-wrap: balance` on headings and short titles.
-- Use `text-wrap: pretty` on short-to-medium body text, captions, descriptions,
-  and list items.
-- Avoid both on long prose, code, and preformatted content.
-- Use `font-variant-numeric: tabular-nums` for counters, timers, prices, tables,
-  and other updating numbers.
-
-### Font Smoothing
-
-On macOS, apply antialiased font smoothing at the root layout when the project
-does not already do so:
-
-```css
-html {
-  -webkit-font-smoothing: antialiased;
-  -moz-osx-font-smoothing: grayscale;
-}
-```
-
-### Image Outlines
-
-Images often need a subtle inset outline so their edges do not blur into the
-surface.
-
-```css
-img {
-  outline: 1px solid rgba(0, 0, 0, 0.1);
-  outline-offset: -1px;
-}
-
-@media (prefers-color-scheme: dark) {
-  img {
-    outline-color: rgba(255, 255, 255, 0.1);
-  }
-}
-```
-
-Use neutral black or white alpha outlines. Do not tint image outlines with the
-brand palette.
-
-### Motion
-
-Use CSS transitions for interactive state changes because they can retarget
-when the user changes intent mid-motion. Reserve keyframes for staged
-one-shot entrances or loading sequences.
-
-Good motion defaults:
-
-- Enter: combine opacity, small `translateY`, and optionally blur.
-- Exit: shorter and quieter than enter, usually 150ms.
-- Press: `scale(0.96)` for tactile buttons, with a way to disable it when the
-  movement distracts.
-- Icon swaps: cross-fade with opacity, scale, and blur instead of instant
-  visibility toggles.
-
-### Transition Scope
-
-Never use `transition: all`. Specify the changed properties:
-
-```css
-.button {
-  transition-property: transform, background-color, box-shadow;
-  transition-duration: 150ms;
-  transition-timing-function: ease-out;
-}
-```
-
-Use `will-change` only for first-frame stutter on compositor-friendly
-properties such as `transform`, `opacity`, and `filter`. Never use
-`will-change: all`.
-
-### Hit Areas
-
-Interactive controls should have at least a 40x40px hit area, ideally 44x44px
-where the layout allows it. Expand with a pseudo-element when the visible icon
-is smaller, but do not let expanded hit areas overlap.
-
-## Review Output
-
-When reviewing a UI polish pass, report concrete changes in before/after rows:
-
-| Principle | Before | After |
-| --- | --- | --- |
-| Concentric radius | Same radius on parent and child | Parent radius accounts for padding |
-| Tabular numbers | Counter shifts as digits change | Counter uses `tabular-nums` |
-| Transition scope | `transition: all` | Explicit transition properties |
-
-Include file paths and properties when they are not obvious from the snippets.
-Omit principles that you checked but did not change.
-
-## Checklist
-
-- Nested rounded elements are optically coherent.
-- Icons are visually centered.
-- Buttons, cards, and popovers use borders or shadows for the right reason.
-- Headings and short text avoid awkward wrapping.
-- Dynamic numbers use tabular numerals.
-- Images have neutral outlines where needed.
-- Enter and exit animations are split, subtle, and interruptible where
-  appropriate.
-- Buttons have tactile active states without exaggerated motion.
-- `transition: all` and `will-change: all` are absent.
-- Small controls still have usable hit areas.
+---
+name: make-interfaces-feel-better
+description: Apply concrete design-engineering details that make interfaces feel polished. Use when reviewing or improving UI spacing, typography, borders, shadows, motion, hit areas, icons, text wrapping, and interaction states.
+metadata:
+  origin: community
+---
+
+# Make Interfaces Feel Better
+
+Use this skill for the small design-engineering details that compound into a
+more polished interface.
+
+Source: salvaged from stale community PR #1659 by `linus707`.
+
+## When to Use
+
+- The user says the UI feels off, flat, generic, cramped, jumpy, or unfinished.
+- You are building controls, cards, lists, dashboards, navigation, forms, or
+  toolbars.
+- A component needs hover, active, focus, enter, exit, loading, or empty states.
+- A frontend review needs specific before/after recommendations.
+
+## Core Principles
+
+### Concentric Radius
+
+For nearby nested rounded surfaces:
+
+```text
+outer radius = inner radius + padding
+```
+
+If padding is large, treat layers as separate surfaces instead of forcing the
+math. The point is optical coherence, not formula worship.
+
+### Optical Alignment
+
+Geometric centering is not always visual centering. Icon buttons, play
+triangles, arrows, stars, and asymmetric icons often need a small offset. Fix the
+SVG when possible; otherwise adjust with a pixel-level margin or padding change.
+
+### Shadows And Borders
+
+Use borders for separation and focus rings. Use layered shadows when a card,
+button, dropdown, or popover needs depth. Shadows should be transparent and
+subtle enough to work across backgrounds.
+
+### Text Wrapping
+
+- Use `text-wrap: balance` on headings and short titles.
+- Use `text-wrap: pretty` on short-to-medium body text, captions, descriptions,
+  and list items.
+- Avoid both on long prose, code, and preformatted content.
+- Use `font-variant-numeric: tabular-nums` for counters, timers, prices, tables,
+  and other updating numbers.
+
+### Font Smoothing
+
+On macOS, apply antialiased font smoothing at the root layout when the project
+does not already do so:
+
+```css
+html {
+  -webkit-font-smoothing: antialiased;
+  -moz-osx-font-smoothing: grayscale;
+}
+```
+
+### Image Outlines
+
+Images often need a subtle inset outline so their edges do not blur into the
+surface.
+
+```css
+img {
+  outline: 1px solid rgba(0, 0, 0, 0.1);
+  outline-offset: -1px;
+}
+
+@media (prefers-color-scheme: dark) {
+  img {
+    outline-color: rgba(255, 255, 255, 0.1);
+  }
+}
+```
+
+Use neutral black or white alpha outlines. Do not tint image outlines with the
+brand palette.
+
+### Motion
+
+Use CSS transitions for interactive state changes because they can retarget
+when the user changes intent mid-motion. Reserve keyframes for staged
+one-shot entrances or loading sequences.
+
+Good motion defaults:
+
+- Enter: combine opacity, small `translateY`, and optionally blur.
+- Exit: shorter and quieter than enter, usually 150ms.
+- Press: `scale(0.96)` for tactile buttons, with a way to disable it when the
+  movement distracts.
+- Icon swaps: cross-fade with opacity, scale, and blur instead of instant
+  visibility toggles.
+
+### Transition Scope
+
+Never use `transition: all`. Specify the changed properties:
+
+```css
+.button {
+  transition-property: transform, background-color, box-shadow;
+  transition-duration: 150ms;
+  transition-timing-function: ease-out;
+}
+```
+
+Use `will-change` only for first-frame stutter on compositor-friendly
+properties such as `transform`, `opacity`, and `filter`. Never use
+`will-change: all`.
+
+### Hit Areas
+
+Interactive controls should have at least a 40x40px hit area, ideally 44x44px
+where the layout allows it. Expand with a pseudo-element when the visible icon
+is smaller, but do not let expanded hit areas overlap.
+
+## Review Output
+
+When reviewing a UI polish pass, report concrete changes in before/after rows:
+
+| Principle | Before | After |
+| --- | --- | --- |
+| Concentric radius | Same radius on parent and child | Parent radius accounts for padding |
+| Tabular numbers | Counter shifts as digits change | Counter uses `tabular-nums` |
+| Transition scope | `transition: all` | Explicit transition properties |
+
+Include file paths and properties when they are not obvious from the snippets.
+Omit principles that you checked but did not change.
+
+## Checklist
+
+- Nested rounded elements are optically coherent.
+- Icons are visually centered.
+- Buttons, cards, and popovers use borders or shadows for the right reason.
+- Headings and short text avoid awkward wrapping.
+- Dynamic numbers use tabular numerals.
+- Images have neutral outlines where needed.
+- Enter and exit animations are split, subtle, and interruptible where
+  appropriate.
+- Buttons have tactile active states without exaggerated motion.
+- `transition: all` and `will-change: all` are absent.
+- Small controls still have usable hit areas.

package/skills/manim-video/SKILL.md

@@ -1,90 +1,90 @@
----
-name: manim-video
-description: Build reusable Manim explainers for technical concepts, graphs, system diagrams, and product walkthroughs, then hand off to the wider ECC video stack if needed. Use when the user wants a clean animated explainer rather than a generic talking-head script.
-metadata:
-  origin: ECC
----
-
-# Manim Video
-
-Use Manim for technical explainers where motion, structure, and clarity matter more than photorealism.
-
-## When to Activate
-
-- the user wants a technical explainer animation
-- the concept is a graph, workflow, architecture, metric progression, or system diagram
-- the user wants a short product or launch explainer for X or a landing page
-- the visual should feel precise instead of generically cinematic
-
-## Tool Requirements
-
-- `manim` CLI for scene rendering
-- `ffmpeg` for post-processing if needed
-- `video-editing` for final assembly or polish
-- `remotion-video-creation` when the final package needs composited UI, captions, or additional motion layers
-
-## Default Output
-
-- short 16:9 MP4
-- one thumbnail or poster frame
-- storyboard plus scene plan
-
-## Workflow
-
-1. Define the core visual thesis in one sentence.
-2. Break the concept into 3 to 6 scenes.
-3. Decide what each scene proves.
-4. Write the scene outline before writing Manim code.
-5. Render the smallest working version first.
-6. Tighten typography, spacing, color, and pacing after the render works.
-7. Hand off to the wider video stack only if it adds value.
-
-## Scene Planning Rules
-
-- each scene should prove one thing
-- avoid overstuffed diagrams
-- prefer progressive reveal over full-screen clutter
-- use motion to explain state change, not just to keep the screen busy
-- title cards should be short and loaded with meaning
-
-## Network Graph Default
-
-For social-graph and network-optimization explainers:
-
-- show the current graph before showing the optimized graph
-- distinguish low-signal follow clutter from high-signal bridges
-- highlight warm-path nodes and target clusters
-- if useful, add a final scene showing the self-improvement lineage that informed the skill
-
-## Render Conventions
-
-- default to 16:9 landscape unless the user asks for vertical
-- start with a low-quality smoke test render
-- only push to higher quality after composition and timing are stable
-- export one clean thumbnail frame that reads at social size
-
-## Reusable Starter
-
-Use [assets/network_graph_scene.py](assets/network_graph_scene.py) as a starting point for network-graph explainers.
-
-Example smoke test:
-
-```bash
-manim -ql assets/network_graph_scene.py NetworkGraphExplainer
-```
-
-## Output Format
-
-Return:
-
-- core visual thesis
-- storyboard
-- scene outline
-- render plan
-- any follow-on polish recommendations
-
-## Related Skills
-
-- `video-editing` for final polish
-- `remotion-video-creation` for motion-heavy post-processing or compositing
-- `content-engine` when the animation is part of a broader launch
+---
+name: manim-video
+description: Build reusable Manim explainers for technical concepts, graphs, system diagrams, and product walkthroughs, then hand off to the wider ECC video stack if needed. Use when the user wants a clean animated explainer rather than a generic talking-head script.
+metadata:
+  origin: ECC
+---
+
+# Manim Video
+
+Use Manim for technical explainers where motion, structure, and clarity matter more than photorealism.
+
+## When to Activate
+
+- the user wants a technical explainer animation
+- the concept is a graph, workflow, architecture, metric progression, or system diagram
+- the user wants a short product or launch explainer for X or a landing page
+- the visual should feel precise instead of generically cinematic
+
+## Tool Requirements
+
+- `manim` CLI for scene rendering
+- `ffmpeg` for post-processing if needed
+- `video-editing` for final assembly or polish
+- `remotion-video-creation` when the final package needs composited UI, captions, or additional motion layers
+
+## Default Output
+
+- short 16:9 MP4
+- one thumbnail or poster frame
+- storyboard plus scene plan
+
+## Workflow
+
+1. Define the core visual thesis in one sentence.
+2. Break the concept into 3 to 6 scenes.
+3. Decide what each scene proves.
+4. Write the scene outline before writing Manim code.
+5. Render the smallest working version first.
+6. Tighten typography, spacing, color, and pacing after the render works.
+7. Hand off to the wider video stack only if it adds value.
+
+## Scene Planning Rules
+
+- each scene should prove one thing
+- avoid overstuffed diagrams
+- prefer progressive reveal over full-screen clutter
+- use motion to explain state change, not just to keep the screen busy
+- title cards should be short and loaded with meaning
+
+## Network Graph Default
+
+For social-graph and network-optimization explainers:
+
+- show the current graph before showing the optimized graph
+- distinguish low-signal follow clutter from high-signal bridges
+- highlight warm-path nodes and target clusters
+- if useful, add a final scene showing the self-improvement lineage that informed the skill
+
+## Render Conventions
+
+- default to 16:9 landscape unless the user asks for vertical
+- start with a low-quality smoke test render
+- only push to higher quality after composition and timing are stable
+- export one clean thumbnail frame that reads at social size
+
+## Reusable Starter
+
+Use [assets/network_graph_scene.py](assets/network_graph_scene.py) as a starting point for network-graph explainers.
+
+Example smoke test:
+
+```bash
+manim -ql assets/network_graph_scene.py NetworkGraphExplainer
+```
+
+## Output Format
+
+Return:
+
+- core visual thesis
+- storyboard
+- scene outline
+- render plan
+- any follow-on polish recommendations
+
+## Related Skills
+
+- `video-editing` for final polish
+- `remotion-video-creation` for motion-heavy post-processing or compositing
+- `content-engine` when the animation is part of a broader launch

package/skills/market-research/SKILL.md

@@ -1,76 +1,76 @@
----
-name: market-research
-description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
-metadata:
-  origin: ECC
----
-
-# Market Research
-
-Produce research that supports decisions, not research theater.
-
-## When to Activate
-
-- researching a market, category, company, investor, or technology trend
-- building TAM/SAM/SOM estimates
-- comparing competitors or adjacent products
-- preparing investor dossiers before outreach
-- pressure-testing a thesis before building, funding, or entering a market
-
-## Research Standards
-
-1. Every important claim needs a source.
-2. Prefer recent data and call out stale data.
-3. Include contrarian evidence and downside cases.
-4. Translate findings into a decision, not just a summary.
-5. Separate fact, inference, and recommendation clearly.
-
-## Common Research Modes
-
-### Investor / Fund Diligence
-Collect:
-- fund size, stage, and typical check size
-- relevant portfolio companies
-- public thesis and recent activity
-- reasons the fund is or is not a fit
-- any obvious red flags or mismatches
-
-### Competitive Analysis
-Collect:
-- product reality, not marketing copy
-- funding and investor history if public
-- traction metrics if public
-- distribution and pricing clues
-- strengths, weaknesses, and positioning gaps
-
-### Market Sizing
-Use:
-- top-down estimates from reports or public datasets
-- bottom-up sanity checks from realistic customer acquisition assumptions
-- explicit assumptions for every leap in logic
-
-### Technology / Vendor Research
-Collect:
-- how it works
-- trade-offs and adoption signals
-- integration complexity
-- lock-in, security, compliance, and operational risk
-
-## Output Format
-
-Default structure:
-1. executive summary
-2. key findings
-3. implications
-4. risks and caveats
-5. recommendation
-6. sources
-
-## Quality Gate
-
-Before delivering:
-- all numbers are sourced or labeled as estimates
-- old data is flagged
-- the recommendation follows from the evidence
-- risks and counterarguments are included
-- the output makes a decision easier
+---
+name: market-research
+description: Conduct market research, competitive analysis, investor due diligence, and industry intelligence with source attribution and decision-oriented summaries. Use when the user wants market sizing, competitor comparisons, fund research, technology scans, or research that informs business decisions.
+metadata:
+  origin: ECC
+---
+
+# Market Research
+
+Produce research that supports decisions, not research theater.
+
+## When to Activate
+
+- researching a market, category, company, investor, or technology trend
+- building TAM/SAM/SOM estimates
+- comparing competitors or adjacent products
+- preparing investor dossiers before outreach
+- pressure-testing a thesis before building, funding, or entering a market
+
+## Research Standards
+
+1. Every important claim needs a source.
+2. Prefer recent data and call out stale data.
+3. Include contrarian evidence and downside cases.
+4. Translate findings into a decision, not just a summary.
+5. Separate fact, inference, and recommendation clearly.
+
+## Common Research Modes
+
+### Investor / Fund Diligence
+Collect:
+- fund size, stage, and typical check size
+- relevant portfolio companies
+- public thesis and recent activity
+- reasons the fund is or is not a fit
+- any obvious red flags or mismatches
+
+### Competitive Analysis
+Collect:
+- product reality, not marketing copy
+- funding and investor history if public
+- traction metrics if public
+- distribution and pricing clues
+- strengths, weaknesses, and positioning gaps
+
+### Market Sizing
+Use:
+- top-down estimates from reports or public datasets
+- bottom-up sanity checks from realistic customer acquisition assumptions
+- explicit assumptions for every leap in logic
+
+### Technology / Vendor Research
+Collect:
+- how it works
+- trade-offs and adoption signals
+- integration complexity
+- lock-in, security, compliance, and operational risk
+
+## Output Format
+
+Default structure:
+1. executive summary
+2. key findings
+3. implications
+4. risks and caveats
+5. recommendation
+6. sources
+
+## Quality Gate
+
+Before delivering:
+- all numbers are sourced or labeled as estimates
+- old data is flagged
+- the recommendation follows from the evidence
+- risks and counterarguments are included
+- the output makes a decision easier