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