technical-communication

Writes evidence-based technical explanations, reviews, and reports using structured templates.

1|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/D1ssolve/craft-agents --skill technical-communication-d1ssolve
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: technical-communication
Source: https://github.com/D1ssolve/craft-agents/tree/main/skills/technical-communication
Command: npx skills add https://github.com/D1ssolve/craft-agents --skill technical-communication-d1ssolve

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Technical writing often buries the answer under filler, vague claims, and unstructured prose, forcing readers to reconstruct the reasoning themselves. This Skill enforces a clarity-first writing policy so explanations, diagnoses, reviews, and reports are compact, precise, and immediately actionable for a Senior developer audience. ## Core Features & Use Cases - Task-specific templates: Provides ready structures for interview mini-notes, diagnosis-and-fix reports, architecture recommendations, code reviews, and completed-work summaries. - Evidence discipline: Distinguishes observed fact, hypothesis, and recommendation, and prevents overstated claims such as unscoped "exactly once" or "thread-safe" guarantees. - Verification reporting: Separates passed, failed, skipped, and not-run checks with concrete commands and scopes. - Use Case: After debugging a Kafka consumer issue, produce a report following the symptom → evidence → cause → fix → verification → next step structure, with the hypothesis clearly labeled and the smallest distinguishing check stated. ## Quick Start Write a diagnosis report for the duplicate Kafka message processing issue using the technical-communication structure with labeled evidence and verification status.

Frequently Asked Questions about technical-communication

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

FAQPage Schema
How do I write a clear technical diagnosis report?

Follow the symptom → evidence → cause → fix → verification → next step structure. If the cause is unconfirmed, label it as a hypothesis and state the smallest check that distinguishes it from alternatives.

How to structure an interview question and answer guide for senior developers?

Use the eight-part mini-note template: main question, what it tests, a compact theory summary, the safe production approach, typical mistakes, related topics, operational follow-ups, and the minimum signs of a strong answer.

What is the difference between observed fact and hypothesis in technical writing?

Observed fact comes from direct evidence such as logs or test results, while a hypothesis is an unconfirmed explanation. Confusing them can change decisions, so label uncertainty explicitly rather than presenting guesses as findings.

Does this writing policy apply to code review output formats?

Yes, but existing schemas take priority. ADR, specification, review, and handoff formats keep their required structure; the writing rules apply inside them, preserving severity rankings and required fields.

When should claims like exactly-once or thread-safe be avoided?

Avoid unconditional guarantees without their scope. State the version, component, transaction boundary, and failure mode; for example, idempotency prevents duplicate database effects only when the event ID and change commit in one transaction.