{"slug": "100-writing-productivity-coding-research-lenses-for-chatgpt", "title": "100 Writing, Productivity, Coding & Research Lenses for ChatGPT 🧠💻", "summary": "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.", "body_md": "From fixing one sentence to designing an algorithm, AI becomes much more useful when you stop treating it as a single-purpose chatbot.\n\nInstead, think of it as a **collection of specialized working modes**.\n\nNeed to debug?\n\n`/debug`\n\nNeed to design an algorithm?\n\n`/algorithm`\n\nNeed to plan research?\n\n`/researchplan`\n\nNeed to challenge your own argument?\n\n`/critic`\n\nNeed to turn a large project into manageable work?\n\n`/roadmap90`\n\nThe underlying idea is simple:\n\nDon't just ask AI for an answer. Give it a mode of thinking.\n\nA normal interaction might look like:\n\n```\nUser\n  ↓\nQuestion\n  ↓\nAI\n  ↓\nAnswer\n```\n\nA structured workflow looks different:\n\n```\nGoal\n ↓\nContext\n ↓\nLens\n ↓\nAnalysis\n ↓\nOutput\n ↓\nReview\n ↓\nIteration\n```\n\nFor example:\n\n```\nProject\n  ↓\n/researchplan\n  ↓\nResearch questions\n  ↓\n/hypothesis\n  ↓\nTestable assumptions\n  ↓\n/experiment\n  ↓\nEvaluation\n  ↓\n/audit\n  ↓\nFinal findings\n```\n\nThe shortcut is not magic.\n\nIt is a **task-specific instruction layer**.\n\nThe first group focuses on transforming existing text.\n\n```\n/rewrite\n/improve\n/polish\n/proofread\n/grammar\n/copyedit\n/expand\n/shorten\n/paraphrase\n/simplifytext\n```\n\nThese commands represent different operations.\n\nFor example:\n\n```\n/rewrite\n```\n\nshould preserve the original meaning while changing the wording.\n\nWhereas:\n\n```\n/improve\n```\n\ncan address:\n\nAnd:\n\n```\n/shorten\n```\n\noptimizes for concision.\n\nThis distinction matters because:\n\nEditing and rewriting are not the same task.\n\nThe next group controls communication style:\n\n```\n/formal\n/casual\n/friendly\n/professional\n/persuasive\n/convincing\n/academic\n/journalistic\n```\n\nThe same information can be communicated differently depending on the audience.\n\nFor example:\n\n```\nTechnical explanation\n        ↓\n ┌──────┼──────┐\n ↓      ↓      ↓\nStudent Developer Executive\n```\n\nThe underlying facts should remain stable.\n\nThe presentation changes.\n\nThat makes tone a **communication parameter**, not merely decoration.\n\nFor longer outputs:\n\n```\n/story\n/essay\n/article\n/report\n/whitepaper\n/casestudy\n/proposal\n/sop\n/playbook\n/manual\n/guide\n/faq\n```\n\nThese commands define the **output structure**.\n\nFor example:\n\n```\nProblem\n ↓\nContext\n ↓\nAnalysis\n ↓\nEvidence\n ↓\nRecommendation\n ↓\nConclusion\n```\n\nThis is much more useful than simply saying:\n\n“Write a detailed report.”\n\nA structured request reduces ambiguity.\n\nLarge amounts of information often need to be compressed.\n\nUseful lenses include:\n\n```\n/bulletpoints\n/keypoints\n/highlights\n/notes\n```\n\nThink of this as:\n\n```\n100 pages\n    ↓\nInformation extraction\n    ↓\nImportant concepts\n    ↓\nKey points\n    ↓\nActionable notes\n```\n\nThe goal isn't simply to make text shorter.\n\nThe goal is to preserve the information that matters.\n\nFor collaborative work:\n\n```\n/minutes\n/agenda\n/meetingsummary\n/todo\n```\n\nA meeting can become:\n\n```\nDiscussion\n    ↓\nDecisions\n    ↓\nAction Items\n    ↓\nOwners\n    ↓\nDeadlines\n```\n\nThat is a much more useful representation than a raw transcript.\n\nLarge projects benefit from explicit planning.\n\nThe toolkit includes:\n\n```\n/kanban\n/gantt\n/okr\n/kpi\n/smartgoals\n/roadmap90\n/roadmapyear\n/milestones\n```\n\nA simple project decomposition might look like:\n\n```\nVISION\n  ↓\nOBJECTIVES\n  ↓\nMILESTONES\n  ↓\nTASKS\n  ↓\nDEPENDENCIES\n  ↓\nEXECUTION\n  ↓\nMETRICS\n```\n\nThis turns a vague goal into an executable system.\n\nA goal without a measurement strategy is difficult to evaluate.\n\nThat's where:\n\n```\n/okr\n/kpi\n/smartgoals\n/metrics\n/dashboardmetrics\n```\n\nbecome useful.\n\nFor example:\n\n```\nGoal:\nImprove application performance\n```\n\ncan become:\n\n```\nObjective:\nReduce application response time\n\nKey Results:\n↓ p95 latency\n↓ error rate\n↑ throughput\n```\n\nThe important shift is:\n\n```\n“I want it better.”\n        ↓\n“How will we know it is better?”\n```\n\nThat question makes planning measurable.\n\nProjects rarely fail because everything went according to plan.\n\nUseful lenses:\n\n```\n/risks\n/riskmatrix\n/dependencies\n/estimate\n/budget\n/forecast\n```\n\nA basic risk model:\n\n```\n              IMPACT\n           Low    High\n        ┌──────┬──────┐\nLow     │      │      │\n        ├──────┼──────┤\nHigh    │      │  🔴  │\n        └──────┴──────┘\n         LIKELIHOOD\n```\n\nThe goal isn't to eliminate uncertainty.\n\nIt's to identify which uncertainties deserve attention first.\n\nWhen something goes wrong, the first explanation isn't always the real explanation.\n\nUseful analytical lenses:\n\n```\n/decisiontree\n/fishbone\n/pareto\n/lean\n/sixsigma\n```\n\nFor example:\n\n```\nProblem\n  ↓\nWhy?\n  ↓\nWhy?\n  ↓\nWhy?\n  ↓\nRoot Cause\n```\n\nA Fishbone-style analysis can separate causes into categories such as:\n\n```\nPeople\nProcess\nTechnology\nEnvironment\nData\nMeasurement\n```\n\nThis is much more useful than asking AI:\n\n“Why did this fail?”\n\nwithout providing a framework.\n\nProductivity lenses include:\n\n```\n/productivity\n/timemanagement\n/pomodoro\n```\n\nBut productivity shouldn't simply mean:\n\n“Do more tasks.”\n\nA better model is:\n\n```\nPriorities\n ↓\nFocus\n ↓\nExecution\n ↓\nFeedback\n ↓\nAdjustment\n```\n\nAI can help with planning and prioritization, but the actual constraints of your schedule and environment still matter.\n\nThe educational group includes:\n\n```\n/studyplan\n/revisionplan\n/learningpath\n/feynman\n/memory\n/mnemonics\n/practice\n/challengequestions\n```\n\nA learning workflow could be:\n\n```\nLearn\n ↓\nExplain\n ↓\nRecall\n ↓\nPractice\n ↓\nTest\n ↓\nIdentify gaps\n ↓\nReview\n```\n\nThe Feynman technique is particularly useful:\n\n```\nLearn concept\n     ↓\nExplain simply\n     ↓\nFind gaps\n     ↓\nStudy gaps\n     ↓\nExplain again\n```\n\nThe important part is active retrieval and feedback—not simply generating longer notes.\n\nNow we enter one of the most useful categories for developers:\n\n```\n/coding\n/explaincode\n/debug\n/refactor\n/optimizecode\n/reviewcode\n```\n\nThese represent different software-engineering activities.\n\nThey should not be treated as interchangeable.\n\nFor example:\n\n```\n/coding\n```\n\nasks AI to produce an implementation.\n\nWhile:\n\n```\n/reviewcode\n```\n\nasks it to inspect an existing implementation.\n\nThe difference:\n\n```\nGeneration\n   ↓\n“Create something.”\n\nReview\n   ↓\n“Evaluate something.”\n```\n\nThat distinction is important because code generation and code evaluation have different failure modes.\n\nA useful debugging workflow is:\n\n```\nBug\n ↓\nReproduce\n ↓\nObserve\n ↓\nHypothesis\n ↓\nTest\n ↓\nFix\n ↓\nRegression Test\n```\n\nThe `/debug`\n\nlens should encourage this process.\n\nInstead of:\n\n“Fix this.”\n\na stronger debugging request provides:\n\n```\nExpected behavior\nActual behavior\nError message\nRelevant code\nEnvironment\nSteps to reproduce\n```\n\nBetter context usually produces better debugging.\n\nRefactoring is different from optimization.\n\n```\n/refactor\n```\n\nfocuses on:\n\nWhereas:\n\n```\n/optimizecode\n```\n\nfocuses on:\n\nA clean implementation isn't automatically the fastest implementation.\n\nAnd the fastest implementation isn't automatically the best design.\n\nFor algorithmic problems:\n\n```\n/pseudocode\n/algorithm\n/datastructure\n```\n\nA useful workflow:\n\n```\nProblem\n ↓\nConstraints\n ↓\nInput / Output\n ↓\nCandidate approaches\n ↓\nComplexity analysis\n ↓\nData structure\n ↓\nAlgorithm\n ↓\nImplementation\n ↓\nTesting\n```\n\nThis is particularly important for technical interviews and competitive programming.\n\nThe toolkit also includes:\n\n```\n/sql\n/regex\n/json\n/yaml\n/csv\n/xml\n```\n\nThese are practical transformation and data-manipulation tasks.\n\nFor SQL, however, the database schema matters enormously.\n\nA strong SQL request should include:\n\n```\nTables\nColumns\nRelationships\nConstraints\nSample data\nExpected result\nDatabase engine\n```\n\nFor example:\n\n```\nPostgreSQL\n≠\nSQL Server\n≠\nMySQL\n```\n\nEven when the syntax looks similar.\n\nThe `/api`\n\nlens can help reason about:\n\n```\nEndpoints\nHTTP methods\nRequest schemas\nResponse schemas\nAuthentication\nErrors\nVersioning\nPagination\nValidation\n```\n\nA simple API lifecycle:\n\n```\nClient\n  ↓\nRequest\n  ↓\nValidation\n  ↓\nAuthentication\n  ↓\nBusiness Logic\n  ↓\nDatabase / Service\n  ↓\nResponse\n```\n\nThinking in this structure makes API design more systematic.\n\nResearch requires a different mindset.\n\nUseful lenses:\n\n```\n/researchplan\n/literaturereview\n/hypothesis\n/experiment\n/peerreview\n/critic\n/audit\n```\n\nA structured research workflow:\n\n```\nResearch Question\n        ↓\nLiterature\n        ↓\nGap\n        ↓\nHypothesis\n        ↓\nMethod\n        ↓\nExperiment\n        ↓\nEvidence\n        ↓\nAnalysis\n        ↓\nConclusion\n```\n\nAI can help organize this process, but generated references, claims, statistics, and citations still need verification.\n\nA hypothesis should be testable.\n\nFor example:\n\n```\nOpinion:\n“This model seems better.”\n\nHypothesis:\n“Model A will achieve higher F1-score than Model B\non dataset X under the same evaluation protocol.”\n```\n\nThe second statement can actually be tested.\n\nThat's a major difference.\n\nThe `/experiment`\n\nlens can help structure:\n\n```\nIndependent variable\nDependent variable\nControls\nDataset\nProcedure\nEvaluation metric\nExpected outcome\nThreats to validity\n```\n\nA simplified structure:\n\n```\n        EXPERIMENT\n             │\n     ┌───────┼────────┐\n     ↓       ↓        ↓\n  INPUT   METHOD   CONTROL\n     │       │        │\n     └───────┼────────┘\n             ↓\n          OUTPUT\n             ↓\n         METRICS\n             ↓\n       INTERPRETATION\n```\n\nThis is much stronger than simply asking AI:\n\n“Design an experiment.”\n\nTwo particularly useful lenses are:\n\n```\n/peerreview\n/critic\n```\n\nTheir purpose should not be:\n\n“Find everything wrong.”\n\nInstead:\n\n```\nClaim\n ↓\nEvidence\n ↓\nReasoning\n ↓\nAssumptions\n ↓\nLimitations\n ↓\nAlternative explanations\n```\n\nA strong critique should distinguish:\n\n```\nFact\nInference\nAssumption\nOpinion\nUncertainty\n```\n\nThis is one of the most useful habits when working with AI-generated material.\n\n`/audit`\n\nLens\nAn audit is broader than a review.\n\nFor example:\n\n```\nTechnical Audit\n```\n\ncould inspect:\n\n```\nArchitecture\nSecurity\nPerformance\nMaintainability\nTesting\nDependencies\nDocumentation\nDeployment\n```\n\nA research audit could inspect:\n\n```\nSources\nMethodology\nEvidence\nStatistics\nClaims\nLimitations\nReproducibility\n```\n\nThe same underlying lens can therefore be adapted to different domains.\n\n`/framework`\n\nThe final shortcut is:\n\n```\n/framework\n```\n\nThis is arguably one of the most powerful concepts in the collection.\n\nInstead of asking:\n\n“Which framework should I use?”\n\nyou can ask AI to first determine:\n\n```\nProblem\n ↓\nCharacteristics\n ↓\nCandidate frameworks\n ↓\nSelection criteria\n ↓\nMost suitable framework\n ↓\nApplication\n```\n\nFor example:\n\n```\nRoot cause?\n→ Fishbone\n\nPrioritization?\n→ Pareto\n\nProject execution?\n→ Kanban / Scrum\n\nStrategic analysis?\n→ SWOT / PESTLE\n\nExperiment?\n→ Experimental design\n\nDecision?\n→ Decision tree / decision matrix\n```\n\nThe framework should match the problem.\n\n| # | Shortcut | Purpose |\n|---|---|---|\n| 301 | `/rewrite` |\nRewrite while preserving meaning |\n| 302 | `/improve` |\nImprove clarity and quality |\n| 303 | `/polish` |\nMake writing smoother |\n| 304 | `/proofread` |\nCorrect grammar and spelling |\n| 305 | `/grammar` |\nFix grammar only |\n| 306 | `/copyedit` |\nProfessional copy editing |\n| 307 | `/expand` |\nAdd useful detail |\n| 308 | `/shorten` |\nCondense content |\n| 309 | `/paraphrase` |\nReword naturally |\n| 310 | `/simplifytext` |\nUse simpler language |\n| 311 | `/formal` |\nFormal tone |\n| 312 | `/casual` |\nCasual conversational tone |\n| 313 | `/friendly` |\nWarm, friendly tone |\n| 314 | `/professional` |\nProfessional business tone |\n| 315 | `/persuasive` |\nStrengthen persuasion |\n| 316 | `/convincing` |\nStrengthen arguments |\n| 317 | `/academic` |\nAcademic style |\n| 318 | `/journalistic` |\nNews-style writing |\n| 319 | `/story` |\nStory format |\n| 320 | `/essay` |\nEssay format |\n| 321 | `/article` |\nArticle format |\n| 322 | `/report` |\nProfessional report |\n| 323 | `/whitepaper` |\nWhite-paper structure |\n| 324 | `/casestudy` |\nCase-study format |\n| 325 | `/proposal` |\nBusiness proposal |\n| 326 | `/sop` |\nStandard operating procedure |\n| 327 | `/playbook` |\nReusable playbook |\n| 328 | `/manual` |\nUser manual |\n| 329 | `/guide` |\nStep-by-step guide |\n| 330 | `/faq` |\nFrequently asked questions |\n| 331 | `/checklist` |\nChecklist format |\n| 332 | `/template` |\nReusable template |\n| 333 | `/outline` |\nStructured outline |\n| 334 | `/bulletpoints` |\nBullet summary |\n| 335 | `/keypoints` |\nKey takeaways |\n| 336 | `/highlights` |\nImportant ideas |\n| 337 | `/notes` |\nStudy notes |\n| 338 | `/minutes` |\nMeeting minutes |\n| 339 | `/agenda` |\nMeeting agenda |\n| 340 | `/meetingsummary` |\nMeeting summary |\n| 341 | `/todo` |\nTask list |\n| 342 | `/kanban` |\nKanban task board |\n| 343 | `/gantt` |\nGantt-style plan |\n| 344 | `/okr` |\nObjectives and key results |\n| 345 | `/kpi` |\nKey performance indicators |\n| 346 | `/smartgoals` |\nSMART goals |\n| 347 | `/roadmap90` |\n90-day roadmap |\n| 348 | `/roadmapyear` |\nAnnual roadmap |\n| 349 | `/milestones` |\nProject milestones |\n| 350 | `/risks` |\nRisk assessment |\n| 351 | `/riskmatrix` |\nLikelihood × impact |\n| 352 | `/dependencies` |\nTask dependencies |\n| 353 | `/estimate` |\nEffort/time estimation |\n| 354 | `/budget` |\nBudget planning |\n| 355 | `/forecast` |\nForecasting |\n| 356 | `/metrics` |\nUseful metrics |\n| 357 | `/dashboardmetrics` |\nDashboard KPI ideas |\n| 358 | `/decisiontree` |\nDecision-tree analysis |\n| 359 | `/fishbone` |\nRoot-cause analysis |\n| 360 | `/pareto` |\n80/20 analysis |\n| 361 | `/lean` |\nLean methodology |\n| 362 | `/sixsigma` |\nSix Sigma approach |\n| 363 | `/agile` |\nAgile methodology |\n| 364 | `/scrum` |\nScrum framework |\n| 365 | `/kanbanflow` |\nKanban workflow |\n| 366 | `/productivity` |\nProductivity optimization |\n| 367 | `/timemanagement` |\nTime management |\n| 368 | `/pomodoro` |\nPomodoro scheduling |\n| 369 | `/studyplan` |\nStudy plan |\n| 370 | `/revisionplan` |\nRevision timetable |\n| 371 | `/learningpath` |\nProgressive learning path |\n| 372 | `/feynman` |\nFeynman technique |\n| 373 | `/memory` |\nMemory techniques |\n| 374 | `/mnemonics` |\nMnemonic creation |\n| 375 | `/practice` |\nPractice exercises |\n| 376 | `/challengequestions` |\nDifficult questions |\n| 377 | `/coding` |\nWrite code |\n| 378 | `/explaincode` |\nExplain code |\n| 379 | `/debug` |\nDebug code |\n| 380 | `/refactor` |\nRefactor code |\n| 381 | `/optimizecode` |\nOptimize performance |\n| 382 | `/reviewcode` |\nCode review |\n| 383 | `/pseudocode` |\nGenerate pseudocode |\n| 384 | `/algorithm` |\nDesign algorithms |\n| 385 | `/datastructure` |\nChoose data structures |\n| 386 | `/sql` |\nGenerate SQL |\n| 387 | `/regex` |\nGenerate regular expressions |\n| 388 | `/api` |\nDesign/explain APIs |\n| 389 | `/json` |\nWork with JSON |\n| 390 | `/yaml` |\nGenerate YAML |\n| 391 | `/csv` |\nGenerate CSV |\n| 392 | `/xml` |\nGenerate XML |\n| 393 | `/researchplan` |\nPlan research |\n| 394 | `/literaturereview` |\nReview literature |\n| 395 | `/hypothesis` |\nGenerate testable hypotheses |\n| 396 | `/experiment` |\nDesign experiments |\n| 397 | `/peerreview` |\nCritical peer review |\n| 398 | `/critic` |\nConstructive criticism |\n| 399 | `/audit` |\nComprehensive audit |\n| 400 | `/framework` |\nSelect an appropriate analytical framework |\n\nThe interesting thing about these 100 lenses is that they can be connected.\n\nFor example, building a software project:\n\n```\nIDEA\n ↓\n/researchplan\n ↓\n/proposal\n ↓\n/roadmap90\n ↓\n/milestones\n ↓\n/dependencies\n ↓\n/coding\n ↓\n/reviewcode\n ↓\n/debug\n ↓\n/optimizecode\n ↓\n/audit\n```\n\nWriting a research paper:\n\n```\nQUESTION\n ↓\n/researchplan\n ↓\n/literaturereview\n ↓\n/hypothesis\n ↓\n/experiment\n ↓\n/analysis\n ↓\n/critic\n ↓\n/peerreview\n ↓\n/article\n```\n\nPreparing for an exam:\n\n```\nSYLLABUS\n ↓\n/learningpath\n ↓\n/studyplan\n ↓\n/notes\n ↓\n/feynman\n ↓\n/practice\n ↓\n/challengequestions\n ↓\n/revisionplan\n```\n\nThat's where these shortcuts become more interesting.\n\nThey stop being isolated commands and become **workflow components**.\n\nThere is a temptation to think:\n\n“The more detailed the prompt, the better.”\n\nI don't think that's always true.\n\nA better principle is:\n\nGive the model the right context, the right task, the right constraints, and the right evaluation criteria.\n\nA useful conceptual model is:\n\n```\nBetter Result\n     =\nContext\n+\nTask\n+\nConstraints\n+\nRelevant Lens\n+\nEvaluation\n```\n\nNot:\n\n```\nBetter Result\n=\nMore Words\n```\n\nThe most interesting future for AI assistants may not be about having one enormous prompt.\n\nIt may be about having **many small, composable reasoning modes**.\n\nInstead of:\n\n“AI, do everything.”\n\nWe move toward:\n\n```\nAI\n ├── Writer\n ├── Researcher\n ├── Programmer\n ├── Reviewer\n ├── Planner\n ├── Analyst\n ├── Teacher\n └── Auditor\n```\n\nAnd the user chooses the appropriate lens for the current problem.\n\nThat makes AI interaction feel less like asking a chatbot a question—\n\nand more like operating a **general-purpose cognitive workbench**.\n\nIf you could add **one more shortcut to this 301–400 collection**, what would it be?\n\nMaybe:\n\n`/securityaudit`\n\n`/testcode`\n\n`/factcheck`\n\n`/architecture`\n\n`/benchmark`\n\n`/citationcheck`\n\nor something completely different?\n\nI'm especially interested in shortcuts that can turn AI from a **content generator into a verification and reasoning tool**.", "url": "https://wpnews.pro/news/100-writing-productivity-coding-research-lenses-for-chatgpt", "canonical_source": "https://dev.to/probal_dhali_f7d15eac866a/100-writing-productivity-coding-research-lenses-for-chatgpt-47mm", "published_at": "2026-08-24 15:49:19+00:00", "updated_at": "2026-08-24 16:13:53.815154+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-tools", "developer-tools"], "entities": ["ChatGPT"], "alternates": {"html": "https://wpnews.pro/news/100-writing-productivity-coding-research-lenses-for-chatgpt", "markdown": "https://wpnews.pro/news/100-writing-productivity-coding-research-lenses-for-chatgpt.md", "text": "https://wpnews.pro/news/100-writing-productivity-coding-research-lenses-for-chatgpt.txt", "jsonld": "https://wpnews.pro/news/100-writing-productivity-coding-research-lenses-for-chatgpt.jsonld"}}