tc-docs-write

Use when writing or updating the TcKit documentation site or the README — anything under docs/content/ or README.md. Triggers on requests like "update the docs", "document this in the docs", "write a docs page for X", "the README needs Y", "add a capability page", "fix the home page", or before editing any file under docs/content/ or README.md. Enforces the user-facing-behaviour update checklist (which surface to update), the voice rules (no ADR references on user-facing surfaces, no history paragraphs, README as voice reference for the home page, no marketing scaffolding), and the "docs are a bug when stale" stance. Do NOT use for ADR writing (that is tc-adr) or for in-code docstrings on ST POUs (that is tc-write-st).

跳到安装

仓库: georgeturneruk/tckit
最近来源活动: 2026年7月2日 22:52
检测到的 SKILL.md 语言: 英语
星标: 4
分支: 2

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/georgeturneruk/tckit --skill tc-docs-write

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

tc-build-test-loop

Use when building a TwinCAT project, deploying to a target, running TcUnit tests, or iterating on build/test failures through TcKit (Build, Deploy, StartRuntime, RunTests, GetTestResults). Triggers on requests like "build it", "run the tests", "fix the build errors", "deploy to <NetId>", "make the tests pass". Enforces the build-before-deploy ordering, the 2-attempt-per-error build fix limit, the 5-iteration test loop limit, the permission-gate rules for Deploy and StartRuntime (surface denials, never self-elevate), and the save+install rule for multi-PLC solutions with library references. Do NOT use for the initial code write itself (that is tc-write-st).

2026-08-09

tc-write-st

Use when writing or modifying Structured Text (ST) code in a TwinCAT 3 project. Triggers on requests like "add a method to FB_Motor", "add a property to FB_Pid", "create FB_PumpControl", "add ST_Config struct", "add E_State enum", "tweak the Execute body", "rename X to Y inside Execute", "add a VAR_INPUT to FB_PumpControl", "change one line in this method", or any other ST edit. Uses TcKit's writer MCP tools (OpenProject, CreateProject, AddPou, AddGvl, AddDut, AddMethod, AddProperty, UpdatePouDeclaration, UpdatePouImplementation, UpdateMethodBody, UpdatePouDeclarationPatch, UpdatePouImplementationPatch, UpdateMethodBodyPatch, AddVariable). Use these tools INSTEAD of Edit/Write on .TcPOU or .plcproj files; the MCP tools go through TcKit's writer backend so GUIDs and project cross-references stay consistent. Enforces comment style, naming conventions, the bError propagation pattern, the rename guard, and the safety-critical naming guard. If the code uses an unfamiliar Beckhoff library FB, hand off to tc-beckhof

2026-08-09

tc-beckhoff-docs

Use when researching a Beckhoff TwinCAT library, function block, or function via Beckhoff infosys, OR when looking up a Beckhoff hardware product by order number. Triggers on requests like "what does FB_EcCoESdoRead do", "which TF library has SDO read", "what are the inputs of FB_X", "what are the technical specs of EL3004", "look up EPP6228", "how many channels does the EK1100 have", or as a precondition before writing code that uses an unfamiliar Beckhoff FB. Uses TcKit's FindFb, SearchDocs, FindHardware, and GetDocPage MCP tools. Do NOT use for inspecting the user's local project (that is tc-read-project).

2026-07-02

查看这个仓库的全部 Skills

name	tc-docs-write
description	Use when writing or updating the TcKit documentation site or the README — anything under docs/content/ or README.md. Triggers on requests like "update the docs", "document this in the docs", "write a docs page for X", "the README needs Y", "add a capability page", "fix the home page", or before editing any file under docs/content/ or README.md. Enforces the user-facing-behaviour update checklist (which surface to update), the voice rules (no ADR references on user-facing surfaces, no history paragraphs, README as voice reference for the home page, no marketing scaffolding), and the "docs are a bug when stale" stance. Do NOT use for ADR writing (that is tc-adr) or for in-code docstrings on ST POUs (that is tc-write-st).
allowed-tools	Read, Edit, Write, Grep, Glob

Writing TcKit docs

The TcKit docs site lives under docs/content/ (MkDocs). The README at the repo root mirrors a slice of it. Both are user-facing surfaces and follow the same voice rules.

When to update docs

A change touches user-facing behaviour, and therefore needs a docs update in the same PR, if any of the following are true:

MCP tool names, arguments, or return shapes changed
CLI commands or flags changed
Config keys changed (config.json, ~/.tckit/permissions.json, .env)
Install or setup steps changed
Ports, adapters, or the one-rule architecture statement changed
An ADR moved to Implemented for a design decision that has now shipped

If none of those apply, the change does not need a docs update. Don't invent one.

Which surface to update

README — only when the surface shown on the README itself has changed. The README is a slice, not the whole story; many real-behaviour changes affect docs/content/ only.
docs/content/ — the default. Find the page that owns the changed surface (capability page for tool/argument changes, getting-started for install, architecture page for the one-rule statement, etc.) and edit there.

If the README and the relevant docs/content/ page both need to change, both go in the PR.

Voice rules

The home page (docs/content/index.md) takes its voice from the README. When editing the home page, match the README's structure, density, and tone. (The capability and adapter pages under docs/content/capabilities/ are denser reference material and have their own appropriate voice — don't apply this rule to them.)

For every user-facing page:

No ADR references. ADRs are an internal design store. docs/content/, the README, MCP tool descriptions, and CLI help text describe current behaviour, not the history of how it got there. If a passage needs more context than fits inline, link to the PR. Never link to adrs/.
No history paragraphs. Don't chronicle what something used to be. "The port had two more methods in an earlier draft" belongs on the ADR or in the commit message, not on a page describing the current shape.
No marketing scaffolding on the home page. Specifically, do not add:
- problem/solution framing tables that repeat the capabilities list (e.g. "What TcKit solves")
- redundant capability summaries ("X at a glance" next to a capabilities table)
- "Design philosophy" or similar sections that duplicate the architecture page
- feature-pitch bullet lists
State what it does, link where it can be verified, move on.

Procedure

Identify which surface(s) changed (use the "Which surface to update" guide above).
Read the page you intend to edit so the change matches the surrounding voice, structure, and link conventions.
Edit. Prefer Edit over Write; never rewrite a page wholesale when a section edit will do.
If the change touches the home page, re-read the README first and match its voice.

Anti-patterns

Linking from docs/content/ or the README to adrs/ to explain "why". The PR or commit message is the right pointer; the docs describe current behaviour.
Adding a "History" / "Background" / "Previously" section to a user-facing page.
Padding the home page with capability blurbs that the capabilities table already covers.
Updating the README for an internals-only change (e.g. a refactor of an adapter that doesn't surface to users).
Leaving the docs stale because "the diff is the truth" — stale docs are a bug.

After the docs edit, return to the calling task (commit, PR, etc.). No further handoff.

tc-docs-write

安装方式

检查来源文件

Writing TcKit docs

When to update docs

Which surface to update

Voice rules

Procedure

Anti-patterns

Next

Writing TcKit docs

When to update docs

Which surface to update

Voice rules

Procedure

Anti-patterns

Next

tc-docs-write

来源信息

安装方式

检查来源文件

同仓库更多 Skills

同仓库更多 Skills

Writing TcKit docs

When to update docs

Which surface to update

Voice rules

Procedure

Anti-patterns

Next

Writing TcKit docs

When to update docs

Which surface to update

Voice rules

Procedure

Anti-patterns

Next