adhd-output-style
This skill should be used when the user asks for "ADHD output", "fewer output tokens", "short numbered steps", "limited working…
This skill should be used when the user asks to "create an issue", "file a bug", "report a problem", "rewrite an issue", or "improve an issue title or body".
$ npx -y skills add fcakyon/claude-codex-settings --skill create-issue --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/create-issueContext preview
The summary Claude sees to decide when to auto-load this skill.
This skill should be used when the user asks to "create an issue", "file a bug", "report a problem", "rewrite an issue", or "improve an issue title or body".
name: create-issue description: This skill should be used when the user asks to "create an issue", "file a bug", "report a problem", "rewrite an issue", or "improve an issue title or body".
An issue describes a problem or missing capability. A PR describes a proposed change. Keep their writing rules separate. For PRs, use [create-pr](../create-pr/SKILL.md).
Use a concise statement of the problem, naming the affected behavior. Do not use an imperative change request such as "Fix", "Add", "Enable", or "Keep" as the default.
Follow the repository's issue template and the user's requested format. Otherwise use:
## Problem One or two sentences naming the failure and its effect. ## Reproduction 1. The relevant setup or version. 2. The smallest steps that demonstrate the problem. ## Current behavior What was observed, with a short error or result when useful. ## Desired behavior The outcome the reporter needs.
For a missing feature, reproduce the current workflow that exposes the gap. If the problem was not reproduced, say so instead of inventing steps or results. Add environment details, evidence, or a proposed approach only when they help a maintainer act. Keep a possible implementation separate from the desired outcome.
Remove repeated explanations, promotional claims, conversation history, full diagnostic dumps, and details that do not help reproduce or resolve the issue. A few useful sections are better than a long narrative or a checklist of every investigation step.
Inspect repository guidance and templates, search for an existing issue, and verify the claims before publishing. When revising, read the current issue and preserve useful attachments, links, and user edits. Do not expand an issue's scope without user direction.
Use `gh issue create` or `gh issue edit` with `--title` and `--body-file`. Read back the published title and body. Link related PRs, but use a closing reference only when the PR addresses the issue's complete desired outcome.
Battle-tested Claude Code, OpenAI Codex, Cursor configs, plugins, hooks and agents with Kimi, MiniMax and GLM API support.
This skill should be used when the user asks for "ADHD output", "fewer output tokens", "short numbered steps", "limited working…
This skill should be used when the user asks to "build an AEO strategy", "improve AI search visibility", "track buyer prompts",…
Agent-browser usage guide. Read this before running any agent-browser commands. Covers the snapshot-and-ref workflow, navigating…
Reverse-engineer a website's internal API by recording browser traffic into a HAR file, then generate a standalone client or CLI…
Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to "dogfood", "QA",…