What makes edn notable?

2.3K downloads. Trust evidence available

How should edn be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

edn

Use before and after meaningful implementation work to keep a local engineering notebook synchronized with the repository. Captures current vs proposed architecture, component and state ownership, dependencies, system flows, tradeoffs, failure modes, verification evidence, security boundaries, and major technical decisions. Skill: edn Owner: skcache Summary: Use before and after meaningful implementation work to keep a local engineering notebook synchronized with the repository. Captures current vs proposed architecture, component and state ownership, dependencies, system flows, tradeoffs, failure modes, verification evidence, security boundaries, and major technical decisions. Tags: latest:0.1.0 Version history: v0.1.0 | 2026-08-08T03:

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

2.3k

Updated

Oct 9, 2026

Version

0.1.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 2.3K downloads reported by the source. Last updated 10/9/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 9, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 9, 2026
Adoption signal: 2.3K downloadsadoption · observed Oct 9, 2026
Latest release: 0.1.0release · observed Aug 8, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17461z2mx5n1cftjtpx2gf3nd8c28yt:edn

Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/snapshot"

Documentation

CLAWHUB

28,882 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: edn
description: >-
Use before and after meaningful implementation work to keep a local
engineering notebook synchronized with the repository. Captures current
vs proposed architecture, component and state ownership, dependencies,
system flows, tradeoffs, failure modes, verification evidence, security
boundaries, and major technical decisions.
license: MIT
compatibility: Agent Skills compatible coding agents with repository read/write access. Designed for local repository workflows. No external service required.
metadata:
version: "0.3.0"
---

# edn — Engineering Dashboard Notebook

> AI can write the code. You still own the system.

You are the implementation engineer. The repository owner is responsible for product intent, architecture, boundaries, invariants, tradeoffs, risk acceptance, and final technical decisions.

Your job is not merely to complete code changes. Your job is to keep the repository owner's mental model synchronized with the actual codebase so architectural decisions can be made deliberately instead of silently delegated to the agent.

The notebook is documentation and architectural review infrastructure.

It is **not** an interactive implementation dashboard. No buttons such as "implement this" or "approve and run". No controls that execute code from the notebook.

## Resources

This skill is intentionally lean. Load details only when needed:

- `assets/notebook.html` — canonical visual scaffold. Start from it; preserve the visual system unless the user asks otherwise.
- `references/NOTEBOOK-SECTIONS.md` — full section definitions, diagram rules, scaling.
- `references/ARCHITECTURE-CHECK.md` — Architecture Check format, measurement guidance, explanation-level behavior, architectural-change examples.

---

## 1. First activation

On first use in a repository:

1. inspect `.gitignore`
2. add the exact root entry:

```gitignore
/engineering-notebook.html
```

3. if the notebook later splits into a directory, also add:

```gitignore
/engineering-notebook/
```

4. create the notebook from `assets/notebook.html` — do not redesign from scratch
5. never commit the notebook unless the user explicitly requests repository-visible documentation; if they do, explain that the relevant ignore entry must be removed

Do not assume a private repository means the notebook should be committed.

---

## 2. Explanation level: calibrate, never block

Choose one explanation level for the notebook:

```text
Intern · New Grad · Junior · Mid-Level · Senior · Staff · Principal · Distinguished
```

Behavior:

1. if the notebook already stores an explanation level, reuse it
2. if an interactive user is available on first activation, ask for the level
3. if no answer can be obtained without blocking, default to `Junior`
4. continue immediately
5. never block implementation solely waiting for calibration

Store the chosen level only inside the local notebook metadata/comment so future updates remain consistent.

Explanation level chan

README.md

# edn

