writing-code

Write and audit code against house coding conventions with rule-cited findings.

Updated Aug 6, 2026
One-click install
npx skills add https://github.com/wkentaro/skills --skill writing-code-wkentaro
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: writing-code
Source: https://github.com/wkentaro/skills/tree/main/skills/in-progress/writing-code
Command: npx skills add https://github.com/wkentaro/skills --skill writing-code-wkentaro

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Settling style decisions and auditing code changes against a fixed set of house coding conventions is inconsistent when done from memory. This Skill provides a single authoritative rulebook covering naming, comments, imports, scoping, type annotations, tests, and class design, so style calls and audits cite the same rules every time. ## Core Features & Use Cases - Style calls while writing code: Answer questions like "how do I name this function?" or "should this be a helper?" by quoting the matching rule verbatim. - Change audits: Check a diff or snippet against every rule and report only actual violations as a numbered list with file:line, the rule's section and bold lead-in, and a concrete edit, or report exactly No findings. - Cross-language application: Apply the structural rules beyond Python (scoping, extraction, imports, annotations, real dependencies over mocks) while dropping Python-only spellings like the _ private prefix. - Use Case: While reviewing a pull request, paste the changed test file and receive a numbered findings list flagging the test class, the deferred import, the bare boolean argument, and the missing -> None return annotation, each with its fix. ## Quick Start Use the writing-code skill to audit this change against the house coding conventions and list any rules it breaks.

Frequently Asked Questions about writing-code

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

FAQPage Schema
How do I audit a code change against house coding conventions?▼

Paste the changed code and ask for an audit. The Skill checks every rule and returns a numbered list of only actual violations, each with file:line, the rule's section and bold lead-in quoted verbatim, and a concrete edit. If nothing breaks, it reports exactly "No findings."

How should I name functions according to these conventions?▼

Start function names with a verb naming what they do, such as compute_mask_iou or round_bbox_to_int. Non-verb forms are allowed only for predicates (is_*, has_*), classmethod constructors (from_*), and conversions (to_dict). Noun-only names like mask_iou are rejected.

Do these coding conventions apply to TypeScript or Go?▼

Yes, the structural rules carry over: scoping, extraction, thin entry points, imports, naming, comments, annotations, and real dependencies over mocks. Python-only spellings like the underscore private prefix are dropped, while goals like keyword arguments translate to options objects or named struct fields.

When should I use mocks instead of real dependencies in tests?▼

Prefer real dependencies wherever cheap: existing fixtures, ephemeral subprocesses, dockerized services, or in-memory engines. Reserve mocks for paid third-party APIs, irreversible side effects like payments or emails, and services with no offline mode, since mocks keep passing after the real API changes.

What happens when a style question is not covered by the rules?▼

The Skill states plainly that no rule covers the case instead of inventing a preference. This applies to style calls, audits, and every language, and it outranks giving a complete-sounding answer.

How do linters and formatters interact with the audit?▼

Run the repository's configured formatters, linters, and type checks before auditing. The audit does not repeat their findings or assume rules the repository has not enabled; it covers only judgment calls that tooling cannot prove.