researchquestions

Name: researchquestions
Author: sterlingcrispin

201stars18forks

How to install researchquestions?

sterlingcrispin/claude_slash_commands/researchquestions

$npx -y skills add sterlingcrispin/claude_slash_commands --skill researchquestions

Installs into the current project.

Summary

Write a structured research prompt document — questions only, no answers

Files · 1

View on GitHub

SKILL.md

1	# Research
2
3	Write a research prompt document — a structured set of questions designed to guide deep technical investigation of a domain. The output is a markdown file that can be fed to an AI (or used by the agent itself) for thorough research.
4
5	You are writing QUESTIONS, not answers. Do not research the topic yourself. Do not include findings, recommendations, or pre-baked conclusions. The entire point is to produce a document that drives research — not to do the research.
6
7
8	## Workflow
9
10	### Step 1: Understand the Topic
11
12	Ask the user what they want to research if it's not clear. Understand:
13	- What are they trying to build or decide?
14	- What do they already have? (Existing code, tools, context)
15	- What's the pain point driving this research?
16	- How far does it need to scale?
17
18	### Step 2: Find the Research Prompts Folder
19
20	Look for an existing `docs/research_prompts/` folder in the project. If it exists, read 1-2 existing prompts to match the project's established format and voice. If no folder exists, create `docs/research_prompts/`.
21
22	### Step 3: Write the Prompt
23
24	Follow the format below exactly. Write it to `docs/research_prompts/<topic-slug>.md`.
25
26	## Format
27
28	Every research prompt follows this structure:
29
30	```markdown
31	# Research Prompt: <Clear Descriptive Title>
32
33	## Objective
34
35	1-2 paragraphs. What are we researching and why. State the core question in bold.
36	Frame it as exploration, not as a spec. Don't prescribe the answer.
37
38	## Context
39
40	### Current State / Pain Point
41	What exists today. What's broken or insufficient. Be specific — reference
42	actual code, tools, numbers. This grounds the research in reality.
43
44	### What We Want
45	Bullet list of desired capabilities. What the end state looks like.
46	Keep it high-level — the research should figure out HOW, not be told how.
47
48	## Key Questions
49
50	### 0. <First Major Topic Area>
51
52	0a. <Specific sub-question>
53	- Concrete question that demands investigation
54	- Follow-up angle or related concern
55	- "How does X handle this?" type comparative question
56
57	0b. <Next sub-question>
58	- ...
59
60	### 1. <Second Major Topic Area>
61
62	1a. <Sub-question>
63	- ...
64
65	### 2. <Third Major Topic Area>
66	...
67
68	(Continue with as many sections as the topic demands. Typical range: 4-8 sections.)
69
70	## Desired Output
71
72	What the research should produce. NOT the answers — but the SHAPE of the answers.
73	Bullet list of deliverables:
74	- Recommendations on approach X vs Y
75	- Architecture diagram for Z
76	- Performance analysis at scale
77	- Trade-off matrix
78	- Phased roadmap
79	- etc.
80	```
81
82	## Rules
83
84	1. Questions only. Never include answers, findings, recommendations, or conclusions in the prompt. If you know something about the topic, formulate it as a question that would uncover that knowledge — don't state it as fact.
85
86	2. Match existing voice. If the project already has research prompts, read them and match the tone, depth, and structure. Some projects are more technical, some more strategic. Adapt.
87
88	3. Be specific, not vague. Bad: "How does performance work?" Good: "At 5,000 building instances with Nanite enabled, what are the real bottlenecks — draw calls, ISM actor count, GPU memory, or CPU transform computation?"
89
90	4. Ground in context. Reference the project's actual code, tools, pain points, and existing systems. The prompt should feel like it was written by someone who knows the codebase, not a generic template.
91
92	5. Hierarchical questions. Major sections (0, 1, 2...) for broad topic areas. Lettered sub-questions (a, b, c...) for specific angles within each area. Sub-bullets for follow-up concerns or comparative angles.
93
94	6. Include "how do others do it" questions. For every major topic, ask how production systems, established tools, or industry leaders approach the same problem. Name specific systems (CitySample, Houdini, CityEngine, etc. — whatever's relevant to the domain).
95
96	7. Scale questions. Always include questions about how the approach scales — from small to large, from prototype to production.
97
98	8. Build-or-borrow questions. If there are existing tools/systems that could solve part of the problem, ask about them explicitly. "Should we build custom X or integrate existing Y? What do we gain and lose?"
99
100	9. End with Desired Output. List what the research should produce — not the content, but the format. (Recommendation, architecture, comparison matrix, roadmap, etc.)
101
102	10. No emojis, no fluff. Professional, direct, technical. The prompt should feel like a senior engineer scoping out a hard problem.
103
104	## What NOT to Do
105
106	- Don't research the topic. Don't search the web, don't read docs, don't look up how things work. Just write the questions.
107	- Don't write a spec. A research prompt explores the space. A spec prescribes the solution. These are different documents.
108	- Don't pad with obvious questions. Every question should require real investigation to answer.

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

researchquestions

201stars18forks

View on GitHub

How to install researchquestions?

sterlingcrispin/claude_slash_commands/researchquestions

$npx -y skills add sterlingcrispin/claude_slash_commands --skill researchquestions

Installs into the current project.

Summary

Write a structured research prompt document — questions only, no answers

Files · 1

View on GitHub

SKILL.md

1	# Research
2
3	Write a research prompt document — a structured set of questions designed to guide deep technical investigation of a domain. The output is a markdown file that can be fed to an AI (or used by the agent itself) for thorough research.
4
5	You are writing QUESTIONS, not answers. Do not research the topic yourself. Do not include findings, recommendations, or pre-baked conclusions. The entire point is to produce a document that drives research — not to do the research.
6
7
8	## Workflow
9
10	### Step 1: Understand the Topic
11
12	Ask the user what they want to research if it's not clear. Understand:
13	- What are they trying to build or decide?
14	- What do they already have? (Existing code, tools, context)
15	- What's the pain point driving this research?
16	- How far does it need to scale?
17
18	### Step 2: Find the Research Prompts Folder
19
20	Look for an existing `docs/research_prompts/` folder in the project. If it exists, read 1-2 existing prompts to match the project's established format and voice. If no folder exists, create `docs/research_prompts/`.
21
22	### Step 3: Write the Prompt
23
24	Follow the format below exactly. Write it to `docs/research_prompts/<topic-slug>.md`.
25
26	## Format
27
28	Every research prompt follows this structure:
29
30	```markdown
31	# Research Prompt: <Clear Descriptive Title>
32
33	## Objective
34
35	1-2 paragraphs. What are we researching and why. State the core question in bold.
36	Frame it as exploration, not as a spec. Don't prescribe the answer.
37
38	## Context
39
40	### Current State / Pain Point
41	What exists today. What's broken or insufficient. Be specific — reference
42	actual code, tools, numbers. This grounds the research in reality.
43
44	### What We Want
45	Bullet list of desired capabilities. What the end state looks like.
46	Keep it high-level — the research should figure out HOW, not be told how.
47
48	## Key Questions
49
50	### 0. <First Major Topic Area>
51
52	0a. <Specific sub-question>
53	- Concrete question that demands investigation
54	- Follow-up angle or related concern
55	- "How does X handle this?" type comparative question
56
57	0b. <Next sub-question>
58	- ...
59
60	### 1. <Second Major Topic Area>
61
62	1a. <Sub-question>
63	- ...
64
65	### 2. <Third Major Topic Area>
66	...
67
68	(Continue with as many sections as the topic demands. Typical range: 4-8 sections.)
69
70	## Desired Output
71
72	What the research should produce. NOT the answers — but the SHAPE of the answers.
73	Bullet list of deliverables:
74	- Recommendations on approach X vs Y
75	- Architecture diagram for Z
76	- Performance analysis at scale
77	- Trade-off matrix
78	- Phased roadmap
79	- etc.
80	```
81
82	## Rules
83
84	1. Questions only. Never include answers, findings, recommendations, or conclusions in the prompt. If you know something about the topic, formulate it as a question that would uncover that knowledge — don't state it as fact.
85
86	2. Match existing voice. If the project already has research prompts, read them and match the tone, depth, and structure. Some projects are more technical, some more strategic. Adapt.
87
88	3. Be specific, not vague. Bad: "How does performance work?" Good: "At 5,000 building instances with Nanite enabled, what are the real bottlenecks — draw calls, ISM actor count, GPU memory, or CPU transform computation?"
89
90	4. Ground in context. Reference the project's actual code, tools, pain points, and existing systems. The prompt should feel like it was written by someone who knows the codebase, not a generic template.
91
92	5. Hierarchical questions. Major sections (0, 1, 2...) for broad topic areas. Lettered sub-questions (a, b, c...) for specific angles within each area. Sub-bullets for follow-up concerns or comparative angles.
93
94	6. Include "how do others do it" questions. For every major topic, ask how production systems, established tools, or industry leaders approach the same problem. Name specific systems (CitySample, Houdini, CityEngine, etc. — whatever's relevant to the domain).
95
96	7. Scale questions. Always include questions about how the approach scales — from small to large, from prototype to production.
97
98	8. Build-or-borrow questions. If there are existing tools/systems that could solve part of the problem, ask about them explicitly. "Should we build custom X or integrate existing Y? What do we gain and lose?"
99
100	9. End with Desired Output. List what the research should produce — not the content, but the format. (Recommendation, architecture, comparison matrix, roadmap, etc.)
101
102	10. No emojis, no fluff. Professional, direct, technical. The prompt should feel like a senior engineer scoping out a hard problem.
103
104	## What NOT to Do
105
106	- Don't research the topic. Don't search the web, don't read docs, don't look up how things work. Just write the questions.
107	- Don't write a spec. A research prompt explores the space. A spec prescribes the solution. These are different documents.
108	- Don't pad with obvious questions. Every question should require real investigation to answer.

People who liked this also viewed

6 picks

Type