メニュー
draw.io diagram creation, editing, and review. Use for .drawio XML editing, PNG conversion, layout adjustment, and AWS icon usage.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
MyLifeのスクラップ要約を作成する。ユーザーが「スクラップ要約」「前日分のスクラップを要約」「Clippingsをデイリーノートに追記」「~/MyLife/Clippings の記事をまとめて」などと依頼したときに使う。Asia/Tokyo基準で対象日を決め、~/MyLife/Clippings/ のYYYYMMDD始まりのファイルからタイトル・URL・本文を抽出し、~/MyLife/pages/YYYY_MM_DD.md の `## 要約` セクションを新規作成または置換する。
Collect analytics from YouTube Studio in Microsoft Edge and save them as a CSV with a fixed schema. Use when Codex is asked to open YouTube Studio, switch to a specific managed channel if needed, read the past 28 days of per-video metrics such as views, average view duration, likes, comments, saves, and impressions, and save the result as a CSV file.
Guide behavior-preserving code refactoring with a language-agnostic core, Fowler-aligned catalog references, and team-specific extension patterns. Use during the TDD REFACTOR phase, when code smells are detected, when preparing for later behavior changes, or when discussing structural improvements.
Orchestrate full implementation lifecycle with sub-agent team delegation through 6 strict phases: Tidy First -> Implement -> TDD Red -> Green -> Refactor -> Tidy After. The leader gives instructions only; sub-agents do all research and coding. Use when user explicitly invokes /implements or says "実装して", "これを実装", "implement this". NOT for quick fixes, single-file edits, or tasks that don't warrant the full 6-phase ceremony.
Boris Tane's structured 3-phase workflow for non-trivial tasks: Research → Plan → Todo → Implement. Use when starting a new feature, refactoring, bug investigation, or any task where you want to plan deeply before coding. Creates research.md, plan.md, and todo.md as shared artifacts for iterative refinement. DO NOT write code until the plan is explicitly approved. Trigger when user says "研究して", "計画を立てて", "research and plan", "plan before coding", or starts a complex task that benefits from upfront analysis.
Use when user says "wrap up", "close session", "end session", "wrap things up", "close out this task", or invokes /wrap-up — runs end-of-session checklist for shipping, memory, and self-improvement
| name | draw-io |
| description | draw.io diagram creation, editing, and review. Use for .drawio XML editing, PNG conversion, layout adjustment, and AWS icon usage. |
Also explicitly specify fontFamily in each text element's style attribute:
style="text;html=1;fontSize=27;fontFamily=Noto Sans JP;"
</example>
mise exec -- pre-commit run convert-drawio-to-png --files assets/my-diagram.drawio
bash ~/.claude/skills/draw-io/scripts/convert-drawio-to-png.sh assets/diagram1.drawio
</example>
<internal_command>drawio -x -f png -s 2 -t -o output.drawio.png input.drawio</internal_command>
<options>
-x: Export mode
-f png: PNG format output
-s 2: 2x scale (high resolution)
-t: Transparent background
-o: Output file path
</options>
</pattern>
<pattern name="coordinate-adjustment">
<description>Adjusting element positions in .drawio XML</description>
<steps>
1. Open `.drawio` file in text editor (plain XML format)
2. Find `mxCell` for element to adjust (search by `value` attribute for text)
3. Adjust coordinates in `mxGeometry` tag (x, y, width, height)
4. Run conversion and verify
</steps>
<note>Element center coordinate = `y + (height / 2)`. To align multiple elements, calculate and match center coordinates.</note>
</pattern>
<pattern name="arrow-connection-to-text">
<description>For text elements, exitX/exitY don't work, so use explicit coordinates</description>
<example>
```xml
<mxCell id="arrow" style="..." edge="1" parent="1">
<mxGeometry relative="1" as="geometry">
<mxPoint x="1279" y="500" as="sourcePoint"/>
<mxPoint x="119" y="500" as="targetPoint"/>
<Array as="points">
<mxPoint x="1279" y="560"/>
<mxPoint x="119" y="560"/>
</Array>
</mxGeometry>
</mxCell>
</example>
<!-- Place below arrow (positive value to distance) --> <mxPoint x="0" y="40" as="offset"/>
</example>
</pattern>
<pattern name="background-frame-placement">
<description>Internal element placement inside background frames with proper margins</description>
<example>
```xml
<!-- Good: sufficient margin -->
<mxCell id="bg" style="rounded=1;strokeWidth=3;...">
<mxGeometry x="500" y="20" width="560" height="430" />
</mxCell>
<mxCell id="label" value="Title" style="text;...">
<mxGeometry x="510" y="50" width="540" height="35" />
</mxCell>
</example>
<calculation>
Background frame: y=20, height=400 -> range is y=20-420 Internal element top: frame y + 30 or more (e.g., y=50) Internal element bottom: frame y + height - 30 or less (e.g., up to y=390)
<best_practices>
Remove background="#ffffff" - transparent background adapts to various themes
Use 1.5x standard font size (around 18px) for PDF readability
Allow 30-40px per Japanese character width; insufficient width causes unintended line breaks
XML layer order: Title -> Arrows (back layer) -> Other elements (front layer)
Remove decorative icons irrelevant to context (e.g., if ECR exists, separate Docker icon is unnecessary)
Service name only: 1 line. Service name + supplementary info: 2 lines with &lt;br&gt; tag
Add auto-stretch: false to YAML header for reveal.js slides to ensure correct image display on mobile
</best_practices>
AWS icon search examples:
python ~/.claude/skills/draw-io/scripts/find_aws_icon.py ec2
python ~/.claude/skills/draw-io/scripts/find_aws_icon.py lambda