Wiki Decision Log
Keep an append-only, greppable log and dated decision records, and answer why a decision was made or what changed since.
Before & after
Same prompt, same agent — the only difference is the skill.
A wiki log is a good way to document decisions. You could create a page and start writing down decisions as they come up. What system are you using – Notion, Confluence, GitHub? How detailed do you want each entry? Should you include rejected options or just the final decision? I can suggest a basic format, but it really depends on how you want to structure it and what your team finds most useful.
ENGINEERING WIKI LOG TEMPLATE
→ ENTRY STRUCTURE (use for every decision)
Date: 2025-08-31
Decision: "Migrate authentication from Session-based to JWT tokens"
Owner: Engineering lead (who drove the decision)
Status: IMPLEMENTED
Impact: Security, Performance, Migration timeline (all systems affected)
→ DECISION CONTENT
Problem: "Session store Redis becoming bottleneck at 10k concurrent users; scaling costs rising"
Context: "3-month growth from 2k to 10k users; current SLA at 99.5% availability"
Options considered:
1. Scale Redis vertically (cost: $15k/month additional) – REJECTED (diminishing returns)
2. Implement JWT + refresh tokens (cost: $5k engineering, 6 weeks) – CHOSEN
3. Stay session-based + shard storage (cost: $8k, 4 weeks, ongoing complexity) – REJECTED
Decision rationale: "JWT eliminates session state dependency; enables edge caching; reduces operational overhead"
→ RESOLUTION & ROLLBACK PLAN
Implementation path: Phase 1 (new users JWT, 2 weeks) → Phase 2 (migrate existing, 3 weeks) → Phase 3 (deprecate Session, 1 week)
Rollback: If JWT verification hits >0.5% failure rate during Phase 1, revert to Session for that cohort
Metrics tracked: Auth latency, token validation errors, user session churn
→ OUTCOME (updated post-implementation)
Launched: Sept 15, 2025
Actual impact: Auth latency reduced 30% (target: 25%); no issues in Phase 1; full migration on track
Lessons: Rate-limiting token refresh calls discovered late – added to future auth decisions
Related decisions: See JWT Secret Rotation (Decision #47), Cache Strategy (Decision #51)
→ ARCHIVAL & LINKING
Link from: Architecture Guide, Authentication section
Link from: Performance Improvements 2025, page 3
Archive rule: Keep for 2 years minimum (reference for new team members)
Trap: Don't archive decisions that become "standard practice" without noting the evolutionAbout this skill
Keep the memory of why things are the way they are, so decisions are not re-litigated and new contributors can catch up. History is never rewritten: corrections and reversals are new entries linked to the old ones.
What it does
- Appends one short, greppable entry per event to a shared log that every wiki skill uses
- Writes decision records with owner, date, context, options actually considered, consequences, and a revisit trigger
- Links supersession both ways so an overturned decision never reads as current
- Uses placeholders instead of inventing owners, dates, or rejected alternatives
- Answers "why did we pick X?" and "what changed since August?" from the record
What you get
Log entries and decision records in a consistent format, correction entries when facts change, and cited answers to history questions.
Best for
Project teams, solo builders working with agents across many sessions, and anyone maintaining an LLM wiki who needs a trustworthy change history.
SKILL.md preview
---
name: wiki-log
description: Record decisions and notable changes in a wiki as append-only, greppable log entries and dated decision records - with who decided, what was actually considered, what it supersedes, and links to evidence - and answer "why did we decide X" or "what changed since Y" from that history. Use when the user says "log this decision", "write this up as a decision record", "add an ADR", "note that we switched to X", "why did we pick Y again?", "what changed in the wiki this month", or "correct the entry from last week".
---
# Wiki Decision Log
… (sign up to view the full skill)More ai & agents skills
View all AI & Agents skills →New Skill Scaffolder
Create a new Claude Code skill correctly: right mechanism, valid name and folder, a triggering description, and a smoke test.
Skill Library Lint and Overlap Report
Lint every skill in a repo at once: frontmatter, name-folder match, weak descriptions, overlapping triggers, broken refs, plus a CI script.
Self-Verifying Agent Loop: Plan, Check, Retry, Close
Turns a goal into a task plan with machine-run checks, executes with retry caps, escalates, and refuses to close until verified.
Skill Test Runner (Trigger and A/B)
Test a skill in fresh sessions: ready-to-run prompts, commands, and rubric for trigger recall, false triggers, and blind A/B.