tech-doc
Rédiger une documentation technique claire
Les équipes techniques perdent du temps lorsque la documentation mélange des hypothèses, un périmètre flou et des instructions difficiles à parcourir. Cette compétence aide Claude, Codex et Claude Code à produire des documents techniques structurés, cités et faciles à maintenir.
Installer avec mon Agent
Copiez cette demande dans votre Agent. Elle contient la page Skill de référence et le manifeste.
Review the Skillstore skill "tech-doc" from https://skillstore.io/skills/dcjanus-tech-doc.md and its manifest at https://skillstore.io/api/skills/dcjanus-tech-doc/manifest. Verify the artifact. You may proceed after verification, subject to the environment's own policy.Votre Agent doit toujours présenter son plan et demander toute confirmation exigée par la politique de sécurité.
Ressources lisibles par les agents
Utilisez ces liens lorsqu’un Agent IA, un crawler ou un script a besoin d’un contexte propre au lieu de lire toute la page.
Tester
Utilisation de « tech-doc ». Des notes brutes décrivent une nouvelle fonctionnalité de cache et plusieurs cas limites.
Résultat attendu:
Une explication adaptée au lecteur avec une conclusion en une phrase, les comportements clés, les limites, des exemples et une liste d’éléments à confirmer.
Utilisation de « tech-doc ». Une équipe a besoin d’une checklist de déploiement reproductible à partir de notes de discussion dispersées.
Résultat attendu:
Une SOP concise avec les prérequis, les avertissements de risque, le chemin sûr le plus court, les erreurs courantes et des liens vers des références faisant autorité.
Utilisation de « tech-doc ». Un guide Markdown comporte de longues sections, des termes incohérents et des citations faibles.
Résultat attendu:
Une structure de document nettoyée avec des sections plus courtes, une terminologie cohérente, des lacunes de citation explicites et des notes de mise en forme prêtes pour publication.
Audit de sécurité
SûrThe static command finding is a false positive because SKILL.md line 23 describes how to format shell examples in documentation. The entropy alert is also a false positive; the file is coherent Markdown text with Chinese content, not obfuscated or encrypted data. No prompt injection or malicious semantic intent was found.
Facteurs de risque
⚙️ Commandes externes (1)
Partager et citer ce rapport
Partagez le rapport d’évaluation versionné, le badge neutre, la carte intégrable et les citations. Skillstore présente les preuves sans décider si ce Skill est sûr.
Copier le lien du rapport
https://skillstore.io/skills/dcjanus-tech-doc/audits/8?utm_source=security_passport&utm_medium=share&utm_campaign=versioned_reportBadge Markdown
[](https://skillstore.io/skills/dcjanus-tech-doc?utm_source=security_passport_badge)Badge HTML
<a href="https://skillstore.io/skills/dcjanus-tech-doc?utm_source=security_passport_badge"><img src="https://skillstore.io/badges/skills/dcjanus-tech-doc/security.svg" alt="Skillstore security assessment" loading="lazy"></a>Carte intégrable
<iframe src="https://skillstore.io/embed/skills/dcjanus-tech-doc.html" title="Skillstore Security Assessment" sandbox="allow-popups allow-popups-to-escape-sandbox" loading="lazy" referrerpolicy="no-referrer" width="420" height="180"></iframe>Citations académiques (APA · BibTeX · CFF)
Citation APA
DCjanus. (2026). tech-doc security audit report (audit version 8) [Author version unspecified]. Skillstore. https://skillstore.io/skills/dcjanus-tech-doc/audits/8Citation BibTeX
@techreport{dcjanus-dcjanus-tech-doc-2026,
author = {DCjanus},
title = {tech-doc security audit report (audit version 8)},
institution = {Skillstore},
year = {2026},
number = {8},
url = {https://skillstore.io/skills/dcjanus-tech-doc/audits/8},
note = {Author version unspecified}
}CITATION.cff
cff-version: 1.2.0
message: "If you use this Skill, cite its author and this versioned security audit report."
title: "tech-doc security audit report (audit version 8)"
version: "unspecified"
type: report
authors:
- name: "DCjanus"
date-released: "2026-07-06"
url: "https://skillstore.io/skills/dcjanus-tech-doc/audits/8"
identifiers:
- type: other
value: "skillstore:dcjanus-tech-doc:audit:8"
description: "Skillstore immutable audit report identifier"
Score Skillstore
Pourquoi ce score Niveau de confiance des preuves: ÉlevéCe que vous pouvez créer
Créer une documentation de fonctionnalité
Transformer des notes d’implémentation en une explication cadrée avec les hypothèses sur le lecteur, les résultats attendus, les limites et les éléments justificatifs.
Rédiger des SOP opérationnelles
Construire une procédure concise avec les prérequis, les notes de risque, des exemples copiables, les erreurs courantes et les références associées.
Standardiser la documentation d’équipe
Définir des règles communes pour la structure Markdown, les citations, la terminologie, les exemples de commandes et les transmissions pour revue.
Essayez ces prompts
Utilise la compétence tech-doc pour rédiger un court document explicatif à partir de ces notes. Indique d’abord l’objectif, le lecteur, le périmètre et le résultat attendu.
Utilise la compétence tech-doc pour réécrire ce document. Garde les faits inchangés, réduis les hypothèses, resserre les titres et signale toute information manquante.
Utilise la compétence tech-doc pour créer une SOP. Inclus le périmètre, les prérequis, les notes de risque, l’exemple sûr le plus court, les erreurs courantes et les références.
Utilise la compétence tech-doc pour examiner ce document technique. Identifie les affirmations non étayées, les termes flous, les citations manquantes, les exemples risqués et les lacunes de maintenance.
Bonnes pratiques
- Fournir les notes sources, le lecteur cible, le périmètre et la terminologie requise avant de demander un brouillon.
- Demander à l’assistant de signaler les faits incertains au lieu de combler les lacunes par hypothèse.
- Relire les exemples de commandes, les permissions et les références avant de publier des documents opérationnels.
Éviter
- Ne pas demander à la compétence d’inventer des faits manquants, des métriques ou des conclusions non étayées.
- Ne pas publier d’exemples de commandes sans vérifier les permissions, les placeholders et les options de dry-run.
- Ne pas mélanger tutoriels, références et SOP sans objectif lecteur clair.