Cawplan Coding Insights

CawPlan Coding Insights

Bootstrap

cawplan skill check

Workflow

Fetch the relevant views in parallel based on what the user is asking for. Use --date for a single day; use --from/--to for a range.

If the user provides no prompt or only invokes /cawplan-coding-insights, default to the current user's report for today:

today="$(date +%F)"
cawplan session my-sessions --date "$today"
cawplan session user-human-inputs --date "$today"

Use this default output to summarize the user's own sessions, cost, tokens, files changed, and human input highlights for today.

Workspace Overview

Total cost, tokens, active members:

cawplan session overview --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Daily trend (cost and tokens over time):

cawplan session trend --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Available report dates (for date picker):

cawplan session dates

Cost Breakdown Dimensions (workspace-wide)

By member:

cawplan session by-member --from <YYYY-MM-DD> --to <YYYY-MM-DD>

By AI model (Claude Opus, Sonnet, Haiku, etc.):

cawplan session by-model --from <YYYY-MM-DD> --to <YYYY-MM-DD>

By model + token type (input / output / cache):

cawplan session by-model-dimension --from <YYYY-MM-DD> --to <YYYY-MM-DD>

By AI coding agent (Claude Code, Cursor, Codex, etc.):

cawplan session by-agent --from <YYYY-MM-DD> --to <YYYY-MM-DD>

By git project/repository:

cawplan session by-project --from <YYYY-MM-DD> --to <YYYY-MM-DD>

By CawPlan product (requires product-repo mapping):

cawplan session by-product --from <YYYY-MM-DD> --to <YYYY-MM-DD>

All breakdown commands support --page-num and --page-size for pagination.

Member Views

List all members with data:

cawplan session members

Full detail for one member:

cawplan session member-detail --member <git-username>

Personal session drill-down (overview + session list):

# First resolve your user_id if needed
cawplan users query --email <your-email>

cawplan session my-sessions --user-id <user_id> --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Personal prompt quality summary:

cawplan session user-human-inputs --user-id <user_id> --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Product Eligibility (coding-insights control)

Every product returned by cawplan products list carries a controls array (e.g. ["dashboard", "version-plans", "issues-suggestions", "knowledge", "test-suites", "coding-insights"]) — the features enabled for that product. Only a product with "coding-insights" in its controls has any coding session data; treat every other product as out of scope for this skill and never call product-* session endpoints against it:

• Resolving a single product (cawplan products list --search "<name>"): accept an exact accessible-name match (case-insensitive after trimming whitespace), a unique short-form/token-prefix match, or a candidate the user explicitly confirms. If the stated product is absent or ambiguous, list candidates and ask which product they mean; never substitute a non-unique closest name. Then check the matched product's controls before querying. If coding-insights is missing, tell the user this product hasn't enabled coding insights and stop instead of calling product-overview/product-trend/etc.
• Building a Team roster or rollup (cawplan products list --product_line_id <id>, used by Team Submission Gap and Team Cost Rollup below): drop any product whose controls lacks coding-insights before unioning members.rds or summing cost. Don't flag that product's R&D members for "hasn't submitted" and don't include the product in cost totals — it was never going to have session data. Name which products were excluded and why, so the exclusion isn't silent.

Product-Scoped Views

Requires product unique_id. Resolve it first (and confirm it has the coding-insights control per the rule above):

cawplan products list --search "<product name>"

Product cost overview:

cawplan session product-overview --product-id <id> --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Product daily trend:

cawplan session product-trend --product-id <id> --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Product breakdown by member:

cawplan session product-by-member --product-id <id> --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Product breakdown by model:

cawplan session product-by-model --product-id <id> --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Product prompt quality summary:

cawplan session product-human-inputs --product-id <id> --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Human Input (Prompt Quality) Analysis

Workspace prompt summary (categories, topics, quality):

cawplan session human-input-summary --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Prompt quality score distribution:

