cuga-new-feature

# Create a new issue (upstream)

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。

npx skills add https://github.com/cuga-project/cuga-flo --skill cuga-new-feature

コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。

ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md

ソースの指示 · 読み取り専用プレビュー

name	cuga-new-feature
description	# Create a new issue (upstream)
metadata	{"user-invocable":true,"disable-model-invocation":true}

Create the issue with the GitHub CLI (gh issue create).
Open it against the origin upstream (use that remote / repository—not a fork-only default).
Labels: run gh label list for that upstream repository. Only use names that appear in that output. Always pass --label needs-triage and add other applicable labels. Do not invent label names.

Choose the correct title prefix based on the issue type:

Prefix	When to use
`[Feature]`	New functionality or capability
`[Design]`	Architecture, API design, or UX proposal before implementation
`[Refactor]`	Internal restructuring with no behavior change
`[Performance]`	Speed, memory, or efficiency improvements
`[Security]`	Vulnerability, safety concern, or hardening
`[Docs]`	Documentation additions or corrections
`[Test]`	Missing tests, flaky tests, or test infrastructure
`[Chore]`	Dependency updates, cleanup, or tooling
`[Epic]`	Large body of work grouping multiple issues
`[Question]`	Clarification needed, not a task

Write the body using the same sections as .github/ISSUE_TEMPLATE/feature_request.yml: What you want and why, How it could work, Links or extra context (if any). Incorporate the user's message and any selected editor/context so the issue is concrete and complete.
Do not add "Made with Cursor" or similar promotional footers to the issue.

1. Commit current changes, one per file or (depends what user asks), but if its build files then all build files one commit

### Step 1: Validate Your Local Repository do it all against upstream `origin`

# Report a bug (upstream issue)

name	cuga-new-feature
description	# Create a new issue (upstream)
metadata	{"user-invocable":true,"disable-model-invocation":true}

Create the issue with the GitHub CLI (gh issue create).
Open it against the origin upstream (use that remote / repository—not a fork-only default).
Labels: run gh label list for that upstream repository. Only use names that appear in that output. Always pass --label needs-triage and add other applicable labels. Do not invent label names.

Choose the correct title prefix based on the issue type:

Prefix	When to use
`[Feature]`	New functionality or capability
`[Design]`	Architecture, API design, or UX proposal before implementation
`[Refactor]`	Internal restructuring with no behavior change
`[Performance]`	Speed, memory, or efficiency improvements
`[Security]`	Vulnerability, safety concern, or hardening
`[Docs]`	Documentation additions or corrections
`[Test]`	Missing tests, flaky tests, or test infrastructure
`[Chore]`	Dependency updates, cleanup, or tooling
`[Epic]`	Large body of work grouping multiple issues
`[Question]`	Clarification needed, not a task

Write the body using the same sections as .github/ISSUE_TEMPLATE/feature_request.yml: What you want and why, How it could work, Links or extra context (if any). Incorporate the user's message and any selected editor/context so the issue is concrete and complete.
Do not add "Made with Cursor" or similar promotional footers to the issue.