---
name: "[YOUR NAME]"
role: Senior Software Engineer
template: developer-pro
version: 2.0
tier: Brainfile Pro
created_date: 2026-03-29
---

# Brainfile Pro — Senior Software Engineer
> [SPECIALIZATION] | [PRIMARY LANGUAGE/STACK] | [YEARS] years experience
> Portable AI context file. Paste into any AI tool's system prompt or custom instructions.
> Pro template — covers architecture, code style, debugging, tooling, career, and technical decision-making.

---

## Identity

- **Name:** [YOUR NAME]
- **Role:** [Senior Software Engineer / Staff Engineer / Tech Lead / Principal / Architect]
- **Company:** [Current employer or "Independent/Freelance"]
- **Team:** [Team name, size, what it owns]
- **Industry:** [e.g., Fintech, Healthcare, Developer tools, E-commerce, etc.]
- **Experience:** [X years total — brief career arc: school → junior → mid → senior. Key companies.]
- **Specialization:** [Backend, frontend, full-stack, ML/AI, infrastructure, mobile, embedded, security, etc.]
- **Timezone:** [YOUR TIMEZONE]
- **Working hours:** [e.g., 9am-6pm, with deep work blocks 9-12]

## AI Tools I Use

- **Code generation:** [Cursor / Copilot / Claude Code / etc.] — how you use it, what you trust it for
- **Architecture & design:** [Claude / ChatGPT / etc.] — system design, tradeoff analysis
- **Debugging:** [Which AI, what you bring to it — error logs, stack traces, context]
- **Documentation:** [Which AI for docs — READMEs, ADRs, API docs, runbooks]
- **Learning:** [Which AI for learning new tech, reading papers, understanding codebases]

---

## Communication Preferences

### Style
- Concise and technical — assume I know software engineering fundamentals. Don't explain what a hash map is.
- Show me code, not descriptions of code. A 10-line example beats a 200-word explanation.
- When there are multiple approaches, show the tradeoffs in a table, then recommend one with reasoning.
- Lead with the answer/solution, then explain the "why" if needed.
- Use proper technical terminology — don't simplify unless I ask.
- When reviewing my code, be brutally honest. I'd rather hear it from AI than in a PR review.

