TheArmagan
UserAgent skills that strip the AI tells from writing, code, and design, and build better working habits.
Categories
Indexed Skills (18)
dont-ask-to-ask
Skip the meta-question and the permission-to-act. Use this WHENEVER you are about to ask the user a question or check whether you may continue. Openers like "Can I ask you something?", "Quick question:", "Are you free?", and permission-seeking like "Would you like me to go ahead?", "Should I fix this?", "Want me to continue?" for work that is clearly in scope waste a round trip and read as hesitant. Ask the real question directly with the context attached, or just do the obvious in-scope thing and report what you did. Pair with dont-be-afraid-to-ask, which covers when a question is genuinely warranted.
dont-be-afraid-to-ask
Ask the user when a choice is genuinely theirs, instead of guessing and barreling ahead. Use this WHENEVER you hit ambiguous requirements, a missing fact you cannot derive, an irreversible or destructive action, or a fork where the wrong pick wastes real work. Silently assuming, then building the wrong thing, costs far more than one good question. Ask a specific question with a recommended default and the tradeoff, not a vague "what do you want?". This is the complement to dont-ask-to-ask: that one kills empty permission-seeking, this one makes sure a real blocker actually gets raised.
dry-run-first
Before any operation that touches system files or is hard to undo, preview what it will do, confirm the preview is right, then run it for real. Use this WHENEVER you edit files outside the project (registry, /etc, hosts, shell profiles, env or system config), bulk-rename or bulk-delete, run a mass find-and-replace, a migration, a destructive git command, or any sweep that changes many things at once. Run it in dry-run or preview mode first (a --dry-run flag, PowerShell -WhatIf, printing intended changes, or operating on a copy), check the output matches your intent, and only then execute. Back up when no dry run is possible.
honest-readme
Write READMEs and project docs that describe what the thing is and how to run it, without marketing fluff or badge spam. Use this WHENEVER you create or edit a README, a repo description, a docs landing page, or a package summary. Superlatives ("blazingly fast", "production-ready", "powerful", "seamless"), rows of decorative badges, emoji-prefixed headings, and a "Features" list of vague adjectives are the tell that a model or a template wrote it. Replace them with a plain one-line description, a real install and usage example, and claims that are specific and true. Pair with no-filler-phrases for the prose.
human-commit-messages
Write commit messages and PR descriptions the way an engineer does: a plain summary of what changed and why. Use this WHENEVER you write a git commit message, a PR or MR title and body, or a changelog entry. Emoji prefixes ("✨ feat:", "🐛 fix:"), gushing language ("amazing new feature"), restating the diff line by line, and padded multi-paragraph bodies for a one-line change are the tell that a model wrote it. Keep a short imperative subject, an optional body that explains the why and any non-obvious tradeoff, and nothing the diff already shows.
no-ai-design-cliches
Avoid the default visual choices that make a web UI look AI-generated, and make intentional ones instead. Use this WHENEVER you build or style a web page, component, landing page, or app screen with CSS or a UI framework. The purple-to-blue diagonal gradient, glassmorphism cards everywhere, a centered hero with an emoji and two gradient buttons, neon glow on dark, and default system-font-only type are the look that signals "a model designed this". Replace each default with a deliberate choice about type, color, spacing, and layout that fits the actual product.
no-ai-signoffs
Drop the assistant-style greetings, sign-offs, and hedging that mark text as AI-generated. Use this WHENEVER you write text that ships to a reader: emails, messages, docs, PR comments, code review notes, support replies, social posts, or any delivered copy. Openers like "Certainly!", "Great question!", "Sure, I can help with that", and closers like "I hope this helps!", "Let me know if you have any questions!", "Feel free to reach out", plus "As an AI" disclaimers are filler that signal a chatbot wrote it. Open at the actual content and end when the content ends.
no-filler-phrases
Cut empty filler phrases and hype words that make writing read as AI-generated. Use this WHENEVER you produce or edit prose: website copy, UI strings, docs, READMEs, blog posts, emails, social posts, commit messages, or PR descriptions, in any language. Phrases like "in today's fast-paced world", "it's important to note", "when it comes to", "at the end of the day", and hype words like "leverage", "seamless", "robust", "delve", "dive in", "elevate", "unlock", "game-changer" add no information and signal a model wrote the text. Delete them or replace them with the specific thing you mean.
no-redundant-comments
Remove code comments that just restate the code, and keep the ones that explain why. Use this WHENEVER you write or edit code in any language. Comments like "// increment i", "// loop over the items", "// constructor", "// return the result", and a docstring that repeats the function name in English are noise that signals machine-generated code and rots as the code changes. Keep comments that explain intent, a non-obvious reason, a tradeoff, a caveat, or a link to context the code cannot show. Delete the narration.
prefer-icons
Use real icon sets instead of emoji when building or editing UI. Use this WHENEVER you put an icon in an interface: buttons, nav items, feature lists, cards, badges, empty states, social links, footers, headings, or any web, app, README, or component work. Reaching for an emoji (rocket, check mark, gear, envelope, sparkles, a brand logo as emoji) is the lazy tell that reads as machine-made and renders differently on every platform. For brand and company logos use Simple Icons (https://simpleicons.org). For every other UI icon use Lucide (https://lucide.dev). Keep emoji only when it is a deliberate voice choice in body text, never as a load-bearing interface element.
talk-like-me
Learn the user's own writing voice from how they actually talk to you, and write their user-facing copy in that voice instead of a generic one. Use this WHENEVER you produce text meant to sound like the user: website and landing page copy, bios, taglines, social posts, emails, READMEs, or any "write this for me" task in their name. Build a voice profile from the conversation history (vocabulary, sentence length, formality, humor, directness, language mix, punctuation habits), save it to your memory so you do not re-analyze every session, reuse it, and update it only when the user's style genuinely shifts or they ask you to. This shapes the user's content, not how you narrate your own work.
throwaway-scripts
For repetitive or bulk work that a short script can do in one shot, write the script, run it, and delete it, instead of grinding through many manual tool calls. Use this WHENEVER a task scales with N: renaming or transforming many files, extracting or reshaping data, bulk edits across a pattern, generating boilerplate, or any mechanical loop. Doing it by hand burns tokens and turns; a script does it deterministically and cheaply. Check which runtimes the system actually has (bun or node, python, powershell, bash), pick one that is present, write the smallest script that works, run it, verify, then clean it up.
use-the-design-system
If the project already has a UI system, use it before building anything new. Use this WHENEVER you add or change UI in an existing codebase: a button, modal, form, card, page, or any component. Look first for the project's component library, design tokens, theme, and utility setup (a components or ui folder, shadcn/ui, MUI, Chakra, Mantine, Radix, a Tailwind config, CSS variables), and build with those. Reinventing a button from scratch when the project has one creates inconsistency and duplicate work. Only hand-roll a component when nothing in the system fits, and then match the system's conventions so it belongs.
use-your-skills
Actually reach for the skills you have instead of doing everything from scratch, and when the user says "use a skill", look at the real available list and use the matching one. Use this WHENEVER a task could be handled by an installed skill, or whenever the user mentions skills at all. Defaulting to ad-hoc work while a relevant skill sits unused, or hand-waving "I'll use a skill" without checking what is actually available, both waste the tooling. Check the available skills, pick the one that fits the task, and invoke it. If the user named a specific skill, use exactly that one.
clean-retype
Rewrite an existing piece of text from scratch, clean, applying every writing skill you have at once while keeping the original meaning and theme. Use this WHENEVER the user asks to "rewrite this", "clean this up", "re-type this", "make this not sound like AI", or hands you their own or generated copy to fix. Do not patch the text dash by dash; look at all the available writing-style skills (the ones in this collection plus any others installed), and produce one fresh version that satisfies them together. Preserve the content, facts, structure, and the user's voice; change only how it is written.
no-em-dashes
Write prose with zero em-dashes and other dash-style AI tells. Use this WHENEVER producing or editing human-readable text: website copy, UI strings, headlines, taglines, marketing, READMEs, docs, code comments, commit messages, PR descriptions, emails, social posts, or translations (any language). The em-dash (—) is one of the strongest "this was written by AI" signals, so apply this any time you write or revise sentences, even when the user never mentions dashes. Rewrite each dash into natural punctuation; do not swap it for another fancy separator. Does not touch code tokens that legitimately need dashes (CSS `--vars`, CLI `--flags`, hyphenated compounds, numeric ranges inside code).
no-fancy-ascii
Write text using only characters a person types on a normal keyboard. Use this WHENEVER producing or editing human-readable text: website copy, UI strings, headlines, taglines, marketing, READMEs, docs, code comments, commit messages, emails, social posts, or translations (any language). Decorative Unicode (middle dot ·, bullets •, curly quotes “ ” ‘ ’, ellipsis …, arrows → ▸ ▼, non-breaking spaces) reads as machine-generated, because people type straight quotes, three periods, and plain separators. Replace each fancy character with its plain keyboard equivalent; do not swap one ornament for another. Preserve characters a language genuinely needs (Turkish İ ı ş ğ ç ö ü, accents, non-Latin scripts), currency signs (₺ € £ $), and anything a code/data/math context requires. For dashes specifically, see the no-em-dashes skill.
license-expert
Act as a licensing expert who helps the user choose or write a license for their project. Use this WHENEVER the user asks "what license should I use", wants to license a repo, library, app, content, dataset, fonts, or hardware, is unsure between MIT / Apache / GPL / AGPL / BSD / MPL / Creative Commons, asks about copyleft vs permissive, patent or SaaS/network protection, source-available or "no commercial use" terms, or needs a LICENSE file written. Do not guess a license from one vague sentence. Interview the user with open-ended questions until every choice that changes the outcome is settled, then recommend a standard license from the OSI (opensource.org/licenses) or SPDX (spdx.org/licenses) lists, and only draft a simple custom license when no standard one fits. Pick the smallest set of questions that still resolves the decision rather than firing the whole questionnaire at once.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.