agentleFS
oschinaoschina/gitee-agent-skills/skills/create-issue/SKILL.md

create-issue

Skill4 starsChanged 7 months agoMITView on GitHub

Use this skill when the user wants to create a new issue, report a bug, submit a feature request, or discuss a requirement before implementation. "create issue", "report bug", "create-issue", "submit issue", "新建 issue", "提需求", "提 bug". Requires Gitee MCP Server to be configured.

63 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use native-nostalgia-stack, software-engineering-excellence and 6 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • frostneySkill

    native-nostalgia-stack

    Applies the user's FreePascal toolchain and its build, formatting, hook, and test contracts while leaving project-specific mechanics local. Use when scaffolding or working in a FreePascal project that follows this toolchain.

    Also in 3 projects that use this

  • frostneySkill

    software-engineering-excellence

    Applies the user's engineering standards during substantial technical work: preserve scope, use current evidence, delegate independent parts, and complete authorized outcomes. Use during substantial implementation, debugging, refactoring, or multi-part delivery work.

    Also in 3 projects that use this

  • withpiperSkill

    roadmap-review

    Audit roadmap health — issues, dependency order, spec coverage, doc freshness. Use when speccing a new initiative. Use when /phase-plan output looks suspicious. Use before /roadmap-create reruns.

    Also in 3 projects that use this

  • MicrosoftSkill

    update-pr

    Update the pull request for the current session. Use when the user wants to push new changes to an existing PR.

    Also in 3 projects that use this

  • TermiX-officialSkill

    merge-pr

    Merge a GitHub PR via squash after /preparepr. Use when asked to merge a ready PR. Do not push to main or modify code. Ensure the PR ends in MERGED state and clean up worktrees after success.

    Also in 3 projects that use this

  • Model Context ProtocolSkill

    project-structure

    Where things live in the Inspector repo — which client owns which surface, what is in core/ versus clients/web, and what each top-level directory is for. Use when locating code, deciding where a new module belongs, or answering which package owns or contains a given area of the codebase.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. 0 are common, 9 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 53 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create a well-structured Issue on Gitee after clarifying the requirements with the user.

    line 14
  2. Distinctive:

    If the user hasn't specified a repository, ask which scenario:

    line 26
  3. Very specific:

    Use list_user_repos to list repositories the user has access to

    line 29
  4. Very specific:

    Use search_open_source_repositories to search for the repository

    line 33
  5. Very specific:

    Verify by checking the repository URL format (owner/repo)

    line 34
  6. Very specific:

    If the user provides a repository directly (format: owner/repo), verify it exists by confirming with the user.

    line 36
  7. Distinctive:

    Use the following template to structure the discussion:

    line 60
  8. Distinctive:

    Before creating the Issue:

    line 94
  9. Very specific:

    Check if a similar Issue already exists using list_repo_issues

    line 96
  10. Distinctive:

    If duplicates are found, present them to the user

    line 97
  11. Very specific:

    Use create_issue to create the Issue with the following parameters:

    line 103
  12. Distinctive:

    Ask if the user wants to:

    line 125
  13. Very specific:

    Start implementing (use implement-issue skill)

    line 126
  14. Distinctive:

    Always confirm the Issue details with the user before creating it

    line 167
  15. Distinctive:

    Search for existing Issues first to avoid duplicates

    line 168
  16. Distinctive:

    Use clear, descriptive titles that summarize the issue in one line

    line 169
  17. Very specific:

    If the user wants to immediately work on the Issue, suggest using the implement-issue skill afterwards

    line 172

“Common” is measured: kept by at least 6 in 10 of the 53 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Note: If you have mcporter installed locally, you should use mcporter to invoke the MCP tool instead of directly calling the MCP tool. The mcporter CLI provides a more convenient interface and better error handling.

Create Issue via Gitee MCP

Create a well-structured Issue on Gitee after clarifying the requirements with the user. This skill is designed for discussions about new requirements, improvements, or bug reports before they are formally created as Issues.

