jrjsmrtn

Conduct SPARK methodology analysis for new project inception. Use at the beginning of a new project, when evaluating significant features, before bootstrap-project to validate viability, or when pivoting an existing project.

Bootstrap a new project at a chosen graduation tier (t0 minimum, t1 decision-tracked, t2 full pattern language) following AI-Assisted Project Orchestration best practices. Use when starting a new software project, promoting an existing project to a higher tier, or converting an existing project for AI-assisted development.

Graduate a project's in-repo backlog (roadmap phases, sprint deliverables, ADRs) onto a forge issue tracker at a thin-hybrid default, once the backlog outgrows a single contributor. Use when a team needs to see and claim work that currently lives only in docs/roadmap and docs/sprints, when a repo has a mature in-repo roadmap but an empty tracker, when open-sourcing a project, or when deciding what work should stay in-repo versus live on a GitHub, GitLab, Codeberg/Forgejo, or self-hosted internal tracker.

Harden GitHub Actions CI/CD workflows for supply-chain security — SHA-pin actions, least-privilege token permissions, verified toolchain installs, OpenSSF Scorecard, and SLSA provenance. Use when adding or auditing GitHub Actions workflows, before making a repository public, when a supply-chain review flags CI gaps, or when standardizing CI hardening across GitHub projects. GitHub-specific by design — GitLab CI and Forgejo Actions are out of scope.

Harden GitLab CI/CD pipelines for supply-chain security — SHA-pin `include:` and CI/CD components, scope the `CI_JOB_TOKEN` allowlist, protect and mask variables, pin job image digests, and use `id_tokens`/OIDC instead of long-lived secrets. Use when adding or auditing a `.gitlab-ci.yml`, before making a GitLab project public, when a supply-chain review flags CI gaps, or when standardizing pipeline hardening across GitLab projects (gitlab.com or self-hosted). GitLab-specific by design — for GitHub Actions use `harden-github-actions`; Forgejo/Gitea Actions are out of scope.

Create a sprint plan for a new development cycle. Use when starting a new sprint, after completing wrapup-sprint, or when initializing Sprint 1 for a new project.

Create the foundational Architecture Decision Record (ADR) sequence for a new project. Use after bootstrap-project, when establishing decision documentation, or when standardizing ADR practices.

Establish architecture-as-code practice using C4 modeling and Structurizr DSL. Use after bootstrap-project, when establishing architecture documentation, or when migrating from diagram-based to code-based architecture.

Formal specification workflow for state machines using TLX (TLA+ in Elixir). Covers writing abstract specs from ADRs, generating concrete specs from code, enriching extracted skeletons with invariants and properties, refinement checking, and CI integration. Use when asked to write a spec, formally specify, verify a state machine, check refinement, generate a concrete spec, enrich a skeleton, or compare abstract and concrete specs.

Scan an Elixir/Erlang project for modules that TLX can formally specify. Covers OTP behaviours (GenServer, gen_statem, LiveView), framework extensions (Ash.StateMachine), and workflow/pipeline libraries (Reactor, Broadway). Reports spec coverage and suggests where to focus verification effort. Use when asked to audit, scan, find extractable modules, check spec coverage, or triage formal verification targets.

Detect when implementation code has changed but its formal TLX spec has not been updated. Compares git timestamps, re-extracts structure, and diffs against existing specs. Use when asked to check spec drift, detect stale specs, verify specs are up to date, or audit spec freshness.

Generate state machine diagrams from TLX specs in multiple formats (DOT, Mermaid, PlantUML, D2). Use when asked to visualize a spec, generate a diagram, draw a state machine, create a graph, or render a spec as an image.

Use this skill when building or modifying the Spark DSL extension. Consult for entity definitions, sections, transformers, and verifiers.

Audit existing documentation against the Diátaxis framework's four quadrants. Use when reviewing documentation that feels unclear, when assessing documentation quality, or when preparing for a documentation reorganization.

Convert mixed documentation into separate Diátaxis quadrant documents. Use when documentation exists but mixes tutorials, how-tos, reference, and explanation content together, or after a diataxis-audit identifies mixed content.

Create new documentation following the Diátaxis framework. Use when writing documentation from scratch, when a user requests a tutorial, how-to guide, reference, or explanation document, or when filling documentation gaps.

Plan documentation architecture for a project using the Diátaxis framework. Use when organizing documentation for a new project, restructuring existing documentation, or designing a documentation strategy.

Model deployment environments using C4 deployment diagrams and Structurizr DSL. Use when adding deployment views, modeling infrastructure, documenting production/staging environments, or mapping containers to infrastructure.

Create and evolve C4 architecture models with proper abstractions, diagram types, and notation. Use when adding elements to a C4 model, choosing diagram types, modeling relationships, or making architecture modeling decisions.

Review C4 architecture models for notation compliance, completeness, and common mistakes. Use when reviewing architecture PRs, auditing existing models, validating model quality, or before publishing architecture documentation.

Structurizr DSL syntax reference and patterns for writing C4 architecture models. Use when writing or editing workspace.dsl files, looking up DSL syntax, implementing specific patterns, or troubleshooting DSL errors.

This skill should be used when the user asks to "read an Obsidian note", "search my vault", "create a note in Obsidian", "append to my daily note", "list tags in Obsidian", "check my tasks", "open a file in Obsidian", "manage Obsidian plugins", "query a base", or any interaction with an Obsidian vault via the command line. Also triggered when the user mentions "obsidian", "vault", "daily note", or "Obsidian CLI".