lucasilverentand/decision-record
plugins/project-docs/skills/decision-record/SKILL.md
Writes decision record documents from the project-docs template. Use when the user asks for a decision record, wants to capture why a choice was made, needs options and trade-offs preserved, or is filling decision-record.md.
$ install --global
skillsauthnpx skillsauth add lucasilverentand/skills decision-recordInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 21, 2026, 7:15 AM139.4s2 files scanned
SKILL.md
- name:
- decision-record
- description:
- Writes decision record documents from the project-docs template. Use when the user asks for a decision record, wants to capture why a choice was made, needs options and trade-offs preserved, or is filling decision-record.md.
Decision Record
Use this skill to preserve a decision that future work may need to understand without forcing every affected document to retell the same rationale.
Decision tree
- What is the user asking for?
- A new decision record -> read
../../README.mdandreferences/template.md, then draft the record in the requested destination. - A design that has not been chosen yet -> use the
technical-designskill for options and review, then create a decision record once the choice is made. - Research evidence behind the decision -> use the
research-briefskill and link it from the decision record. - Follow-up implementation work -> capture follow-up issues in the record and file them only when the user asks or the repo workflow requires it.
- Something else -> ask what decision was made, what alternatives were considered, and what trade-off was accepted.
- A new decision record -> read
Workflow
- Read
../../README.mdfor shared conventions and relationship rules. - Read
references/template.mdbefore drafting or editing. - Capture the decision, context, options considered, chosen option, trade-offs, follow-up work, and review trigger.
- Write the decision in the past or present tense, not as a proposal, unless the user explicitly wants a draft.
- Keep options concrete. Name what was rejected and why, including cost, risk, timing, maintenance, and product effects.
- Link affected briefs, specs, technical designs, dependency docs, research briefs, PRs, and issues.
Document contract
- When to write: After choosing a product, technical, operational, or process direction that future work may need to understand.
- How many: One per important decision.
- Owns: Decision, context, options, chosen direction, trade-offs, follow-up work, and review trigger.
- Link instead of duplicating: Deep research belongs in research briefs; implementation plans belong in technical designs; feature behavior belongs in feature specs.
Related Skills
lucasilverentand/foundations
development
VerifiedTrustedCommunity
Cross-platform Apple Human Interface Guidelines: color, typography, layout, materials, motion, accessibility, SF Symbols, branding, plus shared UI elements (activity views, rating indicators, web views, …) and meta sections (components, patterns, technologies). Use when the design topic is platform-agnostic. User says: "iOS color tokens", "SF Symbols", "Apple typography", "dark mode guidance".
3SKILL.mdUpdated Jun 13, 2026
lucasilverentand/design-workflow
development
VerifiedTrustedCommunity
Guides a full system design from idea to spec — sequences requirements gathering, architecture decomposition, data modeling, API design, and document writing into a coherent workflow with clear handoffs. Use when the user asks to "design a system", "build X from scratch", "architect something end-to-end", "plan a new service", or has a broad design ask that spans multiple concerns. Also use when the user says things like "I need to build X" without specifying which aspect to start with. This is the entry point for any design task that isn't clearly scoped to a single skill (data model only, API only, etc.).
3SKILL.mdUpdated Jun 13, 2026
lucasilverentand/design-system
development
VerifiedTrustedCommunity
Synthesizes build-ready design systems and DESIGN.md files from chat briefs, screenshots, moodboards, videos, URLs, live pages, or local image folders while preserving the target product identity. Use when the user asks to "make a design system from these screenshots", "turn this moodboard into DESIGN.md", "extract the design language from this video", "define the UX vibe and rules from these references", or create cohesive UI rules from visual inspiration.
3SKILL.mdUpdated Jun 13, 2026
lucasilverentand/design-review
development
VerifiedTrustedCommunity
Reviews and critiques an existing or proposed system design — flags single points of failure, missing non-functional requirements, scaling bottlenecks, security gaps, operational blind spots, unjustified tech choices, and places where the design will fall over under load or failure. Produces a structured review with severity-tagged findings, not just vibes. Use when the user asks for a second opinion on an architecture, requests a design review, wants feedback on a proposed system, pastes a design doc, or says things like "review this design", "what's wrong with X", "poke holes in this", or "is this a good architecture".
3SKILL.mdUpdated Jun 13, 2026