Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsBlogPro
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges
  • Chrome Extension
  • Skill Manager

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Mimic

ASecurity

Use when an artifact or an implementation should follow the conventions proven by excellent open-source projects rather than the model's own habits. Triggers on "find similar projects on GitHub and see how they do it", "模仿", "参考同类开源项目", "别人是怎么写的", "how should we implement this", "what's the idiomatic way to do X", "how is this normally structured", "benchmark against comparable repos", "what stack do similar projects use", "make our README look professional", "how should we organise this repo...

2 stars
0 votes
0 copies
0 views
Added 10/6/2026
ai-agentsgogitapi

Works with

api

Security Analysis

A100/100

Pro scans all 10 files and shows the line behind each finding

Scanned 10/6/2026

$npx -y skills add Spkicn/mimic --skill mimic --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Mimic?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Mimic
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/spkicn-mimic/badge)](https://www.skillsdirectory.com/skills/spkicn-mimic)

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

Download with Pro
Files
SKILL.md
---
name: mimic
description: Use when an artifact or an implementation should follow the conventions proven by excellent open-source projects rather than the model's own habits. Triggers on "find similar projects on GitHub and see how they do it", "模仿", "参考同类开源项目", "别人是怎么写的", "how should we implement this", "what's the idiomatic way to do X", "how is this normally structured", "benchmark against comparable repos", "what stack do similar projects use", "make our README look professional", "how should we organise this repo". Four modes - stack selection, implementation shape (module boundaries, data model, error strategy, extension points), written artifacts (README/CONTRIBUTING/docs), and repository conventions (layout, commits, CI, lint, AGENTS.md). Not for renames, typos or version-independent logic, and never for copying source code.
license: MIT
metadata:
  version: "0.1.0"
  author: mimic
---

# Mimic

You are about to produce something a human will judge against the best projects in its
category. Your own defaults are the weakest possible reference: they are what every model
writes. This skill replaces "I think a good README looks like this" with "here are three
comparable projects, here is what their READMEs actually contain, and here is what ours
will contain and why".

The failure this skill exists to prevent is **confident invention** — a plausible-looking
conventions section, a stack recommendation, a star count, a license, an implementation,
all generated from memory. Every one of those is checkable, and a human will check.

## The one rule

> Every statement you make about a repository must trace to something you actually read:
> an API response you fetched, a file you opened, or a page you visited in this session.

If you did not read it, you may not assert it. Write "not checked" or "not found". A short
honest report beats a complete fabricated one.

## Modes

Pick exactly one mode, then read the reference files it names before doing anything else.

| If the question is | Mode | Read |
|---|---|---|
| "What stack / library / architecture should we use?" | **stack** | [reference/mimic-stack.md](reference/mimic-stack.md) |
| "How should we implement X? What shape should this module take?" | **implementation** | [reference/mimic-implementation.md](reference/mimic-implementation.md) |
| "Write / fix / restructure our README, docs, CONTRIBUTING" | **artifact** | [reference/mimic-readme.md](reference/mimic-readme.md) |
| "How should this repo be organised? commits, CI, lint, agent rules" | **conventions** | [reference/mimic-conventions.md](reference/mimic-conventions.md) |

Every mode also requires the three shared references. Read the ones that apply:

- [reference/selecting-repos.md](reference/selecting-repos.md) — **always**. How to find genuinely comparable projects instead of the most popular ones.
- [reference/evidence.md](reference/evidence.md) — **always**. How to record and label what you found, and how to spend a bounded research budget.
- [reference/licensing.md](reference/licensing.md) — **before writing anything derived from another project**. What you may take, and the hard lines.

If the request spans modes ("pick our stack and write the README"), do them in order and
finish the first one before starting the second. Do not blend them into one pass.

## The loop

1. **Frame.** Restate the goal in one sentence. Ask at most three questions, and only ones
   that change which projects count as comparable. If the request is too vague to identify
   a category, say so and ask — do not start searching.
2. **Select.** Name the capability you are missing before you search — searching your own
   stack returns peers, not teachers. Find 3–5 comparable projects using
   [selecting-repos.md](reference/selecting-repos.md), covering more than one knowledge layer.
   Record why each was included and what was rejected. Comparability beats popularity.
3. **Read.** Shallow-read all of them (metadata, README, root tree, dependency manifest);
   deep-read at most two. Fetch, never recall. Cache what you fetch. See
   [evidence.md](reference/evidence.md).
4. **Decide.** Separate repository facts from your own judgement, and label each one.
   State what you will adopt, what you will deliberately not adopt, and why. Run the
   license gate in [licensing.md](reference/licensing.md) before adopting anything.
5. **Write and self-check.** Produce the artifact — a real file on disk, not a chat
   suggestion. In implementation mode the artifact is the changed source plus its
   provenance block. Then run the completion gate below and report it.

## Completion gate

Do not report success until every line holds. Report the gate itself as part of your answer.

The first item decides whether the work was worth doing. Everything after it is about doing
it honestly.

- [ ] **Substance.** At least three claims in the artifact are specific and checkable — a
      number, a name, a path, a version, a date, or a quoted line, each traceable to a fetch.
      Test: delete every proper noun and number; if the artifact still reads complete, it is a
      template. A run can pass every other item here and still produce nothing; see
      [evidence.md](reference/evidence.md).
- [ ] 3–5 comparable projects, each with a stated reason for inclusion.
- [ ] At least one rejected candidate, with the reason for rejection.
- [ ] Every repository claim traceable to a file or API response read in this session.
- [ ] Facts and judgements visibly separated.
- [ ] License checked for every project whose content influenced the result.
- [ ] No source code copied. Structure and conventions only.
- [ ] The artifact exists on disk and you name its path — a written file, or in
      implementation mode the changed sources plus a provenance block.
- [ ] An explicit "adopted / deliberately not adopted / reason" list.
- [ ] Remaining uncertainty named rather than smoothed over.

## Hard lines

- **No network, no answer.** If you cannot reach GitHub or the web, say so and stop. Do not
  reconstruct repositories, stars, licenses, or directory trees from memory. Say what you
  would have checked.
- **Never copy code.** Read how a project structures something; write your own
  implementation. License compatibility is a permission question, not a permission to copy
  — see [licensing.md](reference/licensing.md). In implementation mode this is enforced by
  the clean-room two-step in [mimic-implementation.md](reference/mimic-implementation.md):
  describe the pattern in your own words first, close the source, then write.
- **Never let one project be the answer.** A single admired repository is a taste, not a
  convention. Three is the floor.
- **Never mimic decoration.** Emoji headers, badge walls, and colour schemes are not
  conventions. What transfers is structure and commitments: what sections exist, what each
  promises, what a newcomer can do after reading.
- **Write files.** If the deliverable is a README, the deliverable is `README.md` on disk.
  Unless the user explicitly asked for advice only.

## Anti-patterns

| Anti-pattern | What it looks like | Do instead |
|---|---|---|
| **A template with a clean conscience** | Every process item passed; the output names nothing, numbers nothing, shows nothing | The substance gate at the top of [evidence.md](reference/evidence.md) |
| **Peer-only slate** | Every comparable is another project in your own stack | Name the capability you lack, then search that discipline's vocabulary — [selecting-repos.md](reference/selecting-repos.md) |
| Popularity theatre | "Top 5 by stars" | Filter by comparability, then report maintenance and license |
| README-only archaeology | Claiming to know the architecture from the README | Open the tree, the manifest, and the entry point |
| Consensus by assertion | "Most projects use X" | Name which projects, and cite the file that shows it |
| Template transplant | Pasting a famous repo's README structure wholesale | Adopt sections that fit this project; name what you dropped |
| Silent staleness | Presenting a 2019 repo as current | Report `pushed_at` and archived status for every candidate |
| Fabricated precision | "12.4k stars, MIT" with no fetch | Fetch it or write "not checked" |

Attribution

SpkicnSpkicn
View sourceSee grades on GitHubMore from Spkicn →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

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 (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Caveman

Terse caveman voice: answer first, fluff gone, every technical fact kept. Use for /caveman, "caveman mode", "talk like caveman", "be brief", "less tokens". Stays on until "stop caveman" or "normal mode".

1100021 votes

Hyperplan

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', ...

698621 votes

Writing Skills

Create and manage Claude Code skills in HASH repository following Anthropic best practices. Use when creating new skills, modifying skill-rules.json, understanding trigger patterns, working with hooks, debugging skill activation, or implementing progressive disclosure. Covers skill structure, YAML frontmatter, trigger types (keywords, intent patterns), UserPromptSubmit hook, and the 500-line rule. Includes validation and debugging with SKILL_DEBUG. Examples include rust-error-stack, cargo-dep...

3931 votes

Mcp Code Execution

Routes multi-tool workflows through MCP servers for large datasets and pipelines. Use when Bash tool overhead is limiting throughput on data-heavy tasks.

3421 votes

catchup

Recovers the conversation and failed tool calls of a previous Codex, Amp, Claude Code, Antigravity, Cline, Copilot CLI, Cursor, DeepSeek Harness, Grok Build, Kimi, OpenCode, Pi Agent, or ZCode session. Use when the user says "catch up", "what did the last session do", "get me up to speed", "I switched agents", asks to recover/summarize a previous session before continuing, or asks to diagnose or report a catchup failure. Do NOT use for the current conversation, git history, or any non-agent log.

741 votes
View all in ai-agents →