How Kiluth writes operational documentation: human-first, simple, minimal, concrete, data-first, structured, and flexible. Defines tone, minimum structure, checkpoints vs decision points, handoff rules, and before/after examples. Ensures docs are easy to follow, maintain, and execute under pressure.
Understand the exact structure, phase/step format, and TOC for official docs
Scope
This standard applies to all Kiluth official operational docs across departments (Technology, Marketing, Finance, Legal, Delivery, Creative, HR, Account Management).
Includes
1
Tone and writing style
2
Minimum structure and formatting rules
3
How to write checkpoints / decision points and handoffs
Operating Model
This document follows Kiluth’s standard operating model. See Onboarding Guideline for details on using Asana, checkpoints, decision points, and handoff processes.
Operating Model
1
Asana is the system of record for work tracking, approvals, and handoffs.
2
Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit.
Write for a real person doing real work. Assume they are busy. Reduce reading and cognitive load. Make each step easy to find and follow by breaking complex processes into granular, individual sections.
Simple
Prefer short sentences and common words. Remove filler (“in order to”, “it is important to”).
Minimal
Keep only what prevents mistakes or resolves common confusion. If it’s not used, remove it.
Concrete
Use “do X, paste link Y here, proceed when Z is true”. Prefer examples, templates, and checklists. Include numbered process descriptions within each step to show exactly what needs to happen.
Scientific / data-first
Prefer facts, artifacts, timestamps, links, and proofs over opinions and memory.
Structured
Use consistent headings, 2-column tables for processes/lists, and explicit owners for handoffs. Break each major step into its own section for easier navigation and comprehension.
Flexible
Define a default path, but allow exceptions via explicit decision points and documented deviations.
Document Structure (Minimum)
All Kiluth official docs should include:
Required
1
Title (H1)
2
Department block with link to parent (e.g. [Creative](creative/))
3
Summary section (2–3 sentences after Department)
4
## Table of Contents (always present; 2-column table)
5
A step-by-step section for the core workflow (when it’s a process doc)
6
Roles/owners for handoffs (who creates the next task / who approves / who links proof)
For process documents, use a phase- and step-based (tutorial-style) structure. See Official Docs Format Guide for the exact phase/step headings and TOC format.
Recommended when relevant:
Recommended
1
Usage section (for process documents): Explains how to use the document step-by-step, what each section describes, and when to follow sections in order
2
Overview section (for process documents): Provides high-level context about the process flow before diving into detailed steps
3
Granular step structure: Break each major step into its own section (H2) rather than grouping all steps under a single “Step-by-Step Process” section. This makes the flow easier to follow and navigate
4
Process descriptions: Include numbered lists within each step showing what needs to happen (e.g., “PM estimation process: 1. Review scope, 2. Consider complexity, 3. Estimate range…“)
5
Asana card templates inline at each handoff step (Title / Assignee / Description); no standalone template section. Task titles and descriptions must be actionable and self-explanatory—do not reference step numbers (e.g. “Step 3”) in text the assignee sees.
6
A short checklist at the end (only if the workflow has multiple handoffs/steps)
7
Decision points in an `Outcome
Language & Terminology Rules
Topic
Rule
”Gate” wording
Avoid “gate”. Use checkpoints for step validation and decision points for branching.
Sign-off
Prefer “sign-off proof” language and always make it linkable from Asana. If contract-related, require signed document.
Avoid policy-enforcement tone
Prefer “proceed when…” over “must / cannot” unless the rule prevents real risk.
Handoffs
Always specify: owner → artifact(s) → where to link → what “done” means.
Examples (Before / After)
Before (too vague)
After (Kiluth style)
“Make sure the client is aligned before proceeding."
"Proceed when the client sign-off proof is linked in Asana: Sign-off proof: [Link] (meeting minutes or signed doc; signed doc required for contract-related decisions)."
"Go-live should be done carefully."
"In the go-live task, write: (1) rollback plan link, (2) verification checklist, (3) execution window, (4) result: Verified / Rolled back.”
Checklist (Writer Use)
Checklist
1
☐ Every step is actionable (someone can do it without guessing)
2
☐ Every handoff has an owner + artifact + link location + exit criteria
3
☐ Checkpoints/decision points are explicit (no hidden branching)
4
☐ Asana templates are inline at handoff steps (no standalone template section); task titles/descriptions are actionable and do not reference step numbers
5
☐ The doc is shorter than it wants to be (removed nice-to-have text)
6
☐ Terms are consistent across departments (same labels where possible)