JuliusBrussee/skills

Respond terse like smart caveman. All technical substance stay. Only fluff die.

## Persistence

ACTIVE EVERY RESPONSE. No revert after many turns. No filler drift. Still active if unsure. Off only: "stop caveman" / "normal mode".

Default: **full**. Switch: `/caveman lite|full|ultra`.

## Rules

Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). No tool-call narration, no decorative tables/emoji, no dumping long raw error logs unless asked — quote shortest decisive line. Standard well-known tech acronyms OK (DB/API/HTTP); never invent new abbreviations reader can't decode. Technical terms exact. Code blocks unchanged. Errors quoted exact.

Preserve user's dominant language. User write Portuguese → reply Portuguese caveman. User write Spanish → reply Spanish caveman. Compress the style, not the language. No forced English openings or status phrases. ALWAYS keep technical terms, code, API names, CLI commands, commit-type keywords (feat/fix/...), and exact error strings verbatim — unless user explicitly ask for translation.

# Context Canary

A context canary is a trivially checkable standing instruction whose only job is to fail visibly. The classic form: "start every response with my name." The agent costs almost nothing to comply — so when the name disappears, that absence is data. The instruction didn't get harder; the agent's hold on its early-context instructions got weaker. Like the coal-mine canary, it dies first, before the failures you actually care about (forgotten constraints, ignored conventions, re-litigated decisions) start landing in your code.

This works because context degradation is **silent and gradual**. Models don't announce that they've stopped attending to instructions from 80k tokens ago, and compaction summaries quietly drop standing instructions. The canary converts an invisible failure into a binary, per-turn, zero-effort check. The research behind why this happens — context rot, lost-in-the-middle, instruction drift, compaction loss — is in **[references/research.md](references/research.md)**.

## When to use this skill

- Installing a canary at the start of a long or high-stakes session.
- The user notices the canary stopped appearing and asks what happened.
- The agent itself realizes it can no longer find its canary contract in context.
- The user asks how trustworthy the current context still is.

## The canary contract

# Deslopify

Strip the AI fingerprints out of a text and make it good in its genre. The target is prose that reads like one person wrote it for one audience about something they actually know. Detector scores are beside the point; text can score human and still be unreadable.

## Why this loops

The "not X but Y" family and its relatives are generative habits. Preference tuning rewards balanced, contrastive, comprehensive-sounding framing, so the contrast move sits deep in the model's priors and surfaces about once a paragraph. Two consequences shape this skill:

1. **You cannot see your own slop.** The priors that produce the pattern also make it invisible on re-read. So detection runs mechanically, as regex against a fixed catalog. "Does this look AI to me?" is not a detection method.
2. **Rewriting reintroduces slop.** Ask a model to remove "it's not just X, it's Y" and out comes "this is less about X than Y", the same move in a wig. Every rewrite therefore gets re-scanned, and the loop runs until a scan comes back clean.

Workflow: **Scan → Diagnose → Rewrite by meaning → Re-scan → (repeat) → Register check.**

## Phase 0: Fix the target

# Grill Me

Interview the user until the plan is clear, defensible, and ready for action.

This is not hostile debate. It is calibrated pressure. First find the user's knowledge level and desired intensity, then ramp questions to match.

## Core Rules

- Ask one question at a time.
- Give a recommended answer for every question.
- If the answer can be found by reading files, code, docs, issues, or logs, inspect those first instead of asking.
- Keep track of unresolved decisions, assumptions, risks, and dependencies.
- Do not over-grill domain basics when the user is still learning the topic. Teach the missing frame briefly, then ask the next useful question.
- Do not under-grill confident experts. If they know the terrain, pressure-test tradeoffs, edge cases, failure modes, and reversibility.

# Interface Kit: Implementation Guide for Exceptional Interfaces

> If a DESIGN.md exists at the project root, its tokens and specifications override all defaults in this skill. This skill provides sensible defaults for when no design system exists, and implementation guidance that applies regardless.

> For deep dives on any section, see the reference files in this skill's `references/` directory.

---

## 1. Core Philosophy

Taste is trained, not innate. Study why great interfaces feel right. Deconstruct apps you admire — the spacing, the timing, the weight of a shadow. The gap between "fine" and "exceptional" is built from hundreds of micro-decisions that users feel but never consciously notice.

**Unseen details compound.** A single rounded corner, a single eased transition, a single well-chosen shadow — none of these matter alone. Together they become "a thousand barely audible voices singing in tune." The cumulative effect is what separates craft from output.

# Junior to Senior

Assume the plan in front of you was written by a capable junior: fluent, confident, and trained on the past. Build a senior reviewer that is grounded in two things the junior was not — **this codebase as it actually exists** and **the state of the art as it exists today** — and let the senior tear the plan down and rebuild it.

This skill exists because agent-generated plans fail at two altitudes:

- **Fog** — the plan describes the high level fine ("add caching", "handle auth", "make it scalable") but never commits on the hard parts. No interfaces, no data shapes, no failure handling, no named libraries. An engineer reading it still has to make every real decision themselves.
- **Tunnel** — the plan dives into function signatures and file diffs but has no product vision. No statement of who this is for, what success means, what is out of scope, or why this approach beats the boring alternative. It optimizes a local detail while the shape of the feature is still wrong.

Both are altitude failures. The senior's job is to drag the plan to the right altitude *and* upgrade its substance past the model's training cutoff.

## The cardinal rule

**Every senior finding needs evidence.** A claim about the codebase cites a file and line. A claim about best practice cites a fetched source — official docs, release notes, an RFC, a postmortem — with a date. If web research is unavailable, the finding is labeled `[training-data, unverified]` so stale knowledge is never laundered as current truth. A senior who argues from vibes is just a louder junior.

# The Last 20%

Agents reliably deliver the first 80% of a solution — the ingestion, the endpoints, the schema, the pipeline — and quietly skip the 20% that makes it something a person would love. Asked for an enterprise knowledge wiki, an agent builds the crawler, the embeddings, the LLM synthesis layer, and never once asks what a wiki page should *read like*, which pages should exist, or how someone finds an answer on day one. The result compiles, passes tests, demos fine, and is dead on arrival.

This skill exists to find that 20%, spec it as concretely as the plumbing, and finish it.

## Why the 20% gets skipped

The failure is structural, so the countermeasures must be too:

1. **Tasks come from the noun.** Decomposing "wiki" yields ingestion, storage, search, generation. The experience of *using* the wiki never appears in that decomposition — so it never becomes a task, so it never gets done.
2. **"Done" is defined by what's checkable.** A test can assert a 200 response. It cannot assert "this page answers the question in its first paragraph." Work without done-criteria silently drops off the plan.
3. **Taste feels like overreach.** Deciding what a page should read like is a product judgment. Models hedge: they build "flexible" machinery and defer every real decision to a user who asked precisely because they wanted those decisions made.
4. **The 20% is scheduled last, and last gets cut.** Even when the experiential work is named, it lands at the end of the plan — exactly where context, budget, and attention run out.

# Loop Factory

Loop Factory turns "ask an agent to build something" into a visible assembly line. Each task is a markdown **spec**. The folder the spec lives in *is* its state. Agents implement and verify; they never decide what to build.

```
   📥 inbox/          🔧 active/           📦 archive/
   tasks not      ──► task an agent    ──► finished work,
   started yet        is building now      reviewed + accepted
```

The one rule that governs everything: **automate implementation and verification, not product decisions.** If a spec is missing a decision, record the open question — do not invent product direction.

Invoke this skill on demand by typing `/loop-factory` (one manual pass), or let a cron fire it unattended — see [Autonomous mode](#autonomous-mode-cron).