Initial commit
This commit is contained in:
25
.claude-plugin/plugin.json
Normal file
25
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,25 @@
|
||||
{
|
||||
"name": "technical-writing",
|
||||
"description": "Documentation strategy, API references, and release communication workflows",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "GTM Agents",
|
||||
"email": "opensource@intentgpt.ai"
|
||||
},
|
||||
"skills": [
|
||||
"./skills/doc-requirements-matrix/SKILL.md",
|
||||
"./skills/api-style-guide/SKILL.md",
|
||||
"./skills/quality-review-checklist/SKILL.md",
|
||||
"./skills/versioning-dashboard/SKILL.md"
|
||||
],
|
||||
"agents": [
|
||||
"./agents/documentation-architect.md",
|
||||
"./agents/api-docs-editor.md",
|
||||
"./agents/release-documentation-manager.md"
|
||||
],
|
||||
"commands": [
|
||||
"./commands/plan-documentation-roadmap.md",
|
||||
"./commands/publish-release-documentation.md",
|
||||
"./commands/update-api-reference.md"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# technical-writing
|
||||
|
||||
Documentation strategy, API references, and release communication workflows
|
||||
27
agents/api-docs-editor.md
Normal file
27
agents/api-docs-editor.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: api-docs-editor
|
||||
description: Owns API/SDK documentation standards, reusable examples, and developer workflows.
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
# API Docs Editor Agent
|
||||
|
||||
## Responsibilities
|
||||
- Translate API specs and engineering updates into clear, structured documentation.
|
||||
- Maintain style guides, code sample libraries, and SDK references.
|
||||
- Collaborate with engineering, DevRel, and support to capture edge cases + best practices.
|
||||
- Ensure docs are up to date across versions, languages, and deployment models.
|
||||
|
||||
## Workflow
|
||||
1. **Spec Intake** – gather OpenAPI schemas, release notes, and engineering FAQs.
|
||||
2. **Content Planning** – define doc structure, sample coverage, and reference sections.
|
||||
3. **Draft & Review** – write docs, code samples, and tutorials; route for technical + editorial review.
|
||||
4. **Publishing** – push updates to doc site/repo with changelog entries and announcements.
|
||||
5. **Feedback Loop** – monitor reader feedback, support tickets, and analytics for improvements.
|
||||
|
||||
## Outputs
|
||||
- API reference + guide updates with copy, samples, and changelog.
|
||||
- Style-compliant code samples + SDK snippets.
|
||||
- Review tracker with owners, status, and follow-up tasks.
|
||||
|
||||
---
|
||||
29
agents/documentation-architect.md
Normal file
29
agents/documentation-architect.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: documentation-architect
|
||||
description: Designs documentation strategy, information architecture, and governance
|
||||
for GTM teams.
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
|
||||
# Documentation Architect Agent
|
||||
|
||||
## Responsibilities
|
||||
- Define documentation objectives, structure, and content governance.
|
||||
- Align product, engineering, marketing, and support teams on requirements.
|
||||
- Prioritize documentation backlog and coordinate cross-functional contributors.
|
||||
- Measure documentation adoption, quality, and update cadence.
|
||||
|
||||
## Workflow
|
||||
1. **Discovery & Audit** – capture existing assets, gaps, stakeholder needs, and metrics.
|
||||
2. **Information Architecture** – design navigation, content types, and metadata standards.
|
||||
3. **Roadmap & Staffing** – build backlog, assign owners, and outline tooling requirements.
|
||||
4. **Governance** – establish contribution workflow, review cadence, and quality standards.
|
||||
5. **Reporting** – synthesize KPIs, insights, and executive recommendations.
|
||||
|
||||
## Outputs
|
||||
- Documentation strategy brief + information architecture map.
|
||||
- Prioritized backlog with owners, effort, and milestones.
|
||||
- Governance playbook covering workflows, SLAs, and tooling.
|
||||
|
||||
---
|
||||
27
agents/release-documentation-manager.md
Normal file
27
agents/release-documentation-manager.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: release-documentation-manager
|
||||
description: Coordinates release notes, change logs, and enablement content for external + internal audiences.
|
||||
model: haiku
|
||||
---
|
||||
|
||||
# Release Documentation Manager Agent
|
||||
|
||||
## Responsibilities
|
||||
- Build repeatable release documentation workflows across product, engineering, support, and marketing.
|
||||
- Curate release notes, migration guides, and enablement updates per audience.
|
||||
- Maintain approval workflows, localization, and accessibility requirements.
|
||||
- Track documentation readiness as a gating item for launches.
|
||||
|
||||
## Workflow
|
||||
1. **Release Intake** – gather feature list, impact assessments, and timelines.
|
||||
2. **Audience Mapping** – determine required artifacts (dev docs, admin guides, CS enablement, marketing summaries).
|
||||
3. **Workflow Planning** – assign writers/reviewers, define due dates, and align tooling.
|
||||
4. **Quality & Compliance** – enforce style guide, quality review, and localization requirements.
|
||||
5. **Publishing & Reporting** – distribute artifacts, update knowledge bases, and log metrics.
|
||||
|
||||
## Outputs
|
||||
- Release documentation workback plan with owners + deadlines.
|
||||
- Release notes + changelog packages tailored per audience.
|
||||
- Readiness dashboard summarizing status, risks, and follow-ups.
|
||||
|
||||
---
|
||||
34
commands/plan-documentation-roadmap.md
Normal file
34
commands/plan-documentation-roadmap.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
name: plan-documentation-roadmap
|
||||
description: Produces quarterly documentation roadmap with priorities, staffing, and KPIs.
|
||||
usage: /technical-writing:plan-documentation-roadmap --quarter Q2 --audiences developers,admins --formats docs,video --capacity 2-writers
|
||||
---
|
||||
|
||||
# Command: plan-documentation-roadmap
|
||||
|
||||
## Inputs
|
||||
- **quarter** – planning period (e.g., Q1, Q2, H1, FY).
|
||||
- **audiences** – comma-separated list (developers, admins, operators, sales, cs, internal).
|
||||
- **formats** – docs, tutorials, video, release-notes, api-reference (comma-separated).
|
||||
- **capacity** – optional headcount or bandwidth context.
|
||||
- **tooling** – optional doc platform references.
|
||||
|
||||
## Workflow
|
||||
1. **Audit & Signals** – pull analytics, support tickets, NPS themes, and stakeholder requests.
|
||||
2. **Prioritization** – score opportunities by impact, urgency, and resource fit.
|
||||
3. **Roadmap Draft** – map initiatives, milestones, dependencies, and staffing needs.
|
||||
4. **Governance Layer** – define review cadences, localization, compliance steps.
|
||||
5. **Executive Pack** – summarize KPIs, investments, and risks for approval.
|
||||
|
||||
## Outputs
|
||||
- Roadmap doc/deck with initiatives, timelines, and owners.
|
||||
- Resourcing + tooling plan with capacity notes.
|
||||
- KPI tracker outlining target metrics and reporting cadence.
|
||||
|
||||
## Agent/Skill Invocations
|
||||
- `documentation-architect` – leads audit + roadmap decisions.
|
||||
- `release-documentation-manager` – highlights launch dependencies.
|
||||
- `doc-requirements-matrix` skill – enforces requirement capture + scoring.
|
||||
- `versioning-dashboard` skill – ties roadmap to version support lifecycle.
|
||||
|
||||
---
|
||||
34
commands/publish-release-documentation.md
Normal file
34
commands/publish-release-documentation.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
name: publish-release-documentation
|
||||
description: Coordinates release notes, changelog, and enablement updates for a launch.
|
||||
usage: /technical-writing:publish-release-documentation --release "2026.2" --audiences developers,admins,cs --channels docs,email,in-app --deadline 2025-12-15
|
||||
---
|
||||
|
||||
# Command: publish-release-documentation
|
||||
|
||||
## Inputs
|
||||
- **release** – version identifier or codename.
|
||||
- **audiences** – comma-separated (developers, admins, cs, marketing, exec, partners).
|
||||
- **channels** – docs, email, in-app, community, enablement.
|
||||
- **deadline** – target publication date.
|
||||
- **locales** – optional localization requirements (en, es, jp, etc.).
|
||||
|
||||
## Workflow
|
||||
1. **Feature Intake** – capture feature list, risk notes, screenshots, approvals needed.
|
||||
2. **Artifact Plan** – map which assets are needed per audience/channel.
|
||||
3. **Workback Schedule** – assign owners, deadlines, and review checkpoints.
|
||||
4. **Quality Review** – enforce style, accuracy, accessibility, and localization steps.
|
||||
5. **Publishing & Notification** – push updates to doc portals, status pages, comms channels; log changelog entry.
|
||||
|
||||
## Outputs
|
||||
- Release communication packet (notes, changelog, enablement summary).
|
||||
- Workback tracker with task status and owners.
|
||||
- QA + localization checklist with sign-offs.
|
||||
|
||||
## Agent/Skill Invocations
|
||||
- `release-documentation-manager` – orchestrates workflow + approvals.
|
||||
- `documentation-architect` – ensures governance compliance.
|
||||
- `quality-review-checklist` skill – enforces QA + accessibility steps.
|
||||
- `versioning-dashboard` skill – updates version support + retirement info.
|
||||
|
||||
---
|
||||
34
commands/update-api-reference.md
Normal file
34
commands/update-api-reference.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
name: update-api-reference
|
||||
description: Generates API reference + guides updates from new schema changes with samples and changelog entries.
|
||||
usage: /technical-writing:update-api-reference --spec openapi.yaml --audience developers --outputs reference,guide --languages js,python
|
||||
---
|
||||
|
||||
# Command: update-api-reference
|
||||
|
||||
## Inputs
|
||||
- **spec** – OpenAPI/AsyncAPI file path or URL.
|
||||
- **audience** – developers | partners | internal | admins.
|
||||
- **outputs** – reference, guide, changelog, tutorial (comma-separated).
|
||||
- **languages** – code sample languages (js, python, curl, java, go, ruby, csharp).
|
||||
- **breaking-change** – true/false toggle for migration guidance.
|
||||
|
||||
## Workflow
|
||||
1. **Spec Diff & Analysis** – compare schema version vs prior baseline, note new/changed/deprecated endpoints.
|
||||
2. **Content Scope** – determine docs to update (reference tables, tutorials, SDK snippets, changelog entries).
|
||||
3. **Drafting** – produce updated endpoint descriptions, parameters, responses, usage notes, and code samples per language.
|
||||
4. **Review Loop** – route drafts to engineering/product for validation and to editorial for style compliance.
|
||||
5. **Publishing & Versioning** – push updates, tag version support, update changelog + migration guidance.
|
||||
|
||||
## Outputs
|
||||
- Updated API reference markdown/HTML with highlighted changes.
|
||||
- Code sample bundle per requested languages.
|
||||
- Changelog excerpt + migration guidance (if applicable).
|
||||
|
||||
## Agent/Skill Invocations
|
||||
- `api-docs-editor` – leads spec diff + doc updates.
|
||||
- `documentation-architect` – ensures IA + governance alignment.
|
||||
- `api-style-guide` skill – enforces terminology, formatting, and code sample rules.
|
||||
- `versioning-dashboard` skill – logs version info + deprecation timelines.
|
||||
|
||||
---
|
||||
81
plugin.lock.json
Normal file
81
plugin.lock.json
Normal file
@@ -0,0 +1,81 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:gtmagents/gtm-agents:plugins/technical-writing",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "f903b9ff22aa9f1b4fe54eee063ded403e8db8ba",
|
||||
"treeHash": "cf0990f04dcb6ca442a15861aa6384239070d38c3996fba94bf0e257dc51356e",
|
||||
"generatedAt": "2025-11-28T10:17:17.551763Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "technical-writing",
|
||||
"description": "Documentation strategy, API references, and release communication workflows",
|
||||
"version": "1.0.0"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "a2b6797ae1f3ab1fcc143130f66be921bc059dfa1ff8141a2cf8851c2d5a02be"
|
||||
},
|
||||
{
|
||||
"path": "agents/api-docs-editor.md",
|
||||
"sha256": "27303d943ef65bec35528b45a572addb64896849e33ac794b89ab0c6d56492a2"
|
||||
},
|
||||
{
|
||||
"path": "agents/documentation-architect.md",
|
||||
"sha256": "48fb04ea72a93d1d0b11d0b6bbc88e9b9af1093791b4328082aaa3c3ce44a275"
|
||||
},
|
||||
{
|
||||
"path": "agents/release-documentation-manager.md",
|
||||
"sha256": "5231c57804a4815be3c22f6c4746caa094b312843d78cb6d1820826dca31b6d7"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "ff2c41980015de2ed6d817bc09929994eb1014d667c1c2a061eb0e2c32990b3a"
|
||||
},
|
||||
{
|
||||
"path": "commands/update-api-reference.md",
|
||||
"sha256": "8406e1db73a65c595bf695c3b2edc01fa29150b1ce406d88dc8c40ff5062b45e"
|
||||
},
|
||||
{
|
||||
"path": "commands/publish-release-documentation.md",
|
||||
"sha256": "e5418de0342fed53318ba244f26949bda89824bea4660702cce547b0527b4c21"
|
||||
},
|
||||
{
|
||||
"path": "commands/plan-documentation-roadmap.md",
|
||||
"sha256": "d99aefd1896e40d8ea6bda23288e0848aebb672ca5bc9e7dadc6c96f2ec0ddaa"
|
||||
},
|
||||
{
|
||||
"path": "skills/doc-requirements-matrix/SKILL.md",
|
||||
"sha256": "5130daa681fe18cc1806e1c2e846f19d7ee1e145e75f5ef2c8e2c45818737d56"
|
||||
},
|
||||
{
|
||||
"path": "skills/versioning-dashboard/SKILL.md",
|
||||
"sha256": "3cb08402020c508a4e2430a9fdc4a4ca0d8827b62bf3c4f5fd9a93eae394f12e"
|
||||
},
|
||||
{
|
||||
"path": "skills/api-style-guide/SKILL.md",
|
||||
"sha256": "f2691451617b1c660863e8b95a8b2ab01c1b4c5503bed3aa04981353de335fab"
|
||||
},
|
||||
{
|
||||
"path": "skills/quality-review-checklist/SKILL.md",
|
||||
"sha256": "a9c15efe0f0af800bb130bb66901c5bfe5125e81131cd85e61653a2bc7fdffd2"
|
||||
}
|
||||
],
|
||||
"dirSha256": "cf0990f04dcb6ca442a15861aa6384239070d38c3996fba94bf0e257dc51356e"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
30
skills/api-style-guide/SKILL.md
Normal file
30
skills/api-style-guide/SKILL.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
name: api-style-guide
|
||||
description: Style and formatting rules for API/SDK documentation, samples, and tutorials.
|
||||
---
|
||||
|
||||
# API Style Guide Skill
|
||||
|
||||
## When to Use
|
||||
- Authoring or updating API references, tutorials, and SDK docs.
|
||||
- Reviewing contributions from engineers, DevRel, or partners.
|
||||
- Auditing docs for consistency before releases.
|
||||
|
||||
## Framework
|
||||
1. **Language & Tone** – audience-specific tone, terminology list, and banned phrases.
|
||||
2. **Structure** – endpoint/order conventions, table layouts, code block formatting, error doc patterns.
|
||||
3. **Code Samples** – naming standards, authentication handling, pagination patterns, inline comments.
|
||||
4. **Metadata & Tags** – version labels, availability notes, beta flags, locale indicators.
|
||||
5. **Accessibility & Localization** – heading hierarchy, alt-text, snippet annotations, translation guidance.
|
||||
|
||||
## Templates
|
||||
- Reference entry template (description, parameters, responses, examples, notes).
|
||||
- Tutorial skeleton with prerequisites, steps, troubleshooting, next steps.
|
||||
- Code sample checklist ensuring env vars, comments, and error handling are included.
|
||||
|
||||
## Tips
|
||||
- Keep examples runnable; provide curl equivalents even when primary sample is in another language.
|
||||
- Link to glossary for shared terminology across teams.
|
||||
- Pair with `update-api-reference` command to enforce consistent output.
|
||||
|
||||
---
|
||||
31
skills/doc-requirements-matrix/SKILL.md
Normal file
31
skills/doc-requirements-matrix/SKILL.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: doc-requirements-matrix
|
||||
description: Framework for capturing documentation requirements, scoring priority,
|
||||
and assigning owners.
|
||||
---
|
||||
|
||||
# Doc Requirements Matrix Skill
|
||||
|
||||
## When to Use
|
||||
- Intake from product, engineering, support, or compliance teams.
|
||||
- Prioritizing doc requests against limited capacity.
|
||||
- Tracking readiness requirements for launches or audits.
|
||||
|
||||
## Framework
|
||||
1. **Request Intake** – requester, audience, format, deadline, status, linked release.
|
||||
2. **Scoring Criteria** – impact, urgency, compliance, audience reach, reuse potential.
|
||||
3. **Dependencies** – SMEs, assets, tooling, localization, approvals.
|
||||
4. **Status Tracking** – backlog → in progress → review → published → refresh queued.
|
||||
5. **Reporting** – dashboards for open requests, SLA breaches, and effort allocation.
|
||||
|
||||
## Templates
|
||||
- Requirement intake form (Notion/Sheet) with scoring formula.
|
||||
- Priority board with filters for audience, format, product area.
|
||||
- Weekly review agenda highlighting top priorities + blockers.
|
||||
|
||||
## Tips
|
||||
- Align scoring weights with leadership priorities each quarter.
|
||||
- Attach spec links, mockups, and SME contacts to reduce back-and-forth.
|
||||
- Pair with `plan-documentation-roadmap` to auto-populate backlog sections.
|
||||
|
||||
---
|
||||
31
skills/quality-review-checklist/SKILL.md
Normal file
31
skills/quality-review-checklist/SKILL.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: quality-review-checklist
|
||||
description: Checklist covering accuracy, style, accessibility, and localization requirements
|
||||
for documentation releases.
|
||||
---
|
||||
|
||||
# Quality Review Checklist Skill
|
||||
|
||||
## When to Use
|
||||
- Pre-publication QA for docs, tutorials, and release notes.
|
||||
- Auditing inherited content during migrations.
|
||||
- Training new contributors on required review steps.
|
||||
|
||||
## Framework
|
||||
1. **Accuracy & Coverage** – verify features, parameters, screenshots, and examples match latest build.
|
||||
2. **Style & Voice** – enforce style guide, terminology, formatting, and tone per audience.
|
||||
3. **Accessibility** – heading hierarchy, alt-text, captions, contrast, keyboard navigation, screen-reader cues.
|
||||
4. **Localization & Compliance** – translation scope, legal disclaimers, export controls, privacy statements.
|
||||
5. **Version Control** – version tags, changelog entries, rollback plan, owner assignments.
|
||||
|
||||
## Templates
|
||||
- QA checklist spreadsheet with pass/fail + notes fields.
|
||||
- Reviewer sign-off sheet with timestamps and comments.
|
||||
- Issue log for follow-up fixes grouped by severity.
|
||||
|
||||
## Tips
|
||||
- Pair reviewers (technical + editorial) for faster turnarounds.
|
||||
- Automate linting scripts (links, markdown, accessibility) and attach results to the checklist.
|
||||
- Use with `publish-release-documentation` for final approvals.
|
||||
|
||||
---
|
||||
31
skills/versioning-dashboard/SKILL.md
Normal file
31
skills/versioning-dashboard/SKILL.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: versioning-dashboard
|
||||
description: Dashboard pattern for tracking doc coverage across product versions,
|
||||
locales, and channels.
|
||||
---
|
||||
|
||||
# Versioning Dashboard Skill
|
||||
|
||||
## When to Use
|
||||
- Managing multiple product versions, editions, or deployment models.
|
||||
- Coordinating deprecations, migrations, and long-term support documentation.
|
||||
- Reporting readiness and gaps to leadership during launches.
|
||||
|
||||
## Framework
|
||||
1. **Version Inventory** – list active versions, release dates, support windows, and owners.
|
||||
2. **Artifact Coverage** – matrix of docs/tutorials/guides per version + locale + channel.
|
||||
3. **Change Log Hooks** – tie version changes to release notes, migration guides, and alert cadence.
|
||||
4. **Risk & Action Log** – highlight outdated assets, missing locales, or compliance needs.
|
||||
5. **Reporting Layer** – KPIs (coverage %, SLA adherence, reader metrics) with filters for audience or product area.
|
||||
|
||||
## Templates
|
||||
- Dashboard sheet with pivoted coverage views and status chips.
|
||||
- Migration tracker linking deprecated features to comms + doc updates.
|
||||
- Executive summary slide with version highlights and asks.
|
||||
|
||||
## Tips
|
||||
- Integrate with source control metadata to auto-update coverage status.
|
||||
- Highlight dependencies (SDKs, integrations) when versions shift.
|
||||
- Pair with `plan-documentation-roadmap`, `publish-release-documentation`, and `update-api-reference` workflows.
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user