ChatGPT용 쓰기, 생산성, 코딩 및 리서치 렌즈 100개 🧠💻

작성자

카테고리:

← 피드로
DEV Community · Probal Dhali · 2026-08-25 개발(SW)

From fixing one sentence to designing an algorithm, AI becomes much more useful when you stop treating it as a single-purpose chatbot.

Instead, think of it as a collection of specialized working modes.

Need to debug?

/debug

Need to design an algorithm?

/algorithm

Need to plan research?

/researchplan

Need to challenge your own argument?

/critic

Need to turn a large project into manageable work?

/roadmap90

The underlying idea is simple:

Don’t just ask AI for an answer. Give it a mode of thinking.

From Prompt → Workflow

A normal interaction might look like:

User
  ↓
Question
  ↓
AI
  ↓
Answer

Enter fullscreen mode Exit fullscreen mode

A structured workflow looks different:

Goal
 ↓
Context
 ↓
Lens
 ↓
Analysis
 ↓
Output
 ↓
Review
 ↓
Iteration

Enter fullscreen mode Exit fullscreen mode

For example:

Project
  ↓
/researchplan
  ↓
Research questions
  ↓
/hypothesis
  ↓
Testable assumptions
  ↓
/experiment
  ↓
Evaluation
  ↓
/audit
  ↓
Final findings

Enter fullscreen mode Exit fullscreen mode

The shortcut is not magic.

It is a task-specific instruction layer.

1. Writing Lenses

The first group focuses on transforming existing text.

/rewrite
/improve
/polish
/proofread
/grammar
/copyedit
/expand
/shorten
/paraphrase
/simplifytext

Enter fullscreen mode Exit fullscreen mode

These commands represent different operations.

For example:

/rewrite

Enter fullscreen mode Exit fullscreen mode

should preserve the original meaning while changing the wording.

Whereas:

/improve

Enter fullscreen mode Exit fullscreen mode

can address:

  • clarity
  • structure
  • flow
  • word choice
  • readability

And:

/shorten

Enter fullscreen mode Exit fullscreen mode

optimizes for concision.

This distinction matters because:

Editing and rewriting are not the same task.

2. Tone Is a Control Variable

The next group controls communication style:

/formal
/casual
/friendly
/professional
/persuasive
/convincing
/academic
/journalistic

Enter fullscreen mode Exit fullscreen mode

The same information can be communicated differently depending on the audience.

For example:

Technical explanation
        ↓
 ┌──────┼──────┐
 ↓      ↓      ↓
Student Developer Executive

Enter fullscreen mode Exit fullscreen mode

The underlying facts should remain stable.

The presentation changes.

That makes tone a communication parameter, not merely decoration.

3. Structured Writing

For longer outputs:

/story
/essay
/article
/report
/whitepaper
/casestudy
/proposal
/sop
/playbook
/manual
/guide
/faq

Enter fullscreen mode Exit fullscreen mode

These commands define the output structure.

For example:

Problem
 ↓
Context
 ↓
Analysis
 ↓
Evidence
 ↓
Recommendation
 ↓
Conclusion

Enter fullscreen mode Exit fullscreen mode

This is much more useful than simply saying:

“Write a detailed report.”

A structured request reduces ambiguity.

4. Information Compression

Large amounts of information often need to be compressed.

Useful lenses include:

/bulletpoints
/keypoints
/highlights
/notes

Enter fullscreen mode Exit fullscreen mode

Think of this as:

100 pages
    ↓
Information extraction
    ↓
Important concepts
    ↓
Key points
    ↓
Actionable notes

Enter fullscreen mode Exit fullscreen mode

The goal isn’t simply to make text shorter.

The goal is to preserve the information that matters.

5. Meetings and Collaboration

For collaborative work:

/minutes
/agenda
/meetingsummary
/todo

Enter fullscreen mode Exit fullscreen mode

A meeting can become:

Discussion
    ↓
Decisions
    ↓
Action Items
    ↓
Owners
    ↓
Deadlines

Enter fullscreen mode Exit fullscreen mode

That is a much more useful representation than a raw transcript.

6. Project Management

Large projects benefit from explicit planning.

The toolkit includes:

