# Simple Issue Description

Turn a rough bug report, feature request, support note, or pull request into a short...

- Repository: https://github.com/every-app/open-seo (25988 stars)
- Category: Git and review
- License: MIT
- Last updated: 2026-10-31
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add every-app/open-seo --skill simple-issue-description -g -a claude-code -y`
Codex: `npx skills add every-app/open-seo --skill simple-issue-description -g -a codex -y`
Cursor: `npx skills add every-app/open-seo --skill simple-issue-description -g -a cursor -y`
Gemini CLI: `npx skills add every-app/open-seo --skill simple-issue-description -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add every-app/open-seo`

## Description

Turn a rough bug report, feature request, support note, or pull request into a short, plain-language issue focused on the problem and desired behavior. Use when a contributor asks to simplify an issue, explain what a PR is for, create the corresponding issue for a PR, remove implementation detail from a report, or invokes /simple-issue-description.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Simple Issue Description

Write an issue a maintainer can understand in under a minute. Focus on what someone experiences and what should happen instead.

## Workflow

1. Read the supplied notes, conversation, issue, PR description, or diff. In a PR, also check for spec, design doc, or README changes, they often state the intent better than the description does.
2. Identify the concrete problem. State who or what is affected when the source makes that clear.
3. Describe the desired behavior without prescribing an implementation.
4. Keep only context that helps someone understand or reproduce the problem.
5. If the source is a PR or diff, describe the problem the change tries to solve, not the files or code it changes.
6. Draft the issue immediately unless the problem and desired behavior cannot be determined. In that case, ask one short clarifying question.

One issue per problem. If the source bundles unrelated problems, draft the issue for the most significant one, list the others in a line each, and tell the contributor to split them into separate issues and separate pull requests.

If the source adds a capability instead of fixing a misbehavior, do not stage the absence as a bug. Describe what a user cannot do today and the full user experience of the feature: who uses it, from where, and what they see.

Do not invent user impact, reproduction steps, or certainty that the source does not support. If the source only shows cleanup, refactoring, or a possible code smell, say that no concrete problem is clear instead of manufacturing an issue, this rule wins over step 6. Reply with two or three sentences: what the source shows, and what evidence would make it issue-worthy.

If the source fixes a security weakness that is not already public, do not draft a public issue describing it. Suggest reporting it privately to the maintainer instead.

## Writing rules

The rest: https://github.com/every-app/open-seo/blob/HEAD/.agents/skills/simple-issue-description/SKILL.md