Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

discovery-interview

Conduct an interactive discovery interview to produce a structured product specification. Triggers: write a spec, PRD, feature spec, requirements, product requirements, scope a project, brainstorm a feature, flesh out an idea, plan a new project. Uses AskUserQuestion for all user choices; WebSearch/WebFetch when the user wants research. Outputs: user stories, acceptance criteria, technical constraints, prioritized requirements in docs/specs/ per SPEC_TEMPLATE.md. Do NOT use for: implementation, code review, debugging, refactors, or when the user already has a complete spec they only want edited.

In Manus ausführen

Überblick

Installationsbefehl

npx skills add https://github.com/kvokov/oh-my-ai --skill discovery-interview

Kopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um den Skill zu installieren

Quelle

kvokov/oh-my-ai

Sterne4

Forks1

Aktualisiert6. April 2026 um 14:24

Datei-Explorer

7 Dateien

SKILL.md

readonly

name	discovery-interview
description	Conduct an interactive discovery interview to produce a structured product specification. Triggers: write a spec, PRD, feature spec, requirements, product requirements, scope a project, brainstorm a feature, flesh out an idea, plan a new project. Uses AskUserQuestion for all user choices; WebSearch/WebFetch when the user wants research. Outputs: user stories, acceptance criteria, technical constraints, prioritized requirements in docs/specs/ per SPEC_TEMPLATE.md. Do NOT use for: implementation, code review, debugging, refactors, or when the user already has a complete spec they only want edited.
metadata	{"version":"1.0.5","tags":"discovery, product-spec, PRD, requirements, AskUserQuestion, interviews, specs"}

Discovery Interview

Turn vague ideas into an implementable spec through ordered phases and targeted questions.

Non-negotiables (do not skip)

Run all 7 phases in order below. Do not jump to the spec early.
Minimum 10–15 questions across categories for any real project. Never treat 3–5 questions as enough.

Every AskUserQuestion must include an option for uncertainty (e.g. "I'm not sure" / "Research this").

Example AskUserQuestion call:

AskUserQuestion(
  question: "Which database are you planning to use?",
  options: ["PostgreSQL", "MySQL", "MongoDB", "I'm not sure", "Research this for me"]
)

At least one research loop for any non-trivial project (user accepts research → WebSearch/WebFetch or agent, then follow-up questions).

Example research loop: User selects "Research this for me" on a scaling question → WebSearch("serverless vs container hosting cost comparison 2024") + WebFetch(top result) → follow-up: "Based on the research, AWS Lambda looks cost-effective at your expected traffic. Does that align with your budget?"
Completeness check (Phase 5) must pass before writing the spec. If anything is missing, ask more; do not write the spec yet.
Summarize your understanding and get user confirmation before generating the spec file.
Write the spec to docs/specs/YYYY-MM-DD-<name>.md using SPEC_TEMPLATE.md. Create docs/specs/ if it does not exist.

Process

Execute phases in order. Detailed steps live in companion rules:

Phase	Focus	Rules
1	Initial orientation	orientation-and-deep-dive
2	Category deep dive	orientation-and-deep-dive
3	Research loops	research-and-conflict-resolution
4	Conflict resolution	research-and-conflict-resolution
5	Completeness check	completeness-spec-and-handoff
6	Spec generation	completeness-spec-and-handoff
7	Implementation handoff	completeness-spec-and-handoff

Integrated flow (one pass)

Orientation → deep dive categories for the project type → if unsure on stack/approach, research loop → if two goals conflict, conflict resolution → completeness table green → confirm summary → write spec file → handoff question.

Anti-patterns

Writing the spec after a handful of questions.
Skipping research when the user is guessing about tools or scale.
Leaving contradictions unresolved.
Writing the spec before the completeness check passes.

Mehr aus diesem Repository

gleiches Repository

nestjs

kvokov/oh-my-ai

NestJS (Nest.js) production patterns for modules, controllers, providers, guards, interceptors, pipes, middleware, JWT, ValidationPipe, microservices, GraphQL, Bull queues, Prisma, and TypeORM. Triggers: NestJS, Nest.js, Nest module, dependency injection, class-validator DTO, exception filter, testing module, GraphQL resolver, Bull queue, microservice client. Uses: Read, Grep, Glob, Bash, WebSearch. Outputs: tier-ordered review checklists and/or concrete code edits with cited rule filenames. Do NOT use for: non-Nest backends (Express/Fastify only with no Nest integration), frontend-only frameworks, generating AGENTS.md, or toolchain setup unrelated to Nest.

2026-04-304

uiux

kvokov/oh-my-ai

Professional UI/UX design skill for React, Next.js, Tailwind CSS, React Native, and Flutter. Use when the user asks to create or polish UI components (modals, forms, tables, charts, navbars, sidebars, cards), design landing pages, build dashboards or admin panels, set up SaaS or mobile app screens, review or fix layout and accessibility issues, configure dark mode or responsive breakpoints, or establish a design system with tokens and component specs. Capabilities include: creating design-system token files and MASTER.md artifacts, generating responsive Tailwind layouts, scaffolding page-level component hierarchies, reviewing and fixing UI accessibility (a11y, WCAG), implementing React Native safe-area screens, and configuring Flutter ThemeData. Outputs design-system files (MASTER, page overrides, tokens, component specs) plus stack-faithful code. Do NOT use for: pure backend-only work with no UI impact, or inventing branding assets you do not have rights to use.

2026-04-084

skill-maker

kvokov/oh-my-ai

