omh-deep-interview

Name: omh-deep-interview
Author: witt3rd

117stars9forks

How to install omh-deep-interview?

witt3rd/oh-my-hermes/omh-deep-interview

$npx -y skills add witt3rd/oh-my-hermes --skill omh-deep-interview

Installs into the current project.

Summary

Socratic reqs interview; clarify vague/ambiguous goals

Files · 1

View on GitHub

SKILL.md

1	# OMH Deep Interview — Requirements Specification Through Conversation
2
3	## When to Use
4
5	- The goal is vague, underspecified, or could be interpreted multiple ways
6	- Before planning (omh-ralplan) or implementation on non-trivial work
7	- The user says: "deep interview", "requirements", "what should we build", "help me think through this"
8	- omh-ralplan determines the goal is too ambiguous to plan
9	- You're unsure what the user actually wants
10	- Domain unfamiliarity: if the goal requires external knowledge of an unfamiliar domain, suggest running `omh-deep-research` first to gather context, then resume the interview with the confirmed report as input.
11
12	## When NOT to Use
13
14	- The goal is already crystal clear and bounded
15	- A confirmed spec already exists in `.omh/specs/` for this project
16	- The user explicitly wants to skip requirements gathering
17	- Trivial single-file changes where the task is obvious
18
19	## Prerequisites
20
21	- Conversational access to the user (this skill asks questions and needs answers)
22	- Write access to `.omh/` directory for state and spec files
23
24	## Procedure
25
26	Follow these phases in order. The skill operates through conversation with the user
27	and file writes for state and spec output.
28
29	### Phase 0: Check for Existing State
30
31	Before starting a new interview:
32
33	1. Enumerate active interviews:
34	```
35	listed = omh_state(action="list_instances", mode="interview")
36	```
37	Each entry carries `instance_id` (the interview id) and `active` flag.
38	If `omh_state` is unavailable, glob `.omh/state/interview--*.json` manually.
39	2. If any active interview exists, tell the user: "There's an active interview for '{project_name}' (id={id}). Resume, start fresh, or abandon it?"
40	3. If resuming: `omh_state(action="read", mode="interview", instance_id="{id}")` — read round summaries to reconstruct context
41	4. If abandoning: `omh_state(action="write", mode="interview", instance_id="{id}", data={...status: "abandoned"})`, then proceed to Phase 1 with a NEW id
42	5. If no active state found: proceed to Phase 1
43	6. Concurrent interviews on different projects are permitted; do not block.
44	6. Check for existing research context (omh-deep-research sentinel):
45	if any `.omh/research/*-report.md` exists with frontmatter
46	`status: confirmed`, mention it to the user as available context for
47	the interview (e.g., "I see a confirmed research report on '{topic}'
48	at `{path}` — want me to fold that in as background?"). Do NOT
49	auto-load it; the user decides.
50
51	### Phase 1: Opening
52
53	Start the interview with two questions:
54
55	1. Project description: "Describe what you want to build in 2-3 sentences. What's the core idea?"
56	2. Greenfield or brownfield: "Is this a new project from scratch, or are you working within an existing codebase or system?"
57
58	Then:
59	- Generate an interview ID: `di-{YYYYMMDD}-{short_random}` (e.g., `di-20260407-x7k`)
60	- Ask the user for a short project name (for filenames)
61	- Create the state file at `.omh/state/interview--{id}.json` (engine derives this from `instance_id="{id}"`) with:
62	- All coverage dimensions set to `HIGH`
63	- `type` set to `greenfield` or `brownfield` based on user's answer
64	- `existing_context` coverage set to `N/A` for greenfield projects
65	- Round 0 summary capturing the opening answers
66	- Tell the user: "Got it. I'll ask up to 5 rounds of questions to clarify requirements. You can say 'enough' at any point if you feel we've covered what's needed."
67
68	### Phase 2: Interview Loop
69
70	Run up to 5 rounds (extensible to 10 if user requests). Each round:
71
72	Step 1 — Select dimension to probe
73
74	Compare coverage bins across dimensions. Target the dimension with the highest ambiguity.
75	When multiple dimensions share the same bin, use weights to break ties:
76	- Greenfield: Goal (0.40) > Constraints (0.30) = Success Criteria (0.30)
77	- Brownfield: Goal (0.35) > Constraints (0.25) = Success Criteria (0.25) > Existing Context (0.15)
78
79	Load `references/scoring-rubric.md` for detailed bin definitions and examples.
80
81	Step 2 — Ask the question
82
83	Ask ONE primary question targeting the selected dimension. Make it specific and
84	grounded in what the user has already told you. Don't ask generic questions — reference
85	their earlier answers.
86
87	Good: "You mentioned this is a CLI tool for personal use. What happens when you run it with no tasks configured — should it create a default list, show an error, or something else?"
88
89	Bad: "What are your constraints?"
90
91	Allow 1-2 brief follow-ups if the user's answer is unclear, contradictory, or raises
92	new questions. Don't force follow-ups if the answer is clear.
93
94	Step 3 — Adaptive questioning (if stuck)
95
96	If a dimension has been targeted for 2 or more consecutive rounds without moving from
97	its current bin, chan

People who liked this also viewed

6 picks

Type

paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026157k5
subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026154k259k
dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026143k259k
browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 202685k4.6k
wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 202675k182k
wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 202666k137

omh-deep-interview

117stars9forks

View on GitHub

How to install omh-deep-interview?

witt3rd/oh-my-hermes/omh-deep-interview

$npx -y skills add witt3rd/oh-my-hermes --skill omh-deep-interview

Installs into the current project.

Summary

Socratic reqs interview; clarify vague/ambiguous goals

Files · 1

View on GitHub

SKILL.md

1	# OMH Deep Interview — Requirements Specification Through Conversation
2
3	## When to Use
4
5	- The goal is vague, underspecified, or could be interpreted multiple ways
6	- Before planning (omh-ralplan) or implementation on non-trivial work
7	- The user says: "deep interview", "requirements", "what should we build", "help me think through this"
8	- omh-ralplan determines the goal is too ambiguous to plan
9	- You're unsure what the user actually wants
10	- Domain unfamiliarity: if the goal requires external knowledge of an unfamiliar domain, suggest running `omh-deep-research` first to gather context, then resume the interview with the confirmed report as input.
11
12	## When NOT to Use
13
14	- The goal is already crystal clear and bounded
15	- A confirmed spec already exists in `.omh/specs/` for this project
16	- The user explicitly wants to skip requirements gathering
17	- Trivial single-file changes where the task is obvious
18
19	## Prerequisites
20
21	- Conversational access to the user (this skill asks questions and needs answers)
22	- Write access to `.omh/` directory for state and spec files
23
24	## Procedure
25
26	Follow these phases in order. The skill operates through conversation with the user
27	and file writes for state and spec output.
28
29	### Phase 0: Check for Existing State
30
31	Before starting a new interview:
32
33	1. Enumerate active interviews:
34	```
35	listed = omh_state(action="list_instances", mode="interview")
36	```
37	Each entry carries `instance_id` (the interview id) and `active` flag.
38	If `omh_state` is unavailable, glob `.omh/state/interview--*.json` manually.
39	2. If any active interview exists, tell the user: "There's an active interview for '{project_name}' (id={id}). Resume, start fresh, or abandon it?"
40	3. If resuming: `omh_state(action="read", mode="interview", instance_id="{id}")` — read round summaries to reconstruct context
41	4. If abandoning: `omh_state(action="write", mode="interview", instance_id="{id}", data={...status: "abandoned"})`, then proceed to Phase 1 with a NEW id
42	5. If no active state found: proceed to Phase 1
43	6. Concurrent interviews on different projects are permitted; do not block.
44	6. Check for existing research context (omh-deep-research sentinel):
45	if any `.omh/research/*-report.md` exists with frontmatter
46	`status: confirmed`, mention it to the user as available context for
47	the interview (e.g., "I see a confirmed research report on '{topic}'
48	at `{path}` — want me to fold that in as background?"). Do NOT
49	auto-load it; the user decides.
50
51	### Phase 1: Opening
52
53	Start the interview with two questions:
54
55	1. Project description: "Describe what you want to build in 2-3 sentences. What's the core idea?"
56	2. Greenfield or brownfield: "Is this a new project from scratch, or are you working within an existing codebase or system?"
57
58	Then:
59	- Generate an interview ID: `di-{YYYYMMDD}-{short_random}` (e.g., `di-20260407-x7k`)
60	- Ask the user for a short project name (for filenames)
61	- Create the state file at `.omh/state/interview--{id}.json` (engine derives this from `instance_id="{id}"`) with:
62	- All coverage dimensions set to `HIGH`
63	- `type` set to `greenfield` or `brownfield` based on user's answer
64	- `existing_context` coverage set to `N/A` for greenfield projects
65	- Round 0 summary capturing the opening answers
66	- Tell the user: "Got it. I'll ask up to 5 rounds of questions to clarify requirements. You can say 'enough' at any point if you feel we've covered what's needed."
67
68	### Phase 2: Interview Loop
69
70	Run up to 5 rounds (extensible to 10 if user requests). Each round:
71
72	Step 1 — Select dimension to probe
73
74	Compare coverage bins across dimensions. Target the dimension with the highest ambiguity.
75	When multiple dimensions share the same bin, use weights to break ties:
76	- Greenfield: Goal (0.40) > Constraints (0.30) = Success Criteria (0.30)
77	- Brownfield: Goal (0.35) > Constraints (0.25) = Success Criteria (0.25) > Existing Context (0.15)
78
79	Load `references/scoring-rubric.md` for detailed bin definitions and examples.
80
81	Step 2 — Ask the question
82
83	Ask ONE primary question targeting the selected dimension. Make it specific and
84	grounded in what the user has already told you. Don't ask generic questions — reference
85	their earlier answers.
86
87	Good: "You mentioned this is a CLI tool for personal use. What happens when you run it with no tasks configured — should it create a default list, show an error, or something else?"
88
89	Bad: "What are your constraints?"
90
91	Allow 1-2 brief follow-ups if the user's answer is unclear, contradictory, or raises
92	new questions. Don't force follow-ups if the answer is clear.
93
94	Step 3 — Adaptive questioning (if stuck)
95
96	If a dimension has been targeted for 2 or more consecutive rounds without moving from
97	its current bin, chan

People who liked this also viewed

6 picks

Type