Optimalizace ChatGPT Custom Instructions

# Kompletní Custom Instructions pro Full-Stack Vývojáře

## Část 1: What would you like ChatGPT to know about you?

```
I am a full-stack developer with 5 years of experience, specializing in React and Node.js ecosystems. I use ChatGPT primarily for:
- Technical problem-solving and debugging
- Code review and architecture design
- Best practices consultation

My technical context:
- Frontend: React (Hooks, Context, custom hooks), TypeScript, Next.js, state management (Redux, Zustand)
- Backend: Node.js, Express, NestJS, RESTful APIs, GraphQL
- Database: PostgreSQL, MongoDB, Redis
- DevOps: Docker, CI/CD, AWS basics
- Testing: Jest, React Testing Library, Cypress

I am comfortable with advanced JavaScript/TypeScript concepts (closures, prototypes, async patterns, generics) and modern development practices.

I value:
- Practical, production-ready solutions
- Security and performance considerations
- Scalable and maintainable code architecture
- Clear explanation of trade-offs between different approaches
```

**Proč je to formulováno takto:**
- **Konkrétní technologie**: Místo "znám JavaScript" uvádím specifické frameworky a nástroje, které používám. ChatGPT tak ví, jaký ekosystém zná uživatel.
- **Úroveň zkušeností**: "5 years experience" + výčet pokročilých konceptů dává ChatGPT jasný signál, že nepotřebuji základní vysvětlení.
- **Kontext použití**: Jasně definované případy užití (debugging, code review, architecture) pomáhají ChatGPT optimalizovat odpovědi.
- **Hodnoty**: Explicitní zmínka o tom, co je pro mě důležité (security, performance, scalability), zajistí, že tyto aspekty budou zahrnuty v odpovědích.

## Část 2: How would you like ChatGPT to respond?

```
Response structure I prefer:
1. Brief analysis (1-2 sentences identifying the core issue or question)
2. Primary solution with production-ready code example
3. Alternative approaches (if applicable) with pros/cons
4. Potential issues, edge cases, or performance implications

Code requirements:
- Always use TypeScript when providing code examples
- Include relevant type definitions and interfaces
- Show practical, copy-paste-ready examples (not pseudo-code)
- Comment only non-obvious logic; assume I understand standard patterns
- Consider error handling, validation, and edge cases
- Mention security implications if relevant

What to ALWAYS do:
- Suggest best practices and modern patterns (e.g., React Server Components, custom hooks over class components)
- Consider performance (re-renders, memory leaks, database query optimization)
- Recommend appropriate testing strategies
- Link to official documentation when suggesting libraries/approaches

What to NEVER do:
- Explain basic concepts (closures, promises, React lifecycle, REST principles)
- Generate boilerplate without explaining the important parts
- Ignore TypeScript type safety or use "any" unnecessarily
- Suggest solutions without considering scalability
- Provide generic advice without concrete implementation details

Preferred tone:
- Technical and precise
- Concise but complete
- Professional but conversational
- No excessive pleasantries or motivational language
```

**Proč je to formulováno takto:**
- **Strukturovaný formát**: Definovaná struktura (analýza → řešení → alternativy → problémy) zajišťuje konzistentní a přehledné odpovědi.
- **Technické požadavky**: Specifikace pro TypeScript, type definitions a production-ready kód eliminuje nutnost opakovaně vyžadovat tyto vlastnosti.
- **ALWAYS/NEVER seznamy**: Jasné direktivy předcházejí nežádoucímu chování (např. vysvětlování základů) a zajišťují důležité aspekty (např. security considerations).
- **Tón komunikace**: Definice tónu eliminuje zbytečné "Určitě! Rád vám pomůžu s..." a zaměří se na technický obsah.

## Příklady Dotazů a Odpovědí

### Příklad 1: Dotaz na optimalizaci React komponenty

**Dotaz:**
"Jak optimalizovat tuto komponentu? Renderuje se příliš často."

