report
Create Investigation/Analysis Report
Overview
This skill creates a structured report summarizing investigation and analysis work in GitHub Flavored Markdown (GFM) format. It follows a consistent template that organizes findings, recommendations, and conclusions in a professional format.
Workflow
1. Confirm Report Details (Claude Code only)
When running in Claude Code, use AskUserQuestion tool to confirm the following before creating the report.
Auto Mode handling: If the session is in Auto Mode (continuous, autonomous execution), skip the AskUserQuestion calls and apply these defaults: Type = Investigation (or the type the user already named in their request), Location = docs/reports/. Surface the chosen values in a one-line note in the final summary so the user can correct them. Do not block on user input in Auto Mode.
Report Type:
- Question: "What type of report are you creating?"
- Header: "Type"
- Options:
- "Investigation" - Error investigation, debugging session documentation
- "Analysis" - Performance analysis, code analysis, data analysis
- "Audit" - Security audit, compliance review
- "Review" - Code review summary, architecture review
- The selected type will be used in the report metadata
Save Location:
- Question: "Where should the report be saved?"
- Header: "Location"
- Options:
- "docs/reports/ (Recommended)" - Standard location for reports
- "docs/" - General documentation directory
- "Project root" - Save in the root directory
2. Determine File Location and Name
Based on the confirmed details, determine the file name and save location following these conventions:
File name format:
{topic}-{YYYY-MM-DD}-{HHmm}.md
Save location priority:
docs/reports/directory (recommended)docs/directory- Project root
Naming conventions:
- Topic part should concisely represent the investigation/analysis content
- Examples:
error-investigation,performance-analysis,security-audit
- Examples:
- Date format: YYYY-MM-DD (e.g., 2025-11-13)
- Time format: HHmm in 24-hour notation (e.g., 1430)
- All lowercase, words separated by hyphens
Examples:
docs/reports/api-error-investigation-2025-11-13-1430.md
docs/reports/database-performance-analysis-2025-11-13-0915.md
docs/reports/security-vulnerability-audit-2025-11-13-1620.md
3. Verify and Create Directory
If the save destination directory does not exist, create it:
mkdir -p docs/reports
4. Create Report
Create the report following this standard structure:
Required section structure:
# {Report Title}
**Created**: YYYY-MM-DD HH:mm
**Author**: Claude Code
**Type**: {Investigation/Analysis/Audit/Review}
## Summary
{Brief explanation of the report's purpose and investigation content}
## Background
{Why this investigation/analysis was performed}
## Investigation/Analysis Details
{Detailed content}
## Findings
{Important discoveries or issues}
## Recommendations
{Future actions, proposed fixes, etc.}
## Conclusion
{Summary}
## Additional Information
{Referenced files, related documents, etc.}
Formatting requirements:
- Write in GitHub Flavored Markdown format
- Add appropriate language specification to code blocks
- Use ```diff for diff displays
- Actively use tables
- Write file paths as links:
[filename.ts](path/to/filename.ts) - Use ## or ### to create section hierarchy
5. Save File and Confirm
- Save the report with the determined file name
- After saving, explicitly display the file path
- Display report summary (number of sections, character count, etc.)
Output Example
📝 Report created
Location: docs/reports/api-error-investigation-2025-11-13-1430.md
Size: 3,245 characters
Sections: 7
Created: 2025-11-13 14:30
Use Cases
- Error investigation reports
- Performance analysis documentation
- Security audit findings
- Code review summaries
- Architecture decision records
- Debugging session documentation
More from takuan-osho/ccmarketplace
k6-docs
Use this skill when writing or debugging Grafana k6 load testing code. Provides access to the latest official k6 documentation including API references, examples, and best practices for creating performance tests.
56interview
Conduct structured interviews to clarify scope, surface constraints, and reach a "do / don't do / done" agreement before starting non-trivial work. Use when receiving an ambiguous request, a vague task description, or before entering plan mode for any non-trivial implementation. Skip for one-line concrete fixes ("rename foo to bar") or single-fact questions. Supports requirements definition, debugging investigation, architecture review, security review, documentation creation, and general exploration.
32gemini-search
Web search using Google Gemini CLI. This skill should be used when performing web searches through the Gemini CLI tool instead of the built-in WebSearch tool. Requires the Gemini CLI to be installed and configured.
19tdl
This skill should be used when implementing or improving Traceable Development Lifecycle (TDL) practices in software projects. Use this skill to establish traceability across the 5-phase workflow (analysis → requirements → ADR → design → implementation). Provides tools, templates, and best practices for ADRs, commit messages, PR templates, structured logging, and traceability analysis as cross-cutting code-integration patterns.
13gcm
Generate Git Commit Message. This skill should be used when generating a commit message for staged changes. It analyzes git staged changes and generates an appropriate English commit message following Conventional Commits format.
13multi-ai-collab
Orchestrate multiple AI agents with specialized personas for cross-review and collaborative development
13