[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PDK6MNC6EMGA8W7KD7NJQX":3,"skill-same:01M6PDK6MNC6EMGA8W7KD7NJQX":93},{"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":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":67,"repositoryHtmlUrl":68,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":70,"ownerDescription":71,"updatedAt":72,"install":73,"resources":86},"01M6PDK6MNC6EMGA8W7KD7NJQX","writing-project-readme",null,"Use when explicitly invoked to write or fully rewrite a project README that must cover tech stack, architecture, features, and service description in a single document — readable by non-engineers (PM, design, ops, domain experts) as well as developers. Triggers on requests like \"write the README\", \"redo README.md based on the whole project\", \"make a comprehensive README everyone can understand\". Skip for one-section edits, badge tweaks, or generating a CHANGELOG.","douinc\u002Fagent-skills","douinc","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F104253814?v=4","01M6PDGX2D777TNA7NETDKDHCW","dou inc.","01M6PDGX6QMFW72GNMX59GKN6P",1,"MIT","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-project-readme\u002FSKILL.md",[18,23,26,31],{"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},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"project","writing project readme","project readme","README","writing","alpha","stack","changelog","write","domain","pm","design","as","tech","architecture","make","experts","cover","for","features","2026-11-10 10:12:30",false,"---\nname: writing-project-readme\ndescription: Use when explicitly invoked to write or fully rewrite a project README that must cover tech stack, architecture, features, and service description in a single document — readable by non-engineers (PM, design, ops, domain experts) as well as developers. Triggers on requests like \"write the README\", \"redo README.md based on the whole project\", \"make a comprehensive README everyone can understand\". Skip for one-section edits, badge tweaks, or generating a CHANGELOG.\nmetadata:\n  author: initred\n  email: initred@dou.so\n  version: \"0.1.0-alpha\"\n---\n\n# Writing a Project README\n\n## Overview\n\nA great README answers four questions for **two audiences at once**:\n\n1. _What is this?_ — non-engineers must understand in 30 seconds\n2. _How do I use\u002Finstall it?_ — engineers must get unblocked\n3. _How does it fit together?_ — anyone evaluating must see architecture\n4. _Where do I go next?_ — links to deeper docs, never duplicate them\n\nThis skill is **for full rewrites**, not for small edits. Activate only when the user explicitly asks for a comprehensive README.\n\n## Invocation\n\nThis skill runs **only when the user explicitly invokes it** — e.g. `\u002Fwriting-project-readme` or a clear request like \"redo README.md based on the whole project\". Do NOT auto-apply when:\n\n- Editing a single section, fixing a link, or tweaking badges → use `Edit` directly\n- Generating CHANGELOG, API reference, or ADRs → wrong artifact\n- The existing README already covers the four audience questions → propose a tweak, not a rewrite\n\nIf you are reading this skill without an explicit invocation, stop and ask the user whether a full rewrite is intended.\n\n## Core Principle\n\n> **Top third is for non-engineers. Bottom two-thirds is for engineers. Setup details live in a separate file (`DEVELOPMENT.md`, `CONTRIBUTING.md`, etc.) — the README links to them, never copies them.**\n\nIf a non-engineer cannot read the first three sections and explain what the product does, the README has failed regardless of how complete the technical sections are.\n\n## Workflow\n\n```dot\ndigraph readme_flow {\n    \"Confirm scope\" [shape=diamond];\n    \"Parallel discovery (3 agents)\" [shape=box];\n    \"Clarify open choices with user\" [shape=box];\n    \"Draft README following the template\" [shape=box];\n    \"Verify links & rendering\" [shape=box];\n\n    \"Confirm scope\" -> \"Parallel discovery (3 agents)\";\n    \"Parallel discovery (3 agents)\" -> \"Clarify open choices with user\";\n    \"Clarify open choices with user\" -> \"Draft README following the template\";\n    \"Draft README following the template\" -> \"Verify links & rendering\";\n}\n```\n\n### 1. Confirm scope\n\nBefore exploring, confirm:\n\n- Does a setup\u002Fdev-environment doc already exist? (If yes, link to it. **Never** copy setup steps into the README.)\n- Is the project public\u002Fopen-source or internal? (Adjust tone, license, contact section.)\n- Are there download\u002Fstore links, badges, or visual identity to feature?\n\n### 2. Parallel discovery (3 Explore subagents max)\n\nSend a single message with **three Explore agents in parallel** covering:\n\n| Agent                          | Scope                                                                                                                                               |\n| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Backend \u002F server**           | Models, controllers, services, routes, commands, configs, jobs, external API integrations                                                           |\n| **Frontend \u002F client**          | Pages\u002Fscreens, components, layouts, build config, design system, PWA\u002Fnative shell                                                                   |\n| **Business domain & identity** | App name\u002Fdescription\u002Fkeywords from env or manifest, target user, store URLs, internal jargon, key migrations, dependency analysis to infer features |\n\nEach agent should return **structured tables and lists, not prose**. Cap each section at 5–10 lines. Skip storytelling.\n\n#### Prompt templates\n\nHand each Explore agent one of these verbatim — the format is part of the requirement.\n\n**Backend \u002F server agent:**\n\n```text\nRead this project and report the backend surface as compact tables. No prose.\n\nLook in (whichever apply): app\u002F, src\u002F, server\u002F, api\u002F, routes\u002F, jobs\u002F, config\u002F, migrations\u002F, db\u002F.\n\nReport exactly these tables, 5–10 rows each:\n1. Models — Name | Role | Key fields\n2. Routes \u002F endpoints — Method | Path | Handler | One-line purpose\n3. Background jobs \u002F queues — Name | Trigger | Purpose\n4. External integrations — Service | Purpose | Where called\n5. Datastore(s) — Engine | Used for\n\nIf a table has no entries, write \"— none —\".\n```\n\n**Frontend \u002F client agent:**\n\n```text\nRead this project and report the frontend surface as compact tables. No prose.\n\nLook in (whichever apply): apps\u002F, web\u002F, src\u002F, app\u002F, pages\u002F, components\u002F, layouts\u002F, design-system\u002F, public\u002F, package.json, build config files.\n\nReport exactly these tables, 5–10 rows each:\n1. Entry points \u002F routes — Path | Component | Purpose\n2. Top-level layouts — Name | Where used\n3. Design system \u002F shared components — Name | Role\n4. Build & tooling — Tool | Purpose (bundler, framework, CSS, testing)\n5. Platforms shipped — Web \u002F iOS \u002F Android \u002F Desktop \u002F CLI | Status\n\nIf a table has no entries, write \"— none —\".\n```\n\n**Business domain & identity agent:**\n\n```text\nRead this project and report the product identity as compact tables. No prose.\n\nLook in: README, package.json, manifest files (app.json, capacitor.config.*, Info.plist, AndroidManifest.xml), .env.example, docs\u002F, marketing\u002F, store-listing\u002F.\n\nReport exactly:\n1. Product identity — Name | Tagline | Target user (one line each)\n2. Distribution — Platform | Link or \"internal\" | Status\n3. Core features inferred from code\u002Fdeps — Feature | Evidence (file or dep)\n4. Internal jargon \u002F domain terms — Term | Definition\n5. Compliance \u002F standards mentioned — Standard | Where (filename or doc)\n\nIf a table has no entries, write \"— none —\".\n```\n\n### 3. Clarify open choices with the user\n\nAfter discovery, ask **at most 3 questions** via the user-question tool. Default recommendations:\n\n| Question                             | Recommended default                                                                   |\n| ------------------------------------ | ------------------------------------------------------------------------------------- |\n| Architecture diagram format          | Mermaid (renders on GitHub, scannable for non-engineers)                              |\n| Tech-stack badges                    | Include 4–6 core badges (language, framework, key libraries)                          |\n| Jargon level in feature descriptions | Non-engineer prose first, technology in parentheses: `처방약 자동 불러오기 (연동: …)` |\n\nAvoid open-ended \"any preferences?\" prompts — present concrete options with previews.\n\n### 4. Draft using the template (below)\n\nFollow the section order strictly. The order itself does work — front-loading non-engineer content is the whole point.\n\n### 5. Verify\n\n- Every internal link resolves (relative paths exist)\n- Mermaid blocks render in a GitHub preview\n- Tables align under monospace; no broken pipes\n- Zero emojis (unless the user explicitly requested them)\n- Setup commands shown are **a 3–5 line teaser**, with a link to the full setup doc\n\n## README Template\n\n전체 템플릿은 [`template.md`](.\u002Ftemplate.md) 참고. 섹션 순서가 룰의 핵심이므로 임의 변경 금지 — 상단 1\u002F3은 비개발자, 하단 2\u002F3은 개발자.\n\n## Adapting to Project Type\n\nThe template assumes a service app. Adjust before drafting:\n\n| Project type               | Required sections                                                      | Skip \u002F adapt                      |\n| -------------------------- | ---------------------------------------------------------------------- | --------------------------------- |\n| Service app (web\u002Fmobile)   | What \u002F Who \u002F Features \u002F Architecture \u002F Setup                           | —                                 |\n| Library \u002F SDK              | What \u002F Install \u002F Quick example \u002F API summary                           | \"User journey\", \"Platforms\"       |\n| CLI tool                   | What \u002F Install \u002F Commands \u002F Examples                                   | Architecture diagram (보통 과함)  |\n| Plugin \u002F skill marketplace | What \u002F 목록 테이블 \u002F Install per item \u002F Contributing                   | \"User journey\", ERD               |\n| Monorepo                   | Top-level: What \u002F Packages 표 \u002F Architecture. 각 패키지는 자체 README. | 단일 Tech stack — 패키지별로 분산 |\n\nThis project (`agent-skills`) is the plugin \u002F skill marketplace case — its [`README.md`](..\u002F..\u002FREADME.md) is a working reference layout.\n\n## Writing Rules\n\n- **No emojis** unless the user explicitly opts in.\n- **No HTML** if Markdown alternatives exist. Tables > nested HTML divs.\n- **Mermaid > ASCII > image** for diagrams. Mermaid renders on GitHub and stays diffable.\n- **Tables for any 3+ parallel items.** Bullet lists become unscannable past 5 lines.\n- **Code fences must specify a language** (`bash`, `text`, `mermaid`, `php`, `ts`, …) for syntax highlighting and lint compliance.\n- **Blank lines around headings, lists, tables, fenced blocks.** Many Markdown linters flag missing ones.\n- **Non-engineer phrasing first, jargon in parentheses.** Example: _Prescription auto-import (via insurance-claims API)_.\n- **One verb per feature row.** Verbs reveal value; nouns hide it.\n- **Don't restate setup.** Link to the dev guide. The README is the front door, not the manual.\n\n## Language & Localization\n\n| Audience         | Pattern                                                            |\n| ---------------- | ------------------------------------------------------------------ |\n| 국내 사용자 중심 | 한국어 우선, 영어 보조 (코드\u002F명령어만 영어)                        |\n| 글로벌 OSS       | 영어 단일                                                          |\n| 한국 + 해외 동시 | 섹션 라벨 병기 — `설치 \u002F Installation`, `목차 \u002F Table of Contents` |\n\nWhen writing Korean copy, follow the [`ux-writing-korean`](..\u002Fux-writing-korean\u002FSKILL.md) skill. 핵심 규칙:\n\n- 캐주얼 경어 (`-요`체), 능동형, 긍정형\n- 명사 조합 회피 — `사용자 등록 처리` → `사용자를 등록해요`\n- 이모지는 사용자가 명시적으로 요청했을 때만\n\nThis project's own [README.md](..\u002F..\u002FREADME.md) is a working example of the bilingual pattern.\n\n## Concrete Examples\n\n### Opening section\n\nBad — framework-first, no user value:\n\n```markdown\n# Awesome Project\n\nA Laravel 11 application using Inertia.js, Tailwind CSS, and PostgreSQL.\n```\n\nGood — user value first, stack as supporting metadata:\n\n```markdown\n# Awesome Project\n\n> **약을 깜빡해도 괜찮은 복약 관리 앱**\n> 처방전을 사진 한 장으로 등록하면, 시간 맞춰 알려드려요.\n\nPHP · Laravel · Inertia · PostgreSQL\n```\n\n### Feature list\n\nBad — prose buries the value:\n\n```markdown\nThe application allows users to register, manage their medication schedules,\nreceive notifications, share with family members, and view adherence reports.\n```\n\nGood — table with verb-first rows, 한국어\u002F영어 병기:\n\n```markdown\n| 기능             | 설명                                            |\n| ---------------- | ----------------------------------------------- |\n| 처방전 자동 등록 | 사진 한 장으로 약·복약 시간 입력 (OCR API 연동) |\n| 복약 알림        | 시간대별 푸시 알림 + 잠금화면 위젯              |\n| 가족 공유        | 보호자가 복약 여부를 실시간으로 확인            |\n| 복약 리포트      | 주\u002F월 단위 복용률, PDF 내보내기                 |\n```\n\n### Architecture diagram\n\nBad — single blob, 20+ nodes, unreadable:\n\n```mermaid\nflowchart LR\n  A[Mobile] --> B[API Gateway] --> C[Auth] --> D[User] --> E[Prescription] --> F[OCR Worker] --> G[(Postgres)]\n  E --> H[Notification] --> I[FCM] --> J[APNs] --> K[Family] --> L[Reports] --> M[PDF] --> N[(S3)]\n  D --> O[Profile] --> P[Settings] --> Q[Billing] --> R[Stripe]\n```\n\nGood — split into user journey + system, each ≤12 nodes:\n\n```mermaid\nflowchart LR\n  Signup --> Onboarding --> 처방전등록 --> 복약알림 --> 꾸준한복약\n```\n\n```mermaid\nflowchart LR\n  Mobile --> API\n  API --> Auth\n  API --> Prescription --> OCR\n  API --> Notification --> FCM\n  API -.-> Postgres\n  OCR -.-> S3\n```\n\n## Common Mistakes\n\n| Mistake                                                           | Fix                                                           |\n| ----------------------------------------------------------------- | ------------------------------------------------------------- |\n| Opening with \"Installation\" before the product is explained       | Move What\u002FWho\u002FFeatures above any setup                        |\n| Burying app name behind technical framing (\"A Laravel app for …\") | Lead with what the user gets, not the framework               |\n| Copying every dev-setup command into the README                   | Show 3–5 line teaser + link to the dedicated doc              |\n| Dense paragraphs of feature descriptions                          | Convert to tables; one row per feature                        |\n| Mermaid diagram with 20+ nodes                                    | Split into two diagrams (user journey vs. system) or simplify |\n| Badges for every dependency                                       | Cap at 4–6 — only what defines the project                    |\n| Single \"Tech stack\" list with 40 items                            | Group by layer in a table                                     |\n| `**\\`text\\`\\*\\*` mixing bold + code unnecessarily                 | Pick one. Code for identifiers, bold for emphasis             |\n| ASCII art trees in serif preview                                  | Use a fenced `text` block so it renders monospace             |\n| Stale links to renamed files                                      | Re-verify every relative link after writing                   |\n\n## Rationalization Table\n\nExcuses you may catch yourself making, and the correct response:\n\n| Excuse                                         | Reality                                                               |\n| ---------------------------------------------- | --------------------------------------------------------------------- |\n| \"유저가 기술자라 jargon 써도 됨\"               | 비개발자 한 명이라도 읽는다고 가정. 첫 세 섹션은 평이한 언어로.       |\n| \"셋업이 3줄이라 그냥 README에 넣자\"            | 다음 사람이 또 복사함. 별도 파일이 없으면 새로 만들고, 있으면 링크만. |\n| \"이모지 하나만 — 분위기 살리기용\"              | 사용자가 명시적으로 요청하지 않았으면 0개.                            |\n| \"다이어그램 노드가 20개여도 정확한 게 우선\"    | 12개 넘으면 안 읽힘. 둘로 쪼개거나 단순화.                            |\n| \"기존 README가 짧으니 새로 쓰자\"               | tweak 요청이면 풀 재작성 금지. When-Not-to-use 적용.                  |\n| \"프레임워크 이름이 곧 정체성\"                  | 도구가 아닌 사용자 가치를 첫 문장에. 스택은 뱃지\u002FTech stack 섹션으로. |\n| \"한국어 README라 ux-writing-korean까지는 과함\" | 톤이 어긋나면 가독성이 깨짐. 5분이면 핵심 규칙 확인 가능.             |\n\n## Red Flags — STOP and Reconsider\n\n- You are about to paste setup commands instead of linking → **Stop, link to dev doc.**\n- You are writing your fifth paragraph before any heading → **Stop, convert to a table.**\n- A non-engineer reading the first screen still can't say what the product does → **Stop, rewrite the top section.**\n- Diagram has more than ~12 nodes → **Stop, split or simplify.**\n- You added an emoji \"for warmth\" → **Stop, remove it unless the user asked.**\n\n## When Not To Use This Skill\n\n- Adding one badge or one section to an existing README → just edit\n- Generating a CHANGELOG, RELEASE_NOTES, or API reference → different artifact\n- Writing internal architecture decision records → use ADR conventions\n- The project already has a good README and the user wants a tweak → don't rewrite\n\n## Discovery Checklist Before Writing\n\n- [ ] Confirmed full rewrite is wanted (not a tweak)\n- [ ] Located existing dev\u002Fsetup doc and confirmed it stays the source of truth\n- [ ] Ran 3 parallel discovery agents (backend \u002F frontend \u002F domain)\n- [ ] Identified target audiences (non-engineer roles included)\n- [ ] Asked at most 3 clarifying questions with concrete options\n- [ ] Confirmed badge set, diagram format, jargon level\n\n## Verification After Writing\n\nRun these once — all use `npx -y`, no permanent install:\n\n```bash\n# Markdown lint\nnpx -y markdownlint-cli README.md\n\n# Relative-link resolution\nnpx -y markdown-link-check README.md\n\n# Mermaid renders (writes rendered .md to \u002Ftmp; visually inspect or rely on GitHub preview)\nnpx -y @mermaid-js\u002Fmermaid-cli -i README.md -o \u002Ftmp\u002Freadme-rendered.md\n```\n\nThen walk the checklist:\n\n- [ ] All relative links resolve\n- [ ] Mermaid blocks render\n- [ ] No emojis (unless requested)\n- [ ] Setup section is a teaser + link, not a copy\n- [ ] Non-engineer can summarize the product after reading the first three sections\n- [ ] Engineer can locate architecture, structure, and commands without scrolling past unfamiliar prose\n","# Writing a Project README\n\n## Overview\n\nA great README answers four questions for **two audiences at once**:\n\n1. _What is this?_ — non-engineers must understand in 30 seconds\n2. _How do I use\u002Finstall it?_ — engineers must get unblocked\n3. _How does it fit together?_ — anyone evaluating must see architecture\n4. _Where do I go next?_ — links to deeper docs, never duplicate them\n\nThis skill is **for full rewrites**, not for small edits. Activate only when the user explicitly asks for a comprehensive README.\n\n## Invocation\n\nThis skill runs **only when the user explicitly invokes it** — e.g. `\u002Fwriting-project-readme` or a clear request like \"redo README.md based on the whole project\". Do NOT auto-apply when:\n\n- Editing a single section, fixing a link, or tweaking badges → use `Edit` directly\n- Generating CHANGELOG, API reference, or ADRs → wrong artifact\n- The existing README already covers the four audience questions → propose a tweak, not a rewrite\n\nIf you are reading this skill without an explicit invocation, stop and ask the user whether a full rewrite is intended.\n\n## Core Principle\n\n> **Top third is for non-engineers. Bottom two-thirds is for engineers. Setup details live in a separate file (`DEVELOPMENT.md`, `CONTRIBUTING.md`, etc.) — the README links to them, never copies them.**\n\nIf a non-engineer cannot read the first three sections and explain what the product does, the README has failed regardless of how complete the technical sections are.\n\n## Workflow\n\n```dot\ndigraph readme_flow {\n    \"Confirm scope\" [shape=diamond];\n    \"Parallel discovery (3 agents)\" [shape=box];\n    \"Clarify open choices with user\" [shape=box];\n    \"Draft README following the template\" [shape=box];\n    \"Verify links & rendering\" [shape=box];\n\n    \"Confirm scope\" -> \"Parallel discovery (3 agents)\";\n    \"Parallel discovery (3 agents)\" -> \"Clarify open choices with user\";\n    \"Clarify open choices with user\" -> \"Draft README following the template\";\n    \"Draft README following the template\" -> \"Verify links & rendering\";\n}\n```\n\n### 1. Confirm scope\n\nBefore exploring, confirm:\n\n- Does a setup\u002Fdev-environment doc already exist? (If yes, link to it. **Never** copy setup steps into the README.)\n- Is the project public\u002Fopen-source or internal? (Adjust tone, license, contact section.)\n- Are there download\u002Fstore links, badges, or visual identity to feature?\n\n### 2. Parallel discovery (3 Explore subagents max)\n\nSend a single message with **three Explore agents in parallel** covering:\n\n| Agent                          | Scope                                                                                                                                               |\n| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Backend \u002F server**           | Models, controllers, services, routes, commands, configs, jobs, external API integrations                                                           |\n| **Frontend \u002F client**          | Pages\u002Fscreens, components, layouts, build config, design system, PWA\u002Fnative shell                                                                   |\n| **Business domain & identity** | App name\u002Fdescription\u002Fkeywords from env or manifest, target user, store URLs, internal jargon, key migrations, dependency analysis to infer features |\n\nEach agent should return **structured tables and lists, not prose**. Cap each section at 5–10 lines. Skip storytelling.\n\n#### Prompt templates\n\nHand each Explore agent one of these verbatim — the format is part of the requirement.\n\n**Backend \u002F server agent:**\n\n```text\nRead this project and report the backend surface as compact tables. No prose.\n\nLook in (whichever apply): app\u002F, src\u002F, server\u002F, api\u002F, routes\u002F, jobs\u002F, config\u002F, migrations\u002F, db\u002F.\n\nReport exactly these tables, 5–10 rows each:\n1. Models — Name | Role | Key fields\n2. Routes \u002F endpoints — Method | Path | Handler | One-line purpose\n3. Background jobs \u002F queues — Name | Trigger | Purpose\n4. External integrations — Service | Purpose | Where called\n5. Datastore(s) — Engine | Used for\n\nIf a table has no entries, write \"— none —\".\n```\n\n**Frontend \u002F client agent:**\n\n```text\nRead this project and report the frontend surface as compact tables. No prose.\n\nLook in (whichever apply): apps\u002F, web\u002F, src\u002F, app\u002F, pages\u002F, components\u002F, layouts\u002F, design-system\u002F, public\u002F, package.json, build config files.\n\nReport exactly these tables, 5–10 rows each:\n1. Entry points \u002F routes — Path | Component | Purpose\n2. Top-level layouts — Name | Where used\n3. Design system \u002F shared components — Name | Role\n4. Build & tooling — Tool | Purpose (bundler, framework, CSS, testing)\n5. Platforms shipped — Web \u002F iOS \u002F Android \u002F Desktop \u002F CLI | Status\n\nIf a table has no entries, write \"— none —\".\n```\n\n**Business domain & identity agent:**\n\n```text\nRead this project and report the product identity as compact tables. No prose.\n\nLook in: README, package.json, manifest files (app.json, capacitor.config.*, Info.plist, AndroidManifest.xml), .env.example, docs\u002F, marketing\u002F, store-listing\u002F.\n\nReport exactly:\n1. Product identity — Name | Tagline | Target user (one line each)\n2. Distribution — Platform | Link or \"internal\" | Status\n3. Core features inferred from code\u002Fdeps — Feature | Evidence (file or dep)\n4. Internal jargon \u002F domain terms — Term | Definition\n5. Compliance \u002F standards mentioned — Standard | Where (filename or doc)\n\nIf a table has no entries, write \"— none —\".\n```\n\n### 3. Clarify open choices with the user\n\nAfter discovery, ask **at most 3 questions** via the user-question tool. Default recommendations:\n\n| Question                             | Recommended default                                                                   |\n| ------------------------------------ | ------------------------------------------------------------------------------------- |\n| Architecture diagram format          | Mermaid (renders on GitHub, scannable for non-engineers)                              |\n| Tech-stack badges                    | Include 4–6 core badges (language, framework, key libraries)                          |\n| Jargon level in feature descriptions | Non-engineer prose first, technology in parentheses: `처방약 자동 불러오기 (연동: …)` |\n\nAvoid open-ended \"any preferences?\" prompts — present concrete options with previews.\n\n### 4. Draft using the template (below)\n\nFollow the section order strictly. The order itself does work — front-loading non-engineer content is the whole point.\n\n### 5. Verify\n\n- Every internal link resolves (relative paths exist)\n- Mermaid blocks render in a GitHub preview\n- Tables align under monospace; no broken pipes\n- Zero emojis (unless the user explicitly requested them)\n- Setup commands shown are **a 3–5 line teaser**, with a link to the full setup doc\n\n## README Template\n\n전체 템플릿은 [`template.md`](.\u002Ftemplate.md) 참고. 섹션 순서가 룰의 핵심이므로 임의 변경 금지 — 상단 1\u002F3은 비개발자, 하단 2\u002F3은 개발자.\n\n## Adapting to Project Type\n\nThe template assumes a service app. Adjust before drafting:\n\n| Project type               | Required sections                                                      | Skip \u002F adapt                      |\n| -------------------------- | ---------------------------------------------------------------------- | --------------------------------- |\n| Service app (web\u002Fmobile)   | What \u002F Who \u002F Features \u002F Architecture \u002F Setup                           | —                                 |\n| Library \u002F SDK              | What \u002F Install \u002F Quick example \u002F API summary                           | \"User journey\", \"Platforms\"       |\n| CLI tool                   | What \u002F Install \u002F Commands \u002F Examples                                   | Architecture diagram (보통 과함)  |\n| Plugin \u002F skill marketplace | What \u002F 목록 테이블 \u002F Install per item \u002F Contributing                   | \"User journey\", ERD               |\n| Monorepo                   | Top-level: What \u002F Packages 표 \u002F Architecture. 각 패키지는 자체 README. | 단일 Tech stack — 패키지별로 분산 |\n\nThis project (`agent-skills`) is the plugin \u002F skill marketplace case — its [`README.md`](..\u002F..\u002FREADME.md) is a working reference layout.\n\n## Writing Rules\n\n- **No emojis** unless the user explicitly opts in.\n- **No HTML** if Markdown alternatives exist. Tables > nested HTML divs.\n- **Mermaid > ASCII > image** for diagrams. Mermaid renders on GitHub and stays diffable.\n- **Tables for any 3+ parallel items.** Bullet lists become unscannable past 5 lines.\n- **Code fences must specify a language** (`bash`, `text`, `mermaid`, `php`, `ts`, …) for syntax highlighting and lint compliance.\n- **Blank lines around headings, lists, tables, fenced blocks.** Many Markdown linters flag missing ones.\n- **Non-engineer phrasing first, jargon in parentheses.** Example: _Prescription auto-import (via insurance-claims API)_.\n- **One verb per feature row.** Verbs reveal value; nouns hide it.\n- **Don't restate setup.** Link to the dev guide. The README is the front door, not the manual.\n\n## Language & Localization\n\n| Audience         | Pattern                                                            |\n| ---------------- | ------------------------------------------------------------------ |\n| 국내 사용자 중심 | 한국어 우선, 영어 보조 (코드\u002F명령어만 영어)                        |\n| 글로벌 OSS       | 영어 단일                                                          |\n| 한국 + 해외 동시 | 섹션 라벨 병기 — `설치 \u002F Installation`, `목차 \u002F Table of Contents` |\n\nWhen writing Korean copy, follow the [`ux-writing-korean`](..\u002Fux-writing-korean\u002FSKILL.md) skill. 핵심 규칙:\n\n- 캐주얼 경어 (`-요`체), 능동형, 긍정형\n- 명사 조합 회피 — `사용자 등록 처리` → `사용자를 등록해요`\n- 이모지는 사용자가 명시적으로 요청했을 때만\n\nThis project's own [README.md](..\u002F..\u002FREADME.md) is a working example of the bilingual pattern.\n\n## Concrete Examples\n\n### Opening section\n\nBad — framework-first, no user value:\n\n```markdown\n# Awesome Project\n\nA Laravel 11 application using Inertia.js, Tailwind CSS, and PostgreSQL.\n```\n\nGood — user value first, stack as supporting metadata:\n\n```markdown\n# Awesome Project\n\n> **약을 깜빡해도 괜찮은 복약 관리 앱**\n> 처방전을 사진 한 장으로 등록하면, 시간 맞춰 알려드려요.\n\nPHP · Laravel · Inertia · PostgreSQL\n```\n\n### Feature list\n\nBad — prose buries the value:\n\n```markdown\nThe application allows users to register, manage their medication schedules,\nreceive notifications, share with family members, and view adherence reports.\n```\n\nGood — table with verb-first rows, 한국어\u002F영어 병기:\n\n```markdown\n| 기능             | 설명                                            |\n| ---------------- | ----------------------------------------------- |\n| 처방전 자동 등록 | 사진 한 장으로 약·복약 시간 입력 (OCR API 연동) |\n| 복약 알림        | 시간대별 푸시 알림 + 잠금화면 위젯              |\n| 가족 공유        | 보호자가 복약 여부를 실시간으로 확인            |\n| 복약 리포트      | 주\u002F월 단위 복용률, PDF 내보내기                 |\n```\n\n### Architecture diagram\n\nBad — single blob, 20+ nodes, unreadable:\n\n```mermaid\nflowchart LR\n  A[Mobile] --> B[API Gateway] --> C[Auth] --> D[User] --> E[Prescription] --> F[OCR Worker] --> G[(Postgres)]\n  E --> H[Notification] --> I[FCM] --> J[APNs] --> K[Family] --> L[Reports] --> M[PDF] --> N[(S3)]\n  D --> O[Profile] --> P[Settings] --> Q[Billing] --> R[Stripe]\n```\n\nGood — split into user journey + system, each ≤12 nodes:\n\n```mermaid\nflowchart LR\n  Signup --> Onboarding --> 처방전등록 --> 복약알림 --> 꾸준한복약\n```\n\n```mermaid\nflowchart LR\n  Mobile --> API\n  API --> Auth\n  API --> Prescription --> OCR\n  API --> Notification --> FCM\n  API -.-> Postgres\n  OCR -.-> S3\n```\n\n## Common Mistakes\n\n| Mistake                                                           | Fix                                                           |\n| ----------------------------------------------------------------- | ------------------------------------------------------------- |\n| Opening with \"Installation\" before the product is explained       | Move What\u002FWho\u002FFeatures above any setup                        |\n| Burying app name behind technical framing (\"A Laravel app for …\") | Lead with what the user gets, not the framework               |\n| Copying every dev-setup command into the README                   | Show 3–5 line teaser + link to the dedicated doc              |\n| Dense paragraphs of feature descriptions                          | Convert to tables; one row per feature                        |\n| Mermaid diagram with 20+ nodes                                    | Split into two diagrams (user journey vs. system) or simplify |\n| Badges for every dependency                                       | Cap at 4–6 — only what defines the project                    |\n| Single \"Tech stack\" list with 40 items                            | Group by layer in a table                                     |\n| `**\\`text\\`\\*\\*` mixing bold + code unnecessarily                 | Pick one. Code for identifiers, bold for emphasis             |\n| ASCII art trees in serif preview                                  | Use a fenced `text` block so it renders monospace             |\n| Stale links to renamed files                                      | Re-verify every relative link after writing                   |\n\n## Rationalization Table\n\nExcuses you may catch yourself making, and the correct response:\n\n| Excuse                                         | Reality                                                               |\n| ---------------------------------------------- | --------------------------------------------------------------------- |\n| \"유저가 기술자라 jargon 써도 됨\"               | 비개발자 한 명이라도 읽는다고 가정. 첫 세 섹션은 평이한 언어로.       |\n| \"셋업이 3줄이라 그냥 README에 넣자\"            | 다음 사람이 또 복사함. 별도 파일이 없으면 새로 만들고, 있으면 링크만. |\n| \"이모지 하나만 — 분위기 살리기용\"              | 사용자가 명시적으로 요청하지 않았으면 0개.                            |\n| \"다이어그램 노드가 20개여도 정확한 게 우선\"    | 12개 넘으면 안 읽힘. 둘로 쪼개거나 단순화.                            |\n| \"기존 README가 짧으니 새로 쓰자\"               | tweak 요청이면 풀 재작성 금지. When-Not-to-use 적용.                  |\n| \"프레임워크 이름이 곧 정체성\"                  | 도구가 아닌 사용자 가치를 첫 문장에. 스택은 뱃지\u002FTech stack 섹션으로. |\n| \"한국어 README라 ux-writing-korean까지는 과함\" | 톤이 어긋나면 가독성이 깨짐. 5분이면 핵심 규칙 확인 가능.             |\n\n## Red Flags — STOP and Reconsider\n\n- You are about to paste setup commands instead of linking → **Stop, link to dev doc.**\n- You are writing your fifth paragraph before any heading → **Stop, convert to a table.**\n- A non-engineer reading the first screen still can't say what the product does → **Stop, rewrite the top section.**\n- Diagram has more than ~12 nodes → **Stop, split or simplify.**\n- You added an emoji \"for warmth\" → **Stop, remove it unless the user asked.**\n\n## When Not To Use This Skill\n\n- Adding one badge or one section to an existing README → just edit\n- Generating a CHANGELOG, RELEASE_NOTES, or API reference → different artifact\n- Writing internal architecture decision records → use ADR conventions\n- The project already has a good README and the user wants a tweak → don't rewrite\n\n## Discovery Checklist Before Writing\n\n- [ ] Confirmed full rewrite is wanted (not a tweak)\n- [ ] Located existing dev\u002Fsetup doc and confirmed it stays the source of truth\n- [ ] Ran 3 parallel discovery agents (backend \u002F frontend \u002F domain)\n- [ ] Identified target audiences (non-engineer roles included)\n- [ ] Asked at most 3 clarifying questions with concrete options\n- [ ] Confirmed badge set, diagram format, jargon level\n\n## Verification After Writing\n\nRun these once — all use `npx -y`, no permanent install:\n\n```bash\n# Markdown lint\nnpx -y markdownlint-cli README.md\n\n# Relative-link resolution\nnpx -y markdown-link-check README.md\n\n# Mermaid renders (writes rendered .md to \u002Ftmp; visually inspect or rely on GitHub preview)\nnpx -y @mermaid-js\u002Fmermaid-cli -i README.md -o \u002Ftmp\u002Freadme-rendered.md\n```\n\nThen walk the checklist:\n\n- [ ] All relative links resolve\n- [ ] Mermaid blocks render\n- [ ] No emojis (unless requested)\n- [ ] Setup section is a teaser + link, not a copy\n- [ ] Non-engineer can summarize the product after reading the first three sections\n- [ ] Engineer can locate architecture, structure, and commands without scrolling past unfamiliar prose\n",{"name":5,"metadata":60,"description":7},{"email":61,"author":62,"version":63},"initred@dou.so","initred","0.1.0-alpha","main","ee55538fc8b60bb1595f860f18cbd7baba1925aa","skills\u002Fwriting-project-readme",0,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills","https:\u002F\u002Fgithub.com\u002Fdouinc","https:\u002F\u002Fdou.so","A clinical intelligence company","2026-11-12 10:02:01",{"source":8,"skillName":5,"commands":74,"prompt":84,"zipAvailable":85},[75,78,81],{"tool":76,"command":77},"npx","npx skills add douinc\u002Fagent-skills --skill writing-project-readme",{"tool":79,"command":80},"bunx","bunx skills add douinc\u002Fagent-skills --skill writing-project-readme",{"tool":82,"command":83},"pnpm","pnpm dlx skills add douinc\u002Fagent-skills --skill writing-project-readme","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-project-readme\u002FSKILL.md",true,[87],{"path":88,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":91,"sourceHtmlUrl":92},"template.md","REFERENCE","参考文档",1810,"https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-project-readme\u002Ftemplate.md",[94,108,123,153,169,192],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":101,"publishedAt":55},"01M6PDKC7XDA3NYF969T945D7S","template-skill","Replace with description of the skill and when the agent should use it.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Ftemplate\u002FSKILL.md",[100],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[102,103,104,105,106,107],"template","template skill","it","with","name","use",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":117,"publishedAt":55},"01M6PDK2S8KXK1NDM22C9FKE49","ux-writing-korean","한국어로 UI\u002FUX 문구를 작성하거나 검수할 때 사용합니다. 해요체, 능동형, 긍정형, 캐주얼 경어, 명사 조합 회피 등 5가지 핵심 원칙과 예외 규칙을 적용합니다.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fux-writing-korean\u002FSKILL.md",[114,115,116],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},[118,119,120,39,121,122],"ux writing korean","korean","ux","ux writing","ui",{"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":133,"publishedAt":55},"01M6PDJXK3DVWFR0420XV79HZ6","token-audit","Audit a Claude Code or Codex CLI project for token waste and fix it with the user's approval. Use whenever the user wants to check, reduce, or optimize token usage, context bloat, or API\u002Fsubscription costs of an agent project — phrases like \"토큰 점검\", \"토큰 낭비 찾아줘\", \"토큰 최적화\", \"컨텍스트 최적화\", \"Claude Code 비용 줄여줘\", \"API 비용이 너무 나와\", \"audit token efficiency\", \"check my CLAUDE.md\u002FAGENTS.md\u002FMCP setup\". Also trigger when the user complains that sessions hit context limits too fast, that costs jumped unexpectedly, or asks whether their project setup is token-efficient — even if they don't say the word \"token\".","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftoken-audit\u002FSKILL.md",[129,130],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":131,"categoryName":132,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师",[134,135,136,137,138,139,140,141,35,142,143,144,145,146,147,148,149,150,151,152],"token audit","token","audit","api","code","reduce","MCP","fix","codex cli","efficiency","optimize","cli","limits","my","bloat","context","token efficiency","usage","mcp setup",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":55},"01M6PDJR1Y9BAM48RDKRQHK5MQ","release-showcase","정식 릴리스의 변경을 이전·이후 스크린샷, 클릭 흐름 녹화 영상, 비교·단계·탭·흐름도 같은 HTML 컴포넌트로 보여 주는 파일 하나짜리 릴리스 문서를 만든다. 텍스트뿐인 릴리스 노트로는 어떤 UX가 바뀌었고 새 기능을 어떻게 쓰는지 감이 안 올 때 쓴다. '릴리스 노트 문서 만들어 줘', '릴리스 쇼케이스', '이번 배포 변경사항 정리해서 공유', '릴리즈 노트 HTML', '변경사항을 화면으로 보여 주는 문서', '업데이트 소개 페이지', 'what's new 페이지', 'release notes with screenshots', 'changelog page', '배포 공지 자료'처럼 버전 태그 사이의 변경을 팀·고객에게 시각적으로 알릴 때 반드시 사용한다. git 태그로 릴리스하는 저장소라면 웹·데스크톱·모바일 어느 앱이든 쓴다. 커밋 목록만 필요한 CHANGELOG.md 갱신, 릴리스 태그·배포 자체, 마케팅 영상 제작에는 쓰지 않는다.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Frelease-showcase\u002FSKILL.md",[],[160,161,162,163,164,42,165,105,166,167,168],"release showcase","showcase","release","screenshots","git","notes","release notes","page","html",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":177,"publishedAt":55},"01M6PDJJEQMBWWXW4TPXYNNV38","public-sector-rfp-authoring","Use when drafting or revising Korean government or local-government bid notices, requests for proposals, statements of work, or public-sector service\u002Fproject specifications from the ordering agency's perspective.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fpublic-sector-rfp-authoring\u002FSKILL.md",[175,176],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[178,179,180,181,182,35,119,183,184,185,186,187,188,189,190,107,53,191],"rfp","public","public sector rfp authoring","authoring","local","work","perspective","hermes agent","hermes","service","agency","specifications","requests","proposals",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":205,"publishedAt":55},"01M6PDJBRJXB46K8JKRNHSBRYY","onboarding-design","Use when designing, reviewing, or auditing signup flows, goal-selection quizzes, permission prompts, paywalls, or any screen a user sees before their first meaningful action.","https:\u002F\u002Fgithub.com\u002Fdouinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fonboarding-design\u002FSKILL.md",[198,201,202],{"categoryNo":199,"categoryName":200,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},{"categoryNo":203,"categoryName":204,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000038","人力资源",[206,46,207,208,209,210,211,212,107,213,214,215,216,217,218,219],"onboarding design","onboarding","signup","user","prompts","quizzes","first","permission","action","screen","goal","selection","flows","paywalls"]