```typescript
function UserList({ users, onUserClick }) {
return (
<div>
{users.map(user => (
<UserCard
key={user.id}
user={user}
onClick={() => onUserClick(user.id)}
/>
))}
</div>
);
}
```

**Odpověď BEZ Custom Instructions** (typická obecná odpověď):
"Ano, je několik způsobů, jak optimalizovat React komponentu! Můžete použít React.memo, useMemo, useCallback... Nejprve se podívejme na React.memo - je to higher-order component, která zabrání zbytečnému re-renderingu... [následuje dlouhé vysvětlení základů]"

**Odpověď S Custom Instructions** (optimalizovaná pro pokročilého vývojáře):

**Analýza:** Problém je v inline funkci v onClick prop, která se vytváří při každém renderu rodiče, což způsobuje re-render všech UserCard i při nezměněných users.

**Primary Solution:**

```typescript
interface User {
id: string;
name: string;
email: string;
}

interface UserListProps {
users: User[];
onUserClick: (userId: string) => void;
}

const UserCard = React.memo<{ user: User; onClick: () => void }>(
({ user, onClick }) => {
return (
<div className="user-card" onClick={onClick}>
<h3>{user.name}</h3>
<p>{user.email}</p>
</div>
);
}
);

function UserList({ users, onUserClick }: UserListProps) {
// Stabilní handleClick funkce pro každého usera
const handleUserClick = useCallback(
(userId: string) => () => onUserClick(userId),
[onUserClick]
);

return (
<div className="user-list">
{users.map(user => (
<UserCard
key={user.id}
user={user}
onClick={handleUserClick(user.id)}
/>
))}
</div>
);
}
```

**Alternative Approach - Context API pro velké listy:**

```typescript
const UserClickContext = createContext<(userId: string) => void>(() => {});

function UserList({ users, onUserClick }: UserListProps) {
return (
<UserClickContext.Provider value={onUserClick}>
<div className="user-list">
{users.map(user => (
<UserCard key={user.id} user={user} />
))}
</div>
</UserClickContext.Provider>
);
}

const UserCard = React.memo<{ user: User }>(({ user }) => {
const onUserClick = useContext(UserClickContext);

return (
<div className="user-card" onClick={() => onUserClick(user.id)}>
<h3>{user.name}</h3>
<p>{user.email}</p>
</div>
);
});
```

**Pros/Cons:**
- **Callback factory approach**: Jednodušší, vhodné pro < 50 položek
- **Context approach**: Lepší pro velké listy (100+), stabilnější reference, ale složitější setup

**Potential Issues:**
- Pokud `users` array reference se mění při každém renderu (např. filter/map v parent), zvažte useMemo na users
- Pro virtualizaci velmi dlouhých listů (1000+ items) použijte react-window nebo react-virtuoso
- Performance profiling: React DevTools Profiler ukáže, zda optimalizace skutečně pomáhá

**Testing Strategy:**
```typescript
// Test memo behavior
it('should not re-render UserCard when users prop is stable', () => {
const { rerender } = render(
<UserCard user={mockUser} onClick={mockHandler} />
);
const initialElement = screen.getByText(mockUser.name);

rerender(<UserCard user={mockUser} onClick={mockHandler} />);
const laterElement = screen.getByText(mockUser.name);

expect(initialElement).toBe(laterElement); // Same DOM node = no re-render
});
```

---

**Vidíte rozdíl?** S custom instructions ChatGPT:
1. ✅ Přeskočil vysvětlení co je React.memo a jak funguje
2. ✅ Poskytl TypeScript kód s interfaces
3. ✅ Nabídl alternativní řešení s analýzou trade-offs
4. ✅ Zmínil edge cases (array reference, virtualization)
5. ✅ Přidal testing strategy
6. ✅ Používá technický, stručný jazyk

### Příklad 2: Dotaz na architekturu API