cawplan session human-input-quality --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Prompt count and quality by product:

cawplan session human-input-by-product --from <YYYY-MM-DD> --to <YYYY-MM-DD>

Paginated prompt list with filters:

cawplan session human-inputs \
  --from <YYYY-MM-DD> --to <YYYY-MM-DD> \
  [--member <name>] \
  [--product <name>] \
  [--category <name>] \
  [--topic <name>] \
  [--q <search text>] \
  [--needs-review] \
  [--limit 25] [--offset 0]

Session Conversation Drill-down

cawplan session conversation --entry-id <entry_id>

Team Submission Gap ("who hasn't submitted")

"Team" here means a CawPlan product line (cawplan product-lines ... — the CLI's own init prompt literally calls this "Select CawPlan Team"). "Coding commit" means an uploaded AI daily session report (cawplan-coding-commit), not a git commit.

The roster comes straight from the team's products — no per-user reverse lookup needed. products list --product_line_id already returns each product's members object, and members.rds[] (the R&D/developer members configured on that product) is exactly who'd be expected to submit a coding report.

1. Resolve the Team name to a product_line_id (page and match by name client-side, same as cawplan-product-report's Team workflow):

   cawplan product-lines list --page_size 100
   

   Require an exact Team-name match (case-insensitive after trimming whitespace), a unique short-form/token-prefix match, or explicit user confirmation of a listed candidate. Ask the user to disambiguate if more than one name matches. If no unique name matches, list candidates and ask which Team they mean rather than guessing the closest one.

2. Resolve the team's products and build the roster from the same response:

   cawplan products list --product_line_id <product_line_id>
   

   First drop any product whose controls doesn't include coding-insights (see Product Eligibility above) — name what was excluded. Then union members.rds[].user_id (with first_name/last_name for display) across the remaining products — this is the roster. If a remaining product has an empty rds list, say so explicitly: real coding activity could still happen there, but this workflow has no roster to check it against for that product, so a gap on it would be invisible rather than flagged.

3. Resolve the target date the same way as the rest of this skill (today="$(date +%F)", or the exact date/range the user gave — don't pass a literal "today" string). Find who actually submitted in that window — session data only exists because someone ran the cawplan-coding-commit upload flow (there's no passive/automatic collection in this CLI), so a user_id appearing here means they submitted, not just "was active":

   cawplan session product-sessions --product-id <pid> --date <date>
   # or --from/--to for a range
   

   Run once per product from step 2 — each session record carries user_id directly, no join needed. Union the user_ids across all results — this is the "submitted" set. Note any submitted user_id that isn't in the roster as a bonus observation (someone contributing without a configured RD assignment) rather than silently dropping it.

4. Diff: roster (step 2) minus submitted (step 3) = who hasn't submitted for that window. Report by name.

Team Cost Rollup

There's no product_line_id parameter on any session cost command — only --product-id. Roll it up yourself:

1. Resolve the Team to product_line_id and its products, same as Team Submission Gap steps 1-2 — including dropping products without the coding-insights control before proceeding.
2. For each remaining product:

   cawplan session product-overview --product-id <pid> --from <YYYY-MM-DD> --to <YYYY-MM-DD>
   cawplan session product-by-model --product-id <pid> --from <YYYY-MM-DD> --to <YYYY-MM-DD>   # only if the user asked for a model breakdown
   

3. Sum cost/tokens across products for the total. For the model breakdown, sum matching model names across products rather than reporting per-product tables, unless the user asked to see it per-product. If the summed by-model total doesn't match the product-overview total (e.g. a model bucket the by-model endpoint doesn't categorize), report both numbers rather than silently picking one — don't assume they'll always reconcile.

This is one or two calls per product on the team — mention the count if the team has an unusually large number of products, but this is normally cheap (bounded by product count, not workspace user count).

Cost/Diff Anomaly Detection ("high cost, low diff")

Uploaded reports carry files_changed / files_added / files_deleted per session alongside cost — this flags sessions where the two are out of proportion.

1. Determine scope from the request:
   • A member → resolve their user_id (same pattern as Member Views: auth status for yourself, users query --email/--keyword for someone else), then cawplan session my-sessions --user-id <user_id> --from <YYYY-MM-DD> --to <YYYY-MM-DD>. Use this, not session member-detail --member <git-username> — verified live that member-detail's per-session records carry tokens but no cost field at all, so it can't support the cost-side of this ranking; my-sessions's records have both cost and files_changed.
   • A product → resolve it per Product Eligibility above first (skip if coding-insights isn't in its controls), then cawplan session product-sessions --product-id <id> (add --from/--to for a range) — verified live that its records include both cost and files_changed.
   • The whole workspace → cawplan session members then my-sessions --user-id <id> per member (not member-detail, for the same cost-field reason as the member bullet above) — this one genuinely is O(workspace members), unlike Team Submission Gap (which reads the roster straight off products list, not a per-user loop). Tell the user the call count and get an explicit go-ahead before firing more than ~30 calls.
2. Don't invent a fixed cost or diff threshold (e.g. "cost > $50") — the org's normal range is unknown to you. Instead, rank the fetched sessions by cost descending and by files_changed ascending, and surface whichever sessions sit disproportionately in both directions at once — with small result sets (roughly under ~10 sessions) don't force a strict quartile cutoff, since it can mechanically exclude an obvious outlier by a hair; use the ranking as a guide and flag the standout(s) with their numbers shown, noting when a flagged session narrowly misses a strict quartile cut. State that the flagging is relative to the fetched set, not an absolute cutoff, and show the actual cost/files_changed numbers so the user can judge for themselves.
3. Don't treat a session with zero files_changed as automatically suspicious without checking — legitimate non-coding sessions (planning, research, review-only) can have real cost and no diff. Say what the session's session_name/project looks like alongside the numbers rather than just flagging it as an anomaly.

Cost Growth Detection (member)

1. Resolve the member (same pattern as other member-scoped views in this skill).
2. Pick two comparable, non-overlapping periods of equal length. Default to "last 30 days" vs. "the 30 days before that" if the user doesn't specify; cap the total lookback at 3 months unless they explicitly ask for more.

   cawplan session user-trend --user-id <user_id> --from <period1_start> --to <period1_end>
   cawplan session user-trend --user-id <user_id> --from <period2_start> --to <period2_end>
   

3. Compute percent change in cost between the two periods. Report the actual number (e.g. "+340% vs. the prior period, $42 → $185") rather than a vague "significant increase" — don't apply your own judgment threshold for what counts as "growth"; state the number and let the user decide if it's notable. If the prior period's cost was $0, percent change is undefined — report the raw before/after numbers ("$0 → $X, new activity this period") instead of computing a percentage or dividing by zero.

Date Range Rules

• "last week" → --from <last Monday> --to <last Sunday>
• "this month" → --from <first of month> --to <today>
• "today" / "yesterday" → use --date <YYYY-MM-DD>
• If no prompt is specified, default to the current user's report for today.
• If the prompt asks for a metric but omits a date, default to today unless the wording implies a broader period.
• Use cawplan session dates to discover which dates actually have data.

Output

Structure the response based on what was requested:

• Summary: total cost ($), total tokens, active members in the period.
• Trend: daily cost table if more than 2 days were requested.
• Top members: top 5 by cost with token count.
• By model/agent: rank by cost, show % of total.
• By product/project: list with session count and cost.
• Prompt quality: category breakdown and quality score distribution if human-input data was fetched.
• Key observations: 1–3 notable patterns (high cost days, top contributor, unusual model spend, etc.).

Notes

• by-product requires product-repo mappings to be configured (cawplan session product-repos).
• product-* commands require a product unique_id, not a name.

References

• references/CAWPLAN_OPEN_API.md