メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
| name | tudla-dev-report |
| description | 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. |
| version | 1.0.0 |
Generate a Slack-ready standup report by fetching data from Tudla MCP tools and formatting it with the template in references/template.md.
Australia/Brisbane (AEST/AEST) timezone for all datetime boundariesmcp__tudla__list_user_changes with:
start_time: Previous business day 00:00:00+10:00end_time: Previous business day 23:59:59+10:00limit: 200mcp__tudla__list_projects to get all accessible projectsmcp__tudla__get_project to get full details (scopes, tasks, risk state, duration)Parse the changes output and classify into:
| Category | How to identify |
|---|---|
| Completed tasks | Task state changed to done → goes in "Yesterday's Wins" |
| In-progress tasks | Task state changed to in_progress or in_review |
| Blocked tasks | Task state changed to blocked → goes in "Blockers" |
| New tasks | Task was created (event: create, item_type: Task) |
| Updated scopes/projects | Risk state changes, estimate changes |
For completed tasks, include estimate vs actual duration if both are available.
Suggest a vibe emoji based on patterns in the data:
| Pattern | Suggested vibe |
|---|---|
| Many completions | :rocket: or :sunglasses: |
| Blocked items present | :thinking_face: or :hot_face: |
| Collaboration-heavy changes | :handshake: |
| Deep code/task work | :headphones: |
| Starting new epic/project | :rocket: |
Ask the user to confirm or change the vibe before proceeding.
Pre-populate "Today's Focus" from current Tudla state:
green → :large_green_circle:yellow → :large_yellow_circle:red → :red_circle:in_progress → :hammer:new (upcoming) → :soon:blocked → :construction:Present the draft to the user and ask them to confirm or adjust.
Assemble the final report following the template in references/template.md. Key rules:
:white_check_mark: not checkmark unicode)*bold*) and italic (_italic_) formattingmcp__tudla__list_user_changes — PaperTrail audit log for previous business daymcp__tudla__list_projects — All accessible projectsmcp__tudla__get_project — Project details with scopes/tasksmcp__tudla__list_tasks — Tasks filtered by project/state (for Today's Focus)