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

A developer has compiled a collection of 100 specialized prompt commands, or 'lenses,' for ChatGPT that transform it from a single-purpose chatbot into a multi-mode tool for writing, productivity, coding, and research. The commands, such as /debug, /algorithm, and /researchplan, act as task-specific instruction layers that structure AI outputs for tasks like editing, tone adjustment, project planning, and risk assessment. The approach emphasizes giving AI a mode of thinking rather than just asking for an answer.

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. A normal interaction might look like: User ↓ Question ↓ AI ↓ Answer A structured workflow looks different: Goal ↓ Context ↓ Lens ↓ Analysis ↓ Output ↓ Review ↓ Iteration For example: Project ↓ /researchplan ↓ Research questions ↓ /hypothesis ↓ Testable assumptions ↓ /experiment ↓ Evaluation ↓ /audit ↓ Final findings The shortcut is not magic. It is a task-specific instruction layer . The first group focuses on transforming existing text. /rewrite /improve /polish /proofread /grammar /copyedit /expand /shorten /paraphrase /simplifytext These commands represent different operations. For example: /rewrite should preserve the original meaning while changing the wording. Whereas: /improve can address: And: /shorten optimizes for concision. This distinction matters because: Editing and rewriting are not the same task. The next group controls communication style: /formal /casual /friendly /professional /persuasive /convincing /academic /journalistic The same information can be communicated differently depending on the audience. For example: Technical explanation ↓ ┌──────┼──────┐ ↓ ↓ ↓ Student Developer Executive The underlying facts should remain stable. The presentation changes. That makes tone a communication parameter , not merely decoration. For longer outputs: /story /essay /article /report /whitepaper /casestudy /proposal /sop /playbook /manual /guide /faq These commands define the output structure . For example: Problem ↓ Context ↓ Analysis ↓ Evidence ↓ Recommendation ↓ Conclusion This is much more useful than simply saying: “Write a detailed report.” A structured request reduces ambiguity. Large amounts of information often need to be compressed. Useful lenses include: /bulletpoints /keypoints /highlights /notes Think of this as: 100 pages ↓ Information extraction ↓ Important concepts ↓ Key points ↓ Actionable notes The goal isn't simply to make text shorter. The goal is to preserve the information that matters. For collaborative work: /minutes /agenda /meetingsummary /todo A meeting can become: Discussion ↓ Decisions ↓ Action Items ↓ Owners ↓ Deadlines That is a much more useful representation than a raw transcript. Large projects benefit from explicit planning. The toolkit includes: /kanban /gantt /okr /kpi /smartgoals /roadmap90 /roadmapyear /milestones A simple project decomposition might look like: VISION ↓ OBJECTIVES ↓ MILESTONES ↓ TASKS ↓ DEPENDENCIES ↓ EXECUTION ↓ METRICS This turns a vague goal into an executable system. A goal without a measurement strategy is difficult to evaluate. That's where: /okr /kpi /smartgoals /metrics /dashboardmetrics become useful. For example: Goal: Improve application performance can become: Objective: Reduce application response time Key Results: ↓ p95 latency ↓ error rate ↑ throughput The important shift is: “I want it better.” ↓ “How will we know it is better?” That question makes planning measurable. Projects rarely fail because everything went according to plan. Useful lenses: /risks /riskmatrix /dependencies /estimate /budget /forecast A basic risk model: IMPACT Low High ┌──────┬──────┐ Low │ │ │ ├──────┼──────┤ High │ │ 🔴 │ └──────┴──────┘ LIKELIHOOD The goal isn't to eliminate uncertainty. It's to identify which uncertainties deserve attention first. When something goes wrong, the first explanation isn't always the real explanation. Useful analytical lenses: /decisiontree /fishbone /pareto /lean /sixsigma For example: Problem ↓ Why? ↓ Why? ↓ Why? ↓ Root Cause A Fishbone-style analysis can separate causes into categories such as: People Process Technology Environment Data Measurement This is much more useful than asking AI: “Why did this fail?” without providing a framework. Productivity lenses include: /productivity /timemanagement /pomodoro But productivity shouldn't simply mean: “Do more tasks.” A better model is: Priorities ↓ Focus ↓ Execution ↓ Feedback ↓ Adjustment AI can help with planning and prioritization, but the actual constraints of your schedule and environment still matter. The educational group includes: /studyplan /revisionplan /learningpath /feynman /memory /mnemonics /practice /challengequestions A learning workflow could be: Learn ↓ Explain ↓ Recall ↓ Practice ↓ Test ↓ Identify gaps ↓ Review The Feynman technique is particularly useful: Learn concept ↓ Explain simply ↓ Find gaps ↓ Study gaps ↓ Explain again The important part is active retrieval and feedback—not simply generating longer notes. Now we enter one of the most useful categories for developers: /coding /explaincode /debug /refactor /optimizecode /reviewcode These represent different software-engineering activities. They should not be treated as interchangeable. For example: /coding asks AI to produce an implementation. While: /reviewcode asks it to inspect an existing implementation. The difference: Generation ↓ “Create something.” Review ↓ “Evaluate something.” That distinction is important because code generation and code evaluation have different failure modes. A useful debugging workflow is: Bug ↓ Reproduce ↓ Observe ↓ Hypothesis ↓ Test ↓ Fix ↓ Regression Test 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 Better context usually produces better debugging. Refactoring is different from optimization. /refactor focuses on: Whereas: /optimizecode focuses on: A clean implementation isn't automatically the fastest implementation. And the fastest implementation isn't automatically the best design. For algorithmic problems: /pseudocode /algorithm /datastructure A useful workflow: Problem ↓ Constraints ↓ Input / Output ↓ Candidate approaches ↓ Complexity analysis ↓ Data structure ↓ Algorithm ↓ Implementation ↓ Testing This is particularly important for technical interviews and competitive programming. The toolkit also includes: /sql /regex /json /yaml /csv /xml 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 For example: PostgreSQL ≠ SQL Server ≠ MySQL Even when the syntax looks similar. The /api lens can help reason about: Endpoints HTTP methods Request schemas Response schemas Authentication Errors Versioning Pagination Validation A simple API lifecycle: Client ↓ Request ↓ Validation ↓ Authentication ↓ Business Logic ↓ Database / Service ↓ Response Thinking in this structure makes API design more systematic. Research requires a different mindset. Useful lenses: /researchplan /literaturereview /hypothesis /experiment /peerreview /critic /audit A structured research workflow: Research Question ↓ Literature ↓ Gap ↓ Hypothesis ↓ Method ↓ Experiment ↓ Evidence ↓ Analysis ↓ Conclusion AI can help organize this process, but generated references, claims, statistics, and citations still need verification. 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.” The second statement can actually be tested. That's a major difference. The /experiment lens can help structure: Independent variable Dependent variable Controls Dataset Procedure Evaluation metric Expected outcome Threats to validity A simplified structure: EXPERIMENT │ ┌───────┼────────┐ ↓ ↓ ↓ INPUT METHOD CONTROL │ │ │ └───────┼────────┘ ↓ OUTPUT ↓ METRICS ↓ INTERPRETATION This is much stronger than simply asking AI: “Design an experiment.” Two particularly useful lenses are: /peerreview /critic Their purpose should not be: “Find everything wrong.” Instead: Claim ↓ Evidence ↓ Reasoning ↓ Assumptions ↓ Limitations ↓ Alternative explanations A strong critique should distinguish: Fact Inference Assumption Opinion Uncertainty This is one of the most useful habits when working with AI-generated material. /audit Lens An audit is broader than a review. For example: Technical Audit could inspect: Architecture Security Performance Maintainability Testing Dependencies Documentation Deployment A research audit could inspect: Sources Methodology Evidence Statistics Claims Limitations Reproducibility The same underlying lens can therefore be adapted to different domains. /framework The final shortcut is: /framework 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 For example: Root cause? → Fishbone Prioritization? → Pareto Project execution? → Kanban / Scrum Strategic analysis? → SWOT / PESTLE Experiment? → Experimental design Decision? → Decision tree / decision matrix The framework should match the problem. | | 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 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 Writing a research paper: QUESTION ↓ /researchplan ↓ /literaturereview ↓ /hypothesis ↓ /experiment ↓ /analysis ↓ /critic ↓ /peerreview ↓ /article Preparing for an exam: SYLLABUS ↓ /learningpath ↓ /studyplan ↓ /notes ↓ /feynman ↓ /practice ↓ /challengequestions ↓ /revisionplan That's where these shortcuts become more interesting. They stop being isolated commands and become workflow components . 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 Not: Better Result = More Words 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 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 . 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 .