{"id":"723da800-af9e-4671-a5a2-c5f00a046548","entityType":"agent","slug":"clawhub-athola-nm-scribe-doc-generator","name":"doc-generator","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-scribe-doc-generator","canonicalPath":"/agent/clawhub-athola-nm-scribe-doc-generator","generatedAt":"2026-10-10T10:53:18.405Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T06:58:18.069Z","emptyReason":null},"description":"Generates or remediates documentation with human-quality writing Skill: doc-generator Owner: athola Summary: Generates or remediates documentation with human-quality writing Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:21:38.769Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:41:36.970Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:58:22.982Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:06:10.480Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:23:55.031Z | user","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.6K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-scribe-doc-generator","sourceUrl":"https://clawhub.ai/athola/nm-scribe-doc-generator","homepage":"https://clawhub.ai/athola/skills/nm-scribe-doc-generator","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-scribe-doc-generator","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-scribe-doc-generator","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":64,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Generates or remediates documentation with human-quality writing Skill: doc-generator Owner: athola Summary: Generates or remediates documentation with human-qu"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:58:18.069Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:58:18.069Z","emptyReason":null},"stars":null,"forks":null,"downloads":1606,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.6K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T06:58:18.069Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T06:58:18.069Z","lastCrawledAt":"2026-10-10T06:58:18.069Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T06:58:18.069Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:21:38.769Z","changelog":"Release v1.9.19","fileCount":6,"zipByteSize":10009},{"version":"1.9.17","createdAt":"2026-07-30T05:41:36.970Z","changelog":"Release v1.9.17","fileCount":6,"zipByteSize":10252},{"version":"1.9.16","createdAt":"2026-07-14T19:58:22.982Z","changelog":"Release v1.9.16","fileCount":6,"zipByteSize":10372},{"version":"1.9.14","createdAt":"2026-06-30T18:06:10.480Z","changelog":"Release v1.9.14","fileCount":6,"zipByteSize":10257},{"version":"1.9.13","createdAt":"2026-06-27T16:23:55.031Z","changelog":"Release v1.9.13","fileCount":6,"zipByteSize":10226},{"version":"1.9.12","createdAt":"2026-06-19T03:19:31.294Z","changelog":"Release v1.9.12","fileCount":6,"zipByteSize":10087},{"version":"1.0.2","createdAt":"2026-05-09T02:20:17.628Z","changelog":"Release v1.9.5","fileCount":6,"zipByteSize":9549},{"version":"1.0.1","createdAt":"2026-05-06T14:21:45.846Z","changelog":"Release v1.9.4","fileCount":5,"zipByteSize":8268}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-scribe-doc-generator","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T10:53:18.400Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-scribe-doc-generator/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T06:58:18.069Z","emptyReason":null},"readme":"Skill: doc-generator\n\nOwner: athola\n\nSummary: Generates or remediates documentation with human-quality writing\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:21:38.769Z | user\n\nRelease v1.9.19\n\nv1.9.17 | 2026-07-30T05:41:36.970Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:58:22.982Z | user\n\nRelease v1.9.16\n\nv1.9.14 | 2026-06-30T18:06:10.480Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:23:55.031Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:19:31.294Z | user\n\nRelease v1.9.12\n\nv1.0.2 | 2026-05-09T02:20:17.628Z | user\n\nRelease v1.9.5\n\nv1.0.1 | 2026-05-06T14:21:45.846Z | user\n\nRelease v1.9.4\n\nv1.0.0 | 2026-04-20T14:01:33.828Z | auto\n\n- Initial release of nm-scribe-doc-generator skill.\n- Automates high-quality documentation generation and remediation based on human-centric style and grounded claims.\n- Enforces clear writing principles: active voice, imperative mood for docstrings, minimal bullets, and avoidance of business jargon or vague language.\n- Integrates \"slop-detector\" for stylistic consistency and provides step-by-step workflows for both generation and remediation modes.\n- Includes strict quality gate criteria and structured approval processes to ensure output meets documentation standards.\n\nArchive index:\n\nArchive v1.9.19: 6 files, 10009 bytes\n\nFiles: modules/generation-guidelines.md (3924b), modules/quality-gates.md (2278b), modules/remediation-workflow.md (3430b), skill-card.md (1650b), SKILL.md (6965b), _meta.json (143b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: doc-generator\ndescription: Generates or remediates documentation with human-quality writing\nversion: 1.9.8\ntriggers:\n  - documentation\n  - writing\n  - generation\n  - remediation\n  - polish\n  - creating new docs\n  - rewriting AI-generated content\n  - or applying style profiles\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Documentation Generator\n\n**A document costs the sum of its readers' time. Earn that\ncost or cut.**\n\nGenerate documents that are grounded in specific claims, lead\nwith their thesis, and earn every sentence. Filler phrases like\n\"In today's fast-paced world\" and vague descriptors like\n\"thorough\" or \"complete\" without evidence are bloat. So is\nany sentence that does not carry, instance, bound, or repeat\nthe document's one takeaway.\n\nThis skill enforces both **sentence-level cleanliness** (no\nslop vocabulary, em dash overuse, or sycophantic openers) and\n**document-level economy** (thesis-first, every sentence\nearns weight, repetition reserved for the thesis). See\n`Skill(scribe:slop-detector)` module `document-economy.md`\nfor the full rubric.\n\n## Core Writing Principles\n\nUse active voice and an authorial perspective. Explain the\nreasoning behind technical choices (why this database, not\nthat one) rather than presenting neutral boilerplate. Use\nbullets sparingly for short, parallel summaries; convert\nmulti-line bullet waterfalls into prose so the reasoning\nsurvives.\n\n### Vocabulary and Style\n\nAvoid business jargon and linguistic tics like mirrored\nsentence structures or em dash overuse. Use the imperative\nmood for docstrings (\"Validate input\", not \"Validates\").\nDo not humanize non-living constructs (\"the code wants\",\n\"the function speaks to\").\n\n| Instead of | Use |\n|------------|-----|\n| fallback | default, secondary |\n| leverage | use |\n| utilize | use |\n| facilitate | help, enable |\n| comprehensive | thorough, complete |\n\n### 9. Limit Humanizing Constructs\n\n\"Lives under,\" \"speaks to,\" and similar phrases only make sense\nfor living things.\n\n### 10. Imperative Mood for Docstrings\n\n\"Validate\" not \"Validates\" (per PEP 257, pydocstyle, ruff).\n\n## Required TodoWrite Items\n\n1. `doc-generator:scope-defined` - Target files and type identified\n2. `doc-generator:style-loaded` - Style profile applied (if available)\n3. `doc-generator:content-drafted` - Initial content created\n4. `doc-generator:slop-scanned` - AI markers checked\n5. `doc-generator:quality-verified` - Principles checklist passed\n6. `doc-generator:user-approved` - Final approval received\n\n## Mode: Generation\n\nFor new documentation:\n\n### Step 1: Define Scope\n\n```markdown\n## Generation Request\n\n**Type**: [README/Guide/API docs/Tutorial]\n**Audience**: [developers/users/admins]\n**Audience size**: [1 / small team / org / public]\n**Read frequency**: [once / weekly / per-invocation]\n**Thesis**: [one sentence the reader must walk away with]\n**Length target**: [~X words or sections]\n**Style profile**: [profile name or \"default\"]\n```\n\nThe **Thesis** field is required. If you cannot state the\ntakeaway in one sentence, the scope is not ready. Audience\nsize and read frequency feed the reader-time budget (see\n`scribe:slop-detector` module `document-economy.md`): a\nskill loaded daily by 50 users has a wildly different\nbudget than a 1:1 design note.\n\n### Step 2: Load Style (if available)\n\nIf a style profile exists:\n```bash\ncat .scribe/style-profile.yaml\n```\n\nApply voice, vocabulary, and structural guidelines.\n\n### Step 3: Draft Content\n\n**Lead with the thesis.** The first paragraph must state the\nsingle takeaway. If a reader stops after the lead, they should\nstill leave with the message. Echo the thesis once in the body\nand once at the close; cut every other repetition.\n\nFollow the 10 core principles above. For each section:\n\n1. Start with the essential information (state the thesis or\n   a clear instance of it)\n2. Add context only if it adds value (does it carry, instance,\n   or bound the thesis?)\n3. Use specific examples (one is proof; two is emphasis;\n   three is filler)\n4. Prefer prose over bullets\n5. End when information is complete (no summary padding,\n   no \"in conclusion\" restatements)\n\n### Step 4: Run Slop Detector\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix any findings before proceeding.\n\n### Step 5: Quality Gate\n\nVerify against checklist:\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40%\n- [ ] All claims grounded with specifics\n- [ ] No formulaic openers or closers\n- [ ] Authorial perspective present\n- [ ] No emojis (unless explicitly requested)\n\nDocument-level (document-economy module):\n- [ ] Thesis stated in the lead, single and clear (2/2)\n- [ ] >80% of sentences carry, instance, bound, or repeat\n      the thesis (2/2)\n- [ ] Thesis echoed at least 3 times; non-thesis repetition\n      cut (2/2)\n- [ ] Writing time roughly proportional to (audience size ×\n      read frequency × per-read time)\n\n## Mode: Remediation\n\nFor cleaning up existing content:\n\nLoad: `@modules/remediation-workflow.md`\n\n### Step 1: Analyze Current State\n\n```bash\n# Get slop score\nSkill(scribe:slop-detector) --target file.md\n```\n\n### Step 2: Section-by-Section Approach\n\nFor large files (>200 lines), edit incrementally:\n\n```markdown\n## Section: [Name] (Lines X-Y)\n\n**Current slop score**: X.X\n**Issues found**: [list]\n\n**Proposed changes**:\n1. [Change 1]\n2. [Change 2]\n\n**Before**:\n> [current text]\n\n**After**:\n> [proposed text]\n\nProceed? [Y/n/edit]\n```\n\n### Step 3: Preserve Intent\n\nNever change WHAT is said, only HOW. If meaning is unclear, ask.\n\n### Step 4: Re-verify\n\nAfter edits, re-run slop-detector to confirm improvement.\n\n## Docstring-Specific Rules\n\nWhen editing code comments:\n\n1. **ONLY modify docstring/comment text**\n2. **Never change surrounding code**\n3. **Use imperative mood** (\"Validate input\" not \"Validates input\")\n4. **Brief is better** - remove filler\n5. **Keep Args/Returns structure** if present\n\n## Module Reference\n\n- See `modules/generation-guidelines.md` for content creation patterns\n- See `modules/quality-gates.md` for validation criteria\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| slop-detector | After drafting, before approval |\n| style-learner | Before generation to load profile |\n| sanctum:doc-updates | For broader doc maintenance |\n\n## Exit Criteria\n\n- Content created or remediated\n- Slop score < 1.5 (clean rating)\n- Quality gate checklist passed\n- User approval received\n- No emojis present (unless specified)\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-doc-generator\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787750498769\n}\n\nFile v1.9.19:modules/generation-guidelines.md\n\n---\nmodule: generation-guidelines\ncategory: writing-quality\ndependencies: []\nestimated_tokens: 400\n---\n\n# Documentation Generation Guidelines\n\nDetailed guidance for creating human-quality documentation.\n\n## Opening Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\"\n```\n\n### What to Use\n\n```markdown\nGOOD: \"scribe detects AI-generated content and helps you fix it.\"\nGOOD: \"Install with: npm install scribe\"\nGOOD: \"This guide covers installation, configuration, and common workflows.\"\n```\n\nStart with what it IS or what it DOES. Skip the preamble.\n\n## Section Structure\n\n### Length Targets\n\n| Section Type | Target Length |\n|--------------|---------------|\n| Overview | 50-100 words |\n| Feature description | 30-60 words |\n| Step in guide | 20-50 words |\n| API endpoint | 40-80 words |\n\n### Paragraph Guidance\n\nParagraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it.\n\nOne paragraph = one idea.\n\n## Line Wrapping\n\nWrap prose text at 80 characters per line using hybrid\nwrapping. This makes git diffs readable and mobile-friendly.\n\n### Rules (in priority order)\n\n1. Keep sentences on one line if they fit within 80 chars\n2. Break long sentences at clause boundaries (after `, ; :`)\n3. Break before conjunctions (`and`, `but`, `or`)\n4. Break at word boundaries as a last resort\n\n### Exempt from wrapping\n\nTables, code blocks, headings, frontmatter, HTML blocks,\nlink definitions, and image references stay on one line.\n\n### Example\n\n```markdown\nBEFORE:\nThe system validates all input against the schema and rejects\nmalformed requests with a 400 status code, logging the\nvalidation failure for debugging.\n\nAFTER:\nThe system validates all input against the schema\nand rejects malformed requests with a 400 status code,\nlogging the validation failure for debugging.\n```\n\n### Additional formatting rules\n\n- Blank line before and after every heading\n- ATX headings only (`#` style, never setext underlines)\n- Blank line before every list\n- Use reference-style links when inline links push past\n  80 chars\n\nFull specification: `Skill(leyline:markdown-formatting)`\n\n## Concrete Examples\n\nEvery feature claim needs a concrete example:\n\n```markdown\nBAD: \"The system provides flexible configuration options.\"\n\nGOOD: \"Configure via `scribe.yaml` or environment variables.\nSet `SCRIBE_STRICT=1` to treat warnings as errors.\"\n```\n\n## Trade-off Discussions\n\nInclude reasoning, not just conclusions:\n\n```markdown\nBAD: \"We recommend Redis for caching.\"\n\nGOOD: \"We chose Redis over Memcached for its sorted sets,\nwhich power the leaderboard. Memcached would use less memory\nbut require additional application logic.\"\n```\n\n## Ending Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In conclusion, we have covered the essential aspects of...\"\nBAD: \"We hope this guide has been helpful in your journey...\"\nBAD: \"Happy coding!\"\n```\n\n### What to Use\n\nEnd with the last useful piece of information. No summary paragraph unless the document exceeds 2000 words.\n\n```markdown\nGOOD: \"For issues, open a ticket at github.com/org/repo/issues.\"\nGOOD: \"Next: Advanced Configuration\"\nGOOD: [Just end. No closing needed.]\n```\n\n## Voice Consistency\n\nMaintain consistent perspective throughout:\n\n| Style | Example |\n|-------|---------|\n| Direct | \"Run `npm install`\" |\n| Team | \"We recommend...\" |\n| Instructional | \"You can configure...\" |\n\nDon't mix: \"One should note that you can...\"\n\n## Handling Uncertainty\n\nWhen information is incomplete:\n\n```markdown\nGOOD: \"Exact performance varies by hardware. Our tests showed 50-200ms on M1 Mac.\"\nGOOD: \"This feature is experimental. API may change.\"\nGOOD: \"We haven't tested on Windows. Linux and macOS confirmed working.\"\n```\n\nAcknowledge limits rather than overgeneralizing.\n\nFile v1.9.19:modules/quality-gates.md\n\n---\nmodule: quality-gates\ncategory: writing-quality\ndependencies: [TodoWrite]\nestimated_tokens: 300\n---\n\n# Documentation Quality Gates\n\nChecklists and thresholds for documentation quality validation.\n\n## Pre-Commit Checklist\n\nBefore finalizing any documentation:\n\n### Content Quality\n- [ ] No tier-1 slop words present\n- [ ] No vapid openers or closers\n- [ ] All claims grounded with specifics\n- [ ] Trade-offs explained, not just conclusions\n- [ ] Authorial perspective present (\"we chose\", \"our tests showed\")\n\n### Structure Quality\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40% (unless reference material)\n- [ ] Sentence length varies (SD > 5 words)\n- [ ] Paragraphs 2-5 sentences each\n- [ ] No five-paragraph essay structure\n\n### Style Quality\n- [ ] Consistent voice throughout\n- [ ] Appropriate formality for audience\n- [ ] Contractions used if informal tone\n- [ ] No emojis (unless explicitly requested)\n\n### Technical Quality\n- [ ] File paths verified to exist\n- [ ] Commands tested and working\n- [ ] Version numbers accurate\n- [ ] Links not broken\n\n## Metric Thresholds\n\n| Metric | Pass | Warning | Fail |\n|--------|------|---------|------|\n| Slop score | < 1.0 | 1.0-2.5 | > 2.5 |\n| Tier 1 words | 0 | 1-2 | 3+ |\n| Em dashes | < 3/1000 | 3-5/1000 | > 5/1000 |\n| Bullet ratio | < 30% | 30-50% | > 50% |\n| Sentence SD | > 8 | 5-8 | < 5 |\n\n## TodoWrite Integration\n\nTrack quality gate status:\n\n```\ndoc-generator:quality-content - PASS/FAIL\ndoc-generator:quality-structure - PASS/FAIL\ndoc-generator:quality-style - PASS/FAIL\ndoc-generator:quality-technical - PASS/FAIL\n```\n\n## Remediation Required\n\nIf any gate fails:\n\n1. Identify specific failures\n2. Propose fixes\n3. Apply fixes\n4. Re-run gates\n5. Repeat until pass\n\n## Exceptions\n\nDocument exceptions when gates are intentionally skipped:\n\n```markdown\n## Quality Gate Exception\n\n**Document**: API-reference.md\n**Gate**: bullet-ratio (58%)\n**Reason**: Reference documentation requires list format\n**Approved by**: [user]\n**Date**: [date]\n```\n\n## Integration with CI\n\nFor automated checking:\n\n```yaml\n# .github/workflows/docs-quality.yaml\n- name: Check documentation quality\n  run: |\n    scribe scan docs/\n    if [ $? -ne 0 ]; then\n      echo \"Documentation quality check failed\"\n      exit 1\n    fi\n```\n\nFile v1.9.19:modules/remediation-workflow.md\n\n---\nmodule: remediation-workflow\ncategory: writing-quality\ndependencies: [Edit, Read]\nestimated_tokens: 400\n---\n\n# Documentation Remediation Workflow\n\nStep-by-step process for cleaning up AI-generated content.\n\n## Phase 1: Assessment\n\nRun slop-detector and categorize findings:\n\n```markdown\n## Remediation Assessment: [filename]\n\n**Slop Score**: X.X\n**Word Count**: N\n\n### Critical (fix immediately)\n- [ ] Vapid opener at line 1\n- [ ] \"cannot be overstated\" at line 45\n\n### High Priority (fix in this pass)\n- [ ] 8 tier-1 slop words\n- [ ] Em dash density 7/1000\n\n### Medium Priority (fix if time)\n- [ ] Bullet ratio 55%\n- [ ] Sentence uniformity\n\n### Low Priority (defer)\n- [ ] Minor vocabulary substitutions\n```\n\n## Phase 2: User Approval for Major Changes\n\nIf remediation requires:\n- Deleting entire sections\n- Restructuring document flow\n- Changing technical content\n\nAlways ask:\n\n```markdown\n## Major Change Required\n\nThe opening section (lines 1-25) is primarily filler with no\ntechnical content. Options:\n\n1. **Delete entirely** - Start at line 26 with actual information\n2. **Condense to 2 sentences** - Keep intro but remove fluff\n3. **Rewrite** - New opening based on document purpose\n\nWhich approach? [1/2/3]\n```\n\n## Phase 3: Section-by-Section Editing\n\nFor documents over 200 lines, process in sections:\n\n```markdown\n## Section 1: Introduction (Lines 1-45)\n\n### Current State\n> In today's rapidly evolving technological landscape,\n> comprehensive documentation plays a pivotal role in\n> ensuring seamless developer experiences...\n\n### Issues\n- Vapid opener\n- \"comprehensive\", \"pivotal\", \"seamless\" (tier 1/2 words)\n- No concrete information in 45 words\n\n### Proposed Revision\n> scribe checks documentation for AI-generated patterns\n> and provides rewriting guidance. This guide covers\n> installation, configuration, and usage.\n\n### Changes\n- Removed opener cliche\n- Replaced with direct statement\n- Cut word count from 45 to 22\n\nProceed? [Y/n/edit]\n```\n\n## Phase 4: Vocabulary Sweep\n\nAfter structural fixes, sweep for remaining vocabulary:\n\n```bash\n# Quick vocabulary check\ngrep -nE '\\b(delve|embark|leverage|utilize|comprehensive)\\b' file.md\n```\n\nApply substitutions from shared module:\n\n| Line | Current | Replacement |\n|------|---------|-------------|\n| 23 | leverage | use |\n| 45 | utilize | use |\n| 67 | comprehensive | thorough |\n\n## Phase 5: Structural Polish\n\nFinal pass for structural issues:\n\n1. **Em dashes**: Replace excessive uses with commas/periods\n2. **Lists**: Convert bullet waterfalls to prose\n3. **Sentence variation**: Add short/long variety\n4. **Contractions**: Add if tone is informal\n\n## Phase 6: Verification\n\nRe-run slop-detector:\n\n```markdown\n## Remediation Results\n\n| Metric | Before | After | Change |\n|--------|--------|-------|--------|\n| Slop score | 4.8 | 1.2 | -75% |\n| Tier 1 words | 12 | 0 | -100% |\n| Em dash density | 7/1000 | 2/1000 | -71% |\n| Bullet ratio | 55% | 30% | -45% |\n\nStatus: CLEAN\n```\n\n## Docstring Mode\n\nFor code files, special handling:\n\n1. Extract docstrings only (don't modify code)\n2. Apply vocabulary substitutions\n3. Convert to imperative mood\n4. Verify with slop-detector\n5. Re-insert docstrings\n\n```python\n# ONLY these parts change:\ndef function():\n    \"\"\"\n    BEFORE: \"This function leverages advanced algorithms to\n    comprehensively process the input data.\"\n\n    AFTER: \"Process input data and return result.\"\n    \"\"\"\n    # Code remains EXACTLY as-is\n```\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nGenerates or remediates documentation with human-quality writing.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and technical writers use this skill to draft new documentation, clean up AI-generated or bloated prose, enforce thesis-first structure, and apply writing quality gates before approval.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad trigger words such as writing or polish may activate the skill for requests that are not specifically about documentation.\n\nMitigation: Confirm the task is documentation generation or documentation cleanup before applying the skill's workflow.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-scribe-doc-generator)\n- [claude-night-market scribe plugin](https://github.com/athola/claude-night-market/tree/master/plugins/scribe)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Shell commands, Guidance]\n\n**Output Format:** [Markdown and plain text with occasional shell command blocks]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include documentation drafts, remediation plans, quality checklists, and approval prompts.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 6 files, 10252 bytes\n\nFiles: modules/generation-guidelines.md (3924b), modules/quality-gates.md (2278b), modules/remediation-workflow.md (3430b), skill-card.md (2379b), SKILL.md (6965b), _meta.json (143b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: doc-generator\ndescription: Generates or remediates documentation with human-quality writing\nversion: 1.9.8\ntriggers:\n  - documentation\n  - writing\n  - generation\n  - remediation\n  - polish\n  - creating new docs\n  - rewriting AI-generated content\n  - or applying style profiles\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Documentation Generator\n\n**A document costs the sum of its readers' time. Earn that\ncost or cut.**\n\nGenerate documents that are grounded in specific claims, lead\nwith their thesis, and earn every sentence. Filler phrases like\n\"In today's fast-paced world\" and vague descriptors like\n\"thorough\" or \"complete\" without evidence are bloat. So is\nany sentence that does not carry, instance, bound, or repeat\nthe document's one takeaway.\n\nThis skill enforces both **sentence-level cleanliness** (no\nslop vocabulary, em dash overuse, or sycophantic openers) and\n**document-level economy** (thesis-first, every sentence\nearns weight, repetition reserved for the thesis). See\n`Skill(scribe:slop-detector)` module `document-economy.md`\nfor the full rubric.\n\n## Core Writing Principles\n\nUse active voice and an authorial perspective. Explain the\nreasoning behind technical choices (why this database, not\nthat one) rather than presenting neutral boilerplate. Use\nbullets sparingly for short, parallel summaries; convert\nmulti-line bullet waterfalls into prose so the reasoning\nsurvives.\n\n### Vocabulary and Style\n\nAvoid business jargon and linguistic tics like mirrored\nsentence structures or em dash overuse. Use the imperative\nmood for docstrings (\"Validate input\", not \"Validates\").\nDo not humanize non-living constructs (\"the code wants\",\n\"the function speaks to\").\n\n| Instead of | Use |\n|------------|-----|\n| fallback | default, secondary |\n| leverage | use |\n| utilize | use |\n| facilitate | help, enable |\n| comprehensive | thorough, complete |\n\n### 9. Limit Humanizing Constructs\n\n\"Lives under,\" \"speaks to,\" and similar phrases only make sense\nfor living things.\n\n### 10. Imperative Mood for Docstrings\n\n\"Validate\" not \"Validates\" (per PEP 257, pydocstyle, ruff).\n\n## Required TodoWrite Items\n\n1. `doc-generator:scope-defined` - Target files and type identified\n2. `doc-generator:style-loaded` - Style profile applied (if available)\n3. `doc-generator:content-drafted` - Initial content created\n4. `doc-generator:slop-scanned` - AI markers checked\n5. `doc-generator:quality-verified` - Principles checklist passed\n6. `doc-generator:user-approved` - Final approval received\n\n## Mode: Generation\n\nFor new documentation:\n\n### Step 1: Define Scope\n\n```markdown\n## Generation Request\n\n**Type**: [README/Guide/API docs/Tutorial]\n**Audience**: [developers/users/admins]\n**Audience size**: [1 / small team / org / public]\n**Read frequency**: [once / weekly / per-invocation]\n**Thesis**: [one sentence the reader must walk away with]\n**Length target**: [~X words or sections]\n**Style profile**: [profile name or \"default\"]\n```\n\nThe **Thesis** field is required. If you cannot state the\ntakeaway in one sentence, the scope is not ready. Audience\nsize and read frequency feed the reader-time budget (see\n`scribe:slop-detector` module `document-economy.md`): a\nskill loaded daily by 50 users has a wildly different\nbudget than a 1:1 design note.\n\n### Step 2: Load Style (if available)\n\nIf a style profile exists:\n```bash\ncat .scribe/style-profile.yaml\n```\n\nApply voice, vocabulary, and structural guidelines.\n\n### Step 3: Draft Content\n\n**Lead with the thesis.** The first paragraph must state the\nsingle takeaway. If a reader stops after the lead, they should\nstill leave with the message. Echo the thesis once in the body\nand once at the close; cut every other repetition.\n\nFollow the 10 core principles above. For each section:\n\n1. Start with the essential information (state the thesis or\n   a clear instance of it)\n2. Add context only if it adds value (does it carry, instance,\n   or bound the thesis?)\n3. Use specific examples (one is proof; two is emphasis;\n   three is filler)\n4. Prefer prose over bullets\n5. End when information is complete (no summary padding,\n   no \"in conclusion\" restatements)\n\n### Step 4: Run Slop Detector\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix any findings before proceeding.\n\n### Step 5: Quality Gate\n\nVerify against checklist:\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40%\n- [ ] All claims grounded with specifics\n- [ ] No formulaic openers or closers\n- [ ] Authorial perspective present\n- [ ] No emojis (unless explicitly requested)\n\nDocument-level (document-economy module):\n- [ ] Thesis stated in the lead, single and clear (2/2)\n- [ ] >80% of sentences carry, instance, bound, or repeat\n      the thesis (2/2)\n- [ ] Thesis echoed at least 3 times; non-thesis repetition\n      cut (2/2)\n- [ ] Writing time roughly proportional to (audience size ×\n      read frequency × per-read time)\n\n## Mode: Remediation\n\nFor cleaning up existing content:\n\nLoad: `@modules/remediation-workflow.md`\n\n### Step 1: Analyze Current State\n\n```bash\n# Get slop score\nSkill(scribe:slop-detector) --target file.md\n```\n\n### Step 2: Section-by-Section Approach\n\nFor large files (>200 lines), edit incrementally:\n\n```markdown\n## Section: [Name] (Lines X-Y)\n\n**Current slop score**: X.X\n**Issues found**: [list]\n\n**Proposed changes**:\n1. [Change 1]\n2. [Change 2]\n\n**Before**:\n> [current text]\n\n**After**:\n> [proposed text]\n\nProceed? [Y/n/edit]\n```\n\n### Step 3: Preserve Intent\n\nNever change WHAT is said, only HOW. If meaning is unclear, ask.\n\n### Step 4: Re-verify\n\nAfter edits, re-run slop-detector to confirm improvement.\n\n## Docstring-Specific Rules\n\nWhen editing code comments:\n\n1. **ONLY modify docstring/comment text**\n2. **Never change surrounding code**\n3. **Use imperative mood** (\"Validate input\" not \"Validates input\")\n4. **Brief is better** - remove filler\n5. **Keep Args/Returns structure** if present\n\n## Module Reference\n\n- See `modules/generation-guidelines.md` for content creation patterns\n- See `modules/quality-gates.md` for validation criteria\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| slop-detector | After drafting, before approval |\n| style-learner | Before generation to load profile |\n| sanctum:doc-updates | For broader doc maintenance |\n\n## Exit Criteria\n\n- Content created or remediated\n- Slop score < 1.5 (clean rating)\n- Quality gate checklist passed\n- User approval received\n- No emojis present (unless specified)\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-doc-generator\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785390096970\n}\n\nFile v1.9.17:modules/generation-guidelines.md\n\n---\nmodule: generation-guidelines\ncategory: writing-quality\ndependencies: []\nestimated_tokens: 400\n---\n\n# Documentation Generation Guidelines\n\nDetailed guidance for creating human-quality documentation.\n\n## Opening Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\"\n```\n\n### What to Use\n\n```markdown\nGOOD: \"scribe detects AI-generated content and helps you fix it.\"\nGOOD: \"Install with: npm install scribe\"\nGOOD: \"This guide covers installation, configuration, and common workflows.\"\n```\n\nStart with what it IS or what it DOES. Skip the preamble.\n\n## Section Structure\n\n### Length Targets\n\n| Section Type | Target Length |\n|--------------|---------------|\n| Overview | 50-100 words |\n| Feature description | 30-60 words |\n| Step in guide | 20-50 words |\n| API endpoint | 40-80 words |\n\n### Paragraph Guidance\n\nParagraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it.\n\nOne paragraph = one idea.\n\n## Line Wrapping\n\nWrap prose text at 80 characters per line using hybrid\nwrapping. This makes git diffs readable and mobile-friendly.\n\n### Rules (in priority order)\n\n1. Keep sentences on one line if they fit within 80 chars\n2. Break long sentences at clause boundaries (after `, ; :`)\n3. Break before conjunctions (`and`, `but`, `or`)\n4. Break at word boundaries as a last resort\n\n### Exempt from wrapping\n\nTables, code blocks, headings, frontmatter, HTML blocks,\nlink definitions, and image references stay on one line.\n\n### Example\n\n```markdown\nBEFORE:\nThe system validates all input against the schema and rejects\nmalformed requests with a 400 status code, logging the\nvalidation failure for debugging.\n\nAFTER:\nThe system validates all input against the schema\nand rejects malformed requests with a 400 status code,\nlogging the validation failure for debugging.\n```\n\n### Additional formatting rules\n\n- Blank line before and after every heading\n- ATX headings only (`#` style, never setext underlines)\n- Blank line before every list\n- Use reference-style links when inline links push past\n  80 chars\n\nFull specification: `Skill(leyline:markdown-formatting)`\n\n## Concrete Examples\n\nEvery feature claim needs a concrete example:\n\n```markdown\nBAD: \"The system provides flexible configuration options.\"\n\nGOOD: \"Configure via `scribe.yaml` or environment variables.\nSet `SCRIBE_STRICT=1` to treat warnings as errors.\"\n```\n\n## Trade-off Discussions\n\nInclude reasoning, not just conclusions:\n\n```markdown\nBAD: \"We recommend Redis for caching.\"\n\nGOOD: \"We chose Redis over Memcached for its sorted sets,\nwhich power the leaderboard. Memcached would use less memory\nbut require additional application logic.\"\n```\n\n## Ending Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In conclusion, we have covered the essential aspects of...\"\nBAD: \"We hope this guide has been helpful in your journey...\"\nBAD: \"Happy coding!\"\n```\n\n### What to Use\n\nEnd with the last useful piece of information. No summary paragraph unless the document exceeds 2000 words.\n\n```markdown\nGOOD: \"For issues, open a ticket at github.com/org/repo/issues.\"\nGOOD: \"Next: Advanced Configuration\"\nGOOD: [Just end. No closing needed.]\n```\n\n## Voice Consistency\n\nMaintain consistent perspective throughout:\n\n| Style | Example |\n|-------|---------|\n| Direct | \"Run `npm install`\" |\n| Team | \"We recommend...\" |\n| Instructional | \"You can configure...\" |\n\nDon't mix: \"One should note that you can...\"\n\n## Handling Uncertainty\n\nWhen information is incomplete:\n\n```markdown\nGOOD: \"Exact performance varies by hardware. Our tests showed 50-200ms on M1 Mac.\"\nGOOD: \"This feature is experimental. API may change.\"\nGOOD: \"We haven't tested on Windows. Linux and macOS confirmed working.\"\n```\n\nAcknowledge limits rather than overgeneralizing.\n\nFile v1.9.17:modules/quality-gates.md\n\n---\nmodule: quality-gates\ncategory: writing-quality\ndependencies: [TodoWrite]\nestimated_tokens: 300\n---\n\n# Documentation Quality Gates\n\nChecklists and thresholds for documentation quality validation.\n\n## Pre-Commit Checklist\n\nBefore finalizing any documentation:\n\n### Content Quality\n- [ ] No tier-1 slop words present\n- [ ] No vapid openers or closers\n- [ ] All claims grounded with specifics\n- [ ] Trade-offs explained, not just conclusions\n- [ ] Authorial perspective present (\"we chose\", \"our tests showed\")\n\n### Structure Quality\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40% (unless reference material)\n- [ ] Sentence length varies (SD > 5 words)\n- [ ] Paragraphs 2-5 sentences each\n- [ ] No five-paragraph essay structure\n\n### Style Quality\n- [ ] Consistent voice throughout\n- [ ] Appropriate formality for audience\n- [ ] Contractions used if informal tone\n- [ ] No emojis (unless explicitly requested)\n\n### Technical Quality\n- [ ] File paths verified to exist\n- [ ] Commands tested and working\n- [ ] Version numbers accurate\n- [ ] Links not broken\n\n## Metric Thresholds\n\n| Metric | Pass | Warning | Fail |\n|--------|------|---------|------|\n| Slop score | < 1.0 | 1.0-2.5 | > 2.5 |\n| Tier 1 words | 0 | 1-2 | 3+ |\n| Em dashes | < 3/1000 | 3-5/1000 | > 5/1000 |\n| Bullet ratio | < 30% | 30-50% | > 50% |\n| Sentence SD | > 8 | 5-8 | < 5 |\n\n## TodoWrite Integration\n\nTrack quality gate status:\n\n```\ndoc-generator:quality-content - PASS/FAIL\ndoc-generator:quality-structure - PASS/FAIL\ndoc-generator:quality-style - PASS/FAIL\ndoc-generator:quality-technical - PASS/FAIL\n```\n\n## Remediation Required\n\nIf any gate fails:\n\n1. Identify specific failures\n2. Propose fixes\n3. Apply fixes\n4. Re-run gates\n5. Repeat until pass\n\n## Exceptions\n\nDocument exceptions when gates are intentionally skipped:\n\n```markdown\n## Quality Gate Exception\n\n**Document**: API-reference.md\n**Gate**: bullet-ratio (58%)\n**Reason**: Reference documentation requires list format\n**Approved by**: [user]\n**Date**: [date]\n```\n\n## Integration with CI\n\nFor automated checking:\n\n```yaml\n# .github/workflows/docs-quality.yaml\n- name: Check documentation quality\n  run: |\n    scribe scan docs/\n    if [ $? -ne 0 ]; then\n      echo \"Documentation quality check failed\"\n      exit 1\n    fi\n```\n\nFile v1.9.17:modules/remediation-workflow.md\n\n---\nmodule: remediation-workflow\ncategory: writing-quality\ndependencies: [Edit, Read]\nestimated_tokens: 400\n---\n\n# Documentation Remediation Workflow\n\nStep-by-step process for cleaning up AI-generated content.\n\n## Phase 1: Assessment\n\nRun slop-detector and categorize findings:\n\n```markdown\n## Remediation Assessment: [filename]\n\n**Slop Score**: X.X\n**Word Count**: N\n\n### Critical (fix immediately)\n- [ ] Vapid opener at line 1\n- [ ] \"cannot be overstated\" at line 45\n\n### High Priority (fix in this pass)\n- [ ] 8 tier-1 slop words\n- [ ] Em dash density 7/1000\n\n### Medium Priority (fix if time)\n- [ ] Bullet ratio 55%\n- [ ] Sentence uniformity\n\n### Low Priority (defer)\n- [ ] Minor vocabulary substitutions\n```\n\n## Phase 2: User Approval for Major Changes\n\nIf remediation requires:\n- Deleting entire sections\n- Restructuring document flow\n- Changing technical content\n\nAlways ask:\n\n```markdown\n## Major Change Required\n\nThe opening section (lines 1-25) is primarily filler with no\ntechnical content. Options:\n\n1. **Delete entirely** - Start at line 26 with actual information\n2. **Condense to 2 sentences** - Keep intro but remove fluff\n3. **Rewrite** - New opening based on document purpose\n\nWhich approach? [1/2/3]\n```\n\n## Phase 3: Section-by-Section Editing\n\nFor documents over 200 lines, process in sections:\n\n```markdown\n## Section 1: Introduction (Lines 1-45)\n\n### Current State\n> In today's rapidly evolving technological landscape,\n> comprehensive documentation plays a pivotal role in\n> ensuring seamless developer experiences...\n\n### Issues\n- Vapid opener\n- \"comprehensive\", \"pivotal\", \"seamless\" (tier 1/2 words)\n- No concrete information in 45 words\n\n### Proposed Revision\n> scribe checks documentation for AI-generated patterns\n> and provides rewriting guidance. This guide covers\n> installation, configuration, and usage.\n\n### Changes\n- Removed opener cliche\n- Replaced with direct statement\n- Cut word count from 45 to 22\n\nProceed? [Y/n/edit]\n```\n\n## Phase 4: Vocabulary Sweep\n\nAfter structural fixes, sweep for remaining vocabulary:\n\n```bash\n# Quick vocabulary check\ngrep -nE '\\b(delve|embark|leverage|utilize|comprehensive)\\b' file.md\n```\n\nApply substitutions from shared module:\n\n| Line | Current | Replacement |\n|------|---------|-------------|\n| 23 | leverage | use |\n| 45 | utilize | use |\n| 67 | comprehensive | thorough |\n\n## Phase 5: Structural Polish\n\nFinal pass for structural issues:\n\n1. **Em dashes**: Replace excessive uses with commas/periods\n2. **Lists**: Convert bullet waterfalls to prose\n3. **Sentence variation**: Add short/long variety\n4. **Contractions**: Add if tone is informal\n\n## Phase 6: Verification\n\nRe-run slop-detector:\n\n```markdown\n## Remediation Results\n\n| Metric | Before | After | Change |\n|--------|--------|-------|--------|\n| Slop score | 4.8 | 1.2 | -75% |\n| Tier 1 words | 12 | 0 | -100% |\n| Em dash density | 7/1000 | 2/1000 | -71% |\n| Bullet ratio | 55% | 30% | -45% |\n\nStatus: CLEAN\n```\n\n## Docstring Mode\n\nFor code files, special handling:\n\n1. Extract docstrings only (don't modify code)\n2. Apply vocabulary substitutions\n3. Convert to imperative mood\n4. Verify with slop-detector\n5. Re-insert docstrings\n\n```python\n# ONLY these parts change:\ndef function():\n    \"\"\"\n    BEFORE: \"This function leverages advanced algorithms to\n    comprehensively process the input data.\"\n\n    AFTER: \"Process input data and return result.\"\n    \"\"\"\n    # Code remains EXACTLY as-is\n```\n\nFile v1.9.17:skill-card.md\n\n## Description: <br>\nGenerates or remediates documentation with human-quality writing. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers, technical writers, and documentation maintainers use this skill to draft new documentation or remediate existing content with thesis-first structure, concrete claims, style constraints, and quality checks. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad writing-related triggers may cause the skill to activate for requests where a documentation workflow was not intended. <br>\nMitigation: Review when the skill is invoked and confirm that documentation generation or remediation is the intended task before allowing edits. <br>\nRisk: Documentation remediation can change meaning when the original intent is unclear or when a rewrite restructures large sections. <br>\nMitigation: Preserve the stated meaning, ask for clarification when meaning is unclear, and require user approval before deleting sections, restructuring flow, or changing technical content. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-scribe-doc-generator) <br>\n- [OpenClaw homepage metadata](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Generation Guidelines](artifact/modules/generation-guidelines.md) <br>\n- [Quality Gates](artifact/modules/quality-gates.md) <br>\n- [Remediation Workflow](artifact/modules/remediation-workflow.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance] <br>\n**Output Format:** [Markdown, prose edits, checklists, and command snippets] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May propose or apply documentation rewrites; major changes require user confirmation under the artifact workflow.] <br>\n\n## Skill Version(s): <br>\n1.9.17 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.16: 6 files, 10372 bytes\n\nFiles: modules/generation-guidelines.md (3924b), modules/quality-gates.md (2278b), modules/remediation-workflow.md (3430b), skill-card.md (2788b), SKILL.md (6965b), _meta.json (143b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: doc-generator\ndescription: Generates or remediates documentation with human-quality writing\nversion: 1.9.8\ntriggers:\n  - documentation\n  - writing\n  - generation\n  - remediation\n  - polish\n  - creating new docs\n  - rewriting AI-generated content\n  - or applying style profiles\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Documentation Generator\n\n**A document costs the sum of its readers' time. Earn that\ncost or cut.**\n\nGenerate documents that are grounded in specific claims, lead\nwith their thesis, and earn every sentence. Filler phrases like\n\"In today's fast-paced world\" and vague descriptors like\n\"thorough\" or \"complete\" without evidence are bloat. So is\nany sentence that does not carry, instance, bound, or repeat\nthe document's one takeaway.\n\nThis skill enforces both **sentence-level cleanliness** (no\nslop vocabulary, em dash overuse, or sycophantic openers) and\n**document-level economy** (thesis-first, every sentence\nearns weight, repetition reserved for the thesis). See\n`Skill(scribe:slop-detector)` module `document-economy.md`\nfor the full rubric.\n\n## Core Writing Principles\n\nUse active voice and an authorial perspective. Explain the\nreasoning behind technical choices (why this database, not\nthat one) rather than presenting neutral boilerplate. Use\nbullets sparingly for short, parallel summaries; convert\nmulti-line bullet waterfalls into prose so the reasoning\nsurvives.\n\n### Vocabulary and Style\n\nAvoid business jargon and linguistic tics like mirrored\nsentence structures or em dash overuse. Use the imperative\nmood for docstrings (\"Validate input\", not \"Validates\").\nDo not humanize non-living constructs (\"the code wants\",\n\"the function speaks to\").\n\n| Instead of | Use |\n|------------|-----|\n| fallback | default, secondary |\n| leverage | use |\n| utilize | use |\n| facilitate | help, enable |\n| comprehensive | thorough, complete |\n\n### 9. Limit Humanizing Constructs\n\n\"Lives under,\" \"speaks to,\" and similar phrases only make sense\nfor living things.\n\n### 10. Imperative Mood for Docstrings\n\n\"Validate\" not \"Validates\" (per PEP 257, pydocstyle, ruff).\n\n## Required TodoWrite Items\n\n1. `doc-generator:scope-defined` - Target files and type identified\n2. `doc-generator:style-loaded` - Style profile applied (if available)\n3. `doc-generator:content-drafted` - Initial content created\n4. `doc-generator:slop-scanned` - AI markers checked\n5. `doc-generator:quality-verified` - Principles checklist passed\n6. `doc-generator:user-approved` - Final approval received\n\n## Mode: Generation\n\nFor new documentation:\n\n### Step 1: Define Scope\n\n```markdown\n## Generation Request\n\n**Type**: [README/Guide/API docs/Tutorial]\n**Audience**: [developers/users/admins]\n**Audience size**: [1 / small team / org / public]\n**Read frequency**: [once / weekly / per-invocation]\n**Thesis**: [one sentence the reader must walk away with]\n**Length target**: [~X words or sections]\n**Style profile**: [profile name or \"default\"]\n```\n\nThe **Thesis** field is required. If you cannot state the\ntakeaway in one sentence, the scope is not ready. Audience\nsize and read frequency feed the reader-time budget (see\n`scribe:slop-detector` module `document-economy.md`): a\nskill loaded daily by 50 users has a wildly different\nbudget than a 1:1 design note.\n\n### Step 2: Load Style (if available)\n\nIf a style profile exists:\n```bash\ncat .scribe/style-profile.yaml\n```\n\nApply voice, vocabulary, and structural guidelines.\n\n### Step 3: Draft Content\n\n**Lead with the thesis.** The first paragraph must state the\nsingle takeaway. If a reader stops after the lead, they should\nstill leave with the message. Echo the thesis once in the body\nand once at the close; cut every other repetition.\n\nFollow the 10 core principles above. For each section:\n\n1. Start with the essential information (state the thesis or\n   a clear instance of it)\n2. Add context only if it adds value (does it carry, instance,\n   or bound the thesis?)\n3. Use specific examples (one is proof; two is emphasis;\n   three is filler)\n4. Prefer prose over bullets\n5. End when information is complete (no summary padding,\n   no \"in conclusion\" restatements)\n\n### Step 4: Run Slop Detector\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix any findings before proceeding.\n\n### Step 5: Quality Gate\n\nVerify against checklist:\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40%\n- [ ] All claims grounded with specifics\n- [ ] No formulaic openers or closers\n- [ ] Authorial perspective present\n- [ ] No emojis (unless explicitly requested)\n\nDocument-level (document-economy module):\n- [ ] Thesis stated in the lead, single and clear (2/2)\n- [ ] >80% of sentences carry, instance, bound, or repeat\n      the thesis (2/2)\n- [ ] Thesis echoed at least 3 times; non-thesis repetition\n      cut (2/2)\n- [ ] Writing time roughly proportional to (audience size ×\n      read frequency × per-read time)\n\n## Mode: Remediation\n\nFor cleaning up existing content:\n\nLoad: `@modules/remediation-workflow.md`\n\n### Step 1: Analyze Current State\n\n```bash\n# Get slop score\nSkill(scribe:slop-detector) --target file.md\n```\n\n### Step 2: Section-by-Section Approach\n\nFor large files (>200 lines), edit incrementally:\n\n```markdown\n## Section: [Name] (Lines X-Y)\n\n**Current slop score**: X.X\n**Issues found**: [list]\n\n**Proposed changes**:\n1. [Change 1]\n2. [Change 2]\n\n**Before**:\n> [current text]\n\n**After**:\n> [proposed text]\n\nProceed? [Y/n/edit]\n```\n\n### Step 3: Preserve Intent\n\nNever change WHAT is said, only HOW. If meaning is unclear, ask.\n\n### Step 4: Re-verify\n\nAfter edits, re-run slop-detector to confirm improvement.\n\n## Docstring-Specific Rules\n\nWhen editing code comments:\n\n1. **ONLY modify docstring/comment text**\n2. **Never change surrounding code**\n3. **Use imperative mood** (\"Validate input\" not \"Validates input\")\n4. **Brief is better** - remove filler\n5. **Keep Args/Returns structure** if present\n\n## Module Reference\n\n- See `modules/generation-guidelines.md` for content creation patterns\n- See `modules/quality-gates.md` for validation criteria\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| slop-detector | After drafting, before approval |\n| style-learner | Before generation to load profile |\n| sanctum:doc-updates | For broader doc maintenance |\n\n## Exit Criteria\n\n- Content created or remediated\n- Slop score < 1.5 (clean rating)\n- Quality gate checklist passed\n- User approval received\n- No emojis present (unless specified)\n\nFile v1.9.16:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-doc-generator\",\n  \"version\": \"1.9.16\",\n  \"publishedAt\": 1784059102982\n}\n\nFile v1.9.16:modules/generation-guidelines.md\n\n---\nmodule: generation-guidelines\ncategory: writing-quality\ndependencies: []\nestimated_tokens: 400\n---\n\n# Documentation Generation Guidelines\n\nDetailed guidance for creating human-quality documentation.\n\n## Opening Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\"\n```\n\n### What to Use\n\n```markdown\nGOOD: \"scribe detects AI-generated content and helps you fix it.\"\nGOOD: \"Install with: npm install scribe\"\nGOOD: \"This guide covers installation, configuration, and common workflows.\"\n```\n\nStart with what it IS or what it DOES. Skip the preamble.\n\n## Section Structure\n\n### Length Targets\n\n| Section Type | Target Length |\n|--------------|---------------|\n| Overview | 50-100 words |\n| Feature description | 30-60 words |\n| Step in guide | 20-50 words |\n| API endpoint | 40-80 words |\n\n### Paragraph Guidance\n\nParagraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it.\n\nOne paragraph = one idea.\n\n## Line Wrapping\n\nWrap prose text at 80 characters per line using hybrid\nwrapping. This makes git diffs readable and mobile-friendly.\n\n### Rules (in priority order)\n\n1. Keep sentences on one line if they fit within 80 chars\n2. Break long sentences at clause boundaries (after `, ; :`)\n3. Break before conjunctions (`and`, `but`, `or`)\n4. Break at word boundaries as a last resort\n\n### Exempt from wrapping\n\nTables, code blocks, headings, frontmatter, HTML blocks,\nlink definitions, and image references stay on one line.\n\n### Example\n\n```markdown\nBEFORE:\nThe system validates all input against the schema and rejects\nmalformed requests with a 400 status code, logging the\nvalidation failure for debugging.\n\nAFTER:\nThe system validates all input against the schema\nand rejects malformed requests with a 400 status code,\nlogging the validation failure for debugging.\n```\n\n### Additional formatting rules\n\n- Blank line before and after every heading\n- ATX headings only (`#` style, never setext underlines)\n- Blank line before every list\n- Use reference-style links when inline links push past\n  80 chars\n\nFull specification: `Skill(leyline:markdown-formatting)`\n\n## Concrete Examples\n\nEvery feature claim needs a concrete example:\n\n```markdown\nBAD: \"The system provides flexible configuration options.\"\n\nGOOD: \"Configure via `scribe.yaml` or environment variables.\nSet `SCRIBE_STRICT=1` to treat warnings as errors.\"\n```\n\n## Trade-off Discussions\n\nInclude reasoning, not just conclusions:\n\n```markdown\nBAD: \"We recommend Redis for caching.\"\n\nGOOD: \"We chose Redis over Memcached for its sorted sets,\nwhich power the leaderboard. Memcached would use less memory\nbut require additional application logic.\"\n```\n\n## Ending Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In conclusion, we have covered the essential aspects of...\"\nBAD: \"We hope this guide has been helpful in your journey...\"\nBAD: \"Happy coding!\"\n```\n\n### What to Use\n\nEnd with the last useful piece of information. No summary paragraph unless the document exceeds 2000 words.\n\n```markdown\nGOOD: \"For issues, open a ticket at github.com/org/repo/issues.\"\nGOOD: \"Next: Advanced Configuration\"\nGOOD: [Just end. No closing needed.]\n```\n\n## Voice Consistency\n\nMaintain consistent perspective throughout:\n\n| Style | Example |\n|-------|---------|\n| Direct | \"Run `npm install`\" |\n| Team | \"We recommend...\" |\n| Instructional | \"You can configure...\" |\n\nDon't mix: \"One should note that you can...\"\n\n## Handling Uncertainty\n\nWhen information is incomplete:\n\n```markdown\nGOOD: \"Exact performance varies by hardware. Our tests showed 50-200ms on M1 Mac.\"\nGOOD: \"This feature is experimental. API may change.\"\nGOOD: \"We haven't tested on Windows. Linux and macOS confirmed working.\"\n```\n\nAcknowledge limits rather than overgeneralizing.\n\nFile v1.9.16:modules/quality-gates.md\n\n---\nmodule: quality-gates\ncategory: writing-quality\ndependencies: [TodoWrite]\nestimated_tokens: 300\n---\n\n# Documentation Quality Gates\n\nChecklists and thresholds for documentation quality validation.\n\n## Pre-Commit Checklist\n\nBefore finalizing any documentation:\n\n### Content Quality\n- [ ] No tier-1 slop words present\n- [ ] No vapid openers or closers\n- [ ] All claims grounded with specifics\n- [ ] Trade-offs explained, not just conclusions\n- [ ] Authorial perspective present (\"we chose\", \"our tests showed\")\n\n### Structure Quality\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40% (unless reference material)\n- [ ] Sentence length varies (SD > 5 words)\n- [ ] Paragraphs 2-5 sentences each\n- [ ] No five-paragraph essay structure\n\n### Style Quality\n- [ ] Consistent voice throughout\n- [ ] Appropriate formality for audience\n- [ ] Contractions used if informal tone\n- [ ] No emojis (unless explicitly requested)\n\n### Technical Quality\n- [ ] File paths verified to exist\n- [ ] Commands tested and working\n- [ ] Version numbers accurate\n- [ ] Links not broken\n\n## Metric Thresholds\n\n| Metric | Pass | Warning | Fail |\n|--------|------|---------|------|\n| Slop score | < 1.0 | 1.0-2.5 | > 2.5 |\n| Tier 1 words | 0 | 1-2 | 3+ |\n| Em dashes | < 3/1000 | 3-5/1000 | > 5/1000 |\n| Bullet ratio | < 30% | 30-50% | > 50% |\n| Sentence SD | > 8 | 5-8 | < 5 |\n\n## TodoWrite Integration\n\nTrack quality gate status:\n\n```\ndoc-generator:quality-content - PASS/FAIL\ndoc-generator:quality-structure - PASS/FAIL\ndoc-generator:quality-style - PASS/FAIL\ndoc-generator:quality-technical - PASS/FAIL\n```\n\n## Remediation Required\n\nIf any gate fails:\n\n1. Identify specific failures\n2. Propose fixes\n3. Apply fixes\n4. Re-run gates\n5. Repeat until pass\n\n## Exceptions\n\nDocument exceptions when gates are intentionally skipped:\n\n```markdown\n## Quality Gate Exception\n\n**Document**: API-reference.md\n**Gate**: bullet-ratio (58%)\n**Reason**: Reference documentation requires list format\n**Approved by**: [user]\n**Date**: [date]\n```\n\n## Integration with CI\n\nFor automated checking:\n\n```yaml\n# .github/workflows/docs-quality.yaml\n- name: Check documentation quality\n  run: |\n    scribe scan docs/\n    if [ $? -ne 0 ]; then\n      echo \"Documentation quality check failed\"\n      exit 1\n    fi\n```\n\nFile v1.9.16:modules/remediation-workflow.md\n\n---\nmodule: remediation-workflow\ncategory: writing-quality\ndependencies: [Edit, Read]\nestimated_tokens: 400\n---\n\n# Documentation Remediation Workflow\n\nStep-by-step process for cleaning up AI-generated content.\n\n## Phase 1: Assessment\n\nRun slop-detector and categorize findings:\n\n```markdown\n## Remediation Assessment: [filename]\n\n**Slop Score**: X.X\n**Word Count**: N\n\n### Critical (fix immediately)\n- [ ] Vapid opener at line 1\n- [ ] \"cannot be overstated\" at line 45\n\n### High Priority (fix in this pass)\n- [ ] 8 tier-1 slop words\n- [ ] Em dash density 7/1000\n\n### Medium Priority (fix if time)\n- [ ] Bullet ratio 55%\n- [ ] Sentence uniformity\n\n### Low Priority (defer)\n- [ ] Minor vocabulary substitutions\n```\n\n## Phase 2: User Approval for Major Changes\n\nIf remediation requires:\n- Deleting entire sections\n- Restructuring document flow\n- Changing technical content\n\nAlways ask:\n\n```markdown\n## Major Change Required\n\nThe opening section (lines 1-25) is primarily filler with no\ntechnical content. Options:\n\n1. **Delete entirely** - Start at line 26 with actual information\n2. **Condense to 2 sentences** - Keep intro but remove fluff\n3. **Rewrite** - New opening based on document purpose\n\nWhich approach? [1/2/3]\n```\n\n## Phase 3: Section-by-Section Editing\n\nFor documents over 200 lines, process in sections:\n\n```markdown\n## Section 1: Introduction (Lines 1-45)\n\n### Current State\n> In today's rapidly evolving technological landscape,\n> comprehensive documentation plays a pivotal role in\n> ensuring seamless developer experiences...\n\n### Issues\n- Vapid opener\n- \"comprehensive\", \"pivotal\", \"seamless\" (tier 1/2 words)\n- No concrete information in 45 words\n\n### Proposed Revision\n> scribe checks documentation for AI-generated patterns\n> and provides rewriting guidance. This guide covers\n> installation, configuration, and usage.\n\n### Changes\n- Removed opener cliche\n- Replaced with direct statement\n- Cut word count from 45 to 22\n\nProceed? [Y/n/edit]\n```\n\n## Phase 4: Vocabulary Sweep\n\nAfter structural fixes, sweep for remaining vocabulary:\n\n```bash\n# Quick vocabulary check\ngrep -nE '\\b(delve|embark|leverage|utilize|comprehensive)\\b' file.md\n```\n\nApply substitutions from shared module:\n\n| Line | Current | Replacement |\n|------|---------|-------------|\n| 23 | leverage | use |\n| 45 | utilize | use |\n| 67 | comprehensive | thorough |\n\n## Phase 5: Structural Polish\n\nFinal pass for structural issues:\n\n1. **Em dashes**: Replace excessive uses with commas/periods\n2. **Lists**: Convert bullet waterfalls to prose\n3. **Sentence variation**: Add short/long variety\n4. **Contractions**: Add if tone is informal\n\n## Phase 6: Verification\n\nRe-run slop-detector:\n\n```markdown\n## Remediation Results\n\n| Metric | Before | After | Change |\n|--------|--------|-------|--------|\n| Slop score | 4.8 | 1.2 | -75% |\n| Tier 1 words | 12 | 0 | -100% |\n| Em dash density | 7/1000 | 2/1000 | -71% |\n| Bullet ratio | 55% | 30% | -45% |\n\nStatus: CLEAN\n```\n\n## Docstring Mode\n\nFor code files, special handling:\n\n1. Extract docstrings only (don't modify code)\n2. Apply vocabulary substitutions\n3. Convert to imperative mood\n4. Verify with slop-detector\n5. Re-insert docstrings\n\n```python\n# ONLY these parts change:\ndef function():\n    \"\"\"\n    BEFORE: \"This function leverages advanced algorithms to\n    comprehensively process the input data.\"\n\n    AFTER: \"Process input data and return result.\"\n    \"\"\"\n    # Code remains EXACTLY as-is\n```\n\nFile v1.9.16:skill-card.md\n\n## Description: <br>\nGenerates or remediates documentation with human-quality writing. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers, technical writers, and documentation maintainers use this skill to draft new documentation or remediate existing documentation and comments so they lead with a clear thesis, avoid AI-writing markers, and preserve the intended meaning. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate on broad writing or polish requests. <br>\nMitigation: Confirm the target files, document type, audience, thesis, and requested mode before drafting or remediation. <br>\nRisk: The skill can read a local .scribe style profile. <br>\nMitigation: Treat the style profile as local project context and avoid exposing sensitive profile content in generated documentation. <br>\nRisk: The skill can edit documentation or comment text during remediation. <br>\nMitigation: Review diffs before accepting changes, preserve technical meaning, and limit code-file changes to docstrings or comments. <br>\nRisk: Generated or remediated documentation may introduce inaccurate or misleading guidance. <br>\nMitigation: Run the documented slop detector and quality gates, verify commands, paths, versions, and links, and require user approval before finalization. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-scribe-doc-generator) <br>\n- [Claude Night Market scribe plugin homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Generation guidelines module](artifact/modules/generation-guidelines.md) <br>\n- [Quality gates module](artifact/modules/quality-gates.md) <br>\n- [Remediation workflow module](artifact/modules/remediation-workflow.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance] <br>\n**Output Format:** [Markdown prose, checklists, inline shell commands, and documentation or comment edits.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Can apply a local .scribe style profile when available and can propose or perform documentation and comment remediation when requested.] <br>\n\n## Skill Version(s): <br>\n1.9.16 (source: server release evidence; artifact frontmatter reports 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.14: 6 files, 10257 bytes\n\nFiles: modules/generation-guidelines.md (3924b), modules/quality-gates.md (2278b), modules/remediation-workflow.md (3430b), skill-card.md (2376b), SKILL.md (6965b), _meta.json (143b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: doc-generator\ndescription: Generates or remediates documentation with human-quality writing\nversion: 1.9.8\ntriggers:\n  - documentation\n  - writing\n  - generation\n  - remediation\n  - polish\n  - creating new docs\n  - rewriting AI-generated content\n  - or applying style profiles\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Documentation Generator\n\n**A document costs the sum of its readers' time. Earn that\ncost or cut.**\n\nGenerate documents that are grounded in specific claims, lead\nwith their thesis, and earn every sentence. Filler phrases like\n\"In today's fast-paced world\" and vague descriptors like\n\"thorough\" or \"complete\" without evidence are bloat. So is\nany sentence that does not carry, instance, bound, or repeat\nthe document's one takeaway.\n\nThis skill enforces both **sentence-level cleanliness** (no\nslop vocabulary, em dash overuse, or sycophantic openers) and\n**document-level economy** (thesis-first, every sentence\nearns weight, repetition reserved for the thesis). See\n`Skill(scribe:slop-detector)` module `document-economy.md`\nfor the full rubric.\n\n## Core Writing Principles\n\nUse active voice and an authorial perspective. Explain the\nreasoning behind technical choices (why this database, not\nthat one) rather than presenting neutral boilerplate. Use\nbullets sparingly for short, parallel summaries; convert\nmulti-line bullet waterfalls into prose so the reasoning\nsurvives.\n\n### Vocabulary and Style\n\nAvoid business jargon and linguistic tics like mirrored\nsentence structures or em dash overuse. Use the imperative\nmood for docstrings (\"Validate input\", not \"Validates\").\nDo not humanize non-living constructs (\"the code wants\",\n\"the function speaks to\").\n\n| Instead of | Use |\n|------------|-----|\n| fallback | default, secondary |\n| leverage | use |\n| utilize | use |\n| facilitate | help, enable |\n| comprehensive | thorough, complete |\n\n### 9. Limit Humanizing Constructs\n\n\"Lives under,\" \"speaks to,\" and similar phrases only make sense\nfor living things.\n\n### 10. Imperative Mood for Docstrings\n\n\"Validate\" not \"Validates\" (per PEP 257, pydocstyle, ruff).\n\n## Required TodoWrite Items\n\n1. `doc-generator:scope-defined` - Target files and type identified\n2. `doc-generator:style-loaded` - Style profile applied (if available)\n3. `doc-generator:content-drafted` - Initial content created\n4. `doc-generator:slop-scanned` - AI markers checked\n5. `doc-generator:quality-verified` - Principles checklist passed\n6. `doc-generator:user-approved` - Final approval received\n\n## Mode: Generation\n\nFor new documentation:\n\n### Step 1: Define Scope\n\n```markdown\n## Generation Request\n\n**Type**: [README/Guide/API docs/Tutorial]\n**Audience**: [developers/users/admins]\n**Audience size**: [1 / small team / org / public]\n**Read frequency**: [once / weekly / per-invocation]\n**Thesis**: [one sentence the reader must walk away with]\n**Length target**: [~X words or sections]\n**Style profile**: [profile name or \"default\"]\n```\n\nThe **Thesis** field is required. If you cannot state the\ntakeaway in one sentence, the scope is not ready. Audience\nsize and read frequency feed the reader-time budget (see\n`scribe:slop-detector` module `document-economy.md`): a\nskill loaded daily by 50 users has a wildly different\nbudget than a 1:1 design note.\n\n### Step 2: Load Style (if available)\n\nIf a style profile exists:\n```bash\ncat .scribe/style-profile.yaml\n```\n\nApply voice, vocabulary, and structural guidelines.\n\n### Step 3: Draft Content\n\n**Lead with the thesis.** The first paragraph must state the\nsingle takeaway. If a reader stops after the lead, they should\nstill leave with the message. Echo the thesis once in the body\nand once at the close; cut every other repetition.\n\nFollow the 10 core principles above. For each section:\n\n1. Start with the essential information (state the thesis or\n   a clear instance of it)\n2. Add context only if it adds value (does it carry, instance,\n   or bound the thesis?)\n3. Use specific examples (one is proof; two is emphasis;\n   three is filler)\n4. Prefer prose over bullets\n5. End when information is complete (no summary padding,\n   no \"in conclusion\" restatements)\n\n### Step 4: Run Slop Detector\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix any findings before proceeding.\n\n### Step 5: Quality Gate\n\nVerify against checklist:\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40%\n- [ ] All claims grounded with specifics\n- [ ] No formulaic openers or closers\n- [ ] Authorial perspective present\n- [ ] No emojis (unless explicitly requested)\n\nDocument-level (document-economy module):\n- [ ] Thesis stated in the lead, single and clear (2/2)\n- [ ] >80% of sentences carry, instance, bound, or repeat\n      the thesis (2/2)\n- [ ] Thesis echoed at least 3 times; non-thesis repetition\n      cut (2/2)\n- [ ] Writing time roughly proportional to (audience size ×\n      read frequency × per-read time)\n\n## Mode: Remediation\n\nFor cleaning up existing content:\n\nLoad: `@modules/remediation-workflow.md`\n\n### Step 1: Analyze Current State\n\n```bash\n# Get slop score\nSkill(scribe:slop-detector) --target file.md\n```\n\n### Step 2: Section-by-Section Approach\n\nFor large files (>200 lines), edit incrementally:\n\n```markdown\n## Section: [Name] (Lines X-Y)\n\n**Current slop score**: X.X\n**Issues found**: [list]\n\n**Proposed changes**:\n1. [Change 1]\n2. [Change 2]\n\n**Before**:\n> [current text]\n\n**After**:\n> [proposed text]\n\nProceed? [Y/n/edit]\n```\n\n### Step 3: Preserve Intent\n\nNever change WHAT is said, only HOW. If meaning is unclear, ask.\n\n### Step 4: Re-verify\n\nAfter edits, re-run slop-detector to confirm improvement.\n\n## Docstring-Specific Rules\n\nWhen editing code comments:\n\n1. **ONLY modify docstring/comment text**\n2. **Never change surrounding code**\n3. **Use imperative mood** (\"Validate input\" not \"Validates input\")\n4. **Brief is better** - remove filler\n5. **Keep Args/Returns structure** if present\n\n## Module Reference\n\n- See `modules/generation-guidelines.md` for content creation patterns\n- See `modules/quality-gates.md` for validation criteria\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| slop-detector | After drafting, before approval |\n| style-learner | Before generation to load profile |\n| sanctum:doc-updates | For broader doc maintenance |\n\n## Exit Criteria\n\n- Content created or remediated\n- Slop score < 1.5 (clean rating)\n- Quality gate checklist passed\n- User approval received\n- No emojis present (unless specified)\n\nFile v1.9.14:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-doc-generator\",\n  \"version\": \"1.9.14\",\n  \"publishedAt\": 1782842770480\n}\n\nFile v1.9.14:modules/generation-guidelines.md\n\n---\nmodule: generation-guidelines\ncategory: writing-quality\ndependencies: []\nestimated_tokens: 400\n---\n\n# Documentation Generation Guidelines\n\nDetailed guidance for creating human-quality documentation.\n\n## Opening Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\"\n```\n\n### What to Use\n\n```markdown\nGOOD: \"scribe detects AI-generated content and helps you fix it.\"\nGOOD: \"Install with: npm install scribe\"\nGOOD: \"This guide covers installation, configuration, and common workflows.\"\n```\n\nStart with what it IS or what it DOES. Skip the preamble.\n\n## Section Structure\n\n### Length Targets\n\n| Section Type | Target Length |\n|--------------|---------------|\n| Overview | 50-100 words |\n| Feature description | 30-60 words |\n| Step in guide | 20-50 words |\n| API endpoint | 40-80 words |\n\n### Paragraph Guidance\n\nParagraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it.\n\nOne paragraph = one idea.\n\n## Line Wrapping\n\nWrap prose text at 80 characters per line using hybrid\nwrapping. This makes git diffs readable and mobile-friendly.\n\n### Rules (in priority order)\n\n1. Keep sentences on one line if they fit within 80 chars\n2. Break long sentences at clause boundaries (after `, ; :`)\n3. Break before conjunctions (`and`, `but`, `or`)\n4. Break at word boundaries as a last resort\n\n### Exempt from wrapping\n\nTables, code blocks, headings, frontmatter, HTML blocks,\nlink definitions, and image references stay on one line.\n\n### Example\n\n```markdown\nBEFORE:\nThe system validates all input against the schema and rejects\nmalformed requests with a 400 status code, logging the\nvalidation failure for debugging.\n\nAFTER:\nThe system validates all input against the schema\nand rejects malformed requests with a 400 status code,\nlogging the validation failure for debugging.\n```\n\n### Additional formatting rules\n\n- Blank line before and after every heading\n- ATX headings only (`#` style, never setext underlines)\n- Blank line before every list\n- Use reference-style links when inline links push past\n  80 chars\n\nFull specification: `Skill(leyline:markdown-formatting)`\n\n## Concrete Examples\n\nEvery feature claim needs a concrete example:\n\n```markdown\nBAD: \"The system provides flexible configuration options.\"\n\nGOOD: \"Configure via `scribe.yaml` or environment variables.\nSet `SCRIBE_STRICT=1` to treat warnings as errors.\"\n```\n\n## Trade-off Discussions\n\nInclude reasoning, not just conclusions:\n\n```markdown\nBAD: \"We recommend Redis for caching.\"\n\nGOOD: \"We chose Redis over Memcached for its sorted sets,\nwhich power the leaderboard. Memcached would use less memory\nbut require additional application logic.\"\n```\n\n## Ending Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In conclusion, we have covered the essential aspects of...\"\nBAD: \"We hope this guide has been helpful in your journey...\"\nBAD: \"Happy coding!\"\n```\n\n### What to Use\n\nEnd with the last useful piece of information. No summary paragraph unless the document exceeds 2000 words.\n\n```markdown\nGOOD: \"For issues, open a ticket at github.com/org/repo/issues.\"\nGOOD: \"Next: Advanced Configuration\"\nGOOD: [Just end. No closing needed.]\n```\n\n## Voice Consistency\n\nMaintain consistent perspective throughout:\n\n| Style | Example |\n|-------|---------|\n| Direct | \"Run `npm install`\" |\n| Team | \"We recommend...\" |\n| Instructional | \"You can configure...\" |\n\nDon't mix: \"One should note that you can...\"\n\n## Handling Uncertainty\n\nWhen information is incomplete:\n\n```markdown\nGOOD: \"Exact performance varies by hardware. Our tests showed 50-200ms on M1 Mac.\"\nGOOD: \"This feature is experimental. API may change.\"\nGOOD: \"We haven't tested on Windows. Linux and macOS confirmed working.\"\n```\n\nAcknowledge limits rather than overgeneralizing.\n\nFile v1.9.14:modules/quality-gates.md\n\n---\nmodule: quality-gates\ncategory: writing-quality\ndependencies: [TodoWrite]\nestimated_tokens: 300\n---\n\n# Documentation Quality Gates\n\nChecklists and thresholds for documentation quality validation.\n\n## Pre-Commit Checklist\n\nBefore finalizing any documentation:\n\n### Content Quality\n- [ ] No tier-1 slop words present\n- [ ] No vapid openers or closers\n- [ ] All claims grounded with specifics\n- [ ] Trade-offs explained, not just conclusions\n- [ ] Authorial perspective present (\"we chose\", \"our tests showed\")\n\n### Structure Quality\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40% (unless reference material)\n- [ ] Sentence length varies (SD > 5 words)\n- [ ] Paragraphs 2-5 sentences each\n- [ ] No five-paragraph essay structure\n\n### Style Quality\n- [ ] Consistent voice throughout\n- [ ] Appropriate formality for audience\n- [ ] Contractions used if informal tone\n- [ ] No emojis (unless explicitly requested)\n\n### Technical Quality\n- [ ] File paths verified to exist\n- [ ] Commands tested and working\n- [ ] Version numbers accurate\n- [ ] Links not broken\n\n## Metric Thresholds\n\n| Metric | Pass | Warning | Fail |\n|--------|------|---------|------|\n| Slop score | < 1.0 | 1.0-2.5 | > 2.5 |\n| Tier 1 words | 0 | 1-2 | 3+ |\n| Em dashes | < 3/1000 | 3-5/1000 | > 5/1000 |\n| Bullet ratio | < 30% | 30-50% | > 50% |\n| Sentence SD | > 8 | 5-8 | < 5 |\n\n## TodoWrite Integration\n\nTrack quality gate status:\n\n```\ndoc-generator:quality-content - PASS/FAIL\ndoc-generator:quality-structure - PASS/FAIL\ndoc-generator:quality-style - PASS/FAIL\ndoc-generator:quality-technical - PASS/FAIL\n```\n\n## Remediation Required\n\nIf any gate fails:\n\n1. Identify specific failures\n2. Propose fixes\n3. Apply fixes\n4. Re-run gates\n5. Repeat until pass\n\n## Exceptions\n\nDocument exceptions when gates are intentionally skipped:\n\n```markdown\n## Quality Gate Exception\n\n**Document**: API-reference.md\n**Gate**: bullet-ratio (58%)\n**Reason**: Reference documentation requires list format\n**Approved by**: [user]\n**Date**: [date]\n```\n\n## Integration with CI\n\nFor automated checking:\n\n```yaml\n# .github/workflows/docs-quality.yaml\n- name: Check documentation quality\n  run: |\n    scribe scan docs/\n    if [ $? -ne 0 ]; then\n      echo \"Documentation quality check failed\"\n      exit 1\n    fi\n```\n\nFile v1.9.14:modules/remediation-workflow.md\n\n---\nmodule: remediation-workflow\ncategory: writing-quality\ndependencies: [Edit, Read]\nestimated_tokens: 400\n---\n\n# Documentation Remediation Workflow\n\nStep-by-step process for cleaning up AI-generated content.\n\n## Phase 1: Assessment\n\nRun slop-detector and categorize findings:\n\n```markdown\n## Remediation Assessment: [filename]\n\n**Slop Score**: X.X\n**Word Count**: N\n\n### Critical (fix immediately)\n- [ ] Vapid opener at line 1\n- [ ] \"cannot be overstated\" at line 45\n\n### High Priority (fix in this pass)\n- [ ] 8 tier-1 slop words\n- [ ] Em dash density 7/1000\n\n### Medium Priority (fix if time)\n- [ ] Bullet ratio 55%\n- [ ] Sentence uniformity\n\n### Low Priority (defer)\n- [ ] Minor vocabulary substitutions\n```\n\n## Phase 2: User Approval for Major Changes\n\nIf remediation requires:\n- Deleting entire sections\n- Restructuring document flow\n- Changing technical content\n\nAlways ask:\n\n```markdown\n## Major Change Required\n\nThe opening section (lines 1-25) is primarily filler with no\ntechnical content. Options:\n\n1. **Delete entirely** - Start at line 26 with actual information\n2. **Condense to 2 sentences** - Keep intro but remove fluff\n3. **Rewrite** - New opening based on document purpose\n\nWhich approach? [1/2/3]\n```\n\n## Phase 3: Section-by-Section Editing\n\nFor documents over 200 lines, process in sections:\n\n```markdown\n## Section 1: Introduction (Lines 1-45)\n\n### Current State\n> In today's rapidly evolving technological landscape,\n> comprehensive documentation plays a pivotal role in\n> ensuring seamless developer experiences...\n\n### Issues\n- Vapid opener\n- \"comprehensive\", \"pivotal\", \"seamless\" (tier 1/2 words)\n- No concrete information in 45 words\n\n### Proposed Revision\n> scribe checks documentation for AI-generated patterns\n> and provides rewriting guidance. This guide covers\n> installation, configuration, and usage.\n\n### Changes\n- Removed opener cliche\n- Replaced with direct statement\n- Cut word count from 45 to 22\n\nProceed? [Y/n/edit]\n```\n\n## Phase 4: Vocabulary Sweep\n\nAfter structural fixes, sweep for remaining vocabulary:\n\n```bash\n# Quick vocabulary check\ngrep -nE '\\b(delve|embark|leverage|utilize|comprehensive)\\b' file.md\n```\n\nApply substitutions from shared module:\n\n| Line | Current | Replacement |\n|------|---------|-------------|\n| 23 | leverage | use |\n| 45 | utilize | use |\n| 67 | comprehensive | thorough |\n\n## Phase 5: Structural Polish\n\nFinal pass for structural issues:\n\n1. **Em dashes**: Replace excessive uses with commas/periods\n2. **Lists**: Convert bullet waterfalls to prose\n3. **Sentence variation**: Add short/long variety\n4. **Contractions**: Add if tone is informal\n\n## Phase 6: Verification\n\nRe-run slop-detector:\n\n```markdown\n## Remediation Results\n\n| Metric | Before | After | Change |\n|--------|--------|-------|--------|\n| Slop score | 4.8 | 1.2 | -75% |\n| Tier 1 words | 12 | 0 | -100% |\n| Em dash density | 7/1000 | 2/1000 | -71% |\n| Bullet ratio | 55% | 30% | -45% |\n\nStatus: CLEAN\n```\n\n## Docstring Mode\n\nFor code files, special handling:\n\n1. Extract docstrings only (don't modify code)\n2. Apply vocabulary substitutions\n3. Convert to imperative mood\n4. Verify with slop-detector\n5. Re-insert docstrings\n\n```python\n# ONLY these parts change:\ndef function():\n    \"\"\"\n    BEFORE: \"This function leverages advanced algorithms to\n    comprehensively process the input data.\"\n\n    AFTER: \"Process input data and return result.\"\n    \"\"\"\n    # Code remains EXACTLY as-is\n```\n\nFile v1.9.14:skill-card.md\n\n## Description: <br>\nGenerates or remediates documentation with human-quality writing. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and technical writers use this skill to draft new documentation or remediate existing documentation so it leads with a clear thesis, avoids filler, preserves technical intent, and passes writing-quality checks. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad writing-related triggers may invoke the skill on documentation tasks where the user did not intend a large rewrite. <br>\nMitigation: Review proposed edits before accepting them, especially for large rewrites, and require explicit approval for major structural changes. <br>\nRisk: Documentation remediation can accidentally change meaning while improving style. <br>\nMitigation: Preserve what the source says, change only how it is written, and ask the user when intent is unclear. <br>\nRisk: Generated documentation can contain inaccurate paths, commands, version numbers, or links. <br>\nMitigation: Apply the quality gates that require verifying file paths, testing commands, checking version numbers, and validating links. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-scribe-doc-generator) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [Configured homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown or prose guidance with optional checklists, before-and-after revisions, and command snippets] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include section-by-section remediation proposals, quality gate results, and approval prompts for major documentation changes.] <br>\n\n## Skill Version(s): <br>\n1.9.14 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.13: 6 files, 10226 bytes\n\nFiles: modules/generation-guidelines.md (3924b), modules/quality-gates.md (2278b), modules/remediation-workflow.md (3430b), skill-card.md (2233b), SKILL.md (6965b), _meta.json (143b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: doc-generator\ndescription: Generates or remediates documentation with human-quality writing\nversion: 1.9.8\ntriggers:\n  - documentation\n  - writing\n  - generation\n  - remediation\n  - polish\n  - creating new docs\n  - rewriting AI-generated content\n  - or applying style profiles\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Documentation Generator\n\n**A document costs the sum of its readers' time. Earn that\ncost or cut.**\n\nGenerate documents that are grounded in specific claims, lead\nwith their thesis, and earn every sentence. Filler phrases like\n\"In today's fast-paced world\" and vague descriptors like\n\"thorough\" or \"complete\" without evidence are bloat. So is\nany sentence that does not carry, instance, bound, or repeat\nthe document's one takeaway.\n\nThis skill enforces both **sentence-level cleanliness** (no\nslop vocabulary, em dash overuse, or sycophantic openers) and\n**document-level economy** (thesis-first, every sentence\nearns weight, repetition reserved for the thesis). See\n`Skill(scribe:slop-detector)` module `document-economy.md`\nfor the full rubric.\n\n## Core Writing Principles\n\nUse active voice and an authorial perspective. Explain the\nreasoning behind technical choices (why this database, not\nthat one) rather than presenting neutral boilerplate. Use\nbullets sparingly for short, parallel summaries; convert\nmulti-line bullet waterfalls into prose so the reasoning\nsurvives.\n\n### Vocabulary and Style\n\nAvoid business jargon and linguistic tics like mirrored\nsentence structures or em dash overuse. Use the imperative\nmood for docstrings (\"Validate input\", not \"Validates\").\nDo not humanize non-living constructs (\"the code wants\",\n\"the function speaks to\").\n\n| Instead of | Use |\n|------------|-----|\n| fallback | default, secondary |\n| leverage | use |\n| utilize | use |\n| facilitate | help, enable |\n| comprehensive | thorough, complete |\n\n### 9. Limit Humanizing Constructs\n\n\"Lives under,\" \"speaks to,\" and similar phrases only make sense\nfor living things.\n\n### 10. Imperative Mood for Docstrings\n\n\"Validate\" not \"Validates\" (per PEP 257, pydocstyle, ruff).\n\n## Required TodoWrite Items\n\n1. `doc-generator:scope-defined` - Target files and type identified\n2. `doc-generator:style-loaded` - Style profile applied (if available)\n3. `doc-generator:content-drafted` - Initial content created\n4. `doc-generator:slop-scanned` - AI markers checked\n5. `doc-generator:quality-verified` - Principles checklist passed\n6. `doc-generator:user-approved` - Final approval received\n\n## Mode: Generation\n\nFor new documentation:\n\n### Step 1: Define Scope\n\n```markdown\n## Generation Request\n\n**Type**: [README/Guide/API docs/Tutorial]\n**Audience**: [developers/users/admins]\n**Audience size**: [1 / small team / org / public]\n**Read frequency**: [once / weekly / per-invocation]\n**Thesis**: [one sentence the reader must walk away with]\n**Length target**: [~X words or sections]\n**Style profile**: [profile name or \"default\"]\n```\n\nThe **Thesis** field is required. If you cannot state the\ntakeaway in one sentence, the scope is not ready. Audience\nsize and read frequency feed the reader-time budget (see\n`scribe:slop-detector` module `document-economy.md`): a\nskill loaded daily by 50 users has a wildly different\nbudget than a 1:1 design note.\n\n### Step 2: Load Style (if available)\n\nIf a style profile exists:\n```bash\ncat .scribe/style-profile.yaml\n```\n\nApply voice, vocabulary, and structural guidelines.\n\n### Step 3: Draft Content\n\n**Lead with the thesis.** The first paragraph must state the\nsingle takeaway. If a reader stops after the lead, they should\nstill leave with the message. Echo the thesis once in the body\nand once at the close; cut every other repetition.\n\nFollow the 10 core principles above. For each section:\n\n1. Start with the essential information (state the thesis or\n   a clear instance of it)\n2. Add context only if it adds value (does it carry, instance,\n   or bound the thesis?)\n3. Use specific examples (one is proof; two is emphasis;\n   three is filler)\n4. Prefer prose over bullets\n5. End when information is complete (no summary padding,\n   no \"in conclusion\" restatements)\n\n### Step 4: Run Slop Detector\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix any findings before proceeding.\n\n### Step 5: Quality Gate\n\nVerify against checklist:\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40%\n- [ ] All claims grounded with specifics\n- [ ] No formulaic openers or closers\n- [ ] Authorial perspective present\n- [ ] No emojis (unless explicitly requested)\n\nDocument-level (document-economy module):\n- [ ] Thesis stated in the lead, single and clear (2/2)\n- [ ] >80% of sentences carry, instance, bound, or repeat\n      the thesis (2/2)\n- [ ] Thesis echoed at least 3 times; non-thesis repetition\n      cut (2/2)\n- [ ] Writing time roughly proportional to (audience size ×\n      read frequency × per-read time)\n\n## Mode: Remediation\n\nFor cleaning up existing content:\n\nLoad: `@modules/remediation-workflow.md`\n\n### Step 1: Analyze Current State\n\n```bash\n# Get slop score\nSkill(scribe:slop-detector) --target file.md\n```\n\n### Step 2: Section-by-Section Approach\n\nFor large files (>200 lines), edit incrementally:\n\n```markdown\n## Section: [Name] (Lines X-Y)\n\n**Current slop score**: X.X\n**Issues found**: [list]\n\n**Proposed changes**:\n1. [Change 1]\n2. [Change 2]\n\n**Before**:\n> [current text]\n\n**After**:\n> [proposed text]\n\nProceed? [Y/n/edit]\n```\n\n### Step 3: Preserve Intent\n\nNever change WHAT is said, only HOW. If meaning is unclear, ask.\n\n### Step 4: Re-verify\n\nAfter edits, re-run slop-detector to confirm improvement.\n\n## Docstring-Specific Rules\n\nWhen editing code comments:\n\n1. **ONLY modify docstring/comment text**\n2. **Never change surrounding code**\n3. **Use imperative mood** (\"Validate input\" not \"Validates input\")\n4. **Brief is better** - remove filler\n5. **Keep Args/Returns structure** if present\n\n## Module Reference\n\n- See `modules/generation-guidelines.md` for content creation patterns\n- See `modules/quality-gates.md` for validation criteria\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| slop-detector | After drafting, before approval |\n| style-learner | Before generation to load profile |\n| sanctum:doc-updates | For broader doc maintenance |\n\n## Exit Criteria\n\n- Content created or remediated\n- Slop score < 1.5 (clean rating)\n- Quality gate checklist passed\n- User approval received\n- No emojis present (unless specified)\n\nFile v1.9.13:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-doc-generator\",\n  \"version\": \"1.9.13\",\n  \"publishedAt\": 1782577435031\n}\n\nFile v1.9.13:modules/generation-guidelines.md\n\n---\nmodule: generation-guidelines\ncategory: writing-quality\ndependencies: []\nestimated_tokens: 400\n---\n\n# Documentation Generation Guidelines\n\nDetailed guidance for creating human-quality documentation.\n\n## Opening Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\"\n```\n\n### What to Use\n\n```markdown\nGOOD: \"scribe detects AI-generated content and helps you fix it.\"\nGOOD: \"Install with: npm install scribe\"\nGOOD: \"This guide covers installation, configuration, and common workflows.\"\n```\n\nStart with what it IS or what it DOES. Skip the preamble.\n\n## Section Structure\n\n### Length Targets\n\n| Section Type | Target Length |\n|--------------|---------------|\n| Overview | 50-100 words |\n| Feature description | 30-60 words |\n| Step in guide | 20-50 words |\n| API endpoint | 40-80 words |\n\n### Paragraph Guidance\n\nParagraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it.\n\nOne paragraph = one idea.\n\n## Line Wrapping\n\nWrap prose text at 80 characters per line using hybrid\nwrapping. This makes git diffs readable and mobile-friendly.\n\n### Rules (in priority order)\n\n1. Keep sentences on one line if they fit within 80 chars\n2. Break long sentences at clause boundaries (after `, ; :`)\n3. Break before conjunctions (`and`, `but`, `or`)\n4. Break at word boundaries as a last resort\n\n### Exempt from wrapping\n\nTables, code blocks, headings, frontmatter, HTML blocks,\nlink definitions, and image references stay on one line.\n\n### Example\n\n```markdown\nBEFORE:\nThe system validates all input against the schema and rejects\nmalformed requests with a 400 status code, logging the\nvalidation failure for debugging.\n\nAFTER:\nThe system validates all input against the schema\nand rejects malformed requests with a 400 status code,\nlogging the validation failure for debugging.\n```\n\n### Additional formatting rules\n\n- Blank line before and after every heading\n- ATX headings only (`#` style, never setext underlines)\n- Blank line before every list\n- Use reference-style links when inline links push past\n  80 chars\n\nFull specification: `Skill(leyline:markdown-formatting)`\n\n## Concrete Examples\n\nEvery feature claim needs a concrete example:\n\n```markdown\nBAD: \"The system provides flexible configuration options.\"\n\nGOOD: \"Configure via `scribe.yaml` or environment variables.\nSet `SCRIBE_STRICT=1` to treat warnings as errors.\"\n```\n\n## Trade-off Discussions\n\nInclude reasoning, not just conclusions:\n\n```markdown\nBAD: \"We recommend Redis for caching.\"\n\nGOOD: \"We chose Redis over Memcached for its sorted sets,\nwhich power the leaderboard. Memcached would use less memory\nbut require additional application logic.\"\n```\n\n## Ending Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In conclusion, we have covered the essential aspects of...\"\nBAD: \"We hope this guide has been helpful in your journey...\"\nBAD: \"Happy coding!\"\n```\n\n### What to Use\n\nEnd with the last useful piece of information. No summary paragraph unless the document exceeds 2000 words.\n\n```markdown\nGOOD: \"For issues, open a ticket at github.com/org/repo/issues.\"\nGOOD: \"Next: Advanced Configuration\"\nGOOD: [Just end. No closing needed.]\n```\n\n## Voice Consistency\n\nMaintain consistent perspective throughout:\n\n| Style | Example |\n|-------|---------|\n| Direct | \"Run `npm install`\" |\n| Team | \"We recommend...\" |\n| Instructional | \"You can configure...\" |\n\nDon't mix: \"One should note that you can...\"\n\n## Handling Uncertainty\n\nWhen information is incomplete:\n\n```markdown\nGOOD: \"Exact performance varies by hardware. Our tests showed 50-200ms on M1 Mac.\"\nGOOD: \"This feature is experimental. API may change.\"\nGOOD: \"We haven't tested on Windows. Linux and macOS confirmed working.\"\n```\n\nAcknowledge limits rather than overgeneralizing.\n\nFile v1.9.13:modules/quality-gates.md\n\n---\nmodule: quality-gates\ncategory: writing-quality\ndependencies: [TodoWrite]\nestimated_tokens: 300\n---\n\n# Documentation Quality Gates\n\nChecklists and thresholds for documentation quality validation.\n\n## Pre-Commit Checklist\n\nBefore finalizing any documentation:\n\n### Content Quality\n- [ ] No tier-1 slop words present\n- [ ] No vapid openers or closers\n- [ ] All claims grounded with specifics\n- [ ] Trade-offs explained, not just conclusions\n- [ ] Authorial perspective present (\"we chose\", \"our tests showed\")\n\n### Structure Quality\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40% (unless reference material)\n- [ ] Sentence length varies (SD > 5 words)\n- [ ] Paragraphs 2-5 sentences each\n- [ ] No five-paragraph essay structure\n\n### Style Quality\n- [ ] Consistent voice throughout\n- [ ] Appropriate formality for audience\n- [ ] Contractions used if informal tone\n- [ ] No emojis (unless explicitly requested)\n\n### Technical Quality\n- [ ] File paths verified to exist\n- [ ] Commands tested and working\n- [ ] Version numbers accurate\n- [ ] Links not broken\n\n## Metric Thresholds\n\n| Metric | Pass | Warning | Fail |\n|--------|------|---------|------|\n| Slop score | < 1.0 | 1.0-2.5 | > 2.5 |\n| Tier 1 words | 0 | 1-2 | 3+ |\n| Em dashes | < 3/1000 | 3-5/1000 | > 5/1000 |\n| Bullet ratio | < 30% | 30-50% | > 50% |\n| Sentence SD | > 8 | 5-8 | < 5 |\n\n## TodoWrite Integration\n\nTrack quality gate status:\n\n```\ndoc-generator:quality-content - PASS/FAIL\ndoc-generator:quality-structure - PASS/FAIL\ndoc-generator:quality-style - PASS/FAIL\ndoc-generator:quality-technical - PASS/FAIL\n```\n\n## Remediation Required\n\nIf any gate fails:\n\n1. Identify specific failures\n2. Propose fixes\n3. Apply fixes\n4. Re-run gates\n5. Repeat until pass\n\n## Exceptions\n\nDocument exceptions when gates are intentionally skipped:\n\n```markdown\n## Quality Gate Exception\n\n**Document**: API-reference.md\n**Gate**: bullet-ratio (58%)\n**Reason**: Reference documentation requires list format\n**Approved by**: [user]\n**Date**: [date]\n```\n\n## Integration with CI\n\nFor automated checking:\n\n```yaml\n# .github/workflows/docs-quality.yaml\n- name: Check documentation quality\n  run: |\n    scribe scan docs/\n    if [ $? -ne 0 ]; then\n      echo \"Documentation quality check failed\"\n      exit 1\n    fi\n```\n\nFile v1.9.13:modules/remediation-workflow.md\n\n---\nmodule: remediation-workflow\ncategory: writing-quality\ndependencies: [Edit, Read]\nestimated_tokens: 400\n---\n\n# Documentation Remediation Workflow\n\nStep-by-step process for cleaning up AI-generated content.\n\n## Phase 1: Assessment\n\nRun slop-detector and categorize findings:\n\n```markdown\n## Remediation Assessment: [filename]\n\n**Slop Score**: X.X\n**Word Count**: N\n\n### Critical (fix immediately)\n- [ ] Vapid opener at line 1\n- [ ] \"cannot be overstated\" at line 45\n\n### High Priority (fix in this pass)\n- [ ] 8 tier-1 slop words\n- [ ] Em dash density 7/1000\n\n### Medium Priority (fix if time)\n- [ ] Bullet ratio 55%\n- [ ] Sentence uniformity\n\n### Low Priority (defer)\n- [ ] Minor vocabulary substitutions\n```\n\n## Phase 2: User Approval for Major Changes\n\nIf remediation requires:\n- Deleting entire sections\n- Restructuring document flow\n- Changing technical content\n\nAlways ask:\n\n```markdown\n## Major Change Required\n\nThe opening section (lines 1-25) is primarily filler with no\ntechnical content. Options:\n\n1. **Delete entirely** - Start at line 26 with actual information\n2. **Condense to 2 sentences** - Keep intro but remove fluff\n3. **Rewrite** - New opening based on document purpose\n\nWhich approach? [1/2/3]\n```\n\n## Phase 3: Section-by-Section Editing\n\nFor documents over 200 lines, process in sections:\n\n```markdown\n## Section 1: Introduction (Lines 1-45)\n\n### Current State\n> In today's rapidly evolving technological landscape,\n> comprehensive documentation plays a pivotal role in\n> ensuring seamless developer experiences...\n\n### Issues\n- Vapid opener\n- \"comprehensive\", \"pivotal\", \"seamless\" (tier 1/2 words)\n- No concrete information in 45 words\n\n### Proposed Revision\n> scribe checks documentation for AI-generated patterns\n> and provides rewriting guidance. This guide covers\n> installation, configuration, and usage.\n\n### Changes\n- Removed opener cliche\n- Replaced with direct statement\n- Cut word count from 45 to 22\n\nProceed? [Y/n/edit]\n```\n\n## Phase 4: Vocabulary Sweep\n\nAfter structural fixes, sweep for remaining vocabulary:\n\n```bash\n# Quick vocabulary check\ngrep -nE '\\b(delve|embark|leverage|utilize|comprehensive)\\b' file.md\n```\n\nApply substitutions from shared module:\n\n| Line | Current | Replacement |\n|------|---------|-------------|\n| 23 | leverage | use |\n| 45 | utilize | use |\n| 67 | comprehensive | thorough |\n\n## Phase 5: Structural Polish\n\nFinal pass for structural issues:\n\n1. **Em dashes**: Replace excessive uses with commas/periods\n2. **Lists**: Convert bullet waterfalls to prose\n3. **Sentence variation**: Add short/long variety\n4. **Contractions**: Add if tone is informal\n\n## Phase 6: Verification\n\nRe-run slop-detector:\n\n```markdown\n## Remediation Results\n\n| Metric | Before | After | Change |\n|--------|--------|-------|--------|\n| Slop score | 4.8 | 1.2 | -75% |\n| Tier 1 words | 12 | 0 | -100% |\n| Em dash density | 7/1000 | 2/1000 | -71% |\n| Bullet ratio | 55% | 30% | -45% |\n\nStatus: CLEAN\n```\n\n## Docstring Mode\n\nFor code files, special handling:\n\n1. Extract docstrings only (don't modify code)\n2. Apply vocabulary substitutions\n3. Convert to imperative mood\n4. Verify with slop-detector\n5. Re-insert docstrings\n\n```python\n# ONLY these parts change:\ndef function():\n    \"\"\"\n    BEFORE: \"This function leverages advanced algorithms to\n    comprehensively process the input data.\"\n\n    AFTER: \"Process input data and return result.\"\n    \"\"\"\n    # Code remains EXACTLY as-is\n```\n\nFile v1.9.13:skill-card.md\n\n## Description: <br>\nGenerates or remediates documentation with human-quality writing. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and documentation maintainers use this skill to draft new documentation, remediate AI-like writing, and apply quality gates to repository docs, contributor guidance, and code comments. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Documentation or agent guidance changes could introduce inaccurate, misleading, or workflow-changing instructions. <br>\nMitigation: Review proposed edits before acceptance, especially changes to AGENTS.md, CONTRIBUTING.md, aliases, symlinks, and repository-wide guidance. <br>\nRisk: The remediation workflow may change wording in a way that alters intended meaning. <br>\nMitigation: Use the skill's section-by-section review flow for larger documents and require user approval for major restructuring or unclear intent. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-scribe-doc-generator) <br>\n- [Scribe Plugin Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Generation Guidelines](artifact/modules/generation-guidelines.md) <br>\n- [Quality Gates](artifact/modules/quality-gates.md) <br>\n- [Remediation Workflow](artifact/modules/remediation-workflow.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, shell commands, guidance] <br>\n**Output Format:** [Markdown prose with optional code blocks and shell commands] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May propose documentation edits, quality-gate results, and remediation steps for human review.] <br>\n\n## Skill Version(s): <br>\n1.9.13 (source: ClawHub release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.12: 6 files, 10087 bytes\n\nFiles: modules/generation-guidelines.md (3924b), modules/quality-gates.md (2278b), modules/remediation-workflow.md (3430b), skill-card.md (1964b), SKILL.md (6965b), _meta.json (143b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: doc-generator\ndescription: Generates or remediates documentation with human-quality writing\nversion: 1.9.8\ntriggers:\n  - documentation\n  - writing\n  - generation\n  - remediation\n  - polish\n  - creating new docs\n  - rewriting AI-generated content\n  - or applying style profiles\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Documentation Generator\n\n**A document costs the sum of its readers' time. Earn that\ncost or cut.**\n\nGenerate documents that are grounded in specific claims, lead\nwith their thesis, and earn every sentence. Filler phrases like\n\"In today's fast-paced world\" and vague descriptors like\n\"thorough\" or \"complete\" without evidence are bloat. So is\nany sentence that does not carry, instance, bound, or repeat\nthe document's one takeaway.\n\nThis skill enforces both **sentence-level cleanliness** (no\nslop vocabulary, em dash overuse, or sycophantic openers) and\n**document-level economy** (thesis-first, every sentence\nearns weight, repetition reserved for the thesis). See\n`Skill(scribe:slop-detector)` module `document-economy.md`\nfor the full rubric.\n\n## Core Writing Principles\n\nUse active voice and an authorial perspective. Explain the\nreasoning behind technical choices (why this database, not\nthat one) rather than presenting neutral boilerplate. Use\nbullets sparingly for short, parallel summaries; convert\nmulti-line bullet waterfalls into prose so the reasoning\nsurvives.\n\n### Vocabulary and Style\n\nAvoid business jargon and linguistic tics like mirrored\nsentence structures or em dash overuse. Use the imperative\nmood for docstrings (\"Validate input\", not \"Validates\").\nDo not humanize non-living constructs (\"the code wants\",\n\"the function speaks to\").\n\n| Instead of | Use |\n|------------|-----|\n| fallback | default, secondary |\n| leverage | use |\n| utilize | use |\n| facilitate | help, enable |\n| comprehensive | thorough, complete |\n\n### 9. Limit Humanizing Constructs\n\n\"Lives under,\" \"speaks to,\" and similar phrases only make sense\nfor living things.\n\n### 10. Imperative Mood for Docstrings\n\n\"Validate\" not \"Validates\" (per PEP 257, pydocstyle, ruff).\n\n## Required TodoWrite Items\n\n1. `doc-generator:scope-defined` - Target files and type identified\n2. `doc-generator:style-loaded` - Style profile applied (if available)\n3. `doc-generator:content-drafted` - Initial content created\n4. `doc-generator:slop-scanned` - AI markers checked\n5. `doc-generator:quality-verified` - Principles checklist passed\n6. `doc-generator:user-approved` - Final approval received\n\n## Mode: Generation\n\nFor new documentation:\n\n### Step 1: Define Scope\n\n```markdown\n## Generation Request\n\n**Type**: [README/Guide/API docs/Tutorial]\n**Audience**: [developers/users/admins]\n**Audience size**: [1 / small team / org / public]\n**Read frequency**: [once / weekly / per-invocation]\n**Thesis**: [one sentence the reader must walk away with]\n**Length target**: [~X words or sections]\n**Style profile**: [profile name or \"default\"]\n```\n\nThe **Thesis** field is required. If you cannot state the\ntakeaway in one sentence, the scope is not ready. Audience\nsize and read frequency feed the reader-time budget (see\n`scribe:slop-detector` module `document-economy.md`): a\nskill loaded daily by 50 users has a wildly different\nbudget than a 1:1 design note.\n\n### Step 2: Load Style (if available)\n\nIf a style profile exists:\n```bash\ncat .scribe/style-profile.yaml\n```\n\nApply voice, vocabulary, and structural guidelines.\n\n### Step 3: Draft Content\n\n**Lead with the thesis.** The first paragraph must state the\nsingle takeaway. If a reader stops after the lead, they should\nstill leave with the message. Echo the thesis once in the body\nand once at the close; cut every other repetition.\n\nFollow the 10 core principles above. For each section:\n\n1. Start with the essential information (state the thesis or\n   a clear instance of it)\n2. Add context only if it adds value (does it carry, instance,\n   or bound the thesis?)\n3. Use specific examples (one is proof; two is emphasis;\n   three is filler)\n4. Prefer prose over bullets\n5. End when information is complete (no summary padding,\n   no \"in conclusion\" restatements)\n\n### Step 4: Run Slop Detector\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix any findings before proceeding.\n\n### Step 5: Quality Gate\n\nVerify against checklist:\n\nSentence-level:\n- [ ] No tier-1 slop words\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40%\n- [ ] All claims grounded with specifics\n- [ ] No formulaic openers or closers\n- [ ] Authorial perspective present\n- [ ] No emojis (unless explicitly requested)\n\nDocument-level (document-economy module):\n- [ ] Thesis stated in the lead, single and clear (2/2)\n- [ ] >80% of sentences carry, instance, bound, or repeat\n      the thesis (2/2)\n- [ ] Thesis echoed at least 3 times; non-thesis repetition\n      cut (2/2)\n- [ ] Writing time roughly proportional to (audience size ×\n      read frequency × per-read time)\n\n## Mode: Remediation\n\nFor cleaning up existing content:\n\nLoad: `@modules/remediation-workflow.md`\n\n### Step 1: Analyze Current State\n\n```bash\n# Get slop score\nSkill(scribe:slop-detector) --target file.md\n```\n\n### Step 2: Section-by-Section Approach\n\nFor large files (>200 lines), edit incrementally:\n\n```markdown\n## Section: [Name] (Lines X-Y)\n\n**Current slop score**: X.X\n**Issues found**: [list]\n\n**Proposed changes**:\n1. [Change 1]\n2. [Change 2]\n\n**Before**:\n> [current text]\n\n**After**:\n> [proposed text]\n\nProceed? [Y/n/edit]\n```\n\n### Step 3: Preserve Intent\n\nNever change WHAT is said, only HOW. If meaning is unclear, ask.\n\n### Step 4: Re-verify\n\nAfter edits, re-run slop-detector to confirm improvement.\n\n## Docstring-Specific Rules\n\nWhen editing code comments:\n\n1. **ONLY modify docstring/comment text**\n2. **Never change surrounding code**\n3. **Use imperative mood** (\"Validate input\" not \"Validates input\")\n4. **Brief is better** - remove filler\n5. **Keep Args/Returns structure** if present\n\n## Module Reference\n\n- See `modules/generation-guidelines.md` for content creation patterns\n- See `modules/quality-gates.md` for validation criteria\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| slop-detector | After drafting, before approval |\n| style-learner | Before generation to load profile |\n| sanctum:doc-updates | For broader doc maintenance |\n\n## Exit Criteria\n\n- Content created or remediated\n- Slop score < 1.5 (clean rating)\n- Quality gate checklist passed\n- User approval received\n- No emojis present (unless specified)\n\nFile v1.9.12:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-doc-generator\",\n  \"version\": \"1.9.12\",\n  \"publishedAt\": 1781839171294\n}\n\nFile v1.9.12:modules/generation-guidelines.md\n\n---\nmodule: generation-guidelines\ncategory: writing-quality\ndependencies: []\nestimated_tokens: 400\n---\n\n# Documentation Generation Guidelines\n\nDetailed guidance for creating human-quality documentation.\n\n## Opening Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\"\n```\n\n### What to Use\n\n```markdown\nGOOD: \"scribe detects AI-generated content and helps you fix it.\"\nGOOD: \"Install with: npm install scribe\"\nGOOD: \"This guide covers installation, configuration, and common workflows.\"\n```\n\nStart with what it IS or what it DOES. Skip the preamble.\n\n## Section Structure\n\n### Length Targets\n\n| Section Type | Target Length |\n|--------------|---------------|\n| Overview | 50-100 words |\n| Feature description | 30-60 words |\n| Step in guide | 20-50 words |\n| API endpoint | 40-80 words |\n\n### Paragraph Guidance\n\nParagraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it.\n\nOne paragraph = one idea.\n\n## Line Wrapping\n\nWrap prose text at 80 characters per line using hybrid\nwrapping. This makes git diffs readable and mobile-friendly.\n\n### Rules (in priority order)\n\n1. Keep sentences on one line if they fit within 80 chars\n2. Break long sentences at clause boundaries (after `, ; :`)\n3. Break before conjunctions (`and`, `but`, `or`)\n4. Break at word boundaries as a last resort\n\n### Exempt from wrapping\n\nTables, code blocks, headings, frontmatter, HTML blocks,\nlink definitions, and image references stay on one line.\n\n### Example\n\n```markdown\nBEFORE:\nThe system validates all input against the schema and rejects\nmalformed requests with a 400 status code, logging the\nvalidation failure for debugging.\n\nAFTER:\nThe system validates all input against the schema\nand rejects malformed requests with a 400 status code,\nlogging the validation failure for debugging.\n```\n\n### Additional formatting rules\n\n- Blank line before and after every heading\n- ATX headings only (`#` style, never setext underlines)\n- Blank line before every list\n- Use reference-style links when inline links push past\n  80 chars\n\nFull specification: `Skill(leyline:markdown-formatting)`\n\n## Concrete Examples\n\nEvery feature claim needs a concrete example:\n\n```markdown\nBAD: \"The system provides flexible configuration options.\"\n\nGOOD: \"Configure via `scribe.yaml` or environment variables.\nSet `SCRIBE_STRICT=1` to treat warnings as errors.\"\n```\n\n## Trade-off Discussions\n\nInclude reasoning, not just conclusions:\n\n```markdown\nBAD: \"We recommend Redis for caching.\"\n\nGOOD: \"We chose Redis over Memcached for its sorted sets,\nwhich power the leaderboard. Memcached would use less memory\nbut require additional application logic.\"\n```\n\n## Ending Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In conclusion, we have covered the essential aspects of...\"\nBAD: \"We hope this guide has been helpful in your journey...\"\nBAD: \"Happy coding!\"\n```\n\n### What to Use\n\nEnd with the last useful piece of information. No summary paragraph unless the document exceeds 2000 words.\n\n```markdown\nGOOD: \"For issues, open a ticket at github.com/org/repo/issues.\"\nGOOD: \"Next: Advanced Configuration\"\nGOOD: [Just end. No closing needed.]\n```\n\n## Voice Consistency\n\nMaintain consistent perspective throughout:\n\n| Style | Example |\n|-------|---------|\n| Direct | \"Run `npm install`\" |\n| Team | \"We recommend...\" |\n| Instructional | \"You can configure...\" |\n\nDon't mix: \"One should note that you can...\"\n\n## Handling Uncertainty\n\nWhen information is incomplete:\n\n```markdown\nGOOD: \"Exact performance varies by hardware. Our tests showed 50-200ms on M1 Mac.\"\nGOOD: \"This feature is experimental. API may change.\"\nGOOD: \"We haven't tested on Windows. Linux and macOS confirmed working.\"\n```\n\nAcknowledge limits rather than overgeneralizing.\n\nFile v1.9.12:modules/quality-gates.md\n\n---\nmodule: quality-gates\ncategory: writing-quality\ndependencies: [TodoWrite]\nestimated_tokens: 300\n---\n\n# Documentation Quality Gates\n\nChecklists and thresholds for documentation quality validation.\n\n## Pre-Commit Checklist\n\nBefore finalizing any documentation:\n\n### Content Quality\n- [ ] No tier-1 slop words present\n- [ ] No vapid openers or closers\n- [ ] All claims grounded with specifics\n- [ ] Trade-offs explained, not just conclusions\n- [ ] Authorial perspective present (\"we chose\", \"our tests showed\")\n\n### Structure Quality\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40% (unless reference material)\n- [ ] Sentence length varies (SD > 5 words)\n- [ ] Paragraphs 2-5 sentences each\n- [ ] No five-paragraph essay structure\n\n### Style Quality\n- [ ] Consistent voice throughout\n- [ ] Appropriate formality for audience\n- [ ] Contractions used if informal tone\n- [ ] No emojis (unless explicitly requested)\n\n### Technical Quality\n- [ ] File paths verified to exist\n- [ ] Commands tested and working\n- [ ] Version numbers accurate\n- [ ] Links not broken\n\n## Metric Thresholds\n\n| Metric | Pass | Warning | Fail |\n|--------|------|---------|------|\n| Slop score | < 1.0 | 1.0-2.5 | > 2.5 |\n| Tier 1 words | 0 | 1-2 | 3+ |\n| Em dashes | < 3/1000 | 3-5/1000 | > 5/1000 |\n| Bullet ratio | < 30% | 30-50% | > 50% |\n| Sentence SD | > 8 | 5-8 | < 5 |\n\n## TodoWrite Integration\n\nTrack quality gate status:\n\n```\ndoc-generator:quality-content - PASS/FAIL\ndoc-generator:quality-structure - PASS/FAIL\ndoc-generator:quality-style - PASS/FAIL\ndoc-generator:quality-technical - PASS/FAIL\n```\n\n## Remediation Required\n\nIf any gate fails:\n\n1. Identify specific failures\n2. Propose fixes\n3. Apply fixes\n4. Re-run gates\n5. Repeat until pass\n\n## Exceptions\n\nDocument exceptions when gates are intentionally skipped:\n\n```markdown\n## Quality Gate Exception\n\n**Document**: API-reference.md\n**Gate**: bullet-ratio (58%)\n**Reason**: Reference documentation requires list format\n**Approved by**: [user]\n**Date**: [date]\n```\n\n## Integration with CI\n\nFor automated checking:\n\n```yaml\n# .github/workflows/docs-quality.yaml\n- name: Check documentation quality\n  run: |\n    scribe scan docs/\n    if [ $? -ne 0 ]; then\n      echo \"Documentation quality check failed\"\n      exit 1\n    fi\n```\n\nFile v1.9.12:modules/remediation-workflow.md\n\n---\nmodule: remediation-workflow\ncategory: writing-quality\ndependencies: [Edit, Read]\nestimated_tokens: 400\n---\n\n# Documentation Remediation Workflow\n\nStep-by-step process for cleaning up AI-generated content.\n\n## Phase 1: Assessment\n\nRun slop-detector and categorize findings:\n\n```markdown\n## Remediation Assessment: [filename]\n\n**Slop Score**: X.X\n**Word Count**: N\n\n### Critical (fix immediately)\n- [ ] Vapid opener at line 1\n- [ ] \"cannot be overstated\" at line 45\n\n### High Priority (fix in this pass)\n- [ ] 8 tier-1 slop words\n- [ ] Em dash density 7/1000\n\n### Medium Priority (fix if time)\n- [ ] Bullet ratio 55%\n- [ ] Sentence uniformity\n\n### Low Priority (defer)\n- [ ] Minor vocabulary substitutions\n```\n\n## Phase 2: User Approval for Major Changes\n\nIf remediation requires:\n- Deleting entire sections\n- Restructuring document flow\n- Changing technical content\n\nAlways ask:\n\n```markdown\n## Major Change Required\n\nThe opening section (lines 1-25) is primarily filler with no\ntechnical content. Options:\n\n1. **Delete entirely** - Start at line 26 with actual information\n2. **Condense to 2 sentences** - Keep intro but remove fluff\n3. **Rewrite** - New opening based on document purpose\n\nWhich approach? [1/2/3]\n```\n\n## Phase 3: Section-by-Section Editing\n\nFor documents over 200 lines, process in sections:\n\n```markdown\n## Section 1: Introduction (Lines 1-45)\n\n### Current State\n> In today's rapidly evolving technological landscape,\n> comprehensive documentation plays a pivotal role in\n> ensuring seamless developer experiences...\n\n### Issues\n- Vapid opener\n- \"comprehensive\", \"pivotal\", \"seamless\" (tier 1/2 words)\n- No concrete information in 45 words\n\n### Proposed Revision\n> scribe checks documentation for AI-generated patterns\n> and provides rewriting guidance. This guide covers\n> installation, configuration, and usage.\n\n### Changes\n- Removed opener cliche\n- Replaced with direct statement\n- Cut word count from 45 to 22\n\nProceed? [Y/n/edit]\n```\n\n## Phase 4: Vocabulary Sweep\n\nAfter structural fixes, sweep for remaining vocabulary:\n\n```bash\n# Quick vocabulary check\ngrep -nE '\\b(delve|embark|leverage|utilize|comprehensive)\\b' file.md\n```\n\nApply substitutions from shared module:\n\n| Line | Current | Replacement |\n|------|---------|-------------|\n| 23 | leverage | use |\n| 45 | utilize | use |\n| 67 | comprehensive | thorough |\n\n## Phase 5: Structural Polish\n\nFinal pass for structural issues:\n\n1. **Em dashes**: Replace excessive uses with commas/periods\n2. **Lists**: Convert bullet waterfalls to prose\n3. **Sentence variation**: Add short/long variety\n4. **Contractions**: Add if tone is informal\n\n## Phase 6: Verification\n\nRe-run slop-detector:\n\n```markdown\n## Remediation Results\n\n| Metric | Before | After | Change |\n|--------|--------|-------|--------|\n| Slop score | 4.8 | 1.2 | -75% |\n| Tier 1 words | 12 | 0 | -100% |\n| Em dash density | 7/1000 | 2/1000 | -71% |\n| Bullet ratio | 55% | 30% | -45% |\n\nStatus: CLEAN\n```\n\n## Docstring Mode\n\nFor code files, special handling:\n\n1. Extract docstrings only (don't modify code)\n2. Apply vocabulary substitutions\n3. Convert to imperative mood\n4. Verify with slop-detector\n5. Re-insert docstrings\n\n```python\n# ONLY these parts change:\ndef function():\n    \"\"\"\n    BEFORE: \"This function leverages advanced algorithms to\n    comprehensively process the input data.\"\n\n    AFTER: \"Process input data and return result.\"\n    \"\"\"\n    # Code remains EXACTLY as-is\n```\n\nFile v1.9.12:skill-card.md\n\n## Description: <br>\nGenerates or remediates documentation with human-quality writing. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and documentation maintainers use this skill to draft new documentation, remediate AI-generated writing patterns, and apply quality gates for clear, thesis-led technical content. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad trigger phrases may activate the skill for documentation-adjacent tasks more often than intended. <br>\nMitigation: Narrow trigger phrases or invoke the skill explicitly when installation policy requires activation only for documentation generation or remediation. <br>\nRisk: The skill can influence or edit documentation during remediation workflows. <br>\nMitigation: Review proposed edits before applying them and keep the skill scoped to target documentation files. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-scribe-doc-generator) <br>\n- [Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, shell commands, guidance] <br>\n**Output Format:** [Markdown with prose, checklists, and inline code blocks] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May edit target documentation when explicitly asked and uses documentation quality gates before completion.] <br>\n\n## Skill Version(s): <br>\n1.9.12 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.2: 6 files, 9549 bytes\n\nFiles: modules/generation-guidelines.md (3924b), modules/quality-gates.md (2278b), modules/remediation-workflow.md (3430b), skill-card.md (2545b), SKILL.md (5292b), _meta.json (142b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: doc-generator\ndescription: Generate or remediate documentation with human-quality writing and style\nversion: 1.9.5\ntriggers:\n  - documentation\n  - writing\n  - generation\n  - remediation\n  - polish\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Documentation Generator\n\nDocumentation must be grounded in specific claims rather than abstract adjectives. We avoid filler phrases like \"In today's fast-paced world\" and focus on delivering useful information directly. Each claim should be supported by evidence, such as specific version numbers or request rates, rather than vague descriptors like \"comprehensive.\"\n\n## Core Writing Principles\n\nWe prioritize authorial perspective and active voice to maintain a consistent team tone. This involves explaining the reasoning behind technical choices, such as selecting one database over another, rather than providing neutral boilerplate. Bullets should be used sparingly for actionable summaries; multi-line bullet waterfalls should be converted to short paragraphs to preserve nuance.\n\n### Vocabulary and Style\n\nAvoid business jargon and linguistic tics like mirrored sentence structures or excessive em dashes. We use the imperative mood for docstrings (e.g., \"Validate input\") and strictly avoid humanizing non-living constructs like code.\n\n| Instead of | Use |\n|------------|-----|\n| fallback | default, secondary |\n| leverage | use |\n| utilize | use |\n| facilitate | help, enable |\n| comprehensive | thorough, complete |\n\n### 9. Limit Humanizing Constructs\n\n\"Lives under,\" \"speaks to,\" and similar phrases only make sense for living things.\n\n### 10. Imperative Mood for Docstrings\n\n\"Validate\" not \"Validates\" (per PEP 257, pydocstyle, ruff).\n\n## Required TodoWrite Items\n\n1. `doc-generator:scope-defined` - Target files and type identified\n2. `doc-generator:style-loaded` - Style profile applied (if available)\n3. `doc-generator:content-drafted` - Initial content created\n4. `doc-generator:slop-scanned` - AI markers checked\n5. `doc-generator:quality-verified` - Principles checklist passed\n6. `doc-generator:user-approved` - Final approval received\n\n## Mode: Generation\n\nFor new documentation:\n\n### Step 1: Define Scope\n\n```markdown\n## Generation Request\n\n**Type**: [README/Guide/API docs/Tutorial]\n**Audience**: [developers/users/admins]\n**Length target**: [~X words or sections]\n**Style profile**: [profile name or \"default\"]\n```\n\n### Step 2: Load Style (if available)\n\nIf a style profile exists:\n```bash\ncat .scribe/style-profile.yaml\n```\n\nApply voice, vocabulary, and structural guidelines.\n\n### Step 3: Draft Content\n\nFollow the 10 core principles above. For each section:\n\n1. Start with the essential information\n2. Add context only if it adds value\n3. Use specific examples\n4. Prefer prose over bullets\n5. End when information is complete (no summary padding)\n\n### Step 4: Run Slop Detector\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix any findings before proceeding.\n\n### Step 5: Quality Gate\n\nVerify against checklist:\n- [ ] No tier-1 slop words\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40%\n- [ ] All claims grounded with specifics\n- [ ] No formulaic openers or closers\n- [ ] Authorial perspective present\n- [ ] No emojis (unless explicitly requested)\n\n## Mode: Remediation\n\nFor cleaning up existing content:\n\nLoad: `@modules/remediation-workflow.md`\n\n### Step 1: Analyze Current State\n\n```bash\n# Get slop score\nSkill(scribe:slop-detector) --target file.md\n```\n\n### Step 2: Section-by-Section Approach\n\nFor large files (>200 lines), edit incrementally:\n\n```markdown\n## Section: [Name] (Lines X-Y)\n\n**Current slop score**: X.X\n**Issues found**: [list]\n\n**Proposed changes**:\n1. [Change 1]\n2. [Change 2]\n\n**Before**:\n> [current text]\n\n**After**:\n> [proposed text]\n\nProceed? [Y/n/edit]\n```\n\n### Step 3: Preserve Intent\n\nNever change WHAT is said, only HOW. If meaning is unclear, ask.\n\n### Step 4: Re-verify\n\nAfter edits, re-run slop-detector to confirm improvement.\n\n## Docstring-Specific Rules\n\nWhen editing code comments:\n\n1. **ONLY modify docstring/comment text**\n2. **Never change surrounding code**\n3. **Use imperative mood** (\"Validate input\" not \"Validates input\")\n4. **Brief is better** - remove filler\n5. **Keep Args/Returns structure** if present\n\n## Module Reference\n\n- See `modules/generation-guidelines.md` for content creation patterns\n- See `modules/quality-gates.md` for validation criteria\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| slop-detector | After drafting, before approval |\n| style-learner | Before generation to load profile |\n| sanctum:doc-updates | For broader doc maintenance |\n\n## Exit Criteria\n\n- Content created or remediated\n- Slop score < 1.5 (clean rating)\n- Quality gate checklist passed\n- User approval received\n- No emojis present (unless specified)\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-doc-generator\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1778293217628\n}\n\nFile v1.0.2:modules/generation-guidelines.md\n\n---\nmodule: generation-guidelines\ncategory: writing-quality\ndependencies: []\nestimated_tokens: 400\n---\n\n# Documentation Generation Guidelines\n\nDetailed guidance for creating human-quality documentation.\n\n## Opening Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\"\n```\n\n### What to Use\n\n```markdown\nGOOD: \"scribe detects AI-generated content and helps you fix it.\"\nGOOD: \"Install with: npm install scribe\"\nGOOD: \"This guide covers installation, configuration, and common workflows.\"\n```\n\nStart with what it IS or what it DOES. Skip the preamble.\n\n## Section Structure\n\n### Length Targets\n\n| Section Type | Target Length |\n|--------------|---------------|\n| Overview | 50-100 words |\n| Feature description | 30-60 words |\n| Step in guide | 20-50 words |\n| API endpoint | 40-80 words |\n\n### Paragraph Guidance\n\nParagraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it.\n\nOne paragraph = one idea.\n\n## Line Wrapping\n\nWrap prose text at 80 characters per line using hybrid\nwrapping. This makes git diffs readable and mobile-friendly.\n\n### Rules (in priority order)\n\n1. Keep sentences on one line if they fit within 80 chars\n2. Break long sentences at clause boundaries (after `, ; :`)\n3. Break before conjunctions (`and`, `but`, `or`)\n4. Break at word boundaries as a last resort\n\n### Exempt from wrapping\n\nTables, code blocks, headings, frontmatter, HTML blocks,\nlink definitions, and image references stay on one line.\n\n### Example\n\n```markdown\nBEFORE:\nThe system validates all input against the schema and rejects\nmalformed requests with a 400 status code, logging the\nvalidation failure for debugging.\n\nAFTER:\nThe system validates all input against the schema\nand rejects malformed requests with a 400 status code,\nlogging the validation failure for debugging.\n```\n\n### Additional formatting rules\n\n- Blank line before and after every heading\n- ATX headings only (`#` style, never setext underlines)\n- Blank line before every list\n- Use reference-style links when inline links push past\n  80 chars\n\nFull specification: `Skill(leyline:markdown-formatting)`\n\n## Concrete Examples\n\nEvery feature claim needs a concrete example:\n\n```markdown\nBAD: \"The system provides flexible configuration options.\"\n\nGOOD: \"Configure via `scribe.yaml` or environment variables.\nSet `SCRIBE_STRICT=1` to treat warnings as errors.\"\n```\n\n## Trade-off Discussions\n\nInclude reasoning, not just conclusions:\n\n```markdown\nBAD: \"We recommend Redis for caching.\"\n\nGOOD: \"We chose Redis over Memcached for its sorted sets,\nwhich power the leaderboard. Memcached would use less memory\nbut require additional application logic.\"\n```\n\n## Ending Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In conclusion, we have covered the essential aspects of...\"\nBAD: \"We hope this guide has been helpful in your journey...\"\nBAD: \"Happy coding!\"\n```\n\n### What to Use\n\nEnd with the last useful piece of information. No summary paragraph unless the document exceeds 2000 words.\n\n```markdown\nGOOD: \"For issues, open a ticket at github.com/org/repo/issues.\"\nGOOD: \"Next: Advanced Configuration\"\nGOOD: [Just end. No closing needed.]\n```\n\n## Voice Consistency\n\nMaintain consistent perspective throughout:\n\n| Style | Example |\n|-------|---------|\n| Direct | \"Run `npm install`\" |\n| Team | \"We recommend...\" |\n| Instructional | \"You can configure...\" |\n\nDon't mix: \"One should note that you can...\"\n\n## Handling Uncertainty\n\nWhen information is incomplete:\n\n```markdown\nGOOD: \"Exact performance varies by hardware. Our tests showed 50-200ms on M1 Mac.\"\nGOOD: \"This feature is experimental. API may change.\"\nGOOD: \"We haven't tested on Windows. Linux and macOS confirmed working.\"\n```\n\nAcknowledge limits rather than overgeneralizing.\n\nFile v1.0.2:modules/quality-gates.md\n\n---\nmodule: quality-gates\ncategory: writing-quality\ndependencies: [TodoWrite]\nestimated_tokens: 300\n---\n\n# Documentation Quality Gates\n\nChecklists and thresholds for documentation quality validation.\n\n## Pre-Commit Checklist\n\nBefore finalizing any documentation:\n\n### Content Quality\n- [ ] No tier-1 slop words present\n- [ ] No vapid openers or closers\n- [ ] All claims grounded with specifics\n- [ ] Trade-offs explained, not just conclusions\n- [ ] Authorial perspective present (\"we chose\", \"our tests showed\")\n\n### Structure Quality\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40% (unless reference material)\n- [ ] Sentence length varies (SD > 5 words)\n- [ ] Paragraphs 2-5 sentences each\n- [ ] No five-paragraph essay structure\n\n### Style Quality\n- [ ] Consistent voice throughout\n- [ ] Appropriate formality for audience\n- [ ] Contractions used if informal tone\n- [ ] No emojis (unless explicitly requested)\n\n### Technical Quality\n- [ ] File paths verified to exist\n- [ ] Commands tested and working\n- [ ] Version numbers accurate\n- [ ] Links not broken\n\n## Metric Thresholds\n\n| Metric | Pass | Warning | Fail |\n|--------|------|---------|------|\n| Slop score | < 1.0 | 1.0-2.5 | > 2.5 |\n| Tier 1 words | 0 | 1-2 | 3+ |\n| Em dashes | < 3/1000 | 3-5/1000 | > 5/1000 |\n| Bullet ratio | < 30% | 30-50% | > 50% |\n| Sentence SD | > 8 | 5-8 | < 5 |\n\n## TodoWrite Integration\n\nTrack quality gate status:\n\n```\ndoc-generator:quality-content - PASS/FAIL\ndoc-generator:quality-structure - PASS/FAIL\ndoc-generator:quality-style - PASS/FAIL\ndoc-generator:quality-technical - PASS/FAIL\n```\n\n## Remediation Required\n\nIf any gate fails:\n\n1. Identify specific failures\n2. Propose fixes\n3. Apply fixes\n4. Re-run gates\n5. Repeat until pass\n\n## Exceptions\n\nDocument exceptions when gates are intentionally skipped:\n\n```markdown\n## Quality Gate Exception\n\n**Document**: API-reference.md\n**Gate**: bullet-ratio (58%)\n**Reason**: Reference documentation requires list format\n**Approved by**: [user]\n**Date**: [date]\n```\n\n## Integration with CI\n\nFor automated checking:\n\n```yaml\n# .github/workflows/docs-quality.yaml\n- name: Check documentation quality\n  run: |\n    scribe scan docs/\n    if [ $? -ne 0 ]; then\n      echo \"Documentation quality check failed\"\n      exit 1\n    fi\n```\n\nFile v1.0.2:modules/remediation-workflow.md\n\n---\nmodule: remediation-workflow\ncategory: writing-quality\ndependencies: [Edit, Read]\nestimated_tokens: 400\n---\n\n# Documentation Remediation Workflow\n\nStep-by-step process for cleaning up AI-generated content.\n\n## Phase 1: Assessment\n\nRun slop-detector and categorize findings:\n\n```markdown\n## Remediation Assessment: [filename]\n\n**Slop Score**: X.X\n**Word Count**: N\n\n### Critical (fix immediately)\n- [ ] Vapid opener at line 1\n- [ ] \"cannot be overstated\" at line 45\n\n### High Priority (fix in this pass)\n- [ ] 8 tier-1 slop words\n- [ ] Em dash density 7/1000\n\n### Medium Priority (fix if time)\n- [ ] Bullet ratio 55%\n- [ ] Sentence uniformity\n\n### Low Priority (defer)\n- [ ] Minor vocabulary substitutions\n```\n\n## Phase 2: User Approval for Major Changes\n\nIf remediation requires:\n- Deleting entire sections\n- Restructuring document flow\n- Changing technical content\n\nAlways ask:\n\n```markdown\n## Major Change Required\n\nThe opening section (lines 1-25) is primarily filler with no\ntechnical content. Options:\n\n1. **Delete entirely** - Start at line 26 with actual information\n2. **Condense to 2 sentences** - Keep intro but remove fluff\n3. **Rewrite** - New opening based on document purpose\n\nWhich approach? [1/2/3]\n```\n\n## Phase 3: Section-by-Section Editing\n\nFor documents over 200 lines, process in sections:\n\n```markdown\n## Section 1: Introduction (Lines 1-45)\n\n### Current State\n> In today's rapidly evolving technological landscape,\n> comprehensive documentation plays a pivotal role in\n> ensuring seamless developer experiences...\n\n### Issues\n- Vapid opener\n- \"comprehensive\", \"pivotal\", \"seamless\" (tier 1/2 words)\n- No concrete information in 45 words\n\n### Proposed Revision\n> scribe checks documentation for AI-generated patterns\n> and provides rewriting guidance. This guide covers\n> installation, configuration, and usage.\n\n### Changes\n- Removed opener cliche\n- Replaced with direct statement\n- Cut word count from 45 to 22\n\nProceed? [Y/n/edit]\n```\n\n## Phase 4: Vocabulary Sweep\n\nAfter structural fixes, sweep for remaining vocabulary:\n\n```bash\n# Quick vocabulary check\ngrep -nE '\\b(delve|embark|leverage|utilize|comprehensive)\\b' file.md\n```\n\nApply substitutions from shared module:\n\n| Line | Current | Replacement |\n|------|---------|-------------|\n| 23 | leverage | use |\n| 45 | utilize | use |\n| 67 | comprehensive | thorough |\n\n## Phase 5: Structural Polish\n\nFinal pass for structural issues:\n\n1. **Em dashes**: Replace excessive uses with commas/periods\n2. **Lists**: Convert bullet waterfalls to prose\n3. **Sentence variation**: Add short/long variety\n4. **Contractions**: Add if tone is informal\n\n## Phase 6: Verification\n\nRe-run slop-detector:\n\n```markdown\n## Remediation Results\n\n| Metric | Before | After | Change |\n|--------|--------|-------|--------|\n| Slop score | 4.8 | 1.2 | -75% |\n| Tier 1 words | 12 | 0 | -100% |\n| Em dash density | 7/1000 | 2/1000 | -71% |\n| Bullet ratio | 55% | 30% | -45% |\n\nStatus: CLEAN\n```\n\n## Docstring Mode\n\nFor code files, special handling:\n\n1. Extract docstrings only (don't modify code)\n2. Apply vocabulary substitutions\n3. Convert to imperative mood\n4. Verify with slop-detector\n5. Re-insert docstrings\n\n```python\n# ONLY these parts change:\ndef function():\n    \"\"\"\n    BEFORE: \"This function leverages advanced algorithms to\n    comprehensively process the input data.\"\n\n    AFTER: \"Process input data and return result.\"\n    \"\"\"\n    # Code remains EXACTLY as-is\n```\n\nFile v1.0.2:skill-card.md\n\n## Description: <br>\nGenerate or remediate documentation with human-quality writing and style. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and documentation maintainers use this skill to draft new documentation, remediate existing text, and apply quality checks for clearer technical writing. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad documentation and writing triggers may activate the skill more often than intended. <br>\nMitigation: Confirm the target files and documentation task before applying suggested edits. <br>\nRisk: Documentation edits may introduce incorrect, misleading, or stylistically unwanted changes. <br>\nMitigation: Review diffs before accepting edits and require user approval for major rewrites or structural changes. <br>\nRisk: Style profiles may accidentally contain sensitive project information. <br>\nMitigation: Avoid storing secrets or credentials in .scribe style profiles. <br>\nRisk: Suggested command checks may affect local files or depend on unavailable tools. <br>\nMitigation: Approve proposed command checks explicitly before running them. <br>\n\n\n## Reference(s): <br>\n- [ClawHub release page](https://clawhub.ai/athola/nm-scribe-doc-generator) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [Scribe homepage](https://github.com/athola/claude-night-market/tree/master/plugins/scribe) <br>\n- [Generation guidelines](artifact/modules/generation-guidelines.md) <br>\n- [Quality gates](artifact/modules/quality-gates.md) <br>\n- [Remediation workflow](artifact/modules/remediation-workflow.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, shell commands, configuration, guidance] <br>\n**Output Format:** [Markdown guidance with optional code blocks and shell commands] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May propose documentation edits, quality checklists, and explicit user approval steps before finalizing changes.] <br>\n\n## Skill Version(s): <br>\n1.0.2 (source: release evidence; artifact frontmatter lists 1.9.5) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.1: 5 files, 8268 bytes\n\nFiles: modules/generation-guidelines.md (3924b), modules/quality-gates.md (2278b), modules/remediation-workflow.md (3430b), SKILL.md (5292b), _meta.json (142b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: doc-generator\ndescription: Generate or remediate documentation with human-quality writing and style\nversion: 1.9.4\ntriggers:\n  - documentation\n  - writing\n  - generation\n  - remediation\n  - polish\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Documentation Generator\n\nDocumentation must be grounded in specific claims rather than abstract adjectives. We avoid filler phrases like \"In today's fast-paced world\" and focus on delivering useful information directly. Each claim should be supported by evidence, such as specific version numbers or request rates, rather than vague descriptors like \"comprehensive.\"\n\n## Core Writing Principles\n\nWe prioritize authorial perspective and active voice to maintain a consistent team tone. This involves explaining the reasoning behind technical choices, such as selecting one database over another, rather than providing neutral boilerplate. Bullets should be used sparingly for actionable summaries; multi-line bullet waterfalls should be converted to short paragraphs to preserve nuance.\n\n### Vocabulary and Style\n\nAvoid business jargon and linguistic tics like mirrored sentence structures or excessive em dashes. We use the imperative mood for docstrings (e.g., \"Validate input\") and strictly avoid humanizing non-living constructs like code.\n\n| Instead of | Use |\n|------------|-----|\n| fallback | default, secondary |\n| leverage | use |\n| utilize | use |\n| facilitate | help, enable |\n| comprehensive | thorough, complete |\n\n### 9. Limit Humanizing Constructs\n\n\"Lives under,\" \"speaks to,\" and similar phrases only make sense for living things.\n\n### 10. Imperative Mood for Docstrings\n\n\"Validate\" not \"Validates\" (per PEP 257, pydocstyle, ruff).\n\n## Required TodoWrite Items\n\n1. `doc-generator:scope-defined` - Target files and type identified\n2. `doc-generator:style-loaded` - Style profile applied (if available)\n3. `doc-generator:content-drafted` - Initial content created\n4. `doc-generator:slop-scanned` - AI markers checked\n5. `doc-generator:quality-verified` - Principles checklist passed\n6. `doc-generator:user-approved` - Final approval received\n\n## Mode: Generation\n\nFor new documentation:\n\n### Step 1: Define Scope\n\n```markdown\n## Generation Request\n\n**Type**: [README/Guide/API docs/Tutorial]\n**Audience**: [developers/users/admins]\n**Length target**: [~X words or sections]\n**Style profile**: [profile name or \"default\"]\n```\n\n### Step 2: Load Style (if available)\n\nIf a style profile exists:\n```bash\ncat .scribe/style-profile.yaml\n```\n\nApply voice, vocabulary, and structural guidelines.\n\n### Step 3: Draft Content\n\nFollow the 10 core principles above. For each section:\n\n1. Start with the essential information\n2. Add context only if it adds value\n3. Use specific examples\n4. Prefer prose over bullets\n5. End when information is complete (no summary padding)\n\n### Step 4: Run Slop Detector\n\n```\nSkill(scribe:slop-detector)\n```\n\nFix any findings before proceeding.\n\n### Step 5: Quality Gate\n\nVerify against checklist:\n- [ ] No tier-1 slop words\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40%\n- [ ] All claims grounded with specifics\n- [ ] No formulaic openers or closers\n- [ ] Authorial perspective present\n- [ ] No emojis (unless explicitly requested)\n\n## Mode: Remediation\n\nFor cleaning up existing content:\n\nLoad: `@modules/remediation-workflow.md`\n\n### Step 1: Analyze Current State\n\n```bash\n# Get slop score\nSkill(scribe:slop-detector) --target file.md\n```\n\n### Step 2: Section-by-Section Approach\n\nFor large files (>200 lines), edit incrementally:\n\n```markdown\n## Section: [Name] (Lines X-Y)\n\n**Current slop score**: X.X\n**Issues found**: [list]\n\n**Proposed changes**:\n1. [Change 1]\n2. [Change 2]\n\n**Before**:\n> [current text]\n\n**After**:\n> [proposed text]\n\nProceed? [Y/n/edit]\n```\n\n### Step 3: Preserve Intent\n\nNever change WHAT is said, only HOW. If meaning is unclear, ask.\n\n### Step 4: Re-verify\n\nAfter edits, re-run slop-detector to confirm improvement.\n\n## Docstring-Specific Rules\n\nWhen editing code comments:\n\n1. **ONLY modify docstring/comment text**\n2. **Never change surrounding code**\n3. **Use imperative mood** (\"Validate input\" not \"Validates input\")\n4. **Brief is better** - remove filler\n5. **Keep Args/Returns structure** if present\n\n## Module Reference\n\n- See `modules/generation-guidelines.md` for content creation patterns\n- See `modules/quality-gates.md` for validation criteria\n\n## Integration with Other Skills\n\n| Skill | When to Use |\n|-------|-------------|\n| slop-detector | After drafting, before approval |\n| style-learner | Before generation to load profile |\n| sanctum:doc-updates | For broader doc maintenance |\n\n## Exit Criteria\n\n- Content created or remediated\n- Slop score < 1.5 (clean rating)\n- Quality gate checklist passed\n- User approval received\n- No emojis present (unless specified)\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-doc-generator\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1778077305846\n}\n\nFile v1.0.1:modules/generation-guidelines.md\n\n---\nmodule: generation-guidelines\ncategory: writing-quality\ndependencies: []\nestimated_tokens: 400\n---\n\n# Documentation Generation Guidelines\n\nDetailed guidance for creating human-quality documentation.\n\n## Opening Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\"\n```\n\n### What to Use\n\n```markdown\nGOOD: \"scribe detects AI-generated content and helps you fix it.\"\nGOOD: \"Install with: npm install scribe\"\nGOOD: \"This guide covers installation, configuration, and common workflows.\"\n```\n\nStart with what it IS or what it DOES. Skip the preamble.\n\n## Section Structure\n\n### Length Targets\n\n| Section Type | Target Length |\n|--------------|---------------|\n| Overview | 50-100 words |\n| Feature description | 30-60 words |\n| Step in guide | 20-50 words |\n| API endpoint | 40-80 words |\n\n### Paragraph Guidance\n\nParagraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it.\n\nOne paragraph = one idea.\n\n## Line Wrapping\n\nWrap prose text at 80 characters per line using hybrid\nwrapping. This makes git diffs readable and mobile-friendly.\n\n### Rules (in priority order)\n\n1. Keep sentences on one line if they fit within 80 chars\n2. Break long sentences at clause boundaries (after `, ; :`)\n3. Break before conjunctions (`and`, `but`, `or`)\n4. Break at word boundaries as a last resort\n\n### Exempt from wrapping\n\nTables, code blocks, headings, frontmatter, HTML blocks,\nlink definitions, and image references stay on one line.\n\n### Example\n\n```markdown\nBEFORE:\nThe system validates all input against the schema and rejects\nmalformed requests with a 400 status code, logging the\nvalidation failure for debugging.\n\nAFTER:\nThe system validates all input against the schema\nand rejects malformed requests with a 400 status code,\nlogging the validation failure for debugging.\n```\n\n### Additional formatting rules\n\n- Blank line before and after every heading\n- ATX headings only (`#` style, never setext underlines)\n- Blank line before every list\n- Use reference-style links when inline links push past\n  80 chars\n\nFull specification: `Skill(leyline:markdown-formatting)`\n\n## Concrete Examples\n\nEvery feature claim needs a concrete example:\n\n```markdown\nBAD: \"The system provides flexible configuration options.\"\n\nGOOD: \"Configure via `scribe.yaml` or environment variables.\nSet `SCRIBE_STRICT=1` to treat warnings as errors.\"\n```\n\n## Trade-off Discussions\n\nInclude reasoning, not just conclusions:\n\n```markdown\nBAD: \"We recommend Redis for caching.\"\n\nGOOD: \"We chose Redis over Memcached for its sorted sets,\nwhich power the leaderboard. Memcached would use less memory\nbut require additional application logic.\"\n```\n\n## Ending Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In conclusion, we have covered the essential aspects of...\"\nBAD: \"We hope this guide has been helpful in your journey...\"\nBAD: \"Happy coding!\"\n```\n\n### What to Use\n\nEnd with the last useful piece of information. No summary paragraph unless the document exceeds 2000 words.\n\n```markdown\nGO\n\nArchive v1.0.0: 5 files, 8269 bytes\n\nFiles: modules/generation-guidelines.md (3924b), modules/quality-gates.md (2278b), modules/remediation-workflow.md (3430b), SKILL.md (5292b), _meta.json (142b)","readmeExcerpt":"Skill: doc-generator Owner: athola Summary: Generates or remediates documentation with human-quality writing Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:21:38.769Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:41:36.970Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:58:22.982Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:06:10.480Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:23:55.031Z | user ","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"## Generation Request\n\n**Type**: [README/Guide/API docs/Tutorial]\n**Audience**: [developers/users/admins]\n**Audience size**: [1 / small team / org / public]\n**Read frequency**: [once / weekly / per-invocation]\n**Thesis**: [one sentence the reader must walk away with]\n**Length target**: [~X words or sections]\n**Style profile**: [profile name or \"default\"]"},{"language":"bash","snippet":"cat .scribe/style-profile.yaml"},{"language":"text","snippet":"Skill(scribe:slop-detector)"},{"language":"bash","snippet":"# Get slop score\nSkill(scribe:slop-detector) --target file.md"},{"language":"markdown","snippet":"## Section: [Name] (Lines X-Y)\n\n**Current slop score**: X.X\n**Issues found**: [list]\n\n**Proposed changes**:\n1. [Change 1]\n2. [Change 2]\n\n**Before**:\n> [current text]\n\n**After**:\n> [proposed text]\n\nProceed? [Y/n/edit]"},{"language":"markdown","snippet":"BAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\""}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: doc-generator\ndescription: Generates or remediates documentation with human-quality writing\nversion: 1.9.8\ntriggers:\n  - documentation\n  - writing\n  - generation\n  - remediation\n  - polish\n  - creating new docs\n  - rewriting AI-generated content\n  - or applying style profiles\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/scribe\", \"emoji\": \"\\ud83e\\udd9e\", \"requires\": {\"config\": [\"night-market.scribe:shared\", \"night-market.scribe:slop-detector\"]}}}\nsource: claude-night-market\nsource_plugin: scribe\n---\n\n> **Night Market Skill** — ported from [claude-night-market/scribe](https://github.com/athola/claude-night-market/tree/master/plugins/scribe). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n# Documentation Generator\n\n**A document costs the sum of its readers' time. Earn that\ncost or cut.**\n\nGenerate documents that are grounded in specific claims, lead\nwith their thesis, and earn every sentence. Filler phrases like\n\"In today's fast-paced world\" and vague descriptors like\n\"thorough\" or \"complete\" without evidence are bloat. So is\nany sentence that does not carry, instance, bound, or repeat\nthe document's one takeaway.\n\nThis skill enforces both **sentence-level cleanliness** (no\nslop vocabulary, em dash overuse, or sycophantic openers) and\n**document-level economy** (thesis-first, every sentence\nearns weight, repetition reserved for the thesis). See\n`Skill(scribe:slop-detector)` module `document-economy.md`\nfor the full rubric.\n\n## Core Writing Principles\n\nUse active voice and an authorial perspective. Explain the\nreasoning behind technical choices (why this database, not\nthat one) rather than presenting neutral boilerplate. Use\nbullets sparingly for short, parallel summaries; convert\nmulti-line bullet waterfalls into prose so the reasoning\nsurvives.\n\n### Vocabulary and Style\n\nAvoid business jargon and linguistic tics like mirrored\nsentence structures or em dash overuse. Use the imperative\nmood for docstrings (\"Validate input\", not \"Validates\").\nDo not humanize non-living constructs (\"the code wants\",\n\"the function speaks to\").\n\n| Instead of | Use |\n|------------|-----|\n| fallback | default, secondary |\n| leverage | use |\n| utilize | use |\n| facilitate | help, enable |\n| comprehensive | thorough, complete |\n\n### 9. Limit Humanizing Constructs\n\n\"Lives under,\" \"speaks to,\" and similar phrases only make sense\nfor living things.\n\n### 10. Imperative Mood for Docstrings\n\n\"Validate\" not \"Validates\" (per PEP 257, pydocstyle, ruff).\n\n## Required TodoWrite Items\n\n1. `doc-generator:scope-defined` - Target files and type identified\n2. `doc-generator:style-loaded` - Style profile applied (if available)\n3. `doc-generator:content-drafted` - Initial content created\n4. `doc-generator:slop-scanned` - AI markers checked\n5. `doc-generator:quality-verified` - Principles checklist passed\n6. `doc-generator:user-approved` - Final approval received\n\n## Mode: Generatio"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-scribe-doc-generator\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787750498769\n}"},{"path":"modules/generation-guidelines.md","content":"---\nmodule: generation-guidelines\ncategory: writing-quality\ndependencies: []\nestimated_tokens: 400\n---\n\n# Documentation Generation Guidelines\n\nDetailed guidance for creating human-quality documentation.\n\n## Opening Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In today's fast-paced development environment, documentation plays a crucial role...\"\nBAD: \"Welcome to the comprehensive guide to...\"\nBAD: \"This document aims to provide an in-depth overview of...\"\n```\n\n### What to Use\n\n```markdown\nGOOD: \"scribe detects AI-generated content and helps you fix it.\"\nGOOD: \"Install with: npm install scribe\"\nGOOD: \"This guide covers installation, configuration, and common workflows.\"\n```\n\nStart with what it IS or what it DOES. Skip the preamble.\n\n## Section Structure\n\n### Length Targets\n\n| Section Type | Target Length |\n|--------------|---------------|\n| Overview | 50-100 words |\n| Feature description | 30-60 words |\n| Step in guide | 20-50 words |\n| API endpoint | 40-80 words |\n\n### Paragraph Guidance\n\nParagraphs should contain 2-4 sentences on a single topic. If a paragraph exceeds 5 sentences, split it.\n\nOne paragraph = one idea.\n\n## Line Wrapping\n\nWrap prose text at 80 characters per line using hybrid\nwrapping. This makes git diffs readable and mobile-friendly.\n\n### Rules (in priority order)\n\n1. Keep sentences on one line if they fit within 80 chars\n2. Break long sentences at clause boundaries (after `, ; :`)\n3. Break before conjunctions (`and`, `but`, `or`)\n4. Break at word boundaries as a last resort\n\n### Exempt from wrapping\n\nTables, code blocks, headings, frontmatter, HTML blocks,\nlink definitions, and image references stay on one line.\n\n### Example\n\n```markdown\nBEFORE:\nThe system validates all input against the schema and rejects\nmalformed requests with a 400 status code, logging the\nvalidation failure for debugging.\n\nAFTER:\nThe system validates all input against the schema\nand rejects malformed requests with a 400 status code,\nlogging the validation failure for debugging.\n```\n\n### Additional formatting rules\n\n- Blank line before and after every heading\n- ATX headings only (`#` style, never setext underlines)\n- Blank line before every list\n- Use reference-style links when inline links push past\n  80 chars\n\nFull specification: `Skill(leyline:markdown-formatting)`\n\n## Concrete Examples\n\nEvery feature claim needs a concrete example:\n\n```markdown\nBAD: \"The system provides flexible configuration options.\"\n\nGOOD: \"Configure via `scribe.yaml` or environment variables.\nSet `SCRIBE_STRICT=1` to treat warnings as errors.\"\n```\n\n## Trade-off Discussions\n\nInclude reasoning, not just conclusions:\n\n```markdown\nBAD: \"We recommend Redis for caching.\"\n\nGOOD: \"We chose Redis over Memcached for its sorted sets,\nwhich power the leaderboard. Memcached would use less memory\nbut require additional application logic.\"\n```\n\n## Ending Patterns\n\n### What to Avoid\n\n```markdown\nBAD: \"In conclusion, we have covered the essential aspects of...\"\nBAD: \"We hope this guide has been helpf"},{"path":"modules/quality-gates.md","content":"---\nmodule: quality-gates\ncategory: writing-quality\ndependencies: [TodoWrite]\nestimated_tokens: 300\n---\n\n# Documentation Quality Gates\n\nChecklists and thresholds for documentation quality validation.\n\n## Pre-Commit Checklist\n\nBefore finalizing any documentation:\n\n### Content Quality\n- [ ] No tier-1 slop words present\n- [ ] No vapid openers or closers\n- [ ] All claims grounded with specifics\n- [ ] Trade-offs explained, not just conclusions\n- [ ] Authorial perspective present (\"we chose\", \"our tests showed\")\n\n### Structure Quality\n- [ ] Em dash count < 3 per 1000 words\n- [ ] Bullet ratio < 40% (unless reference material)\n- [ ] Sentence length varies (SD > 5 words)\n- [ ] Paragraphs 2-5 sentences each\n- [ ] No five-paragraph essay structure\n\n### Style Quality\n- [ ] Consistent voice throughout\n- [ ] Appropriate formality for audience\n- [ ] Contractions used if informal tone\n- [ ] No emojis (unless explicitly requested)\n\n### Technical Quality\n- [ ] File paths verified to exist\n- [ ] Commands tested and working\n- [ ] Version numbers accurate\n- [ ] Links not broken\n\n## Metric Thresholds\n\n| Metric | Pass | Warning | Fail |\n|--------|------|---------|------|\n| Slop score | < 1.0 | 1.0-2.5 | > 2.5 |\n| Tier 1 words | 0 | 1-2 | 3+ |\n| Em dashes | < 3/1000 | 3-5/1000 | > 5/1000 |\n| Bullet ratio | < 30% | 30-50% | > 50% |\n| Sentence SD | > 8 | 5-8 | < 5 |\n\n## TodoWrite Integration\n\nTrack quality gate status:\n\n```\ndoc-generator:quality-content - PASS/FAIL\ndoc-generator:quality-structure - PASS/FAIL\ndoc-generator:quality-style - PASS/FAIL\ndoc-generator:quality-technical - PASS/FAIL\n```\n\n## Remediation Required\n\nIf any gate fails:\n\n1. Identify specific failures\n2. Propose fixes\n3. Apply fixes\n4. Re-run gates\n5. Repeat until pass\n\n## Exceptions\n\nDocument exceptions when gates are intentionally skipped:\n\n```markdown\n## Quality Gate Exception\n\n**Document**: API-reference.md\n**Gate**: bullet-ratio (58%)\n**Reason**: Reference documentation requires list format\n**Approved by**: [user]\n**Date**: [date]\n```\n\n## Integration with CI\n\nFor automated checking:\n\n```yaml\n# .github/workflows/docs-quality.yaml\n- name: Check documentation quality\n  run: |\n    scribe scan docs/\n    if [ $? -ne 0 ]; then\n      echo \"Documentation quality check failed\"\n      exit 1\n    fi\n```"},{"path":"modules/remediation-workflow.md","content":"---\nmodule: remediation-workflow\ncategory: writing-quality\ndependencies: [Edit, Read]\nestimated_tokens: 400\n---\n\n# Documentation Remediation Workflow\n\nStep-by-step process for cleaning up AI-generated content.\n\n## Phase 1: Assessment\n\nRun slop-detector and categorize findings:\n\n```markdown\n## Remediation Assessment: [filename]\n\n**Slop Score**: X.X\n**Word Count**: N\n\n### Critical (fix immediately)\n- [ ] Vapid opener at line 1\n- [ ] \"cannot be overstated\" at line 45\n\n### High Priority (fix in this pass)\n- [ ] 8 tier-1 slop words\n- [ ] Em dash density 7/1000\n\n### Medium Priority (fix if time)\n- [ ] Bullet ratio 55%\n- [ ] Sentence uniformity\n\n### Low Priority (defer)\n- [ ] Minor vocabulary substitutions\n```\n\n## Phase 2: User Approval for Major Changes\n\nIf remediation requires:\n- Deleting entire sections\n- Restructuring document flow\n- Changing technical content\n\nAlways ask:\n\n```markdown\n## Major Change Required\n\nThe opening section (lines 1-25) is primarily filler with no\ntechnical content. Options:\n\n1. **Delete entirely** - Start at line 26 with actual information\n2. **Condense to 2 sentences** - Keep intro but remove fluff\n3. **Rewrite** - New opening based on document purpose\n\nWhich approach? [1/2/3]\n```\n\n## Phase 3: Section-by-Section Editing\n\nFor documents over 200 lines, process in sections:\n\n```markdown\n## Section 1: Introduction (Lines 1-45)\n\n### Current State\n> In today's rapidly evolving technological landscape,\n> comprehensive documentation plays a pivotal role in\n> ensuring seamless developer experiences...\n\n### Issues\n- Vapid opener\n- \"comprehensive\", \"pivotal\", \"seamless\" (tier 1/2 words)\n- No concrete information in 45 words\n\n### Proposed Revision\n> scribe checks documentation for AI-generated patterns\n> and provides rewriting guidance. This guide covers\n> installation, configuration, and usage.\n\n### Changes\n- Removed opener cliche\n- Replaced with direct statement\n- Cut word count from 45 to 22\n\nProceed? [Y/n/edit]\n```\n\n## Phase 4: Vocabulary Sweep\n\nAfter structural fixes, sweep for remaining vocabulary:\n\n```bash\n# Quick vocabulary check\ngrep -nE '\\b(delve|embark|leverage|utilize|comprehensive)\\b' file.md\n```\n\nApply substitutions from shared module:\n\n| Line | Current | Replacement |\n|------|---------|-------------|\n| 23 | leverage | use |\n| 45 | utilize | use |\n| 67 | comprehensive | thorough |\n\n## Phase 5: Structural Polish\n\nFinal pass for structural issues:\n\n1. **Em dashes**: Replace excessive uses with commas/periods\n2. **Lists**: Convert bullet waterfalls to prose\n3. **Sentence variation**: Add short/long variety\n4. **Contractions**: Add if tone is informal\n\n## Phase 6: Verification\n\nRe-run slop-detector:\n\n```markdown\n## Remediation Results\n\n| Metric | Before | After | Change |\n|--------|--------|-------|--------|\n| Slop score | 4.8 | 1.2 | -75% |\n| Tier 1 words | 12 | 0 | -100% |\n| Em dash density | 7/1000 | 2/1000 | -71% |\n| Bullet ratio | 55% | 30% | -45% |\n\nStatus: CLEAN\n```\n\n## Docstring Mode\n\nFor code files, special handling:"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Generates or remediates documentation with human-quality writing Skill: doc-generator Owner: athola Summary: Generates or remediates documentation with human-quality writing Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:21:38.769Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:41:36.970Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:58:22.982Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:06:10.480Z | user Release v1.9.14 v1.9.13 | 2026-06-27T16:23:55.031Z | user","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1322,"uniquenessScore":58,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T06:58:18.069Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T06:58:18.069Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T10:53:18.405Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}