make-issue-spec
The make-issue-spec tool generates a detailed markdown specification document for a software development task. Use it when you need to create clear, comprehensive issue documentation that outlines requirements, acceptance criteria, and implementation details. The tool prompts for clarification on ambiguous requirements and automatically stages the resulting specification in Git if permissions allow.
git clone --depth 1 https://github.com/pchalasani/claude-code-tools /tmp/make-issue-spec && cp -r /tmp/make-issue-spec/plugins/workflow/skills/make-issue-spec ~/.claude/skills/make-issue-specSKILL.md
# make-issue-spec There isn't a lot more to this than what the top level description says. The idea is for this issue spec to contain a clear specification of what is needed. Make sure to ask the user any questions for parts that you're not sure of or are under specified. Stage this in Git if you have permissions.
Use this skill when you learn one or more design pattern(s) in the
Literature-backed English technical-prose writing rules (agent-style, 21 rules). Its lane is FORMAL technical prose (papers, design docs, proposals, READMEs, commit messages). Use ONLY when the user explicitly asks for agent-style by name (e.g. "apply agent-style", "write/revise this per agent-style rules", "iterate until agent-style clean"). NOT for de-AI-ing casual or voiced text — use remove-ai-patterns for that. Do not auto-trigger for ordinary prose or documentation tasks.
Audit and rewrite content to remove AI writing patterns ("AI-isms"). Use this skill when asked to "remove AI-isms," "clean up AI writing," "edit writing for AI patterns," "audit writing for AI tells," or "make this sound less like AI." Supports a detect-only mode, an edit-in-place mode for files, an optional voice profile (casual / professional / technical / warm / blunt), and an iterate-to-convergence pass.
Use this when user wants you to walk through (code or text) files in a EDITOR to either explain how some code works, or to show the user what changes you made, etc. You would typically use this repeatedly to show the user your changes or code files one by one, sometimes with specific line-numbers. This way the user is easily able to follow along in their favorite EDITOR as you point at various files possibly at specific line numbers within those files.
>-
>-
Log the work segment that you did after the last work log until now in a
>-