lucasilverentand/documentation-placement-rules
plugins/project-docs/skills/documentation-placement-rules/SKILL.md
Writes documentation placement rules from the project-docs template. Use when the user asks where docs should live, wants a documentation placement rulebook, needs Linear versus repo documentation ownership, or is filling documentation-placement-rules.md.
$ install --global
skillsauthnpx skillsauth add lucasilverentand/skills documentation-placement-rulesInstall 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 AM144.2s2 files scanned
SKILL.md
- name:
- documentation-placement-rules
- description:
- Writes documentation placement rules from the project-docs template. Use when the user asks where docs should live, wants a documentation placement rulebook, needs Linear versus repo documentation ownership, or is filling documentation-placement-rules.md.
Documentation Placement Rules
Use this skill to create or update the rulebook that tells a project where each kind of planning, repo, and code-level document belongs.
Decision tree
- What is the user asking for?
- A new placement rulebook -> read
../../README.mdandreferences/template.md, then draft the document in the requested destination. - A decision about where one doc should live -> use the placement table from
references/template.md, explain the chosen surface briefly, and create or update the doc there if asked. - Updates to existing placement rules -> preserve established owners, review expectations, and cross-linking conventions unless the user explicitly changes them.
- A different project document type -> use the matching project-docs skill for that document and consult this template only for placement.
- Something else -> ask one short clarifying question about the document surface or ownership decision.
- A new placement rulebook -> read
Workflow
- Read
../../README.mdfor shared conventions, status values, and how project documents relate. - Read
references/template.mdbefore drafting or editing. - Identify the documentation surfaces in play: Linear initiative, Linear project, Linear issue, repo
documents/, package docs, README, or code comments. - Decide ownership by durability, review path, and who needs to find the document later.
- Keep the rules usable. Prefer a table for document type, destination, owner, linked docs, and reason.
- Update frontmatter and
related:references when writing a concrete document.
Document contract
- When to write: When a repo, app, product area, or initiative has more than one plausible documentation surface.
- How many: One per app, product area, or repo.
- Owns: Placement decisions, ownership expectations, review triggers, and cross-linking conventions.
- Link instead of duplicating: Specific project scope, feature behavior, technical designs, release checks, and reviews belong in their own documents.
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