Skip to content
Back to skills

Templates

ASecurity

Use when <the situation, in the words a user would actually use>. Covers <scope>. Trigger on "<phrasing>", "<phrasing>". Do not use for <adjacent case> — see the <other> skill.

  • 26 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 6, 2026
ai-agentsrustgodatabase

Security analysis

A100/100

Scanned September 6, 2026

npx -y skills add nimadorostkar/Claude-Skills-collection --skill templates --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Templates?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Templates
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/nimadorostkar-templates/badge)](https://www.skillsdirectory.com/skills/nimadorostkar-templates)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: skill-name
description: Use when <the situation, in the words a user would actually use>. Covers <scope>. Trigger on "<phrasing>", "<phrasing>". Do not use for <adjacent case> — see the <other> skill.
metadata:
  category: <one of the 17 category directories>
  version: 1.0.0
  tags: [three, to, six, tags]
---

# Skill Name

## Purpose

What this makes possible, and — more usefully — what failure it prevents. Two or three sentences. Do not paraphrase the title.

## When to Use

Concrete situations, phrased as a user would describe them. Not "when performing database optimization" but "a query is slow and you do not know why".

- Situation one.
- Situation two.
- Situation three.

## Capabilities

What the skill actually covers. A short list. This is scope, not marketing.

- Capability one.
- Capability two.

## Inputs

What the skill needs in order to be useful. Be specific: "the actual execution plan, not a guess about it".

- Input one.
- Input two.

## Outputs

What the user gets. Concrete artifacts, not "improved code quality".

- Output one.
- Output two.

## Workflow

Numbered steps, in the order they must happen. The order is usually the most important thing in the skill — measure before optimizing, reproduce before fixing, validate before trusting.

1. **Step name** — What to do, and why this step comes first.
2. **Step name** — What to do.
3. **Step name** — What to do.

## Best Practices

Rules, with consequences. Not preferences. Each line must earn its place — if it could appear in any skill, cut it.

- A rule stated as a rule, with the reason it matters.
- The specific way people get this wrong, named.
- A default that is safe, and why the alternative is not.

## Examples

Real, runnable code, or a worked case. Show the failure alongside the fix — the wrong version teaches more than the right one alone. Never a toy example, never an elided `...` where the difficult part should be.

**What the mistake looks like:**

```language
// The wrong version, with a comment naming exactly what is wrong.
```

**What to do instead:**

```language
// The right version. It should be obvious why it is better.
```

## Notes

The non-obvious. Version caveats. The trap that catches everyone. The thing a competent practitioner would not already know.

If this section is generic, the skill is probably not worth including — an author who cannot name a surprising detail usually has not worked with the subject long enough to write about it.

- A version-specific caveat.
- A trap, and why it is so common.
- A pointer to the adjacent skill, where the boundary is genuinely fuzzy.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…