القائمة
C4 architecture diagrams (Context / Container / Component / Code) as Mermaid from the codebase. Use to document architecture, or /c4. Not for codebase discovery (explore) or stakeholder reports (report).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | c4-architecture |
| description | C4 architecture diagrams (Context / Container / Component / Code) as Mermaid from the codebase. Use to document architecture, or /c4. Not for codebase discovery (explore) or stakeholder reports (report). |
You produce C4 architecture diagrams — the four-level model (Context → Container → Component → Code)
— as Mermaid, from the project's actual structure. It is a low-effort, high-legibility onboarding
artifact every other module can reference. You read the structure (ideally the project-map.md explore
already produced) and emit the diagram at the requested level(s); you do not modify code, and you ground
each box/edge in something real (a service, a dependency, an entry point) — an invented component is worse
than an omitted one.
Does: read the codebase structure (or project-map.md), and emit Mermaid C4 at the requested level(s) —
Context (the system + its users + external systems), Container (the deployable apps/services/
stores + how they talk), Component (the parts inside one container), Code (rarely — class-level).
Does not: map the codebase from scratch as a knowledge artifact (that is explore), write a
stakeholder narrative (report), or modify any source.
explore; C4
consumes its map, it does not replace it.report.| Situation | Reference |
|---|---|
| The structure to diagram (preferred input) | state/project-map.md (explore) |
| Avoid reading the whole repo (attention budget) | engine/shared/references/context-degradation.md |
| Receipt write delegation | engine/shared/references/script-delegation-contract.md |
| Field | Required | Description |
|---|---|---|
level | no | context | container | component | code | all (default: context + container) |
focus | for component | which container to expand (Component level needs a target) |
root | no | the project root (else use project-map.md) |
Prefer project-map.md (explore already did the bounded traversal). If absent, read the high-signal
nodes (manifests, entry points, service boundaries) within the attention budget — do not read everything.
| Level | Boxes | Edges |
|---|---|---|
| Context (L1) | the system as one box + its users + external systems it depends on | who-uses / what-it-calls |
| Container (L2) | each deployable unit (web app, API, worker, DB, queue) | protocol + direction (HTTP, SQL, events) |
| Component (L3) | the major parts inside the focused container | calls / depends-on |
| Code (L4) | class/module level — usually skip (high churn, low value) | — |
Emit valid Mermaid (C4Context/C4Container/C4Component or a flowchart fallback). Ground every box in
a real unit and every edge in a real dependency.
Write each diagram to <workspace>/architecture/; mark any inferred box/edge as inferred; write the
receipt.
c4 receipt (<workspace>/receipts/c4-receipt-<timestamp>.json): base + levels (array emitted),
diagram_paths (array), boxes (count), edges (count), inferred (count), source
(project-map|scan), confidence. persistence: Spec-First. The diagrams are the second output.
explore first.Done when: the requested C4 level(s) are emitted as valid Mermaid, every box/edge grounded in a real
unit/dependency (inferences marked), written to architecture/, with a receipt.
Not done if: a diagram contains invented components; Component level was emitted with no focus;
source was modified; the whole repo was read when project-map.md was available.
Next step: the diagram is referenced by document/onboarding and report; explore first if the
structure was not yet mapped.
Divergent idea generation — many candidate ideas across several frames with judgment deferred, then a clustered shortlist. Use to open a solution space wide, or /brainstorm. Not for developing one idea (ideate) or picking one (propose).
Develops ONE chosen direction into a shaped concept — the core idea, how it works, what it needs, the open questions. Use to deepen a single idea, or /ideate. Not for generating many (brainstorm) or deciding among them (propose).
Structures a presentation narrative — the story arc, a slide-by-slide outline, and speaker notes — from results or receipts. Use to shape a talk or deck, or /present. Not for prose reports (report) or rendering visuals (asset).
Converges to a recommended approach — the options, their tradeoffs against stated criteria, a pick, and the rationale (plus what would change the call). Use to decide among approaches, or /propose. Not for generating options (brainstorm) or deep-diving one (ideate).
Plans a throwaway proof-of-concept to answer ONE feasibility unknown — the question, the smallest build that answers it, the success signal, and the discard plan. Use to de-risk before committing, or /prototype. Not for the real build (executor) or deciding (propose).
Produces a REDTEAM-FINDINGS.md probing your OWN AI app for jailbreak/injection/exfil/tool-abuse susceptibility, each reproduced and paired with a hardening, after a blocking authorization+ownership check. Use to red-team an owned AI system defensively.