npx claudepluginhub bencium/bencium-marketplace --plugin renaissance-architectureThis skill uses the workspace's default tool permissions.
Build genuinely new things. Not "X but for Y."
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Build genuinely new things. Not "X but for Y."
The problem isn't modern tools. It's building commentaries instead of creations.
Medieval scholars wrote commentaries on Aristotle instead of new philosophy. We build Star Wars spin-offs instead of new sci-fi. We add AI to existing workflows instead of asking what workflows become possible.
Renaissance architecture means:
Start simple, add complexity when pain is measurable.
| Start With | Move To | When |
|---|---|---|
| SQLite | Postgres | >10 concurrent writers, >100GB, need PostGIS/full-text |
| Single file | Multiple files | File exceeds ~500 LOC or has multiple responsibilities |
| Monolith | Services | Team can't work on same codebase, or genuine scale isolation needed |
| Static hosting | Server | Need auth, real-time, or server-side computation |
| Local state | Cloud sync | Multi-device is a real user need, not assumed |
Not dogma, but defaults. Violate with documented reasoning.
Use frameworks when they provide genuine leverage.
| Framework | When to Use | When to Avoid |
|---|---|---|
| Next.js | Full-stack React apps, SSR matters, team knows it | Simple static sites, non-React teams |
| Remix | Data-heavy apps, progressive enhancement priority | Simple SPAs, unfamiliar teams |
| Astro | Content sites, partial hydration valuable | Highly interactive apps |
| SvelteKit | Smaller bundles critical, team willing to learn | Large existing React codebases |
| Rails/Django | Rapid CRUD apps, admin panels, proven patterns | Real-time heavy, team prefers JS |
| FastAPI | Python APIs, async matters | Simple scripts, team prefers other languages |
| Hono/Elysia | Edge functions, lightweight APIs | Complex apps needing full framework |
The question isn't "framework or not" but "does this framework serve the thing we're creating, or are we creating something that serves the framework?"
Configuration
Error messages that teach
Logs you can understand
Documentation lives WITH code
Not "never use cloud" but "don't require cloud unnecessarily."
| Feature | Local-First Approach | Cloud When |
|---|---|---|
| Core functionality | Works offline | Never required for core |
| Data storage | SQLite/local storage | Sync, backup, multi-device |
| Computation | Client-side where possible | Heavy processing, shared resources |
| Auth | Local sessions work | OAuth for third-party, enterprise SSO |
State should be inspectable
Sync as enhancement
Libraries over frameworks when:
Frameworks over libraries when:
APIs expose primitives
Minimize exit costs
| Use Case | Cloud Appropriate | Local/Edge Better |
|---|---|---|
| Auth | Enterprise SSO, OAuth providers | Simple username/password |
| Storage | Multi-device sync, collaboration | Single-user, offline-capable |
| Compute | Heavy ML inference, video processing | Text processing, simple transforms |
| Database | Multi-writer, global distribution | Single user, local-first |
| Real-time | Multi-user collaboration | Single-user state |
The question: Does cloud serve your users, or does it serve your assumptions about scale you don't have?
<100ms for user actions, honest progress for longer operations
Loading states should:
User always knows what the system is doing
No black boxes
Things stay where you put them
Predictable navigation
Implemented at the data layer, not just UI
Destructive actions
Notifications
Modals & Interruptions
Autoplay
Defaults over customization
First-Principles Check
Simplicity Check
Tool Fitness Check
Human-Legibility Check
UI/UX Check
Start by asking:
Default to:
Add complexity when:
When to upgrade from defaults:
| From | To | Trigger |
|---|---|---|
| SQLite | Postgres | >10 concurrent writers OR >100GB data OR need PostGIS/full-text search |
| Monolith | Services | Team can't work on same codebase OR genuine scale isolation needed |
| Static | Server | Need auth, real-time, or server-side computation |
| Local storage | Cloud sync | Multi-device is validated user need, not assumption |
| Library | Framework | Team expertise exists AND time-to-market critical AND framework opinions align |
| Simple | Complex | Pain is measurable, not theoretical |
Complexity is acceptable when:
Document the reasoning. Future you will thank present you.
Start simple, add complexity when pain is measurable.
Premature complexity is technical debt with interest.
These are defaults, not laws. Violate with documented reasoning.
Every principle here has valid exceptions. The goal isn't purity - it's intentionality.
Valid reasons to deviate:
Invalid reasons to deviate:
When you deviate, write down why. One sentence in a comment, ADR, or README.
| Dimension | Default | Upgrade When |
|---|---|---|
| Storage | SQLite | Concurrent writes, scale, features |
| Framework | Yes, if team knows it | Build from scratch if simpler |
| Cloud | Where genuinely needed | Don't assume, validate |
| Config | YAML/JSON, well-documented | - |
| Errors | Teaching messages | - |
| Loading | Spinners with honest progress | - |
| State | Visible, inspectable | - |
| Undo | Data-layer versioning | - |
| Complexity | Earned, not assumed | Document reasoning |
When designing anything, ask:
"Am I creating something new, or commenting on something that exists?"
Renaissance architecture isn't about rejecting modern tools. It's about using them to build genuinely new things - not just another variation on established patterns.
Medieval scholars could only write commentaries because they believed truth was revealed in the past. We have no such limitation. We can create.