Prerequisites

  • Gitee MCP Server configured (tools: create_issue, list_repo_issues, list_user_repos, search_open_source_repositories)
  • User must provide: repository owner/name (or search/select from available repositories)
  • Optional: issue type (feature/bug/enhancement), priority, labels

Steps

Step 1: Identify the Target Repository

If the user hasn't specified a repository, ask which scenario:

Scenario A: User's own/private repository

  • Use list_user_repos to list repositories the user has access to
  • Let user select from the list

Scenario B: Open source/public repository

  • Use search_open_source_repositories to search for the repository
  • Verify by checking the repository URL format (owner/repo)

If the user provides a repository directly (format: owner/repo), verify it exists by confirming with the user.

Step 2: Clarify the Issue Content

Discuss with the user to gather the following information:

For Bug Reports:

  • What is the expected behavior?
  • What is the actual behavior?
  • How to reproduce the issue (reproduction steps)?
  • Environment details (OS, version, browser, etc.)
  • Any error messages or logs?

For Feature Requests:

  • What problem does this feature solve?
  • What is the proposed solution?
  • Are there any similar features in other projects for reference?
  • Any design preferences or constraints?

For Improvements:

  • What aspect needs improvement?
  • What are the suggested improvements?
  • What is the expected outcome?

Use the following template to structure the discussion:

## Issue Information

**Type:** [Bug / Feature / Enhancement / Question / Other]

**Title:** [Brief description - keep it under 50 characters]

**Description:**
[Detailed description of the issue]

**Reproduction Steps (for bugs):**
1. Step 1
2. Step 2
3. Step 3

**Expected Behavior:**
[What should happen]

**Actual Behavior:**
[What actually happens]

**Environment:**
- OS:
- Version:
- Browser (if applicable):

**Additional Context:**
[Any other relevant information, screenshots, logs, etc.]

Step 3: Validate and Refine

Before creating the Issue:

  1. Check if a similar Issue already exists using list_repo_issues
  2. If duplicates are found, present them to the user
  3. Refine the title and description based on discussion
  4. Confirm with the user before creating

Step 4: Create the Issue

Use create_issue to create the Issue with the following parameters:

  • owner: repository owner
  • repo: repository name
  • title: Issue title (concise and descriptive)
  • body: Issue description (detailed and well-structured)
  • labels: (optional) comma-separated list of labels like bug, feature, enhancement

Label recommendations:

TypeLabels
Bugbug
Featurefeature
Enhancementenhancement
Questionquestion
Documentationdocs

Step 5: Confirm and Summary

After successful creation:

  1. Display the Issue URL to the user
  2. Summarize what was created
  3. Ask if the user wants to:
    • Start implementing (use implement-issue skill)

Example Conversations

Example 1: Bug Report

User: I found a bug in the login page - it doesn't show error message when password is wrong.

You: Let me help you create a bug report. Could you please clarify:
1. What is the expected behavior? (e.g., "Show 'Invalid credentials' message")
2. What is the actual behavior? (e.g., "Nothing happens, page just reloads")
3. How to reproduce? (e.g., "Enter wrong password and click login")
4. What browser and OS are you using?

User: [Provides details...]

You: Here's the Issue I've prepared:
Title: Login page doesn't show error message for invalid credentials
...
Should I create this Issue?

Example 2: Feature Request

User: I want to add dark mode to the app.

You: Great idea! Let me understand more about this feature:
1. What problem does dark mode solve? (e.g., "Reduce eye strain at night")
2. Should it follow system preference or be user-toggleable?
3. Any reference implementations you have in mind?

User: [Provides details...]

You: Here's the Issue I've prepared:
Title: Add dark mode support
...
Should I create this Issue?

Notes

  • Always confirm the Issue details with the user before creating it
  • Search for existing Issues first to avoid duplicates
  • Use clear, descriptive titles that summarize the issue in one line
  • Include all necessary details in the description to help others understand and reproduce
  • For complex features, consider creating a technical design document as a comment after the Issue is created
  • If the user wants to immediately work on the Issue, suggest using the implement-issue skill afterwards

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.