skillforge

Compute Claude Code token usage by model for any date range from local session transcripts. Use this whenever the user asks how many tokens they used, their Claude Code / Claude subscription usage, usage for a month or week or day, a "usage report", per-model token breakdown, or "how much did I spend/use" over some period — including phrasings like "first week of June", "last 7 days", "June 2026", or "yesterday". This is the right tool on the subscription plan, where console.anthropic.com does NOT show usage. Trigger even when the user just names a period and the word "usage" without saying "tokens".

WalkInto.in virtual tour platform and helpdesk — authenticate, view profile, manage 360 tours, search the knowledge base, and run the support ticket lifecycle. Use this skill whenever the user mentions 'walkinto', a WalkInto account, virtual/360 tours, panorama uploads, tour analytics, OR the WalkInto helpdesk: support tickets, customer questions, knowledge-base/KB articles, replying to or triaging tickets, ticket status/priority/tags, or 'who am I on walkinto'.

Evaluate whether the lean-ctx MCP is saving more context tokens than it costs, for the current project, using that project's Claude Code session transcripts. Measures ctx_read with a per-call counterfactual vs native Read, compares ctx_shell against native Bash observationally, nets out the per-session instruction+schema tax, and reports a token ledger. Use when asked to eval lean-ctx, measure context-compression savings, audit token usage of an MCP, or decide if lean-ctx earns its seat.

Inspect a project and recommend developer tooling (LSP, AST, test runners, debuggers, linters) that would make Claude Code most effective. Provides exact install commands and a verify mode to confirm each tool works.

In-browser annotation overlay for HTML, Markdown, and plain-text documents. Use when a user wants to annotate a document, run a structured review pass with severities (typo / edit / rewrite), or apply review comments back into source files via Claude Code.

Use when a model emits multiple tool calls in a single turn and the harness must execute them in parallel safely, or when subagents/forks run concurrently and share state. Apply when designing the concurrency model for tool dispatch. Covers parallel tool execution, ordering guarantees, cancellation propagation, race detection on shared resources (filesystem, db), partial-failure semantics, and result aggregation.

Use when an agent harness needs user- or admin-configurable interception points — before/after tool calls, on prompt submit, on stop, on session start. Apply when designing the event/hook architecture that lets operators inject policy, logging, or transformation without modifying core harness code. Covers event taxonomy, blocking vs non-blocking hooks, hook contract (stdin/stdout/exit-code), failure modes, and security implications.

Use when an agent's conversation or working memory grows past the model's context window, or when long sessions accumulate stale tool output, repeated reads, and verbose traces that crowd out signal. Apply when designing how a harness summarizes, prunes, tiers (hot/warm/cold), or evicts history without losing load-bearing facts. Covers compaction triggers, summarization strategies, lossy vs lossless tradeoffs, and recovery from over-compaction.

Use when an agent harness has access to multiple models (Opus/Sonnet/Haiku, or cross-vendor) and must pick the right one per turn based on capability, cost, latency, or load. Apply when designing the routing layer that sits in front of model invocation. Complements graceful-degradation (which covers fallback on failure); this skill covers proactive capability/cost routing. Covers routing signals, classifier design, cost ceilings, and stickiness vs per-turn re-routing.

Use when an agent harness must classify tool calls by risk and decide which require human approval, which run automatically, and which are denied outright. Apply when building the permission/policy layer that sits between the model's tool-call output and execution. Covers risk classification (read/write/destructive/exfil), allowlist/denylist design, approval UX, irreversibility detection, scope-bound consent, and audit logging.

Use when an agent harness makes repeated calls with large shared prefixes (system prompt, tool schemas, prior turns) and inference cost or latency matters. Apply when designing cache breakpoint placement, TTL selection, and turn structure to maximize hit rate. Covers Anthropic prompt cache mechanics (5-min/1-hour TTL, breakpoint rules, cache-aware ordering), measurement, and common pitfalls that silently break caching.

Use when an agent harness must respect upstream model/tool rate limits, manage quotas across concurrent sessions, and handle 429s without dropping work. Apply when designing the queue/throttle layer in front of model and tool calls. Covers token-bucket vs leaky-bucket, per-key vs global quotas, backoff strategies (exponential, jittered), queue fairness across sessions, and 429/Retry-After handling.

