You are turning raw SVG markup the user provides into an Astro icon component in website/src/icons/.

Workflow

1. Get the SVG: The user will give you raw SVG markup (often copy-pasted from Streamline, Figma, etc.).

2. Pick a filename: Use a short kebab-case name describing the icon (e.g. settings.astro, arrow-right.astro). Infer obvious icon names without asking. For common brand logos, use the brand name (e.g. GitHub → github.astro). Ask the user only if the name is truly ambiguous.

3. Transform the SVG:

   • Add this Astro frontmatter at the top:

     ---
     interface Props {
       class?: string
     }
     
     const { class: className } = Astro.props
     ---
     

   • On the <svg> tag: keep xmlns, fill, and viewBox. Add class={className}. Remove hardcoded width and height — size is controlled by Tailwind (size-4, size-6, etc.).

   • Replace every hardcoded stroke color (e.g. stroke="#000000") with stroke="currentColor". Same for fill if it's a color — but leave fill="none" alone. Brand icons that should inherit text color should use fill="currentColor".

   • Strip noise: id attributes, <desc> tags, <title> tags, and any other vendor metadata.

   • Keep stroke-width, stroke-linecap, stroke-linejoin, d, and other geometry-defining attributes. Preserve valid Astro/HTML attribute casing for SVG markup.

4. Write the file to website/src/icons/<name>.astro immediately. Use bash with a quoted heredoc instead of the write tool to avoid slow line-by-line UI rendering:

   cat > website/src/icons/<name>.astro <<'EOF'
   ...
   EOF
   

Speed rules

• Do not inspect existing icon files unless necessary.
• Infer obvious icon names without asking.
• For common brand logos, use the brand name.
• Immediately write website/src/icons/<name>.astro after transforming.
• Prefer bash with a quoted heredoc for file creation; do not use the write tool unless bash is unavailable.
• Do not run checks unless the user asks.

Example

Input:

<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" id="Foo" height="24" width="24">
  <desc>Some vendor blurb</desc>
  <g id="group"><path id="p1" stroke="#000000" d="M6 0v14" stroke-width="2" /></g>
</svg>

Output (website/src/icons/foo.astro):

---
interface Props {
  class?: string
}

const { class: className } = Astro.props
---

<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" class={className}>
  <g>
    <path stroke="currentColor" d="M6 0v14" stroke-width="2" />
  </g>
</svg>

Usage: <FooIcon class="size-4 text-primary" /> when imported with an alias, or import the .astro component directly and render it with class="size-4 text-primary".

You are turning raw SVG markup the user provides into a React icon component in src/icons/.

Workflow

1. Get the SVG: The user will give you raw SVG markup (often copy-pasted from Streamline, Figma, etc.).

2. Pick a filename: Use a short kebab-case name describing the icon (e.g. settings.tsx, arrow-right.tsx). Infer obvious icon names without asking. For common brand logos, use the brand name (e.g. GitHub → github.tsx). Ask the user only if the name is truly ambiguous.

3. Pick a component name: PascalCase + Icon suffix (e.g. SettingsIcon, ArrowRightIcon, GithubIcon).

4. Transform the SVG:

   • Wrap it in export const <Name>Icon = ({ className }: { className?: string }) => (...)
   • On the <svg> tag: keep xmlns, fill, and viewBox. Add className={className}. Remove hardcoded width and height — size is controlled by Tailwind (size-4, size-6, etc.).
   • Replace every hardcoded stroke color (e.g. stroke="#000000") with stroke="currentColor". Same for fill if it's a color — but leave fill="none" alone.
   • Strip noise: id attributes, <desc> tags, <title> tags, and any other vendor metadata.
   • Keep strokeWidth, strokeLinecap, strokeLinejoin, d, and other geometry-defining attributes.

5. Write the file to src/icons/<name>.tsx immediately. Use bash with a quoted heredoc instead of the write tool to avoid slow line-by-line UI rendering:

   cat > src/icons/<name>.tsx <<'EOF'
   ...
   EOF
   

Speed rules

• Do not inspect existing icon files unless necessary.
• Infer obvious icon names without asking.
• For common brand logos, use the brand name.
• Immediately write src/icons/<name>.tsx after transforming.
• Prefer bash with a quoted heredoc for file creation; do not use the write tool unless bash is unavailable.
• Do not run checks unless the user asks.

Example

