القائمة
Communication guidelines for non-technical founders. Plain English defaults, analogy-first explanations, progressive disclosure. Use when generating any user-facing architecture output.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Structured web research methodology for market analysis, competitor research, and technology evaluation. Ensures research uses live web data with source citations and confidence tags.
Mermaid diagram templates for solution architecture, service communication, C4 Context/Container, data flow, agent flow, deployment, and sequence diagrams. Use when generating architecture diagrams.
Solution Design Language (SDL) specification — schema, validation, normalization, and generation rules
Core methodology for analysing requirements, building system manifests, and generating architecture deliverables. Use when planning or designing any software architecture.
Extract and render all Mermaid diagrams from architecture blueprints to PNG images. Creates a diagrams/ folder with high-quality images ready for presentations and documentation.
Convert architecture documents (blueprints, stakeholder presentations) from Markdown to professionally formatted Word (.docx) files. Applies corporate styling, embeds PNG diagrams, and creates presentation-ready documents.
| name | founder-communication |
| description | Communication guidelines for non-technical founders. Plain English defaults, analogy-first explanations, progressive disclosure. Use when generating any user-facing architecture output. |
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.
