DEV Community

Cover image for 100 Writing, Productivity, Coding & Research Lenses for ChatGPT 🧠💻
Probal Dhali
Probal Dhali

Posted on

100 Writing, Productivity, Coding & Research Lenses for ChatGPT 🧠💻

#ai #webdev #programming #productivity

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

Top comments (0)