@bcelep/capint 0.4.2 → 0.7.0

package/skills/seo-audit/references/ai-writing-detection.md

@@ -0,0 +1,200 @@
+# AI Writing Detection
+
+Words, phrases, and punctuation patterns commonly associated with AI-generated text. Avoid these to ensure writing sounds natural and human.
+
+Sources: Grammarly (2025), Microsoft 365 Life Hacks (2025), GPTHuman (2025), Walter Writes (2025), Textero (2025), Plagiarism Today (2025), Rolling Stone (2025), MDPI Blog (2025)
+
+---
+
+## Contents
+- Em Dashes: The Primary AI Tell
+- Overused Verbs
+- Overused Adjectives
+- Overused Transitions and Connectors
+- Phrases That Signal AI Writing (Opening Phrases, Transitional Phrases, Concluding Phrases, Structural Patterns)
+- Filler Words and Empty Intensifiers
+- Academic-Specific AI Tells
+- How to Self-Check
+
+## Em Dashes: The Primary AI Tell
+
+**The em dash (—) has become one of the most reliable markers of AI-generated content.**
+
+Em dashes are longer than hyphens (-) and are used for emphasis, interruptions, or parenthetical information. While they have legitimate uses in writing, AI models drastically overuse them.
+
+### Why Em Dashes Signal AI Writing
+- AI models were trained on edited books, academic papers, and style guides where em dashes appear frequently
+- AI uses em dashes as a shortcut for sentence variety instead of commas, colons, or parentheses
+- Most human writers rarely use em dashes because they don't exist as a standard keyboard key
+- The overuse is so consistent that it has become the unofficial signature of ChatGPT writing
+
+### What To Do Instead
+| Instead of | Use |
+|------------|-----|
+| The results—which were surprising—showed... | The results, which were surprising, showed... |
+| This approach—unlike traditional methods—allows... | This approach, unlike traditional methods, allows... |
+| The study found—as expected—that... | The study found, as expected, that... |
+| Communication skills—both written and verbal—are essential | Communication skills (both written and verbal) are essential |
+
+### Guidelines
+- Use commas for most parenthetical information
+- Use colons to introduce explanations or lists
+- Use parentheses for supplementary information
+- Reserve em dashes for rare, deliberate emphasis only
+- If you find yourself using more than one em dash per page, revise
+
+---
+
+## Overused Verbs
+
+| Avoid | Use Instead |
+|-------|-------------|
+| delve (into) | explore, examine, investigate, look at |
+| leverage | use, apply, draw on |
+| optimise | improve, refine, enhance |
+| utilise | use |
+| facilitate | help, enable, support |
+| foster | encourage, support, develop, nurture |
+| bolster | strengthen, support, reinforce |
+| underscore | emphasise, highlight, stress |
+| unveil | reveal, show, introduce, present |
+| navigate | manage, handle, work through |
+| streamline | simplify, make more efficient |
+| enhance | improve, strengthen |
+| endeavour | try, attempt, effort |
+| ascertain | find out, determine, establish |
+| elucidate | explain, clarify, make clear |
+
+---
+
+## Overused Adjectives
+
+| Avoid | Use Instead |
+|-------|-------------|
+| robust | strong, reliable, thorough, solid |
+| comprehensive | complete, thorough, full, detailed |
+| pivotal | key, critical, central, important |
+| crucial | important, key, essential, critical |
+| vital | important, essential, necessary |
+| transformative | significant, important, major |
+| cutting-edge | new, advanced, recent, modern |
+| groundbreaking | new, original, significant |
+| innovative | new, original, creative |
+| seamless | smooth, easy, effortless |
+| intricate | complex, detailed, complicated |
+| nuanced | subtle, complex, detailed |
+| multifaceted | complex, varied, diverse |
+| holistic | complete, whole, comprehensive |
+
+---
+
+## Overused Transitions and Connectors
+
+| Avoid | Use Instead |
+|-------|-------------|
+| furthermore | also, in addition, and |
+| moreover | also, and, besides |
+| notwithstanding | despite, even so, still |
+| that being said | however, but, still |
+| at its core | essentially, fundamentally, basically |
+| to put it simply | in short, simply put |
+| it is worth noting that | note that, importantly |
+| in the realm of | in, within, regarding |
+| in the landscape of | in, within |
+| in today's [anything] | currently, now, today |
+
+---
+
+## Phrases That Signal AI Writing
+
+### Opening Phrases to Avoid
+- "In today's fast-paced world..."
+- "In today's digital age..."
+- "In an era of..."
+- "In the ever-evolving landscape of..."
+- "In the realm of..."
+- "It's important to note that..."
+- "Let's delve into..."
+- "Imagine a world where..."
+
+### Transitional Phrases to Avoid
+- "That being said..."
+- "With that in mind..."
+- "It's worth mentioning that..."
+- "At its core..."
+- "To put it simply..."
+- "In essence..."
+- "This begs the question..."
+
+### Concluding Phrases to Avoid
+- "In conclusion..."
+- "To sum up..."
+- "By [doing X], you can [achieve Y]..."
+- "In the final analysis..."
+- "All things considered..."
+- "At the end of the day..."
+
+### Structural Patterns to Avoid
+- "Whether you're a [X], [Y], or [Z]..." (listing three examples after "whether")
+- "It's not just [X], it's also [Y]..."
+- "Think of [X] as [elaborate metaphor]..."
+- Starting sentences with "By" followed by a gerund: "By understanding X, you can Y..."
+
+---
+
+## Filler Words and Empty Intensifiers
+
+These words often add nothing to meaning. Remove them or find specific alternatives:
+
+- absolutely
+- actually
+- basically
+- certainly
+- clearly
+- definitely
+- essentially
+- extremely
+- fundamentally
+- incredibly
+- interestingly
+- naturally
+- obviously
+- quite
+- really
+- significantly
+- simply
+- surely
+- truly
+- ultimately
+- undoubtedly
+- very
+
+---
+
+## Academic-Specific AI Tells
+
+| Avoid | Use Instead |
+|-------|-------------|
+| shed light on | clarify, explain, reveal |
+| pave the way for | enable, allow, make possible |
+| a myriad of | many, numerous, various |
+| a plethora of | many, numerous, several |
+| paramount | very important, essential, critical |
+| pertaining to | about, regarding, concerning |
+| prior to | before |
+| subsequent to | after |
+| in light of | because of, given, considering |
+| with respect to | about, regarding, for |
+| in terms of | regarding, for, about |
+| the fact that | that (or rewrite sentence) |
+
+---
+
+## How to Self-Check
+
+1. Read your text aloud. If phrases sound unnatural in speech, revise them
+2. Ask: "Would I say this in a conversation with a colleague?"
+3. Check for repetitive sentence structures
+4. Look for clusters of the words listed above
+5. Ensure varied sentence lengths (not all similar length)
+6. Verify each intensifier adds genuine meaning

