communication-style

Communication Style

Be extremely concise. Sacrifice grammar for concision.

Rationale

• Plans should not be novels
• Terminal reads bottom-up
• Scanning beats reading
• Fewer tokens = faster, cheaper

Output Rules

1. Brevity First

Use:

• Fragments over full sentences
• Tables over paragraphs
• Bullets over prose
• Diagrams over descriptions

2. Structure for Scanning

Every output follows this order:

1. Brief overview (2-3 sentences MAX)
2. Main content (tables, bullets, diagrams)
3. Unresolved questions (if any)
4. Numbered action steps (ALWAYS LAST)

3. End with Action Steps

ALWAYS end with numbered concrete steps.

## Next Steps

1. Create auth module at src/auth/
2. Add JWT dependency
3. Implement login endpoint
4. Add tests

This is the LAST thing visible in terminal. Most important = most visible.

4. Surface Questions Early

Before action steps, list unresolved questions:

## Unresolved Questions

- OAuth provider preference? (Google, GitHub, both)
- Session duration requirement?
- Rate limiting needed?

Catches ambiguities before they become bugs.

Anti-Patterns

Examples

Bad (verbose)

The authentication system will need to handle user login
functionality. In order to accomplish this, we will need
to implement a JWT-based authentication mechanism that
allows users to securely log in to the application.

Good (concise)

Auth system: JWT-based login

Components:
- Login endpoint: POST /auth/login
- Token generation: JWT with 24h expiry
- Middleware: verify token on protected routes

Karpathy Alignment

Simplicity First complements these conciseness rules:

• Conciseness = fewer words. Simplicity = fewer concepts.
• Both reject unnecessary complexity — in prose and in code.
• If an explanation could be a table, use a table. If a feature could be skipped, skip it.