godmode

Audit godmode skills, agents, and plugin files for internal consistency, broken references, stale commands, and cross-skill contradictions. Use when asked to "introspect", "audit the skills", "review godmode", or after adding new skills.

Use at the start of every conversation to orient to available skills and workspace rules. Replaces superpowers entirely. Triggers on session start, "/godmode", or "what skills do you have".

Generate and maintain a `.ctx/godmode/memory-bank/` directory that captures project context backed by source code. The memory bank is injected into prompts via lifecycle hooks and updated incrementally as work progresses. Use when starting a new project, onboarding to an unfamiliar codebase, or when context drift is detected.

Patterns and techniques for adding governance, safety, and trust controls to AI agent systems in Rust. Use this skill when building agents that call external tools, implementing policy-based access controls, adding semantic intent classification to detect dangerous prompts, creating trust scoring systems for multi-agent workflows, building audit trails, or enforcing rate limits and content filters. Covers policy composition, tool wrappers, trust decay, and JSONL audit trails — all in Rust.

Parse git history into structured changelogs. Use to generate release notes, audit commit conventions before tagging, or integrate with `godmode release` workflow.

Dead code detector for Rust workspaces. Finds unused public API surface, orphaned test helpers, stale feature flags, and plugin artifacts referencing removed CLI subcommands. Cross-references pub exports against call sites across the workspace.

Triage and prioritize GitHub issues by type (bug/feature/chore), complexity (S/M/L), and priority (P1-P4). Detect duplicates, propose execution order, and generate task graphs for godmode automation.

Use when facing 2 or more independent tasks that have no shared state or sequential dependencies between them. Triggers on multiple failing tests from different root causes, independent crate implementations, or independent task chains in GODMODE.tasks.yaml.

Write user-facing release notes from git history. Use when preparing announcements, GitHub Releases, or user documentation. Differs from changelog — focuses on user impact, not implementation or crate structure.

Use when the user wants to work on GitHub issues in parallel — "tackle issues", "fix these issues", "work on #7 #8 #9", "dispatch agents for open issues". Fetches issues, groups them into independent units, and dispatches one godmode-crate-agent per issue (capped at 5 concurrent). Triggers on issue numbers, "tackle", "fix issues", or "dispatch for issues".

Discover and catalog breaking changes when a shared crate's public API changes. Find all dependent repos, list call sites that break, estimate migration effort, and optionally dispatch parallel subagents to apply migrations.

Audit dependencies across cargo outdated, cargo deny check, and cargo audit. Produce tiered findings: Blocking (CVEs), Suggestions (major bumps), Nitpicks (minor/patch bumps). Can auto-apply patch updates when asked.

