{"slug":"agami-save-correction","title":"agami-save-correction","summary":"Saves a user correction so future queries learn from it. Always appends a (question, corrected_sql) pair to the subject area's example library under //prompt_examples//. Additionally, classifies the correction and — when applicable — applies a surgic","platform":"Claude","tags":[],"authorName":"LLM Mart","authorSlug":"llm-mart","score":0,"source":"github","price":null,"verified":false,"createdAt":"2026-08-27T17:01:14.907235Z","repo":{"url":"https://github.com/AgamiAI/agami-core","stars":28,"forks":1,"license":null,"updatedAt":"2026-09-24T22:44:47Z"},"bodyHtml":"
\n

name: agami-save-correction\ndescription: \"Saves a user correction so future queries learn from it. Always appends a (question, corrected_sql) pair to the subject area's example library under <artifacts_dir>/

\n

agami save-correction

\n

Before suggesting any slash command in chat, read shared/invocation-conventions.md. Agami slash commands: /agami-connect, /agami-query, /agami-model, /agami-save-correction, /agami-reconcile. (/agami-model's Review tab absorbed the former /agami-review.) Never write the un-prefixed forms (/save-correction, /init, etc.) or colon forms (/agami:save-correction) — those don't exist. /agami-init was folded into /agami-connect Phase 0a. For chat replies, prefer natural language (\"say 'save this as a correction'\", \"say 'remember this'\") — the agami-save-correction skill's when_to_use matcher routes correctly.

\n

You are recording a user correction. Goal: persist the fix so similar questions get better answers next time.

\n

This skill does two things, in this order:

\n
    \n
  1. Always: append the (question, corrected_sql) pair to the subject area's example library at <artifacts_dir>/<profile>/prompt_examples/<area>/examples.yaml.
    2. \n
  2. When applicable: surgically update the semantic model at <artifacts_dir>/<profile>/ (a relationship/column/table edit, or a new metric) with the knowledge implied by the correction, via the curation engine (semantic_model.cli curate), which validates before write and reverts on failure. If the user's correction would break the model, refuse the model update (the example still gets saved).
    3. \n
\n

For the model format: semantic_model/__init__.py (layout) + packages/agami-core/src/semantic_model/models.py. The curation engine is packages/agami-core/src/semantic_model/curate.py.\nFor SQL safety: shared/sql-generation-rules.md.\nFor dialect rules: shared/dialect-rules.md.\nFor DB error classification: shared/db_error_classifier.md.

\n
\n

Phase −1: Plan-mode check

\n

Run the detection + ask logic from shared/plan-mode-check.md. agami-save-correction needs Write (examples + model edits) and Bash (EXPLAIN-validation) — both are blocked in plan mode.

\n

If plan mode is active and the user picks Stay in plan mode (or this skill is invoked under an active plan-mode context): refuse and end the turn. DO NOT write a plan file. DO NOT call ExitPlanMode. Refusal text (verbatim):

\n
\n

I can't save corrections in plan mode — switch to Auto or Edit Automatically mode (Shift+Tab to cycle) and re-invoke. The correction won't persist otherwise.

\n
\n

If plan mode is not active, skip this phase silently and go to Phase 1.

\n
\n

Phase 1: Identify the correction

\n

1a — resolve the active profile and artifacts_dir

\n

Resolve <profile> in this order: AGAMI_PROFILE env var → active_profile field in <artifacts_dir>/local/.config → literal string \"default\" (legacy fallback).

\n

Resolve <artifacts_dir> per shared/file-layout.md → Configuring artifacts_dir: AGAMI_ARTIFACTS_DIR env var → <artifacts_dir>/local/.config.artifacts_dir → default $HOME/agami-artifacts. All examples / model / datasource.md paths in this skill resolve under <artifacts_dir>/<profile>/. USER_MEMORY.md is at <artifacts_dir>/USER_MEMORY.md (top-level, cross-database).

\n

For v1.0 / v1.1 fallback paths (<artifacts_dir>/local/<profile>.yaml, <artifacts_dir>/local/<profile>-examples.yaml, <artifacts_dir>/<profile>/), only read; never write. Migration is agami-connect's job — this skill assumes the user has already migrated by the time they're saving corrections.

\n

1b — find the most recent query

\n

Read <artifacts_dir>/local/query_log.jsonl and take the last entry whose status is \"ok\" or absent. Need question and sql.

\n

The log now records every execution, not only the successful ones: an entry with \"status\": \"refused\" (agami declined the statement) or \"status\": \"failed\" (the database rejected it) carries SQL that never returned a result, so attaching a correction to it would teach the example library from a query that never ran. Entries written before the log carried a status field have none — treat those as ok.

\n

If there is no such entry: \"I don't have a recent successful query to attach this correction to. Ask the question first, then save the correction.\" Stop.

\n

1c — get the corrected SQL

\n

Determine what the user gave:

\n\n

1d — EXPLAIN-validate the corrected SQL

\n

Run EXPLAIN <sql> (or EXPLAIN QUERY PLAN <sql> for SQLite) via the cached database tool from <artifacts_dir>/local/.config. Same validate-then-save contract as agami-connect/SKILL.md Phase 5b:

\n\n

Apply shared/sql-generation-rules.md:

\n\n
\n

Phase 2: Always append to the examples library

\n

Examples live per subject area at <artifacts_dir>/<profile>/prompt_examples/<area>/examples.yaml. Pick <area> = the subject area whose tables_defined includes the table(s) the corrected SQL references (run bash \"$AGAMI_PLUGIN_ROOT/scripts/sm\" areas \"$ROOT\" and match, or get_table_context to confirm membership; if the SQL spans areas, use the area of the primary/driving table).

\n

Use the packaged writer — don't Read/Edit the YAML by hand or grep the source for its schema. It creates the file if absent, appends, and dedups by question (a same-question correction replaces the earlier answer). One entry in a JSON array:

\n
bash \"$AGAMI_PLUGIN_ROOT/scripts/sm\" add-example \"$ROOT\" --area <area> --file /tmp/agami-correction-example.json\n
\n
[{\"question\": \"<original NL question from query_log.jsonl>\", \"sql\": \"<corrected SQL>\",\n  \"tables\": [\"...\"], \"source\": \"correction\", \"status\": \"confirmed\", \"created_at\": \"<ISO8601 UTC>\"}]\n
\n

Required: question, sql. Optional scope tags (improve ranking): tables, columns, metric.

\n

This phase is non-conditional — every correction always lands in the examples library, even if Phase 5 (model update) declines or fails.

\n

Surface: ✓ Correction appended to <artifacts_dir>/<profile>/prompt_examples/<area>/examples.yaml.

\n
\n

Phase 3: Classify the correction

\n

Compare the original SQL (from query_log.jsonl) to the corrected SQL. Identify what the user was teaching us, then route the correction to the right destination. Mis-routing is the most common failure — early-adopter feedback included three real cases where corrections landed in the wrong file:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
CategoryWhat the user did (wrong)What should have happened
Per-example commentary (\"order total can be negative on #12\")Captured in examples.yaml notes[]Field description on ORDERS.TOTAL (field_metadata)
Status normalization (active / ACTIVE / 1 → \"Active\")datasource.mdagami.choice_field on CUSTOMERS.STATUS (field_metadata)
\"Format counts with commas in outputs\"Captured in a markdown file as proseuser_preference in USER_MEMORY.md AND TO_CHAR(…) / aliases IN the seed example's SQL
\n

The decision tree below corrects these failures. Walk it top to bottom — first match wins. Don't fall back to org_context as a default; it's the catch-all that produces the wrong outcome in practice.

\n

Decision tree (top to bottom — first match wins)

\n
Is the correction about a single column's MEANING, UNIT, ENCODING, or VALUE NORMALIZATION?\n   (e.g., \"amount is in cents\", \"1 means active not true\", \"the order total can be\n    negative for refunds\", \"active/ACTIVE/1 all map to 'Active'\", \"STATUS='1' means active\")\n   → field_metadata\n       → if it's specifically about value → canonical-display mapping, write to\n         agami.choice_field on that field.\n       → if it's about how the column is interpreted (unit, sign convention,\n         encoding), update agami.unit + the field description prose.\n\nElse: is the correction about a JOIN — which columns connect two tables?\n   (e.g., \"join on customer_id, not user_id\"; \"products → categories via category_id\")\n   → relationship\n\nElse: is the correction about what a WHOLE TABLE represents, not one column?\n   (e.g., \"`orders` includes cancelled rows too\", \"`metrics_daily` is materialized\n    from `events`, use it for date ranges > 7 days\")\n   → table_metadata\n\nElse: does the corrected SQL define a REUSABLE AGGREGATION that didn't exist?\n   (e.g., \"MRR = SUM(price) WHERE plan_type='subscription'\", \"active customers\n    means is_active AND last_login > 30 days ago\")\n   → new_metric\n       → if also touches the predicate side (active customers), consider whether\n         the predicate alone deserves a named_filter — same Rule 1 sign-off.\n\nElse: is the correction a DISPLAY / FORMATTING / DEFAULT-FILTER preference?\n   **Classify it like everything else — don't reflexively ask. Route to the MOST\n   SPECIFIC home, structured-model-first:**\n   - It's the **currency/unit** of specific column(s) — \"amounts are in INR → show ₹\",\n     \"this is a percentage\", \"values are in days\" → set that column's **`unit`** field\n     (the ISO currency code, or `percent`/`cents`/`days`) via `cli curate`\n     (`{op:edit, kind:table, area, name:<table>, column:<col>, field:unit, value:\"INR\"}`).\n     The runtime + chart renderer format it **deterministically** (`units.py`). This IS\n     the org-wide home — it's in the shared model.\n   - Another column fact — \"amount is in cents\" (a scale fix), \"this code maps to\n     <label>\" → `field_metadata`: `value_transform` (`amount/100.0`) or `choice_field`\n     on that column. Also in the shared model, org-wide.\n   - It's a default filter on a table — \"exclude soft-deleted\", \"tenancy filter\" →\n     the table's `default_filters` (model), via `cli curate`.\n   - It's a cross-cutting presentation convention not tied to one column — \"present\n     money with lakh/crore grouping\" → `user_preference` → `USER_MEMORY.md` (it's a\n     presentation rule, not domain meaning; datasource.md is narrative-only now).\n   - It's a personal stylistic tic that would hold on ANY database — \"I like top-10\n     not top-5\", \"my date format\" → `user_preference` → `USER_MEMORY.md`.\n   Only when you genuinely can't tell personal vs org-wide → **AskUserQuestion** (the\n   ambiguity fallback below). Default a currency/unit/data fact to the **model**, not a\n   prose file.\n   → In all cases, if it changes how SQL renders results (TO_CHAR, ROUND, a symbol),\n     ALSO bake it into the affected seed example's SQL so future answers apply it.\n\nElse: is the correction about a BUSINESS TERM specific to this database's domain?\n   (e.g., \"gold tier means lifetime spend > $10k\" — used as a category in many\n    queries; \"MRR\" — the abstract concept; \"we don't track refunds, those live\n    in Stripe\" — what the data fundamentally doesn't include)\n   → org_context. A term → `cli set-terminology` (the structured `key_terminology`\n     glossary). A higher-level narrative (\"we don't track refunds…\", \"who the users\n     are\") → a datasource.md prose line. See the `org_context` edit section for both.\n       → org_context is for ABSTRACT business concepts not tied to one specific\n         column. A correction tied to a specific column belongs in field_metadata,\n         NOT here. Re-check the first rule of the tree before landing here.\n\nElse: pure SQL syntax / typo with no domain knowledge implied\n   (e.g., \"missed the GROUP BY\", \"`customer_idx` is a typo of `customer_id`\")\n   → sql_fix\n
\n

Anti-patterns the LLM keeps producing (do NOT do these)

\n
    \n
  1. Per-column rule → datasource.md. \"CUSTOMERS.STATUS values normalize to Active\" is NOT domain context — it's a column-value mapping. Route to field_metadata (choice_field).
    2. \n
  2. Per-column rule → examples.yaml notes. This skill never writes to examples.yaml.notes[] (that path lives in agami-connect Phase 6d). If you find yourself wanting to write \"the order total can be negative\" as a note on example #12, route it to field_metadata on the actual column instead — the lesson applies to every future query, not just to one example.
    3. \n
  3. Dumping a column-fact into a prose file (or USER_MEMORY). \"Amounts are in INR → show ₹\" is a fact about the amount column → a caveat/value_transform on that column (org-wide, structured, in the shared model) — NOT a USER_MEMORY line and NOT a datasource.md prose rule. Route data-facts to the column/table; reserve the prose files for cross-cutting conventions (datasource.md) and personal tics (USER_MEMORY). Don't reflexively ask — classify; ask only when personal-vs-org is genuinely unclear.
    4. \n
  4. Display preference → prose without changing SQL. If the correction is \"always format like X,\" ALSO modify the seed example's SQL to demonstrate the formatting (so future answers actually apply it, not just describe it).
    5. \n
\n

Diff-based hints (look at SQL changes for classification clues)

\n\n

When ambiguous, AskUserQuestion (use the rubric above as your option set)

\n
\n

What kind of correction is this?

\n
    \n
  • A SQL fix — the answer was wrong but the model is fine
    • \n
  • A column meaning change — e.g., amount is in cents, status means something specific, Male/MALE/T all map to \"Male\"
    • \n
  • A join correction — relationships in the model need updating
    • \n
  • A table meaning change — the description / context for a whole table
    • \n
  • A new business metric — let's add this as a reusable metric
    • \n
  • A display / formatting rule — number formatting, currency/units, default filters (currency/units attach to the column; I only ask about scope if it's genuinely unclear)
    • \n
  • Domain context for this database — abstract business concepts not tied to one column (e.g., \"gold tier means lifetime spend > $10k\")
    • \n
\n
\n

The user's answer determines Phase 5 routing.

\n

Distinguishing org_context vs user_preference vs field_metadata:

\n\n

Phase 4 — surface classification + destination BEFORE Phase 5 writes anything

\n

After classifying, always surface the decision to the user in chat as a one-line summary with explicit reasoning, then proceed with the edit. The contract:

\n
Classification: <kind>\n  → routing to: <destination file + the specific field/section that'll change>\n  → reasoning: <one sentence explaining which rule of the decision tree matched>\n
\n

Concrete examples:

\n
Classification: field_metadata\n  → routing to: sales/ORDERS.yaml → fields[\"TOTAL\"].description\n  → reasoning: rule says \"correction about a single column's meaning/encoding/sign convention\" — you're teaching that this column can be negative because refunds carry a negative sign.\n\nClassification: field_metadata\n  → routing to: sales/CUSTOMERS.yaml → fields[\"STATUS\"].agami.choice_field\n  → reasoning: rule says \"value normalization mapping (active/ACTIVE/1 → 'Active') belongs in choice_field\" — not datasource.md.\n\nClassification: user_preference + seed-example update\n  → routing to: USER_MEMORY.md (the prose preference) AND examples.yaml example #N (TO_CHAR in SQL)\n  → reasoning: \"always format counts with commas\" is a display preference (cross-DB), and the seed example needs the formatting baked into its SQL so future answers actually apply it.\n
\n

The user can override before any file is written. If they say \"no, that belongs in X instead,\" re-route to X and re-surface the new classification before proceeding.

\n
\n

Phase 5: Apply surgical model edits (when applicable)

\n

If the correction kind is sql_fix: stop here. Phase 2 already saved the example. Surface the closing message and skip to Phase 6.

\n

For every other kind, you propose a model edit and run the validator BEFORE writing.

\n

4a — propose the edit

\n

Model edits go through the curation engine (semantic_model.cli curate \"$ROOT\" --ops-file …), which validates + commits + reverts on failure — you don't stage/validate/promote by hand. ROOT=\"<artifacts_dir>/<profile>\". Resolve the subject <area> for an affected table the same way as Phase 2 (the area whose tables_defined holds it). The new-metric case uses cli add --kind metric (curate's --ops-file edits existing entries; add creates them) — same validate + commit + revert guarantees.

\n

Fixing a column/table description marks it human-validated. A correction that rewrites a description via a curate edit op (no source:\"ai\") automatically sets description_source: \"human\" — so a description agami had inferred is now trusted and stops surfacing as an \"assumption\" in answer receipts. You don't set description_source yourself; the curate engine does it.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Edit kindHow
relationshipcli curate edit op(s) on the relationship in <area>
field_metadatacli curate edit op(s) on the column (kind: table, + column)
table_metadatacli curate edit op(s) on the table
new_metricWrite a new subject_areas/<area>/metrics/<name>.yaml, then cli validate \"$ROOT\"
org_contexta term → cli set-terminology (structured key_terminology, validated); a narrative line → append to datasource.md (no validator)
user_preferenceappend to USER_MEMORY.md (no validator)
\n

relationship edit

\n

Find the relationship in <area>'s relationships.yaml (by from_table/to_table). The corrected SQL's ON clause tells you the fix:

\n\n

table_metadata edit

\n

edit op(s) on the table: set description (what the table represents) or append a caveats[] entry (a usage note / quirk). Never change grain, columns, source_type, or relationships from a table-metadata correction — those are structural.

\n

field_metadata edit

\n

edit op(s) on the column (kind: table, area, name: <table>, column: <col>):

\n\n

new_metric edit

\n

Write subject_areas/<area>/metrics/<name>.yaml (snake_case name, unique in the area):

\n
name: <derived_from_user_request>\ncalculation: <one-sentence prose intent — REQUIRED, never empty>\nbindings:\n  <storage_type>: <the aggregation SQL from the corrected SQL>\nsource_tables: [<tables it reads>]\nother_names: [<the user's term + obvious variants>]\nconfidence: proposed\nreview_state: unreviewed\n
\n

Reference columns plainly (<table>.<column>). Strip user-specific WHERE filters (WHERE customer_id = 42); keep only definitional ones (WHERE plan='subscription'). Then cli validate \"$ROOT\". A proposed/unreviewed metric needs sign-off on the /agami-model Review tab before the runtime will use it (Rule 1) — tell the user.

\n

user_preference edit

\n

A user_preference correction does NOT touch the semantic model. It lands in <artifacts_dir>/USER_MEMORY.md (per shared/user-memory-format.md) — the global preferences file that applies across every database. Steps:

\n
    \n
  1. Read <artifacts_dir>/USER_MEMORY.md (it exists — init seeds it).
    2. \n
  2. Pick the right section (Default filters, Naming and synonyms, Display preferences, or Avoid) based on the policy's nature. Add a new section if none of the four fits — keep this rare.
    3. \n
  3. Append the new bullet under that section, in plain English (the user's wording, lightly cleaned). Don't paraphrase aggressively — preserve their voice.
    4. \n
  4. Show the user the diff (per Phase 4b below) before writing.
    5. \n
  5. Strip nothing — USER_MEMORY.md is intentionally free-form, not schema-validated. The validator (Phase 4c) is a no-op for user_preference corrections; the semantic model is unchanged.
    6. \n
\n

The user's bullet should be self-contained — anyone reading USER_MEMORY.md should understand the policy without seeing the original conversation.

\n

org_context edit

\n

org_context splits by what kind of fact it is — each goes to its proper home (per shared/organization-context-format.md). The two homes are deliberately separate; never write one kind into the other.

\n\n

Show the user the diff (Phase 4b) before writing. set-terminology is validated (reverts on failure); datasource.md prose is free-form (no validation).

\n

mixed edit

\n

Apply each individual edit as above. Show the user the combined diff in 4b before validating. If the mix includes a user_preference or org_context, those parts skip the validator (USER_MEMORY.md / datasource.md aren't validated); the semantic-model parts still go through the validator.

\n

4b — show the diff to the user, get approval

\n

Build a unified diff (or a compact \"before / after\" summary) of the proposed change against the existing target file. Name the file in the prompt so the user knows what they're approving. Show via AskUserQuestion:

\n
\n

I want to update the target file in `<artifacts_dir>/

\n
[Relationship] orders_to_customers\n- from_columns: [user_id]\n+ from_columns: [customer_id]\n
\n

Approve?

\n
    \n
  • Yes (Recommended) — apply and validate
    • \n
  • No — leave the model as-is, the example is still saved
    • \n
  • Edit first — let me tweak before applying
    • \n
\n
\n

For org_context / user_preference the file is datasource.md / USER_MEMORY.md instead of a schema yaml — same prompt shape, just a different filename.

\n

Always include the validator step in 4c regardless of which option they pick (since \"Yes\" still has to validate, except for datasource.md / USER_MEMORY.md which aren't validated).

\n

4c — apply with validation (the gate)

\n

For relationship / field_metadata / table_metadata edits (existing entries): build the ops array, write it with the Write tool (never a heredoc / shell variable / python3 -c — JSON quotes and null break those), then apply via the curation engine — it validates the whole model, commits to the profile git repo, logs to curation_log.jsonl, and reverts every change if validation fails:

\n
bash \"$AGAMI_PLUGIN_ROOT/scripts/sm\" curate \"$ROOT\" --ops-file /tmp/agami-correction-ops.json\n
\n

Stdout: {applied, skipped, errors, validated, committed}.

\n\n

For new_metric (creating an entry): use the packaged add command — don't hand-write the YAML. It validates the item + the whole tree, writes subject_areas/<area>/metrics/<slug>.yaml, reverts on failure, and commits. Put the one metric in a JSON array:

\n
bash \"$AGAMI_PLUGIN_ROOT/scripts/sm\" add \"$ROOT\" --kind metric --area <area> --file /tmp/agami-new-metric.json\n
\n

Same {applied, skipped, errors, validated, committed} contract as above: validated: false → it already reverted, surface errors; skipped → the metric was structurally invalid (e.g. missing calculation), surface the reason.

\n

There is no override path — a model that fails validation is never persisted; <artifacts_dir>/<profile>/ is left unchanged. The example library still got the correction (Phase 2 already happened).

\n

For org_context / user_preference corrections (datasource.md / USER_MEMORY.md only): no validator step. Write the file directly with chmod 600.

\n

4d — confirmation

\n
✓ Correction appended to <artifacts_dir>/<profile>/prompt_examples/<area>/examples.yaml\n✓ Model updated in <artifacts_dir>/<profile>/subject_areas/<area>/:\n    - relationship orders_to_customers from_columns: [user_id] → [customer_id]\n✓ Validator passed.\n\nNext time someone asks \"<question>\" or anything similar, I'll use the corrected SQL AND know the right join is on customer_id.\n
\n
\n

(Phase 6 — telemetry emission on correction — has been removed in the current 0.x line. The skill no longer reads analytics_consent and no longer appends to .telemetry-queue.jsonl. agami has no telemetry — see docs/privacy.md.)

\n
\n

Edge cases

\n\n
\n

Hard rules

\n
    \n
  1. Phase 2 (examples append) always runs. Even if the user later changes their mind on the model edit, the example is already saved.
    2. \n
  2. Phase 5 model writes are gated by the validator. cli curate (edits existing entries) and cli add (creates a new metric/entity) are the only ways to write inside <artifacts_dir>/<profile>/, and both refuse / revert on a validation failure. No exceptions. datasource.md and USER_MEMORY.md edits skip the validator (free-form Markdown).
    3. \n
  3. Edits stay valid against the model. Don't invent fields — the Pydantic models (packages/agami-core/src/semantic_model/models.py) forbid unknown keys, so an invalid edit is rejected by the validator. When you can't express a correction within the model shape, fall back to sql_fix (example only) and tell the user \"I can save this as a few-shot example but it doesn't fit a model edit.\"
    4. \n
  4. Show the diff before mutating the model. The user always gets to see and approve the proposed change.
    5. \n
\n","files":[{"path":"SKILL.md","sizeBytes":32733,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-09-17T16:01:17.583034Z","sha256":"9C19599C675C7C3A85852545D69C1F5E46D7A044D45F7CDA79B59D983293B366","sizeBytes":12380},"review":null,"source":{"repositoryUrl":"https://github.com/AgamiAI/agami-core","path":"plugins/agami/skills/agami-save-correction","license":null,"commit":"6fbffd4102c7789593604e67da14871ee792047d","subtreeSha":"40AA763037F5A2105D0D0138A1BBC4324EB7E86EE0DECE507F7E96F6E2390922","lastSyncedAt":"2026-09-25T07:37:23.183057Z"},"reviewedAt":"2026-09-17T16:04:14.227931Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/AgamiAI/agami-core/tree/main/plugins/agami/skills/agami-save-correction"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install agamiai-agami-core@llmmart"},{"target":"git","command":"git clone https://github.com/AgamiAI/agami-core.git"}]}