Renaissance Architecture
Apply first-principles architecture and UI/UX rules so you design original products instead of “X but for Y” clones before you commit engineering effort.
Overview
Renaissance Architecture is a journey-wide agent skill that applies first-principles software architecture and UI/UX thinking so solo builders create new paradigms instead of derivative commentaries on existing products.
Install
npx skills add https://github.com/bencium/bencium-marketplace --skill renaissance-architectureWhat is this skill?
- Reframes modern tooling as an enabler of new creations, not commentaries on existing products
- Simplicity-as-default table: SQLite→Postgres, monolith→services, single file splits with measurable pain thresholds
- Explicit anti-pattern: extending old workflows with AI instead of asking what becomes newly possible
- Covers feature design, software architecture, brainstorming, design review, and strategy discussions
- Pragmatic HOW guidance paired with first-principles WHAT thinking
Adoption & trust: 1.1k installs on skills.sh; 273 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You keep shipping “another app in a crowded category” because design chats optimize for familiar patterns instead of asking what should exist if you started from scratch.
Who is it for?
Solo builders in early concept, scope, or redesign moments who want principled pushback before locking architecture or UX.
Skip if: Teams that already have an approved spec and only need mechanical coding, or builders who want step-by-step deployment or test checklists without strategic debate.
When should I use this skill?
Designing features, architecting software, brainstorming apps, reviewing designs, or during strategy discussions.
What do I get? / Deliverables
You leave sessions with clearer build-or-skip judgments, simpler default stacks, and design rationale you can fold into validation scope or an implementation plan.
- First-principles problem framing
- Architecture simplicity vs complexity recommendations
- Design review notes distinguishing creation from commentary
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Stress-test whether your AI wrapper invents a new workflow or only annotates an incumbent product.
Choose a minimal SQLite monolith MVP before earning Postgres or service splits.
Split oversized UI modules when responsibilities blur past a maintainable file size.
Review a feature mock for commentator patterns versus a genuinely new interaction model.
Revisit architecture debt only when measured pain justifies added complexity.
How it compares
Use as a design philosophy lens instead of generic “make it like Notion/Linear” feature prompts.
Common Questions / FAQ
Who is renaissance-architecture for?
Indie and solo builders who own product, UX, and technical direction and want an agent to challenge derivative ideas with first-principles architecture.
When should I use renaissance-architecture?
During Idea research when picking a wedge, Validate scope when simplifying an MVP, Build frontend/backend when structuring modules, or Ship review when critiquing whether a UI merely copies incumbents.
Is renaissance-architecture safe to install?
It is advisory prose with no required keys or network calls by default; review the Security Audits panel on this Prism page before installing any marketplace skill.
SKILL.md
READMESKILL.md - Renaissance Architecture
# Renaissance Architecture Build genuinely new things. Not "X but for Y." --- ## Core Philosophy 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:** - First-principles thinking about WHAT to build - Pragmatic choices about HOW to build it - Creating new paradigms, not extending old ones - Using modern tools to make genuinely new things possible --- ## Architecture Principles ### 1. Simplicity as Default, Complexity When Earned **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. --- ### 2. Framework Choices **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?"** --- ### 3. Human-Legible Systems **Configuration** - YAML/JSON are fine - the format isn't the problem - Problem is: 500-line configs with nested conditionals - Good: Config a new team member can read and modify in 10 minutes - Document non-obvious settings inline **Error messages that teach** - What happened - Why it happened - What to do about it - Link to docs if complex **Logs you can understand** - Structured logging (JSON) for machines - Human-readable format for development - Timestamps, context, severity - Searchable without specialized tools **Documentation lives WITH code** - README in each significant directory - API docs generated from code - Architecture decisions recorded (ADRs) - External wikis for onboarding/process only --- ### 4. Local-First Where It Matters **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*