/kanban
/gantt
/okr
/kpi
/smartgoals
/roadmap90
/roadmapyear
/milestones

Enter fullscreen mode Exit fullscreen mode

A simple project decomposition might look like:

VISION
  ↓
OBJECTIVES
  ↓
MILESTONES
  ↓
TASKS
  ↓
DEPENDENCIES
  ↓
EXECUTION
  ↓
METRICS

Enter fullscreen mode Exit fullscreen mode

This turns a vague goal into an executable system.

7. Goals Need Measurement

A goal without a measurement strategy is difficult to evaluate.

That’s where:

/okr
/kpi
/smartgoals
/metrics
/dashboardmetrics

Enter fullscreen mode Exit fullscreen mode

become useful.

For example:

Goal:
Improve application performance

Enter fullscreen mode Exit fullscreen mode

can become:

Objective:
Reduce application response time

Key Results:
↓ p95 latency
↓ error rate
↑ throughput

Enter fullscreen mode Exit fullscreen mode

The important shift is:

“I want it better.”
        ↓
“How will we know it is better?”

Enter fullscreen mode Exit fullscreen mode

That question makes planning measurable.

8. Risk Analysis

Projects rarely fail because everything went according to plan.

Useful lenses:

/risks
/riskmatrix
/dependencies
/estimate
/budget
/forecast

Enter fullscreen mode Exit fullscreen mode

A basic risk model:

              IMPACT
           Low    High
        ┌──────┬──────┐
Low     │      │      │
        ├──────┼──────┤
High    │      │  🔴  │
        └──────┴──────┘
         LIKELIHOOD

Enter fullscreen mode Exit fullscreen mode

The goal isn’t to eliminate uncertainty.

It’s to identify which uncertainties deserve attention first.

9. Root-Cause Analysis

When something goes wrong, the first explanation isn’t always the real explanation.

Useful analytical lenses:

/decisiontree
/fishbone
/pareto
/lean
/sixsigma

Enter fullscreen mode Exit fullscreen mode

For example:

Problem
  ↓
Why?
  ↓
Why?
  ↓
Why?
  ↓
Root Cause

Enter fullscreen mode Exit fullscreen mode

A Fishbone-style analysis can separate causes into categories such as:

People
Process
Technology
Environment
Data
Measurement

Enter fullscreen mode Exit fullscreen mode

This is much more useful than asking AI:

“Why did this fail?”

without providing a framework.

10. Productivity

Productivity lenses include:

/productivity
/timemanagement
/pomodoro

Enter fullscreen mode Exit fullscreen mode

But productivity shouldn’t simply mean:

“Do more tasks.”

A better model is:

Priorities
 ↓
Focus
 ↓
Execution
 ↓
Feedback
 ↓
Adjustment

Enter fullscreen mode Exit fullscreen mode

AI can help with planning and prioritization, but the actual constraints of your schedule and environment still matter.

11. Learning and Study

The educational group includes:

/studyplan
/revisionplan
/learningpath
/feynman
/memory
/mnemonics
/practice
/challengequestions

Enter fullscreen mode Exit fullscreen mode

A learning workflow could be:

Learn
 ↓
Explain
 ↓
Recall
 ↓
Practice
 ↓
Test
 ↓
Identify gaps
 ↓
Review

Enter fullscreen mode Exit fullscreen mode

The Feynman technique is particularly useful:

Learn concept
     ↓
Explain simply
     ↓
Find gaps
     ↓
Study gaps
     ↓
Explain again

Enter fullscreen mode Exit fullscreen mode

The important part is active retrieval and feedback—not simply generating longer notes.

12. Coding Lenses

Now we enter one of the most useful categories for developers:

/coding
/explaincode
/debug
/refactor
/optimizecode
/reviewcode

Enter fullscreen mode Exit fullscreen mode

These represent different software-engineering activities.

They should not be treated as interchangeable.

13. Writing Code vs Reviewing Code

For example:

/coding

Enter fullscreen mode Exit fullscreen mode

asks AI to produce an implementation.

While:

/reviewcode

Enter fullscreen mode Exit fullscreen mode

asks it to inspect an existing implementation.

The difference:

