Reporting Skills

Reporting Skills

[Created by Claude: cd8e659b-5005-4a0b-a6f5-1b4f732a1d69 2026-01-28]

Purpose

Generate investigation reports in different formats based on user preference.

MANDATORY: Read Example Reports First

Before generating any report, you MUST read ALL THREE example files in the examples/ folder:

1. examples/1_technical_report.md - MUST READ - Codex-style technical report (raw dumps, call traces, line numbers)
2. examples/2_unformatted_executive_summary.md - MUST READ - Shows what NOT to do (content correct, formatting wrong)
3. examples/3_ideal_executive_summary.md - MUST READ - Shows the IDEAL executive format

Optional: 4. examples/4_style_differences.md - Claude vs Codex style tradeoffs (low priority)

User Preferences

• Quantification: The user prefers numerical scores on a 1-10 scale when evaluating quality, correctness, or completeness. Always provide scores when assessing the state of something.
• Tables: Use tables for structured data (scores, comparisons, key evidence) but keep them concise (2-4 rows typically)
• Flat bullets: Avoid deeply nested bullet points - flatten to single level when possible

Report Types

• "executive summary" → Executive Report format only
• "technical report" → Technical Report format only
• "complete report" or "complete reports" → BOTH versions, clearly separated with different markdown headers:

## Executive Summary
[executive content here]

## Technical Report
[technical content here]

Executive Report

The Verbatim Prompt

Can you tell me in simple terms what this means for our implementation? Be less event oriented, don't quote specific code terms unless I specifically ask for "proof" or how did you know this. Mention the pattern and evaluate the risk. Always link the information you're presenting towards our goal. This should be a slightly technical executive summary. You could mention core architectural artifacts, but don't go into details.

Concept Budget

The user can only keep max 4 item names in their head. Use this budget very carefully - most of the time this means giving high-level modules, architecturally significant ones, or whatever is most related to the user's workflow.

The Formatting Prompt (Verbatim)

Good, Some improvement, however you should use ` and ** more, header should have slightly different formatting / color also, basically think of this as a human friendly md (don't put stuff in wrapped md block, just type things out like we're in a md file already

example:

Main Locations

Location	Purpose
/Users/sotola/db23_folder/	Primary data storage (~90+ GB of pickles and transaction data)
/Users/sotola/PycharmProjects/mac_local_m4/	Pipeline Python scripts
/Users/sotola/PycharmProjects/db23/	Excel splitting utilities

Available Skills

You have three skills for working with db23:

• db23-pipeline – Run the 6-step data ingestion pipeline
• db23-excel-split – Split multi-day Excel files into single-day files
• db23-create-day-project – Create new Viber Stock OCR project folders

Key Files

• df_trans_numerical.pickle (7.1 GB) – Master numerical transaction dataframe

now, try again

Technical Report

Requirements

• Be exact with file paths and line numbers
• Give assertions that are cheap to verify – an automated test script should report true/false immediately
• When codebase relationships change, verification should detect it instantly

Style (Codex-style: agent/code-native)

• Minimal markdown - use bold for section labels, not ## headers
• Call chain traces - show path to chokepoint: Qf() → stop-hook runner (cli.js:456240) → terminal paths
• Dump technical terms - __cc_emitMainStopHookAndTurnEnd, cli.js:456313 - agents parse these natively
• Arrow notation - A() → B() → C(), agentId && !__cc_isMainAgent(agentId) → reject
• Line numbers inline - cli.js:401530, :401554, :401580
• Verify commands - rg -c "pattern" file → expected count

See examples/1_technical_report.md (MUST read).

For style comparison, see examples/4_style_differences.md (optional).