lucasilverentand/technical-design
plugins/project-docs/skills/technical-design/SKILL.md
Writes technical design documents from the project-docs template. Use when the user asks for a technical design, wants implementation architecture, needs state, contract, migration, or failure-mode planning, or is filling technical-design.md.
$ install --global
skillsauthnpx skillsauth add lucasilverentand/skills technical-designInstall 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:20 AM355.7s2 files scanned
SKILL.md
- name:
- technical-design
- description:
- Writes technical design documents from the project-docs template. Use when the user asks for a technical design, wants implementation architecture, needs state, contract, migration, or failure-mode planning, or is filling technical-design.md.
Technical Design
Use this skill to turn settled product scope into an engineering plan that reviewers can evaluate before code changes sprawl.
Decision tree
- What is the user asking for?
- A new technical design -> read
../../README.mdandreferences/template.md, then draft the design in the requested destination. - Product behavior or acceptance criteria are still unclear -> use the
feature-specskill first, then return to technical design. - A cross-cutting system architecture decision -> use this skill for implementation structure and a
decision-recordfor the chosen direction if it creates precedent. - Testing expectations -> link to
testing-strategyfor project-wide rules and write only the feature-specific testing plan here. - Something else -> ask whether the user needs implementation design or a product feature spec.
- A new technical design -> read
Workflow
- Read
../../README.mdfor shared conventions and relationship rules. - Read
references/template.mdbefore drafting or editing. - Gather goals, non-goals, proposed design, state model, interfaces, contracts, failure modes, security, privacy, migration, rollout, testing plan, alternatives, and open questions.
- Use diagrams or tables for flows, state ownership, API contracts, data models, rollout phases, and alternatives when they make review easier.
- Preserve trade-offs and rejected options. They are often the part future maintainers need.
- Link to feature specs, testing strategy, platform dependency docs, research briefs, and decision records where they affect the design.
Document contract
- When to write: After product scope is clear enough to choose implementation shape.
- How many: One per feature, system, or infrastructure change that needs engineering review.
- Owns: Goals, non-goals, implementation structure, state ownership, contracts, failure handling, migration, rollout, testing plan, alternatives, and open questions.
- Link instead of duplicating: Product behavior belongs in feature specs; shared testing rules belong in testing strategy; durable decisions belong in decision records.
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