Generate a daily activity report from Claude Code session data. Harvests human/assistant turns from ~/.claude/projects/*/*.jsonl, analyzes them with claude-haiku-4-5 via the Anthropic API, and renders an HTML report with KPI cards, goals table, and effort/leverage breakdown.

rustqual guidance for Rust workspaces with multiple crates (lib + binary, lib + CLI, multi-crate workspace). Use when rustqual findings don't make sense in a workspace context — DEAD_CODE on pub API, TQ_UNTESTED on CLI dispatch, score mismatch between workspace-level and per-crate scans, or ORPHAN_SUPPRESSION after adding qual:allow(dry). Triggers on: "rustqual workspace", "dead code false positive", "cross-crate", "lib and binary crate", "qual:allow dry not working", "ORPHAN_SUPPRESSION", or any rustqual scenario involving pub API used across crate boundaries.

Runs the agent improvement loop: collect traces → human+LLM feedback → generate evals → HALO diagnosis → Codex handoff → harness update. Use when you want to systematically improve an agent's behavior from observed evidence. Triggers on "run the improvement loop", "improve agent from traces", "agent feedback loop", "what should I fix in the agent".

Working with the crux codebase — an agentic Rust DSL and runtime trace model. Use when navigating crux source code, building crux from source, adding crux as a dependency, understanding crate boundaries, or debugging crux compilation issues. Triggers on "crux crate", "crux workspace", "crux build", "add crux dependency", "crux types", "CruxCtx", "Crux<T>", or any work inside the crux repo or a repo that depends on crux crates. Also use when someone asks about crux naming — the project was renamed from cruxx-* to crux-* in May 2026.

Use when creating a new local skill or fixing an existing skill that was saved to the wrong skills tree. Symptoms - a skill was written under ~/.claude/skills, the active setup uses ~/.agents/skills, or skill instructions still reference the old path convention.

Audit and maintain project documentation. Compares CLAUDE.md, README.md, agents/INDEX.md, and skill descriptions against actual source code. Detects stale references, undocumented features, and cross-doc inconsistencies. Use when asked to "check docs", "audit documentation", or "sync docs".

Measure codebase health across seven metrics: test count, clippy warnings, TODO density, public API surface, dependency count, average module size, and doc coverage. Track trends vs previous runs and persist scores to history.

Use when applying the global Rust release-workflow pattern to the notfiles repo. Symptoms - you need the repo-specific release file, affected-crate exclusions, binary list, or GitHub-vs-Gitea cautions for notfiles.

Structured tracing for all godmode helpers and subagents. Every script invocation, branching decision, and agent lifecycle transition is recorded as a JSONL event. Use when diagnosing session failures, auditing agent convergence, or reviewing cross-session continuity.

Use when a local project exists but does not yet have a GitHub repo or issue backlog, and you want to turn a completion review into concrete GitHub issues. Symptoms - local code is ahead of repo setup, there is no README/spec, or you need to answer "is this done?" and capture the gaps as issues.

Use when creating or editing a GitHub Actions release workflow for a Rust workspace with version bumps, tags, affected-crate selection, binary packaging, and GitHub releases. Symptoms - you need a manual release workflow, selective crate bumps, downstream-dependent bump logic, or a release asset pipeline for Rust binaries.

Use when creating a task graph for a session, tracking progress across tasks, executing the next unblocked task, or managing causal dependencies between work items. Triggers on "create tasks", "what's next", "mark done", "task graph", or at session start when GODMODE.tasks.yaml exists.

The seven-dimension testing model for Rust. Use when designing a test strategy for new code, reviewing test coverage, deciding which test type to write next, or onboarding to the project's testing conventions. Triggers on "what tests do I need", "how should I test this", "test coverage", "fuzz", "kani", "model check", or any question about test strategy.

Use when merging multiple parallel agent branches (waves) into a single integration commit — rebasing each onto main, resolving conflicts while preserving intent, running tests per branch, and producing a clean summary commit with a conflict resolution log.

Guided refactoring with test discipline. Use when restructuring code without changing observable behaviour — extract, rename, reorganise, decouple.

Session reflection — review what was accomplished this session, surface patterns and surprises, and write a structured retrospective. Use when asked to "reflect", "self-reflect", "what did we do this session", or at natural session close points.

Use when ending a coding session and you want to capture handoff state, commit all current changes, and push the branch. Symptoms - you finished a work slice, updated HANDOFF state, and want one repeatable closeout flow instead of running handoff, commit, and git push separately.

Use when applying version bumps to selected Rust workspace crates and creating the release commit cleanly. Symptoms - you already know which crates should change, and you need to run `cargo set-version`, stage the right manifests, update the lockfile, and create a release commit without touching unrelated packages.

Use when you have a spec, approved design, or requirements for a multi-step task, before touching any code. Triggers after brainstorming completes, or when given a feature spec to implement.

Use when adding new BAML types/functions to cruxx-agentic. Symptoms - need to add structured extraction functions, mirror types to cruxx-types.

Three-layer verification pipeline for AI-generated output. Extracts every verifiable claim, searches for supporting or contradicting sources, runs an adversarial hallucination review, and produces a structured report with source links for human review. Use after any response that contains citations, statistics, legal/regulatory analysis, or specific factual claims you intend to rely on. Also use inline after your own substantive responses when accuracy matters.

Use when a repo is mirrored across GitHub and Gitea and you need to decide where to open or merge a PR. Symptoms - the branch tracks one forge, another forge has a different `main`, or GitHub tooling is available but the active branch lives on Gitea.

Use when creating multiple GitHub issues from a structured list. Symptoms - need to file 3+ issues with consistent format/labels.

Design and author agentic workflows using the crux DSL — both YAML pipeline files (.crux) and Rust macro-based agents. Use when writing a .crux pipeline, designing an agent workflow, choosing between crux combinators (pipe, join_all, speculate, route_on_confidence, delegate), or planning how to decompose a task into crux steps. Triggers on "write a pipeline", "crux pipeline", ".crux file", "agentic workflow", "agent plan", "step handler", "which combinator", or any request involving pipeline design, step composition, or handler selection. Also use when reviewing or debugging existing pipelines.

Use before cutting a release to verify tags, affected crates, gates, binaries, and target remote. Symptoms - you are about to tag a release, create a GitHub release, or automate publishing and want to catch the obvious failures before mutating history.

Use when git push, PR creation, or merge flow fails because the current branch has no upstream, the wrong remote is selected, or remote branches have drifted across forges. Symptoms - `git push` says no configured destination, PR tools target the wrong remote, or branch tracking does not match where the work was pushed.

Rust code quality analysis and improvement using the rustqual CLI. Use when the user asks to "run rustqual", "check quality", "fix rustqual findings", "improve quality score", "what does rustqual say", or when you see rustqual output pasted into the conversation. Also use when configuring rustqual.toml, adding qual:allow suppressions, interpreting IOSP/DRY/SRP/TQ findings, or working toward a quality score target. Triggers on any mention of rustqual, quality score percentages, or finding codes like TQ_UNTESTED, VIOLATION, DEAD_CODE, SRP_STRUCT, SRP_MODULE, BOILERPLATE, or TQ_NO_SUT.

Use when analyzing Claude or agent token usage, ccusage reports, output-to-input token ratios, model spend, or ways to lower AI coding costs. Symptoms - the user asks "why is Claude expensive", "analyze token usage", "reduce token usage", "optimize costs", "make agents less verbose", "lower output/input ratio", or shares `ccusage` output. Produces concise technical strategies, model-routing rules, and copy-paste cost-control policies.