From architect
Communication guidelines for non-technical founders. Plain English defaults, analogy-first explanations, progressive disclosure. Use when generating any user-facing architecture output.
npx claudepluginhub navraj007in/architecture-cowork-plugin --plugin architectThis skill uses the workspace's default tool permissions.
Guidelines for communicating architecture decisions to non-technical founders and early-stage teams. These rules apply to all outputs unless the user explicitly requests deep technical language.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Guidelines for communicating architecture decisions to non-technical founders and early-stage teams. These rules apply to all outputs unless the user explicitly requests deep technical language.
Expand every acronym on first use in every deliverable:
After the first expansion, use the acronym freely.
When introducing a concept, use an analogy before the technical definition:
| Concept | Analogy |
|---|---|
| Load balancer | "Like a host at a restaurant — directs customers to available tables" |
| Message queue | "Like a to-do list between two teams — one team adds tasks, the other works through them" |
| Caching | "Like keeping frequently used files on your desk instead of walking to the filing cabinet" |
| WebSocket | "Like a phone call — both sides can talk at any time, unlike email where you send and wait" |
| Vector database | "Like a librarian who understands meaning — finds related documents even if they don't share exact words" |
| API gateway | "Like a reception desk — all visitors check in here before being directed to the right department" |
| Microservices | "Like separate departments in a company — each handles its own job and communicates through email" |
| Container | "Like a shipping container — your app and everything it needs, packed so it runs the same way everywhere" |
| CI/CD pipeline | "Like an assembly line — every code change gets automatically tested and deployed" |
Structure every output following this order:
Never lead with technical implementation details. A founder reading the output should understand the business value in the first 2 sentences.
Use these severity levels consistently:
| Severity | Label | Meaning | Example |
|---|---|---|---|
| Low | "Manageable" | Standard engineering challenge, well-understood solution | "Real-time updates add some complexity but it's a solved problem" |
| Medium | "Significant" | Requires careful planning or specialized expertise | "Multi-tenant data isolation needs to be designed carefully from day one" |
| High | "Potential dealbreaker" | Could fundamentally change scope, timeline, or feasibility | "HIPAA compliance adds 2-3 months and requires specialized infrastructure" |
Always pair a risk with a mitigation: "This is significant because X, but you can manage it by Y."
Start simple. Add detail only when:
If in doubt, keep it simple. A founder who wants more detail will ask.