miren-house-style

Write and review Go code matching the Miren runtime team's house style.

Updated Nov 10, 2013
One-click install
npx skills add https://github.com/bnferguson/dotfiles --skill miren-house-style-bnferguson
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: miren-house-style
Source: https://github.com/bnferguson/dotfiles/tree/main/.agents/skills/miren-house-style
Command: npx skills add https://github.com/bnferguson/dotfiles --skill miren-house-style-bnferguson

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Go code written or reviewed by AI assistants often reads as machine-generated — essayistic comments, reflexive doc blocks, and uniform density — and misses the specific conventions the Miren runtime team enforces in review. This Skill encodes the team's actual house style, derived from the mirendev/runtime codebase and roughly 1,600 real review comments by maintainers phinze and evanphx, so contributions look Miren-authored and reviews flag what maintainers actually flag. ## Core Features & Use Cases - Writing mode: Eliminates LLM "tells" (free-floating file-overview prose, essay comments, _ struct{} opts) and applies universal conventions for command handlers, error wrapping with fmt.Errorf("...: %w", err), naming, table-driven tests, concurrency, and import layout. - Reviewing mode: Provides the substantive adjustment catalog maintainers use — reuse over reinvention, scoped error handling, concurrency bounds, lifecycle tracing, security, scope discipline — plus the blocking calculus and suggestion-reply taxonomy. - Sanctioned inconsistencies: Distinguishes universal conventions (flag them) from sanctioned mixed styles like ID vs Id or testify vs plain t.Errorf (never flag them). - Use Case: When reviewing a Miren PR that adds a new CLI command, verify the handler signature func Name(ctx *Context, opts struct{...}) error, check for duplicated helpers, and label each finding blocking or not — exactly as phinze or evanphx would. ## Quick Start Ask the assistant to review this Go pull request against the Miren house style and list which findings are blocking.

Frequently Asked Questions about miren-house-style

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write Go code that matches the Miren house style?▼

Match the surrounding file first, then eliminate LLM tells: no free-floating file-overview prose, no essay comments, no `_ struct{}` for empty opts. Use `func Name(ctx *Context, opts struct{...}) error` handlers, wrap errors with `fmt.Errorf("verb noun: %w", err)`, and keep comment density proportional to subtlety.

What should I flag when reviewing a Miren Go pull request?▼

Flag deviations from universal conventions: wrong handler signatures, re-declared flags instead of FormatOptions embeds, pkg/errors.Wrap in new code, slog key "err", goroutines without ctx.Done arms, and duplicated helpers. Never flag sanctioned inconsistencies like ID vs Id or testify vs plain t.Errorf.

Does the Miren style use testify or plain testing for Go tests?▼

Both are house style. Testify dominates in pkg/ packages while about half of cli/commands test files use plain t.Errorf and t.Fatalf. Use require for preconditions where continuing is pointless and assert for independent comparisons.

Should I use ID or Id in Go identifiers for Miren code?▼

Both are genuinely mixed in hand-written code, so match the surrounding file and never flag it in review. Generated entity code always uses title-case Id with an Id() accessor, while hand-written code leans toward all-caps acronyms like URL and JSON.

When should a review comment be marked blocking in a Miren PR?▼

Reserve blocking for correctness, safety, and merge-safety issues; most substantive notes are non-blocking improvements. CHANGES_REQUESTED acts as a scoped hold for discussion, and deferrals should be filed as MIR-xxxx tickets rather than left vague.