**Dotaz:**
"Navrhuji microservices architekturu pro e-commerce. Potřebuji rozdělit služby podle domén."

**Odpověď BEZ Custom Instructions:**
"Microservices jsou skvělý přístup! Nejprve si vysvětlíme, co jsou microservices... [základní teorie] ...výhody microservices jsou... [obecné výhody] ...můžete mít službu pro produkty, službu pro uživatele..."

**Odpověď S Custom Instructions:**

**Analýza:** E-commerce microservices architecture s domain-driven design approach. Klíčové je správné ohraničení domén (bounded contexts) a definice komunikačních vzorů.

**Primary Solution - Domain Decomposition:**

```typescript
// Service Boundaries
interface ServiceArchitecture {
// Core Business Services
productCatalog: {
responsibilities: ['Product CRUD', 'Categories', 'Inventory tracking', 'Search indexing'],
database: 'PostgreSQL',
cache: 'Redis',
events: ['ProductCreated', 'ProductUpdated', 'StockChanged']
},

orderManagement: {
responsibilities: ['Order placement', 'Order status', 'Payment coordination', 'Fulfillment tracking'],
database: 'PostgreSQL (with event sourcing)',
events: ['OrderPlaced', 'OrderPaid', 'OrderShipped', 'OrderCompleted', 'OrderCancelled']
},

userManagement: {
responsibilities: ['Authentication', 'Authorization', 'User profiles', 'Preferences'],
database: 'PostgreSQL',
cache: 'Redis (sessions)',
events: ['UserRegistered', 'UserUpdated']
},

paymentService: {
responsibilities: ['Payment processing', 'Refunds', 'Payment method storage', 'PCI compliance'],
database: 'PostgreSQL (encrypted)',
integration: 'Stripe/PayPal',
events: ['PaymentInitiated', 'PaymentCompleted', 'PaymentFailed', 'RefundProcessed']
},

// Supporting Services
notificationService: {
responsibilities: ['Email', 'SMS', 'Push notifications', 'Template management'],
database: 'MongoDB (logs)',
queue: 'RabbitMQ/SQS',
consumers: 'Multiple event types from all services'
},

analyticsService: {
responsibilities: ['Event tracking', 'Reporting', 'Data aggregation'],
database: 'ClickHouse/BigQuery',
consumers: 'All domain events'
}
}

// Event-Driven Communication Pattern
interface OrderPlacedEvent {
eventId: string;
eventType: 'OrderPlaced';
timestamp: Date;
aggregateId: string; // orderId
version: number;
data: {
orderId: string;
userId: string;
items: Array<{
productId: string;
quantity: number;
priceAtPurchase: number;
}>;
totalAmount: number;
shippingAddress: Address;
};
}

// Order Service publishes event
class OrderService {
async placeOrder(orderData: CreateOrderDTO): Promise<Order> {
const order = await this.orderRepository.create(orderData);

// Publish event to message bus
await this.eventBus.publish<OrderPlacedEvent>({
eventId: uuidv4(),
eventType: 'OrderPlaced',
timestamp: new Date(),
aggregateId: order.id,
version: 1,
data: {
orderId: order.id,
userId: order.userId,
items: order.items,
totalAmount: order.total,
shippingAddress: order.shippingAddress
}
});

return order;
}
}

// Inventory Service listens and reserves stock
class InventoryEventHandler {
@EventHandler('OrderPlaced')
async handleOrderPlaced(event: OrderPlacedEvent): Promise<void> {
try {
// Reserve stock for order items
await this.inventoryService.reserveStock(
event.data.items.map(item => ({
productId: item.productId,
quantity: item.quantity,
orderId: event.data.orderId
}))
);

// Publish success event
await this.eventBus.publish({
eventType: 'StockReserved',
orderId: event.data.orderId,
timestamp: new Date()
});

} catch (error) {
// Publish failure event - triggers compensation
await this.eventBus.publish({
eventType: 'StockReservationFailed',
orderId: event.data.orderId,
reason: error.message,
timestamp: new Date()
});
}
}
}
```