Use this skill any time someone wants to create, scaffold, build, fix, improve, benchmark, or optimize a Tessl/Claude skill — even if they don't say 'tessl' explicitly. If the request involves making a new skill ('create a skill for X', 'build me a skill that does Y', 'scaffold a skill called Z'), fixing or completing an existing one (missing tile.json, broken repo integration, low eval scores, description not triggering), or running and iterating on evals, invoke this skill. The full workflow covers: structured interview → SKILL.md + tile.json + rules/ scaffolding → README/CI repo integration → tessl tile lint → optional Tessl CLI pipeline (skill review, scenario generate/download, eval run) → hand-authored evals or LLM-as-judge fallback → benchmark logging. Do NOT use for: editing application code, debugging, refactoring, writing general documentation, or creating presentations.

2026-04-084

reading-synthesis

kvokov/oh-my-ai

Rigorous thirteen-part synthesis of a text or talk: deep summary, insights, structure, critique, framework rebuild, and CEO-level takeaways. Triggers: reading synthesis, synthesize this, deep dive, rigorous analysis, deconstruct, book analysis, article analysis, essay breakdown, intellectual synthesis, multi-dimensional analysis, executive summary of ideas, framework extraction. Uses: Read (and related file tools) for attached sources; WebSearch or WebFetch when comparands are missing or context is thin. Outputs: single structured markdown message with fixed section headers per rules/output-sections.md.

2026-04-084

llm-wiki

kvokov/oh-my-ai

Compiles and maintains a persistent LLM-written markdown wiki between immutable raw sources and answers—the Karpathy LLM Knowledge Base pattern. The agent writes and maintains the wiki; the human curates sources and reads it. Knowledge compounds instead of being re-derived each query. Triggers: llm wiki, persistent wiki, personal knowledge base, wiki maintenance, ingest sources, compound knowledge, index.md, log.md, Obsidian wiki, cross-references, Karpathy wiki pattern, compile wiki, knowledge base. Uses: Read, Glob, Grep, file edits, optional WebSearch, AskUserQuestion when schema or goals are ambiguous. Outputs: updated wiki pages, index, append-only log, citations on query, filed answers, visual outputs. Do NOT use for: mutating raw sources, one-off chat answers with no wiki artifact, or replacing a user-defined wiki schema without reading it first.

2026-04-064

agent-init

kvokov/oh-my-ai

Creates, updates, or prunes an AGENTS.md for any repository by auditing the codebase, detecting non-discoverable gaps, and drafting minimal high-signal instructions. Triggers: AGENTS.md, agent setup, agent config, init agents, workspace setup, agent instructions, Claude setup. Uses: Read, Bash, Glob, Grep, AskUserQuestion. Outputs: AGENTS.md at repo root (or module-level for monorepos). Do NOT use for: writing README, generating docs, configuring CI, or editing code.

2026-04-064

Quelle

kvokov

kvokov/oh-my-ai

GitHub-Repository öffnen Creator-Repositorys ansehen

Installationsbefehl

Download

In Manus ausführen

Nützlich fürSOC

ProjektmanagementspezialistenWirtschafts- und Finanzberufe13-1082L4

name	discovery-interview
description	Conduct an interactive discovery interview to produce a structured product specification. Triggers: write a spec, PRD, feature spec, requirements, product requirements, scope a project, brainstorm a feature, flesh out an idea, plan a new project. Uses AskUserQuestion for all user choices; WebSearch/WebFetch when the user wants research. Outputs: user stories, acceptance criteria, technical constraints, prioritized requirements in docs/specs/ per SPEC_TEMPLATE.md. Do NOT use for: implementation, code review, debugging, refactors, or when the user already has a complete spec they only want edited.
metadata	{"version":"1.0.5","tags":"discovery, product-spec, PRD, requirements, AskUserQuestion, interviews, specs"}

Discovery Interview

Turn vague ideas into an implementable spec through ordered phases and targeted questions.

Non-negotiables (do not skip)

Run all 7 phases in order below. Do not jump to the spec early.
Minimum 10–15 questions across categories for any real project. Never treat 3–5 questions as enough.

Every AskUserQuestion must include an option for uncertainty (e.g. "I'm not sure" / "Research this").

Example AskUserQuestion call:

AskUserQuestion(
  question: "Which database are you planning to use?",
  options: ["PostgreSQL", "MySQL", "MongoDB", "I'm not sure", "Research this for me"]
)

At least one research loop for any non-trivial project (user accepts research → WebSearch/WebFetch or agent, then follow-up questions).

Example research loop: User selects "Research this for me" on a scaling question → WebSearch("serverless vs container hosting cost comparison 2024") + WebFetch(top result) → follow-up: "Based on the research, AWS Lambda looks cost-effective at your expected traffic. Does that align with your budget?"
Completeness check (Phase 5) must pass before writing the spec. If anything is missing, ask more; do not write the spec yet.
Summarize your understanding and get user confirmation before generating the spec file.
Write the spec to docs/specs/YYYY-MM-DD-<name>.md using SPEC_TEMPLATE.md. Create docs/specs/ if it does not exist.

Process

Execute phases in order. Detailed steps live in companion rules:

Phase	Focus	Rules
1	Initial orientation	orientation-and-deep-dive
2	Category deep dive	orientation-and-deep-dive
3	Research loops	research-and-conflict-resolution
4	Conflict resolution	research-and-conflict-resolution
5	Completeness check	completeness-spec-and-handoff
6	Spec generation	completeness-spec-and-handoff
7	Implementation handoff	completeness-spec-and-handoff

Integrated flow (one pass)

Anti-patterns

Writing the spec after a handful of questions.
Skipping research when the user is guessing about tools or scale.
Leaving contradictions unresolved.
Writing the spec before the completeness check passes.