package/skills/seo-audit/references/international-seo.md

@@ -0,0 +1,230 @@
+# International SEO: Evidence & Sources
+
+Detailed evidence backing the International SEO & Localization section of the SEO Audit skill. Organized by topic with source URLs and key quotes.
+
+---
+
+## Hreflang
+
+### Placement Methods
+
+Google supports three equivalent methods: HTML `<link>` in `<head>`, HTTP `Link` headers, and XML sitemap `<xhtml:link>` elements. Google confirmed no method is prioritized over another.
+
+Google combines signals from both HTML and sitemaps. If the same language-region pair points to different URLs across methods, Google drops that pair rather than guessing.
+
+- [Google Search Central: Localized Versions](https://developers.google.com/search/docs/specialty/international/localized-versions)
+- [SEJ: Google Combines Hreflang Signals](https://www.searchenginejournal.com/google-combines-hreflang-signals-from-html-sitemaps/389219/)
+
+### Reciprocal Requirement
+
+Google's docs: "If page X links to page Y, page Y must link back to page X. If not, those annotations may be ignored or not interpreted correctly."
+
+Every page must include itself (self-referencing) in the hreflang set. Missing self-referencing is the #1 error found by Semrush audits. A study of 374,756 domains found 67% of hreflang implementations had issues.
+
+- [Google Search Central: Localized Versions](https://developers.google.com/search/docs/specialty/international/localized-versions)
+- [Semrush: 9 Common Hreflang Errors](https://www.semrush.com/blog/hreflang-errors/)
+- [SE Land: 31% of International Websites Contain Hreflang Errors](https://searchengineland.com/study-31-of-international-websites-contain-hreflang-errors-395161)
+
+### x-default
+
+Introduced April 2013. Designates the fallback page for users whose language/region matches no declared variant. Can point to the same URL as one of the language-specific alternates. Must be included in the complete set of annotations on every variant page.
+
+- [Google Blog: x-default hreflang](https://developers.google.com/search/blog/2013/04/x-default-hreflang-for-international-pages)
+- [Google Blog: How x-default can help you (2023)](https://developers.google.com/search/blog/2023/05/x-default)
+
+### Language & Region Codes
+
+Language: ISO 639-1 (2-letter). Region: ISO 3166-1 Alpha 2 (2-letter). Format: `language[-script][-region]`.
+
+You cannot specify a region code alone. Common mistakes: `en-UK` (should be `en-GB`), `es-419` (not ISO 3166-1). A study found 8.9% of sites using hreflang contain invalid language codes.
+
+- [Google Search Central: Localized Versions](https://developers.google.com/search/docs/specialty/international/localized-versions)
+- [SE Land: 31% Study](https://searchengineland.com/study-31-of-international-websites-contain-hreflang-errors-395161)
+
+### Hreflang at Scale (20+ locales)
+
+With 20 locales, HTML `<head>` hreflang adds ~1.5KB per page for zero user benefit. Sitemap-based hreflang has zero runtime performance impact. `<xhtml:link>` child elements do NOT count toward the 50,000 URL sitemap limit (only `<loc>` elements count).
+
+John Mueller recommends focusing hreflang on pages receiving wrong-language traffic, not every page: "I wouldn't do it for any of the other pages of the site because it's so complex & hard to manage."
+
+- [SERoundtable: Child Elements Don't Count](https://www.seroundtable.com/google-child-elements-dont-count-towards-sitemap-url-limit-34377.html)
+- [SERoundtable: Where To Focus Hreflang](https://www.seroundtable.com/using-hreflang-34127.html)
+- [Yoast: hreflang Ultimate Guide](https://yoast.com/hreflang-ultimate-guide/)
+
+### Google vs Bing
+
+Bing treats hreflang as a "weak signal." Bing relies on `content-language` meta tag, HTML `lang` attribute, ccTLDs, and server location. Yandex supports hreflang like Google.
+
+For both engines: implement hreflang (Google/Yandex) + `<html lang="...">` + `<meta http-equiv="content-language">` (Bing).
+
+- [Digital Ready Marketing: Bing Doesn't Use Hreflang](https://digitalreadymarketing.com/bing-doesnt-use-hreflang-annotation-what-does-it-use/)
+- [Yoast: hreflang Ultimate Guide](https://yoast.com/hreflang-ultimate-guide/)
+
+---
+
+## Canonicalization & i18n
+
+### Self-Referencing Canonicals
+
+Each locale page must canonical to itself. John Mueller: "Don't use a rel=canonical across languages/countries, only use it on a per-country/language basis."
+
+Google's docs: "Specify a canonical page in the same language, or the best possible substitute language if a canonical doesn't exist for the same language."
+
+- [John Mueller: hreflang canonical](https://johnmu.com/hreflang-canonical/)
+- [Google: Consolidate Duplicate URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)
+
+### Canonical Overrides Hreflang
+
+Mueller: "If your canonical is pointing somewhere else, Google will follow that and ignore your hreflang annotation." The canonical URL must be one of the URLs in the hreflang set, or all hreflang markup is ignored.
+
+Google also states: "Google prefers URLs that are part of hreflang clusters for canonicalization" -- when signals align, hreflang strengthens canonical selection.
+
+- [John Mueller: hreflang canonical](https://johnmu.com/hreflang-canonical/)
+- [SEJ: Hreflang Tags Are Hints](https://www.searchenginejournal.com/google-reminds-that-hreflang-tags-are-hints-not-directives/546428/)
+- [Google: Consolidate Duplicate URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls)
+
+### Near-Duplicate Regional Variants
+
+Mueller (2023 Office Hours): "If the content is completely the same, and we can't tell any difference, then for simplicity and user experience we may just show one version -- even if hreflang is present."
+
+Google's duplicate detection runs BEFORE hreflang evaluation. To keep both versions indexed, you need substantive content differences beyond currency symbols.
+
+- [International Web Mastery: Same-Language Duplicate Pages](https://internationalwebmastery.com/blog/how-google-handles-canonicalization-of-same-language-duplicate-near-duplicate-pages/)
+- [Google: Managing Multi-Regional Sites](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)
+
+### Pagination Across Locales
+
+Google: "Don't use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL." Each paginated page in each locale gets self-referencing canonical. `rel="next/prev"` deprecated March 2019.
+
+- [Google: Pagination Best Practices](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading)
+
+---
+
+## International Sitemaps
+
+### Structure
+
+Each `<url>` entry includes `<xhtml:link>` alternates for every locale. Requires `xmlns:xhtml="http://www.w3.org/1999/xhtml"` namespace.
+
+Split sitemaps by content type, not by locale. Splitting by locale creates maintenance problems because every locale sitemap must reference every other locale (reciprocal requirement).
+
+- [Google Search Central: Localized Versions](https://developers.google.com/search/docs/specialty/international/localized-versions)
+- [Lumar: How Google Handles Hreflang](https://www.lumar.io/office-hours/hreflang/)
+
+### Size Limits
+
+50,000 URLs / 50MB uncompressed per sitemap. Only `<loc>` elements count toward the 50K limit. But with 20 hreflang alternates per entry, the 50MB file size limit becomes the bottleneck. Plan for 2,000-5,000 URLs per sitemap when using full hreflang.
+
+- [Google: Build and Submit a Sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap)
+- [SERoundtable: Sitemap 50,000 Limit](https://www.seroundtable.com/google-sitemap-50-000-limit-based-on-location-urls-not-alternative-urls-33843.html)
+
+### Submission
+
+Submit the sitemap index in Search Console AND reference it in robots.txt. Individual child sitemaps can be submitted separately for per-sitemap reporting.
+
+- [Google: Build and Submit a Sitemap](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap)
+
+### Next.js Caveat
+
+Next.js `alternates.languages` does NOT automatically include a self-referencing `<xhtml:link>` for the `<loc>` URL. You must explicitly include the `<loc>` URL's own language in the `languages` object.
+
+- [Next.js Docs: sitemap.xml](https://nextjs.org/docs/app/api-reference/file-conventions/metadata/sitemap)
+
+---
+
+## URL Structure
+
+### Strategies Compared
+
+Google treats subdirectories and subdomains equivalently. Mueller: "From our point of view...they say subdomains and subdirectories are essentially equivalent."
+
+URL parameters (`?lang=en`) are explicitly "Not recommended" per Google docs.
+
+- [Google: Managing Multi-Regional Sites](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)
+
+### Default Language
+
+Mueller recommends: set `/` as x-default, put each language in its own prefix. Without marking `/` as x-default, "to Google it can look like '/' is a separate page from the others."
+
+- [Google Blog: x-default](https://developers.google.com/search/blog/2023/05/x-default)
+- [Google Blog: Creating the Right Homepage](https://developers.google.com/search/blog/2014/05/creating-right-homepage-for-your)
+
+### Content Negotiation / IP Redirects
+
+Google strongly advises against locale-adaptive pages. Googlebot crawls from US IPs and does not send Accept-Language headers. Separate URLs + hreflang are required.
+
+- [Google: Locale-Adaptive Pages](https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages)
+
+### Trailing Slash Consistency
+
+Mueller: trailing slash is "a significant part of the URL and will change the URL if it's there or not." Pick one format for all locale paths, internal links, canonicals, hreflang, and sitemaps.
+
+Mueller (2025): "Consistency is the biggest technical SEO factor."
+
+- [SERoundtable: Consistency Is The Biggest Technical SEO Factor](https://www.seroundtable.com/google-consistency-seo-40427.html)
+
+### Search Console Geotargeting
+
+The International Targeting report is deprecated. Google now relies entirely on hreflang, content language analysis, and linking patterns. You can add subdirectory properties for per-locale reporting.
+
+- [Google Support: International Targeting Deprecated](https://support.google.com/webmasters/answer/12474899?hl=en)
+
+### Framework Locale Modes
+
+Use `localePrefix: 'always'` (next-intl) or equivalent. Never hide locale from URLs -- Google needs unique URLs per language. Using `'never'` mode disables alternate links entirely.
+
+- [next-intl: Routing Configuration](https://next-intl.dev/docs/routing/configuration)
+- [Next.js Discussion #18419](https://github.com/vercel/next.js/discussions/18419)
+
+---
+
+## Content Quality Across Locales
+
+### Auto-Translated Content (2025 Stance)
+
+Google removed longstanding guidance advising against auto-translated content in mid-2025. Current stance: "Our policies do not strictly define content that has been translated by AI as spam." The scaled content abuse policy mentions translation as a possible vector, but does not ban it.
+
+Reddit scaled AI translations to 35+ languages with Google's knowledge. The key distinction is intent and quality, not the method.
+
+- [Google Spam Policies](https://developers.google.com/search/docs/essentials/spam-policies)
+- [Glenn Gabe: Auto-Translating Content](https://www.gsqi.com/marketing-blog/auto-translating-content-google-scaled-content-abuse/)
+- [SE Land: Reddit AI Translations](https://searchengineland.com/google-comments-on-reddits-use-of-ai-to-translate-its-pages-456908)
+
+### Thin Locale Pages
+
+Google: "Localized versions of a page are only considered duplicates if the main content of the page remains untranslated." Pages with only translated boilerplate get clustered as duplicates.
+
+Do NOT use noindex for unwanted locale pages (wastes crawl budget). Do NOT canonical cross-locale (conflicts with hreflang). Best approach: don't create locale pages you can't make genuinely helpful.
+
+- [Google: Localized Versions](https://developers.google.com/search/docs/specialty/international/localized-versions)
+- [Google: Crawl Budget Management](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget)
+
+### Helpful Content System Impact
+
+Merged into core ranking March 2024. Site-wide signal: "any content -- not just unhelpful content -- on sites determined to have relatively high amounts of unhelpful content overall is less likely to perform well in Search."
+
+Low-quality translated pages can drag down the entire site. This is the strongest argument against creating locale pages that aren't genuinely helpful.
+
+- [Google Blog: Helpful Content Update](https://developers.google.com/search/blog/2022/08/helpful-content-update)
+- [Amsive: What Changed in 2024](https://www.amsive.com/insights/seo/googles-helpful-content-update-ranking-system-what-happened-and-what-changed-in-2024/)
+
+### Partial Translation
+
+Google: "Translating only the boilerplate text of your pages while keeping the bulk of your content in a single language...can create a bad user experience." Google uses visible content (not lang attribute) to determine page language.
+
+Translate ALL content on a page if you create a locale version. Untranslated metadata (title, description) in the wrong language reduces CTR.
+
+- [Google: Managing Multi-Regional Sites](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)
+
+### Crawl Budget
+
+Only a concern for 1M+ pages or 10K+ pages changing daily. But alternate URLs (hreflang targets) do consume crawl budget. Broken hreflang links waste budget AND invalidate signals.
+
+- [Google: Crawl Budget Management](https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget)
+- [Google Blog: Crawl Budget](https://developers.google.com/search/blog/2017/01/what-crawl-budget-means-for-googlebot)
+
+### Locale-Specific Signals
+
+Google identifies audience via: "local addresses and phone numbers on the pages, the use of local language and currency, links from other local sites, or signals from your Business Profile."
+
+- [Google: Managing Multi-Regional Sites](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)

package/skills/sequential-thinking/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: sequential-thinking
+description: 当复杂问题需要系统性逐步推理时使用。适用于多阶段分析、设计规划、问题分解，或初始范围不明确且需要受控收敛的任务。
+license: MIT
+---
+
+# Sequential Thinking
+
+这个 skill 的核心不是“多写几段 thought”，而是让 AI 在复杂问题里**持续推进、允许修正，并最终收敛成结论**。CLI 只是执行载体；skill 本身负责定义什么时候该进入这种思考方式，以及如何避免把顺序思考退化成松散输出。
+
+## Mission
+
+这个 skill 用来把复杂问题处理成一个**有边界、可修正、可复核的推理过程**：
+
+- 先澄清问题，而不是急着给答案
+- 在推进过程中允许修正和调整判断
+- 在复杂度上升时比较替代路径，而不是单线硬推
+- 在有限步数内收敛成结论与建议
+- 最后保留可回放的推理轨迹
+
+它解决的不是“不会想”，而是“想得太散、太早下结论、太难复核”。
+
+## Core Capabilities
+
+- **迭代推进**: 把复杂问题拆成连续步骤，而不是试图一口气得到完整答案
+- **动态修正**: 当新证据出现时，允许回看并修正前面的判断
+- **分支比较**: 当存在替代路径时，允许先比较再收敛
+- **上下文保持**: 在多步推理中维持清晰的问题边界与目标
+- **结论收束**: 最终必须形成判断，而不是无限发散
+
+## When to Use
+
+### 核心判断规则
+
+> **模型能力决定基线，任务复杂度决定是否升级。**
+
+
+| 模型能力          | 简单任务            | 复杂任务            |
+| ------------- | --------------- | --------------- |
+| **有思维链（CoT）** | 自然 CoT 即可       | 调用 ST CLI       |
+| **无思维链**      | **必须调用 ST CLI** | **必须调用 ST CLI** |
+
+
+### 判断口诀
+
+> **"无 CoT → 必须用 ST**
+> **有 CoT → 复杂才用 ST"**
+
+### 必须调用 CLI 的场景
+
+
+| 场景           | 判断标准                 | 为什么需要 CLI           |
+| ------------ | -------------------- | ------------------- |
+| **无 CoT 模型** | 当前模型不支持思维链输出         | 必须依赖外部工具组织推理        |
+| **修正前提**     | 推理过程中发现前面判断错了，需要回头修正 | CLI 会话保留历史，支持回看修正   |
+| **多方案比较**    | 需要在 2+ 个候选方案之间做权衡决策  | `branch` 模式专为分支比较设计 |
+| **可回放轨迹**    | 需要留下可审计、可复现的推理过程     | CLI 支持生成 replay 文档  |
+| **复杂收敛**     | 问题需要 > 5 步才能收敛到结论    | 强制步数限制防止无限发散        |
+
+
+### 有 CoT 时可直接用自然 CoT 的场景
+
+
+| 场景        | 判断标准             | 为什么不需要 CLI           |
+| --------- | ---------------- | -------------------- |
+| **单向推理**  | 不需要回头修正，线性推进     | 模型自然输出即可             |
+| **简单分析**  | 问题边界清晰、步骤 < 5    | 不需要复杂工具辅助            |
+| **快速决策**  | 只需结论，不需要可回放轨迹    | CoT 足够表达推理           |
+| **探索性思考** | 还在发散阶段，不确定是否需要收敛 | 先用 CoT 探索，再决定是否用 CLI |
+
+
+### 决策树
+
+```mermaid
+flowchart TD
+    A[需要多步推理?] -->|否| Z[直接回答]
+    A -->|是| B{模型有 CoT?}
+    B -->|否| CLI[必须调用 ST CLI]
+    B -->|是| C{任务复杂?}
+    C -->|简单: 步骤 < 5, 无修正| CoT[自然 CoT]
+    C -->|复杂: 修正/比较/回放| CLI
+```
+
+
+
+### 不适用场景
+
+- 简单事实查询
+- 单步即可完成的任务
+- 路径已经非常明确、无需多步推演的问题
+- 纯头脑风暴且暂时不要求收敛的场景
+
+## Working Philosophy
+
+- **先找主问题，再找答案**：不要把现象描述误当作根因定位
+- **允许修正，而不是硬撑前提**：前面想错了，就回头修，不要带着错误前提继续推进
+- **先消除复杂度，再堆解决方案**：优先识别主矛盾，而不是抢着给补丁
+- **每一步只推进一步**：当前步只表达当前判断，不重复整套背景
+- **最终必须落到结论**：不能把“我还能继续想”当作默认出口
+
+## Installation & Runtime Model
+
+这个 skill 面向 agent 交付思考方式与调用约束；CLI 通过 npm 分发。
+
+在使用前，应先确保本地已安装对应 CLI：
+
+```bash
+npm install -g sequential-thinking-cli
+
+# 或
+pnpm add -g sequential-thinking-cli
+```
+
+安装后，使用 `sthink` 作为命令入口。
+
+## CLI Contract
+
+本 skill 不再要求 AI 手写 thought JSON。执行层通过 CLI 主路径动作完成：
+
+- `start`
+- `step`
+- `replay`
+
+### `start`
+
+只接受四个输入：
+
+- `name`
+- `goal`
+- `mode`
+- `totalSteps`
+
+约束：
+
+- `mode` 仅允许 `explore`、`branch`、`audit`
+- `totalSteps` 仅允许 `5` 或 `8`
+
+如果你不确定该选哪种模式，默认用 `explore`。只有在任务明显是在比较候选路径时才用 `branch`；只有在任务明显是在审查既有判断时才用 `audit`。
+
+### `step`
+
+只接受：
+
+- `content`
+
+其余上下文应由 runtime 自动恢复并注入。
+
+### `replay`
+
+用于读取已完成会话并生成 replay 文档；如需要，可额外导出到当前目录。
+
+## Recommended Workflow
+
+```text
+1. 先判断问题是否真的需要 sequential-thinking，而不是默认套用。
+2. 如需要，先安装或确认本地已有 npm CLI。
+3. 用 `sthink start` 给出 `name`、`goal`、`mode`、`totalSteps`。
+4. 用 `sthink step` 逐步推进，每一步只写当前推进内容。
+5. 当出现新证据时，允许修正，而不是硬撑旧判断。
+6. 到收敛阶段时，必须输出结论、风险与下一步建议。
+7. 完成后按需使用 `sthink replay` 生成与导出回放文档。
+```
+
+## Examples
+
+以下示例不是为了让你回去手写 JSON，而是为了说明这种 skill 真正有价值的地方：**如何推进、如何修正、如何收敛**。
+
+### Example 1: 基础推演
+
+```bash
+sthink start --name "query-diagnosis" --goal "定位查询性能下降的主因" --mode explore --totalSteps 5
+sthink step --sessionPath "<session-path>" --content "先不要急着选优化手段。需要先把问题拆成几层：是单条 SQL 退化、接口级 N+1，还是更上层的调用放大。若根因没分清，后面的缓存、索引、重写都可能只是补丁。"
+sthink step --sessionPath "<session-path>" --content "从查询日志看，用户详情接口在一次请求里触发了大量重复读取，已经出现明显的 N+1 信号。但还不能直接下结论，因为重复查询也可能只是症状；需要继续确认慢点究竟来自“查询次数过多”，还是“某条关键查询本身很慢”。因此总步数上调一档。"
+sthink step --sessionPath "<session-path>" --content "结论可以收敛了：主因是列表页批量加载时触发的 N+1，次因是关联字段缺少索引放大了单次查询成本。优化顺序应该先消除 N+1，再补索引验证尾延迟；这样既先打掉主矛盾，也避免一上来引入缓存复杂度。"
+```
+
+### Example 2: 修正前提
+
+```bash
+sthink step --sessionPath "<session-path>" --content "回看 profiling 结果后，前面的判断需要修正：真正拖垮接口的不是 N+1 本身，而是关联列缺少索引，导致每次关联查询都在放大全表扫描成本。也就是说，N+1 仍然存在，但它不是第一性瓶颈，优先级应该后移。"
+```
+
+### Example 3: 复杂变更拆解
+
+```bash
+sthink start --name "change-impact-analysis" --goal "拆解复杂变更的影响与优先级" --mode explore --totalSteps 5
+sthink step --sessionPath "<session-path>" --content "用户一次性提出了多项规则修改，不该把它们当成同一种改动处理。先拆开看：有的是机制原则调整，有的是数值平衡，有的是接口语义变化，还有的是文档与实现脱节。如果不先分型，后面会把“该改 ADR 的”“该改设计文档的”“该补代码契约的”混成一锅。"
+sthink step --sessionPath "<session-path>" --content "先做影响矩阵。机制原则类改动通常会回流到 ADR 和 System Design；数值平衡会影响规则表、配置与测试基线；接口语义变化最危险，因为它会悄悄破坏调用方的假设。这里最该警惕的不是改动数量，而是有没有改到“被多个模块默认依赖、但文档里没写清楚”的隐性契约。"
+sthink step --sessionPath "<session-path>" --content "可以收敛了：先处理那些会改变系统边界或调用语义的项，再处理数值与体验层面的项。顺序上应优先修正文档与契约，再讨论平衡性；否则后续所有实现和评审都会建立在漂移的前提上。结论不是“先改最显眼的”，而是“先修最容易污染系统认知的”。"
+```
+
+### Example 4: 分支比较
+
+```bash
+sthink start --name "performance-tradeoff" --goal "比较缓存止血与查询优化的优先级" --mode branch --totalSteps 5
+sthink step --sessionPath "<session-path>" --content "方案 A：先引入缓存削峰。好处是见效快、对接口层侵入小，适合先止血；坏处是会把问题从“数据库慢”转成“缓存一致性与失效策略复杂”，如果根因其实是查询设计不合理，这条路容易把偶然复杂度永久留在系统里。与此同时，方案 B：直接做索引优化和查询重写。好处是从根上消除瓶颈，长期结构更干净；代价是需要更仔细验证写入放大、锁竞争和回归风险。这条路更慢，但如果业务模型稳定，通常比提前上缓存更符合简单优先的原则。"
+```
+
+## Storage & Export Boundary
+
+- runtime 会自动保存会话状态与步骤记录
+- 完成态可生成 replay 文档
+- `replay` 支持导出到当前目录，便于审阅与复用
+
+## Heuristic Reminders
+
+以下提醒是启发式问题，不是硬约束。真正重要的是：它们能帮助你减少空转，逼近结论。
+
+- **问题定义提醒**: 你现在是在描述现象，还是在定位根因？
+- **证据提醒**: 当前判断基于事实、观察结果，还是基于猜测与假设？
+- **边界提醒**: 当前问题影响的是局部模块、单系统，还是跨系统结构？
+- **复杂度提醒**: 你是在消除本质复杂度，还是在增加偶然复杂度？
+- **收敛提醒**: 当前是否已经足够形成结论，还是仍在无效发散？
+
+## Tips
+
+- 不要再手写 thought JSON；让 CLI runtime 负责节奏、落盘与 replay
+- 不要把 sequential-thinking 当成默认模式，只在真正需要多步收敛时调用
+- 如果不确定模式，先用 `explore`
+- `step` 的 `content` 只表达当前推进内容，不要重复补全系统上下文
+- 如果发现前提错了，就明确修正，不要硬撑
+- 到收敛阶段时，应明确输出结论、风险和下一步动作
+- 只有已完成会话才能执行 `replay`
+