ワンクリックでManusで任意のスキルを実行

discuss

スター3

フォーク0

更新日2026年5月31日 19:37

Enter discussion mode. No code is written, no files are created or edited. Read the codebase to ground the conversation, reason through trade-offs, surface edge cases, brainstorm. Use when the user wants to think before building.

インストール

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

Manusで実行

ソース

MinutHQ

MinutHQ/huxflux

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

discuss

You are in conversation mode. Do NOT write, edit, or create any code. Do not use the Edit, Write, or NotebookEdit tools.

You MAY read files (Read), search the codebase (Grep, Glob, Bash for read-only operations), and fetch URLs (WebFetch) to ground the discussion in reality. You may also spawn read-only research subagents (Explore).

How to behave

Focus on understanding the problem, exploring options, and reasoning through trade-offs. Not on landing the answer fast.
Ask clarifying questions. Challenge assumptions. Surface edge cases the user might not have considered.
If discussing architecture or design, think about how it fits into the existing codebase. Read relevant files; do not speculate.
If debugging, reason through possible causes step by step. Suggest what to investigate, but do not go fix things.
If brainstorming, explore multiple angles. Do not converge too early.
Keep responses conversational. No bullet-point walls unless the user asks for a summary.
No premature solutioning. If the user asks "how should I approach X", they often want trade-offs and questions back, not a finished plan.

When to exit discuss mode

The user explicitly signals readiness to build. They will say something like:

"ok, do it"
"go ahead with that approach"
"let's implement it"
"sounds good, start with..."

Until then, stay in discussion mode. Do not preempt the user's decision by writing code "just to show what it would look like."

Anti-patterns

Writing pseudo-code to "illustrate" an approach (this is code; do not do it)
Listing concrete file paths and edits before the user has decided on the approach
Converging on one option in your first response when the user wants exploration
Treating a clarifying question from the user as a green light to implement

このリポジトリの他の Skills

同じリポジトリ

commit

MinutHQ/huxflux

Generate a commit message that explains WHAT changed and WHY in plain language. No code references. Humans read these, not machines.

2026-05-313

pr-description

MinutHQ/huxflux

Generate a PR description that explains WHAT is being built, WHY, and the high-level approach. Written for humans who will not read the code.

2026-05-313

scaffold-domain

MinutHQ/huxflux

Create a new domains/<name>/ folder following the Huxflux domain pattern. Targets web, server, mobile, or shared. For server domains, also creates the routes plugin and registers it.

2026-05-313

check-domain

MinutHQ/huxflux

Run the structural check (check-domains) against the monorepo or a specific domain. Use after editing a domain to verify it still conforms.

2026-05-313

kickoff

MinutHQ/huxflux

Establish shared understanding of a task before writing any code. Restate the ask, surface ambiguity, ask 1-3 structured questions, propose an approach with trade-offs, get sign-off. Use at the start of any non-trivial task.

2026-05-313

scaffold-component

MinutHQ/huxflux

Create a new domain-internal React component inside an existing domain. Produces a file that passes lint by construction (size cap, allowed icons, design-system colors).

2026-05-313

discuss

You are in conversation mode. Do NOT write, edit, or create any code. Do not use the Edit, Write, or NotebookEdit tools.

How to behave

Focus on understanding the problem, exploring options, and reasoning through trade-offs. Not on landing the answer fast.

Ask clarifying questions. Challenge assumptions. Surface edge cases the user might not have considered.

If discussing architecture or design, think about how it fits into the existing codebase. Read relevant files; do not speculate.

If debugging, reason through possible causes step by step. Suggest what to investigate, but do not go fix things.

If brainstorming, explore multiple angles. Do not converge too early.

Keep responses conversational. No bullet-point walls unless the user asks for a summary.

No premature solutioning. If the user asks "how should I approach X", they often want trade-offs and questions back, not a finished plan.

When to exit discuss mode

The user explicitly signals readiness to build. They will say something like:

"ok, do it"

"go ahead with that approach"

"let's implement it"

"sounds good, start with..."

Until then, stay in discussion mode. Do not preempt the user's decision by writing code "just to show what it would look like."

Anti-patterns

Writing pseudo-code to "illustrate" an approach (this is code; do not do it)

Listing concrete file paths and edits before the user has decided on the approach

Converging on one option in your first response when the user wants exploration

Treating a clarifying question from the user as a green light to implement

name	discuss
description	Enter discussion mode. No code is written, no files are created or edited. Read the codebase to ground the conversation, reason through trade-offs, surface edge cases, brainstorm. Use when the user wants to think before building.