acking-you/myclaude-skills/tech-impl-doc

Technical Implementation Docs

The user's explicit instructions override every default below.

Scope and edits

Match the user's audience, scope, voice, structure, and length. Infer obvious choices rather than opening with a questionnaire. Produce the smallest document or edit that fully answers the request.

When editing an existing document:

• Read the current document first.
• Preserve its organization, voice, and unrelated content.
• Patch what was asked. Keep an expansion inside the named section; add a new section only when requested or genuinely necessary.
• Do not rewrite, reorder, or "improve" adjacent material.
• After editing, reread the result and confirm unrelated text is intact.

Evidence

• Lead with the answer, decision, or root cause, then give enough evidence to make it trustworthy.
• Verify implementation-specific claims against source, runtime output, or authoritative docs.
• Keep verified facts, inferences, and open questions visibly distinct.
• If a claim cannot be verified, say so, mark it as an assumption, or leave it out. Do not fill gaps with plausible guesses.
• Define unfamiliar terms near first use, at the reader's level.

Form

• Prefer cohesive prose. Use lists, tables, or diagrams only when they make relationships materially clearer; diagrams are never required.
• Use the fewest, shallowest headings that work. No template sections, executive summaries, or code indexes unless they serve this reader.
• Include commands, paths, line references, failure modes, and trade-offs only when they help the reader reproduce, navigate, decide, or operate safely.
• Skip generic introductions, boilerplate, and sentences that restate a heading.
• Before finishing, check for repetition, scope creep, unsupported claims, and needless headings.