Mine coding sessions into personalized agent profiles
A skill that mines a private agent profile from real coding-session history, with mandatory approval before mining begins.
Why it matters
Generate evidence-based agent work profiles by mining real user-authored coding session logs, extracting repeated patterns, and creating private design and writing profiles that reflect actual working behavior rather than questionnaires or rules.
Outcomes
What it gets done
Extract and deduplicate user-authored text from local coding-agent session logs
Run model-backed mining workers over validated segments to identify patterns
Generate and validate private work, design, and writing profile packs
Activate approved profiles with dated receipts and cache reuse tracking
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-ditto | bash Overview
Ditto
A skill that mines a private agent profile from real coding-session history via an installed Ditto runtime, gated by a read-only preflight plan requiring explicit approval before any model-backed mining runs. Use it only on an explicit user request to set up or run Ditto - personalization being potentially useful is never sufficient reason to trigger mining on its own.
What it does
This skill mines only the user's own words from real local coding-agent session logs and turns repeated, supported patterns into private work, design, and writing profiles. It keeps dated session receipts, rejects authored rules and memory files as source evidence, and requires explicit approval before any model-backed mining begins. As a standalone skill it routes to a compatible, already-installed Ditto runtime; native namespaced routing is available separately through the upstream Ditto plugin.
It resolves an installed runtime first - asking for the path to an existing, trusted Ditto installation (or using the native plugin if already present), retaining the Python 3 executable path, the runtime path, and the matching MINING_PROMPT.md path, and confirming the installed version before use. It never downloads or installs executable code itself; if Ditto isn't installed, it stops and points to the separate upstream installation guidance. It then shows a read-only mining plan built only from real user-authored sessions - never from AGENTS.md, CLAUDE.md, memory files, rules files, or a typed self-description - running a full-history quality-default preflight:
"$PYTHON3" "$DITTO_PY" plugin preflight
That preflight surfaces the valid session count, post-dedupe and selected source tokens, cache hits, and planned worker/reducer calls, and it waits for explicit approval of the displayed plan before doing any model-backed work. A --preview flag creates a cheaper starter profile from selected history rather than the full profile, and is never presented as equivalent to the full-history result. Once approved, it retains the plan's approval_hash, prepares the run in the exact approved mode, and re-shows the plan for fresh approval if the hash changes. For every uncached selected segment it runs one worker against just that segment and its per-segment contract, caches the JSON report, and stops on any rejection; it then runs one reducer over only the validated reports, writes and validates the complete pack, and activates only that validated pack. Finally it verifies status and reports the active version, active/inactive domains, source-token and pass counts, cache reuse, and the profile card path.
When to use - and when NOT to
Use it when the user explicitly asks to set up, run, update, re-mine, or deepen Ditto, wants a profile derived from real session history rather than a questionnaire or rules file, and native ditto:mine isn't available while a compatible runtime already is. Personalization being potentially useful is never sufficient reason to trigger it on its own - mining requires an explicit user request every time. Raw sessions, caches, receipts, and generated profiles stay private by default, and only a card or short trait gets shared, not the full profile or receipt appendix; it stops on any validation failure rather than activating a partial profile, and never uploads session logs or full profiles to a third party without explicit approval.
Inputs and outputs
Input is the user's real local coding-agent session logs, filtered through the resolved Ditto runtime. Output is a validated, activated profile pack plus a profile card reporting active version, active/inactive domains, source-token counts, and cache reuse - all kept local except for the selected, redacted text actually sent to the model provider the user chooses.
Integrations
It routes to an already-installed Ditto runtime (via its Python executable and MINING_PROMPT.md contract) rather than installing one itself, and cross-references @agenttrace-session-audit for cost/latency/failure/health analysis of sessions and @agent-memory for explicit persistent knowledge storage as distinct from evidence-based profile mining.
Who it's for
Users who want an agent profile grounded in their own real coding-session history rather than a questionnaire or authored rules file, and who are comfortable approving a displayed, cost-transparent mining plan before any model-backed work runs.
Source README
Ditto
Overview
Ditto mines only the user's words from real local coding-agent session logs and
turns repeated, supported patterns into private work, design, and writing
profiles. It keeps dated session receipts, rejects authored rules and memory as
source evidence, and requires approval before model-backed mining begins.
This standalone skill routes a compatible, already-installed Ditto runtime.
Native namespaced routing is available through the upstream Ditto plugin.
When to Use This Skill
- Use when the user explicitly asks to set up, run, update, re-mine, or deepen Ditto.
- Use when the user wants an agent profile derived from real coding-session history rather than a questionnaire or rules file.
- Use when native
ditto:mineis unavailable and the user already has a compatible Ditto runtime installed.
Do not trigger this skill merely because personalization might be useful. Mining
requires an explicit user request.
How It Works
1. Resolve an installed runtime
Ask the user for the path to an existing, trusted Ditto runtime, or use the
native upstream plugin when it is already installed. Retain the exact Python 3
executable path as PYTHON3, the runtime path as DITTO_PY, and its matchingMINING_PROMPT.md path. Confirm the installed version and source before use.
Do not download or install executable code as part of this skill. If Ditto is
not installed, stop and direct the user to the upstream installation guidance;
installation is a separate, explicit decision.
2. Show the read-only mining plan
Mine only real user-authored sessions. Never synthesize a profile fromAGENTS.md, CLAUDE.md, memory files, rules files, or a typed self-description.
Run the full-history quality-default preflight:
"$PYTHON3" "$DITTO_PY" plugin preflight
Show the user the valid session count, post-dedupe source tokens, selected source
tokens, cache hits, planned worker calls, and planned reducer calls. Wait for
explicit approval of this displayed plan before any model-backed work.
If the user explicitly asks for a quick preview, add --preview and say exactly:
Quick preview creates a starter profile from selected history, not the full profile.
Never present preview as the default or as equivalent to the full-history result.
3. Prepare the approved run
Retain the displayed approval_hash, then prepare with the exact approved mode.
For the full-history plan, run:
"$PYTHON3" "$DITTO_PY" plugin prepare --approved-plan-hash HASH
For an approved quick-preview plan, preserve preview mode explicitly:
"$PYTHON3" "$DITTO_PY" plugin prepare --preview --approved-plan-hash HASH
If the hash changes, show the new plan and obtain approval again. Retain the
returned run_id, assigned segment and report paths, and pack_path.
4. Mine and validate evidence
For every uncached selected segment, run one worker over only that segment and
the per-segment contract in the resolved MINING_PROMPT.md. Cache each JSON
report with plugin cache-report and stop on rejection.
Run one strongest-available reducer over only the validated reports and reducer
contract. Write the complete pack to pack_path, validate it, and activate only
the validated pack with plugin activate.
5. Verify and report
Run plugin status, render the profile card, and report:
- active version and core profile path
- active and inactive domains
- selected source tokens and actual worker/reducer passes
- cache reuse
- card path
- any exact targeted-deepen instruction
If the current host already has the native Ditto plugin, do not create a
competing direct profile installation.
Examples
Full-history setup
User: run ditto on my coding history
Agent: resolves the pinned runtime, shows the read-only full-history plan, and
waits for explicit cost approval before starting any mining workers.
Explicit quick preview
User: give me a cheap ditto preview first
Agent: runs preflight with --preview, labels it as a starter profile, and waits
for approval of the displayed preview plan.
Best Practices
- Keep raw sessions, caches, receipts, and generated profiles private by default.
- Report exact observed counts and paths; never estimate provider billing or coverage.
- Preserve the approval hash and mode through the complete run.
- Stop on validation failure instead of activating a partial profile.
- Share the card or a short trait, not the full private profile or receipt appendix.
Limitations
- Ditto models working behavior; it does not make the underlying model smarter.
- Sparse or repetitive histories can leave design or writing domains inactive.
- Provider system prompts, tool traffic, and billing overhead are outside Ditto's exact token accounting.
- Quick preview has lower recall than the full-history quality default.
- Automatic work, design, and writing routing requires the upstream native plugin.
Security & Safety Notes
- This skill does not download executable code; it requires an existing trusted Ditto installation.
- Extraction, redaction, caches, and generated profiles stay local. Selected redacted text is processed by the model provider the user chooses.
- Redaction is best-effort. Tell the user to inspect private output before sharing it.
- Never upload session logs or full profiles to a third party without explicit user approval.
- Installation itself schedules no mining model calls; every prepared mining mode still requires approval of its displayed plan.
Common Pitfalls
Problem: No eligible sessions are found.
Solution: Report the supported source locations that were checked and ask whether the user has retained or exported session history.
Problem: The approval hash changed.
Solution: Do not reuse the old approval. Show the updated plan and obtain approval again.
Problem: A cached or reduced report fails validation.
Solution: Stop, preserve the failure evidence, and never activate the incomplete pack.
Related Skills
@agenttrace-session-audit- Use for cost, latency, failure, and health analysis of coding-agent sessions.@agent-memory- Use for explicit persistent knowledge storage rather than evidence-based profile mining.
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.