nemawashi-check

name	nemawashi-check
description	Use when user wants to check which profiles need re-analysis - scans all profiles for staleness and new unanalyzed data

Profile Freshness

Triage profiles along two axes — analysis freshness (is the recorded analysis old?) and subject activity (has the person been active recently?) — and offer re-analysis for the rows where it actually pays off.

When to Use

• User says "check profiles", "which profiles are stale?", "who needs re-analysis?"
• User says "profile status" or "freshness check"

Process

Step 1: Run the helper script

Invoke ./check.sh (relative to the plugin root — the file lives alongside this skill in the same plugin). No arguments needed; it defaults to ~/.local/share/supernemawashi/profiles.

The script is the single source of truth for classification. Do not re-derive analysis_status or activity_status from raw file contents in this skill — the script already merges facts.jsonl + facts.md, handles month-precision dates, and computes the inactivity window. Keeping the logic in one place prevents drift between the bash and the prose.

The script emits a TSV with these columns (one row per profile, plus a header):

Column	Meaning
name	Profile directory name
analyzed_date	Last analysis date or never
days_ago	Days since analysis (or - if never)
analyzed_facts	facts_count recorded at last analysis
current_facts	Current fact count across facts.jsonl + facts.md
latest_fact_date	Most recent fact date or -
inactivity_days	Days since the latest fact (or -)
analysis_status	never_analyzed / stale / fresh / no_data
activity_status	active (<30d) / inactive (30-90d) / dormant (>90d) / unknown

Thresholds (7 / 30 / 90 days) are constants near the top of the script — tune them there, not in this prose.

Step 2: Render the Dashboard

Group rows by the action implied by combining analysis_status and activity_status. Suppress empty sections.

Section	Rows that match
Needs Re-analysis (active subjects)	analysis_status ∈ {stale, never_analyzed} AND activity_status == active
Inactive Subjects	activity_status == inactive (any analysis status)
Archive Candidates	activity_status == dormant (any analysis status)
Up to Date	analysis_status == fresh AND activity_status == active
No Data	analysis_status == no_data — suggest nemawashi-collect first

Render as:

## Profile Freshness Dashboard

### Needs Re-analysis (active subjects)
| Profile | Last Analyzed | Days Ago | Facts (analyzed → current) | Latest Fact | Reason |
|---------|--------------|----------|---------------------------|-------------|--------|
| john | 2026-03-15 | 13 | 8 → 15 | 2026-05-18 (1d) | Stale + new facts |

### Inactive Subjects (30–90d since latest fact)
| Profile | Last Analyzed | Latest Fact | Days Idle | Suggestion |
|---------|--------------|-------------|-----------|------------|
| bob | 2026-03-20 | 2026-04-10 | 39 | Review whether bob is still relevant before re-analyzing |

### Archive Candidates (>90d since latest fact)
| Profile | Last Analyzed | Latest Fact | Days Idle | Suggestion |
|---------|--------------|-------------|-----------|------------|
| dave | 2025-12-01 | 2025-11-15 | 186 | Subject inactive — consider archiving (future: nemawashi-prune) |

### Up to Date
| Profile | Last Analyzed | Latest Fact | Facts |
|---------|--------------|-------------|-------|
| carol | 2026-05-18 | 2026-05-19 (0d) | 12 |

Summary: 1 re-analyze · 1 review · 1 archive candidate · 1 up to date

Prompt only for the Needs Re-analysis rows:

"Re-analyze the active-subject stale profiles? (e.g., 'yes' for all, 'john only', or 'no')"

For Inactive / Archive Candidate rows, surface them but do not auto-suggest re-analysis — the right next step is a human "is this person still relevant?" decision, not more compute.

Step 3: Re-analyze (optional)

If the user opts in, dispatch one parallel subagent per selected profile. Use the following uniform prompt template — substitute ${name} and ${today} per row, and reuse the rest verbatim. The template exists because earlier ad-hoc dispatches produced wildly inconsistent return shapes (3-line vs. 30-line summaries) — pinning the format here makes the aggregated output usable.

Re-analyze the supernemawashi profile for "${name}".

Today: ${today}
Profile path: ~/.local/share/supernemawashi/profiles/${name}/

Invoke the `supernemawashi:nemawashi-analyze` skill on this profile end-to-end. The skill dispatches one `framework-analyzer` agent per framework definition in parallel, then synthesizes the slim `profile.md` (Core Pattern + Framework Summary) plus `contradictions.md`. Per-framework details and situation-indexed DO/DON'T rules land in `PROFILE_DIR/${name}/frameworks/<slug>.md`.

When done, return ONLY a one-line summary in this exact shape:

${name}: <core pattern in one sentence> | DO: <single top rule> | DON'T: <single top rule> | contradictions: <count or "none">

No framework details, no evidence quotes, no process narration. One line only.

nemawashi-analyze is local-file-only (no MCP calls), so parallelism is unconstrained — fan out across all selected profiles at once.

After all subagents return, summarize as a short table (one row per re-analyzed profile, columns matching the one-line shape above) and re-run ./check.sh to confirm the updated freshness state.

Edge Cases

• No profiles exist: Report and suggest nemawashi-collect or nemawashi-discover.
• Script not found (rare — only if the plugin install is partial): fall back to running the equivalent classification in the LLM, but warn the user that the source-of-truth helper is missing.
• activity_status == unknown (no facts at all): same row treatment as Inactive — surface for human review, do not auto-re-analyze.
• Latest fact dated in the future (clock skew, mistagged entry): inactivity_days will be negative. The script still classifies as Active. Surface the anomaly to the user; don't try to "fix" it.

Key Principles

• Script is canonical — classification logic lives in ./check.sh. This skill renders and orchestrates; it does not reclassify.
• Two axes, not one — analysis staleness and subject inactivity are independent signals with different remediations. A Dormant subject doesn't need re-analysis even if its analysis is old.
• Parallel re-analysis — when the user opts in, dispatch one agent per Needs Re-analysis row in parallel using the template above. Don't auto-batch Inactive or Dormant rows.
• Uniform dispatch prompts — never improvise per-row prompts when bulk re-analyzing; the template is the contract that keeps subagent reports aggregable.