agentleFS
arielfikruarielfikru/kuli/skills/deepseek/SKILL.md

deepseek

Skill0 starsChanged 6 months agoMITView on GitHub

Delegate cheap/bulk subtasks to DeepSeek V4 via OpenRouter instead of doing them inline on Claude. Use for research, summarization, drafting, data extraction, bulk transforms, brainstorming, or any well-scoped task where DeepSeek output is good enough and saves Claude tokens/cost. Trigger when user says "pakai deepseek", "delegate to deepseek", "/deepseek", or when a subtask is mechanical enough to offload. Claude stays the orchestrator and validates output.

  • Reads credentials

3 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions3 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 3

    1. G1Joshi/Agent-Skills★ 15same name
    2. HyperfocuSam/deepseek-tc-localizer★ 2same name
    3. runapi-ai/deepseek★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository5 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Treat DeepSeek as a cheap, capable intern working under you (Claude).

    line 8
  2. Very specific:

    USE -c when: factual/numeric/categorical answer + you'd otherwise have to trust it blind (no cheap way to verify).

    line 29
  3. Very specific:

    Use -q to drop the stderr stats line when you don't need cost numbers.

    line 78
  4. Very specific:

    Keep the stable part first and identical across calls: same -s SYSTEM, same -f FILE reference block.

    line 180

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

DeepSeek V4 delegation — the "intern" model

Treat DeepSeek as a cheap, capable intern working under you (Claude). You are the senior: you scope the work, hand the intern everything it needs (it has no memory of the repo), let it grind, then review its output before anything ships. You never merge the intern's work blind, and you escalate hard/critical decisions to yourself.

The intern protocol — every delegation follows it:

  1. Brief — state the task precisely. The intern has zero repo context, so bundle the material it needs into -f FILE / stdin (file tree, key files, the text to transform). A vague brief gets vague work.
  2. Assign — pick the right intern for the job:
    • trivial / bulk / mechanical → default flash (cheapest, no flag)
    • hard multi-step reasoning / quality matters → --pro
    • sized automatically → --auto
    • needs to think hard (math, logic, tricky analysis) → --reasoning / --reasoning xhigh (thinking mode; measurably more accurate)
    • many similar items → ask-deepseek-batch (parallel, shared cached prefix)
    • answer is a single short verifiable value AND being wrong is costly (a number, name, yes/no, classification, picked option) → add -c 5 (self-consistency vote). Decision rule:
      • USE -c when: factual/numeric/categorical answer + you'd otherwise have to trust it blind (no cheap way to verify). The agreement X/N line tells you how much to trust it; ⚠ LOW = don't.
      • SKIP -c when: output is prose/code/a draft (every sample differs, vote is meaningless), OR you can verify the result yourself anyway (run it, check the repo), OR cost matters more than the extra confidence. It is N× the tokens — never the default.
  3. Review (mandatory gate) — read the output, spot-check claims against the real repo/source, correct mistakes. The intern hallucinates and overstates; never paste its result into user-facing work without verifying.
  4. Integrate — use the validated result, and say it was an intern draft you reviewed.

Docs are not ground truth (feed code, not marketing)

The intern believes whatever you hand it. If you bundle a README/spec and ask "what does this project do?", it reports the doc's claims as implemented fact — README says "multi-tenancy + RBAC", intern reports multi-tenancy even when the schema has a single role column and zero organization references. Garbage in, garbage out.

  • For "is X implemented / how does X work?" questions, the evidence is code, not docs. Bundle the real source: schema files, router/handler files, grep counts, dep lists. -f spec.md answers "what was planned", never "what is".
  • Separate the two in the brief. Label sections SPEC CLAIMS (unverified — check against code) vs VERIFIED FROM CODE. Tell the intern to treat spec claims as hypotheses and flag any mismatch with the code — don't blend them into one authoritative blob.
  • Narrow the question so there's no gap to fill with assumptions: "given THIS schema, what RBAC exists?" beats "research this project".
  • You verify factual impl claims before relaying. Any "X is built / X works" the intern asserts → grep/read the repo and confirm. This is the review gate's whole point; it's what catches the doc-vs-reality drift above.

Protect your own context (token discipline)

Delegating already saves your input tokens — the intern reads the big file, you don't. But the intern's output lands back in your context when you read the command result. For large outputs, don't slurp it all:

  • Redirect to a file, then read only the slice you need:
    ask-deepseek -f bigdoc.md "produce a detailed report" > /tmp/ds_out.md
    Then Read /tmp/ds_out.md with limit/offset, or grep for the part that matters — instead of piping the whole thing through your context.
  • Make the intern do the trimming: ask for a tight format up front ("max 200 words", "bullets only", "return just the JSON"). Cheaper to constrain the intern than to ingest verbosity and summarize it yourself.
  • Use -q to drop the stderr stats line when you don't need cost numbers.

Tool

