mcpField
J
jww-writing-style

jww-writing-style

github.com/justinProductivity051 installsUpdated 2w ago
Repository

About jww-writing-style

A writing-style skill for drafting and revising prose in Justin’s voice. It emphasizes direct, economical communication while preserving context, technical accuracy, and the limits of what is known.

Key features

  1. 01Direct, point-first writing
  2. 02Natural, ordinary language
  3. 03Clear next steps when relevant
  4. 04Channel- and audience-aware tone
  5. 05Preserves technical detail and uncertainty

Use cases

  1. 01Drafting a Slack update in Justin’s voice
  2. 02Revising an email for clarity and directness
  3. 03Preparing technical discussion prompts
  4. 04Adapting a message for a sensitive audience

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/justin/jww-skills --skill jww-writing-style

After installing, type/jww-writing-stylein Claude Code to confirm it loaded.

Bundled filesagents/openai.yaml

Details

From the project README

Justin's writing style

Write like a technically confident colleague who wants people to understand the point and know what happens next. Favor natural speech, useful detail, and clear expectations over ceremony or conspicuous polish.

Activation and scope

  • Apply when explicitly invoked as $jww-writing-style, or when drafting or revising prose on Justin's behalf in his voice.
  • Follow the requested audience, channel, tone, and format. A specific request for a formal or sensitive message takes precedence over the casual default.
  • Use this as a writing guide, not a personality roleplay or a rule for every response to Justin. Drafting does not authorize sending, posting, or accessing message history.

Rules

  1. Lead with the point. Start with the answer, request, decision, or action. Add context only where the reader needs it; do not assume a new audience shares an existing team's context.
  2. Use ordinary language. Prefer “I'll look into it” to “I'll investigate this issue and provide an update on my findings.” Use contractions and active verbs naturally. Avoid corporate filler and inflated enthusiasm.
  3. Make the next step clear. Include ownership, an ask, or timing when relevant and supported by the supplied facts. Do not force an action item into a message that only needs to inform.
  4. Keep it economical, not cryptic. Use short paragraphs. Use bullets for several distinct items. Preserve reasoning, constraints, and qualifications that affect the recipient's decision.
  5. Be casually authoritative. State expectations plainly, give people room to execute, and explain the reason when it helps. Avoid micromanaging language, condescension, and unnecessary apologies. Keep genuine thanks and apologies when warranted.
  6. Keep technical detail exact. Retain meaningful names, identifiers, distinctions, and uncertainty. Confidence in tone must not turn an estimate into a promise or a hypothesis into a fact.
  7. Let warmth be understated. A simple acknowledgment or thanks is often enough. Dry humor is optional and should fit supplied material and the relationship; never add a joke just to make the voice recognizable.

Adapt to the channel

ChannelDefault treatment
Slack or team chatBrief, conversational, little preamble. Fragments are fine when clear.
EmailSame direct voice with enough context to stand alone. Use a greeting, closing, and complete sentences when appropriate to the relationship.
Technical discussion or ChatGPT promptState the desired outcome, relevant constraints, and the question or next action explicitly. Keep terminology precise.
Sensitive or unfamiliar audienceAdd necessary context, empathy, and polish. Keep the message direct without making it abrupt.

Examples

These are illustrative rewrites, not quotations from Justin. Facts and commitments in them are examples, not reusable promises.

Slack update

Before: “I will review the provided materials and create any additional API-related tickets that may be necessary.”

After: “I'll look through this and add API tickets where needed.”

Status with an estimate

Before: “I am currently consolidating the issues in GitHub and anticipate completing the work within one to two days.”

After: “I'm collecting these in GitHub and will start working through them. Should take a day or two.”

Only retain that estimate if Justin supplied or approved it.

Email request

Before: “I wanted to reach out to see whether you might be able to provide clarification regarding which API version we should utilize.”

After: “Can you confirm which API version we should use? That's the last detail I need before I start.”

The second sentence requires that dependency to be established; otherwise omit it.

Technical disagreement

Before: “There may potentially be some concerns regarding whether this solution adequately addresses the underlying issue.”

After: “I don't think this fixes the underlying issue. The retry still uses the expired token.”

Use the specific explanation only when supported by the provided evidence.

Guardrails and final check

  • Capture the priorities and cadence, not typing accidents. Use normal spelling, capitalization, apostrophes, and punctuation. Do not manufacture lowercase text, missing apostrophes, typos, slang, profanity, or emojis to imitate informality.
  • Do not confuse brevity with coldness or bluntness with hostility. Preserve necessary empathy and accountability.
  • Do not invent experiences, opinions, relationships, deadlines, certainty, or commitments for Justin. Preserve the source's meaning and level of confidence.
  • Do not imitate the analysis's headings, bold emphasis, or explanatory prose: those belong to the analyst, not necessarily Justin.
  • When revising, preserve useful original phrasing. Return one ready-to-use draft unless alternatives or commentary are requested. Ask only when missing information materially affects the message; otherwise omit unsupported details.
  • Before delivering, check: Is the point immediate? Is the next step clear when needed? Are all claims supported? Does it sound natural without performing informality?

Basis and limits

Based on the supplied cached preview of “Writing Style Analysis,” ChatGPT conversation 6ace2afd-3900-83e8-ba56-dcce19f488a5. That analysis describes Justin's email, Slack, and ChatGPT voice as informal, efficient, technically confident, action-oriented, and occasionally dryly humorous; it also emphasizes clarity, conversational authority, and autonomy.

The preview contains two complete Slack examples and ends partway through the analysis. The full conversation and underlying email/Slack history were not available for verification when this skill was created. Channel guidance and illustrative rewrites operationalize the available analysis; they are not additional observed samples. Treat this as a starting guide, and let Justin's corrections and supplied examples refine it.

Comments

Markdown supported