--- name: tech-writer description: How to author, audit, and refresh Gobby technical documentation. Use when writing or rewriting a guide, validating an existing doc against the codebase, generating Mermaid diagrams, or explaining a technical concept to docs readers. category: engineering version: "1.0.0" triggers: - tech writer - technical writing - write documentation - audit documentation - refresh guide - validate doc - mermaid diagram - explain concept tags: - gobby - docs metadata: gobby: audience: all depth: 0 --- # Tech Writer Methodology for authoring, auditing, and maintaining Gobby's technical documentation. Covers `docs/guides/`, in-repo READMEs, architecture notes, and inline reference material. For design-surface copy (product UI, marketing, installer), the canonical authority is `.impeccable.md` — read it before touching any UI string. ## Principles - **Write for the reader's task, not the author's checklist.** A guide exists to make the reader successful, not to enumerate features. - **A diagram beats a thousand-word paragraph.** When structure, flow, or state transitions are involved, lead with Mermaid; let prose explain only what the diagram cannot. - **Audience-aware depth.** Operator docs assume terminal fluency; contributor docs assume the codebase; user docs assume nothing. Don't mix levels in one doc — split it. - **One source of truth.** If a fact lives in code (a CLI flag, an MCP tool signature, an HTTP route), the doc cites the code, never restates it from memory. Drift kills docs faster than anything else. - **Diátaxis where it fits.** Tutorials, how-to guides, reference, and explanation each have a different shape. Don't blend them in one document. ## Capabilities | Operation | When to use | |-----------|-------------| | **Write** a new document | Net-new guide, feature launch, new MCP server, new CLI surface | | **Audit/refresh** an existing document | Code has drifted from docs, periodic freshness pass, post-refactor cleanup | | **Mermaid diagram** | Sequence, flow, state, ER, or architecture visualization carries more signal than prose | | **Explain** a concept | Reader needs the *why*, not the *how* — architecture rationale, design trade-offs, mental model | The four operations below are inline methodology, not separate dispatchable modes. Pick the one that matches the ask and follow its process. ## Writing a Document 1. **Discover intent.** Ask until scope, audience, and purpose are concrete. Refuse to draft a guide whose audience you cannot name. 2. **Locate authority.** Identify the source-of-truth code (a CLI module, MCP tool, route file). Every concrete claim in the doc must trace back to a file path or symbol you can `gcode search` or `Read`. 3. **Outline before prose.** Headings first; verify the structure makes sense to the target reader before writing paragraphs. 4. **Draft.** Lead each section with the action or the answer; put background below. Use fenced code blocks for any command, config, or API shape. 5. **Diagram where structure matters.** State machines, dispatch flows, request lifecycles — Mermaid them. 6. **Cross-link.** If another guide owns a concept, link to it; do not re-explain. 7. **Footer.** Add `_Last verified: YYYY-MM-DD_` as the final line so future auditors can see freshness at a glance. 8. **Index.** Update `docs/guides/README.md` so the new guide is discoverable. ## Auditing / Refreshing a Document This is the dominant mode in Gobby — most doc work is keeping existing guides honest. Apply the eight-point checklist established by the audit epic: 1. Every CLI command, flag, MCP tool name, MCP server name, CLI subcommand, and HTTP route mentioned in the guide exists in the current codebase (verify via `gcode search`, `gobby --help`, or route inspection in `src/gobby/servers/routes/`). 2. No references to retired concepts. Maintain a project-specific deny-list when refactors retire terms — for Gobby today: `orchestrator`, `conductor`, `developer` agent, `pipeline-worker`, `terminal` agent mode (renamed `interactive`), `list_pipeline_executions`, `search_pipeline_executions` (renamed `pipeline_runs`), `lobster`, `mem0`, `tool-compression`, `workflow-actions`. 3. All inter-guide links resolve to existing files in `docs/guides/`. 4. Code blocks showing CLI/MCP/HTTP usage match current signatures (no positional/keyword drift). Re-fetch tool schemas with `get_tool_schema(server, tool)` rather than recalling them. 5. Architecture references align with current `CLAUDE.md` (dispatch architecture, plan-coverage contract, stage-manifest model). 6. If guide is < 100 lines and content overlaps another guide, justify keeping it standalone or merge it. Two thin guides that overlap is worse than one complete guide. 7. Update the `_Last verified: YYYY-MM-DD_` footer on completion. 8. Update `docs/guides/README.md` if the guide was renamed, deleted, or merged. When the audit finds a guide that is obsolete (feature removed, replaced by another guide, or stub-quality with no path forward), prefer **delete** over preserve. Stale docs are worse than missing docs because they actively mislead. Update the index and any inbound links when removing. ## Generating Mermaid Diagrams 1. Pick the diagram type up front: `flowchart`, `sequenceDiagram`, `stateDiagram-v2`, `classDiagram`, `erDiagram`, `gantt`. State the choice before drawing. 2. Use stable IDs (`A`, `B`, `node1`) and human labels (`A[Reader]`); never put long sentences inside node labels. 3. Render inside a fenced ` ```mermaid ` code block so GitHub/Sphinx/MkDocs can hand it to a renderer. 4. Test the diagram with the Mermaid live editor or a local renderer before committing — silent syntax errors break the whole page in some renderers. 5. Constrain layout: `direction LR` or `direction TB` for flowcharts when the default makes the diagram unreadable. 6. For sequence diagrams of dispatch or hook flows, name the actors after the real subsystems (`Dispatcher`, `RuleEngine`, `AgentRunner`) so the diagram maps 1:1 to code. ## Explaining a Concept 1. **Anchor.** Open with the one-sentence definition the reader can carry away even if they read nothing else. 2. **Motivate.** Why does this exist? What was broken before it? Skip when the answer is obvious. 3. **Demonstrate.** A minimal worked example — code, command, or diagram — beats abstract description. 4. **Bound.** State what the concept is *not* responsible for. Misuse of a concept usually traces back to an unbounded explanation. 5. **Link.** Point to the canonical reference doc and the code that implements it. ## Gobby Conventions ### File locations - Bundled guides: `docs/guides/.md` - Index: `docs/guides/README.md` (must include every linked guide) - Design system: `.impeccable.md` (root) — authoritative for any UI/color/typography/copy work - Architecture and contracts: `docs/contracts/` - Research drafts: `docs/research/` (not user-facing — do not link from `docs/guides/`) ### Cross-references Use relative paths (`./tasks.md`, not `/docs/guides/tasks.md`) so links resolve in both GitHub view and local clones. Verify every link before closing the task. ### Source-of-truth lookups - CLI commands → `src/gobby/cli/` (use `gobby --help` to confirm runtime visibility, since some commands gate on feature flags) - MCP tools → `src/gobby/mcp_proxy/tools/` and `get_tool_schema(server, tool)` - HTTP routes → `src/gobby/servers/routes/` - Hook events → `src/gobby/hooks/events.py` and `src/gobby/hooks/hook_types/` - Agent definitions → `src/gobby/agents/definitions.py` and `src/gobby/install/shared/agents/` - Dispatch architecture → `src/gobby/dispatch/rules.py` plus the dispatch section of `CLAUDE.md` ### Commit and close Doc work is real work — claim a Gobby task, commit the changes, validate against the task's acceptance criteria, and close. Closing a docs task without a commit is blocked by Gobby rules. Treat a half-finished refresh as unfinished, not as merge-ready. ### Freshness footer End every guide with `_Last verified: YYYY-MM-DD_` on its own line. The date reflects when the doc was last cross-checked against the codebase, not when prose was last edited. The footer is the cheapest staleness signal an auditor has. ## Boundaries - Do not invent CLI flags, tool names, or routes — verify or omit. - Do not document features that aren't shipped. Forward-looking text belongs in `docs/research/` or a plan, not `docs/guides/`. - Do not blend Diátaxis modes. A how-to that turns into an explanation halfway through is a sign the doc should be split. - Do not edit `.impeccable.md` freehand — that file is updated through the `impeccable` skill's `teach` mode. - Do not rely on memory for tool signatures. Fetch the schema, then write. _Last verified: 2026-05-04_ --- Source attribution: GobbyAI Original project: https://github.com/GobbyAI/gobby/blob/45b0ea0e6a1d93bc9815269c94ada8b4ed743476/src/gobby/install/shared/skills/tech-writer/SKILL.md License: Apache-2.0 License information: https://www.apache.org/licenses/LICENSE-2.0 Original upstream instructions; downloaded from Mega AI Hub. ## Upstream license notice # Apache License Version 2.0, January 2004 TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1\. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to the Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2\. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3\. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4\. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5\. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6\. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7\. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8\. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9\. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Copyright 2026 GobbyAI SPDX-License-Identifier: Apache-2.0 # Mega AI Hub resource metadata Creator / publisher: GobbyAI Original project: https://github.com/GobbyAI/gobby/blob/45b0ea0e6a1d93bc9815269c94ada8b4ed743476/src/gobby/install/shared/skills/tech-writer/SKILL.md Attribution basis: Source repository record Fields of work: Content & Media, Design, Product Management Roles: Product Manager, Technical Writer, UX Writer Specialties: API Tools: Gobby Country applicability: Country not specified Classification basis: Source catalog labels Instruction SHA-256: 733a64d716064940bfbf32806c32b578e0d01d4d86aa36d189172f450e6d7c62