菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | tudla-report-analyzer |
| description | 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. |
| version | 1.0.0 |
Analyze a user's Tudla reports against quality criteria and cross-reference with actual project/task activity data. Produces a structured evaluation with ratings, verified/unverified claims, and actionable recommendations.
start_time and end_time in ISO8601 with +10:00 (Australia/Brisbane). Default: past 7 calendar days from todaymcp__tudla__fetch_reports_tool with team_id: 1 (R&D default) and the computed date rangemcp__tudla__get_report_tool to get full content{id, content, as_of_at, reportable_type, reportable_name, status}mcp__tudla__list_user_changes_tool with team_id: 1 and the same date range, limit: 200. Filter output for changes by the target usermcp__tudla__list_projects_tool to get all projectsmcp__tudla__get_project_tool for scope/task/risk detailsEvaluate each report against the 7 criteria defined in references/criteria.md:
| # | Criterion | What to check |
|---|---|---|
| 1 | Progress visibility | Are completions clearly stated? Match against done transitions in audit log |
| 2 | Task specificity | Are exact Tudla task names used, or vague descriptions? |
| 3 | Estimate tracking | Are Est vs Actual figures included? Match against task ai_assisted_estimate / actual_manhours |
| 4 | Blocker identification | Are blockers called out with context? Match against blocked state transitions |
| 5 | Project alignment | Do mentioned projects/tasks exist in Tudla? Any significant audit log activity omitted? |
| 6 | Consistency | Count reports vs expected business days in range. Note gaps |
| 7 | Forward-looking | Does report mention upcoming tasks? Verify they exist in new/in_progress state |
Rate each criterion: Strong / Adequate / Weak / Missing
Cross-reference findings:
Format the output as follows:
## Report Analysis: [User Name]
**Period:** [start] to [end]
**Reports reviewed:** X of Y expected
### Overall Rating: [Strong / Adequate / Needs Improvement / Poor]
### Criteria Breakdown
| Criteria | Rating | Notes |
|----------|--------|-------|
| Progress visibility | ... | ... |
| Task specificity | ... | ... |
| Estimate tracking | ... | ... |
| Blocker identification | ... | ... |
| Project alignment | ... | ... |
| Consistency | ... | ... |
| Forward-looking | ... | ... |
### Cross-Reference Findings
**Verified claims:** [list]
**Unreported activity:** [list]
**Unverified claims:** [list]
### Recommendations
1. [Specific, actionable recommendation]
2. ...
After outputting the analysis, ask the user if they want to drill into any specific report or criterion.
| Condition | Rating |
|---|---|
| 5+ criteria Strong, none Weak/Missing | Strong |
| 3+ criteria Strong or Adequate, at most 1 Missing | Adequate |
| 2+ criteria Weak or 1+ Missing | Needs Improvement |
| 3+ criteria Weak/Missing | Poor |
mcp__tudla__fetch_reports_tool — Fetch reports by date range, team, and usermcp__tudla__get_report_tool — Get full report content by IDmcp__tudla__list_user_changes_tool — PaperTrail audit log for cross-referencingmcp__tudla__list_projects_tool — All accessible projectsmcp__tudla__get_project_tool — Project details with scopes, tasks, risk statemcp__tudla__list_tasks_tool — Tasks filtered by project/stateUse 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.