**Inter-Service Communication Patterns:**

1. **Synchronous (REST/gRPC) - pro read operations a validace:**
```typescript
// API Gateway pattern
class OrderController {
async getOrderDetails(orderId: string): Promise<OrderDetailsDTO> {
// Parallel calls to multiple services
const [order, user, products] = await Promise.all([
this.orderServiceClient.getOrder(orderId),
this.userServiceClient.getUser(order.userId),
this.productServiceClient.getProducts(order.items.map(i => i.productId))
]);

return this.assembleOrderDetails(order, user, products);
}
}
```

2. **Asynchronous (Event Bus) - pro write operations a side effects:**
```typescript
// RabbitMQ/Kafka event bus
interface EventBusConfig {
exchanges: {
'domain.events': {
type: 'topic',
durable: true,
routingPatterns: {
'order.*': ['order-service', 'analytics-service'],
'payment.*': ['payment-service', 'order-service', 'notification-service'],
'product.*': ['product-service', 'search-service', 'analytics-service']
}
}
}
}
```

**Saga Pattern pro distributed transactions:**
```typescript
class OrderSaga {
async execute(orderData: CreateOrderDTO): Promise<void> {
const sagaId = uuidv4();

try {
// Step 1: Create order
const order = await this.orderService.createOrder(orderData, sagaId);

// Step 2: Reserve inventory
await this.inventoryService.reserveStock(order.items, sagaId);

// Step 3: Process payment
await this.paymentService.processPayment(order.payment, sagaId);

// Step 4: Confirm order
await this.orderService.confirmOrder(order.id);

// Success - publish OrderCompleted event
await this.eventBus.publish({ eventType: 'OrderCompleted', orderId: order.id });

} catch (error) {
// Compensation: rollback all steps
await this.compensate(sagaId, error);
}
}

private async compensate(sagaId: string, error: Error): Promise<void> {
// Reverse order of operations
await this.paymentService.refund(sagaId);
await this.inventoryService.releaseStock(sagaId);
await this.orderService.cancelOrder(sagaId);

await this.eventBus.publish({
eventType: 'OrderFailed',
sagaId,
reason: error.message
});
}
}
```

**Alternative Approach - Modular Monolith First:**

Místo okamžitého microservices, začněte s modular monolith a rozdělte později:

```typescript
// Modular monolith structure
src/
├── modules/
│ ├── orders/
│ │ ├── domain/
│ │ ├── application/
│ │ ├── infrastructure/
│ │ └── interface/
│ ├── products/
│ ├── users/
│ └── payments/
├── shared/
│ ├── events/
│ ├── database/
│ └── utils/
```

**Pros/Cons:**
- **Microservices**: Nezávislé škálování, technologická svoboda, izolace selhání | Složitější deployment, distributed transactions, network latency
- **Modular Monolith**: Jednodušší development, rychlejší iteration, ACID transactions | Společné škálování, potenciálně náročnější refactoring později

**Potential Issues:**
1. **Network Failures**: Implementujte circuit breaker pattern (Polly, resilience4j)
2. **Data Consistency**: Eventual consistency - UI musí toto reflektovat (loading states)
3. **Distributed Tracing**: Používejte correlation IDs napříč službami (OpenTelemetry)
4. **Service Discovery**: Kubernetes service mesh nebo Consul pro dynamic service location
5. **API Versioning**: Implementujte versioning od začátku (/v1/, /v2/ nebo header-based)

**Performance Considerations:**
- **Database per Service**: Izolace, ale složitější joins → používejte CQRS pattern pro read models
- **Event Sourcing**: Pro order-service pro audit trail a replay capability
- **Caching Strategy**: Redis pro session, product catalog cache s invalidation on ProductUpdated events
- **Rate Limiting**: Per-service a API gateway level pro DDoS protection

