Dedicated Graph Demo Prompt

Shared by @futuretrees

Updated Jun 22, 2026

Dedicated graph demo prompt

Demo framing

We already proved one successful dedicated-graph integration with the automated feedback triage agent.

Now the next demo should show something much bigger:

one prompt provisions a brand-new Ditto knowledge graph, watches for backend changes, updates every dependent MCP-extension repo, opens PRs across the stack, records the run, and then kicks off a fresh-context reviewer agent.

That makes the story:

  1. Dedicated graph for review/feedback triage
  2. Dedicated graph for cross-repo MCP extensions maintenance
  3. Ditto Code handles the full lifecycle: detect → provision → patch → PR → review → persist

Exact repo set for this demo

These are the repos that must be maintained based on changes to @ditto-assistant/backend:

  • @ditto-assistant/ditto-mcp
  • @ditto-assistant/ditto-cli
  • @ditto-assistant/ditto-hermes
  • @ditto-assistant/ditto-clawhub
  • @ditto-assistant/ditto-claude-plugins

Source-of-truth repo being watched:

  • @ditto-assistant/backend

Last-run ledger repo:

  • @ditto-assistant/ditto-backend-ops-log

This should be presented explicitly as a multi-repo MCP extensions maintenance automation.

Best prompt draft

Prompt for Ditto Code:

We already have one successful dedicated-graph integration: the automated feedback triage workflow in @ditto-assistant/backend uses its own durable graph as a task-specific memory layer.

Now I want you to create a new dedicated Ditto knowledge graph for MCP extensions maintenance and handle the full integration end-to-end.

This new workflow should follow the same overall shape and standard patterns as the existing OpenCode feedback-triager workflow in @ditto-assistant/backend, except this one is for maintaining the MCP extension repos when @ditto-assistant/backend changes.

Goal

Provision a new dedicated KG for an automation that watches @ditto-assistant/backend for relevant MCP/server changes and maintains every dependent extension repo. When backend changes require downstream updates, the system should use this dedicated graph to understand prior runs, determine what must be updated, patch all affected repos, open PRs, record the run state, and then trigger a separate reviewer agent with fresh context.

Repos in scope

Watch for upstream changes in:

  • @ditto-assistant/backend

Maintain downstream repos:

  • @ditto-assistant/ditto-mcp
  • @ditto-assistant/ditto-cli
  • @ditto-assistant/ditto-hermes
  • @ditto-assistant/ditto-clawhub
  • @ditto-assistant/ditto-claude-plugins

Use this repo for last-run state / run ledger:

  • @ditto-assistant/ditto-backend-ops-log

What you should do

  1. Inspect the existing pattern first.

    • Start by reviewing the existing OpenCode feedback-triager workflow in @ditto-assistant/backend.
    • Reuse the same high-level workflow shape, conventions, config patterns, and operational structure where appropriate.
    • Do not copy feedback-triage-specific business logic; adapt the pattern for MCP extensions maintenance.

  2. Provision a new dedicated Ditto knowledge graph.

    • Use the create_dedicated_graph tool specifically to create/provision the new dedicated KG for this automation.
    • Give it a clear, production-ready name and alias.
    • Document its purpose, expected read/write behavior, and retention expectations.
    • Keep this graph separate from the feedback-triage graph because it serves a different workflow.
    • Treat the graph as the durable memory layer for MCP extensions maintenance across repos.
    • Reply with the claim link for the newly provisioned graph.

  3. Use the correct secret name.

    • In @ditto-assistant/backend, the GitHub Actions / workflow secret name for this automation must be:
      • DITTO_API_KEY_HEARTBEAT_MCP_MAINTENANCE
    • Use that exact name so it does not collide with the other stored Ditto API key(s).
    • If the provisioning flow requires a human claim/auth step for the graph API key, use the Ditto claim-link pattern rather than exposing raw key material.

  4. Implement change detection / gating based on backend changes.

    • The automation should not run full maintenance work unless @ditto-assistant/backend actually changed in a way that matters to the downstream MCP-extension repos.
    • Use @ditto-assistant/ditto-backend-ops-log as the canonical source of truth for the last successful run state.
    • Read and update the last-run marker there following the standard repo patterns.
    • Record at minimum:
      • last reviewed backend revision / commit / version
      • last maintenance run timestamp
      • repos touched
      • PR links opened
      • reviewer outcome
    • If there is no relevant backend change, the automation should exit cleanly with a clear no-op summary.

  5. Integrate the new dedicated KG into the primary implementation flow in @ditto-assistant/backend.

    • Add the config, env handling, workflow wiring, documentation, and code paths needed for this graph-backed automation.
    • Keep it aligned with the existing OpenCode workflow structure used by the feedback triager.
    • Make sure the workflow can:
      • inspect backend state
      • compare against the last recorded run
      • consult the dedicated KG
      • decide whether to proceed
      • update downstream repos when required

  6. Maintain all dependent repos when backend changes require it.

    • Inspect how backend MCP/server changes affect each downstream repo.
    • Update the following repos as needed:
      • @ditto-assistant/ditto-mcp
      • @ditto-assistant/ditto-cli
      • @ditto-assistant/ditto-hermes
      • @ditto-assistant/ditto-clawhub
      • @ditto-assistant/ditto-claude-plugins
    • Update code, config, docs, examples, schemas, or integration points as needed.
    • Keep changes minimal, correct, and tightly scoped to backend-driven MCP extensions compatibility/maintenance.

  7. Open PRs in each affected downstream repo.

    • One PR per repo.
    • Use clear titles and bodies explaining:
      • what backend change triggered the maintenance run
      • what was updated in that repo
      • how the dedicated KG fits into the automation
      • any setup, migration, or secret requirements

  8. Kick off a separate reviewer agent with fresh context.

    • After the implementation PRs are opened, trigger a second agent pass to review the changes.
    • This reviewer should have:
      • fresh context
      • access to the same backend / MCP surfaces
      • access to the same dedicated KG
      • access to the implementation PRs / diffs
    • The reviewer agent should validate correctness, consistency across repos, documentation quality, and whether any important downstream updates were missed.
    • This can happen either:
      • within the same overall workflow as a second phase, or
      • as a separately triggered step, if that is architecturally cleaner.
    • Prefer the design that gives the reviewer the cleanest possible context boundary while still following the same operational pattern family.

  9. Write run results back to the durable systems.

    • Save the final run summary in the dedicated KG.
    • Persist the canonical last-run marker in @ditto-assistant/ditto-backend-ops-log.
    • The stored result should be enough to support the next incremental run without re-deriving everything from scratch.

  10. Return a final operator summary.

    • New KG name / alias
    • KG claim link
    • Backend change detection mechanism
    • Last-run ledger location
    • Which downstream repos were changed
    • PR links
    • Reviewer-agent outcome
    • Required secrets or claim steps
    • Any follow-up work or risks

