herdr-planner-profile

Read and apply Courier architecture decision records. Use when planning, reviewing, or implementing changes with architecture, infrastructure, interface, routing, or cross-service impact.

Write, review, or ingest implementation blueprints. Use when formalizing an explored design, auditing a blueprint before implementation, or loading one as implementation context.

Enforces the Linear proof boundary for planning, implementation, review, readiness, and merge. Use for multi-surface work, ownership or plan changes, exact-head evidence, Scope Review, or moving a ticket to Done.

Reconcile engineering project state from a Linear project URL or parent issue using Linear, GitHub PRs, and the local git repo: status, what changed, blockers, ticket-to-PR links, tracker drift, next work items.

Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's comprehensive "Signs of AI writing" guide. Detects and fixes patterns including: inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, negative parallelisms, and excessive conjunctive phrases.

Evidence-based implementation planning without edits.

Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests (general knowledge, prose, translation, summaries, recipes).

Break down a task into one well-defined ticket for one engineer (Linear, Jira, GitHub Issues). Use for "make a ticket for X", "write this up", filing an issue, or a vague idea. Read any parent issue and file as a child.