Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

c4-docs

Étoiles1

Forks0

Mis à jour3 juillet 2026 à 10:53

Generates or updates C4 architecture documentation as Mermaid diagrams in the host repo (docs/architecture/ by default, or the repo's existing docs location). Produces Level 1 context and Level 2 container diagrams, plus Level 3 components only for the subsystem being changed. Updates existing diagrams in place and flags drift between diagrams and code instead of silently rewriting them.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

ianshank

ianshank/Agents

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

Explorateur de fichiers

2 fichiers

SKILL.md

readonly

name	c4-docs
description	Generates or updates C4 architecture documentation as Mermaid diagrams in the host repo (docs/architecture/ by default, or the repo's existing docs location). Produces Level 1 context and Level 2 container diagrams, plus Level 3 components only for the subsystem being changed. Updates existing diagrams in place and flags drift between diagrams and code instead of silently rewriting them.
when_to_use	Use when the user asks for architecture documentation, C4 or Mermaid diagrams, a system overview, or when a structural change makes existing architecture docs stale. Not for API reference docs, READMEs, or inline code comments.

C4 Architecture Docs (Mermaid)

Produce C4 diagrams as Mermaid in the repository so they render on GitHub without a build step.

Procedure

Locate the docs home. If architecture docs already exist (search for C4Context, C4Container, or docs/architecture), use that location and update in place. Otherwise create docs/architecture/ at the repo root.
Inventory (read-only). Scan the codebase without modifying it: entry points (main functions, servers, CLIs, handlers), top-level modules/packages, external dependencies (databases, queues, third-party APIs), and deployment manifests. Record what each module does and what talks to what, citing the files you derived it from.
Level 1 — System Context. One diagram: the system as a single box, its users (personas), and external systems it depends on. Use Mermaid C4Context syntax.
Level 2 — Containers. One diagram: deployable/runnable units (services, apps, databases, queues) and the protocols between them. Use C4Container syntax. Every container must map to something findable in the repo (a package, service dir, or manifest) — no aspirational boxes.
Level 3 — Components (scoped). Only for the subsystem currently being changed or explicitly requested. Do not diagram every container to Level 3; that decays fastest and costs most to maintain. Use C4Component syntax.
Keep it renderable. Fence every diagram as ```mermaid and stick to Mermaid's C4 syntax (C4Context, C4Container, C4Component, Person, System, Container, Component, Rel, Boundary). Avoid experimental directives that GitHub's renderer rejects. Keep diagrams under ~20 elements; split by boundary if larger.
Update, don't duplicate. When a diagram for the same level and scope exists, edit it. Never create containers-v2.md or a parallel diagram alongside a stale one.
Flag drift. Where the existing diagram and the code disagree, do not silently rewrite the diagram to match either side. List each discrepancy (diagram says X, code at <file> shows Y) in your summary, update the diagram to match the code, and note that the change reflects observed drift — so reviewers can catch cases where the code, not the diagram, is wrong.

Output

New or updated markdown files containing the Mermaid diagrams, plus a short summary: files touched, diagrams added vs. updated, and any drift flagged.

Plus depuis ce dépôt

même dépôt

architecture-drift-guard

ianshank/Agents

Detect and block architecture drift in CI by comparing a codebase's actual Python import graph against a declared C4 component model. Use this whenever the user wants to enforce architecture in CI/CD, fail builds on undocumented dependencies, keep C4/Mermaid diagrams in sync with code, set up architecture tests or fitness functions, prevent layering violations, or guard/lint/gate their architecture — even if they don't name C4 or Mermaid explicitly. Also use it to bootstrap an architecture manifest from an existing repo or to remediate a failing drift check.

2026-07-071

eval-corpus-forge

ianshank/Agents

Build, validate, and package reusable evaluation datasets for agent and LLM systems from prompts, traces, tool-call logs, metadata, and expected outcomes. Use this when the user asks to gather eval data, create benchmark datasets, normalize traces, define reusable ground truth, bootstrap eval suites, or produce retrieval, tool-invocation, response, or end-to-end evaluation artifacts.

2026-07-071

model-bench

ianshank/Agents

Benchmark and A/B-test multiple LLMs or systems-under-test on one evaluation dataset. Use this whenever the user wants to compare models side by side, rank candidates by a score, run a multi-model comparison, set up a persistent A/B eval campaign, decide whether a new model is significantly better than a baseline, or produce a comparative HTML/JSON benchmark report.

2026-07-071

openai-judge

ianshank/Agents

LLM-as-a-judge evaluations over OpenAI-compatible APIs (including NVIDIA Nemotron & LM Studio). Use whenever evaluating output quality, correctness, or scoring responses using standard rubrics.

2026-07-071

code-review

ianshank/Agents

Runs a security and quality review checklist over a diff or named files in an isolated forked subagent. Covers injection, secrets, authz/authn, error handling, resource leaks, concurrency, compatibility, test coverage, and hardcoded config. Returns severity-ranked findings with file:line and a blocking/non-blocking/clean verdict. Read-only - never edits code or proposes inline fixes.

2026-07-031

plan

ianshank/Agents

Instantiates a constraint-programming planning template for a new task, producing a single markdown plan with five sections - objective function, feasible region, permission architecture, feedback loop, and context persistence. All success criteria must be mechanically verifiable (commands, not vibes).

2026-07-031

name	c4-docs
description	Generates or updates C4 architecture documentation as Mermaid diagrams in the host repo (docs/architecture/ by default, or the repo's existing docs location). Produces Level 1 context and Level 2 container diagrams, plus Level 3 components only for the subsystem being changed. Updates existing diagrams in place and flags drift between diagrams and code instead of silently rewriting them.
when_to_use	Use when the user asks for architecture documentation, C4 or Mermaid diagrams, a system overview, or when a structural change makes existing architecture docs stale. Not for API reference docs, READMEs, or inline code comments.

C4 Architecture Docs (Mermaid)

Produce C4 diagrams as Mermaid in the repository so they render on GitHub without a build step.

Procedure

Locate the docs home. If architecture docs already exist (search for C4Context, C4Container, or docs/architecture), use that location and update in place. Otherwise create docs/architecture/ at the repo root.
Inventory (read-only). Scan the codebase without modifying it: entry points (main functions, servers, CLIs, handlers), top-level modules/packages, external dependencies (databases, queues, third-party APIs), and deployment manifests. Record what each module does and what talks to what, citing the files you derived it from.
Level 1 — System Context. One diagram: the system as a single box, its users (personas), and external systems it depends on. Use Mermaid C4Context syntax.
Level 2 — Containers. One diagram: deployable/runnable units (services, apps, databases, queues) and the protocols between them. Use C4Container syntax. Every container must map to something findable in the repo (a package, service dir, or manifest) — no aspirational boxes.
Level 3 — Components (scoped). Only for the subsystem currently being changed or explicitly requested. Do not diagram every container to Level 3; that decays fastest and costs most to maintain. Use C4Component syntax.
Keep it renderable. Fence every diagram as ```mermaid and stick to Mermaid's C4 syntax (C4Context, C4Container, C4Component, Person, System, Container, Component, Rel, Boundary). Avoid experimental directives that GitHub's renderer rejects. Keep diagrams under ~20 elements; split by boundary if larger.
Update, don't duplicate. When a diagram for the same level and scope exists, edit it. Never create containers-v2.md or a parallel diagram alongside a stale one.
Flag drift. Where the existing diagram and the code disagree, do not silently rewrite the diagram to match either side. List each discrepancy (diagram says X, code at <file> shows Y) in your summary, update the diagram to match the code, and note that the change reflects observed drift — so reviewers can catch cases where the code, not the diagram, is wrong.

Output

New or updated markdown files containing the Mermaid diagrams, plus a short summary: files touched, diagrams added vs. updated, and any drift flagged.