Use when an agent harness must survive process restarts, resume interrupted work, fork a session for parallel exploration, or replay a transcript for debugging. Apply when sessions span hours/days, when crash recovery matters, or when humans need to audit/replay agent runs. Covers checkpoint format, transcript stores, fork/branch semantics, resume-from-step, and idempotent replay.

Use when an agent harness must stream model output to the user in real time, dispatch tool calls mid-stream, or support cancellation before generation completes. Apply when building the IO layer that mediates between the model's token stream and the user/UI. Covers SSE/streaming protocols, partial JSON parsing, mid-stream tool-call dispatch, cancellation propagation, backpressure, and reconnect semantics.

Use when a single agent loop is insufficient and work must be delegated to subagents — for context isolation, parallel exploration, specialized capability, or scope reduction. Apply when designing how a parent agent spawns, briefs, monitors, and merges results from child agents. Covers fork-vs-fresh-subagent tradeoffs, prompt briefing rules, isolation modes (worktree, sandbox), result merging, and failure containment.

Use when an agent harness needs operational visibility — token spend per turn/session, latency breakdown, tool-call success rates, and the ability to replay/debug a specific run. Apply when designing the observability layer for production agents. Covers span trees (turn → tool-call → subagent), token/cost attribution, structured logging, replay format, and the difference between eval (quality) and telemetry (ops).

Use when LLM-invoked tools execute code, touch the filesystem, or make network calls — and you need to bound their blast radius. Apply when designing the isolation boundary for tool execution in an agent harness. Covers filesystem jails, network egress controls, exec sandboxes (containers, gVisor, firecracker, seatbelt/landlock), capability-scoped credentials, and the difference between safety sandboxing and security sandboxing.

Use when an agent operates on a filesystem workspace and the harness must track which files have been read, edited, or moved — so tool calls can detect stale reads, prevent conflicting writes, and enforce read-before-edit invariants. Apply when designing the workspace/cwd state model. Covers file-state tracking, mtime/hash invariants, cwd persistence across tool calls, diff awareness, and external-mutation detection.

Expert in Freshdesk helpdesk API for building integrations, extracting support data, managing tickets/contacts/companies, managing knowledge base (Solutions — categories, folders, articles), and automating support workflows. Use when working with Freshdesk, building helpdesk integrations, analyzing support ticket data, managing help center content, or creating customer support applications.

LLM extension security analysis — threat model, attack patterns, and heuristics for evaluating Claude Code plugins and skills for prompt injection, hook script abuse, permission escalation, and data exfiltration. Load when reviewing any LLM extension, skill pack, or agent for security.

Use when external system types, vocabulary, or conventions bleed into your domain model, a single provider change would require touching many internal files, or a legacy system must keep running while a new one is built alongside it. Apply before writing any integration with an external API, legacy codebase, or third-party service. Covers Anti-Corruption Layer, Gateway, Facade, and Strangler Fig.

Use when behaviour varies across cases, accumulates conditionals, or needs to be decoupled, queued, undone, or observed. Apply when a method is growing if/switch branches, an algorithm differs per context, a pipeline needs flexible steps, or objects need to react to each other without tight coupling. Covers all 10 GoF behavioural patterns.

Use when read and write performance requirements diverge significantly, complex reporting is painful through the domain model, or you need to scale reads and writes independently. Apply before splitting any command/query handler or building read-optimised projections. Covers Command Query Responsibility Segregation — including when it is overkill — with guidance on applying only as much separation as the problem demands.

Use when object creation is the source of pain — constructors growing too complex, the same setup repeated, unclear which concrete type to instantiate, or a shared instance causing hidden coupling. Apply before writing any factory, builder, or instantiation logic. Covers all 5 GoF creational patterns: Singleton, Builder, Factory Method, Abstract Factory, Prototype.

Use when persistence logic bleeds into domain or business code, tests require a real database to verify business logic, ORM types appear in service or handler code, or switching storage would require touching domain classes. Apply before writing any database query, repository, or ORM integration. Covers Repository, Unit of Work, Data Mapper, and Active Record with explicit guidance on when each applies.

Use when aggregates need to stay loosely coupled, side effects (emails, audit logs, projections) are tangled into domain operations, or one aggregate directly calls methods on another. Apply when something significant happens in the domain that other parts of the system need to react to without being tightly coupled. Covers Domain Events, publishing patterns, synchronous vs asynchronous handling, idempotency, and eventual consistency trade-offs.

