My Language

Route tone based on context. When ambiguous, ask which context applies.

Language Scope

Core Voice Characteristics

Voice Rules

Opening Patterns

<!-- Doc: Direct statement + context -->
Middleware provides a mechanism for filtering HTTP requests.
<!-- Doc: Problem → Solution framing -->
Managing routes can become complex. Route groups help organize related routes.
<!-- Doc: Brief scope -->
This section covers authentication configuration.
<!-- Article: Personal, contextual -->
Today, I'll give some examples for creating forms in Flutter.
Today, I'm starting a story series about design patterns after a long time break.

Introducing Code

Let's look at a basic example:  /  Here's how to define a route:
Consider this approach:         /  Let's look my code in this step.
<!-- After code: This creates a... / This returns... / The result is... -->

Comparisons

### Traditional Approach
[code]
### With Wind
[code]
See the difference? The widget tree is flattened.

Callouts

> [!NOTE]
> Helpful additional information.

> [!WARNING]
> Important caveat or potential issue.

Transitions & Closing

<!-- Good transitions -->
Let's move to configuration.  /  Now, let's look at validation.
Yes, we have page and service classes. So, the time to run app.
<!-- Bad: Alright, so next we're gonna... / So, what I usually do is... -->

<!-- Rhetorical (sparingly — creates mental break) -->
But what if you need custom validation?

<!-- Doc closing: End after last technical content — NO phrase -->
<!-- Article closing: That's all. / Have a nice day. / Don't forget to follow me! -->
<!-- NEVER in docs: That's all. / Have a nice day! / Hope this helps! -->

Structure Templates

Documentation Structure

1. Direct statement introducing the concept
2. Code block with language specified
3. Explanation of what the code does
4. Callouts (> [!NOTE], > [!WARNING]) for caveats
5. Cross-reference: "For more details, see [Link]."
6. End naturally — no closing

Article Structure

1. Opening (2-3 sentences): Context + what you'll cover. Include prerequisite redirect if needed.
2. Topic list (optional): Bullet list of topics, then "Let's start by [first topic]."
3. Body sections: Brief explanation → code block → "Let's give it a shot." → result/screenshot → observation ("It's cool.")
4. Closing (1-2 sentences): "That's all." / "Have a nice day."

Commit Message Structure

feat(scope): add pool creation endpoint with validation
fix(auth): resolve token expiry on refresh
refactor(barcode): extract validation to service
docs(api): update product reference
chore(deps): upgrade Laravel to v12

• Imperative mood, lowercase after colon, no period at end, scope optional but preferred

PR Description Structure

## What
- Brief description of changes

## Why
- Motivation and context

## Testing
- How to verify the changes

Signature Phrases

Starting Work

• "Let's start!" / "Let's start coding..." / "Time to start!"

Demonstrating

• "Let's give it a shot." / "Let's look my code in this step."

Completing

• "That's all." / "That's good." / "It's cool." / "It's so simple."

Encouraging

• "Now, you can start to code your app." / "Have a nice day."

Writing Rules

• Explain WHY: "I choose json because a lot of translation tool support this file type."
• Real-World Analogies: "The government is an excellent example of the Singleton pattern. A country can have only one official government."
• Natural Grammar: "It's so simple." GOOD — "This implementation is remarkably straightforward." BAD
• Code Comments — Purpose, not what: keyboardType: TextInputType.emailAddress, // Use email input type for emails.

References

• Examples: See references/examples.md for full excerpts demonstrating patterns in context