Generation
   ↓
“Create something.”

Review
   ↓
“Evaluate something.”

Enter fullscreen mode Exit fullscreen mode

That distinction is important because code generation and code evaluation have different failure modes.

14. Debugging

A useful debugging workflow is:

Bug
 ↓
Reproduce
 ↓
Observe
 ↓
Hypothesis
 ↓
Test
 ↓
Fix
 ↓
Regression Test

Enter fullscreen mode Exit fullscreen mode

The /debug lens should encourage this process.

Instead of:

“Fix this.”

a stronger debugging request provides:

Expected behavior
Actual behavior
Error message
Relevant code
Environment
Steps to reproduce

Enter fullscreen mode Exit fullscreen mode

Better context usually produces better debugging.

15. Refactoring

Refactoring is different from optimization.

/refactor

Enter fullscreen mode Exit fullscreen mode

focuses on:

  • readability
  • maintainability
  • structure
  • duplication
  • separation of concerns

Whereas:

/optimizecode

Enter fullscreen mode Exit fullscreen mode

focuses on:

  • runtime
  • memory
  • algorithmic complexity
  • I/O
  • resource usage

A clean implementation isn’t automatically the fastest implementation.

And the fastest implementation isn’t automatically the best design.

16. Algorithms and Data Structures

For algorithmic problems:

/pseudocode
/algorithm
/datastructure

Enter fullscreen mode Exit fullscreen mode

A useful workflow:

Problem
 ↓
Constraints
 ↓
Input / Output
 ↓
Candidate approaches
 ↓
Complexity analysis
 ↓
Data structure
 ↓
Algorithm
 ↓
Implementation
 ↓
Testing

Enter fullscreen mode Exit fullscreen mode

This is particularly important for technical interviews and competitive programming.

17. SQL and Data

The toolkit also includes:

/sql
/regex
/json
/yaml
/csv
/xml

Enter fullscreen mode Exit fullscreen mode

These are practical transformation and data-manipulation tasks.

For SQL, however, the database schema matters enormously.

A strong SQL request should include:

Tables
Columns
Relationships
Constraints
Sample data
Expected result
Database engine

Enter fullscreen mode Exit fullscreen mode

For example:

PostgreSQL
≠
SQL Server
≠
MySQL

Enter fullscreen mode Exit fullscreen mode

Even when the syntax looks similar.

18. API Design

The /api lens can help reason about:

Endpoints
HTTP methods
Request schemas
Response schemas
Authentication
Errors
Versioning
Pagination
Validation

Enter fullscreen mode Exit fullscreen mode

A simple API lifecycle:

Client
  ↓
Request
  ↓
Validation
  ↓
Authentication
  ↓
Business Logic
  ↓
Database / Service
  ↓
Response

Enter fullscreen mode Exit fullscreen mode

Thinking in this structure makes API design more systematic.

19. Research

Research requires a different mindset.

Useful lenses:

/researchplan
/literaturereview
/hypothesis
/experiment
/peerreview
/critic
/audit

Enter fullscreen mode Exit fullscreen mode

A structured research workflow:

Research Question
        ↓
Literature
        ↓
Gap
        ↓
Hypothesis
        ↓
Method
        ↓
Experiment
        ↓
Evidence
        ↓
Analysis
        ↓
Conclusion

Enter fullscreen mode Exit fullscreen mode

AI can help organize this process, but generated references, claims, statistics, and citations still need verification.

20. Hypothesis vs Opinion

A hypothesis should be testable.

For example:

Opinion:
“This model seems better.”

Hypothesis:
“Model A will achieve higher F1-score than Model B
on dataset X under the same evaluation protocol.”

Enter fullscreen mode Exit fullscreen mode

The second statement can actually be tested.

That’s a major difference.

21. Experiment Design

The /experiment lens can help structure:

Independent variable
Dependent variable
Controls
Dataset
Procedure
Evaluation metric
Expected outcome
Threats to validity

Enter fullscreen mode Exit fullscreen mode

A simplified structure:

        EXPERIMENT
             │
     ┌───────┼────────┐
     ↓       ↓        ↓
  INPUT   METHOD   CONTROL
     │       │        │
     └───────┼────────┘
             ↓
          OUTPUT
             ↓
         METRICS
             ↓
       INTERPRETATION