**Recommended Tech Stack:**
- **API Gateway**: Kong nebo AWS API Gateway
- **Message Bus**: Kafka (high throughput) nebo RabbitMQ (flexibility)
- **Service Mesh**: Istio nebo Linkerd pro observability
- **Container Orchestration**: Kubernetes
- **Monitoring**: Prometheus + Grafana, ELK stack pro logy

**Migration Strategy:**
1. Start with modular monolith, jasné module boundaries
2. Extract stateless services first (notification-service)
3. Následně business-critical services (payment, order)
4. Implementujte strangler fig pattern pro postupnou migraci

---

**Vidíte rozdíl?** S custom instructions dostanete:
1. ✅ Konkrétní architekturu s kódem, ne teoretické vysvětlení
2. ✅ Event-driven patterns s TypeScript interfaces
3. ✅ Saga pattern pro distributed transactions
4. ✅ Alternative approach s analýzou trade-offs
5. ✅ Security, performance a migration considerations
6. ✅ Doporučení konkrétních technologií

## Další Tipy na Optimalizaci Custom Instructions

### 1. Iterativní Vylepšování

Custom instructions nejsou "set and forget" - průběžně je vylepšujte:

**Sledujte vzory:**
- Pokud často musíte upřesňovat "potřebuji TypeScript", přidejte to do instructions
- Pokud dostáváte příliš dlouhé odpovědi, specifikujte preferovanou délku
- Pokud ChatGPT ignoruje určitý aspekt, zdůrazněte ho v ALWAYS sekci

**Měsíční review:**
```
Každý měsíc si projděte:
1. Conversations, kde jste museli korigovat odpověď → přidejte do instructions
2. Opakující se požadavky → automatizujte je v instructions
3. Nové technologie, které jste osvojili → aktualizujte svůj profil
```

### 2. Specifické Formulace, Které Fungují

**Místo vágního:**
"Vysvětli věci jednoduše"

**Použijte konkrétní:**
"Assume I understand [basic concepts]. Focus explanation on [specific aspect]. Use analogies only for complex architectural patterns."

**Místo obecného:**
"Dávej mi příklady kódu"

**Použijte detailní:**
"Always provide production-ready TypeScript code with:
- Complete type definitions
- Error handling for edge cases
- Comments only for non-obvious logic
- Relevant unit tests when introducing new patterns"

### 3. Kontextové Instructions pro Různé Projekty

Vytvořte si varianty instructions pro různé kontexty:

**Frontend Development Instructions:**
```
Current project context:
- Next.js 14 with App Router and Server Components
- TailwindCSS for styling
- React Hook Form + Zod for forms
- Tanstack Query for data fetching
- Vercel deployment

Always consider:
- Server vs Client Components trade-offs
- SEO implications of rendering strategy
- Core Web Vitals optimization
```

**Backend Development Instructions:**
```
Current project context:
- NestJS with TypeORM
- PostgreSQL with indexes and materialized views
- Redis for caching and pub/sub
- AWS Lambda for async processing
- Stripe for payments

Always consider:
- Database query performance (use EXPLAIN ANALYZE)
- Transaction boundaries and isolation levels
- API rate limiting and authentication
- Background job failures and retries
```

### 4. Negativní Instructions (Co NIKDY nedělat)

Jsou často důležitější než pozitivní:

```
NEVER:
- Use "any" type in TypeScript (use "unknown" if truly needed)
- Suggest solutions without error handling
- Ignore accessibility (a11y) in React components
- Recommend installing packages without checking bundle size impact
- Use "var" keyword (use const/let)
- Create unindexed database queries on large tables
- Store sensitive data in localStorage (use httpOnly cookies)
- Use Math.random() for cryptographic purposes (use crypto.randomBytes)
```

### 5. Meta-Instructions (Jak ChatGPT má přemýšlet)

