decision-log
Log project decisions to the context-hub (chub) knowledge base with full context, rationale, and telemetry. Use this skill whenever a meaningful decision is made during a conversation — architecture choices, tooling selections, deployment strategies, process changes, security tradeoffs, or any choice that future-you would want context on. Trigger explicitly when the user says "log decision", "record decision", "capture this decision", "decision log", or "ADR". Also trigger proactively — if you detect that a significant decision just happened (e.g., the user picked an approach, chose a library, agreed to a tradeoff), suggest logging it with a brief one-liner like "Worth logging this decision?"
What this skill does
# Decision Log
Record project decisions to the context-hub so they survive context resets and session boundaries. Every decision entry captures *what* was decided, *why*, *what alternatives were considered*, and enough telemetry to reconstruct the moment.
## When to Log
**Explicit:** User says "log this decision", "record decision", "capture decision", "ADR", or similar.
**Proactive:** When you detect a meaningful decision was just made — a choice between alternatives, a tradeoff accepted, a direction confirmed. Suggest it briefly:
> "Worth logging this decision to chub?"
If the user declines, move on immediately. Don't nag.
What counts as a "meaningful decision":
- Architecture or design choices (database selection, API design, service boundaries)
- Tooling and dependency choices (library A vs B, framework selection)
- Deployment and infrastructure choices (hosting, scaling strategy, CI/CD)
- Process decisions (branching strategy, review process, testing approach)
- Security tradeoffs (auth mechanism, data handling, access control)
- Scope decisions (feature cut, MVP boundary, what to defer)
What does NOT count:
- Routine code changes (renaming a variable, fixing a typo)
- Obvious best practices (adding error handling, following lint rules)
- Temporary debugging choices ("let's try adding a log here")
## Decision Entry Structure
Each decision is appended to a per-project decisions doc in chub. The doc lives at:
```
~/.chub-internal/neuronbox/docs/decisions-<project>/DOC.md
```
If the doc doesn't exist yet, create it with this frontmatter. The `languages` and `versions` fields are required by `chub build` — always include them:
```markdown
---
name: decisions-<project>
description: Decision log for <project> — architecture, tooling, deployment, process, and security decisions with full context and rationale.
metadata:
languages: "all"
versions: "<YYYY.M.DD>"
revision: 1
updated-on: "<YYYY-MM-DD>"
source: decision-log-skill
tags: "decisions,<project>,adr"
---
# Decision Log: <project>
Accumulated decisions with context, rationale, and telemetry.
```
### Entry Format
Append each new decision as a section under the main heading:
```markdown
---
## DEC-<NNN>: <short title>
**Date:** <YYYY-MM-DD>
**Category:** <one of: architecture | tooling | deployment | process | security | scope>
**Tags:** <free-form comma-separated tags>
**Status:** accepted
### Context
<What situation or problem prompted this decision? What were we trying to achieve? Include enough background that someone reading this 6 months later — without access to this conversation — understands the landscape.>
### Alternatives Considered
| Option | Pros | Cons |
|--------|------|------|
| <option A> | ... | ... |
| <option B> | ... | ... |
### Decision
<What was decided and why. Be specific — not "we chose option A" but "we chose per-project decision logs because they mirror the existing chub structure and keep entries focused.">
### Consequences
<What follows from this decision. Structure as:>
- **Easier:** <what this decision simplifies>
- **Harder:** <what this decision makes more difficult or defers>
- **Constraints:** <new constraints or invariants this imposes>
### Telemetry
| Field | Value |
|-------|-------|
| project | <project name> |
| working_dir | <cwd> |
| model | <model ID> |
| files_involved | <comma-separated list of files touched or discussed> |
| tools_used | <tools invoked during this decision> |
| conversation_turns | <approximate turn count> |
| session_duration_est | <rough estimate> |
```
## Numbering
Decision IDs are sequential per project. When appending to an existing doc, read the last `DEC-<NNN>` entry and increment. If the doc is new, start at `DEC-001`.
## Determining the Project
Infer the project from context:
1. If working in a project directory with a CLAUDE.md, use that project's name
2. If the user mentions a specific project/bot (DB, Nook, X, M-Bot), use that
3. If ambiguous, ask: "Which project should I log this under?"
Map common names to chub slugs:
- DB / OpenClaw / Neuron → `openclaw`
- Nook / Letta → `nook`
- X / NanoClaw → `nanoclaw`
- M-Bot / OpenJarvis → `mbot`
- AEGIS → `aegis`
If the project doesn't match any known slug, create a new one using the project's lowercase name.
## After Logging
1. Increment the `revision` number in the doc's frontmatter
2. Update the `updated-on` date
3. Rebuild the chub registry:
```bash
chub build ~/.chub-internal -o ~/.chub-internal/dist
```
4. Confirm to the user: "Logged DEC-<NNN> to decisions-<project>: <title>"
## Retrieving Past Decisions
When the user asks about past decisions ("why did we choose X?", "what decisions have we made about Y?"), search chub:
```bash
chub search "decisions <project>"
```
Then read the relevant doc and surface the matching entries.
Related in Security
mac-ops
IncludedComprehensive macOS workstation operations — diagnose kernel panics, identify failing drives, audit launchd startup items, decode wake reasons, triage TCC permission denials, manage APFS snapshots, recover from no-boot. Use for: Mac is slow, slow bootup, won't boot, kernel panic, kernel_task hot, mds_stores CPU, photoanalysisd, cloudd, login loop, gray screen, sleep wake failure, drive failing, IO errors, APFS snapshots eating space, Time Machine local snapshots, Spotlight indexing, launchd, LaunchAgent, LaunchDaemon, login items, TCC permissions, Full Disk Access, Screen Recording denied, Gatekeeper, quarantine, com.apple.quarantine, app is damaged, helper tool, /Library/PrivilegedHelperTools, pmset, wake reasons, dark wake, sysdiagnose, panic.ips, DiagnosticReports, configuration profile, MDM profile, remote diagnostics over SSH.
a11y-audit
IncludedRun accessibility audits on web projects combining automated scanning (axe-core, Lighthouse) with WCAG 2.1 AA compliance mapping, manual check guidance, and structured reporting. Output is configurable: markdown report only, markdown plus machine-readable JSON, or markdown plus issue tracker integration. Use this skill whenever the user mentions "accessibility audit", "a11y audit", "WCAG audit", "accessibility check", "compliance scan", or asks to check a web project for accessibility issues. Also trigger when the user wants to verify WCAG conformance or map findings to a specific standard (CAN-ASC-6.2, EN 301 549, ADA/AODA).
erpclaw
IncludedAI-native ERP system with self-extending OS. Full accounting, invoicing, inventory, purchasing, tax, billing, HR, payroll, advanced accounting (ASC 606/842, intercompany, consolidation), and financial reporting. 413 actions across 14 domains, 43 expansion modules. Constitutional guardrails, adversarial audit, schema migration. Double-entry GL, immutable audit trail, US GAAP.
assess
IncludedAssesses and rates quality 0-10 across multiple dimensions (correctness, maintainability, security, performance, testability, simplicity) with pros/cons analysis. Compares against project conventions and prior decisions from memory. Produces structured evaluation reports with actionable improvement suggestions. Use when evaluating code, designs, architectures, or comparing alternative approaches.
spring-boot-security-jwt
IncludedProvides JWT authentication and authorization patterns for Spring Boot 3.5.x covering token generation with JJWT, Bearer/cookie authentication, database/OAuth2 integration, and RBAC/permission-based access control using Spring Security 6.x. Use when implementing authentication or authorization in Spring Boot applications.
code-hardcode-audit
IncludedDetect hardcoded values, magic numbers, and leaked secrets. TRIGGERS - hardcode audit, magic numbers, PLR2004, secret scanning.