tudla

Use when the user wants verification evidence for a branch or uncommitted changes — screenshots of the actual resulting UI states, captioned with what each one demonstrates, plus a markdown evidence report — to attach to a PR or bug report. Captured via chrome-devtools MCP; optional combined walkthrough GIF assembled with ffmpeg for multi-step flows. Output lives under tmp/evidence/<slug>/ (gitignored) and is never committed.

Use when the user wants to ship release notes for the work on the current branch with an accompanying demo GIF. Audits the branch's changes vs its base, records a short walkthrough of the new behaviour via the record-change-evidence capture pipeline, and writes a dated markdown release notes doc under docs/release_notes/. Tudla has no in-app changelog UI, so the deliverable is a docs artefact, not a wired-up modal.

This skill should be used when the user asks to "write a spec", "add tests", "test this model/policy/service/tool", "raise coverage", "create an rspec test", or any task involving authoring RSpec tests in the Tudla (Rails 8.1) codebase. Encodes project conventions for factories, the UserPartyRole access hierarchy, Statesman state machines, Pundit, Devise, soft delete, estimate caching, MCP tools, ViewComponents, and PaperTrail so new specs match house style and run cleanly under Docker.

Iteratively runs the comprehensive-spec-writer agent on a single spec file up to 5 times until the spec receives a PASS verdict. Reports all work done in each iteration and the final result. Trigger when the user asks to "iterate on a spec until it passes", "keep fixing this spec", "run comprehensive-spec-iterator on", or "comprehensively fix this spec".

Review RSpec tests for meaningfulness, correctness, and assertion quality. Use this skill after writing or generating RSpec tests for the Tudla Rails application. Trigger whenever the user asks to review tests, audit test quality, check if tests are meaningful, validate rspec coverage, or mentions concerns about "weak assertions", "dubious tests", "fake coverage", "tautological specs", or "tests just to pass". Also trigger when the user says things like "review the tests you just wrote", "are these tests actually good", "check test quality", or "make sure the specs are real". This skill is specifically about evaluating whether tests verify real application behavior — not about writing tests from scratch.

Orchestrates a full RSpec spec-quality audit across the project. Triggers when the user asks to "review all specs", "audit test quality", "run the spec review checklist", "continue spec review", or "resume spec review". Builds and maintains a resumable checklist at `spec_review_checklist.md`, then spawns the `spec-reviewer` sub-agent once per spec file (sequentially, one at a time) and appends each verdict to the checklist. Designed to survive interruptions — rate limits, context exhaustion, or the user just closing the terminal.

Use when the user asks to "analyze report", "critique report", "review report", "report quality", or "report analysis". Analyzes a user's Tudla reports against quality criteria and cross-references with actual project/task data.

Use when the user asks for a "daily report", "standup update", "dev daily", "yesterday's changes", or "daily update". Generates a formatted Dev Team Daily report from Tudla data.