Use when business objects have no behaviour (anemic model), invariants are enforced in services or controllers instead of domain classes, ownership of business rules is unclear, or the code allows states the business forbids. Apply before designing or reviewing any business domain class. Covers DDD tactical patterns: Entity, Value Object, Aggregate, Aggregate Root.

INVOKE THIS FIRST before choosing, introducing, or reviewing any design pattern. Use when you are about to add a pattern, refactor toward one, or assess whether existing code uses the right one. Maps the friction you feel to the pattern that removes it — start from the pain, not from a pattern name.

Use when business logic leaks into controllers or handlers, services contain both orchestration and domain decisions, the boundary between use-case coordination and domain rules is unclear, or domain objects have no behaviour. Apply before designing or reviewing any service class. Covers Application Service, Domain Service, and Service Layer — with explicit rules for what belongs where.

Use when the pain is about how objects fit together — incompatible interfaces, subsystems too complex to use correctly, needing to add behaviour without subclassing, controlling access, or managing hierarchical structures. Apply when external types bleed into domain code, composition is hard to manage, or a subsystem requires too many steps in the right order. Covers all 7 GoF structural patterns.

Use when a task requires autonomous multi-step reasoning — the LLM must observe, decide, act, and iterate until a goal is met or a termination condition is reached. Apply when a single prompt cannot solve the task, the number of steps is not known in advance, and the next step depends on the result of the previous one. Covers ReAct, Plan-and-Execute, state management, termination, and guardrails for autonomous agents.

Use when you cannot systematically measure whether your LLM feature is working correctly. Apply when testing is based on vibes rather than metrics, when you cannot detect regressions after prompt changes, or when production quality is unknown. Covers evaluation datasets, metrics, regression testing, LLM-as-judge, and production monitoring for non-deterministic systems.

Use when an LLM-powered feature must remain functional when the primary model is slow, down, over budget, or producing low-quality results. Apply when building any production AI feature that users depend on. Covers fallback chains, semantic routing, circuit breakers, cost management, and degradation levels.

Use when LLM inputs or outputs must be validated for safety, policy compliance, schema conformance, or content appropriateness before they reach users or downstream systems. Apply when LLM responses could contain harmful content, PII leakage, prompt injection, off-topic responses, or policy violations. Covers input validation, output validation, content filtering, and prompt injection defence.

INVOKE THIS FIRST before designing any LLM-powered feature. Use when integrating an LLM as a component in a software system — not as a chat interface, but as a decision-making, data-processing, or logic-executing building block. Maps the friction you feel to the pattern that removes it.

Use when prompts are ad-hoc strings scattered through code, hard to test, version, or maintain. Apply when building any LLM-powered feature to ensure prompts are treated as first-class engineering artifacts — versioned, tested, composable, and separated from application logic. Covers prompt structure, template patterns, few-shot design, chain-of-thought, and prompt chaining.

Use when LLM responses must be grounded in factual, up-to-date, or domain-specific data that the model was not trained on. Apply when the LLM hallucinates facts, gives outdated information, lacks knowledge of proprietary data, or needs to cite sources. Covers Retrieval-Augmented Generation — retrieval strategies, chunking, ranking, context assembly, and when simpler alternatives suffice.

Use when LLM output must conform to a specific schema, type, or format — JSON responses, typed function returns, database records, API payloads. Apply when free-text LLM output breaks downstream parsing, requires fragile regex extraction, or produces inconsistent shapes across calls. Covers schema enforcement, output typing, validation, and error recovery.

Use when an LLM is repeatedly performing a task that could be codified as a deterministic or semi-deterministic script, tool, or function. Apply when inference cost, latency, or non-determinism is the pain — the LLM evaluates whether to generate a reusable artifact that replaces itself for a class of inputs. Covers the decision framework, generation strategies, hybrid deterministic/probabilistic routing, validation of generated tools, and lifecycle management.

Use when an LLM needs to interact with external systems — calling APIs, querying databases, reading files, executing code, or performing actions with side effects. Apply when the LLM must go beyond text generation to retrieve live data, perform calculations, or trigger real-world operations. Covers tool definition, invocation patterns, safety boundaries, and error handling.