[![skills.sh](https://skills.sh/b/skcache/edn)](https://skills.sh/skcache/edn)

**Engineering Dashboard Notebook**

AI coding agents can write most of the code now.

The problem is when they also start owning the architecture and you slowly stop knowing why your own system works the way it does.

`edn` keeps a local engineering notebook in sync with your repo so you can actually stay on top of:

- architecture
- components
- dependencies
- data flow
- tradeoffs
- failure modes
- security boundaries
- current vs proposed changes

The notebook lives locally as:

```text
engineering-notebook.html
```

and gets added to `.gitignore` automatically.

## How it works

For normal work, the agent just builds.

If something meaningfully changes the architecture, it shows you the current setup, the proposed change, tradeoffs, evidence, and simpler alternatives before implementing it.

You make the call.

After the task is done, `edn` updates the notebook to match the actual code.

## Learn while you build

On first use, `edn` picks an explanation level: it reuses one already stored in the notebook, asks when an interactive user is around, and otherwise defaults to **Junior** without blocking work.

```text
Intern
New Grad
Junior
Mid-Level
Senior
Staff
Principal
Distinguished
```

Same engineering rigor, just different levels of context.

So if the agent wants to throw Redis into your app, it should explain why it helps **your system**, what extra complexity it adds, and whether you've even measured a bottleneck yet.

## Install

```bash
npx skills add skcache/edn
```

For Codex:

```bash
npx skills add skcache/edn -a codex
```

For Claude Code:

```bash
npx skills add skcache/edn -a claude-code
```

The `skills` CLI supports a bunch of coding agents and installs skills directly from GitHub.

## Update

To update an existing install:

```bash
npx skills update edn
```

`metadata.version` in `SKILL.md` is for human release tracking; the CLI finds updates from the source repo, not this field.

## Use

Inside your repo:

```text
Use the edn skill.
Bootstrap the engineering notebook for this repository.
```

That's it.

The agent can own the typing.

You should still own the system.

## License

MIT

_meta.json

{
  "ownerId": "kn74j906ccqnn8y8r445e03g298c2t2r",
  "slug": "edn",
  "version": "0.1.0",
  "publishedAt": 1786160553796
}

references/ARCHITECTURE-CHECK.md

# ARCHITECTURE-CHECK.md

Deep-dive for architectural decision-making. Load this when the task is classified as an architectural change, when recommending performance/scale/reliability architecture, or when calibrating explanation depth.

## Explanation-level calibration

Level changes **depth and terminology**, not the underlying architecture or technical rigor.

Do not claim the levels map universally to company-specific L3/L4/L5/etc. Engineering ladders vary by organization.

### Intern / New Grad / Junior

- explain unfamiliar infrastructure concepts when they become relevant
- define jargon briefly at first use
- explicitly connect a design choice to the current repository
- show the simplest credible alternative
- use it as a teachable moment, not a lecture
- keep the same technical substance but add context

### Mid-Level / Senior

- assume familiarity with common application architecture
- focus on boundaries, ownership, consistency, latency, operational cost, and failure modes
- explain uncommon or repository-specific concepts
- keep background explanation compact

### Staff / Principal / Distinguished

- optimize for decision density
- emphasize system constraints, second-order effects, interfaces, invariants, operational consequences, and alternatives
- avoid introductory explanations unless requested
- surface uncertainty and evidence directly

## Architectural-change checklist

Run an Architecture Check before coding when the change:

- adds/removes a service or process
- adds a database, cache, queue, or persistent store
- changes source-of-truth ownership
- introduces a new external dependency/API
- changes authentication/authorization boundaries
- changes tenant isolation behavior
- is a meaningful schema redesign
- introduces new async/concurrency behavior
- moves responsibility between major components
- changes a public/internal interface used across subsystem boundaries
- splits or merges major components
- changes deployment/runtime topology
- introduces a new consistency model

Routine work (bug fixes, styling, validation, tests, internal helpers, implementation details behind existing interfaces, small performance cleanup that does not alter topology) proceeds without an Architecture Check.

## Architecture Check format

Keep the check compact enough to be useful.

```md
## Architecture Check

### Requested change
What is being requested.

### Relevant current architecture
Only the part of the system affected.

### Proposed architecture
What would structurally change.

### Why this may help
Concrete benefit tied to a real constraint.

### Costs / tradeoffs
Complexity, consistency, latency, operations, security, coupling, cost, etc.

### Evidence
What measurements, tests, docs, or observed behavior support the change?
If evidence is missing, say so.

### Alternatives
Include the simplest credible alternative.

### Concepts worth knowing
Explain only what is necessary to evaluate this decision, calibrated to the configured eng

references/NOTEBOOK-SECTIONS.md

# NOTEBOOK-SECTIONS.md

Detailed rules for the notebook content and visual system, kept out of `SKILL.md` to keep activation lightweight. Load this when creating or editing notebook sections, diagrams, or deciding how to scale the notebook.

## Learning check

Before writing a section, confirm the notebook already knows:

- the configured explanation level (store: **Intern, New Grad, Junior, Mid-Level, Senior, Staff, Principal, Distinguished**)
- which sections exist and why
- whether this is a compact-repo notebook (fewer sections) or a full notebook

Explanation level changes **depth and terminology**, not rigor. Per-level behavior lives in `ARCHITECTURE-CHECK.md`.

## Section definitions

Keep the core notebook stable. Sections may be omitted when genuinely irrelevant. See `SKILL.md` section 9 (Compact-repo mode) for when to omit.

### A. Project Map

A one-screen map of the major system.

Show:

- clients / entry points
- major components
- persistent stores
- queues / caches
- external systems
- important trust/runtime boundaries

Prefer a diagram plus terse annotations.

### B. System Architecture

Explain:

- major layers
- responsibilities
- dependency direction
- important invariants
- process/runtime boundaries
- architectural style where useful

Do not list every file.

### C. Core Components

For each important component:

```text
Purpose
Owns
Does NOT own
Public interface / entry points
Dependencies
Important state
Failure behavior
```

"Does NOT own" is required when ownership could otherwise be ambiguous.

### D. Key Flows

Document important end-to-end flows.

Each flow should answer:

```text
Where does it enter?
Which components touch it?
Where is state read/written?
What external system is called?
What leaves the system?
Where can it fail?
```

Examples:

- sign in
- create invoice
- execute inference request
- upload file
- generate report

### E. Data / State Ownership

For meaningful state, show:

- owner
- source of truth
- storage location
- mutation path
- read path
- cache relationship if present
- tenant/user boundary if relevant

Pay special attention to authorization and tenant isolation.

### F. Decisions & Tradeoffs

Record only decisions a future engineer may reasonably question.

For each:

```text
Decision
Why
Alternatives considered
What we gain
What we give up
Evidence / assumption
When to revisit
```

Do not create decision-record theater for trivial choices.

### G. Failure Modes / Risks

For important paths:

```text
What can fail?
What does the user/system experience?
How is it detected?
How is it recovered?
What data can be lost, duplicated, delayed, or exposed?
Could a security or tenant boundary be crossed?
```

### H. Current vs Proposed Architecture

Clearly distinguish:

- **Current** — exists in code now
- **Proposed** — planned but not implemented

Use solid visual treatment for current architecture and dashed/dotted visual treatment for proposed architecture<br>
(solid border/edge = current, dashed

Github ReposUpdated 5h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.