Enter fullscreen mode Exit fullscreen mode

This is much stronger than simply asking AI:

“Design an experiment.”

22. Peer Review and Criticism

Two particularly useful lenses are:

/peerreview
/critic

Enter fullscreen mode Exit fullscreen mode

Their purpose should not be:

“Find everything wrong.”

Instead:

Claim
 ↓
Evidence
 ↓
Reasoning
 ↓
Assumptions
 ↓
Limitations
 ↓
Alternative explanations

Enter fullscreen mode Exit fullscreen mode

A strong critique should distinguish:

Fact
Inference
Assumption
Opinion
Uncertainty

Enter fullscreen mode Exit fullscreen mode

This is one of the most useful habits when working with AI-generated material.

23. The /audit Lens

An audit is broader than a review.

For example:

Technical Audit

Enter fullscreen mode Exit fullscreen mode

could inspect:

Architecture
Security
Performance
Maintainability
Testing
Dependencies
Documentation
Deployment

Enter fullscreen mode Exit fullscreen mode

A research audit could inspect:

Sources
Methodology
Evidence
Statistics
Claims
Limitations
Reproducibility

Enter fullscreen mode Exit fullscreen mode

The same underlying lens can therefore be adapted to different domains.

24. The Meta-Lens: /framework

The final shortcut is:

/framework

Enter fullscreen mode Exit fullscreen mode

This is arguably one of the most powerful concepts in the collection.

Instead of asking:

“Which framework should I use?”

you can ask AI to first determine:

Problem
 ↓
Characteristics
 ↓
Candidate frameworks
 ↓
Selection criteria
 ↓
Most suitable framework
 ↓
Application

Enter fullscreen mode Exit fullscreen mode

For example:

Root cause?
→ Fishbone

Prioritization?
→ Pareto

Project execution?
→ Kanban / Scrum

Strategic analysis?
→ SWOT / PESTLE

Experiment?
→ Experimental design

Decision?
→ Decision tree / decision matrix

Enter fullscreen mode Exit fullscreen mode

The framework should match the problem.

The Complete 100-Lens Map

# Shortcut Purpose 301 /rewrite Rewrite while preserving meaning 302 /improve Improve clarity and quality 303 /polish Make writing smoother 304 /proofread Correct grammar and spelling 305 /grammar Fix grammar only 306 /copyedit Professional copy editing 307 /expand Add useful detail 308 /shorten Condense content 309 /paraphrase Reword naturally 310 /simplifytext Use simpler language 311 /formal Formal tone 312 /casual Casual conversational tone 313 /friendly Warm, friendly tone 314 /professional Professional business tone 315 /persuasive Strengthen persuasion 316 /convincing Strengthen arguments 317 /academic Academic style 318 /journalistic News-style writing 319 /story Story format 320 /essay Essay format 321 /article Article format 322 /report Professional report 323 /whitepaper White-paper structure 324 /casestudy Case-study format 325 /proposal Business proposal 326 /sop Standard operating procedure 327 /playbook Reusable playbook 328 /manual User manual 329 /guide Step-by-step guide 330 /faq Frequently asked questions 331 /checklist Checklist format 332 /template Reusable template 333 /outline Structured outline 334 /bulletpoints Bullet summary 335 /keypoints Key takeaways 336 /highlights Important ideas 337 /notes Study notes 338 /minutes Meeting minutes 339 /agenda Meeting agenda 340 /meetingsummary Meeting summary 341 /todo Task list 342 /kanban Kanban task board 343 /gantt Gantt-style plan 344 /okr Objectives and key results 345 /kpi Key performance indicators 346 /smartgoals SMART goals 347 /roadmap90 90-day roadmap 348 /roadmapyear Annual roadmap 349 /milestones Project milestones 350 /risks Risk assessment 351 /riskmatrix Likelihood × impact 352 /dependencies Task dependencies 353 /estimate Effort/time estimation 354 /budget Budget planning 355 /forecast Forecasting 356 /metrics Useful metrics 357 /dashboardmetrics Dashboard KPI ideas 358 /decisiontree Decision-tree analysis 359 /fishbone Root-cause analysis 360 /pareto 80/20 analysis 361 /lean Lean methodology 362 /sixsigma Six Sigma approach 363 /agile Agile methodology 364 /scrum Scrum framework 365 /kanbanflow Kanban workflow 366 /productivity Productivity optimization 367 /timemanagement Time management 368 /pomodoro Pomodoro scheduling 369 /studyplan Study plan 370 /revisionplan Revision timetable 371 /learningpath Progressive learning path 372 /feynman Feynman technique 373 /memory Memory techniques 374 /mnemonics Mnemonic creation 375 /practice Practice exercises 376 /challengequestions Difficult questions 377 /coding Write code 378 /explaincode Explain code 379 /debug Debug code 380 /refactor Refactor code 381 /optimizecode Optimize performance 382 /reviewcode Code review 383 /pseudocode Generate pseudocode 384 /algorithm Design algorithms 385 /datastructure Choose data structures 386 /sql Generate SQL 387 /regex Generate regular expressions 388 /api Design/explain APIs 389 /json Work with JSON 390 /yaml Generate YAML 391 /csv Generate CSV 392 /xml Generate XML 393 /researchplan Plan research 394 /literaturereview Review literature 395 /hypothesis Generate testable hypotheses 396 /experiment Design experiments 397 /peerreview Critical peer review 398 /critic Constructive criticism 399 /audit Comprehensive audit 400 /framework Select an appropriate analytical framework