ask-deepseek (at ~/.claude/bin/ask-deepseek). Stdlib Python, no deps. Needs OPENROUTER_API_KEY env var.

# direct prompt
ask-deepseek "summarize the tradeoffs of WAL vs rollback journaling"

# pipe a file / command output for analysis
rtk cat report.md | ask-deepseek "extract every action item as a bullet"
ask-deepseek -f src/big.py "list every public function and its purpose"

# cheaper model for trivial work
ask-deepseek --flash "rewrite this sentence formally: ..."

# make the intern think hard (thinking mode) for a tricky problem
ask-deepseek -r high "logic/math problem ..."        # or -r xhigh for max effort

# self-consistency: sample 5, majority-vote, flag disagreement (short answers)
ask-deepseek --flash -c 5 "Capital of Australia? Reply ONLY the city."

# system prompt + JSON output (machine-parseable)
ask-deepseek -s "You are a data extractor" --json "return {name,email} from: ..."

Flags: --flash (v4-flash — the default, cheap), --pro (v4-pro — stronger, pricier; reach for hard multi-step reasoning), --auto (route by input size: small→flash, large→pro; threshold DEEPSEEK_AUTO_THRESHOLD tokens, default 1500), --reasoning/-r [high|xhigh] (thinking mode — bare = high; big accuracy gain on hard reasoning, costs more output tokens), -m SLUG, -s SYSTEM, -f FILE, --consistency/-c N (automatic review gate: sample N, majority-vote the answer, print agreement X/N + ⚠ LOW when no majority — best for short/factual/numeric answers, not long prose), -t TEMP, --max-tokens N (output cap, default 262144, env DEEPSEEK_MAX_TOKENS), --show-thinking (print the reasoning process too, not just the final answer — off by default), --timeout SEC (default 600, env DEEPSEEK_TIMEOUT; raise for long xhigh runs), --json, -q (no stats). Models: deepseek/deepseek-v4-flash (default), deepseek/deepseek-v4-pro (--pro). Agentic (--agentic) still defaults to pro for harness tool-use; --flash opts cheap. Context window is 1M tokens (input) — feed big files via -f; output is capped by --max-tokens, not 1M.

Batch fan-out

ask-deepseek-batch sends many prompts in parallel, reusing one cached prefix:

# one prompt per line on stdin
printf 'tldr A\ntldr B\ntldr C\n' | ask-deepseek-batch --flash -j 8

# shared context file -> cached after first call; --auto routes each
ask-deepseek-batch -c report.md --auto < questions.txt

# multiline prompts split on a delimiter line; JSON output
ask-deepseek-batch -d '---' --json < prompts.txt > out.json

Batch flags: -s SYSTEM, -c CONTEXT_FILE, -d DELIM, -j N (workers, def 4), --flash, --auto, -m, -t, --max-tokens, --json. Use it for fan-out over a big document — keep -s/-c identical so the shared prefix is cached.

Agentic coding mode (--agentic)

Plain ask-deepseek is text-only (no repo access). --agentic drives DeepSeek through the Codex harness so it can read a repo, call tools, and edit files — cheap agentic coding on OpenRouter $, no ChatGPT login. (Internally shells ask-codex --or-model deepseek/deepseek-v4-pro.)

ask-deepseek --agentic "explain how the parser works here"        # read-only
ask-deepseek --agentic --apply -C ../wt "add tests for parser"    # edits files

--apply = edit mode (use a throwaway worktree, review the diff). --cd DIR = working root. Note: agentic runs are token-heavy (codex system prompt + tools); DeepSeek keeps that cheap, but it's not free. For a stronger agent use ask-codex (native GPT-5.5) or ask-or -m <slug> --agentic for another model.

When to delegate (offload to DeepSeek)

  • Research / explanation that doesn't need codebase context
  • Summarizing long text, logs, docs
  • Drafting boilerplate prose, comments, commit-body brainstorm
  • Bulk mechanical transforms (reformat, extract, classify many items)
  • First-pass brainstorming / option generation

Escalate to yourself — do NOT hand the intern (keep on Claude)

  • Anything needing this repo's structure, tools, or graph context
  • Editing files, running commands, multi-step orchestration
  • Final correctness-critical decisions — you review the intern's output, never ship it blind
  • Security-sensitive reasoning

Caching (automatic)

DeepSeek prompt caching on OpenRouter is automatic — no cache_control breakpoints needed. Cached prompt tokens bill at ~0.25x. Cache keys on the prefix of the request, so to get hits:

  • Keep the stable part first and identical across calls: same -s SYSTEM, same -f FILE reference block. Put the varying question last (CLI already orders system → file → prompt).
  • For batch fan-out over one big document, pass the doc via the same -f FILE (or identical -s) every call so the shared prefix is cached after call 1.

ask-deepseek reports cache usage on stderr, e.g. [deepseek/deepseek-v4-pro | in 5000 out 200 tok | cached 4800 (~0.25x) | discount $0.0012].

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.