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:
Context
+
Task
+
Constraints
+
Relevant Lens
+
Evaluation
Not:
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.