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

始める

interview

スター0

フォーク0

更新日2026年4月14日 13:33

Interview the user to clarify requirements before building a large feature. Produces a SPEC.md.

インストール

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

Manusで実行

ソース

shin1ohno

shin1ohno/setup

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

ダウンロード

Manusで実行

Interview Skill

Purpose

Deeply explore requirements for a feature before implementation begins. The output is a written spec, not code.

Argument Parsing

$ARGUMENTS is a brief description of the feature. If omitted, use AskUserQuestion to ask what the user wants to build.

Workflow

Phase 1: Initial Understanding

Read any files referenced in $ARGUMENTS to understand the current state.

Phase 2: Interview

Use AskUserQuestion repeatedly to explore these dimensions:

User intent — What problem does this solve? Who benefits?
Scope — What is explicitly in scope? What is out of scope?
Technical implementation — What existing code, APIs, or infrastructure does this touch?
UI/UX — What does the user see? What interactions are needed?
Edge cases — What happens when input is invalid, the network fails, or data is missing?
Tradeoffs — What are we trading off (speed vs correctness, simplicity vs flexibility)?
Acceptance criteria — How do we know it works? What tests should pass?
Operations — How is this deployed? How do we monitor it? What does rollback look like?

Guidelines:

Ask 1-2 questions at a time, not a wall of questions
Skip dimensions that are obviously irrelevant (e.g., no UI/UX for a CLI tool)
Dig into the hard parts the user might not have considered
Stop when all dimensions are covered or the user says "that's enough"

Phase 3: Write Spec

Write SPEC.md in the project root containing:

Summary — One paragraph describing the feature
Requirements — Numbered list with priority (Must / Should / Could)
Non-requirements — Explicitly out of scope
Technical approach — High-level implementation plan
Edge cases — Known edge cases and how to handle them
Acceptance criteria — Testable conditions for "done"

Phase 4: Review

Present the spec to the user. Ask if anything needs to be added or changed before implementation.

このリポジトリの他の Skills

同じリポジトリ

todo-collect

shin1ohno/setup

config（~/.claude/todo/sources.yaml + sources.local.yaml）に列挙された外部 capture ソース — Slack saved（後で見る）/ 📌 リアクション / self-DM、Google Tasks、 Apple Reminders（remind --dump）、Claude Code transcript の deferral 発話、カレンダー連携 Notion 議事録 — を sweep し、 TODO 形に正規化（完了条件の起草 + provenance 付与）して機密性 routing どおりの memory store（ai-memory / memory-local）に tags:["todo"] で書き込む毎日ループ skill。 explicit ソース（明示マーク）は自動保存 + 領収書 1 行、inferred ソース（推論抽出）は候補提案のみ（承認後に保存）。dedup は provenance キー。結果は ~/.claude/todo/ledger.md に追記。設計の真実源は ~/.claude/docs/todo-management.md。「todo collect」「TODO 集めて」「capture 集めて」「TODO 収集」でトリガー。注: ソース側の状態は絶対に変更しない（Task の完了化・saved 解除等をしない）。例外は連携ストアの Apple Reminders のみ（リンクトークン annotate と close 伝播 complete）。仕事ソースの sink は memory-local 固定 — 個人 ai-memory へ流すのは egress 違反。

2026-07-080

todo-reconcile

shin1ohno/setup

全 TODO ストア（各 repo の TODO.md、ai-memory / memory-local の tags:["todo"]、 federated な GitHub issues）を横断列挙し、項目ごとに 2 秒 probe で stale を検出して済み / 前提消滅 / 継続 / 要判断に分類する、TODO 管理パイプラインの週次棚卸しループ skill。 probe なしの即答列挙（list モード）も担当。結果は ~/.claude/todo/ledger.md に書き出す。ストア設計・capture routing は ~/.claude/docs/todo-management.md が真実源。デフォルトは dry-run（列挙 + probe + 分類提案のみ。forget も TODO.md 編集もしない）。「todo reconcile」「TODO 棚卸し」「TODO 掃除」で dry-run、「TODO 見せて」「open な TODO は」で list モード、「LIVE mode」明記で適用モード。注: forget / TODO.md 編集は機械的証拠か明示承認がある場合のみ。TODO.md 編集は PR 経由（main 直 push 禁止）。issues と TODO.md は列挙するだけで複製しない。