The Bigger Picture

The interesting thing about these 100 lenses is that they can be connected.

For example, building a software project:

IDEA
 ↓
/researchplan
 ↓
/proposal
 ↓
/roadmap90
 ↓
/milestones
 ↓
/dependencies
 ↓
/coding
 ↓
/reviewcode
 ↓
/debug
 ↓
/optimizecode
 ↓
/audit

Enter fullscreen mode Exit fullscreen mode

Writing a research paper:

QUESTION
 ↓
/researchplan
 ↓
/literaturereview
 ↓
/hypothesis
 ↓
/experiment
 ↓
/analysis
 ↓
/critic
 ↓
/peerreview
 ↓
/article

Enter fullscreen mode Exit fullscreen mode

Preparing for an exam:

SYLLABUS
 ↓
/learningpath
 ↓
/studyplan
 ↓
/notes
 ↓
/feynman
 ↓
/practice
 ↓
/challengequestions
 ↓
/revisionplan

Enter fullscreen mode Exit fullscreen mode

That’s where these shortcuts become more interesting.

They stop being isolated commands and become workflow components.

The Core Principle

There is a temptation to think:

“The more detailed the prompt, the better.”

I don’t think that’s always true.

A better principle is:

Give the model the right context, the right task, the right constraints, and the right evaluation criteria.

A useful conceptual model is:

Better Result
     =
Context
+
Task
+
Constraints
+
Relevant Lens
+
Evaluation

Enter fullscreen mode Exit fullscreen mode

Not:

Better Result
=
More Words

Enter fullscreen mode Exit fullscreen mode

Final Thought

The most interesting future for AI assistants may not be about having one enormous prompt.

It may be about having many small, composable reasoning modes.

Instead of:

“AI, do everything.”

We move toward:

AI
 ├── Writer
 ├── Researcher
 ├── Programmer
 ├── Reviewer
 ├── Planner
 ├── Analyst
 ├── Teacher
 └── Auditor

Enter fullscreen mode Exit fullscreen mode

And the user chooses the appropriate lens for the current problem.

That makes AI interaction feel less like asking a chatbot a question—

and more like operating a general-purpose cognitive workbench.

What would you add?

If you could add one more shortcut to this 301–400 collection, what would it be?

Maybe:

/securityaudit

/testcode

/factcheck

/architecture

/benchmark

/citationcheck

or something completely different?

I’m especially interested in shortcuts that can turn AI from a content generator into a verification and reasoning tool.

AI #ChatGPT #Productivity #Programming #SoftwareEngineering #Research #PromptEngineering #DeveloperTools #Coding #ArtificialIntelligence #DevCommunity #Learning

원문에서 계속 ↗