# 100 Writing, Productivity, Coding & Research Lenses for ChatGPT πŸ§ πŸ’» > Source: > Published: 2026-08-24 15:49:19+00:00 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**.