القائمة
Guidelines for writing or editing zynk documentation (README, CLAUDE.md/AGENTS.md/WORKFLOW.md, ADRs, user docs). Use when creating or updating any doc in this repo.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Control zynk from inside it. Manage workspaces, tabs, and panes, spawn and coordinate agents, read pane output, wait for state changes, and exchange native messages — all via CLI commands that talk to the running zynk instance over a local unix socket. Use when running inside zynk (ZYNK_ENV=1).
Prepares production launches. Use when preparing to cut a release. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
Optimizes runtime performance. Use when performance requirements exist, when you suspect performance regressions, or when render latency, IPC/PTY throughput, allocation, or async overhead needs improvement. Use when profiling reveals bottlenecks that need fixing.
Manages deprecation and migration. Use when removing old systems, APIs, IPC methods, or features. Use when migrating consumers from one implementation to another, evolving the wire protocol or DB schema, or deciding whether to maintain or sunset existing code.
Audit zynk release readiness by comparing commits since the last release tag against the root CHANGELOG.md and README.md, plus version/tag/Nix-hash consistency. Use when asked to run the repo's pre-release audit or to check that the changelog and docs cover what shipped before a zynk release.
Use early when debugging a medium or hard bug, especially when tests alone may not reveal the real runtime failure. Trigger this before extended TDD iteration when a bug involves runtime state, PTY/terminal ordering, persistence, streaming, async/concurrency, the TUI/manual reproduction, the IPC socket layer, or when a red or newly passing test may not model the real issue. Skip only when the root cause is already directly proven by a stack trace or deterministic test that exercises the real runtime path.
استنادا إلى تصنيف SOC المهني
| name | zynk-docs |
| description | Guidelines for writing or editing zynk documentation (README, CLAUDE.md/AGENTS.md/WORKFLOW.md, ADRs, user docs). Use when creating or updating any doc in this repo. |
Use this skill when you write or edit zynk docs. Start with docs/styleguides/STYLEGUIDE.md (the default
writing guide), then apply the doc-type guidance below.
README.md — user-facing: what zynk is, install, quickstart, key usage. The ONLY place for the project
intro/marketing.CLAUDE.md / AGENTS.md / WORKFLOW.md — agent guidance. Terse + actionable ONLY (build, commands,
conventions, architecture invariants + file paths + the WHY, gotchas). NO marketing or "what the project is"
prose — that belongs in README. These load into context every session, so noise wastes tokens and reduces
adherence. Target under 200 lines.docs/zynk/decisions/NNNN-*.md (ADRs) — # ADR NNNN — Title, then **Status:** … **Date:** …,
## Context / ## Decision / ## Alternatives considered / ## Consequences. Accepted ADRs are binding —
amend via a NEW ADR, never rewrite one.CONTRIBUTING.md / CHANGELOG.md / SECURITY.md — keep current and factual.just docs-lint runs Vale (write-good + the custom zynk prose style in docs/styles/) over the docs —
optional, not a hard CI gate. Run it before committing docs.