Use when creating or modifying REST API endpoints (Rails controllers, engine routes, API actions). Requires generating or updating an API Collection file (e.g., Postman Collection v2.1) so the new or changed endpoints can be tested. Trigger words: endpoint, API route, controller action, API collection, request collection. --- # REST API Collection **Core principle:** Every API surface (Rails app or engine) has a single API collection file that stays in sync with its endpoints. ## Quick Reference | Aspect | Rule | |--------|------| | When | Create or update collection when creating or modifying any REST API endpoint (route + controller action) | | Format | Postman Collection JSON v2.1 (`schema` or `info.schema` references v2.1) is a good default standard | | Location | One file per app or engine — `docs/api-collections/<app-or-engine-name>.json` or `spec/fixtures/api-collections/`; if a collection folder already exists, update the existing file | | Language | All request names, descriptions, and variable names must be in **English** | | Variables | Use `{{base_url}}` (or equivalent) for the base URL so the collection works across environments | | Per request | method, URL (with variables for base URL), headers (Content-Type, Authorization if needed), body example when applicable | | Validation | See validation steps in the HARD-GATE section below | ## HARD-GATE: Generate on Endpoint Change ``` When you create or modify a REST API endpoint (new or changed route and controller action), you MUST also create or update the corresponding API collection file so the flow can be tested. Do not leave the collection missing or outdated.
Generate accurate, readable D2 block diagrams for software, research, and system explanations from a text brief. Normalize components and edges, write a canonical .d2 source file, render compact sketch-style SVG and optional PNG artifacts by default, support optional LaTeX equation blocks when the diagram genuinely needs them, keep arrows unlabeled unless a label adds concrete meaning, and emit Telegram file directives when needed.
Skill files are scattered across GitHub and communities, difficult to search, and hard to evaluate. SkillWink organizes open-source skills into a searchable, filterable library you can directly download and use.
We provide keyword search, version updates, multi-metric ranking (downloads / likes / comments / updates), and open SKILL.md standards. You can also discuss usage and improvements on skill detail pages.
Sort by downloads/likes/comments/updated to find higher-quality skills.
4. Which import methods are supported?
Upload archive: .zip / .skill (recommended)
Upload skills folder
Import from GitHub repository
Note: file size for all methods should be within 10MB.
5. How to use in Claude / Codex?
Typical paths (may vary by local setup):
Claude Code：~/.claude/skills/
Codex CLI：~/.codex/skills/
One SKILL.md can usually be reused across tools.
6. Can one skill be shared across tools?
Yes. Most skills are standardized docs + assets, so they can be reused where format is supported.
Example: retrieval + writing + automation scripts as one workflow.
7. Are these skills safe to use?
Some skills come from public GitHub repositories and some are uploaded by SkillWink creators. Always review code before installing and own your security decisions.
8. Why does it not work after import?
Most common reasons:
Wrong folder path or nested one level too deep
Invalid/incomplete SKILL.md fields or format
Dependencies missing (Python/Node/CLI)
Tool has not reloaded skills yet
9. Does SkillWink include duplicates/low-quality skills?
We try to avoid that. Use ranking + comments to surface better skills:
