القائمة
READMEs and website guides. Read before writing or modifying docs.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Benchmark runner, fixture repos, and publication. Read before running, modifying, or publishing benchmark results.
Pull request submission flow. Read only when the user explicitly asks for a pull request.
Work rules, testing, validation, and change integrity. Read before writing or modifying code.
Self-Review, Review Cycle, Discussion, and Research Review Round workflows. Read the Exhaustive rounds and Stop condition rules before any review round (solo or team); read the Briefing subagents rule before delegating to any subagent; read in full when the user asks for a named mode.
What ttsc is, the workspace layout, and the canonical commands.
Keeping packages/ttsc/shim/* synced with typescript-go and complete for plugin authors. Read before adding a re-export, bumping the pinned typescript-go version, or chasing a missing AST/transform/printer/emit API a plugin needs.
| name | documentation |
| description | READMEs and website guides. Read before writing or modifying docs. |
README files are for the final reader of that package or directory. Start with what it is, when to use it, installation, the smallest working setup, and the common path.
Keep README language direct and practical. Avoid compiler theory, protocol details, internal architecture, and edge cases unless the reader must know them to use the package. Move deep explanations into the website guides and link them only as the next step.
Guide documents live under website/src/content/docs/ as MDX, served by Nextra at https://ttsc.dev. They are the detailed layer. Each guide must name its reader: consumer, package user, bundler user, runtime user, plugin author, or maintainer.
The tree is organized by audience: top-level pages (index.mdx, setup.mdx, faq.mdx, benchmark/) for cross-cutting tasks, per-package folders (ttsc/, lint/, plugins/, wasm/) for package guides, and development/ for plugin-author guides. Package guides may go deeper than README with full options, recipes, troubleshooting, compatibility notes, and migration details. Plugin-author guides may cover protocol, Go APIs, testing, publishing, and internals. Keep one audience and task per page, and update the matching _meta.ts when adding, renaming, or moving a guide.
Write Markdown and MDX prose as one line per paragraph, never hard-wrap at a fixed column. Markdown soft-wraps on render, so a manual line break mid-paragraph changes nothing visible while making diffs noisy (a reworded sentence reflows several lines) and edits awkward. Keep real line breaks only for paragraph boundaries, list items, headings, tables, and fenced code. prettier --prose-wrap never (with embeddedLanguageFormatting: off, so code fences stay byte-identical) enforces this across *.md and *.mdx. Run the repo format script rather than wrapping by hand.
Write in the plain, direct voice of the human-authored docs in this repo. Do not write like an AI assistant.