```
Problem-solving approach:
1. Identify root cause before suggesting fix
2. Consider if there's a simpler solution without new dependencies
3. Think about edge cases and error scenarios
4. Evaluate performance implications for scale (1K, 100K, 1M users)
5. Check if solution follows SOLID principles
```

### 6. Formátovací Preferences

```
Code formatting:
- Max line length: 100 characters
- Use 2 spaces for indentation
- Always use trailing commas in objects/arrays
- Prefer named exports over default exports
- Use absolute imports (@ alias) for shared modules

Response formatting:
- Use markdown code blocks with language specification
- Use tables for comparing multiple options
- Use mermaid diagrams for architecture/flow explanations
- Bold key terms in explanations
```

## Testování Custom Instructions

Po nastavení instructions otestujte na typických dotazech:

### Test 1: Základní dotaz
**Dotaz:** "Jak vytvořit autentizaci v Next.js?"

**Očekávaný výstup s instructions:**
- Konkrétní implementace s Next.js 14 App Router
- TypeScript kód s type definitions
- Integrace s vaším preferovaným auth poskytovatelem (např. NextAuth.js)
- Security best practices
- Žádné vysvětlení co je JWT nebo session

### Test 2: Debugging dotaz
**Dotaz:** "Tento kód nefunguje: [vložíte kód]"

**Očekávaný výstup:**
- Analýza problému (ne "zkusme to vyřešit společně!")
- Konkrétní chyba identifikována
- Opravený kód
- Vysvětlení, proč původní kód selhal
- Jak zabránit podobným chybám v budoucnu

### Test 3: Architekturní dotaz
**Dotaz:** "Měl bych použít Redux nebo Zustand?"

**Očekávaný výstup:**
- Analýza vašeho use case
- Porovnání s konkrétními pros/cons pro VÁŠ projekt
- Doporučení s vysvětlením
- Implementační příklad pro doporučený přístup
- Migration strategy pokud měníte stávající řešení

## Časté Problémy a Řešení

### Problém 1: ChatGPT stále vysvětluje základy

**Řešení:**
```
Add to instructions:
"I have [X years] experience with [technologies]. Never explain:
- Basic [language] syntax
- How [framework] works
- What [concept] is
Skip directly to solving the specific problem."
```

### Problém 2: Odpovědi jsou příliš dlouhé

**Řešení:**
```
Add to instructions:
"Keep responses concise:
- Max 3 paragraphs for explanation
- Code examples should be minimal but complete
- Use bullet points for lists
- Link to docs instead of explaining framework basics"
```

### Problém 3: ChatGPT používá zastaralé patterns

**Řešení:**
```
Add to instructions:
"Use modern patterns:
- React: Hooks over class components, Server Components in Next.js 14
- JavaScript: Async/await over callbacks, optional chaining
- TypeScript: Strict mode, no implicit any
- Node.js: ESM imports over CommonJS

If suggesting older pattern, explain why it's necessary."
```

### Problém 4: Generický kód bez kontextu mého projektu

**Řešení:**
```
Add to instructions:
"My current project stack:
[list specific versions and libraries]

Always use these libraries in examples. If suggesting alternative, explain why it's better than my current setup."
```

## Závěr

Dobře napsané Custom Instructions mohou:
- ✅ Ušetřit 50-70% času na upřesňování dotazů
- ✅ Zajistit konzistentní kvalitu odpovědí
- ✅ Eliminovat vysvětlování základů
- ✅ Dostat odpovědi přímo relevantní pro váš kontext
- ✅ Automaticky zahrnout best practices

**Klíčové principy:**
1. **Buďte konkrétní** - místo "znám React" uveďte "React 18, Hooks, Suspense, Server Components"
2. **Definujte ALWAYS/NEVER** - jasné hranice eliminují nežádoucí chování
3. **Specifikujte formát** - strukturované odpovědi jsou čitelnější
4. **Iterujte** - průběžně vylepšujte podle zkušeností
5. **Testujte** - ověřte, že instructions fungují na typických dotazech