2026-07-060

mcp-auth

shin1ohno/setup

Check the connection and authentication status of every MCP server and re-authenticate any that need it, one at a time. Use when the SessionStart MCP health hook reports "NEEDS-AUTH" / "MCP connectors need attention", when an mcp__* tool call fails with an auth or connection error, or when the user asks to check MCP status, reconnect MCP, "MCP 認証", "check mcp", "mcp 繋がってない", "認証されていない MCP を認証して".

2026-07-060

self-heal-resolve

shin1ohno/setup

self-heal observability ループの Layer 2-B（issue 解決）。shin1ohno/setup の open な self-heal ラベル issue を 1 件選び、fleet を調査して根本原因を特定し、修正する自律ループ。 allowlist 内の remediation class（既知サービスの再収束／cookbook drift 修正）は調査→修正→PR→CI green→merge→auto-mitamae 適用→機能検証→issue close まで完全自律。 allowlist 外（新規設計・破壊的変更・auth/secret・原因不明・3 回失敗）は PR/診断を残して self-heal-needs-human を付け停止。merge は CI green 必須、破壊的操作禁止、1 回 1 issue。 owner(shin1ohno) が issue/PR に付けたコメント・更新は GO 承認として拾い、needs-human でも再着手する（第三者のコメント・更新は無視。bot コメントは  で識別）。「self-heal resolve」「self-heal issue を直す」「fleet alert を解決」でトリガー。対は self-heal-create（ES 状態を issue 化する loop）。

2026-07-060

bootstrap-docs-hub

shin1ohno/setup

Scaffold a new documentation-hub repository for a project: README.md, CLAUDE.md (AI agent instructions), .claude/rules/ discipline files, bundled skills/agents (interview, retro, writing, notion-cli, claude-docs-researcher, session-retrospective, sync-bundled-tools), .gitignore, and an initial git commit. Use when user asks to "set up a docs hub", "create a documentation repository", "新しいプロジェクトのドキュメントハブを作る", "ドキュメント管理リポジトリを scaffold", "init docs project", or starts a fresh repo intended to manage external doc links (Notion, Slack, etc.) rather than source code.

2026-07-060

load-test

shin1ohno/setup

Progressive load testing and performance tuning for Docker services. Identifies hard constraints, finds breaking points, and proposes tuning within safe limits.

2026-07-060

Interview Skill

Purpose

Deeply explore requirements for a feature before implementation begins. The output is a written spec, not code.

Argument Parsing

$ARGUMENTS is a brief description of the feature. If omitted, use AskUserQuestion to ask what the user wants to build.

Workflow

Phase 1: Initial Understanding

Read any files referenced in $ARGUMENTS to understand the current state.

Phase 2: Interview

Use AskUserQuestion repeatedly to explore these dimensions:

User intent — What problem does this solve? Who benefits?

Scope — What is explicitly in scope? What is out of scope?

Technical implementation — What existing code, APIs, or infrastructure does this touch?

UI/UX — What does the user see? What interactions are needed?

Edge cases — What happens when input is invalid, the network fails, or data is missing?

Tradeoffs — What are we trading off (speed vs correctness, simplicity vs flexibility)?

Acceptance criteria — How do we know it works? What tests should pass?

Operations — How is this deployed? How do we monitor it? What does rollback look like?

Guidelines:

Ask 1-2 questions at a time, not a wall of questions

Skip dimensions that are obviously irrelevant (e.g., no UI/UX for a CLI tool)

Dig into the hard parts the user might not have considered

Stop when all dimensions are covered or the user says "that's enough"

Phase 3: Write Spec

Write SPEC.md in the project root containing:

Summary — One paragraph describing the feature

Requirements — Numbered list with priority (Must / Should / Could)

Non-requirements — Explicitly out of scope

Technical approach — High-level implementation plan

Edge cases — Known edge cases and how to handle them

Acceptance criteria — Testable conditions for "done"

Phase 4: Review

Present the spec to the user. Ask if anything needs to be added or changed before implementation.

name	interview
description	Interview the user to clarify requirements before building a large feature. Produces a SPEC.md.
user-invocable	true
argument-hint	[feature description]

name	interview
description	Interview the user to clarify requirements before building a large feature. Produces a SPEC.md.
user-invocable	true
argument-hint	[feature description]