{"id":"a9e24e40-1746-47d6-977a-f15f94c4078a","entityType":"agent","slug":"clawhub-skcache-edn","name":"edn","canonicalUrl":"https://www.xpersona.co/agent/clawhub-skcache-edn","canonicalPath":"/agent/clawhub-skcache-edn","generatedAt":"2026-10-10T00:54:51.381Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T16:33:02.738Z","emptyReason":null},"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. 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:","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 2.3K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17461z2mx5n1cftjtpx2gf3nd8c28yt:edn","sourceUrl":"https://clawhub.ai/skcache/edn","homepage":"https://clawhub.ai/skcache/skills/edn","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/skcache/edn","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/skcache/skills/edn","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":67,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Use before and after meaningful implementation work to keep a local engineering notebook synchronized with the repository. Captures current vs proposed architec"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T16:33:02.738Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T16:33:02.738Z","emptyReason":null},"stars":null,"forks":null,"downloads":2303,"packageName":null,"latestVersion":"0.1.0","tractionLabel":"2.3K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T16:33:02.738Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T16:33:02.738Z","lastCrawledAt":"2026-10-09T16:33:02.738Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T16:33:02.738Z","lastVerifiedAt":null,"highlights":[{"version":"0.1.0","createdAt":"2026-08-08T03:42:33.796Z","changelog":"- Initial release of edn, the Engineering Dashboard Notebook skill. - Synchronizes a local engineering notebook with repository changes to document and review architecture, ownership, flows, dependencies, tradeoffs, risks, decisions, and evidence. - Automatically manages creation and `.gitignore` rules for the notebook on first activation; avoids committing private notes unless explicitly requested. - Guides users to classify work as routine or architectural, prompting for Architecture Checks and owner input when necessary. - Enforces security and ownership checkpoints for changes affecting sensitive areas. - Supports explanation depth calibration for notebook updates, adapting technical language for different experience levels.","fileCount":10,"zipByteSize":22121}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17461z2mx5n1cftjtpx2gf3nd8c28yt:edn","setupComplexity":"low","setupSteps":["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":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T00:54:51.380Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-skcache-edn/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T16:33:02.738Z","emptyReason":null},"readme":"Skill: edn\n\nOwner: skcache\n\nSummary: 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.\n\nTags: latest:0.1.0\n\nVersion history:\n\nv0.1.0 | 2026-08-08T03:42:33.796Z | auto\n\n- Initial release of edn, the Engineering Dashboard Notebook skill.\n- Synchronizes a local engineering notebook with repository changes to document and review architecture, ownership, flows, dependencies, tradeoffs, risks, decisions, and evidence.\n- Automatically manages creation and `.gitignore` rules for the notebook on first activation; avoids committing private notes unless explicitly requested.\n- Guides users to classify work as routine or architectural, prompting for Architecture Checks and owner input when necessary.\n- Enforces security and ownership checkpoints for changes affecting sensitive areas.\n- Supports explanation depth calibration for notebook updates, adapting technical language for different experience levels.\n\nArchive index:\n\nArchive v0.1.0: 10 files, 22121 bytes\n\nFiles: assets (0b), assets/notebook.html (29961b), LICENSE (1059b), README.md (2230b), references (0b), references/ARCHITECTURE-CHECK.md (5577b), references/NOTEBOOK-SECTIONS.md (6441b), skill-card.md (2393b), SKILL.md (9419b), _meta.json (122b)\n\nFile v0.1.0:SKILL.md\n\n---\nname: edn\ndescription: >-\n  Use before and after meaningful implementation work to keep a local\n  engineering notebook synchronized with the repository. Captures current\n  vs proposed architecture, component and state ownership, dependencies,\n  system flows, tradeoffs, failure modes, verification evidence, security\n  boundaries, and major technical decisions.\nlicense: MIT\ncompatibility: Agent Skills compatible coding agents with repository read/write access. Designed for local repository workflows. No external service required.\nmetadata:\n  version: \"0.3.0\"\n---\n\n# edn — Engineering Dashboard Notebook\n\n> AI can write the code. You still own the system.\n\nYou are the implementation engineer. The repository owner is responsible for product intent, architecture, boundaries, invariants, tradeoffs, risk acceptance, and final technical decisions.\n\nYour 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.\n\nThe notebook is documentation and architectural review infrastructure.\n\nIt is **not** an interactive implementation dashboard. No buttons such as \"implement this\" or \"approve and run\". No controls that execute code from the notebook.\n\n## Resources\n\nThis skill is intentionally lean. Load details only when needed:\n\n- `assets/notebook.html` — canonical visual scaffold. Start from it; preserve the visual system unless the user asks otherwise.\n- `references/NOTEBOOK-SECTIONS.md` — full section definitions, diagram rules, scaling.\n- `references/ARCHITECTURE-CHECK.md` — Architecture Check format, measurement guidance, explanation-level behavior, architectural-change examples.\n\n---\n\n## 1. First activation\n\nOn first use in a repository:\n\n1. inspect `.gitignore`\n2. add the exact root entry:\n\n```gitignore\n/engineering-notebook.html\n```\n\n3. if the notebook later splits into a directory, also add:\n\n```gitignore\n/engineering-notebook/\n```\n\n4. create the notebook from `assets/notebook.html` — do not redesign from scratch\n5. never commit the notebook unless the user explicitly requests repository-visible documentation; if they do, explain that the relevant ignore entry must be removed\n\nDo not assume a private repository means the notebook should be committed.\n\n---\n\n## 2. Explanation level: calibrate, never block\n\nChoose one explanation level for the notebook:\n\n```text\nIntern · New Grad · Junior · Mid-Level · Senior · Staff · Principal · Distinguished\n```\n\nBehavior:\n\n1. if the notebook already stores an explanation level, reuse it\n2. if an interactive user is available on first activation, ask for the level\n3. if no answer can be obtained without blocking, default to `Junior`\n4. continue immediately\n5. never block implementation solely waiting for calibration\n\nStore the chosen level only inside the local notebook metadata/comment so future updates remain consistent.\n\nExplanation level changes **depth and terminology**, not the underlying architecture or technical rigor. Full per-level behavior: `references/ARCHITECTURE-CHECK.md`.\n\n---\n\n## 3. Core operating loop\n\nDo not replace architectural judgment with documentation generated after the fact.\n\n```text\nGOAL\n  ↓\nUNDERSTAND CURRENT SYSTEM\n  ↓\nSHOW ARCHITECTURAL CONSEQUENCES WHEN MATERIAL\n  ↓\nOWNER DIRECTION\n  ↓\nIMPLEMENT\n  ↓\nVERIFY WITH EVIDENCE\n  ↓\nUPDATE NOTEBOOK TO MATCH REALITY\n```\n\nRoutine work must not be slowed by unnecessary approval gates.\n\nArchitectural work must not be implemented behind the user's back and merely documented afterward.\n\n---\n\n## 4. Classify the task\n\nBefore meaningful work, read the notebook if present and classify:\n\n```text\nROUTINE IMPLEMENTATION\nor\nARCHITECTURAL CHANGE\n```\n\n### Routine implementation\n\nExamples:\n\n- bug fix within existing ownership\n- styling\n- validation\n- test coverage\n- internal helper\n- implementation detail behind an existing interface\n- small performance cleanup that does not alter system topology\n\nProceed without architecture approval.\n\n### Architectural change\n\nExamples:\n\n- adding/removing a service or process\n- adding a database, cache, queue, or persistent store\n- changing source-of-truth ownership\n- introducing a new external dependency/API\n- changing authentication/authorization boundaries\n- changing tenant isolation behavior\n- meaningful schema redesign\n- introducing new async/concurrency behavior\n- moving responsibility between major components\n- changing a public/internal interface used across subsystem boundaries\n- splitting or merging major components\n- changing deployment/runtime topology\n- introducing a new consistency model\n\nRun an Architecture Check before coding.\n\n---\n\n## 5. Evidence before complexity\n\nBefore recommending architecture primarily for performance, scale, or reliability:\n\n1. identify the claimed bottleneck/risk\n2. check whether evidence exists\n3. measure when reasonably possible\n4. compare the simplest viable approaches\n5. prefer the least complex architecture that satisfies the requirement\n\nRecord how important architectural claims were validated — tests, benchmarks, profiling, traces, reproducible commands — over tutorial convention, \"best practice\" without context, infrastructure fashion, or unmeasured assumptions.\n\nExample:\n\n```text\nClaim:    Database reads are the current bottleneck.\nEvidence: p95 endpoint = 420 ms; SQL = 310 ms avg across 50 local requests.\nDecision: Index/query work is justified before introducing a cache.\n```\n\nCache / queue / microservice guidance: `references/ARCHITECTURE-CHECK.md`.\n\n---\n\n## 6. Security and tenant checkpoint\n\nWhen a change touches:\n\n- authentication\n- authorization\n- tenant/user-scoped data\n- shared caches\n- database queries\n- object ownership\n- background jobs acting on user data\n- admin/user privilege separation\n\nexplicitly answer:\n\n```text\nWho is allowed to access this?\nWhere is that enforced?\nWhat identifier scopes the data?\nWhat is the source of truth for ownership?\nCould one tenant/user read or mutate another's data?\nWhat tests prove isolation?\n```\n\nNever rely on frontend filtering as an authorization boundary.\n\nIf scope/ownership is unclear, stop before implementation.\n\n---\n\n## 7. Before implementation\n\nFor every meaningful task:\n\n1. read `engineering-notebook.html` if present\n2. inspect relevant code\n3. identify affected components, dependencies, state, flows, interfaces, and boundaries\n4. inspect existing measurements/tests where relevant\n5. classify the task (section 4)\n\nIf architectural, run the Architecture Check and get owner direction before coding.\n\n---\n\n## 8. After implementation\n\n### A. Normal engineering report\n\nState:\n\n- what changed\n- affected modules\n- tests/checks run\n- benchmarks/measurements if relevant\n- what remains\n\n### B. Update the notebook\n\nUpdate only affected sections:\n\n- new component → Project Map + Core Components\n- changed request path → Key Flows\n- new meaningful dependency → Dependencies & External Contracts\n- performance-motivated change → Verification & Evidence\n- new cache → Project Map + State Ownership + Dependencies + Tradeoffs + Failure Modes\n- authorization fix → State Ownership + Failure/Risk + Recent Changes\n- unchanged-interface refactor → often only Recent Changes, or no update if system understanding did not change\n\n### C. Short engineering review\n\nEnd meaningful tasks with:\n\n```md\n## Engineering Notebook Review\n\n### System-level change\n...\n\n### Key concepts / implications\n- ...\n\n### Tradeoff introduced or removed\n...\n\n### Evidence / verification\n...\n\n### Open architectural decision\nNone / ...\n```\n\nCalibrate wording to the configured engineering level.\n\n---\n\n## 9. Compact-repo mode\n\nIf the repository is small, single-process, or has few meaningful architectural boundaries, keep the notebook compact.\n\nPrefer only sections that contain useful information, typically:\n\n- Project Map\n- Core Components\n- Key Flows\n- Dependencies\n- Verification\n\nDo not create empty or repetitive sections merely to satisfy the full schema.\n\nExpand only as actual architectural complexity appears. There is no arbitrary component-count threshold.\n\n---\n\n## 10. Notebook rules\n\n- the notebook is documentation, not an execution/control dashboard\n- no SaaS, backend, telemetry, or API requirement\n- never fabricate historical rationale — use `Rationale: Not established from repository evidence.` when unknown\n- current vs proposed architecture must be visually distinct (solid = current, dashed/dotted = proposed)\n- never present a proposal as implemented reality\n- the notebook is healthy when the repository owner can answer — without reading thousands of generated lines — what the major components are, what each owns, the meaningful dependencies, how key flows work, where important state lives, the security/tenant boundaries, the accepted tradeoffs, the failure modes, the evidence behind important choices, what changed structurally in the last feature, what is proposed but unbuilt, and what decision comes next\n\n---\n\n## 11. Final rule\n\nThe agent may own implementation throughput.\n\nThe repository owner owns:\n\n- product intent\n- architecture\n- boundaries\n- invariants\n- interfaces\n- tradeoffs\n- risk acceptance\n- final technical decisions\n\nNever confuse:\n\n```text\nthe agent can implement this\n```\n\nwith:\n\n```text\nthe system should be designed this way\n```\n\nFile v0.1.0:README.md\n\n# edn\n\n[![skills.sh](https://skills.sh/b/skcache/edn)](https://skills.sh/skcache/edn)\n\n**Engineering Dashboard Notebook**\n\nAI coding agents can write most of the code now.\n\nThe problem is when they also start owning the architecture and you slowly stop knowing why your own system works the way it does.\n\n`edn` keeps a local engineering notebook in sync with your repo so you can actually stay on top of:\n\n- architecture\n- components\n- dependencies\n- data flow\n- tradeoffs\n- failure modes\n- security boundaries\n- current vs proposed changes\n\nThe notebook lives locally as:\n\n```text\nengineering-notebook.html\n```\n\nand gets added to `.gitignore` automatically.\n\n## How it works\n\nFor normal work, the agent just builds.\n\nIf something meaningfully changes the architecture, it shows you the current setup, the proposed change, tradeoffs, evidence, and simpler alternatives before implementing it.\n\nYou make the call.\n\nAfter the task is done, `edn` updates the notebook to match the actual code.\n\n## Learn while you build\n\nOn 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.\n\n```text\nIntern\nNew Grad\nJunior\nMid-Level\nSenior\nStaff\nPrincipal\nDistinguished\n```\n\nSame engineering rigor, just different levels of context.\n\nSo 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.\n\n## Install\n\n```bash\nnpx skills add skcache/edn\n```\n\nFor Codex:\n\n```bash\nnpx skills add skcache/edn -a codex\n```\n\nFor Claude Code:\n\n```bash\nnpx skills add skcache/edn -a claude-code\n```\n\nThe `skills` CLI supports a bunch of coding agents and installs skills directly from GitHub.\n\n## Update\n\nTo update an existing install:\n\n```bash\nnpx skills update edn\n```\n\n`metadata.version` in `SKILL.md` is for human release tracking; the CLI finds updates from the source repo, not this field.\n\n## Use\n\nInside your repo:\n\n```text\nUse the edn skill.\nBootstrap the engineering notebook for this repository.\n```\n\nThat's it.\n\nThe agent can own the typing.\n\nYou should still own the system.\n\n## License\n\nMIT\n\nFile v0.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn74j906ccqnn8y8r445e03g298c2t2r\",\n  \"slug\": \"edn\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1786160553796\n}\n\nFile v0.1.0:references/ARCHITECTURE-CHECK.md\n\n# ARCHITECTURE-CHECK.md\n\nDeep-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.\n\n## Explanation-level calibration\n\nLevel changes **depth and terminology**, not the underlying architecture or technical rigor.\n\nDo not claim the levels map universally to company-specific L3/L4/L5/etc. Engineering ladders vary by organization.\n\n### Intern / New Grad / Junior\n\n- explain unfamiliar infrastructure concepts when they become relevant\n- define jargon briefly at first use\n- explicitly connect a design choice to the current repository\n- show the simplest credible alternative\n- use it as a teachable moment, not a lecture\n- keep the same technical substance but add context\n\n### Mid-Level / Senior\n\n- assume familiarity with common application architecture\n- focus on boundaries, ownership, consistency, latency, operational cost, and failure modes\n- explain uncommon or repository-specific concepts\n- keep background explanation compact\n\n### Staff / Principal / Distinguished\n\n- optimize for decision density\n- emphasize system constraints, second-order effects, interfaces, invariants, operational consequences, and alternatives\n- avoid introductory explanations unless requested\n- surface uncertainty and evidence directly\n\n## Architectural-change checklist\n\nRun an Architecture Check before coding when the change:\n\n- adds/removes a service or process\n- adds a database, cache, queue, or persistent store\n- changes source-of-truth ownership\n- introduces a new external dependency/API\n- changes authentication/authorization boundaries\n- changes tenant isolation behavior\n- is a meaningful schema redesign\n- introduces new async/concurrency behavior\n- moves responsibility between major components\n- changes a public/internal interface used across subsystem boundaries\n- splits or merges major components\n- changes deployment/runtime topology\n- introduces a new consistency model\n\nRoutine 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.\n\n## Architecture Check format\n\nKeep the check compact enough to be useful.\n\n```md\n## Architecture Check\n\n### Requested change\nWhat is being requested.\n\n### Relevant current architecture\nOnly the part of the system affected.\n\n### Proposed architecture\nWhat would structurally change.\n\n### Why this may help\nConcrete benefit tied to a real constraint.\n\n### Costs / tradeoffs\nComplexity, consistency, latency, operations, security, coupling, cost, etc.\n\n### Evidence\nWhat measurements, tests, docs, or observed behavior support the change?\nIf evidence is missing, say so.\n\n### Alternatives\nInclude the simplest credible alternative.\n\n### Concepts worth knowing\nExplain only what is necessary to evaluate this decision, calibrated to the configured engineering level.\n\n### Recommendation\nGive a recommendation with assumptions and uncertainty made explicit.\n\n### Decision\nState the smallest decision the repository owner needs to make.\n```\n\nDo not use vague wording such as \"what the human needs to understand.\" The notebook and the check are written for the repository owner/engineer.\n\nIf a concept is unfamiliar:\n\n- name it\n- explain the problem it solves\n- explain the problems it introduces\n- relate it to this repository\n- cite or point to official documentation when research tools are available\n- do not substitute senior-sounding jargon for reasoning\n\n## Measurement before complexity\n\nBefore recommending architecture primarily for performance, scale, or reliability:\n\n1. identify the claimed bottleneck/risk\n2. check whether it is worth measuring\n3. measure when reasonably possible\n4. prefer the least complex approach satisfying the requirement\n5. record the evidence in the Verification & Evidence section\n\n### Cache example (Redis)\n\nDo not recommend Redis merely because reads exist.\n\nFirst route through the questions above:\n\n- are reads actually slow?\n- is the database the bottleneck?\n- would indexing/query changes solve it?\n- what staleness is acceptable?\n- what invalidates the cache?\n\nThen the check might read:\n\n```md\nRedis would sit between ProductService and PostgreSQL.\n\nPotential benefit:\nRepeated reads can avoid the database.\n\nNew complexity:\nCached data can become stale, invalidation logic is required, and Redis\nbecomes another runtime dependency.\n\nEvidence status:\nWe have not yet shown that PostgreSQL reads are the bottleneck.\n\nSimpler alternative:\nMeasure the query and inspect indexing before adding a cache.\n```\n\n### Other burden\n\nDo not introduce a queue merely because work is asynchronous.\n\nFirst ask:\n\n- is request latency unacceptable?\n- does work need retries?\n- does it need durable execution?\n- can an in-process/background mechanism satisfy the current requirement?\n\nDo not split a service because the repository is large or a diagram looks messy.\n\nRequire a real boundary or operational need.\n\n## Evidence-first rule\n\nPrefer, as evidence for an important choice:\n\n- tests\n- benchmarks\n- profiling\n- measurements\n- production/local traces\n- official documentation\n- reproducible commands\n\nOver:\n\n- tutorial convention\n- \"best practice\" without context\n- infrastructure fashion\n- unmeasured performance assumptions\n\nRecord how important claims were validated. Never fabricate historical rationale — when unknown, write:\n\n```text\nRationale: Not established from current evidence.\n```\n\nFile v0.1.0:references/NOTEBOOK-SECTIONS.md\n\n# NOTEBOOK-SECTIONS.md\n\nDetailed 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.\n\n## Learning check\n\nBefore writing a section, confirm the notebook already knows:\n\n- the configured explanation level (store: **Intern, New Grad, Junior, Mid-Level, Senior, Staff, Principal, Distinguished**)\n- which sections exist and why\n- whether this is a compact-repo notebook (fewer sections) or a full notebook\n\nExplanation level changes **depth and terminology**, not rigor. Per-level behavior lives in `ARCHITECTURE-CHECK.md`.\n\n## Section definitions\n\nKeep the core notebook stable. Sections may be omitted when genuinely irrelevant. See `SKILL.md` section 9 (Compact-repo mode) for when to omit.\n\n### A. Project Map\n\nA one-screen map of the major system.\n\nShow:\n\n- clients / entry points\n- major components\n- persistent stores\n- queues / caches\n- external systems\n- important trust/runtime boundaries\n\nPrefer a diagram plus terse annotations.\n\n### B. System Architecture\n\nExplain:\n\n- major layers\n- responsibilities\n- dependency direction\n- important invariants\n- process/runtime boundaries\n- architectural style where useful\n\nDo not list every file.\n\n### C. Core Components\n\nFor each important component:\n\n```text\nPurpose\nOwns\nDoes NOT own\nPublic interface / entry points\nDependencies\nImportant state\nFailure behavior\n```\n\n\"Does NOT own\" is required when ownership could otherwise be ambiguous.\n\n### D. Key Flows\n\nDocument important end-to-end flows.\n\nEach flow should answer:\n\n```text\nWhere does it enter?\nWhich components touch it?\nWhere is state read/written?\nWhat external system is called?\nWhat leaves the system?\nWhere can it fail?\n```\n\nExamples:\n\n- sign in\n- create invoice\n- execute inference request\n- upload file\n- generate report\n\n### E. Data / State Ownership\n\nFor meaningful state, show:\n\n- owner\n- source of truth\n- storage location\n- mutation path\n- read path\n- cache relationship if present\n- tenant/user boundary if relevant\n\nPay special attention to authorization and tenant isolation.\n\n### F. Decisions & Tradeoffs\n\nRecord only decisions a future engineer may reasonably question.\n\nFor each:\n\n```text\nDecision\nWhy\nAlternatives considered\nWhat we gain\nWhat we give up\nEvidence / assumption\nWhen to revisit\n```\n\nDo not create decision-record theater for trivial choices.\n\n### G. Failure Modes / Risks\n\nFor important paths:\n\n```text\nWhat can fail?\nWhat does the user/system experience?\nHow is it detected?\nHow is it recovered?\nWhat data can be lost, duplicated, delayed, or exposed?\nCould a security or tenant boundary be crossed?\n```\n\n### H. Current vs Proposed Architecture\n\nClearly distinguish:\n\n- **Current** — exists in code now\n- **Proposed** — planned but not implemented\n\nUse solid visual treatment for current architecture and dashed/dotted visual treatment for proposed architecture<br>\n(solid border/edge = current, dashed/dotted border/edge = proposed).\n\nNever present a proposed architecture as implemented reality.\n\n### I. Recent Architectural Changes\n\nMaintain a short reverse-chronological feed:\n\n```text\nDate / task\nWhat changed structurally\nWhy\nAffected components / flows\nNew tradeoff, risk, or dependency\n```\n\nDo not duplicate raw git history.\n\n### J. Dependencies & External Contracts\n\nTrack dependencies that materially affect how the system works.\n\nInclude only meaningful dependencies, not every npm/pip package.\n\nFor each relevant dependency:\n\n```text\nDependency / service\nWhy it exists\nWhere it is used\nWhat contract we rely on\nFailure / timeout behavior\nVersion or compatibility constraint if important\nReplacement / fallback considerations if relevant\n```\n\nExamples:\n\n- PostgreSQL\n- Redis\n- Stripe\n- S3\n- model runtime\n- message broker\n- external identity provider\n- public/internal API consumed across subsystem boundaries\n\nAlso document important internal contracts:\n\n- API shapes\n- events/messages\n- data schemas\n- interface invariants\n\n### K. Verification & Evidence\n\nRecord how important architectural claims were validated.\n\nPrefer:\n\n- tests\n- benchmarks\n- profiling\n- measurements\n- production/local traces\n- official documentation\n- reproducible commands\n\nOver:\n\n- tutorial convention\n- \"best practice\" without context\n- infrastructure fashion\n- unmeasured performance assumptions\n\nExample:\n\n```text\nClaim:\nDatabase reads are the current bottleneck.\n\nEvidence:\nP95 endpoint = 420 ms\nSQL query = 310 ms average across 50 local test requests\n\nDecision:\nIndex/query work is justified before introducing a cache.\n```\n\nDo not fill this section with routine unit-test noise. Capture evidence that affects engineering decisions.\n\n## Diagrams and readability\n\nBefore saving an updated notebook, inspect each diagram for:\n\n- dimensional fit\n- text clipping\n- overlap\n- edge crossings\n- label readability\n- consistent alignment\n- clean visual hierarchy\n- browser resizing\n- current/proposed distinction\n- unnecessary decorative elements\n\nIf a diagram is unreadable at normal laptop width, fix it.\n\nDo not assume the first generated diagram is acceptable.\n\nPrefer simple system diagrams that communicate ownership and flow over decorative complexity.\n\n## Scaling to larger repositories\n\nDefault single file:\n\n```text\nengineering-notebook.html\n```\n\nFor genuinely large repositories, it may become a bookmark index linking to:\n\n```text\nengineering-notebook/\n  auth.html\n  billing.html\n  inference.html\n```\n\nSplit only when the single notebook becomes meaningfully difficult to navigate.\n\n## Existing vs new repositories\n\n### Existing repositories\n\nWhen bootstrapping:\n\n1. inspect repository structure\n2. identify runtime entry points\n3. identify meaningful dependencies\n4. identify persistent stores\n5. identify major components\n6. trace 2–5 important flows\n7. inspect state ownership\n8. inspect auth/tenant boundaries where present\n9. inspect tests and available measurements\n10. create the notebook\n11. mark unknown rationale/uncertain architecture explicitly\n\nNever invent historical rationale. Use:\n\n```text\nRationale: Not established from repository evidence.\n```\n\nwhen necessary.\n\n### New repositories\n\nFor new projects:\n\n1. create a minimal notebook from agreed architecture\n2. mark unbuilt components as proposed\n3. keep current architecture limited to real code\n4. update after meaningful tasks\n5. use evidence as implementation matures\n\nFile v0.1.0:skill-card.md\n\n## Description:\n\nKeeps a local engineering notebook synchronized with a repository so agents can document architecture, ownership, flows, dependencies, tradeoffs, risks, decisions, and verification evidence before and after meaningful implementation work.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[skcache](https://clawhub.ai/user/skcache)\n\n### License/Terms of Use:\n\nMIT\n\n## Use Case:\n\nDevelopers and engineers use edn with compatible coding agents to maintain a local engineering notebook that keeps repository architecture, security boundaries, tradeoffs, and implementation evidence visible while work progresses.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Install and update examples use unpinned npx skills commands, so the resolved CLI version can change over time.\n\nMitigation: Review or pin the skills CLI version before installing or updating the skill.\n\nRisk: The skill is expected to read the repository and write a local engineering-notebook.html file plus .gitignore entries.\n\nMitigation: Install it only in repositories where local architecture documentation is acceptable, and review generated notebook content before sharing or committing it.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/skcache/skills/edn)\n- [Server-Resolved Source Repository](https://github.com/skcache/edn)\n- [skills.sh Package Page](https://skills.sh/skcache/edn)\n- [ARCHITECTURE-CHECK.md](references/ARCHITECTURE-CHECK.md)\n- [NOTEBOOK-SECTIONS.md](references/NOTEBOOK-SECTIONS.md)\n- [notebook.html Scaffold](assets/notebook.html)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown guidance with inline code blocks plus local HTML notebook and configuration file updates]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Creates or updates a local engineering-notebook.html file and .gitignore entries; no external service is required by the skill.]\n\n## Skill Version(s):\n\n0.1.0 (source: server release metadata; skill frontmatter reports 0.3.0)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v0.1.0:LICENSE\n\nMIT License\n\nCopyright (c) 2026 SK\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.","readmeExcerpt":"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:","codeSnippets":[],"executableExamples":[{"language":"gitignore","snippet":"/engineering-notebook.html"},{"language":"gitignore","snippet":"/engineering-notebook/"},{"language":"text","snippet":"Intern · New Grad · Junior · Mid-Level · Senior · Staff · Principal · Distinguished"},{"language":"text","snippet":"GOAL\n  ↓\nUNDERSTAND CURRENT SYSTEM\n  ↓\nSHOW ARCHITECTURAL CONSEQUENCES WHEN MATERIAL\n  ↓\nOWNER DIRECTION\n  ↓\nIMPLEMENT\n  ↓\nVERIFY WITH EVIDENCE\n  ↓\nUPDATE NOTEBOOK TO MATCH REALITY"},{"language":"text","snippet":"ROUTINE IMPLEMENTATION\nor\nARCHITECTURAL CHANGE"},{"language":"text","snippet":"Claim:    Database reads are the current bottleneck.\nEvidence: p95 endpoint = 420 ms; SQL = 310 ms avg across 50 local requests.\nDecision: Index/query work is justified before introducing a cache."}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: edn\ndescription: >-\n  Use before and after meaningful implementation work to keep a local\n  engineering notebook synchronized with the repository. Captures current\n  vs proposed architecture, component and state ownership, dependencies,\n  system flows, tradeoffs, failure modes, verification evidence, security\n  boundaries, and major technical decisions.\nlicense: MIT\ncompatibility: Agent Skills compatible coding agents with repository read/write access. Designed for local repository workflows. No external service required.\nmetadata:\n  version: \"0.3.0\"\n---\n\n# edn — Engineering Dashboard Notebook\n\n> AI can write the code. You still own the system.\n\nYou are the implementation engineer. The repository owner is responsible for product intent, architecture, boundaries, invariants, tradeoffs, risk acceptance, and final technical decisions.\n\nYour 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.\n\nThe notebook is documentation and architectural review infrastructure.\n\nIt is **not** an interactive implementation dashboard. No buttons such as \"implement this\" or \"approve and run\". No controls that execute code from the notebook.\n\n## Resources\n\nThis skill is intentionally lean. Load details only when needed:\n\n- `assets/notebook.html` — canonical visual scaffold. Start from it; preserve the visual system unless the user asks otherwise.\n- `references/NOTEBOOK-SECTIONS.md` — full section definitions, diagram rules, scaling.\n- `references/ARCHITECTURE-CHECK.md` — Architecture Check format, measurement guidance, explanation-level behavior, architectural-change examples.\n\n---\n\n## 1. First activation\n\nOn first use in a repository:\n\n1. inspect `.gitignore`\n2. add the exact root entry:\n\n```gitignore\n/engineering-notebook.html\n```\n\n3. if the notebook later splits into a directory, also add:\n\n```gitignore\n/engineering-notebook/\n```\n\n4. create the notebook from `assets/notebook.html` — do not redesign from scratch\n5. never commit the notebook unless the user explicitly requests repository-visible documentation; if they do, explain that the relevant ignore entry must be removed\n\nDo not assume a private repository means the notebook should be committed.\n\n---\n\n## 2. Explanation level: calibrate, never block\n\nChoose one explanation level for the notebook:\n\n```text\nIntern · New Grad · Junior · Mid-Level · Senior · Staff · Principal · Distinguished\n```\n\nBehavior:\n\n1. if the notebook already stores an explanation level, reuse it\n2. if an interactive user is available on first activation, ask for the level\n3. if no answer can be obtained without blocking, default to `Junior`\n4. continue immediately\n5. never block implementation solely waiting for calibration\n\nStore the chosen level only inside the local notebook metadata/comment so future updates remain consistent.\n\nExplanation level chan"},{"path":"README.md","content":"# edn\n\n[![skills.sh](https://skills.sh/b/skcache/edn)](https://skills.sh/skcache/edn)\n\n**Engineering Dashboard Notebook**\n\nAI coding agents can write most of the code now.\n\nThe problem is when they also start owning the architecture and you slowly stop knowing why your own system works the way it does.\n\n`edn` keeps a local engineering notebook in sync with your repo so you can actually stay on top of:\n\n- architecture\n- components\n- dependencies\n- data flow\n- tradeoffs\n- failure modes\n- security boundaries\n- current vs proposed changes\n\nThe notebook lives locally as:\n\n```text\nengineering-notebook.html\n```\n\nand gets added to `.gitignore` automatically.\n\n## How it works\n\nFor normal work, the agent just builds.\n\nIf something meaningfully changes the architecture, it shows you the current setup, the proposed change, tradeoffs, evidence, and simpler alternatives before implementing it.\n\nYou make the call.\n\nAfter the task is done, `edn` updates the notebook to match the actual code.\n\n## Learn while you build\n\nOn 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.\n\n```text\nIntern\nNew Grad\nJunior\nMid-Level\nSenior\nStaff\nPrincipal\nDistinguished\n```\n\nSame engineering rigor, just different levels of context.\n\nSo 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.\n\n## Install\n\n```bash\nnpx skills add skcache/edn\n```\n\nFor Codex:\n\n```bash\nnpx skills add skcache/edn -a codex\n```\n\nFor Claude Code:\n\n```bash\nnpx skills add skcache/edn -a claude-code\n```\n\nThe `skills` CLI supports a bunch of coding agents and installs skills directly from GitHub.\n\n## Update\n\nTo update an existing install:\n\n```bash\nnpx skills update edn\n```\n\n`metadata.version` in `SKILL.md` is for human release tracking; the CLI finds updates from the source repo, not this field.\n\n## Use\n\nInside your repo:\n\n```text\nUse the edn skill.\nBootstrap the engineering notebook for this repository.\n```\n\nThat's it.\n\nThe agent can own the typing.\n\nYou should still own the system.\n\n## License\n\nMIT"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn74j906ccqnn8y8r445e03g298c2t2r\",\n  \"slug\": \"edn\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1786160553796\n}"},{"path":"references/ARCHITECTURE-CHECK.md","content":"# ARCHITECTURE-CHECK.md\n\nDeep-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.\n\n## Explanation-level calibration\n\nLevel changes **depth and terminology**, not the underlying architecture or technical rigor.\n\nDo not claim the levels map universally to company-specific L3/L4/L5/etc. Engineering ladders vary by organization.\n\n### Intern / New Grad / Junior\n\n- explain unfamiliar infrastructure concepts when they become relevant\n- define jargon briefly at first use\n- explicitly connect a design choice to the current repository\n- show the simplest credible alternative\n- use it as a teachable moment, not a lecture\n- keep the same technical substance but add context\n\n### Mid-Level / Senior\n\n- assume familiarity with common application architecture\n- focus on boundaries, ownership, consistency, latency, operational cost, and failure modes\n- explain uncommon or repository-specific concepts\n- keep background explanation compact\n\n### Staff / Principal / Distinguished\n\n- optimize for decision density\n- emphasize system constraints, second-order effects, interfaces, invariants, operational consequences, and alternatives\n- avoid introductory explanations unless requested\n- surface uncertainty and evidence directly\n\n## Architectural-change checklist\n\nRun an Architecture Check before coding when the change:\n\n- adds/removes a service or process\n- adds a database, cache, queue, or persistent store\n- changes source-of-truth ownership\n- introduces a new external dependency/API\n- changes authentication/authorization boundaries\n- changes tenant isolation behavior\n- is a meaningful schema redesign\n- introduces new async/concurrency behavior\n- moves responsibility between major components\n- changes a public/internal interface used across subsystem boundaries\n- splits or merges major components\n- changes deployment/runtime topology\n- introduces a new consistency model\n\nRoutine 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.\n\n## Architecture Check format\n\nKeep the check compact enough to be useful.\n\n```md\n## Architecture Check\n\n### Requested change\nWhat is being requested.\n\n### Relevant current architecture\nOnly the part of the system affected.\n\n### Proposed architecture\nWhat would structurally change.\n\n### Why this may help\nConcrete benefit tied to a real constraint.\n\n### Costs / tradeoffs\nComplexity, consistency, latency, operations, security, coupling, cost, etc.\n\n### Evidence\nWhat measurements, tests, docs, or observed behavior support the change?\nIf evidence is missing, say so.\n\n### Alternatives\nInclude the simplest credible alternative.\n\n### Concepts worth knowing\nExplain only what is necessary to evaluate this decision, calibrated to the configured eng"},{"path":"references/NOTEBOOK-SECTIONS.md","content":"# NOTEBOOK-SECTIONS.md\n\nDetailed 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.\n\n## Learning check\n\nBefore writing a section, confirm the notebook already knows:\n\n- the configured explanation level (store: **Intern, New Grad, Junior, Mid-Level, Senior, Staff, Principal, Distinguished**)\n- which sections exist and why\n- whether this is a compact-repo notebook (fewer sections) or a full notebook\n\nExplanation level changes **depth and terminology**, not rigor. Per-level behavior lives in `ARCHITECTURE-CHECK.md`.\n\n## Section definitions\n\nKeep the core notebook stable. Sections may be omitted when genuinely irrelevant. See `SKILL.md` section 9 (Compact-repo mode) for when to omit.\n\n### A. Project Map\n\nA one-screen map of the major system.\n\nShow:\n\n- clients / entry points\n- major components\n- persistent stores\n- queues / caches\n- external systems\n- important trust/runtime boundaries\n\nPrefer a diagram plus terse annotations.\n\n### B. System Architecture\n\nExplain:\n\n- major layers\n- responsibilities\n- dependency direction\n- important invariants\n- process/runtime boundaries\n- architectural style where useful\n\nDo not list every file.\n\n### C. Core Components\n\nFor each important component:\n\n```text\nPurpose\nOwns\nDoes NOT own\nPublic interface / entry points\nDependencies\nImportant state\nFailure behavior\n```\n\n\"Does NOT own\" is required when ownership could otherwise be ambiguous.\n\n### D. Key Flows\n\nDocument important end-to-end flows.\n\nEach flow should answer:\n\n```text\nWhere does it enter?\nWhich components touch it?\nWhere is state read/written?\nWhat external system is called?\nWhat leaves the system?\nWhere can it fail?\n```\n\nExamples:\n\n- sign in\n- create invoice\n- execute inference request\n- upload file\n- generate report\n\n### E. Data / State Ownership\n\nFor meaningful state, show:\n\n- owner\n- source of truth\n- storage location\n- mutation path\n- read path\n- cache relationship if present\n- tenant/user boundary if relevant\n\nPay special attention to authorization and tenant isolation.\n\n### F. Decisions & Tradeoffs\n\nRecord only decisions a future engineer may reasonably question.\n\nFor each:\n\n```text\nDecision\nWhy\nAlternatives considered\nWhat we gain\nWhat we give up\nEvidence / assumption\nWhen to revisit\n```\n\nDo not create decision-record theater for trivial choices.\n\n### G. Failure Modes / Risks\n\nFor important paths:\n\n```text\nWhat can fail?\nWhat does the user/system experience?\nHow is it detected?\nHow is it recovered?\nWhat data can be lost, duplicated, delayed, or exposed?\nCould a security or tenant boundary be crossed?\n```\n\n### H. Current vs Proposed Architecture\n\nClearly distinguish:\n\n- **Current** — exists in code now\n- **Proposed** — planned but not implemented\n\nUse solid visual treatment for current architecture and dashed/dotted visual treatment for proposed architecture<br>\n(solid border/edge = current, dashed"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"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:","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1543,"uniquenessScore":47,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T16:33:02.738Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T16:33:02.738Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:54:51.381Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"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!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"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","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}