lucasilverentand
53 verified skills159 total stars
platform-dependency
Writes platform dependency documents from the project-docs template. Use when the user asks for a platform dependency doc, wants vendor or API risk analysis, needs external framework constraints documented, or is filling platform-dependency.md.
development3
post-release-review
Writes post-release review documents from the project-docs template. Use when the user asks for a post-release review, wants a retrospective after shipping or abandoning work, needs lessons and follow-up issues captured, or is filling post-release-review.md.
documentation3
retrospecting
Mines recent agent conversations and git history for struggles, repeated corrections, rework patterns, and taste signals — then turns findings into new skills or updates to existing ones. Use when you want to retrospect on recent coding sessions to extract learnings, identify skill gaps, improve existing skills based on real usage patterns, or codify preferences that keep coming up in conversations.
data-ai3
tooling
Creates and improves bun-based tools for skills — decides when a tool earns its place, scaffolds zero-dependency scripts with dual output, validates tool quality, and wires tools into SKILL.md decision trees. Use when adding a tool to a skill, improving an existing tool, deciding whether something should be a tool or inline instructions, or reviewing tool quality.
tools3
release-readiness
Writes release readiness documents from the project-docs template. Use when the user asks for release readiness, wants a ship or hold checklist, needs launch risk and rollback evidence, or is filling release-readiness.md.
testing3
research-brief
Writes research brief documents from the project-docs template. Use when the user asks for a research brief, wants an evidence trail, needs sourced findings for a product or technical decision, or is filling research-brief.md.
testing3
testing-strategy
Writes testing strategy documents from the project-docs template. Use when the user asks for a testing strategy, wants a shared test plan, needs CI or coverage expectations across a project, or is filling testing-strategy.md.
testing3
decision-trees
Creates decision trees that both humans and AI agents can follow reliably — captures expert knowledge as branching logic with concrete conditions, clear actions, and visible reasoning traces. Use when the user wants to document a decision process, create a troubleshooting guide, build a triage flowchart, write an escalation tree, or turn tribal knowledge into structured steps.
development3
write-design-doc
Assembles architecture, data modeling, and API design work into a structured, readable system design document. Focuses on writing quality, document structure, and completeness — the thinking work (decomposition, trade-offs, data modeling) happens in other skills and this skill pulls the results together into a single artifact that engineers and LLMs can implement from. Use when the user asks to write a design doc, document a design, write up the architecture, create a technical spec, assemble a system design, or says things like "write this up", "let's document the design", "create a design doc for this", or "turn this into a spec".
development3
write-adr
Writes Architecture Decision Records (ADRs) in MADR format — captures context and problem, decision drivers, considered options with pros/cons, the chosen option and why, and consequences. Numbers files sequentially under .context/architecture/adr/. Use when the user asks to document a decision, write an ADR, record a trade-off, capture why something was chosen over alternatives, or says things like "let's write this up as an ADR", "log this decision", or "we should document why we picked X".
development3
design-options
Generates interactive HTML design explorations for UI features — produces a single self-contained HTML file with multiple design variants and a switcher to compare them. Supports card-level components through full screen layouts using skeleton wireframe elements. Use when exploring design directions, comparing layout options, mocking up a feature before building it, or presenting UI alternatives.
development3
cleaning-repos
Leaves a repo in a pristine state — commits all changes cleanly, prompts about leftover files, clears stale stashes, opens a PR if on a feature branch, cleans up merged branches and stale worktrees, and returns to main. Use when the user says "clean up the repo", "wrap up this branch", "tidy up", or wants to get back to a clean main branch after finishing work.
data-ai3
project-brief
Writes project brief documents from the project-docs template. Use when the user asks for a project brief, wants a one-page kickoff or framing document, needs scope and success criteria for a new project, or is filling project-brief.md.
documentation3
c4-diagrams
Generates C4 model architecture diagrams (System Context, Container, Component) as Mermaid for embedding in docs — picks the right C4 level for the question being answered, labels every element with its technology and responsibility, and avoids the "everything touches everything" spaghetti that makes most architecture diagrams useless. Writes to .context/architecture/diagrams/. Use when the user asks for a diagram of their system, an architecture visualization, a container/component diagram, wants to see how pieces fit together, or mentions "C4".
documentation3
resolving-conflicts
Resolves merge conflicts during rebases, merges, and cherry-picks — reads both sides, understands intent from git history, auto-resolves clear-cut cases, and asks about ambiguous ones. Also handles end-to-end rebase workflows (fetch, rebase onto target, resolve, continue). Use when the user says "rebase onto main", "resolve conflicts", "fix these conflicts", "merge main in", "finish this rebase", or when a rebase/merge/cherry-pick has stopped due to conflicts.
data-ai3
creating-commits
Creates well-structured conventional commits from working tree changes — analyzes diffs, writes short snappy commit titles with detailed bodies, and splits messy working trees into multiple focused commits with line-level precision. Use when committing changes, organizing uncommitted work into commits, splitting a large changeset into atomic commits, writing commit messages, cleaning up a repo into clean commits, or proactively after completing a piece of implementation work to keep the repo clean.
testing3
creating-prs
Creates pull requests with clear titles and well-structured descriptions — rebases onto the target branch, checks for PR templates and contributing guides, summarizes commits into a coherent narrative, and opens the PR via gh CLI. Use when opening a pull request or preparing a branch for review.
tools3
feature-spec
Writes feature spec documents from the project-docs template. Use when the user asks for a feature spec, wants user stories or acceptance criteria, needs product behavior documented before implementation, or is filling feature-spec.md.
documentation3
documentation-placement-rules
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.
documentation3
customer-profile
Writes customer profile and market documents from the project-docs template. Use when the user asks for a customer profile, wants persona or market notes, needs audience assumptions for a project, or is filling customer-profile.md.
documentation3
decision-record
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.
testing3
requirements
Gathers, structures, and prioritizes requirements for a system before any design work begins. Use when the user has a vague idea ("I need to build X", "we need a service that does Y"), wants to define what a system should do and under what constraints, asks about non-functional requirements, says things like "what are the requirements for", "help me scope this", "what do I need to think about before building", or "let's figure out what this needs to do". Do NOT use for designing the system itself — this skill produces the inputs that architecture and design skills consume.
development3
monitoring-ci
Monitors CI checks on the current branch, diagnoses failures from logs, fixes them (lint, typecheck, test, build), pushes the fix, and re-watches until green. Uses gh run watch for live monitoring and gh run view --log-failed for diagnosis. Use when CI is failing, after pushing to a PR, when the user says "watch CI", "fix CI", "why is CI failing", or proactively after creating a PR or pushing changes.
development3
project-context
Generates and maintains a hierarchical .context/ directory with architecture overviews, coding conventions, domain glossaries, and dependency maps that give any LLM working in the project the right background. Use when setting up a new project for AI-assisted development, when the user asks to create or update context docs, when onboarding a new LLM tool to an existing codebase, or when the user says the AI doesn't understand their project.
tools3
taste-encoding
Interviews the user to extract their design taste, technology preferences, and opinionated defaults for a domain — then encodes those preferences into skill reference files, decision rules, conventions, and anti-patterns. Use when the user wants to encode their preferences into a skill, capture their taste for a domain, add opinionated defaults, make a skill reflect their style, or says things like "encode my taste", "add my preferences to this skill", "make this skill opinionated", or "interview me about my preferences for X".
development3
authoring
Creates and improves agent skills — scaffolds skill directories, writes SKILL.md with frontmatter and decision trees, adds references, validates structure and token budgets. Use when creating a new skill from scratch, improving an existing skill's instructions or decision tree, adding a reference to a skill, validating a skill, or refactoring a bloated skill into smaller pieces. For adding tools to a skill, use the tooling skill.
tools3
technical-design
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.
documentation3
api-design
Designs REST, GraphQL, or gRPC APIs from requirements — picks the right protocol for the use case, models resources and operations, defines schemas (Zod for internal, OpenAPI/GraphQL SDL/proto for specs), and writes the spec to .context/architecture/api/. Use when the user asks to design an API, sketch out endpoints, model a schema, plan a service's interface, or says things like "what should the API look like for X", "design endpoints for Y", or "how should clients talk to this service".
tools3
design-review
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".
development3
design-workflow
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.).
development3
architecture
Guides system architecture and decomposition — turns requirements into a concrete system shape by identifying components, drawing boundaries, tracing data flow, analyzing failure modes, and selecting technology. Covers the intellectual work of breaking a system apart, not the writing of a design document. Use when the user asks to architect a system, decompose a feature into components, figure out how services should talk to each other, evaluate system trade-offs, or says things like "how should we structure this", "what components do we need", "let's think through the architecture", or "where should this logic live".
testing3
data-modeling
Designs the data layer — schemas, entities, relationships, ID strategy, naming, tenancy, timestamps, indexes, audit logging, and migrations. Turns a set of domain concepts into a concrete Drizzle schema with all the small decisions that compound into either a clean data layer or a mess. Use when the user asks to design a schema, model the data, plan the database, add tables, review an existing schema, or says things like "what should the database look like", "design the schema for X", "add a table for Y", or "how should I store Z". Does NOT cover system decomposition (use architecture) or API design (use api-design).
development3
project-docs
Writes and edits project documents from the project-docs templates. Use when the user asks for a project brief, feature spec, technical design, decision record, research brief, platform dependency doc, customer profile, testing strategy, release readiness doc, post-release review, documentation placement rules, or is filling one of those project document templates.
testing3
create-doc-template
Maintains Markdown document templates in the project-docs plugin. Use when working in this skills repo and the user asks to add a reusable project document template, update an existing template reference, change the project-docs template library, or adjust README/template validation for project-docs.
tools3
macos
Apple Human Interface Guidelines for macOS — UI components, controls, navigation, and platform conventions for Mac. Use when designing for Mac, building a macOS UI, or auditing macOS components. Pair with `foundations` for shared principles and `services` for framework integrations. User says: "design Mac UI", "macOS component", "audit my macOS app".
development3
foundations
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".
development3
ios
Apple Human Interface Guidelines for iOS & iPadOS — UI components, controls, navigation, and platform conventions for iPhone and iPad. Use when designing for iPhone and iPad, building a iOS & iPadOS UI, or auditing iOS & iPadOS components. Pair with `foundations` for shared principles and `services` for framework integrations. User says: "design iPhone and iPad UI", "iOS & iPadOS component", "audit my iOS & iPadOS app".
development3
watchos
Apple Human Interface Guidelines for watchOS — UI components, controls, navigation, and platform conventions for Apple Watch. Use when designing for Apple Watch, building a watchOS UI, or auditing watchOS components. Pair with `foundations` for shared principles and `services` for framework integrations. User says: "design Apple Watch UI", "watchOS component", "audit my watchOS app".
development3
visionos
Apple Human Interface Guidelines for visionOS — UI components, controls, navigation, and platform conventions for Apple Vision Pro. Use when designing for Apple Vision Pro, building a visionOS UI, or auditing visionOS components. Pair with `foundations` for shared principles and `services` for framework integrations. User says: "design Apple Vision Pro UI", "visionOS component", "audit my visionOS app".
development3
services
Apple framework and service integrations: Apple Pay, HealthKit, HomeKit, Siri, CarPlay, Sign in with Apple, App Clips, widgets, Camera, Control Center, sensors, and more. Use when integrating an Apple framework or designing UI that surfaces one. User says: "add Apple Pay", "Sign in with Apple", "HealthKit UI", "design a widget".
tools3
tvos
Apple Human Interface Guidelines for tvOS — UI components, controls, navigation, and platform conventions for Apple TV. Use when designing for Apple TV, building a tvOS UI, or auditing tvOS components. Pair with `foundations` for shared principles and `services` for framework integrations. User says: "design Apple TV UI", "tvOS component", "audit my tvOS app".
development3
closed-source-docs
Creates, audits, and updates private or closed-source project documentation, including internal README hubs, codebase navigation guides, ownership links, Linear initiative links, onboarding notes, runbooks, and contribution guidance for teams. Use when maintaining docs for private repositories, internal apps, services, infrastructure, or company projects, especially when the user says "make this README an internal hub", "document how to navigate this repo", "add Linear links to the docs", or "write private project documentation".
development3
linear-issues
Creates, updates, estimates, and tidies Linear issues using Luca's issue-shaping rules. Use when the user asks to create a Linear issue, write ticket-ready issue text, refine an existing issue, add acceptance criteria, set issue relationships, estimate points, audit issue hygiene, tidy a Linear project, find duplicates, fix stale blockers, or normalize labels, milestones, priorities, and issue state.
development3
task-spec
Interviews the user to turn rough intent into a written task spec before filing an issue, starting code, or doing substantial work. Use when the user asks to create an issue, start implementation, scope a task, capture specs, clarify intent, write acceptance criteria, says "grill me", or has a fuzzy request that needs a concrete brief before action.
development3
open-source-docs
Creates, audits, and updates public open-source repository documentation, including README files, CONTRIBUTING guides, SECURITY and SUPPORT docs, project badges, quickstarts, usage guidance, community links, and contributor onboarding. Use when maintaining docs for public GitHub projects, libraries, CLIs, apps, or reusable packages, especially when the user says "update this README", "write CONTRIBUTING.md", "make these docs open-source ready", or "improve the public project docs".
tools3
tidy-linear-project
Keeps an existing Linear project tidy after planning and during execution. Use when the user asks to "tidy Linear", "clean up the project", "audit issues", "find duplicates", "check stale blockers", "fix project drift", or run periodic Linear housekeeping on a project, initiative, or milestone set. Use when planning is underway or execution has started and relationships, labels, priorities, documents, and issue states need coherence without changing product scope.
testing3
estimate-issue-complexity
Assigns Linear issue points using Luca's complexity-only scale. Use when the user asks to grade, estimate, score, point, size, triage, compare, normalize, or audit Linear issues by complexity, especially when they mention points, estimates, acceptance criteria, issue sizing, or avoiding time estimates.
testing3
pickup-work
Picks up the next actionable Linear issue for the product represented by the current repository. Use when the user says "/pickup-work", "pickup work", "pick up an issue", "what should I work on next", or asks to start Linear work from a repo. Use when a local monorepo should be mapped to its Linear product initiative or project before assigning and starting an issue.
tools3
fix-pr
Gets an existing GitHub pull request ready to merge when the user gives only a PR number. Checks out the PR, inspects mergeability, resolves or reports conflicts, syncs with the base branch, runs appropriate local validation, watches CI until green, handles draft/review/conversation blockers, pushes fixes when needed, and reports the exact remaining merge blockers. Use when the user asks to get a PR ready to merge, prepare a PR for merge, make PR
testing3
create-doc-template
Maintains Markdown document templates in the linear-planner plugin's project-docs library. Use when working in this skills repo and the user asks to add a reusable project document template, update an existing template reference, change the project-docs template library, or adjust README/template validation for project-docs.
tools3
project-docs
Writes and edits project documents from the project-docs templates. Use when the user asks for a project brief, feature spec, technical design, decision record, research brief, platform dependency doc, customer profile, testing strategy, release readiness doc, post-release review, documentation placement rules, or is filling one of those project document templates.
testing3
create-planner-project
Creates fresh Linear planning projects from Luca's five-phase planner structure. Use when the user asks to "create a planner project", "set up planning in Linear", "turn this app idea into a Linear planning project", or replace a live Linear template project with a reusable skill-backed workflow. Use when a real web, native, backend, automation, data, AI, or mixed-surface project needs initiative, project, milestone, and issue records in Linear without keeping reusable template issues live.
tools3
publishing
Manages Codex, Claude Code, and Cursor skill marketplaces — publishes plugin-owned skills, updates plugin groups, removes entries, packages skills for distribution, regenerates plugin manifests, and validates catalog integrity. Use when publishing a skill to the marketplace, bumping a version, removing a skill from the catalog, packaging a skill as a .skill file, regenerating marketplace files, moving a skill between plugins, or fixing marketplace validation errors.
tools3