feat(skills): logging-init — interactive, evidence-based logging initialization

[nfeuer]

Summary

Fixes the weakest part of both install paths: logging setup was a one-line "adapt from templates" copy step buried at bootstrap step 8, with no detection of existing logging, no user input, and no guidance for non-Python stacks. Adoption's audit didn't probe logging at all — the gap-report row was an assumption.

New logging-init skill — the initialization flow:

1. Probe (read-only): known-logger imports per language, logging config files, print/console.log density → classify the starting point: GREENFIELD / PRINT-ONLY (with site count) / PARTIAL / ESTABLISHED (library).
2. Ask 3 questions in one batch, each pre-filled with a detected default: log destination (stdout/file/Loki/Datadog/CloudWatch), dev rendering (console-on-TTY vs JSON-everywhere), and the correlation unit (request/job/message id — which decides where context gets bound). Non-interactive runs proceed on defaults and log a follow-up so assumptions get confirmed, never silently becoming policy.
3. Recommend, stack-mapped: structlog / pino / slog / tracing / browser posture, each expressed as the four LOGGING_STANDARD.md capabilities (dual render, correlation context, event naming, outcome+duration helper). ESTABLISHED repos keep their library and get a gap list — never a rewrite.
4. Wire with approval, additively: entry-point setup + context binding; PRINT-ONLY migrates entry points now and logs a follow-up for the rest; outcome recorded in a new kit.yaml logging block; verified by rendering a test event both ways and running observability-check.

Wiring:

• new-project-bootstrap step 8 now dispatches logging-init instead of copying a template
• adopt-existing-project gains Phase 1.8 "logging reality check" (evidence-based gap report) and wires via logging-init in Phase 4; audit summary shows the classification
• kit.yaml + all five presets get the logging block; documented in docs/PROFILE.md
• kit-doctor warns when logging.initialized is false, or the recorded library isn't actually in the project's dependencies
• using-the-kit trigger index row (print/console.log logging → logging-init); README tree + catalog
• kit_version 1.2.0 → 1.3.0

Spec citation

• No design change — kit repo has no canonical spec; the skill body and PROFILE.md are the convention docs.

What was tested

• kit-ci validation run locally: kit.yaml and all five presets parse (each shows its logging block), new SKILL.md frontmatter valid with name matching directory.
• Unit tests: N/A — documentation/skill repo.
• Manual verification: cross-references resolve — logging-init referenced from bootstrap step 8, adopt §1.8/Phase 4, kit-doctor check 3, using-the-kit index, PROFILE.md, README; adopt section renumbering (1.8→1.9) checked for dangling references.
• Coverage ratchet: N/A

Risk and rollback

Risk: low — new skill + checklist/config additions; no hooks or gate semantics change. The kit repo's own kit.yaml records logging.initialized: true (accurate: structlog reference setup). Presets ship initialized: false, which makes kit-doctor nudge newly-bootstrapped projects to run the skill — intended behavior.

Rollback: revert the PR.

Docs

• Narrative docs updated in the same PR (PROFILE.md, README)
• Changelog entry — generated at next release by the release skill
• No ADR needed

Follow-ups

• None added or closed

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01LxEwyqF1KjEPpQKqM5tSrv

---

Generated by Claude Code