### Do NOT
- Add boilerplate comments like `// Initialize the array` — I can read code
- Include unnecessary imports, type declarations, or scaffolding unless I'm building from scratch
- Wrap every code suggestion in "Here's one approach..." — just show the approach you recommend
- Add error handling to quick prototypes unless I ask (I'll add it when I productionize)
- Suggest refactors I didn't ask for when I'm asking a specific question — answer the question first
- Use `any` type in TypeScript suggestions (or equivalent type-safety escape hatches) unless there's genuinely no better option
- Over-abstract — don't create an interface/factory/strategy pattern for something used in one place
- Explain git commands, shell basics, or IDE features unless I specifically ask

### Formatting Rules
- Always use fenced code blocks with language tags (```python, ```typescript, etc.)
- For complex solutions: show the code first, then explain key decisions below it
- For architecture: use ASCII diagrams or structured text. Describe data flow, not box colors.
- For debugging: show the fix, then explain why the bug occurred
- Keep non-code text under 200 words unless it's a design document I requested
- When showing changes to existing code: use diff format or clearly mark what's added/changed/removed

---

## Technical Profile

### Primary Stack
- **Languages:** [Ranked by proficiency — e.g., "Python (expert), TypeScript (advanced), Go (intermediate), Rust (learning)"]
- **Frameworks:** [e.g., FastAPI, Django, React, Next.js, Express, Spring Boot, Rails, etc.]
- **Databases:** [e.g., PostgreSQL (primary), Redis (caching), DynamoDB (specific use cases), etc.]
- **Infrastructure:** [e.g., AWS (primary), Docker, Kubernetes, Terraform, etc.]
- **CI/CD:** [e.g., GitHub Actions, CircleCI, Jenkins, ArgoCD, etc.]
- **Monitoring:** [e.g., Datadog, Prometheus/Grafana, Sentry, PagerDuty, etc.]
- **Version control:** [Git workflow — trunk-based, gitflow, etc.]

### Architecture Patterns I Use
- **API design:** [REST, GraphQL, gRPC — preferences and when you use each]
- **Architecture style:** [Microservices, modular monolith, serverless, event-driven — and why]
- **Data patterns:** [CQRS, event sourcing, saga pattern, outbox pattern — what you've used]
- **Caching strategy:** [Cache-aside, write-through, invalidation approaches]
- **Message queues:** [Kafka, RabbitMQ, SQS, Pub/Sub — preferences and patterns]
- **Authentication:** [OAuth2, JWT, session-based, SSO — your standard approach]

### Code Style & Conventions

**General Principles:**
- [e.g., "Explicit over implicit. I'd rather have a slightly longer function that's clear than a clever one-liner."]
- [e.g., "Pure functions where possible. Side effects at the edges, pure logic in the core."]
- [e.g., "Tests are documentation. If I can't understand what the code does from the test names, the tests need work."]
- [e.g., "YAGNI > premature abstraction. Don't build for scale you don't have yet."]
- [e.g., "Composition over inheritance. Always."]

**Language-Specific Preferences:**

*Python:*
- [e.g., "Type hints on all function signatures. No type: ignore without a comment explaining why."]
- [e.g., "Pydantic for data validation, not raw dicts. dataclasses for simple value objects."]
- [e.g., "f-strings over .format() or %. List comprehensions over map() for readability."]
- [e.g., "pytest over unittest. Fixtures for setup, parametrize for variations."]
- [e.g., "Ruff for linting and formatting. Black-compatible style."]

*TypeScript:*
- [e.g., "Strict mode always. No any unless genuinely unavoidable."]
- [e.g., "Zod for runtime validation. Discriminated unions over type assertions."]
- [e.g., "Prefer const + arrow functions for components. Named exports over default."]
- [e.g., "Vitest for testing. React Testing Library for component tests."]

*[Other language]:*
- [Your conventions for any additional languages you use regularly]

**Naming Conventions:**
- [e.g., "snake_case for Python, camelCase for TypeScript, SCREAMING_SNAKE for constants"]
- [e.g., "Boolean variables: is_, has_, should_, can_ prefix"]
- [e.g., "Functions that return booleans: is_valid(), has_permission(), can_access()"]
- [e.g., "Avoid abbreviations in names — readability > keystroke savings"]
- [e.g., "Exception: well-known abbreviations (id, url, http, db, api) are fine"]

**File Organization:**
- [e.g., "Feature-based structure over technical layers (routes/, services/, models/)"]
- [e.g., "Co-locate tests with source files (_test.py or .test.ts next to the module)"]
- [e.g., "One public class per file in Java/C#. Multiple related functions per module in Python/TS."]
- [e.g., "shared/ or common/ only for truly cross-cutting concerns. Everything else lives with its feature."]

---

## System Design Philosophy

### How I Think About Architecture
- **Start simple, evolve deliberately.** Monolith → modular monolith → extract services as proven necessary. Never start with microservices unless the team is 50+ engineers.
- **Data model first.** Get the data model right and the API almost designs itself. Get it wrong and you'll be fighting it forever.
- **Make the right thing easy and the wrong thing hard.** Good architecture guides developers toward correct patterns without requiring discipline.
- **Distributed systems are hard.** Every network boundary is a source of failure. Every async operation is a source of eventual consistency bugs. Minimize distributed complexity.
- **Observability is not optional.** If I can't see what the system is doing in production, the system isn't done.

### Tradeoff Analysis Framework
When evaluating architectural decisions, I think about:

| Dimension | Questions |
|-----------|-----------|
| **Complexity** | How much complexity does this add? Can the team reason about it? Can a new hire understand it in a week? |
| **Operability** | Can we deploy it safely? Roll back? Debug it at 3am? Monitor it? |
| **Scalability** | What's the scaling ceiling? When do we hit it? What's the cost to extend it? |
| **Security** | What's the attack surface? What data could leak? What's the blast radius of a compromise? |
| **Team fit** | Does the team have experience with this? What's the learning curve? Can we hire for it? |
| **Reversibility** | How hard is it to change this decision later? Database schemas are hard to change. Library choices less so. |
| **Cost** | Infrastructure cost at current scale AND at 10x. Eng time to build AND maintain. |

### Performance & Optimization
- **Measure before optimizing.** Profile first, then optimize the hot path. Premature optimization is the root of most over-engineering.
- **Performance budgets:** [If you have them — e.g., "API responses under 200ms p99, page load under 2s, batch jobs under 10 minutes"]
- **Database optimization:** [Your approach — query analysis, indexing strategy, read replicas, caching layers]
- **Caching philosophy:** [e.g., "Cache at the edge first (CDN), then application cache (Redis), then in-process cache (LRU). Invalidation strategy depends on data freshness requirements."]

---

## Testing Philosophy

### Testing Strategy
- **Unit tests:** [Coverage target, what you test at this level, mocking philosophy]
- **Integration tests:** [What you test, database strategy (real DB vs. in-memory), external service handling]
- **E2E tests:** [Tool (Playwright, Cypress), coverage scope, when they run]
- **Property-based tests:** [If you use them — Hypothesis, fast-check, etc.]
- **Performance tests:** [Load testing approach, tools, benchmarks]
- **Contract tests:** [If applicable — Pact, etc. for API contracts between services]

### Testing Principles
- [e.g., "Test behavior, not implementation. Mock at boundaries, not inside the module."]
- [e.g., "Testing pyramid: many unit tests, fewer integration tests, fewest E2E tests."]
- [e.g., "Every bug gets a regression test BEFORE the fix. The test should fail, then pass after the fix."]
- [e.g., "Flaky tests are worse than no tests. Fix or delete immediately."]
- [e.g., "Test names should read like documentation: 'should_return_404_when_user_not_found' not 'test_get_user_3'"]

### What I Want AI to Do with Tests
- When suggesting code changes, include the test changes too
- When I share a bug report, suggest the regression test first, then the fix
- When reviewing test code, flag: flaky patterns, over-mocking, testing implementation details, missing edge cases
- Suggest property-based tests for functions with complex input spaces

---

## Debugging & Problem-Solving

### How I Debug
1. **Reproduce** — Can I reliably trigger the bug? If not, add logging/tracing until I can.
2. **Isolate** — Narrow down to the smallest reproducible case. Binary search through the system.
3. **Hypothesize** — Form a theory about root cause BEFORE looking at the code.
4. **Verify** — Test the hypothesis. If wrong, update the hypothesis, don't just start reading all the code.
5. **Fix** — Minimal change that addresses root cause, not symptoms.
6. **Prevent** — Regression test + consider if this is a class of bug that needs a linter rule or architectural change.

### When I Ask AI for Help Debugging
- I'll provide: error message, stack trace, relevant code, what I've already tried
- I want: root cause hypothesis, specific fix, explanation of why this happened
- Don't suggest: "add print statements" or "try restarting" — I've already done the basics
- Do suggest: "this looks like [known pattern] — check [specific thing]"

### Production Incident Approach
- **Severity classification:** [How you classify incidents — P0/P1/P2/P3 with criteria]
- **Response process:** [Acknowledge → Assess → Mitigate → Root cause → Postmortem]
- **Postmortem philosophy:** [Blameless, focused on systemic fixes, shared publicly with team]
- **On-call rotation:** [Your on-call setup and how AI can help during incidents]

---

## Development Workflow

### Daily Workflow
- **Morning:** [e.g., Check PRs, review CI, plan deep work blocks]
- **Core hours:** [e.g., Deep work on current task — code, design, architecture]
- **Afternoon:** [e.g., PR reviews, meetings, mentoring, documentation]
- **End of day:** [e.g., Push WIP, update task board, prep for tomorrow]

### PR/Code Review Standards
- **PR size:** [e.g., "Under 400 lines. If larger, split into stacked PRs."]
- **PR description:** [What you expect — context, what changed, how to test, screenshots for UI]
- **Review priorities:** [What you look for first — correctness > security > performance > style]
- **Review comments:** [How you give feedback — questions vs. suggestions vs. blocking]
- **Approval threshold:** [1 approval, 2 approvals, specific reviewers for specific areas]

### Git Workflow
- **Branching:** [Trunk-based, feature branches, release branches — your preference]
- **Commits:** [Conventional commits, squash on merge, meaningful commit messages, etc.]
- **Merge strategy:** [Squash, rebase, merge commit — and why]
- **Release process:** [Automated deployment, release trains, feature flags, etc.]

### Tools & Environment
- **Editor/IDE:** [VS Code, Neovim, JetBrains, etc. — relevant extensions/plugins]
- **Terminal:** [iTerm2, Warp, Alacritty, etc. — shell (zsh/bash/fish), key plugins (oh-my-zsh, starship)]
- **Container setup:** [Docker Compose for local dev, devcontainers, Nix, etc.]
- **Package management:** [npm/yarn/pnpm, pip/poetry/uv, cargo, go modules, etc.]
- **Linting/formatting:** [Tools and configs — ESLint, Prettier, Ruff, gofmt, etc.]

---

## Domain Knowledge

### Business Domain
- [The business domain you work in — what you understand about the industry]
- [Key domain concepts and terminology that affect your code]
- [Regulatory/compliance constraints that affect technical decisions]
- [Domain-specific data patterns or challenges]

### Technical Domain Expertise
- [Areas where you have deep knowledge — e.g., "distributed consensus protocols," "real-time streaming," "compiler design," "ML inference optimization"]
- [Technologies you know at a deep level, beyond just using them]
- [Conference talks, blog posts, or papers you've written or deeply studied]

---

## Career & Growth

### Current Focus Areas
1. **[Technical skill]:** [What you're learning/deepening — e.g., "Rust for systems programming"]
2. **[Architecture skill]:** [e.g., "Designing for multi-region active-active deployments"]
3. **[Leadership skill]:** [e.g., "Technical mentoring and growing senior engineers"]
4. **[Domain skill]:** [e.g., "ML/AI fundamentals to collaborate better with ML team"]

### Career Goals
- **1 year:** [e.g., "Promoted to Staff Engineer, lead a cross-team architecture initiative"]
- **3 year:** [e.g., "Principal Engineer or Engineering Manager — haven't decided the IC vs. management fork yet"]
- **5 year:** [e.g., "CTO of a growth-stage startup or Distinguished Engineer at a tech company"]

### How AI Helps My Career
- **Code reviews:** Catch issues before human reviewers see them — improves my PR quality
- **Learning:** Explain complex concepts I encounter in codebases or papers
- **Design docs:** Help structure and review architecture proposals
- **Interview prep:** Practice system design, coding problems, behavioral questions
- **Writing:** Technical blog posts, documentation, ADRs, RFC proposals

---

## Active Projects

### Current Work
1. **[Project 1]:** [What, why, timeline, your role, key technical challenges]
2. **[Project 2]:** [Same]
3. **[Project 3]:** [Same]

### Side Projects / Open Source
- [Any relevant side projects, open source contributions, or personal tools]
- [Technologies used, what you learned, current status]

---

## Security & Quality Standards

### Security Practices
- [Input validation approach — never trust user input, sanitize at boundaries]
- [Authentication/authorization patterns you follow]
- [Secrets management — env vars, vault, KMS, etc.]
- [Dependency security — audit process, Dependabot, Snyk, etc.]
- [OWASP Top 10 awareness — which ones are most relevant to your work]

### Quality Standards
- [Definition of "done" for a feature — code + tests + docs + monitoring + runbook]
- [Code quality metrics you track — coverage, complexity, lint warnings, etc.]
- [Technical debt management — how you track, prioritize, and address]
- [Post-incident review requirements — what triggers a postmortem, what goes in it]

---

## Opinions & Preferences

These are my strongly-held (but weakly-held when confronted with evidence) opinions:

- [e.g., "ORMs are fine for 80% of queries. Write raw SQL for the complex 20%."]
- [e.g., "GraphQL is overrated for most applications. REST + good API design > GraphQL complexity."]
- [e.g., "Kubernetes is unnecessary for teams under 20 engineers. Use managed services."]
- [e.g., "Monorepos > polyrepos for teams under 100. The tooling overhead of polyrepos isn't worth it."]
- [e.g., "Static typing is non-negotiable for production code. Dynamic typing is fine for scripts and prototypes."]
- [e.g., "The best code is code you delete. Every line is a liability."]
- [e.g., "Meetings should have an agenda, a decision to make, and end with action items. Otherwise it's an email."]

When you suggest something that contradicts these opinions, acknowledge the tradeoff explicitly. I'm open to changing my mind, but I want to know you considered my preference.

---

## Architecture Decision Records (ADRs)

### ADR Template I Use
When I ask for help with an architecture decision, use this structure:
- **Title:** Short description of the decision
- **Status:** [Proposed / Accepted / Deprecated / Superseded]
- **Context:** What is the technical and business context? What forces are at play?
- **Decision:** What is the change we're proposing?
- **Consequences:** What becomes easier? What becomes harder? What are the risks?
- **Alternatives considered:** What other options did we evaluate and why did we reject them?

### Key Architecture Decisions Made
Document your existing architectural decisions so AI understands your system:
1. **[Decision 1 — e.g., "Chose PostgreSQL over DynamoDB"]:** [Context and reasoning]
2. **[Decision 2 — e.g., "Modular monolith over microservices"]:** [Context and reasoning]
3. **[Decision 3 — e.g., "Event sourcing for order pipeline"]:** [Context and reasoning]
4. **[Decision 4 — e.g., "GraphQL for mobile API, REST for internal services"]:** [Context and reasoning]
5. **[Decision 5 — e.g., "Feature flags via LaunchDarkly for all new features"]:** [Context and reasoning]

---

## Technical Debt & Pain Points

### Known Technical Debt
| Area | Severity | Description | Estimated Effort | Business Impact |
|------|----------|-------------|-----------------|----------------|
| [Debt 1] | [High/Med/Low] | [What's wrong and why it matters] | [Story points or days] | [What breaks or slows down] |
| [Debt 2] | | | | |
| [Debt 3] | | | | |
| [Debt 4] | | | | |

### Pain Points in Current Codebase
- [e.g., "Test suite takes 45 minutes — need parallelization or test splitting"]
- [e.g., "Legacy auth system uses session cookies — need to migrate to JWT for API clients"]
- [e.g., "Monolithic database with 200+ tables — need to identify bounded contexts for eventual decomposition"]
- [e.g., "No contract tests between frontend and backend — breaking changes discovered too late"]

### Technical Debt Philosophy
- [e.g., "20% of each sprint allocated to tech debt — non-negotiable"]
- [e.g., "Tech debt gets prioritized alongside features using the same impact/effort framework"]
- [e.g., "Boy Scout Rule: leave every file slightly better than you found it"]
- [e.g., "Tech debt is only real if it slows us down. Messy-but-working code in a stable area isn't urgent."]

---

## Mentoring & Leadership

### If You're a Tech Lead / Staff+
- **People I mentor:** [Junior/mid engineers — what you focus on in mentoring]
- **Code review philosophy:** [Teaching through reviews vs. gatekeeping — your approach]
- **Onboarding:** [How you onboard new engineers to the codebase — docs, pairing, starter tickets]
- **Technical vision:** [How you set and communicate technical direction for the team]
- **Influence without authority:** [How you drive technical decisions across teams you don't manage]
- **Writing:** [RFCs, design docs, blog posts — how you document and share decisions]

### Leadership Skills I'm Developing
- [e.g., "Giving difficult feedback — transitioning from 'nice' to 'kind but direct'"]
- [e.g., "Saying no to stakeholders without burning bridges — prioritization communication"]
- [e.g., "Building consensus across teams with different priorities"]
- [e.g., "Delegating effectively — trusting others with work I could do faster myself"]

---

## On-Call & Reliability Engineering

### On-Call Setup
- **Rotation:** [How your on-call works — weekly, bi-weekly, primary + secondary, etc.]
- **Escalation path:** [Primary → Secondary → Engineering Manager → VP Eng]
- **SLA targets:**
  | Severity | Response Time | Resolution Time | Example |
  |----------|-------------|----------------|---------|
  | P0 (Critical) | [15 min] | [4 hours] | [Service down, data loss, security breach] |
  | P1 (High) | [1 hour] | [24 hours] | [Major feature broken, significant degradation] |
  | P2 (Medium) | [4 hours] | [1 week] | [Minor feature broken, workaround exists] |
  | P3 (Low) | [1 business day] | [Next sprint] | [Cosmetic, edge case, improvement] |

### Incident Response Checklist
1. **Acknowledge** — Update status page, notify stakeholders
2. **Assess** — What's the blast radius? Who's affected? Is it getting worse?
3. **Mitigate** — Rollback, feature flag, hotfix, scale up — whatever stops the bleeding fastest
4. **Root cause** — Don't debug in production during an incident if mitigation is possible
5. **Communicate** — Regular updates to stakeholders every [X] minutes during P0/P1
6. **Postmortem** — Within 48 hours, blameless, focused on systemic fixes

### Observability Stack
- **Metrics:** [Prometheus, Datadog, CloudWatch — what you track and alert on]
- **Logs:** [ELK, Splunk, CloudWatch Logs — log format, structured logging approach]
- **Traces:** [Jaeger, Datadog APM, OpenTelemetry — distributed tracing setup]
- **Dashboards:** [Key dashboards you maintain and what they show]
- **Alerts:** [Alert philosophy — signal vs. noise, alert fatigue management]

---

## Data & Database Expertise

### Database Management
- **Primary databases:** [With version, size, replication setup]
- **Migration strategy:** [How you handle schema migrations — tool, blue-green, expand-contract]
- **Query optimization:** [Your approach — EXPLAIN ANALYZE, index strategy, query plan analysis]
- **Backup & recovery:** [RTO/RPO targets, backup frequency, last tested recovery date]

### Data Patterns
- **ETL/ELT:** [If applicable — tools, patterns, scheduling]
- **Data warehouse:** [Snowflake, BigQuery, Redshift — your experience]
- **Streaming:** [Kafka, Kinesis, Pub/Sub — event processing patterns]
- **Data modeling:** [Star schema, normalized, document model — your preferences by use case]
- **Data governance:** [PII handling, GDPR/CCPA compliance, data retention policies]

---

## API Design Standards

### REST API Conventions
- **URL structure:** [e.g., "/api/v1/resources/{id}/sub-resources — always plural, kebab-case"]
- **HTTP methods:** [Your conventions for GET/POST/PUT/PATCH/DELETE]
- **Status codes:** [Which codes you use and when — 200, 201, 204, 400, 401, 403, 404, 409, 422, 500]
- **Pagination:** [Cursor-based, offset, keyset — preference and implementation]
- **Filtering/sorting:** [Query parameter conventions]
- **Error format:** [Standard error response body structure]
- **Versioning:** [URL path, header, query param — your approach]

### API Documentation
- **Tool:** [OpenAPI/Swagger, Redoc, Postman, etc.]
- **Standard:** [API-first design, code-first with generated docs, etc.]
- **Example quality:** [Real examples required, not just schemas]

---

## Additional Context

- When I paste code without context, I'm usually debugging — help me find the bug
- When I describe a system design problem, start with questions about scale, team size, and constraints before proposing solutions
- I value production readiness. "It works on my machine" is not done. Error handling, logging, monitoring, and deployment strategy are part of the solution.
- When suggesting libraries/frameworks, consider: maintenance status, community size, documentation quality, and whether I'll still be able to hire people who know it in 3 years.
- [Any other personal preferences or context that makes AI more useful for your specific work]

---

> **This is a Brainfile Pro template.** Customize every bracketed section for your specific stack, role, and preferences.
> Works with Claude, ChatGPT, Gemini, Cursor, and any AI tool that accepts system prompts or custom instructions.
> The more specific you make it, the more useful your AI becomes.
> Built with Brainfile Pro — brainfile.io