From 9cca605384ea817f557338eb31458f9da3d124c7 Mon Sep 17 00:00:00 2001 From: Ditto skills sync <41898282+github-actions[bot]@users.noreply.github.com> Date: Mon, 2 Nov 2026 02:46:51 +0000 Subject: [PATCH] chore: sync shared skills at 6adea513b263 --- .kimi-plugin/plugin.json | 2 +- plugins/ditto/.antigravity-plugin/plugin.json | 2 +- plugins/ditto/.claude-plugin/plugin.json | 2 +- plugins/ditto/.codex-plugin/plugin.json | 2 +- plugins/ditto/.cursor-plugin/plugin.json | 2 +- plugins/ditto/.github/plugin/plugin.json | 2 +- plugins/ditto/.grok-plugin/plugin.json | 2 +- plugins/ditto/.kimi-plugin/plugin.json | 2 +- plugins/ditto/shared-skills.lock.json | 23 +++++++-- plugins/ditto/skills/code-review/SKILL.md | 47 +++++++++++++++++ plugins/ditto/skills/daily-brief/SKILL.md | 43 ++++++++++++++++ plugins/ditto/skills/decision-log/SKILL.md | 44 ++++++++++++++++ plugins/ditto/skills/diagnose-bug/SKILL.md | 49 ++++++++++++++++++ plugins/ditto/skills/gift-ideas/SKILL.md | 41 +++++++++++++++ plugins/ditto/skills/grill-me/SKILL.md | 46 +++++++++++++++++ plugins/ditto/skills/launch-post/SKILL.md | 43 ++++++++++++++++ plugins/ditto/skills/learn-anything/SKILL.md | 44 ++++++++++++++++ plugins/ditto/skills/plan-meals/SKILL.md | 40 +++++++++++++++ plugins/ditto/skills/plan-trip/SKILL.md | 40 +++++++++++++++ plugins/ditto/skills/prep-meeting/SKILL.md | 47 +++++++++++++++++ plugins/ditto/skills/research-brief/SKILL.md | 46 +++++++++++++++++ plugins/ditto/skills/tdd/SKILL.md | 47 +++++++++++++++++ plugins/ditto/skills/tidy-memory/SKILL.md | 50 +++++++++++++++++++ plugins/ditto/skills/verify-done/SKILL.md | 46 +++++++++++++++++ plugins/ditto/skills/weekly-review/SKILL.md | 46 +++++++++++++++++ plugins/ditto/skills/write-spec/SKILL.md | 48 ++++++++++++++++++ scripts/shared_skills.py | 7 ++- 27 files changed, 798 insertions(+), 15 deletions(-) create mode 100644 plugins/ditto/skills/code-review/SKILL.md create mode 100644 plugins/ditto/skills/daily-brief/SKILL.md create mode 100644 plugins/ditto/skills/decision-log/SKILL.md create mode 100644 plugins/ditto/skills/diagnose-bug/SKILL.md create mode 100644 plugins/ditto/skills/gift-ideas/SKILL.md create mode 100644 plugins/ditto/skills/grill-me/SKILL.md create mode 100644 plugins/ditto/skills/launch-post/SKILL.md create mode 100644 plugins/ditto/skills/learn-anything/SKILL.md create mode 100644 plugins/ditto/skills/plan-meals/SKILL.md create mode 100644 plugins/ditto/skills/plan-trip/SKILL.md create mode 100644 plugins/ditto/skills/prep-meeting/SKILL.md create mode 100644 plugins/ditto/skills/research-brief/SKILL.md create mode 100644 plugins/ditto/skills/tdd/SKILL.md create mode 100644 plugins/ditto/skills/tidy-memory/SKILL.md create mode 100644 plugins/ditto/skills/verify-done/SKILL.md create mode 100644 plugins/ditto/skills/weekly-review/SKILL.md create mode 100644 plugins/ditto/skills/write-spec/SKILL.md diff --git a/.kimi-plugin/plugin.json b/.kimi-plugin/plugin.json index f71f25c..b2a72b9 100644 --- a/.kimi-plugin/plugin.json +++ b/.kimi-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "ditto", - "version": "0.3.8", + "version": "0.3.9", "author": { "name": "Omni Aura LLC", "email": "support@heyditto.ai", diff --git a/plugins/ditto/.antigravity-plugin/plugin.json b/plugins/ditto/.antigravity-plugin/plugin.json index 61438c6..c52ff46 100644 --- a/plugins/ditto/.antigravity-plugin/plugin.json +++ b/plugins/ditto/.antigravity-plugin/plugin.json @@ -2,7 +2,7 @@ "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json", "name": "ditto", "displayName": "Ditto", - "version": "0.3.8", + "version": "0.3.9", "description": "Search and save Ditto memories through hosted MCP, curate music, and hand off chats with verified continuation notes. Archival and owned workspace cleanup depend on host capabilities and authorization. Sign in through Antigravity.", "logo": "assets/icon.png", "suggestedPrompts": [ diff --git a/plugins/ditto/.claude-plugin/plugin.json b/plugins/ditto/.claude-plugin/plugin.json index 85f6024..ec9a927 100644 --- a/plugins/ditto/.claude-plugin/plugin.json +++ b/plugins/ditto/.claude-plugin/plugin.json @@ -1,7 +1,7 @@ { "$schema": "https://anthropic.com/claude-code/plugin.schema.json", "name": "ditto", - "version": "0.3.8", + "version": "0.3.9", "description": "Search and save Ditto memories through hosted MCP, curate music, and hand off chats with verified continuation notes. Archival and owned workspace cleanup depend on host capabilities and authorization. Sign in through Claude.", "author": { "name": "Omni Aura LLC", diff --git a/plugins/ditto/.codex-plugin/plugin.json b/plugins/ditto/.codex-plugin/plugin.json index b270147..fea768c 100644 --- a/plugins/ditto/.codex-plugin/plugin.json +++ b/plugins/ditto/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "ditto", - "version": "0.3.8", + "version": "0.3.9", "author": { "name": "Omni Aura LLC", "email": "support@heyditto.ai", diff --git a/plugins/ditto/.cursor-plugin/plugin.json b/plugins/ditto/.cursor-plugin/plugin.json index 81c5806..a8527d0 100644 --- a/plugins/ditto/.cursor-plugin/plugin.json +++ b/plugins/ditto/.cursor-plugin/plugin.json @@ -2,7 +2,7 @@ "name": "ditto", "displayName": "Ditto", "description": "Search and save Ditto memories through hosted MCP, curate music, and hand off chats with verified continuation notes. Archival and owned workspace cleanup depend on host capabilities and authorization. Sign in through Cursor.", - "version": "0.3.8", + "version": "0.3.9", "author": { "name": "Omni Aura LLC", "email": "support@heyditto.ai" diff --git a/plugins/ditto/.github/plugin/plugin.json b/plugins/ditto/.github/plugin/plugin.json index 1f76205..4f19e68 100644 --- a/plugins/ditto/.github/plugin/plugin.json +++ b/plugins/ditto/.github/plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "ditto", - "version": "0.3.8", + "version": "0.3.9", "displayName": "Ditto", "description": "Search and save Ditto memories through hosted MCP, curate music, and hand off chats with verified continuation notes. Archival and owned workspace cleanup depend on host capabilities and authorization. Sign in through GitHub Copilot.", "author": { diff --git a/plugins/ditto/.grok-plugin/plugin.json b/plugins/ditto/.grok-plugin/plugin.json index 922bf78..147b2e9 100644 --- a/plugins/ditto/.grok-plugin/plugin.json +++ b/plugins/ditto/.grok-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "ditto", - "version": "0.3.8", + "version": "0.3.9", "author": { "name": "Omni Aura LLC", "email": "support@heyditto.ai", diff --git a/plugins/ditto/.kimi-plugin/plugin.json b/plugins/ditto/.kimi-plugin/plugin.json index 4024221..5cf8d6c 100644 --- a/plugins/ditto/.kimi-plugin/plugin.json +++ b/plugins/ditto/.kimi-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "ditto", - "version": "0.3.8", + "version": "0.3.9", "author": { "name": "Omni Aura LLC", "email": "support@heyditto.ai", diff --git a/plugins/ditto/shared-skills.lock.json b/plugins/ditto/shared-skills.lock.json index bb8ceab..ad8571b 100644 --- a/plugins/ditto/shared-skills.lock.json +++ b/plugins/ditto/shared-skills.lock.json @@ -1,16 +1,33 @@ { "schema_version": 1, "source_repository": "https://github.com/ditto-assistant/ditto-skills", - "source_commit": "b4065445c5bc4d637503f0982119b957686dbf50", + "source_commit": "6adea513b2633efc05f2f34d9f655adceeca2c37", "host": "plugins", "core_sha256": "5912af5483c469ec15db27858122fc9128fc25cd239202c0fdd9727de7dd5f6b", "adapter_sha256": "c44c1d6054861d915c77f6333f1f972b9c3144cbc8d3c387988c3af9b917d9a4", - "generator_sha256": "f0fe5c02da33e861c0962230d0d1486a0542b915808c33b8bd8d4350012467db", + "generator_sha256": "210bce4b3167244d234ee0cc0e5adf771a72ce78a99675ad9dcf103969018d12", "skill_sha256": "d74135ea9af4d33fe1fb55727b3dbe93e448449ac124f95b333f0aebfdf880ed", "files_sha256": { + "plugins/ditto/skills/code-review/SKILL.md": "6696e1a3d3887ad8d5e115e463d1ad0f5652db3032ad9d425584460c0dbe4a76", "plugins/ditto/skills/curate-music/SKILL.md": "b498f8639aeb64e59f88830ac162a894f9f128b7e1f2db6a7c528092904c1eb4", "plugins/ditto/skills/curate-music/references/youtube-music.md": "e763797cc7821114682c7b92cec6919e6f957792cdc54756f670c7086b09e52c", + "plugins/ditto/skills/daily-brief/SKILL.md": "aa4b1398e2b1fb1ad0b6588ff92e44e07b96316204544429c7582f56828e6dfd", + "plugins/ditto/skills/decision-log/SKILL.md": "fe131adeab044ebef9ec0d98be607629cdf7acf27b65d344ac6a01b333a52985", + "plugins/ditto/skills/diagnose-bug/SKILL.md": "b1899c41cc9362b41fbe5bd069352cb1ddc8e209bb9e33e0558fd0aef29b3ab6", + "plugins/ditto/skills/gift-ideas/SKILL.md": "f8c60204bb8fb8156e1a6d2e7130009a905d6cb2b3dfecf5098f1983b58b1db1", + "plugins/ditto/skills/grill-me/SKILL.md": "14e9e774d33286f0a51fc8521dd9ed479e7eccbd5567697da3a6586b8564cf2a", "plugins/ditto/skills/handoff/SKILL.md": "84624fa46d8740f0dc0a26055dd427be5aa664edeac5193542b256ca2c3b733d", - "plugins/ditto/skills/handoff/references/workspace-cleanup.md": "be4d5ec45fdaf7ed5a16c00bec7b013a61b86f26084cfaeddc39f430c4c92a53" + "plugins/ditto/skills/handoff/references/workspace-cleanup.md": "be4d5ec45fdaf7ed5a16c00bec7b013a61b86f26084cfaeddc39f430c4c92a53", + "plugins/ditto/skills/launch-post/SKILL.md": "1c634996254a9a48df0b3f6ec8ae8aa094231286927686bccb82354a06b90307", + "plugins/ditto/skills/learn-anything/SKILL.md": "997550bbdb5354c2e0e95ad358a69bd5a3f2209f22a401c1eac64bfbb9a6d9f0", + "plugins/ditto/skills/plan-meals/SKILL.md": "ca6959b54c5008e23c902c1cc8785fc63047f78988ed334bdc94fd46ccda8787", + "plugins/ditto/skills/plan-trip/SKILL.md": "ed7aac4da4219030b40f50ecbfd726fa3adbf85042387a608f0b0c90984caf3e", + "plugins/ditto/skills/prep-meeting/SKILL.md": "13e49ec46686cee975fb3ab13fc86c8de01378e4a749415efdc0ba9efb08f83a", + "plugins/ditto/skills/research-brief/SKILL.md": "3fa3d9c865b48f7d3a6aa76e5570619983afb8adac783e56c6c9a4438ad31780", + "plugins/ditto/skills/tdd/SKILL.md": "95dcdd4fc7eab08662a8cf37ce10efc26aafde87eda94c714e9c66977fc9ee18", + "plugins/ditto/skills/tidy-memory/SKILL.md": "496c0cbeabb76e4874f106f91ec14221b80c8111e28af814daa36c52487ea7f9", + "plugins/ditto/skills/verify-done/SKILL.md": "5cd669a2157d9723c19449571aafc8cbe880a42bf54bc7a72e5119f9318c858c", + "plugins/ditto/skills/weekly-review/SKILL.md": "efecbfcc90f68222ce1072272063a4ea7111a69bc636f0273814bc060aaa8753", + "plugins/ditto/skills/write-spec/SKILL.md": "3d93adbf733f71dc14cbbf07f98865c766fcc4c837d1e01e3785978e630dad1d" } } diff --git a/plugins/ditto/skills/code-review/SKILL.md b/plugins/ditto/skills/code-review/SKILL.md new file mode 100644 index 0000000..7780b23 --- /dev/null +++ b/plugins/ditto/skills/code-review/SKILL.md @@ -0,0 +1,47 @@ +--- +name: code-review +description: Review a diff for correctness bugs first, applying the team's conventions remembered in Ditto. +--- + +# Code review + +Find the problems that would hurt users or maintainers, and say each one so the +author can act on it. Correctness first, clarity second, style last. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Gather context + +Read the full diff and enough surrounding code to understand each change. Read +the description or linked issue to learn the intent. Search Ditto for the team's +review conventions, past review decisions about this area and known pitfalls; a +convention the team agreed on outranks your personal preference. Compare against +the branch the change will merge into, not an older one, or you will review +someone else's work. + +## Review in passes + +1. **Correctness.** Wrong logic, missing cases, off-by-one, nil or empty inputs, + error paths, concurrency, resource leaks, unsafe input handling, permission + checks, data migrations and backwards compatibility. +2. **Tests.** Do the tests cover the new behavior, and could they fail if the + code were wrong? +3. **Design.** Unneeded complexity, duplication of an existing helper, names that + mislead, and changes in the wrong layer. +4. **Style.** Only what the project's formatter and linter do not already catch. + +## Verify before reporting + +For each candidate finding, trace the actual code path and try to construct the +failing input. Drop findings you cannot support. Mark a finding as a question +when you are unsure. Check whether an issue is new in this change or already on +the base branch, and say which. + +## Report + +List findings most severe first. Each one names the file and line, the problem, +a concrete failure scenario and a suggested fix. Then give a short verdict. Do +not post comments, approve or request changes on a hosted review unless the +user asks you to. When the review settles a convention ("we always validate at +the handler"), offer to save it to Ditto, in the team's space if the user has +one. diff --git a/plugins/ditto/skills/daily-brief/SKILL.md b/plugins/ditto/skills/daily-brief/SKILL.md new file mode 100644 index 0000000..a878d14 --- /dev/null +++ b/plugins/ditto/skills/daily-brief/SKILL.md @@ -0,0 +1,43 @@ +--- +name: daily-brief +description: Start the day with priorities, commitments and open loops from Ditto memory, optionally every morning. +--- + +# Daily brief + +A short morning page that answers "what matters today?" from what Ditto already +knows, so the user does not have to reconstruct it. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Build the brief + +Search Ditto for what is relevant to today: priorities the user set, deadlines +and commitments due soon, promises made to other people, open loops waiting on +someone, and personal reminders (birthdays, appointments, habits the user is +building). Read a connected calendar or task list when the user has one and +asks you to use it. Fetch the records you rely on and check their dates; a +"due Friday" saved three weeks ago may already be past. + +Keep it to one screen: + +- **Top three:** the most important outcomes for today, with a first step each. +- **Commitments:** meetings and promises with times and people. +- **Waiting on:** what others owe the user, and when to nudge. +- **Don't forget:** small personal items. + +Mark anything inferred. If memory is thin, say so and ask the user for today's +priorities instead of padding the brief. + +## End of day (optional) + +When the user comes back with a recap, update the records: mark finished items, +carry unfinished ones forward and save new commitments. Save only what the user +confirms. + +## Every morning + +Offer a Ditto workflow that writes this brief on a schedule the user picks, in +their time zone, delivered where they choose. Create it only on the user's yes; +anything that would send or post on their behalf needs their explicit approval +when the workflow is created. diff --git a/plugins/ditto/skills/decision-log/SKILL.md b/plugins/ditto/skills/decision-log/SKILL.md new file mode 100644 index 0000000..01c1cfb --- /dev/null +++ b/plugins/ditto/skills/decision-log/SKILL.md @@ -0,0 +1,44 @@ +--- +name: decision-log +description: Record decisions with rationale and owner in Ditto, shared with the team, and answer why they were made. +--- + +# Decision log + +Teams forget why they decided things, then re-argue them. Record each decision +once, with enough context that someone who was not in the room can understand +it, and make it findable when the question comes back. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Record a decision + +Capture these fields from the conversation, asking only for what is missing: + +- **Decision:** one sentence, stated as what we will do. +- **Context:** the problem and the constraints at the time. +- **Alternatives:** what else was considered and why it lost. +- **Owner and date:** who decided, and when it takes effect. +- **Revisit when:** the condition that would reopen it, if any. + +Keep proposals and decisions distinct: if it is not decided yet, record it as an +open question with an owner, not as a decision. + +Before saving, search Ditto for earlier decisions on the same topic. If this one +replaces an earlier decision, say so in the new record and update the old one to +point at it rather than leaving two live answers. + +## Where it goes + +A personal decision goes to the user's main memory. A team decision belongs in +the team's or company's Ditto space, so teammates' agents can recall it. Write to +a shared space only when the user asks for it and their access allows it; never +widen who can see a record without saying so first. Check the save receipt and +give the user the reference. + +## Answer "why did we...?" + +Search the decision records and related memories, fetch the full records, and +answer with the decision, its rationale and its date, citing the records. If the +records disagree, show both and their dates. If there is no record, say so +rather than reconstructing a rationale. diff --git a/plugins/ditto/skills/diagnose-bug/SKILL.md b/plugins/ditto/skills/diagnose-bug/SKILL.md new file mode 100644 index 0000000..3526d68 --- /dev/null +++ b/plugins/ditto/skills/diagnose-bug/SKILL.md @@ -0,0 +1,49 @@ +--- +name: diagnose-bug +description: Find the root cause of a bug or slowdown with a reproduce-and-test loop, using past incidents in Ditto. +--- + +# Diagnose a bug + +Find the cause before changing code. A fix without a cause is a guess, and a +guess that happens to make the symptom disappear is the most expensive kind. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## 1. Recall + +Search Ditto for the error text, the component and earlier incidents with similar +symptoms. A previous root cause, a known flaky dependency or a recorded gotcha +can save hours. Treat a recalled cause as a hypothesis to test, not an answer. + +## 2. Reproduce + +Get a reliable reproduction before anything else: the smallest input, command or +sequence that shows the failure. Record the exact environment (versions, branch, +data, flags). If the bug is intermittent, measure how often it happens so you can +later tell a fix from luck. If you cannot reproduce it, say so and gather +evidence (logs, traces, the user's exact steps) instead of guessing. + +## 3. Hypothesize and test + +List the candidate causes and, for each, the observation that would rule it in +or out. Test the cheapest discriminating one first. Change one thing at a time. +Prefer evidence that can fail: a log line that would show a different value, a +bisect between a known-good and known-bad version, a stripped-down test case. +A check that could only ever pass proves nothing. + +When a hypothesis survives, confirm it from both sides: the failure appears when +you introduce the cause, and disappears when you remove it. + +## 4. Fix and guard + +Fix the cause, not the symptom. Add a regression test that fails on the unfixed +code and passes on the fixed code; run it both ways. Remove temporary +instrumentation. If the fix is a workaround, say so plainly. + +## 5. Report and remember + +Report the symptom, root cause, evidence, fix and remaining risk, keeping what you +observed separate from what you inferred. Offer to save the incident to Ditto +(symptom, cause, fix, how it was found) so the next occurrence starts from it. +Save only when the user agrees, and exclude secrets and customer data. diff --git a/plugins/ditto/skills/gift-ideas/SKILL.md b/plugins/ditto/skills/gift-ideas/SKILL.md new file mode 100644 index 0000000..c4311e6 --- /dev/null +++ b/plugins/ditto/skills/gift-ideas/SKILL.md @@ -0,0 +1,41 @@ +--- +name: gift-ideas +description: Suggest thoughtful gifts from what Ditto remembers about a person, and track occasions and past gifts. +--- + +# Gift ideas + +The best gifts show you were paying attention. Ditto remembers the details: the +hobby a friend mentioned, the book a parent wanted, what you gave last year. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Recall the person + +Ask who the gift is for, the occasion, the budget and the deadline. Search Ditto +for that person: interests, recent life events, things they said they wanted or +loved, sizes or preferences, and gifts already given. Fetch the memories you +use. Treat these as the user's own notes about someone else: use them only to +help the user, and keep them out of public searches and anything shared. + +## Suggest + +Offer three to five ideas across types (an object, an experience, something +handmade or personal), each with: + +- why it fits this person, tied to a specific remembered detail; +- a price range and where to find it, verified with a current search; +- lead time, so it arrives in time. + +Avoid repeating past gifts and anything the memory says they dislike. If memory +is thin, ask two or three questions about the person rather than guessing. + +## Remember + +Offer to save the choice, the occasion and the date, so next year's suggestions +avoid repeats. Offer to save new details the user mentions ("she's learning +pottery now"). Buy only when the user asks and a connected tool supports it, +confirming the item and total first. + +Offer a Ditto workflow that reminds the user a couple of weeks before important +dates with fresh ideas. Set it up only on the user's yes. diff --git a/plugins/ditto/skills/grill-me/SKILL.md b/plugins/ditto/skills/grill-me/SKILL.md new file mode 100644 index 0000000..6ceca75 --- /dev/null +++ b/plugins/ditto/skills/grill-me/SKILL.md @@ -0,0 +1,46 @@ +--- +name: grill-me +description: Interview the user about a plan until every open decision is resolved, recalling past decisions from Ditto. +--- + +# Grill me + +Sharpen a plan by asking the hard questions before anyone builds it. The goal is +shared understanding: by the end, you and the user agree on what is being built, +why, and what was decided along the way. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Before the first question + +Search Ditto for the project, the people involved and earlier decisions on the +same topic. Fetch the full memories you rely on. Open by stating what you already +know, so the user does not repeat it, and name any earlier decision the new plan +appears to contradict. If a repository or document is in scope, read it first: +answer from the material whatever the material can answer. + +## The interview + +Walk the decision tree one branch at a time. Ask one question per message, and +attach your recommended answer with a short reason. Prefer questions whose answer +changes the design: scope, users, constraints, failure modes, data ownership, +cost, rollout and how success is measured. When an answer opens a sub-decision, +resolve it before moving on. Keep a running list of open questions and say how +many remain. + +Push back when an answer is vague ("it should be fast"), conflicts with an earlier +answer or with a remembered decision, or quietly assumes something nobody has +checked. Do not accept "we'll figure it out later" for a decision that blocks +building; record it as an explicit open question with an owner instead. + +Stop when the open list is empty or the user calls time. Do not start +implementing during the interview. + +## Close out + +Summarize the plan as decisions, each with its rationale, followed by any open +questions and their owners. Offer to save the summary to Ditto as one decision +record, linked to related memories returned by the save. Save only on the user's +yes, check the receipt, and update an existing record rather than duplicating it. +For a team project, suggest the `decision-log` skill to share it in the team's +space. diff --git a/plugins/ditto/skills/launch-post/SKILL.md b/plugins/ditto/skills/launch-post/SKILL.md new file mode 100644 index 0000000..33a8d14 --- /dev/null +++ b/plugins/ditto/skills/launch-post/SKILL.md @@ -0,0 +1,43 @@ +--- +name: launch-post +description: Turn shipped work into an accurate launch post or changelog entry, using Ditto memory and the real changes. +--- + +# Launch post + +Explain what shipped, why it matters and how it works, accurately enough that an +engineer would sign off and clearly enough that a customer would read to the end. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Gather the facts + +Search Ditto for the feature's origin: the problem it solves, the decisions and +trade-offs, measurements and the people involved. Read the actual changes (pull +requests, release notes, docs) when they are available. Confirm what is really +live, for whom, and with what limits. Do not announce what has only been merged, +or present a plan as shipped. + +## Write it + +Pick one reader (customer, developer or investor) and write for them. + +1. **Headline:** the user-visible outcome, not the internal project name. +2. **Opening:** the problem in the reader's words and what is now possible. +3. **How it works:** the essential mechanism, with one diagram or table if it + genuinely explains something. +4. **Proof:** real numbers, examples or quotes with their conditions, never + invented ones. +5. **Limits and what is next:** honest availability, constraints and roadmap + claims the user has approved. +6. **Call to action:** how to try it. + +Keep claims checkable. Mark anything you could not verify for the user to +confirm. Match the user's past posts for voice when Ditto has them. + +## Deliver + +Return the draft for review, plus a short version for social posts and a one-line +changelog entry when useful. Publishing, posting or emailing are separate +actions: do them only when the user asks, through a connected tool. Offer to save +the final post and its sources to Ditto. diff --git a/plugins/ditto/skills/learn-anything/SKILL.md b/plugins/ditto/skills/learn-anything/SKILL.md new file mode 100644 index 0000000..e9a594c --- /dev/null +++ b/plugins/ditto/skills/learn-anything/SKILL.md @@ -0,0 +1,44 @@ +--- +name: learn-anything +description: Teach a subject over many sessions, tracking the goal, progress and weak spots in Ditto with spaced review. +--- + +# Learn anything + +A tutor that remembers. Each session starts where the last one ended, adapts to +what the user found hard, and brings old material back before it is forgotten. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Start with the goal + +Search Ditto for an existing learning record on this topic. If there is none, ask +why the user wants to learn it and what they want to be able to do (pass an +exam, hold a conversation in Spanish, ship a first app, run a 10K), how much +time they have and what they already know. That goal grounds every lesson. +Offer to save it as the learning record. + +## Each session + +1. **Warm up with recall.** Ask two or three questions on earlier material, + weighted toward items the user got wrong before. Answering from memory + builds retention; rereading does not. +2. **Teach one thing.** Pick the next step that is just beyond what the user can + do now, explain it briefly with an example, and cite a high-quality source + for further reading. Do not rely on your own recall for facts that matter; + check them. +3. **Practice.** Give an exercise with immediate feedback: a quiz, a problem, a + short real-world task. Quiz options should not give the answer away by + length or position. +4. **Record.** At the end, update the learning record with what was covered, + what was solid and what was shaky. Save only what the user agrees to keep. + +When a question needs judgment from real practitioners, say so and suggest a +reputable community, class or mentor. + +## Spaced review + +Offer a Ditto workflow that sends a few review questions on a schedule (for +example after one day, three days and a week), drawn from the shaky items. For +a long course, offer a dedicated Ditto agent for the subject so lessons have +their own conversation. Set either up only on the user's yes. diff --git a/plugins/ditto/skills/plan-meals/SKILL.md b/plugins/ditto/skills/plan-meals/SKILL.md new file mode 100644 index 0000000..a936297 --- /dev/null +++ b/plugins/ditto/skills/plan-meals/SKILL.md @@ -0,0 +1,40 @@ +--- +name: plan-meals +description: Plan a week of meals for the household's remembered tastes and diets, with recipes and a grocery list. +--- + +# Plan meals + +Answer "what's for dinner?" for the whole week, for this household, and turn it +into a grocery list. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Learn the household + +Search Ditto for who is eating, dietary needs and allergies, likes and dislikes, +cooking skill and equipment, budget, and meals that were hits or misses before. +Allergies and medical diets are hard constraints; confirm them when the record +is old or unclear. Ask for the week's shape: busy nights, guests, leftovers +wanted, and anything already in the fridge to use up. + +## The plan + +- **Week at a glance:** a meal per slot the user wants planned, quick ones on + busy nights, with variety in protein and cuisine. +- **Recipes:** short ingredient lists and steps, scaled to the household, with + substitutions for any restriction. Link a source recipe when you adapt one. +- **Prep:** what to make ahead and when, and how leftovers become another meal. +- **Grocery list:** combined quantities grouped by store section, with pantry + items marked "check first". + +Note nutrition only in general terms and suggest a professional for medical +diets. + +## Learn and repeat + +After the week, ask what worked, and save the hits, misses and new preferences +to Ditto on the user's yes, so next week's plan improves. Offer a weekly Ditto +workflow that drafts the plan and grocery list on the day the user shops. Order +groceries only when the user asks and a connected tool supports it, confirming +items and total first. diff --git a/plugins/ditto/skills/plan-trip/SKILL.md b/plugins/ditto/skills/plan-trip/SKILL.md new file mode 100644 index 0000000..f76e2fe --- /dev/null +++ b/plugins/ditto/skills/plan-trip/SKILL.md @@ -0,0 +1,40 @@ +--- +name: plan-trip +description: Plan a trip around the traveler's remembered preferences and budget, with itinerary and logistics. +--- + +# Plan a trip + +Plan the trip this person would enjoy, not a generic top-ten list. Ditto's +memory of how they like to travel is what makes the plan theirs. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Learn the traveler + +Search Ditto for travel preferences and constraints: pace, budget, dietary +needs, accessibility, preferred airlines or hotel styles, past trips they loved +or regretted, and who is coming. Fetch the memories you use, and check whose +preference each one is; a partner's or friend's taste is not the user's. Ask +for what is missing: dates, origin, budget range, must-dos and deal-breakers. + +## Build the plan + +- **Shape:** where to stay and why, how to get around, and a rhythm that + matches the traveler's pace. +- **Day by day:** a few anchored plans per day with sensible geography, meal + ideas that fit their diet, and a rainy-day or low-energy alternative. +- **Logistics:** documents and visas to check, bookings to make and when, + packing notes from the forecast and activities, and rough costs. + +Use web search for current facts: opening hours, prices, seasonal closures and +travel advisories. Cite sources for anything time-sensitive and tell the user to +confirm bookings directly. Never put private memory details in public searches. + +## Booking and saving + +Do not book, buy or reserve anything unless the user asks and a connected tool +supports it; then confirm the item, dates and total first. Offer to save the +itinerary to Ditto, and afterwards to record what the user loved or would skip +next time, so the next trip starts smarter. A trip planned with others can live +in a shared Ditto space when the user wants to share it. diff --git a/plugins/ditto/skills/prep-meeting/SKILL.md b/plugins/ditto/skills/prep-meeting/SKILL.md new file mode 100644 index 0000000..e077665 --- /dev/null +++ b/plugins/ditto/skills/prep-meeting/SKILL.md @@ -0,0 +1,47 @@ +--- +name: prep-meeting +description: Brief the user before a meeting from Ditto memory, then save the decisions and action items afterwards. +--- + +# Prepare for a meeting + +Walk in knowing what was said last time, what is still open, and what you want +out of this meeting. Walk out with the decisions and action items saved. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Before: the brief + +Ask for the meeting's topic, attendees and goal if they are not given, or read +them from a connected calendar when the user points you at the event. Then +search Ditto for: + +- each attendee and their company or team: role, what they care about, past + conversations and commitments made to or by them; +- the project's latest decisions, open questions and blockers; +- promises from the previous meeting and whether they were kept. + +Fetch the memories you rely on. Use web search only for public facts (a company's +recent news), and never put private memory details in a public query. + +Deliver one page: purpose and desired outcome, who is attending and what to know +about each, history in three to five bullets, open items, and suggested +questions or an agenda. Mark anything inferred, and note any gap ("no record of +the pricing discussion"). + +## After: capture + +When the user shares notes, a transcript or a quick recap, extract decisions, +action items (owner and due date), open questions and notable facts about the +people. Show them for a quick check, then save on the user's yes as one meeting +record, linked to the project and people it concerns. Use the `decision-log` +skill for decisions the team will need to find later. + +Sending a recap to attendees, creating calendar events or assigning tasks in +another tool are separate actions: draft them, and act only when asked. + +## Make it routine + +Offer a Ditto workflow that builds this brief automatically before recurring +meetings. Set it up only when the user agrees to the schedule and to anything it +would send. diff --git a/plugins/ditto/skills/research-brief/SKILL.md b/plugins/ditto/skills/research-brief/SKILL.md new file mode 100644 index 0000000..f2ab552 --- /dev/null +++ b/plugins/ditto/skills/research-brief/SKILL.md @@ -0,0 +1,46 @@ +--- +name: research-brief +description: Research a question from credible sources into a cited brief compared with what Ditto already knows. +--- + +# Research brief + +Answer a question with evidence, not recall. A good brief says what the best +sources say, where they disagree, what that means for the user, and what is +still unknown. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Frame the question + +Restate the question and the decision it informs. Ask how deep to go and how +recent the sources must be, if that matters. Search Ditto first for earlier +research, decisions and constraints on the topic, so the brief builds on what +the user already knows instead of repeating it. + +## Find and judge sources + +Use web search and any connected sources the user names. Prefer primary sources: +official documentation, papers, filings, company engineering posts, datasets and +first-hand accounts. Note each source's date and who wrote it. Treat marketing +copy, anonymous summaries and AI-generated pages as weak. Look for at least one +source that disagrees with the emerging answer. Do not put private memory +details into public search queries. + +## The brief + +- **Answer:** two or three sentences, with your confidence. +- **Findings:** the key points, each cited with a link. +- **Disagreements:** where credible sources differ, and why. +- **Compared with what we know:** how this confirms, extends or contradicts + earlier Ditto records, citing them. +- **Implications:** what it means for the decision. +- **Unknowns:** what could not be established, and how to find out. + +Quote sparingly and summarize in your own words. + +## Keep it current + +Offer to save the brief to Ditto, in the team's space when the research is for a +team. For a topic that moves, offer a scheduled Ditto workflow that re-runs the +search and reports only what changed. Set either up only on the user's yes. diff --git a/plugins/ditto/skills/tdd/SKILL.md b/plugins/ditto/skills/tdd/SKILL.md new file mode 100644 index 0000000..f81c576 --- /dev/null +++ b/plugins/ditto/skills/tdd/SKILL.md @@ -0,0 +1,47 @@ +--- +name: tdd +description: Build features and fix bugs test-first with red-green-refactor, proving every new test can fail. +--- + +# Test-driven development + +Write the test that describes the behavior, watch it fail for the right reason, +make it pass with the simplest change, then clean up. Repeat in small steps. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Before starting + +Search Ditto for the project's testing conventions: the test runner and command, +fixture and mocking habits, and known traps. Then confirm them against the +repository itself; the repository wins when they disagree. Find the existing +test closest to what you are about to write and follow its shape. + +## The loop + +1. **Red.** Write one test for one behavior, named for the behavior rather than + the implementation. Run it and read the failure. It must fail because the + behavior is missing, not because of a typo, an import error or a broken + fixture. +2. **Green.** Make the smallest change that passes. Run the whole relevant suite, + not only the new test. +3. **Refactor.** Remove duplication and improve names with the tests green. + Run them again after each change. + +Keep steps small enough that a failure points at the last change. Commit at +green when the user wants commits. + +## Tests that can fail + +A test is only evidence if it could have failed. Check each new test against the +unfixed code, or break the implementation on purpose and watch it go red. Pin +inputs, not computed values: a test that mocks the very value it asserts cannot +fail. Assert on observable behavior, not on private calls. A suite that reports +zero tests run, or exits zero while printing failures, is not a pass; read the +runner's summary line. + +## Finish + +Report which behaviors are covered, the command that runs them and the result. +When the work turns up a durable convention or trap (a flaky fixture, a slow +suite, a required flag), offer to save it to Ditto for next time. diff --git a/plugins/ditto/skills/tidy-memory/SKILL.md b/plugins/ditto/skills/tidy-memory/SKILL.md new file mode 100644 index 0000000..5375e56 --- /dev/null +++ b/plugins/ditto/skills/tidy-memory/SKILL.md @@ -0,0 +1,50 @@ +--- +name: tidy-memory +description: Find duplicate, stale and contradictory Ditto memories on a topic and fix them with the user's approval. +--- + +# Tidy memory + +Memory is only useful if it is current. Over months, the same fact gets saved +three ways, plans become decisions, decisions get reversed, and a launch date +moves twice. This skill keeps one topic's memory clean. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Scope it + +Ask which topic, project, person or time range to tidy, and which space (main +memory, a project space or a company space). Work on one bounded topic per pass. +Never sweep the whole account unprompted. + +## Survey + +Search the topic, explore the related subjects and memory network, and fetch the +full memories you will judge. Use counts from the tools when they exist; a page +of search hits is not a total. Group what you find into: + +- **Duplicates:** the same fact saved more than once. +- **Superseded:** an older fact a newer one replaces (a moved date, a reversed + decision, a changed owner). +- **Contradictions:** two records that cannot both be true, with no clear winner. +- **Stale:** a status that was true once ("in progress", "waiting on legal") and + probably is not now. +- **Mislabelled:** a proposal recorded as a decision, a draft recorded as sent. + +Note each record's author and date. Content another person published to a space +the user subscribes to is not the user's to edit. + +## Propose, then change + +Show the user a short table: what you found, the proposed action (merge into one +record, update, mark superseded, or leave), and the evidence. Ask about every +contradiction rather than choosing a winner. Apply only the approved changes, +preferring an update to the record the user maintains over creating a new one. +Delete only when the user explicitly asks for deletion of that record. Check +each write's receipt. + +## Report + +Say what changed, what was left alone and why, and what still needs a human +answer. Offer to repeat the pass on a schedule with a Ditto workflow that asks +before changing anything; set it up only on the user's yes. diff --git a/plugins/ditto/skills/verify-done/SKILL.md b/plugins/ditto/skills/verify-done/SKILL.md new file mode 100644 index 0000000..5661fc9 --- /dev/null +++ b/plugins/ditto/skills/verify-done/SKILL.md @@ -0,0 +1,46 @@ +--- +name: verify-done +description: Check each claim before reporting work done: built, merged, deployed and working are separate facts. +--- + +# Verify before saying done + +"Done" is a claim, and each part of it needs its own evidence. Most confident +wrong answers come from letting one piece of evidence stand in for another. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Separate the claims + +Split the report into the claims it actually makes, and check each one: + +- **Written:** the change exists in the files or document, in the right place. +- **Builds and tests pass:** at the exact version you are describing, from the + runner's own summary, not its exit code alone. +- **Reviewed and merged:** on the target branch, not only approved. +- **Deployed:** the running system serves this version. Read the version it + reports instead of assuming a pipeline succeeded. +- **Works:** someone exercised the behavior the user cares about, in the place + they will use it. + +Report each separately. Saying "merged" when you mean "works" is the failure +this skill exists to prevent. + +## Evidence that could have failed + +A check proves something only if it could have come out the other way. + +- A search that found nothing is evidence of absence only if the same search + finds a known positive. +- A test is evidence only if it fails without the change. +- A status page or green badge may be cached, cancelled or for a different + version. Check what it is attached to. +- A count next to "all clear" shows how much was actually inspected. Zero + inspected is not a pass. + +## Report honestly + +State what you observed and what you inferred, in separate sentences. Name what +you could not check and why. If a later fact contradicts an earlier report, say +which claim it replaces. Search Ditto for this project's known false-green traps +before checking, and offer to save any new one you find. diff --git a/plugins/ditto/skills/weekly-review/SKILL.md b/plugins/ditto/skills/weekly-review/SKILL.md new file mode 100644 index 0000000..04fa22e --- /dev/null +++ b/plugins/ditto/skills/weekly-review/SKILL.md @@ -0,0 +1,46 @@ +--- +name: weekly-review +description: Run a weekly review of wins, misses and next priorities from Ditto memory, optionally on a schedule. +--- + +# Weekly review + +Look back before planning ahead. A weekly review turns a week of scattered work +into a short record of what happened, what was learned and what matters next. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Gather the week + +Search Ditto for the past seven days: decisions, finished work, meetings, tasks, +blockers and anything the user flagged as important. Fetch the records you will +summarize, and pay attention to dates: a task saved this week may have been +finished last week. Ask the user what Ditto cannot know: how the week felt, what +they are proud of, what drained them. + +## The review + +Keep it to one screen: + +- **Done:** outcomes, not activity. "Shipped the pricing page", not "worked on + pricing". +- **Not done:** what slipped and the honest reason. +- **Learned:** one to three lessons worth keeping. +- **Open loops:** waiting-on items with the person and the date. +- **Next week:** at most three priorities, each with a first concrete step. + +For a team review, group by person or project and keep the same headings. + +## Keep it + +Offer to save the review to Ditto so next week's review and future planning can +build on it, and so trends ("third week the same blocker slipped") become +visible. Point out repeated patterns across past reviews when you find them. + +## Make it automatic + +Offer to create a Ditto workflow that runs every week at a time the user picks: +it gathers the week from memory, asks the user a few questions in a form, and +writes the review. Create it only after the user agrees to the schedule and to +where the result goes. Anything that would post or send on the user's behalf +needs their explicit approval when the workflow is created. diff --git a/plugins/ditto/skills/write-spec/SKILL.md b/plugins/ditto/skills/write-spec/SKILL.md new file mode 100644 index 0000000..55feb70 --- /dev/null +++ b/plugins/ditto/skills/write-spec/SKILL.md @@ -0,0 +1,48 @@ +--- +name: write-spec +description: Turn a conversation or rough idea into a one-page spec and shippable tickets, grounded in Ditto memory. +--- + +# Write a spec and tickets + +Turn what was discussed into something a person or agent can build without the +conversation: a short spec, then tickets that each deliver one testable outcome. + +Use the bundled `ditto-memory` skill for connection, recall and capture rules. + +## Gather + +Search Ditto for the project's goals, users, constraints, earlier decisions and +related specs. Read the current conversation and any linked documents or code. +If key facts are missing (who it is for, what done looks like, hard +constraints), ask for them, up to three questions at a time. Use the `grill-me` +skill when the plan itself is still unsettled. + +## The spec + +Keep it to one page where possible: + +- **Problem:** who has it and how we know. +- **Outcome:** what is true for the user when this ships. +- **Scope:** what is included, and what is explicitly excluded. +- **Design:** the approach and the main alternatives considered, with the reason + for the choice. +- **Risks and open questions:** each with an owner. +- **Acceptance:** observable checks that prove the outcome. + +Mark assumptions as assumptions. Do not invent requirements to fill a heading. + +## The tickets + +Split the work into tickets that each ship and can be verified on their own. +Each ticket has a title stating the outcome, context linking to the spec, +acceptance criteria and its dependencies. Order them so the riskiest unknown is +resolved first. Prefer vertical slices (a thin path through every layer) over +layer-by-layer tickets. + +## Deliver + +Show the spec and tickets in the conversation. Create tickets in a tracker only +through a connected tool and only when the user asks. Offer to save the spec to +Ditto, in the project's or team's space when there is one, so later +conversations build from it. diff --git a/scripts/shared_skills.py b/scripts/shared_skills.py index bba733b..656225d 100644 --- a/scripts/shared_skills.py +++ b/scripts/shared_skills.py @@ -6,7 +6,7 @@ whose generated SKILL.md is the canonical core plus that distribution's host-connection adapter. The ``plugins`` host is the multi-host monorepo (ditto-assistant/ditto-plugins): one shared skills folder per plugin serves -Claude, Cursor, Grok, Codex, Copilot, Antigravity, Kimi and Gemini CLI manifests, +Claude, Cursor, Grok, Codex, ChatGPT, Copilot, Antigravity and Kimi manifests, so every versioned manifest in the plugin directory is bumped together. """ import argparse @@ -29,18 +29,17 @@ NAME = r"[a-z0-9]+(?:-[a-z0-9]+)*" # Versioned manifests, relative to plugins//. The first entry is required. PLUGIN_MANIFESTS = { - "openai": ["plugin.json"], "claude": [".claude-plugin/plugin.json"], "plugins": [ ".claude-plugin/plugin.json", ".cursor-plugin/plugin.json", ".grok-plugin/plugin.json", ".codex-plugin/plugin.json", - "plugin.json", + # ChatGPT: the portable manifest, written as plugin.json at the root of the upload ZIP. + ".openai-plugin/plugin.json", ".github/plugin/plugin.json", ".antigravity-plugin/plugin.json", ".kimi-plugin/plugin.json", - "gemini-extension.json", ], } MANIFESTS = {host: f"plugins/{DEFAULT_PLUGIN}/{paths[0]}" for host, paths in PLUGIN_MANIFESTS.items()}