duthaho
- 40 skills
- 0 followers
- 4 hours ago last updated
- ▌
- ▌
- ▌ Slug Generator · duthaho bundleUse when the user asks for a URL slug, kebab-case identifier, filename-safe version of a string, or slug-ified title. Produces a lowercase, dash-separated, punctuation-stripped version of the input.
- ▌ Adr Writer · duthaho bundleUse when the user asks to write, create, or draft an ADR, architecture decision record, or decision record. Picks between a short or long template based on the size of the decision, assigns the next ADR number, and writes the result to docs/adr/NNNN-<slug>.md.
- ▌
- ▌ Map · duthahoCodebase orientation for an unfamiliar or large repo — "map this before I work in it." Fans out read-only Explore sub-agents that navigate the code (keyless — grep/glob/read, no embeddings to go stale) along the order that matters: entry points, build/test/lint commands, architecture and key abstractions, conventions and gotchas, test layout. Distills the findings into a lean AGENTS.md at the repo root — the cross-tool standard file many agents auto-load — where every claim points to a real file and nothing survives that isn't load-bearing. Human-in-the-loop: it drafts, you approve, and it never writes or commits into your repo without an explicit yes. Stamps the map with date + commit so /map refresh regenerates only what went stale. Use before working in a repo you or the agent don't know — e.g. "/map", "/map the auth subsystem", "generate an AGENTS.md", "/map refresh". Run it upstream of feature or bugfix; for the end-of-session shipping gate use done.
- ▌ Done · duthahoEnd-of-session shipping gate — "prove it works, then ship it." Runs an evidence checklist (full test suite, lint/typecheck, build, and actually running the change — output quoted, never asserted), then a fresh-context two-stage review by a sub-agent that sees only the diff and the spec: spec-compliance first, correctness second, style never — joined by a cross-model second opinion when a codex/gemini CLI is installed. Flags fake-green tripwires (edited or deleted tests, new TODOs or skips, hardcoded expectations) and ends with a verdict — SHIP, FIX FIRST, or NEEDS HUMAN — before drafting the commit/PR for the user's approval. Use at the end of any coding session or when the user asks "is this done", "ready to ship?", "/done", "wrap this up", "review and commit this". It is the closing step of both feature and bugfix, but works standalone on any uncommitted or branch diff.
- ▌ Tune · duthahoHarness retro — turn recurring agent mistakes into one-line fixes. Mines recent session transcripts (plus the bugfix log and past runs) for repeated corrections, permission friction, and rules that get violated anyway, then proposes ranked changes one at a time: a CLAUDE.md rule, an allowlist entry, a script replacing repeated prose, a new-skill candidate, or a deletion that no longer earns its context cost. Nothing applies without approval; accepted/rejected findings persist in out/tune/learnings.md. Use when the user says "/tune", "improve my setup", "why does claude keep doing X", or after a frustrating session. done's one-line retro catches one lesson at ship time; tune is the periodic audit of the whole harness.
- ▌ Learn · duthahoPersonalized tutor with memory across sessions — "teach me X, at my pace." Builds a syllabus with a pass rubric per unit, teaches one unit per session: a recall quiz on what's due (date-based spaced repetition), examples matched to your background, and an active-recall check graded against the rubric with confidence tags. Progress and weak spots persist in out/learn/<topic>.md, so sessions resume and re-drill what was missed; fact-sensitive content is verified by web search, not memory. Keyless. Use to learn or study a topic — e.g. "/learn rust ownership", "teach me kubernetes", "quiz me on X", "continue the SQL lessons"; "/learn" alone lists topics in progress. For community buzz use pulse; for choosing between technologies use verdict.
- ▌ Pulse · duthaho bundleCommunity-pulse research on any topic — "what are people saying about X right now." Fans out parallel sub-agents across web search, Hacker News, Reddit, and GitHub; ranks findings by real engagement (points/upvotes/stars/comments); flags rumors; and writes a cited brief to chat plus saved .md and .html files. Use when the user wants the current community conversation / recent buzz / sentiment / "last 30 days" view on a person, product, project, or concept — e.g. "/pulse <topic>", "what's the buzz on X", "what are people saying about X lately", "research recent discussion on X". For exhaustive, adversarially fact-checked web reports, prefer the deep-research skill instead.
- ▌ Scout · duthaho bundleCompetitive reconnaissance for your project — what do the repos solving this same problem do better, and what's worth adopting? Finds peer repos (ranked by activity, downloads, dependents — never raw stars), mines what their users beg for — issue reactions, releases, docs claims, every finding with a locator — and verdicts each candidate feature ADOPT/ADAPT/SKIP/WATCH, where SKIP is the default and "a competitor has it" is never a reason. ADOPT items become ready seeds for feature or autopilot; verdicts persist in out/scout/tracker.md so repeat runs open with what changed. Keyless. Use for "what are similar projects doing", "compare us to X", "what are we missing" — e.g. "/scout", "/scout <owner/repo>", "/scout deep <repo>". For X-vs-Y tech choices use verdict; for community buzz use pulse.
- ▌ Bugfix · duthahoLightweight bug-fixing loop — reproduce → root-cause → fix test-first → verify — deliberately separate from the heavyweight feature workflow so small fixes don't drag a spec-and-plan process behind them. Demands a deterministic reproduction before any code changes, a stated root-cause hypothesis confirmed with evidence (never a shotgun fix), a failing test that captures the bug, and the original repro re-run as proof. Keeps a one-line-per-bug log in out/dev/bugfix-log.md and checks it first, so recurring bugs get recognized instead of re-diagnosed. Use when the user reports something broken, failing, throwing, or flaky, or asks to fix a bug — e.g. "/bugfix login 500s on empty password", "fix this error", "this test is flaky", "why is X crashing". If the fix turns out to need real design work, hand off to feature; the shipping gate is done.
- ▌ Ideate · duthaho bundleStructured idea generation for a project or a blank-slate problem — ideas worth pursuing, not the first one that sticks. Grounds in the current repo (AGENTS.md/README) or a freeform problem, then diverges across named lenses (adjacent user, removed constraint, inversion, and more) so a run yields range, not ten variations of one idea. Fights premature convergence — nothing judged until the divergence quota is met — then verdicts each idea EXPLORE/PARK/DROP, where DROP is cheap. EXPLORE items become seeds for priorart (is it novel?) or feature (build it); verdicts persist in out/ideate/tracker.md so repeat runs open with what's new. Keyless. Use to generate, brainstorm, or explore ideas or new directions for a project or problem — e.g. "/ideate", "/ideate <topic>", "brainstorm features for X". For whether an idea already exists use priorart; for competitor features use scout; for choosing between named options use verdict.
- ▌ Jobfit · duthaho bundleJob-fit evaluation and discovery for job seekers — "find roles that fit me" and "should I apply to this one?" DISCOVER searches job boards for openings matching your profile; EVALUATE takes job URLs/descriptions you provide. Both research compensation, company signal, and posting legitimacy in parallel, score each role A–F, and emit a ranked decision brief with tailored CV-bullet suggestions. Evaluated roles persist in out/jobfit/tracker.md so repeat runs skip what you passed on. Keyless and human-in-the-loop: it never applies for you. Use to find matching jobs, triage postings, decide whether a role is worth applying to, or tailor a CV to a JD — e.g. "find jobs that fit my CV", "/jobfit <url>", "score these roles against my CV". For community buzz on a company use pulse.
- ▌ Feature · duthahoEnd-to-end feature workflow around the agent — spec by interview, a plan of 2–5-minute tasks, test-first execution with checkpoint commits, then an evidence-gated finish. Effort-scaled: a one-sentence diff skips straight to implementation; a real feature gets spec.md → plan.md → task-by-task TDD, with all state in out/dev/<change>/ so any later session resumes at the first unchecked task. Human-in-the-loop: the spec and the plan are approved (and editable) before any code is written, and nothing ships without the done gate. Use when the user wants to build, add, or implement a feature or start non-trivial coding work — e.g. "/feature add rate limiting", "implement X", "build a Y that Z", "resume the <change> feature". For fixing something broken use bugfix; for just the end-of-session shipping gate use done; for this whole loop end-to-end without approval stops, suggest the user run /autopilot (explicit invocation only).
- ▌ Revisit · duthahoRevisit dashboard — one scan of everything you parked to re-check later, across every skill's memory. Reads out/*/tracker.md and the other memory files skills leave behind (ideate PARK "revive when", verdict/scout revisit-when triggers, refactor WATCH candidates, learn spaced-repetition due dates, jobfit roles to re-check) and surfaces what's due now: date-based items past their date, trigger-based items whose condition may have fired. Renders one prioritized "due to re-check" list in chat — grouped by skill, most overdue first — quoting the exact tracker line and its revive trigger so you can act or defer. Strictly read-only: it never edits a tracker or fires the follow-up skill; it points, you decide. Use for "what do I need to revisit", "what's due to re-check", "anything parked worth reviving", "show my revisit queue" — e.g. "/revisit", "/revisit ideate".
- ▌ Verdict · duthaho bundleArchitect-grade technology decision briefs — "which option should we pick, and why?" Takes a decision question (X vs Y vs Z for a stated context: library, database, framework, platform, buy-vs-build) plus your constraints, fans out parallel sub-agents to research each option's project health, community sentiment, technical claims, and operational story, then scores options across weighted criteria and emits an ADR-style recommendation with a full scorecard and cited evidence. Keyless; the recommendation is advisory — you decide. Use when the user must choose between technologies or approaches — e.g. "/verdict postgres vs mongodb for <use case>", "should we use Kafka or NATS", "compare X and Y", "buy vs build", "which framework for this". Also supports "/verdict revisit <brief>" to cheaply re-check a past verdict's revisit-when triggers. For community buzz on a single topic use pulse; for exhaustive fact-checked research use deep-research.
- ▌ Daybrief · duthahoMorning work briefing — "what does my day look like, in one scan?" Gathers today's calendar and emails needing attention (via connected Google MCP tools when available), recent git activity and unfinished work across your local repos, your open tasks (TODO file / assigned GitHub issues), and a quick radar check on topics you track — all in parallel — and renders one compact, prioritized brief in chat, carrying over unfinished focus items from yesterday's saved brief. Every source is optional and degrades gracefully; strictly read-only (never sends email, never touches the calendar, never pushes). Use at the start of a workday or when the user asks "what's on today", "morning brief", "daybrief", "catch me up", "what should I focus on today". For deep research on one topic use pulse instead.
- ▌ Newskill · duthahoScaffold a new skillhub skill, or repair one that drifted, across all four registration surfaces in one motion — folder, README table row, marketplace plugin, and trigger evals — then prove it with validate-skills.py. User-invoked.
- ▌ Priorart · duthaho bundlePrior-art check before you build — does this idea already exist? Takes a project/tool/library idea, reframes it in the vocabularies different communities would use, searches where builders publish (code registries, Show HN, arXiv), traces each match one dependency-layer down to the real incumbent, and returns a locator-backed landscape plus exactly one verdict: Build / Fork X / Contribute to Y / Use Z / Investigate first. Checked ideas persist in out/priorart/checked.md, so re-checking one opens with what changed. Keyless. Use for "does something like X already exist", "has anyone built this", "am I reinventing the wheel", "check prior art before I build" — e.g. "/priorart <idea>". For your existing project vs its peers use scout; for choosing between named options use verdict.
- ▌ Refactor · duthaho bundleEvidence-driven refactoring — where does structural improvement actually pay off, then make that change without changing behavior. Survey mode diagnoses by evidence, not aesthetics — git churn × complexity hotspots, the recurring-bug log, upcoming work — and verdicts each candidate REFACTOR/PREP/LEAVE/WATCH, where LEAVE is the default and "the textbook recommends it" is never a reason. Execute mode takes one approved candidate in small behavior-preserving moves, suite green after each. Keeps a debt register in out/refactor/tracker.md so repeat surveys open with what changed. Use for "clean up this module", "improve the architecture", "pay down tech debt" — e.g. "/refactor", "/refactor <target>". For new behavior use feature; for something broken use bugfix.
- ▌ Autopilot · duthahoThe whole coding loop on one deliberate yes: map, spec, critic-hardened plan, GitHub issues, parallel worktree implementers, fresh-context review loops, one PR with the evidence. Acts only on its itemized charter; parks what it can't settle honestly. Commands: /autopilot <task> [--merge], resume, status. It signs a charter and pushes branches, so it never auto-triggers — explicit invocation only.
- ▌ Blueprint · duthaho bundleHuman-facing documentation, architecture docs, and mermaid diagrams for a codebase, a module, or a feature — "draw me the architecture, with receipts." Fans out read-only sub-agents to build a grounded component graph first: every node is a real path, every edge backed by a grep-verified import or call — unverifiable edges are dropped, not drawn. Diagrams render from that verified table per a fixed checklist (never freehand mermaid), capped at 5–8 top-level components with drill-down pages; every doc section cites its sources as file:line. Drafts in chat, writes docs/blueprint/ only on your yes, and stamps a manifest with date + commit so /blueprint refresh regenerates only what the diff touched. Use for "generate an architecture diagram", "document this codebase or module for people", "create a mermaid diagram of this feature" — e.g. "/blueprint", "/blueprint the payment flow", "/blueprint refresh". For agent-facing orientation (AGENTS.md) use map; blueprint is the human-facing sibling.
- ▌ Cachewise · duthaho bundlePrompt-cache economics forensics — why your Claude Code tokens burn so fast, with the numbers to prove it. Parses local ~/.claude transcripts (0 tokens, a bundled Python script does the counting) and attributes every cache-miss rebuild to a cause — idle gaps past the 5-min TTL, mid-session model/effort switches, prefix churn (MCP tool-lists, edited CLAUDE.md, dynamic content), and cold re-boots of a session you could have resumed — each priced in real USD, then prescribes the fixes ranked by dollars saved. Tracks before/after in out/cachewise/tracker.md so the next run measures whether a fix worked. Use when the user asks why they hit usage limits so fast, wants their cache hit rate or token spend analyzed, or where their tokens are going — e.g. "/cachewise", "analyze my prompt cache", "what's burning my tokens". For recurring behavior mistakes use tune; for today's schedule use daybrief.
- ▌ Factcheck · duthahoAdversarial citation and claim audit for any document — "do these sources actually say what the text claims?" Takes a markdown file, URL, or pasted draft (including this repo's own pulse/verdict briefs), extracts every checkable claim, then fans out verifier sub-agents instructed to refute, not confirm: does the cited link resolve AND assert the claim as stated, is the source primary or a laundered secondary write-up, has the claim gone stale. Emits a graded audit table — VERIFIED / MISATTRIBUTED / UNSUPPORTED / STALE / UNCHECKABLE — with a quoted passage as evidence for every grade, saved to out/factcheck/. Advisory: it grades, the human edits. Use when the user wants to check citations, verify sources, or audit a report, post, or brief — e.g. "/factcheck <doc>", "verify the sources in this", "are these citations real?", "is this actually true?". For researching a fresh topic use pulse; for judging code changes use done.
- ▌ Evidence Driven Debugging · duthahoUse during active debugging when you have a hypothesis to test or need to instrument a running system. Activate for keywords like "debug", "instrument", "log", "trace", "breakpoint", "what's happening at runtime", "production behavior". Pair to investigate-root-cause for the doing-it phase. Always record what you observed -- never debug entirely "in your head" without leaving evidence behind.
- ▌ Release And Changelog · duthahoUse when cutting a release, bumping a version, or writing release notes. Activate for keywords like "release", "version bump", "changelog", "release notes", "tag", "publish", "ship a release", "v1.x", "v2.x". Enforces version hygiene: SemVer respect, changelog discipline, atomic commits, tagged release. Always reflect the actual diff in the changelog -- never write notes from memory or marketing copy.
- ▌ Investigate Root Cause · duthahoUse when encountering ANY bug, error, test failure, or unexpected behavior. Activate for keywords like "bug", "error", "failing", "broken", "doesn't work", "unexpected", "crash", "exception", "TypeError", "undefined", stack traces, or any error message. Also trigger when tests fail unexpectedly, when behavior differs from expectations, when investigating production incidents, or when flaky/intermittent issues appear. Investigation produces evidence and a written hypothesis before any fix is attempted. Always investigate root cause before proposing fixes -- never guess at solutions.
- ▌ Plan Review Experience · duthahoExperience-dimension reviewer for written plans (UX + DX). Use when running plan-review or directly when an experience review is wanted. Activate for keywords like "UX review", "DX review", "experience review", "error states", "API ergonomics", "developer experience", "user states". Scores 5 sub-dimensions 0-10 covering both end-user experience (information hierarchy, state coverage, accessibility) and developer experience (error copy, API/CLI ergonomics, AI-slop avoidance). Always cite plan task numbers -- never write generic UX/DX advice.
- ▌ Plan Review Architecture · duthahoArchitecture-dimension reviewer for written plans. Use when running plan-review or directly when an architectural review is wanted. Activate for keywords like "architecture review", "data flow", "failure modes", "rollback", "edge cases", "test matrix". Scores 5 sub-dimensions 0-10, produces ranked fixes. Always cite file paths or task numbers from the plan -- never write generic architectural advice.
- ▌ Code Review Loop · duthahoUse when opening a PR for review or when receiving review feedback. Activate for keywords like "code review", "PR review", "request review", "review feedback", "address comments", "reviewer said". Covers both ends of the loop: preparing a reviewable PR and acting on feedback rigorously. Always engage with every comment -- never dismiss feedback by silently ignoring it.
- ▌ Verification Gate · duthahoUse before claiming a task, feature, or PR is complete. Activate for keywords like "done", "complete", "ready to merge", "ship it", "tests pass", "looks good", "fixed". Mandatory pre-completion gate. Refuses to mark anything done without evidence: command outputs, test runs, behavioral checks. Always paste the evidence -- never assert "it works" without showing it works.
- ▌ Audit Dependencies · duthahoUse when investigating dependency bloat, security advisories, supply-chain risk, upgrade planning, or before adding a new third-party package. Activate for keywords like "deps", "dependencies", "package.json", "requirements.txt", "Cargo.toml", "audit", "CVE", "stale package", "do we use", "what depends on", "transitive dep". Produces a written audit with import-graph evidence — never trust scanner output without verifying call sites.
- ▌ Incremental Shipping · duthahoUse when implementing a non-trivial feature, migration, or refactor that would otherwise be a single large change. Activate for keywords like "feature flag", "incremental", "vertical slice", "migration", "rollout", "behind a flag", "ship small". Enforces vertical slicing, feature-flagged rollout, and refactor-with- evidence (behavior-preserving changes proved by test/perf deltas). Always ship the smallest reversible change -- never bundle unrelated improvements.
- ▌ Test First · duthahoUse when implementing any feature, bugfix, or refactor that has a testable outcome. Activate for keywords like "TDD", "test-first", "red-green", "write the test first", "implement <feature>", "fix <bug>". Enforces the red-green-refactor discipline -- write a failing test, make it pass with the smallest change, refactor with tests as a safety net. Always paste the red and green test runner output -- never claim "tests pass" without showing them pass.
- ▌ Write Plan · duthahoUse after a spec exists and before any implementation code is written. Activate for keywords like "plan", "break down", "decompose", "implementation plan", "task list", "what's the order". Produces a numbered task list where each task names the file, the change, the test, and what evidence proves it's done. Always cite file paths and exact commands -- never write a plan with placeholder verbs like "implement" or "set up".
- ▌ Plan Review · duthahoUse after a plan exists and before any implementation begins. Activate for keywords like "review the plan", "check this plan", "is the plan ready", "plan-review", "pressure-test the plan". Orchestrates two parallel reviewers — architecture and experience — consolidates their findings into one fix gate, and applies user-selected fixes to the plan. Always run before non-trivial implementation -- a plan that survives review costs less to implement than one that doesn't.
- ▌ Map Codebase · duthahoUse when entering an unfamiliar codebase or area, before making non-trivial changes, when onboarding to a new system, or when planning a refactor that touches multiple modules. Activate for keywords like "explore", "map", "find where", "trace", "how does X work", "what calls Y", "scope of change". Produces an evidence-cited map of the relevant area with file:line references for every claim. Always cite the file and line you read -- never assert behavior you have not verified by reading.
- ▌ Init · duthaho bundleInteractive setup wizard for claudekit. Scaffolds rules, hooks, and MCP server configs into the user's project. Run /claudekit:init to configure. Use when setting up a new project with claudekit or reconfiguring an existing one.
- ▌ Shape Spec · duthahoUse when starting a non-trivial feature, change, or refactor before any plan or code is written. Activate for keywords like "spec", "shape", "what should we build", "requirements", "design this", "we need to", "let's add". Produces a written spec covering goals, non-goals, constraints, acceptance criteria, and open questions. Engineering-flavored — does not chase founder framings like demand reality, wedge focus, or 10x outcomes.