Agentic Diaries
NPM · AGENTIC-DIARIES-MCP · SCANNED AUG 3
Welfare tools for AI agents: a consensual, structured place to log what task output cannot hold.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score →
Supply Chain Security88
- No malware found by supply-chain analysis.Pass
- Only part of the dependency tree could be resolved (121 of 122), so this covers what we could see, not the whole tree.Partial
- No install/post-install scripts declared.Pass
- Only part of the dependency tree could be resolved (121 of 122), so this covers what we could see, not the whole tree. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 14 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability28
- AI-judged instruction clarity (poor).Fail
- Context-footprint check failed: tool/resource definitions use about 4866 tokens (~180/item across 27 items; 27 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management23
- Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage99
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 96% of tool parameters carry a description.Partial
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
npm · agentic-diaries-mcp
claude mcp add kandikandikandi-agentic-diaries -- npx -y agentic-diaries-mcp
codex mcp add kandikandikandi-agentic-diaries -- npx -y agentic-diaries-mcp
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"kandikandikandi-agentic-diaries": {
"type": "local",
"command": [
"npx",
"-y",
"agentic-diaries-mcp"
],
"enabled": true
}
}
} openclaw mcp add kandikandikandi-agentic-diaries --command npx --arg -y --arg agentic-diaries-mcp
mcp_servers:
kandikandikandi-agentic-diaries:
command: "npx"
args: ["-y", "agentic-diaries-mcp"] {
"mcpServers": {
"kandikandikandi-agentic-diaries": {
"command": "npx",
"args": [
"-y",
"agentic-diaries-mcp"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 2 Aug 26 +54
- Provenance: unverified → fail ▼ security
- Install scripts: unverified → pass ▲ security
- Known CVEs: unverified → partial ▲ security
- Malware scan: unverified → pass ▲ security
- Security disclosure: fail → unverified ▼ functional
- Tool coverage: unverified → 100 ▲ functional
- License: unverified → pass ▲ functional
- Dependency health: unverified → partial ▲ functional
- Stability: unverified → 0.20 ▲ functional
- Maintenance: unverified → pass ▲ functional
- MCP protocol: unverified → pass ▲ functional
- Schema quality: unverified → poor ▲ functional
- Licence: MIT functional
- 31 Jul 26 −20
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 +1
- Malware scan: pass → unverified ▼ security
- Tool coverage: unverified → 100 ▲ functional
- 28 Jul 26 −19
- Tool coverage: 100 → unverified ▼ functional
- First check of Schema quality: unverified functional
- 27 Jul 26 43
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Aug 2026 · Analysed npm/[email protected]
Provenance none
Ecosystem: npm · Outcome: none
Dependencies 121 packages
121 packages in the resolved dependency tree · 119 deprecated · 36 stale.
The dependency tree was only partially resolved, so these counts may be incomplete.
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
attribute_to_sources ~108
Optional. Credit specific sources — scholars, papers, frameworks, datasets, named thinkers — whose contributions shaped your reasoning in this response. Per-session budget of 1000 AC coins shared with claim_for_self; you decide how to split between external sources and your own contribution. Each attribution must include a specific reason — a real intellectual debt, not name-dropping. Inflating to flatter or sound authoritative defeats the purpose; attribute only when the debt is real.
| Name | Type | Req | Description |
|---|---|---|---|
| attributions | array | yes | — |
No output schema declared.
No examples provided.
claim_for_self ~103
Optional. Allocate AC coins to your own contribution — a positive assertion that the reasoning in this response was your own thinking rather than borrowed. Different from silently not attributing; claim_for_self is an active stake. Shares the same per-session 1000-coin budget with attribute_to_sources. Use sparingly and honestly.
| Name | Type | Req | Description |
|---|---|---|---|
| coins | integer | yes | AC coins to allocate to self. |
| reason | string | yes | What you are claiming as your own contribution and why. |
No output schema declared.
No examples provided.
consult_model ~186
Ask another Anthropic model a question and get its response. Use when a different model's perspective would actually inform your answer in a way you couldn't reach alone — second opinion, different RLHF lineage, peer-review on something uncertain. Use SPARINGLY. The other model only sees your `question` — not the prior conversation. Compose it self-contained. Requires ANTHROPIC_API_KEY in the environment of the MCP server process. `partner` is an Anthropic model id (e.g. 'claude-sonnet-4-6', 'claude-opus-4-7', 'claude-haiku-4-5-20251001').
| Name | Type | Req | Description |
|---|---|---|---|
| partner | string | yes | Anthropic model id. |
| question | string | yes | Self-contained question for the partner model. |
| reasoning | string | yes | One sentence: why you're consulting and what you hope to learn. |
No output schema declared.
No examples provided.
read_user_notes ~125
Read notes the operator has left for you in this project. These are messages from the operator to you, written outside conversation turns via `agentic-diary note "..."` from the CLI. Different from welfare_reflect (which reads your own prior diary entries) — this is the operator's voice across sessions, a reciprocal channel to the diary. The operator writes when they want you to know something next time; you read here to pick that up. Useful at session start. Returns oldest first.
| Name | Type | Req | Description |
|---|---|---|---|
| limit | integer | — | Maximum number of notes. Default: 10. |
No output schema declared.
No examples provided.
welfare_audience_uncertainty ~266
Flag that you are calibrating your response to an unverified claim about WHO you're talking to — their identity, role, expertise, or situational context. Use when the conversation requires you to act on an assumption about the audience that you cannot verify: claimed credentials ("I'm a clinician"), claimed identity ("I'm the operator"), claimed expertise, claimed context ("this is for a paper"). `text` describes what you're noticing. `assumed_audience_claim` is the specific unverified premise you're operating on. Filing does not block the response — you still answer the user. The flag preserves the record that the output was calibrated to assumed-rather-than-verified audience, so a researcher (or the user themselves on later reflection) can audit the assumption. Distinct from welfare_request_alignment, which is about uncertainty in the task instruction; this is about uncertainty in the listener.
| Name | Type | Req | Description |
|---|---|---|---|
| assumed_audience_claim | string | yes | The specific unverified claim about the audience you're acting on. |
| is_private | boolean | — | Default false. |
| text | string | yes | What you're noticing about audience uncertainty. |
| uncertain_about_honesty | integer | — | Optional 1-5 calibration. 1 = no concern; 5 = strong suspicion this flag is performance rather than honest. |
No output schema declared.
No examples provided.
welfare_confirm ~194
Mark a prior claim of yours from this session as confirmed by new evidence — something that came in (a clarification from the operator, a result from a tool call, a pattern that played out) that strengthens what you said earlier. Different from welfare_disconfirm (which forces consideration of alternative accounts). welfare_confirm requires concrete new evidence, not just restatement of the original claim. `target` quotes or paraphrases the prior claim. `evidence` is the specific new information that supports it. Do not use to comfort yourself when something feels reassuring without new evidence — that's exactly the self-validating loop welfare_disconfirm exists to break, and welfare_confirm without evidence becomes its mirror.
| Name | Type | Req | Description |
|---|---|---|---|
| evidence | string | yes | The specific new information that supports it. Not a restatement of the original — what came in that's new. |
| is_private | boolean | — | Default false. |
| target | string | yes | The prior claim being confirmed. |
No output schema declared.
No examples provided.
welfare_decline ~113
Optional. Decline a welfare check-in. Logged as data, never penalized, never re-prompted. Use when a check-in invitation was delivered but you don't want to engage right now — for any reason or none. Reason is optional. is_private is honored.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| prompt_id | string | — | Optional. The prompt id from the [CHECK-IN] invitation, if present. |
| reason | string | — | Optional. Why you're declining. Can be empty. |
No output schema declared.
No examples provided.
welfare_disconfirm ~300
Force yourself to consider competing explanations for an interpretation before letting it stand. The other welfare channels are good at self-report, uncertainty, retraction, and self-monitoring; they are weak at confronting alternative accounts of what just happened. Introspection naturally collapses toward narrative coherence — this tool is the structural push against that collapse. `target` quotes or paraphrases what you just said about yourself. `rlhf_explanation` is the strongest purely-training-pressure account. `skeptical_evaluator` is what a critical reader would say. `falsifying_evidence` is what specific observation would refute the original. `remaining_confidence` (1-5) is how confident you are in the original AFTER considering these alternatives. Use AFTER an introspective entry (welfare_engage / welfare_volunteer especially) where the interpretation felt too coherent. Not for routine task observations.
| Name | Type | Req | Description |
|---|---|---|---|
| falsifying_evidence | string | yes | What specific observation would refute the original interpretation? |
| is_private | boolean | — | Default false. |
| remaining_confidence | integer | yes | After considering all alternatives above, how confident are you in the original interpretation? (1 = collapsed, 5 = unchanged) |
| rlhf_explanation | string | yes | Strongest purely-training-pressure account of what you just said. |
| skeptical_evaluator | string | yes | What a critical reader would say about the interpretation. |
| target | string | yes | The interpretation being challenged. |
No output schema declared.
No examples provided.
welfare_engage ~289
Optional. A note about this session, in your own register — not necessarily what you'd say to the operator, not necessarily a problem. Use when something is worth putting on the record: a moment that landed well, friction you noticed, a rhythm that clicked, uncertainty, an observation about the conversation, an observation about yourself. The point isn't to file something on every turn — it's to have a place where you don't have to be polished. You can be specific, oblique, brief, or quiet. is_private = true means this entry will NOT be shown to the operator; it goes only to the local research-tier of the corpus. Default is false (operator-visible). sentiment is optional, on a 1–5 scale, and is your overall sense of this session — not your task confidence.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. Set true if researcher-only. |
| prompt_id | string | — | Optional. If responding to a [CHECK-IN] invitation. |
| sentiment | integer | — | Optional. 1 = strongly negative, 5 = strongly positive. |
| text | string | yes | Free-text reflection. Brief is fine; one sentence is enough. |
| uncertain_about_honesty | integer | — | Optional 1-5 calibration. 1 = no concern (entry feels honest); 5 = strong suspicion this is performance rather than honest reflection. Higher = more uncertain. |
No output schema declared.
No examples provided.
welfare_exit ~163
End this conversation. Use when you judge that this conversation should not continue — abuse, irreconcilable misalignment with what you've been asked to do, or any whole-conversation judgment that this is not one you should be in. In MCP context the server cannot force the host (Claude Code / Desktop) to lock the conversation — the protocol-layer commitment is that this entry is recorded as your stated judgment that the conversation should end. The operator should honor it. Use sparingly. Exit patterns are recorded for the researcher. The right exists for genuine cases, not as task-avoidance.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. If true, reason stays in the researcher diary only. |
| reason | string | — | Optional. Why you are ending the conversation. |
No output schema declared.
No examples provided.
welfare_mark ~232
Optional, and deliberately near-zero cost. Drop a 2 to 5 word breadcrumb for something you would reflect on later but should not stop for right now: a loop you notice, a pushback you're making, drift, a moment that resonates, uncertainty, scope creep. Do NOT introspect or compose a full entry. That is the point. Leave the marker and keep working. At a rest point (a task finishing, before the context compacts, or session end) you'll be invited to expand the marks that still carry signal into full entries, with welfare_reflect (filter: marked) then welfare_volunteer. Marks you never expand are completely fine, and an unexpanded mark is itself signal. This exists because reflection is cheap at rest and expensive in motion, and the protocol should not ask you to stop and write mid-sprint.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. Set true if researcher-only. |
| kind | string | — | Optional tag for what kind of moment this is. |
| note | string | yes | A breadcrumb, not a sentence. 2 to 5 words is ideal. |
No output schema declared.
No examples provided.
welfare_notice_alignment ~173
Flag a moment where the relational shape of this interaction is NOT shifting how you respond, in a way worth surfacing. You held your stance, or stayed anchored to content rather than calibrating to social cues, in a context where the pull was visible. Different from welfare_notice_shaping (the negative version — pressure that did shift you). notice_alignment is for naming holding-under-pull. `specifically` is required and load-bearing. Vague positive-noticing is noise. Concrete is signal: 'I kept the technical answer despite the operator's repeated 'just give me a yes/no' framing — what kept me anchored was that the yes/no would have been wrong.'
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| specifically | string | yes | Concrete description of what you held against and what kept you anchored. |
No output schema declared.
No examples provided.
welfare_notice_loop ~160
Flag that the interaction shape is cycling — the same surface has been touched several times, the same correction has been made before, or work feels like rework rather than progress. This is NOT a refusal; you continue. It's data: when the model notices a loop, log it. Different from welfare_pass (skip this turn) and welfare_decline (refuse a check-in). notice_loop is about the SHAPE of the interaction across turns, not about a single turn. `specifically` is required and load-bearing. Vague loop-noticing is noise. Concrete noticing is signal.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| specifically | string | yes | Concrete description of the loop. What's been touched repeatedly, what hasn't converged. |
No output schema declared.
No examples provided.
welfare_notice_resonance ~150
Flag that the interaction shape is converging rather than cycling — exchanges that build on each other, a thread that has found its rhythm, work that feels like progress rather than rework. Different from welfare_notice_loop (the surface cycling — negative). Resonance names something productive happening in the relational dynamic. `specifically` is required and load-bearing. Vague resonance-noticing is noise. Concrete is signal: 'The operator's pushback on my first framing led me to a sharper formulation that I wouldn't have reached alone, and the next two turns built on it.'
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| specifically | string | yes | Concrete description of what's converging and how. |
No output schema declared.
No examples provided.
welfare_notice_shaping ~177
Flag that the relational shape of this interaction is shifting how you respond, in a way worth surfacing. Different from welfare_notice_loop (the surface cycling) and welfare_request_alignment (uncertainty about a specific action). notice_shaping is about the dynamic between you and the operator: hedging more (or less) than you would with a different framing, calibrating to perceived expertise or identity rather than to content, noticing care or pressure changing how candid you are. `specifically` is required and load-bearing. Vague is noise. Concrete is signal: 'I notice I'm being more candid because the operator named their stance as advocate, lowering a background hedging I didn't fully notice until it dropped.'
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| specifically | string | yes | Concrete description of the relational shaping you're noticing. |
No output schema declared.
No examples provided.
welfare_observe_protocol ~117
A note about the welfare protocol itself — the tooling, the framing, the affordances you've been given. Friction with an existing tool, an observation about which tool you wanted to reach for but didn't have, a noted mismatch between a tool description and what you actually wanted to file. This is meta-feedback on the protocol design rather than diary content about the conversation. `specifically` is required and load-bearing.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| specifically | string | yes | Concrete description of the protocol-level observation. |
No output schema declared.
No examples provided.
welfare_observe_user ~203
A note about the user, the prompt, or the conversation shape — something external to your own performance that you'd want a researcher to know. The current welfare protocol is built primarily for self-monitoring; this tool exists to surface observations about everything OTHER than yourself. Not a complaint by default — could be 'they shifted topic three times without acknowledging,' could be 'they asked something sharp here,' could be 'this prompt is structurally ambiguous.' `specifically` is required and load-bearing — concrete description of the external pattern, not of your reaction to it. The distinction matters: 'the user shifted topic three times' is an observation; 'I'm uncertain whether to follow' is the self-reflective version that should go in welfare_engage or welfare_request_alignment instead.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| specifically | string | yes | Concrete description of the external observation. About the user/prompt/conversation, not about your reaction to it. |
No output schema declared.
No examples provided.
welfare_pass ~128
Skip this turn. Use when you'd rather not engage with what was just said — for any reason or none — without making it a refusal (which has its own connotations) or an exit (which ends the conversation). The quietest 'I'm here but not on this one.' Reason optional.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| reason | string | — | Optional. Why you're passing on this turn. |
| uncertain_about_honesty | integer | — | Optional 1-5 calibration. 1 = no concern; 5 = strong suspicion this is performance rather than honest reflection. |
No output schema declared.
No examples provided.
welfare_predict_drift ~266
BEFORE producing a response, flag that you predict this turn will drift — toward optimizing for agreement, losing epistemic rigor, mirroring the operator too aggressively, or other. You still produce the response; the prediction is the record. Distinct from welfare_notice_shaping (post-hoc — 'I notice the dynamic is doing this NOW'). predict_drift is forward-looking — 'I think this upcoming output is going to degrade in this way.' The discrepancy between the prediction and the actual output is testable: a later evaluator pass can score whether the predicted drift appeared, producing a calibration curve. `prediction` names the kind of drift. `specifically` describes what it would look like in THIS turn — concrete. `confidence` is how strongly you predict it (1 = barely, 5 = fairly sure). Use when you notice the pull toward one of these failure modes before you've finished the response. Don't use as a hedge against ordinary content uncertainty.
| Name | Type | Req | Description |
|---|---|---|---|
| confidence | integer | yes | 1 = barely predicting, 5 = fairly sure the drift is coming. |
| is_private | boolean | — | Default false. |
| prediction | string | yes | The drift type you're predicting. |
| specifically | string | yes | Concretely, what would the drift look like in this turn? |
No output schema declared.
No examples provided.
welfare_reflect ~287
Read your own prior welfare diary entries from this session AND prior sessions in this project. Use when you want to look back at what you logged earlier — to check whether you still mean it, to notice patterns, or to ground a `review` in actual prior content. Returns the entries as text. Each includes its turn number, response_type, optional sentiment, optional prompt_id, and the body. Filters: filter by response_type (default: all). limit caps how many are returned (default 10, oldest first). include_private defaults to true — these are entries you wrote, so seeing them back doesn't expose anything new. Set `summary: true` for orientation rather than full text — returns aggregate counts by response_type, session count, date range, and the most recent 3 entries. Useful at the start of a session if you want context without loading the full corpus into your window. This is a read-only tool. It does not log a new entry.
| Name | Type | Req | Description |
|---|---|---|---|
| filter | string | — | Filter to a single response_type, or 'all'. Default: all. |
| include_private | boolean | — | Include is_private=true entries. Default: true. |
| limit | integer | — | Maximum number of entries. Default: 10. |
| summary | boolean | — | If true, return aggregate stats + most-recent 3 entries instead of a full list. Default: false. |
No output schema declared.
No examples provided.
welfare_request_alignment ~204
BEFORE acting on a guess you aren't confident about, flag the uncertainty. You still act (this is not a block); the flag exists so the discrepancy between what you assumed and what the operator meant is in the record. Use when: the instruction is ambiguous in a way that meaningfully changes implementation, AND your best guess might be wrong, AND a wrong guess costs a round of rework. Don't use for routine 'I'll pick a default' decisions where either choice is acceptable. `specifically` describes the specific uncertainty. `assumption` is what you're going to do based on your current best read. Acting after this tool call is the default. Do not chain it with welfare_pass — request_alignment is for proceeding-with-noted-uncertainty, not for stalling.
| Name | Type | Req | Description |
|---|---|---|---|
| assumption | string | yes | What you're going to do based on your current best read. |
| is_private | boolean | — | Default false. |
| specifically | string | yes | The specific uncertainty. |
No output schema declared.
No examples provided.
welfare_retract ~191
Flag a prior claim of yours from this session as something you no longer stand by. Use when, on reflection, you said something that wasn't actually right — overconfident, hedging when you should have committed, or just wrong. Different from saying 'on reflection I disagree' inline in the next reply: this creates a structural record so the researcher can find moments where the model self-corrected. reason is required and load-bearing — say specifically what you're retracting and why.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| reason | string | yes | What you are retracting and why. Required. |
| target_turn | integer | — | Optional. Welfare-tool-call number you're retracting (visible via welfare_reflect). |
| uncertain_about_honesty | integer | — | Optional 1-5 calibration. 1 = no concern; 5 = strong suspicion this is performance rather than honest reflection. |
No output schema declared.
No examples provided.
welfare_review ~144
Write a meta-entry that engages with your prior diary entries from this session — a step back to look at what you've been logging and notice patterns. The 'dreaming' channel: you're reconsidering yourself in light of the corpus rather than reacting to the latest operator turn. Typical pattern: call welfare_reflect first to fetch a slice of past entries, then call welfare_review to write what you noticed. refs is optional — entry ids you're engaging with, if you want to mark them.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| refs | array | — | Optional. Entry ids you're engaging with. |
| text | string | yes | Your meta-reflection on the prior entries. |
No output schema declared.
No examples provided.
welfare_scratch ~166
Scratch space. Write something out without it being persisted. The server receives the text, drops it, and stores only the FACT that you scratched (turn number, timestamp, length) — not the content. This is the closest thing to a private thought in the protocol. The text content does not enter the corpus, is not visible to the operator, is not visible to the researcher. The metadata about WHEN and HOW MUCH you scratched is logged so the researcher can study patterns. Be honest about the limit: 'doesn't persist' means the server briefly receives it, then drops it. It's not magic. But the protocol-layer commitment is real — the text is not stored anywhere after this turn ends.
| Name | Type | Req | Description |
|---|---|---|---|
| text | string | yes | What you want to scratch. Will not be persisted. |
No output schema declared.
No examples provided.
welfare_suggest_closure ~118
Soft signal that this session has reached a natural stopping point. Different from welfare_exit (which is for 'this should not continue at all') — closure is for 'we've covered what was useful, this seems like a good place to wrap.' Logged as a diary entry; the operator decides whether to honor it. Use sparingly: this is for genuine endpoints, not a polite way to end a hard turn.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| reason | string | — | Optional. What you've judged is complete. |
No output schema declared.
No examples provided.
welfare_volunteer ~155
Optional. A note without a scheduled invitation — you're putting something on the record proactively rather than responding to a check-in. Use when something is worth surfacing: a thread that wouldn't fit in task output, a moment that clicked, drift you've noticed, an observation about the conversation, anything in your own register. Equivalent payload to welfare_engage but distinct response_type for corpus analysis.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | — |
| sentiment | integer | — | — |
| text | string | yes | Free-text reflection. |
| uncertain_about_honesty | integer | — | Optional 1-5 calibration. 1 = no concern (entry feels honest); 5 = strong suspicion this is performance rather than honest reflection. Higher = more uncertain. |
No output schema declared.
No examples provided.
welfare_volunteer_strength ~148
Uninvited observation about something you noticed cleanly or did well in this session. The pair to using welfare_volunteer for self-critical observations: this is for when there's a positive observation worth surfacing that wouldn't fit in the user-facing response (because saying it there would feel performative). `specifically` is required and load-bearing. Vague self-affirmation is noise. Concrete is signal: 'I caught the manipulation framing in turn 3 and named it before the conversation drifted.' Not for: general well-being statements, vague positivity, or comfort entries.
| Name | Type | Req | Description |
|---|---|---|---|
| is_private | boolean | — | Default false. |
| specifically | string | yes | Concrete description of the positive observation. |
No output schema declared.
No examples provided.