[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71EZN3JR87PJ1BBHRG24M39":3,"skill-same:01M71EZN3JR87PJ1BBHRG24M39":98},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":67,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M71EZN3JR87PJ1BBHRG24M39","write-clear-readme",null,"Author, restructure, audit or polish a project README for clarity and scannability. Reads repository truth, preserves anchors and code, and verifies rendering. Explicit author\u002Fpolish requests apply local changes; audit\u002Fpropose stays read-only. Use for README creation, wording, structure and navigation, including skill collections and CLI\u002FSDK docs.","coroboros\u002Fagent-skills","coroboros","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276246903?v=4","01M71EW9FC462PB6BEAC5P9JK1","Coroboros","01M71EW9G1KB3SQM769D2JMXXZ",5,"MIT","https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-clear-readme\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"write clear readme","clear","README","write","only","ls","project readme","creation","project","local","preview","references","writing","access","markdown preview","Bash","verification","browser","code","libraries","2026-11-10 10:12:30",false,"---\nname: write-clear-readme\ndescription: Author, restructure, audit or polish a project README for clarity and scannability. Reads repository truth, preserves anchors and code, and verifies rendering. Explicit author\u002Fpolish requests apply local changes; audit\u002Fpropose stays read-only. Use for README creation, wording, structure and navigation, including skill collections and CLI\u002FSDK docs.\nwhen_to_use: Useful for long human-facing docs (config READMEs, plugin monorepos), skill libraries, npm SDK references, CLI manuals, or any README showing scroll fatigue, unclear writing, or verbose passages.\nargument-hint: \"[author|audit|polish] [optional path — defaults to .\u002FREADME.md]\"\nallowed-tools: Read Write Edit Grep Glob Bash(git *) Bash(jq *) Bash(python3 *) Bash(basename *) Bash(test *) Bash(ls *)\nlicense: MIT\ncompatibility: \"Requires project file access and Python 3.10+ for the bundled audit. Rendering checks use an available Markdown preview or browser; unavailable rendering remains an explicit verification gap.\"\nmetadata:\n  author: coroboros\n---\n\n# Write Clear README\n\n\u003C!-- canonical:writing-rules:start -->\n## Important — Writing rules\n\nApply these rules to emitted prose: docs, comments, commit messages, PR bodies, and release notes.\n\n- Match surrounding punctuation, capitalization, and formatting.\n- Every sentence changes the reader's understanding. Cut it otherwise.\n- Lead with the action or outcome.\n- Use concrete language and lists when they improve comparison or sequence.\n- Assert positively. Reserve negation for real constraints (`NEVER commit secrets`).\n- No marketing words: powerful, robust, seamlessly, leverage, unlock, comprehensive, delightful.\n- No AI tells: delve, tapestry, intricate, pivotal, testament, underscore, crucial, garner, showcase, additionally, moreover, furthermore, indeed.\n- For substantive English prose, use `\u002Fhumanize-en` if installed with the existing scope and authorization. It adds no approval stage; skip redundant passes over short status text.\n\u003C!-- canonical:writing-rules:end -->\n\nAuthor, audit, or polish a README.md for clarity and scannable structure. Read repository truth first. Explicit author\u002Fpolish requests authorize local edits; audit\u002Fpropose stays read-only. Carry this target and mode through a nested prose pass without another approval prompt. Publication is a separate action.\n\nAdditional context from the user: $ARGUMENTS\n\n## Context\n\n- Repo: !`basename $(git rev-parse --show-toplevel 2>\u002Fdev\u002Fnull || echo unknown)`\n- Existing README: !`test -f README.md && wc -l \u003C README.md | awk '{print $1 \" lines\"}' || echo \"none\"`\n- Package manifest: !`test -f package.json && jq -r '.name + \"@\" + .version' package.json 2>\u002Fdev\u002Fnull || echo \"none\"`\n- Top-level folders: !`ls -d *\u002F 2>\u002Fdev\u002Fnull | head -20 | tr '\\n' ' '`\n\n## Doc type → pattern\n\nLong READMEs cause scroll fatigue. The fix is a structural decision before any prose: pick one collapse pattern for the whole doc and apply it uniformly. Selective collapse driven by per-section judgment — some sections visible, some hidden — creates a minefield. Readers cannot infer the rule, every heading becomes a guess.\n\n| Doc type | Default pattern | Why |\n|----------|-----------------|-----|\n| Short single-purpose (\u003C5 sections, \u003C300 lines) | **No collapse** | Adds clicks for no scroll savings |\n| Long human-facing, mixed-audience (config docs, personal `~\u002F.claude\u002F` companions, internal index READMEs) | **Pattern A — Per-section collapse** | One file, audiences self-select via expand; h2s read as scan-line |\n| Skill library \u002F plugin monorepo \u002F package index (5+ peers, ≤7 groups) | **Pattern B — Grouped collapse** | Groups stay visible as scan-map; details hide |\n| Library \u002F SDK \u002F CLI reference (dozens of API entries) | **Pattern C — Per-entry collapse** | Each function\u002Fcommand independently expandable |\n\nContent shape comes before collapse. See [Author mode — Step 0](#author-mode).\n\n### Pattern A — Per-section collapse\n\n**When**: long human-facing doc serving more than one audience in one file (install + reference + meta-instructions). Per-section collapse turns the h2 list into a scan-line; readers expand only the section that matches their job.\n\nH2 stays uncollapsed (scan-line + anchor target). Every sub-section inside h2 wraps in a `\u003Cdetails>` with the section label as `\u003Csummary>`. Drop the h3 above the disclosure — the `\u003Csummary>` carries the label.\n\n```markdown\n## Section name\n\nShort intro paragraph (optional, visible).\n\n\u003Cdetails>\n\u003Csummary>\u003Cem>Sub-section one\u003C\u002Fem>\u003C\u002Fsummary>\n\n\u003Cbr>\n\nContent for sub-section one. Tables, paragraphs, code blocks.\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Cem>Sub-section two\u003C\u002Fem>\u003C\u002Fsummary>\n\n\u003Cbr>\n\nContent for sub-section two.\n\n\u003C\u002Fdetails>\n```\n\nTwo acceptable variants — pick one per h2 and stay consistent across the file:\n\n- **Full per-section collapse** — no visible intro, every sub-section in `\u003Cdetails>`.\n- **Intro + per-section collapse** — one short paragraph visible under each h2, then every sub-section in `\u003Cdetails>`. Use when the intro carries enough signal for the reader to decide whether to click.\n\nWhat does NOT work: ad-hoc selective collapse where some sub-sections are visible and others hidden based on length or \"frequency of use.\" The rule must be self-evident from the structure.\n\n**Trade-off** — dropping the h3 loses the per-sub-section anchor. Acceptable for internal-facing docs with h2-only TOCs. When deep anchors matter (cross-doc links, external bookmarks), keep the h3 inside the `\u003Cdetails>` — GitHub auto-expands on hash navigation and the anchor resolves.\n\n### Pattern B — Grouped collapse\n\n**When**: 5+ peer items cluster into ≤7 logical groups. Typical: skill libraries, plugin ecosystems, monorepo package indexes, component catalogs.\n\nGroup heading stays OUTSIDE `\u003Cdetails>` so `#group-name` anchors keep working. Per-item content goes inside.\n\n```markdown\n### Group Name\n\n\u003Cdetails>\n\u003Csummary>\u003Cem>item1 · item2 · item3\u003C\u002Fem>\u003C\u002Fsummary>\n\n\u003Cbr>\n\n#### item1\n...\n\n#### item2\n...\n\n\u003C\u002Fdetails>\n```\n\nKeep an overview table at the top listing all items with anchor links — users see the full scope without clicking.\n\n### Pattern C — Per-entry collapse\n\n**When**: reference docs with dozens of API entries, functions, CLI commands, or config options. Typical: npm package READMEs, SDK references, CLI manuals.\n\nSignature in `\u003Csummary>` (inside `\u003Ccode>` for monospace), one-line description after an em-dash, full detail hidden until expanded:\n\n````markdown\n## API\n\n\u003Cdetails>\n\u003Csummary>\u003Ccode>functionName(arg: T, opts?: Options): Result\u003C\u002Fcode> — one-line description\u003C\u002Fsummary>\n\n\u003Cbr>\n\nLonger explanation. Params table, return value, edge cases, examples.\n\n```ts\n\u002F\u002F usage\n```\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Ccode>anotherFunction(x: X): Y\u003C\u002Fcode> — what it does\u003C\u002Fsummary>\n...\n\u003C\u002Fdetails>\n````\n\nUnderused pattern — most npm READMEs list signatures as flat headings and force a 3000-line scroll. The `\u003Cdetails>` version is dramatically more scannable for reference-heavy docs.\n\n## Universal rules\n\n- **Overview visible** — TOC, tables, API index stay uncollapsed. Collapse *details*, not the *list*.\n- **Anchors preserved** — navigation targets (group headings, API section heading) go OUTSIDE `\u003Cdetails>`. Headings inside still auto-anchor, and GitHub auto-expands the parent `\u003Cdetails>` on hash navigation.\n- **One rule per level** — when applying any collapse pattern, every peer at the chosen level collapses or none does. Selective collapse driven by per-section judgment (\"collapse if length > N\") is forbidden — mixed visibility without an obvious rule turns the page into a minefield.\n- **No `Expand —` prefix** — the disclosure triangle is the universal affordance. `\u003Csummary>\u003Cem>Files installed\u003C\u002Fem>\u003C\u002Fsummary>` reads cleanly; `\u003Csummary>\u003Cem>Expand — files installed\u003C\u002Fem>\u003C\u002Fsummary>` adds a word of noise on every block and signals the author distrusts the reader.\n- **No h3 directly above `\u003Cdetails>` that repeats the `\u003Csummary>` label** — duplicate signal. Drop the h3 and let the `\u003Csummary>` carry the label, OR move the h3 inside the `\u003Cdetails>` if the deep anchor matters.\n- **No stale counts in `\u003Csummary>` or prose** — \"25 symlinks\", \"14 tasks\", \"8 imports\" rot the moment a row is added. Use qualitative descriptors: \"symlinks installed by `install.sh`\", \"declared periodic tasks\".\n- **`\u003Cbr>` after `\u003Csummary>`** — markdown rendering inside `\u003Cdetails>` can be flaky; the explicit break is defensive and consistent.\n- **No deep nesting** — one level of `\u003Cdetails>` max; nested collapsibles confuse navigation.\n- **Signature-first summary (Pattern C)** — put the most identifying token first (function signature, command name, option name) so `Ctrl+F` hits the right entry immediately.\n\n## When NOT to collapse\n\n- Short docs (\u003C5 major sections, \u003C300 lines) — adds clicks for no scroll savings.\n- Install \u002F Quick Start \u002F Requirements — users need these instantly visible.\n- Single-purpose tools where the README is already concise.\n- Cases where no self-evident rule connects the choices — leave everything visible rather than ship a minefield.\n\n## Subcommands\n\nResolve natural-language author\u002Fpolish\u002Faudit intent before these shorthand defaults. An invoking parent passes the user's existing target and mode; empty tool arguments do not reset an authorized polish to audit or create authority to edit another file.\n\n| Invocation | Mode |\n|------------|------|\n| `\u002Fwrite-clear-readme` | Default — if `README.md` exists, audit. Else, author from repo state. |\n| `\u002Fwrite-clear-readme author [path]` | Create or fully restructure a README from scratch. |\n| `\u002Fwrite-clear-readme audit [path]` | Review existing README for collapse opportunities + anchor\u002Foverview integrity + clarity issues. |\n| `\u002Fwrite-clear-readme polish [path]` | Tighten wording, drop filler, clarify ambiguous passages — preserve structure, change only the prose. |\n\n## README-specific style\n\nThe canonical *Writing rules* block above carries the universal prose rules. The bullets below add what is specific to authoring a README:\n\n- **First-3-lines test.** A reader given only the first three lines must be able to (a) decide whether the doc is for them, and (b) predict the next section. A generic tagline followed by a list-of-contents fails the test — it asks for positioning, not enumeration.\n- **Backtick code-like tokens** — file paths, command names, function names, env vars. `~\u002F.claude\u002Frules\u002F` not ~\u002F.claude\u002Frules\u002F.\n- **Em-dashes for context, not parentheses** — `(also see foo)` → `— also see foo`. Reads less aside-y.\n- **Headings as questions or commands**, not topics. \"Installation\" is fine; \"How do I install?\" or \"Install\" reads quicker than \"About installation\".\n- **Qualitative over quantitative** — describe what content is, not how much of it. \"Symlinks created by `install.sh`\" beats \"25 symlinks created by `install.sh`\"; the count rots on add.\n\n## Adjacent skills\n\n- **`\u002Fhumanize-en`** — AI-tell stripping. Called by `author` and `polish` modes after clarity edits; `audit` mode flags AI tells without rewriting. Also usable standalone.\n\n## AI-tell removal — skill-specific notes\n\nThe canonical *Writing rules* block already requires invoking `\u002Fhumanize-en` after any English-prose draft. The notes below pin two skill-specific behaviors:\n\n- **Audit mode:** flag suspected AI tells in the findings but do not auto-rewrite.\n- **Non-English content:** skip the humanize-en pass entirely — it is English-only.\n\n## Author mode\n\n1. **Inspect repo** — read its manifest, relevant entry points and active instruction entrypoint (AGENTS.md, CLAUDE.md or local equivalent). Identify what the README must cover (install, usage, API surface, architecture, license).\n2. **Map audiences** — list the implicit reader for each major section (first-time installer, daily user, maintainer, agent reading CLAUDE.md context). Multi-audience files are candidates for Pattern A.\n3. **Step 0 — Content shape** (BEFORE picking a collapse pattern):\n   - Can content be cut? Sections that no longer earn their place.\n   - Can a thin section merge into its parent?\n   - Can a long table split by category into micro-tables?\n   - Can a redundant column drop? (e.g. a `Source` column that just repeats the file path already in the row label.)\n   - Can six bullets become one sentence? Or a long paragraph become bullets?\n   - Only after shape is settled: pick a collapse pattern.\n4. **Pick a pattern** — use the *Doc type → pattern* table. Confirm one rule per level applies cleanly; if not, simplify the structure further or fall back to no collapse.\n5. **Draft** — overview table at top with anchor links, Install \u002F Quick Start \u002F Requirements uncollapsed, chosen collapse pattern applied uniformly below. Apply the canonical *Writing rules* + *README-specific style* as you write.\n6. **Strip AI traces** — for English content, invoke `\u002Fhumanize-en` on the draft (see *AI-tell removal — skill-specific notes* above). Skip if the skill is unavailable or the content is non-English.\n7. **Verify structure** — every TOC anchor resolves. Every `\u003Cdetails>` has a `\u003Cbr>` after `\u003Csummary>`. No nested collapsibles. Install block is never inside `\u003Cdetails>`. Pattern applied uniformly across all peers at the chosen level. No `Expand —` in `\u003Csummary>`. No h3 above a `\u003Cdetails>` that repeats the `\u003Csummary>` label. No numeric counts adjacent to content nouns.\n8. **Verify rendering** — view the rendered output (GitHub preview, IDE markdown preview, or ask the user to confirm visually). Source-only checks miss visual monotony and inconsistent collapse patterns.\n9. **Write** — overwrite or create `README.md`. Present the diff if it existed before.\n\n## Audit mode\n\n> **Silent assumption — name it.** This audit evaluates structure, anchor integrity, collapse uniformity, and prose tells. It does NOT evaluate whether the right content is in this file. For that, consider whether sections should be cut, merged, reshaped, or split into adjacent files — and ask the user before rewriting scope.\n\n`$SKILL_DIR` = this skill's folder — `${CLAUDE_SKILL_DIR}` in Claude Code, the directory containing this SKILL.md elsewhere.\n\n1. **Read existing README** in full.\n2. **Run the structural audit script**: `\"$SKILL_DIR\"\u002Fscripts\u002Faudit_readme.py \u003Cpath>` emits a JSON report covering unresolved anchors, nested `\u003Cdetails>`, missing `\u003Cbr>` after `\u003Csummary>`, bloat tokens, `Expand —` prefixes, stale counts adjacent to nouns, h3-above-details redundancy, and a visual-rhythm signal (callout + image density). Exit 1 on hard findings; the JSON is your hit-list.\n3. **Score against Universal rules** (structure — use the script output first):\n   - Is the overview (TOC \u002F index \u002F table) visible without clicking?\n   - Do all anchors resolve?\n   - Are any `\u003Cdetails>` blocks nested?\n   - Is `\u003Cbr>` present after every `\u003Csummary>`?\n   - Is the chosen collapse pattern applied uniformly at one level? (No mixed-visibility peers.)\n   - Any `\u003Csummary>` starting with `Expand —`?\n   - Any h3 directly above a `\u003Cdetails>` whose `\u003Csummary>` repeats the label?\n   - Any numeric counts adjacent to content nouns (\"25 X\", \"14 Y\") that would rot on add?\n4. **Score against the canonical *Writing rules* + *README-specific style*** (prose — the script covers mechanical bloat, you cover the rest):\n   - First-3-lines test — can a reader decide if the doc is for them AND predict the next section?\n   - Verbose passages where bullets would do?\n   - Code-like tokens unbacktick'd?\n5. **Map audiences** — for each major section, identify the implicit reader. When the file serves more than two audiences, flag as a Pattern A candidate.\n6. **Visual rhythm** — soft signal from the script. Long user-facing READMEs with zero GitHub callouts (`> [!NOTE|TIP|WARNING|IMPORTANT|CAUTION]`) and zero images read as flat. Surface as a suggestion, not a finding.\n7. **Detect anti-patterns**:\n   - Flat signature list 50+ lines deep → recommend Pattern C.\n   - 5+ peer sub-sections under one h2 in a long human-facing doc → recommend Pattern A.\n   - 10+ peer sections clustering into groups → recommend Pattern B.\n   - Selective `\u003Cdetails>` — some peers collapsed, others not, no inferable rule → call out as minefield; recommend uniform collapse or none.\n   - `\u003Cdetails>` wrapping a group\u002Fsection heading → broken anchor, must move heading outside.\n   - Nested `\u003Cdetails>` → flatten to one level (flagged by the script).\n   - Install \u002F Quick Start \u002F Requirements inside a `\u003Cdetails>` → must surface.\n8. **Report** — bullet list of findings (split structure vs clarity vs content-shape suggestions) + proposed diff.\n9. **Verify rendering after edits** — view the rendered output before declaring done.\n10. **Audit boundary** — report the proposed changes without editing README.md. A later explicit fix request authorizes applying its named scope.\n\n## Polish mode\n\nWording-only pass. Structure stays as-is — only the prose changes.\n\n1. **Read existing README** in full.\n2. **Apply the canonical *Writing rules* + *README-specific style*** sentence by sentence:\n   - Drop filler phrases.\n   - Replace marketing voice with concrete verbs.\n   - Split compound sentences.\n   - Tighten verbose passages into bullets when enumerable.\n   - Backtick code-like tokens.\n   - Replace `(parens)` with em-dashes where they are aside-context.\n   - Replace numeric content-counts with qualitative descriptors.\n3. **Strip AI traces** — for English content, invoke `\u002Fhumanize-en` on the result (see *AI-tell removal — skill-specific notes* above). Skip if the skill is unavailable or the content is non-English.\n4. **Preserve** all anchors, headings, code blocks, diagrams, badges, and link URLs verbatim.\n5. **Apply and report** — apply the authorized wording changes, verify rendering and present the diff. If the user requested a proposal only, report it without modifying the target.\n\n## Rules\n\n- Preserve the authorized target and mode: explicit author\u002Fpolish edits; audit\u002Fpropose does not. A filepath or casual README mention alone grants no edit authority.\n- NEVER collapse Install \u002F Quick Start \u002F Requirements — what a first-time reader needs is never behind a click.\n- NEVER nest `\u003Cdetails>` blocks — GitHub renders nested disclosure unreliably.\n- NEVER wrap a group heading or a TOC anchor target inside `\u003Cdetails>` — a collapsed heading vanishes from the visual scan, and auto-expand on anchor jumps is not reliable across renderers.\n- NEVER apply Pattern A or B partially — every peer at the chosen level collapses or none does.\n- NEVER prefix `\u003Csummary>` with `Expand —` (or `Expand –`, `Expand -`) — the disclosure triangle already says it.\n- NEVER put a numeric content-count adjacent to a noun in prose or `\u003Csummary>` — counts go stale on the next edit; qualitative descriptors only.\n- NEVER change anchors, code blocks, or link URLs in polish mode (those are content, not prose).\n- ALWAYS add `\u003Cbr>` after `\u003Csummary>` — GitHub needs it to render the first inner block.\n- ALWAYS match the existing README's style (quote convention, heading hierarchy, badge format) when editing.\n- ALWAYS verify the rendered output before declaring done (GitHub preview, IDE preview, or user confirmation).\n- Empty `$ARGUMENTS` follows the *Subcommands* default row above. Non-empty: first token is the subcommand, second is the path.\n\n## Gotchas\n\n1. **Mixed `\u003Cdetails>` collapse across peers is a minefield.** Pattern A\u002FB require uniformity: every peer at the chosen level collapses or none does. When applying collapse, audit every peer and normalize before declaring done.\n2. **Topic-form headings (\"About installation\", \"Installation overview\") violate the questions-or-commands rule** at § README-specific style. Convert to imperative (\"Install\") or question (\"How do I install?\").\n3. **Numeric content-counts adjacent to nouns rot fast.** \"25 symlinks\" or \"14 tasks\" go stale the moment a row lands. Use qualitative descriptors instead (\"symlinks installed by `install.sh`\").\n4. **`\u003Cdetails>` wrapping a heading breaks GitHub anchors.** `\u003Cdetails>\u003Csummary>### API\u003C\u002Fsummary>` makes `#api` un-clickable from external links; the disclosure does not auto-expand on anchor click. Keep headings outside `\u003Cdetails>`.\n","# Write Clear README\n\n\u003C!-- canonical:writing-rules:start -->\n## Important — Writing rules\n\nApply these rules to emitted prose: docs, comments, commit messages, PR bodies, and release notes.\n\n- Match surrounding punctuation, capitalization, and formatting.\n- Every sentence changes the reader's understanding. Cut it otherwise.\n- Lead with the action or outcome.\n- Use concrete language and lists when they improve comparison or sequence.\n- Assert positively. Reserve negation for real constraints (`NEVER commit secrets`).\n- No marketing words: powerful, robust, seamlessly, leverage, unlock, comprehensive, delightful.\n- No AI tells: delve, tapestry, intricate, pivotal, testament, underscore, crucial, garner, showcase, additionally, moreover, furthermore, indeed.\n- For substantive English prose, use `\u002Fhumanize-en` if installed with the existing scope and authorization. It adds no approval stage; skip redundant passes over short status text.\n\u003C!-- canonical:writing-rules:end -->\n\nAuthor, audit, or polish a README.md for clarity and scannable structure. Read repository truth first. Explicit author\u002Fpolish requests authorize local edits; audit\u002Fpropose stays read-only. Carry this target and mode through a nested prose pass without another approval prompt. Publication is a separate action.\n\nAdditional context from the user: $ARGUMENTS\n\n## Context\n\n- Repo: !`basename $(git rev-parse --show-toplevel 2>\u002Fdev\u002Fnull || echo unknown)`\n- Existing README: !`test -f README.md && wc -l \u003C README.md | awk '{print $1 \" lines\"}' || echo \"none\"`\n- Package manifest: !`test -f package.json && jq -r '.name + \"@\" + .version' package.json 2>\u002Fdev\u002Fnull || echo \"none\"`\n- Top-level folders: !`ls -d *\u002F 2>\u002Fdev\u002Fnull | head -20 | tr '\\n' ' '`\n\n## Doc type → pattern\n\nLong READMEs cause scroll fatigue. The fix is a structural decision before any prose: pick one collapse pattern for the whole doc and apply it uniformly. Selective collapse driven by per-section judgment — some sections visible, some hidden — creates a minefield. Readers cannot infer the rule, every heading becomes a guess.\n\n| Doc type | Default pattern | Why |\n|----------|-----------------|-----|\n| Short single-purpose (\u003C5 sections, \u003C300 lines) | **No collapse** | Adds clicks for no scroll savings |\n| Long human-facing, mixed-audience (config docs, personal `~\u002F.claude\u002F` companions, internal index READMEs) | **Pattern A — Per-section collapse** | One file, audiences self-select via expand; h2s read as scan-line |\n| Skill library \u002F plugin monorepo \u002F package index (5+ peers, ≤7 groups) | **Pattern B — Grouped collapse** | Groups stay visible as scan-map; details hide |\n| Library \u002F SDK \u002F CLI reference (dozens of API entries) | **Pattern C — Per-entry collapse** | Each function\u002Fcommand independently expandable |\n\nContent shape comes before collapse. See [Author mode — Step 0](#author-mode).\n\n### Pattern A — Per-section collapse\n\n**When**: long human-facing doc serving more than one audience in one file (install + reference + meta-instructions). Per-section collapse turns the h2 list into a scan-line; readers expand only the section that matches their job.\n\nH2 stays uncollapsed (scan-line + anchor target). Every sub-section inside h2 wraps in a `\u003Cdetails>` with the section label as `\u003Csummary>`. Drop the h3 above the disclosure — the `\u003Csummary>` carries the label.\n\n```markdown\n## Section name\n\nShort intro paragraph (optional, visible).\n\n\u003Cdetails>\n\u003Csummary>\u003Cem>Sub-section one\u003C\u002Fem>\u003C\u002Fsummary>\n\n\u003Cbr>\n\nContent for sub-section one. Tables, paragraphs, code blocks.\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Cem>Sub-section two\u003C\u002Fem>\u003C\u002Fsummary>\n\n\u003Cbr>\n\nContent for sub-section two.\n\n\u003C\u002Fdetails>\n```\n\nTwo acceptable variants — pick one per h2 and stay consistent across the file:\n\n- **Full per-section collapse** — no visible intro, every sub-section in `\u003Cdetails>`.\n- **Intro + per-section collapse** — one short paragraph visible under each h2, then every sub-section in `\u003Cdetails>`. Use when the intro carries enough signal for the reader to decide whether to click.\n\nWhat does NOT work: ad-hoc selective collapse where some sub-sections are visible and others hidden based on length or \"frequency of use.\" The rule must be self-evident from the structure.\n\n**Trade-off** — dropping the h3 loses the per-sub-section anchor. Acceptable for internal-facing docs with h2-only TOCs. When deep anchors matter (cross-doc links, external bookmarks), keep the h3 inside the `\u003Cdetails>` — GitHub auto-expands on hash navigation and the anchor resolves.\n\n### Pattern B — Grouped collapse\n\n**When**: 5+ peer items cluster into ≤7 logical groups. Typical: skill libraries, plugin ecosystems, monorepo package indexes, component catalogs.\n\nGroup heading stays OUTSIDE `\u003Cdetails>` so `#group-name` anchors keep working. Per-item content goes inside.\n\n```markdown\n### Group Name\n\n\u003Cdetails>\n\u003Csummary>\u003Cem>item1 · item2 · item3\u003C\u002Fem>\u003C\u002Fsummary>\n\n\u003Cbr>\n\n#### item1\n...\n\n#### item2\n...\n\n\u003C\u002Fdetails>\n```\n\nKeep an overview table at the top listing all items with anchor links — users see the full scope without clicking.\n\n### Pattern C — Per-entry collapse\n\n**When**: reference docs with dozens of API entries, functions, CLI commands, or config options. Typical: npm package READMEs, SDK references, CLI manuals.\n\nSignature in `\u003Csummary>` (inside `\u003Ccode>` for monospace), one-line description after an em-dash, full detail hidden until expanded:\n\n````markdown\n## API\n\n\u003Cdetails>\n\u003Csummary>\u003Ccode>functionName(arg: T, opts?: Options): Result\u003C\u002Fcode> — one-line description\u003C\u002Fsummary>\n\n\u003Cbr>\n\nLonger explanation. Params table, return value, edge cases, examples.\n\n```ts\n\u002F\u002F usage\n```\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Ccode>anotherFunction(x: X): Y\u003C\u002Fcode> — what it does\u003C\u002Fsummary>\n...\n\u003C\u002Fdetails>\n````\n\nUnderused pattern — most npm READMEs list signatures as flat headings and force a 3000-line scroll. The `\u003Cdetails>` version is dramatically more scannable for reference-heavy docs.\n\n## Universal rules\n\n- **Overview visible** — TOC, tables, API index stay uncollapsed. Collapse *details*, not the *list*.\n- **Anchors preserved** — navigation targets (group headings, API section heading) go OUTSIDE `\u003Cdetails>`. Headings inside still auto-anchor, and GitHub auto-expands the parent `\u003Cdetails>` on hash navigation.\n- **One rule per level** — when applying any collapse pattern, every peer at the chosen level collapses or none does. Selective collapse driven by per-section judgment (\"collapse if length > N\") is forbidden — mixed visibility without an obvious rule turns the page into a minefield.\n- **No `Expand —` prefix** — the disclosure triangle is the universal affordance. `\u003Csummary>\u003Cem>Files installed\u003C\u002Fem>\u003C\u002Fsummary>` reads cleanly; `\u003Csummary>\u003Cem>Expand — files installed\u003C\u002Fem>\u003C\u002Fsummary>` adds a word of noise on every block and signals the author distrusts the reader.\n- **No h3 directly above `\u003Cdetails>` that repeats the `\u003Csummary>` label** — duplicate signal. Drop the h3 and let the `\u003Csummary>` carry the label, OR move the h3 inside the `\u003Cdetails>` if the deep anchor matters.\n- **No stale counts in `\u003Csummary>` or prose** — \"25 symlinks\", \"14 tasks\", \"8 imports\" rot the moment a row is added. Use qualitative descriptors: \"symlinks installed by `install.sh`\", \"declared periodic tasks\".\n- **`\u003Cbr>` after `\u003Csummary>`** — markdown rendering inside `\u003Cdetails>` can be flaky; the explicit break is defensive and consistent.\n- **No deep nesting** — one level of `\u003Cdetails>` max; nested collapsibles confuse navigation.\n- **Signature-first summary (Pattern C)** — put the most identifying token first (function signature, command name, option name) so `Ctrl+F` hits the right entry immediately.\n\n## When NOT to collapse\n\n- Short docs (\u003C5 major sections, \u003C300 lines) — adds clicks for no scroll savings.\n- Install \u002F Quick Start \u002F Requirements — users need these instantly visible.\n- Single-purpose tools where the README is already concise.\n- Cases where no self-evident rule connects the choices — leave everything visible rather than ship a minefield.\n\n## Subcommands\n\nResolve natural-language author\u002Fpolish\u002Faudit intent before these shorthand defaults. An invoking parent passes the user's existing target and mode; empty tool arguments do not reset an authorized polish to audit or create authority to edit another file.\n\n| Invocation | Mode |\n|------------|------|\n| `\u002Fwrite-clear-readme` | Default — if `README.md` exists, audit. Else, author from repo state. |\n| `\u002Fwrite-clear-readme author [path]` | Create or fully restructure a README from scratch. |\n| `\u002Fwrite-clear-readme audit [path]` | Review existing README for collapse opportunities + anchor\u002Foverview integrity + clarity issues. |\n| `\u002Fwrite-clear-readme polish [path]` | Tighten wording, drop filler, clarify ambiguous passages — preserve structure, change only the prose. |\n\n## README-specific style\n\nThe canonical *Writing rules* block above carries the universal prose rules. The bullets below add what is specific to authoring a README:\n\n- **First-3-lines test.** A reader given only the first three lines must be able to (a) decide whether the doc is for them, and (b) predict the next section. A generic tagline followed by a list-of-contents fails the test — it asks for positioning, not enumeration.\n- **Backtick code-like tokens** — file paths, command names, function names, env vars. `~\u002F.claude\u002Frules\u002F` not ~\u002F.claude\u002Frules\u002F.\n- **Em-dashes for context, not parentheses** — `(also see foo)` → `— also see foo`. Reads less aside-y.\n- **Headings as questions or commands**, not topics. \"Installation\" is fine; \"How do I install?\" or \"Install\" reads quicker than \"About installation\".\n- **Qualitative over quantitative** — describe what content is, not how much of it. \"Symlinks created by `install.sh`\" beats \"25 symlinks created by `install.sh`\"; the count rots on add.\n\n## Adjacent skills\n\n- **`\u002Fhumanize-en`** — AI-tell stripping. Called by `author` and `polish` modes after clarity edits; `audit` mode flags AI tells without rewriting. Also usable standalone.\n\n## AI-tell removal — skill-specific notes\n\nThe canonical *Writing rules* block already requires invoking `\u002Fhumanize-en` after any English-prose draft. The notes below pin two skill-specific behaviors:\n\n- **Audit mode:** flag suspected AI tells in the findings but do not auto-rewrite.\n- **Non-English content:** skip the humanize-en pass entirely — it is English-only.\n\n## Author mode\n\n1. **Inspect repo** — read its manifest, relevant entry points and active instruction entrypoint (AGENTS.md, CLAUDE.md or local equivalent). Identify what the README must cover (install, usage, API surface, architecture, license).\n2. **Map audiences** — list the implicit reader for each major section (first-time installer, daily user, maintainer, agent reading CLAUDE.md context). Multi-audience files are candidates for Pattern A.\n3. **Step 0 — Content shape** (BEFORE picking a collapse pattern):\n   - Can content be cut? Sections that no longer earn their place.\n   - Can a thin section merge into its parent?\n   - Can a long table split by category into micro-tables?\n   - Can a redundant column drop? (e.g. a `Source` column that just repeats the file path already in the row label.)\n   - Can six bullets become one sentence? Or a long paragraph become bullets?\n   - Only after shape is settled: pick a collapse pattern.\n4. **Pick a pattern** — use the *Doc type → pattern* table. Confirm one rule per level applies cleanly; if not, simplify the structure further or fall back to no collapse.\n5. **Draft** — overview table at top with anchor links, Install \u002F Quick Start \u002F Requirements uncollapsed, chosen collapse pattern applied uniformly below. Apply the canonical *Writing rules* + *README-specific style* as you write.\n6. **Strip AI traces** — for English content, invoke `\u002Fhumanize-en` on the draft (see *AI-tell removal — skill-specific notes* above). Skip if the skill is unavailable or the content is non-English.\n7. **Verify structure** — every TOC anchor resolves. Every `\u003Cdetails>` has a `\u003Cbr>` after `\u003Csummary>`. No nested collapsibles. Install block is never inside `\u003Cdetails>`. Pattern applied uniformly across all peers at the chosen level. No `Expand —` in `\u003Csummary>`. No h3 above a `\u003Cdetails>` that repeats the `\u003Csummary>` label. No numeric counts adjacent to content nouns.\n8. **Verify rendering** — view the rendered output (GitHub preview, IDE markdown preview, or ask the user to confirm visually). Source-only checks miss visual monotony and inconsistent collapse patterns.\n9. **Write** — overwrite or create `README.md`. Present the diff if it existed before.\n\n## Audit mode\n\n> **Silent assumption — name it.** This audit evaluates structure, anchor integrity, collapse uniformity, and prose tells. It does NOT evaluate whether the right content is in this file. For that, consider whether sections should be cut, merged, reshaped, or split into adjacent files — and ask the user before rewriting scope.\n\n`$SKILL_DIR` = this skill's folder — `${CLAUDE_SKILL_DIR}` in Claude Code, the directory containing this SKILL.md elsewhere.\n\n1. **Read existing README** in full.\n2. **Run the structural audit script**: `\"$SKILL_DIR\"\u002Fscripts\u002Faudit_readme.py \u003Cpath>` emits a JSON report covering unresolved anchors, nested `\u003Cdetails>`, missing `\u003Cbr>` after `\u003Csummary>`, bloat tokens, `Expand —` prefixes, stale counts adjacent to nouns, h3-above-details redundancy, and a visual-rhythm signal (callout + image density). Exit 1 on hard findings; the JSON is your hit-list.\n3. **Score against Universal rules** (structure — use the script output first):\n   - Is the overview (TOC \u002F index \u002F table) visible without clicking?\n   - Do all anchors resolve?\n   - Are any `\u003Cdetails>` blocks nested?\n   - Is `\u003Cbr>` present after every `\u003Csummary>`?\n   - Is the chosen collapse pattern applied uniformly at one level? (No mixed-visibility peers.)\n   - Any `\u003Csummary>` starting with `Expand —`?\n   - Any h3 directly above a `\u003Cdetails>` whose `\u003Csummary>` repeats the label?\n   - Any numeric counts adjacent to content nouns (\"25 X\", \"14 Y\") that would rot on add?\n4. **Score against the canonical *Writing rules* + *README-specific style*** (prose — the script covers mechanical bloat, you cover the rest):\n   - First-3-lines test — can a reader decide if the doc is for them AND predict the next section?\n   - Verbose passages where bullets would do?\n   - Code-like tokens unbacktick'd?\n5. **Map audiences** — for each major section, identify the implicit reader. When the file serves more than two audiences, flag as a Pattern A candidate.\n6. **Visual rhythm** — soft signal from the script. Long user-facing READMEs with zero GitHub callouts (`> [!NOTE|TIP|WARNING|IMPORTANT|CAUTION]`) and zero images read as flat. Surface as a suggestion, not a finding.\n7. **Detect anti-patterns**:\n   - Flat signature list 50+ lines deep → recommend Pattern C.\n   - 5+ peer sub-sections under one h2 in a long human-facing doc → recommend Pattern A.\n   - 10+ peer sections clustering into groups → recommend Pattern B.\n   - Selective `\u003Cdetails>` — some peers collapsed, others not, no inferable rule → call out as minefield; recommend uniform collapse or none.\n   - `\u003Cdetails>` wrapping a group\u002Fsection heading → broken anchor, must move heading outside.\n   - Nested `\u003Cdetails>` → flatten to one level (flagged by the script).\n   - Install \u002F Quick Start \u002F Requirements inside a `\u003Cdetails>` → must surface.\n8. **Report** — bullet list of findings (split structure vs clarity vs content-shape suggestions) + proposed diff.\n9. **Verify rendering after edits** — view the rendered output before declaring done.\n10. **Audit boundary** — report the proposed changes without editing README.md. A later explicit fix request authorizes applying its named scope.\n\n## Polish mode\n\nWording-only pass. Structure stays as-is — only the prose changes.\n\n1. **Read existing README** in full.\n2. **Apply the canonical *Writing rules* + *README-specific style*** sentence by sentence:\n   - Drop filler phrases.\n   - Replace marketing voice with concrete verbs.\n   - Split compound sentences.\n   - Tighten verbose passages into bullets when enumerable.\n   - Backtick code-like tokens.\n   - Replace `(parens)` with em-dashes where they are aside-context.\n   - Replace numeric content-counts with qualitative descriptors.\n3. **Strip AI traces** — for English content, invoke `\u002Fhumanize-en` on the result (see *AI-tell removal — skill-specific notes* above). Skip if the skill is unavailable or the content is non-English.\n4. **Preserve** all anchors, headings, code blocks, diagrams, badges, and link URLs verbatim.\n5. **Apply and report** — apply the authorized wording changes, verify rendering and present the diff. If the user requested a proposal only, report it without modifying the target.\n\n## Rules\n\n- Preserve the authorized target and mode: explicit author\u002Fpolish edits; audit\u002Fpropose does not. A filepath or casual README mention alone grants no edit authority.\n- NEVER collapse Install \u002F Quick Start \u002F Requirements — what a first-time reader needs is never behind a click.\n- NEVER nest `\u003Cdetails>` blocks — GitHub renders nested disclosure unreliably.\n- NEVER wrap a group heading or a TOC anchor target inside `\u003Cdetails>` — a collapsed heading vanishes from the visual scan, and auto-expand on anchor jumps is not reliable across renderers.\n- NEVER apply Pattern A or B partially — every peer at the chosen level collapses or none does.\n- NEVER prefix `\u003Csummary>` with `Expand —` (or `Expand –`, `Expand -`) — the disclosure triangle already says it.\n- NEVER put a numeric content-count adjacent to a noun in prose or `\u003Csummary>` — counts go stale on the next edit; qualitative descriptors only.\n- NEVER change anchors, code blocks, or link URLs in polish mode (those are content, not prose).\n- ALWAYS add `\u003Cbr>` after `\u003Csummary>` — GitHub needs it to render the first inner block.\n- ALWAYS match the existing README's style (quote convention, heading hierarchy, badge format) when editing.\n- ALWAYS verify the rendered output before declaring done (GitHub preview, IDE preview, or user confirmation).\n- Empty `$ARGUMENTS` follows the *Subcommands* default row above. Non-empty: first token is the subcommand, second is the path.\n\n## Gotchas\n\n1. **Mixed `\u003Cdetails>` collapse across peers is a minefield.** Pattern A\u002FB require uniformity: every peer at the chosen level collapses or none does. When applying collapse, audit every peer and normalize before declaring done.\n2. **Topic-form headings (\"About installation\", \"Installation overview\") violate the questions-or-commands rule** at § README-specific style. Convert to imperative (\"Install\") or question (\"How do I install?\").\n3. **Numeric content-counts adjacent to nouns rot fast.** \"25 symlinks\" or \"14 tasks\" go stale the moment a row lands. Use qualitative descriptors instead (\"symlinks installed by `install.sh`\").\n4. **`\u003Cdetails>` wrapping a heading breaks GitHub anchors.** `\u003Cdetails>\u003Csummary>### API\u003C\u002Fsummary>` makes `#api` un-clickable from external links; the disclosure does not auto-expand on anchor click. Keep headings outside `\u003Cdetails>`.\n",{"name":5,"license":15,"metadata":57,"description":7,"when_to_use":58,"allowed-tools":59,"argument-hint":60,"compatibility":61},{"author":9},"Useful for long human-facing docs (config READMEs, plugin monorepos), skill libraries, npm SDK references, CLI manuals, or any README showing scroll fatigue, unclear writing, or verbose passages.","Read Write Edit Grep Glob Bash(git *) Bash(jq *) Bash(python3 *) Bash(basename *) Bash(test *) Bash(ls *)","[author|audit|polish] [optional path — defaults to .\u002FREADME.md]","Requires project file access and Python 3.10+ for the bundled audit. Rendering checks use an available Markdown preview or browser; unavailable rendering remains an explicit verification gap.","main","5ff268fdc77fdf345ffe3ba808e74c82023839f8","skills\u002Fwrite-clear-readme",0,"https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills","https:\u002F\u002Fcoroboros.com","https:\u002F\u002Fgithub.com\u002Fcoroboros","https:\u002F\u002Fcoroboros.com\u002F","Branch-stable systems.","2026-11-11 14:33:57",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add coroboros\u002Fagent-skills --skill write-clear-readme",{"tool":78,"command":79},"bunx","bunx skills add coroboros\u002Fagent-skills --skill write-clear-readme",{"tool":81,"command":82},"pnpm","pnpm dlx skills add coroboros\u002Fagent-skills --skill write-clear-readme","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-clear-readme\u002FSKILL.md",true,[86,92],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"evals\u002Fevals.json","REFERENCE","参考文档",2155,"https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-clear-readme\u002Fevals\u002Fevals.json",{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"scripts\u002Faudit_readme.py","SCRIPT","脚本",17241,"https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-clear-readme\u002Fscripts\u002Faudit_readme.py",[99,113,123,151,174,199],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":52},"01M71EZVB829YQPX3AM9ETPJYE","foo","Fixture skill for repo-kind classifier tests.","https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftests\u002Fcode-ultrareview\u002Ffixtures\u002Fclassify\u002Fskills\u002Fskills\u002Ffoo\u002FSKILL.md",[],[101,106,107,108,109,110,111,112],"fixture skill","repo","classifier","for","kind","tests","fixture",{"skillNo":114,"name":101,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":52},"01M71EZSPGWRBJ9JGT0Y5F7YGX","Fixture for compound skills + npm tooling detection.","https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftests\u002Fcode-ultrareview\u002Ffixtures\u002Fclassify\u002Fmixed-skills-npm\u002Fskills\u002Ffoo\u002FSKILL.md",[],[101,119,120,109,121,122,112],"npm","tooling","compound","detection",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":132,"publishedAt":52},"01M71EZGFF8C081XJVPGJ11AG7","video-loop","Prepare a background video loop for a website with optional crossfade, MP4\u002FWebM encoding and poster extraction. Use for loop joins or web delivery of an existing clip.","https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fvideo-loop\u002FSKILL.md",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,48,47],"video loop","loop","Video","Audio","when","crossfade","end","fix","continuity","inspection","architecture","processing","hero","command","transition","work","optimize","loops",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":52},"01M71EZCS60P8DK9Y34PHGK1R3","ultrapex","Adaptive implementation when the user explicitly selects \u002Fultrapex or asks for this adaptive workflow. Establish accepted outcomes, implement, and verify the final result. Generic implementation requests use \u002Fapex; use \u002Fforge for decisions only and \u002Foneshot for small focused changes.","https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fultrapex\u002FSKILL.md",[157],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[153,159,160,161,162,163,164,165,166,167,36,168,169,170,139,171,172,40,173,137],"capability","context","Tools","apex","at","result","self","review","workflow","forge","host","delegation","ponytail","select","model",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":184,"publishedAt":52},"01M71EZ5Y1QZWEV5K69JT7QK1D","suno-produce","Create and revise Suno v5.5 prompt artifacts from a song, track or album brief. Produces TRACK.md, ALBUM.md for explicit multi-track work, and optional ARTIST.md identity. Validates prompt fields and preserves supplied lyrics. Artifact-only; audio generation stays in Suno. Pure lyric writing and audio post-production use other skills.","https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsuno-produce\u002FSKILL.md",[180,181,182,183],{"categoryNo":130,"categoryName":131,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[185,186,187,41,188,136,189,190,191,192,193,194,195,196,197,198,168,134,44,169],"suno","produce","suno produce","Meta","question","artifact","website","mv","track","create","guides","lyric","information","song",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":52},"01M71EZ2GDGQ45KBCBPRANVNCF","scaffold","Create a new Next.js or Astro project on the bundled Cloudflare Workers stack with pnpm, Biome and Tailwind. Use for an empty target directory; skip existing applications and requests for a different stack.","https:\u002F\u002Fgithub.com\u002Fcoroboros\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fscaffold\u002FSKILL.md",[],[201,206,207,194,208,209,210,47,211,212,213,214,215,216,217,218,219,40,109,220],"Existing","astro","with","biome","Next.js","version","workers","use","new","cloudflare","applications","deployment","Tailwind","provider","target"]