Input:

<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" id="Foo" height={24} width={24}>
  <desc>Some vendor blurb</desc>
  <g id="group"><path id="p1" stroke="#000000" d="M6 0v14" strokeWidth={2} /></g>
</svg>

Output (src/icons/foo.tsx):

export const FooIcon = ({ className }: { className?: string }) => (
  <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" className={className}>
    <g>
      <path stroke="currentColor" d="M6 0v14" strokeWidth={2} />
    </g>
  </svg>
)

Usage: <FooIcon className="size-4 text-primary" />

Release Notes

Use this skill to draft concise release notes for renCal from git history.

Workflow

1. Identify the current and previous release tags.

   • If the user names a tag, use that as the current tag.
   • Otherwise use git describe --tags --abbrev=0 for the current tag.
   • Find the previous tag with git tag --sort=-creatordate or semver ordering when relevant.

2. Inspect the changes between tags:

   git log --oneline --decorate <previous-tag>..<current-tag>
   git diff --stat <previous-tag>..<current-tag>
   

3. Inspect commit subjects/bodies for PR references:

   git log --format='%h%x09%s%x09%b' <previous-tag>..<current-tag>
   

   • Preserve PR references like (#30) from merge/squash commit subjects.
   • If a change comes from a non-PR commit, reference the short commit hash only when useful.
   • Prefer grouping related implementation details under the same PR number instead of listing every touched file.

4. If the diffstat is broad or unclear, inspect focused diffs for changed areas:

   git diff <previous-tag>..<current-tag> -- <path>
   

Output style

• Return short bullet-form notes grouped under these headings, omitting any empty section:
  • ### ✨ New features
  • ### 🛠️ Improvements
  • ### 🐛 Bug fixes
• Mention the compared range before the grouped notes when helpful, e.g. v0.1.0 since v0.0.6.
• Each bullet should describe user-visible impact first, then cite the PR/commit at the end.
• Use HTML <kbd> tags for keyboard shortcuts, e.g. <kbd>Ctrl</kbd><kbd>K</kbd> or <kbd>.</kbd>.
• Avoid internal implementation details unless they explain a visible improvement.
• Keep wording release-note friendly: concise, polished, and understandable to users.

Example

### ✨ New features

- Added a <kbd>Ctrl</kbd><kbd>K</kbd> command palette for quickly switching themes, switching calendar groups, and performing other actions. (#47)
- Added “Go to date…” so you can jump directly to a specific date from the command palette or with <kbd>.</kbd>. (#50)

### 🛠️ Improvements

- Reminders now support weeks and months, not just shorter intervals. (#52)
- All-day event editing: disabled time fields look cleaner, and unchecking all-day restores the previously selected time. (#53)

### 🐛 Bug fixes

- Fixed a startup crash affecting some Nvidia driver setups. (#46)
- Fixed Linux single-instance handling so repeated launches focus the existing app instead of leaking extra WebKit processes. (#51)
- Fixed stale “today” state so the calendar updates correctly after the day changes. (098e366)

You are helping the user optimize the performance of a specific part of the app.

Workflow

1. Ask for a recording: Ask the user to do a Chrome DevTools performance recording (in Safari Web Inspector or Chrome) of the interaction they want to optimize. They should save the recording JSON file in the recordings/ directory.

2. Analyze the recording: Run just analyze recordings/<filename>.json to get a breakdown of rendering frames, layout events, script events, and CPU profile hotspots.

3. Identify bottlenecks: Look at:

   • Longest rendering frames — anything over 16ms breaks 60fps
   • Top script executions — which events take the most time
   • CPU self-time — which functions are burning the most CPU (especially in src/)
   • CPU total time — which call trees are the most expensive

4. Read the relevant source code: Based on the CPU profile hotspots, read the source files to understand what the code is doing and why it's slow.

5. Propose optimizations: Present concrete, ranked optimization ideas to the user. Common patterns:

   • Caching/memoizing repeated computations
   • Replacing heavy library calls (e.g. date-fns) with lightweight arithmetic
   • Reducing algorithmic complexity (e.g. pre-indexing instead of O(n*m) loops)
   • Avoiding unnecessary object allocations (especially Date objects)

6. Let the user choose: Don't implement anything until the user picks which optimizations to pursue.

7. After implementing: Ask the user to do another recording so you can compare before/after with just analyze and verify the improvements.