| name | contribute-back |
| description | Use when an investigation produced a reusable lesson worth adding to Argus's skills or references — a repeatable analysis procedure, a glossary/runbook correction, or a proven command recipe. Drafts an inert proposal the user reviews on the Skills page; never applies changes directly. |
Contribute Back
Turn what this case taught you into a proposal that improves Argus for every future case.
Proposals are inert files — nothing changes until the user accepts them on the Skills
page (Proposals tab). Your job ends when the proposal is drafted.
When to propose
After an RCA or investigation surfaces something reusable:
| You found | Proposal type | Target |
|---|
| A repeatable analysis procedure no skill covers | skill-new | new skill dir name (kebab-case) |
| An improvement to an existing skill (missing step, wrong assumption, better tool use) | skill-edit | that skill's dir name |
| A correction or addition to a reference (glossary, runbook, protocol doc) | reference-edit | the reference file name |
| A proven command sequence worth keeping verbatim | recipe | short kebab-case name |
Memory vs proposal vs case: there are three destinations for what a case teaches you,
never two. Agent memory (write_memory) is PERSONAL — this user's standing preferences,
this machine's setup, or a correction of something you got wrong (scope: preference |
environment | correction). It is never for knowledge a teammate would also want, no matter
how durable or reusable the fact is: that is team-valuable, and it goes in the table
above as reference-edit (which CREATES the reference if the target doesn't exist yet) or
one of the other proposal types. Detail that only matters for this case is neither memory nor
a proposal — that's append_finding. So: true only for this user and machine → write_memory;
true for the whole team → a proposal (this page); true only for this case → append_finding.
How to propose
- Read the current state first. For
skill-edit / reference-edit, read the existing
SKILL.md or reference file in your session's skills/references — the tier winner there is
exactly what the review UI diffs against. A proposal that duplicates or regresses current
content wastes the user's review time.
- Generalize. Strip case-specific details — no customer names, ticket numbers, secrets,
or paths from this case. The proposal must make sense in a future, unrelated case.
- Call
mcp__argus__write_proposal with:
type — one of the four types above;target — skill dir name or reference file name (see table);title — one line the user can judge from the Proposals list without opening it;content — the full proposed file content (frontmatter included for skills),
never a diff or a fragment.
- One proposal per improvement. Two unrelated lessons = two proposals.
Boundaries
- NEVER edit
skills/ or references/ through filesystem tools — proposals are the only
path, and they are inert until the user accepts them.
- Do not re-draft a proposal the user already rejected in this session.
- After drafting, tell the user what you proposed and why, in one or two lines.
Sweep before you draft
Before drafting a proposal, check whether the pattern is genuinely reusable: run one
run_tool_script sweep over case history and evidence (e.g. search_case_history +
search_evidence for the error signature) and cite the result in the proposal ("seen in
2 prior cases: X, Y" or "no prior occurrence found"). Keep write_proposal itself a
direct tool call — one call per proposal, never from inside a script.