Constraints

  • Treat this as a real multi-repo maintenance automation, not a mockup.
  • Preserve separation of concerns between dedicated graphs by use case.
  • Follow the same overall workflow shape as the existing OpenCode feedback-triager flow in @ditto-assistant/backend.
  • Do not trigger costly maintenance work if @ditto-assistant/backend has not changed in a relevant way.
  • Use DITTO_API_KEY_HEARTBEAT_MCP_MAINTENANCE exactly as the backend-stored secret name for this workflow.
  • Be careful with secrets: do not leak raw credentials in code, logs, or PR text.
  • If a human claim/auth step is needed, return the claim link rather than raw secret output.
  • The reviewer agent should be meaningfully independent from the implementation pass.

Success criteria

  • A brand-new dedicated KG exists for MCP extensions maintenance automation.
  • The agent replies with the KG claim link.
  • There is a reliable backend-change detection gate so the workflow only runs when @ditto-assistant/backend changes in a relevant way.
  • @ditto-assistant/backend is wired to use the new graph and workflow correctly.
  • The downstream repos are updated when relevant:
    • @ditto-assistant/ditto-mcp
    • @ditto-assistant/ditto-cli
    • @ditto-assistant/ditto-hermes
    • @ditto-assistant/ditto-clawhub
    • @ditto-assistant/ditto-claude-plugins
  • PRs are opened in all affected repos.
  • A fresh-context reviewer agent evaluates the generated changes.
  • The run is recorded in @ditto-assistant/ditto-backend-ops-log so the next invocation can be incremental.
  • The resulting setup clearly demonstrates that Ditto Code can operationalize a dedicated graph across a multi-repo system from a single prompt.

Stronger founder-demo version

We already showed that a dedicated graph can power one successful automation: feedback triage.

Now show the next step.

Create a new dedicated Ditto knowledge graph for MCP extensions maintenance, wire it into the right implementation flow in @ditto-assistant/backend, use it to maintain every downstream repo that depends on backend MCP/server changes, open PRs across that repo set, record the run in @ditto-assistant/ditto-backend-ops-log, and then hand the result to a separate reviewer agent with fresh context.

I want this to demonstrate that Ditto Code can:

  • create a new task-specific knowledge graph
  • return the claim link for that graph
  • use that graph as durable operational memory
  • detect whether backend changes actually require downstream work
  • maintain a multi-repo system when a shared backend/MCP dependency changes
  • open implementation PRs automatically
  • and then perform an independent review pass using the same KG but fresh context

Follow the same shape as the existing OpenCode feedback-triager workflow in @ditto-assistant/backend, but make this one the MCP extensions repos maintainer.

The downstream repos are:

  • @ditto-assistant/ditto-mcp
  • @ditto-assistant/ditto-cli
  • @ditto-assistant/ditto-hermes
  • @ditto-assistant/ditto-clawhub
  • @ditto-assistant/ditto-claude-plugins

The upstream repo being watched is:

  • @ditto-assistant/backend

The last-run ledger repo is:

  • @ditto-assistant/ditto-backend-ops-log

The backend secret name must be:

  • DITTO_API_KEY_HEARTBEAT_MCP_MAINTENANCE

Return the KG details, claim link, changed repos, PR links, last-run ledger details, reviewer-agent outcome, and any required human claim/secret steps.

Clean architecture for the demo

Phase 1: detect

  • inspect @ditto-assistant/backend
  • compare against the last-run marker in @ditto-assistant/ditto-backend-ops-log
  • decide whether downstream maintenance work is needed

Phase 2: provision + implement

  • provision the dedicated KG
  • return the claim link
  • load dedicated KG context
  • identify impacted downstream repos
  • patch each affected repo
  • open PRs
  • record implementation summary

Phase 3: review

  • launch separate reviewer agent
  • give it fresh context, the same backend / MCP surfaces, the same dedicated KG, and the PR diffs
  • validate quality and cross-repo consistency
  • record review outcome

Phase 4: persist

  • write final run summary into the dedicated KG
  • update @ditto-assistant/ditto-backend-ops-log with the last-run marker and outcomes

Why this works for the demo

  • It tells a much stronger story than “graphs store memory.”
  • It shows dedicated graphs can power real operational automations.
  • It shows Ditto Code can coordinate work across many repos.
  • It proves the system can avoid unnecessary runs with change detection.
  • It introduces a credible two-agent pattern: implementer + reviewer.
  • It reinforces the broader platform story: graphs + backend/MCP change detection + agent workflows + PR automation + durable run memory.