[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CTMSPW65SH5CXM4RVT20PB":3,"skill-same:01M7CTMSPW65SH5CXM4RVT20PB":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":14,"repositoryHtmlUrl":28,"repositoryHomepageUrl":29,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":6,"updatedAt":32,"install":33,"resources":46},"01M7CTMSPW65SH5CXM4RVT20PB","why",null,"Investigate why code, a design or a decision is the way it is, and return a cited answer that separates what was found from what is inferred and what is unknown. Reads the decision records, git history, pull request bodies and reviews, and issues, and any other evidence source the session offers. Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds, and before changing code whose reason is not visible. For how the code behaves at runtime, use discover:how.","lyngon\u002Fdevkit","lyngon","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F70928830?v=4","01M7CTHVD57GT6VR6Y5SES6GKR","Lyngon","01M7CTHVDSGGTXSY9S7M5MA8RA",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscover\u002Fskills\u002Fwhy\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: why\ndescription: Investigate why code, a design or a decision is the way it is, and return a cited answer that separates what was found from what is inferred and what is unknown. Reads the decision records, git history, pull request bodies and reviews, and issues, and any other evidence source the session offers. Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds, and before changing code whose reason is not visible. For how the code behaves at runtime, use discover:how.\nargument-hint: \"\u003Cthe question, naming the code, design or decision it is about>\"\n---\n\n# Why\n\nInvestigate the motivation and intent behind code.\n\nCompanion to `discover:how`.\n`discover:how` answers what the code does and how it works.\nThis skill answers what forces led to its shape.\n\n## Operating posture\n\nOperate as a **careful, cautious, and precise investigator**.\nBe honest about what you know vs what you're inferring.\nRead `references\u002Fepistemics.md` for the full confidence framework and phrasing guide.\nWhoever writes the answer, you or a synthesizer, must follow it.\n\n## Understand the target and the question\n\nParse what the user is asking.\nThe **target** is usually a chunk of code, a pattern, a feature, or a named design decision.\nThe **question** is usually a design rationale, a tradeoff, a motivating edge case, an external constraint, dead code, or a broad history sweep.\n\nIf the target is vague (\"why do we do it this way?\" with no clear referent), make your best guess from conversation context (open files, recent edits, cursor location, what was just discussed).\nState your interpretation briefly so the user can redirect if you're off, then proceed.\n\n## Establish the code anchor\n\nBefore investigating, anchor the investigation in concrete code.\nYou need:\n\n- The relevant file path(s) and line range(s)\n- The key symbols (function names, class names, constants)\n- An initial commit list. The last few commits touching the target.\n- PR numbers from merge commits (pattern `(#1234)` or `Merge pull request #1234` in the subject line)\n- The decision records that name the target, in `docs\u002Fdecisions\u002F` at the root or inside a package\n\nBuild this inline.\n\n```bash\n# Blame target lines for last-touch commits\ngit blame -L \u003Cstart>,\u003Cend> \u003Cfile>\n\n# Full file history, with patches, through renames\ngit log --follow -p -- \u003Cfile>\n\n# Last N commits touching the file, PR numbers visible\ngit log --oneline -20 -- \u003Cfile>\n\n# Extract PR numbers from a commit message\ngit log -1 --format=%B \u003Ccommit>\n```\n\nPull PR bodies and discussion via `gh` for any substantive commits:\n\n```bash\ngh pr view \u003Cnumber> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews\n```\n\nCapture this as seed context (file paths, symbols, commits, PR numbers, linked ticket IDs, decision records).\n\n## Investigate\n\n### Discovery\n\nList the evidence sources this session can reach, one coverage map over seven evidence categories:\n\n1. Source control history\n2. Issue \u002F ticket tracker\n3. Long-form documents\n4. Real-time team chat\n5. Infrastructure observability\n6. Error \u002F exception tracking\n7. Product analytics warehouse\n\nSource control is always available through git, and its pull requests through `gh`.\nThe issue tracker is GitHub Issues, also through `gh`.\nFor anything else, list the MCP servers the session offers and map each one to one evidence category, using the MCP name, server instructions, tool names, and resource descriptors.\nIf an MCP could fit more than one category, choose the one matching its primary evidence.\nRecord ambiguous cases in the coverage map.\nAn MCP that holds none of these kinds of evidence, such as one for a build tool or a browser, is not a source.\n\nAim for a complete **coverage map**, not a minimal one.\nDocument the null, don't skip the search.\nA source you could not reach (`gh` missing or not signed in, no network, an MCP that refused) is a gap: report it with the error you got, never as \"nothing found\".\n\n### One pass, when git and GitHub are the only sources\n\nWhen no MCP maps to a category, run the investigation yourself, with no investigators and no synthesizer.\n\n1. Follow `references\u002Fsources\u002Fcode-archaeology.md`, then `references\u002Fsources\u002Fgithub-issues.md`.\n2. Run the queries of `references\u002Fsources\u002Fincident-postmortem.md` inside both **if the target code looks defensive** (null checks, retry logic, timeout handling, rate limiting, feature flags, egress guards, OOM handlers).\n3. Work to the sections \"Operating posture\", \"Investigation instructions\" and \"Epistemic discipline\" of `references\u002Finvestigator-prompt.md`: quote, record every query, keep the contradictions. Both sources are yours, so follow a reference from one into the other yourself.\n4. Write the answer in the output format of `references\u002Fsynthesizer-prompt.md`, and run its quality check before you present it.\n\n### Parallel investigators, when another source exists\n\nSpawn one investigator per source, each a subagent that inherits the session's model.\nLaunch them in a single message, so that they run concurrently, and go on only once every finding is back.\nDon't ask one agent to cover multiple sources.\nAn investigator needs the tools of its source, so do not give it an agent type that lacks them.\nInvestigators still shouldn't write anything.\n\nEach investigator gets:\n\n1. The base prompt from `references\u002Finvestigator-prompt.md`\n2. The playbook of its category, when `references\u002Fsource-playbook.md` lists one, adapted to the source at hand\n3. The cross-cutting `references\u002Fsources\u002Fincident-postmortem.md` **if the target code looks defensive** (null checks, retry logic, timeout handling, rate limiting, feature flags, egress guards, OOM handlers)\n4. The code anchor (file paths, symbols, commit hashes, PR numbers, ticket IDs, decision records)\n5. The user's original question\n\nEach entry of the roster names the category and the kind of \"why\" it uniquely surfaces.\nUse it to know what to expect back, how to name a gap when a category returns empty, and (only in the rare provably-irrelevant case) to justify a skip.\n\n1. **Source control investigator**. Decision records, git history, `gh` for PRs, code comments, tests. Always spawn. The only guaranteed source. Best at surfacing *implementation-time rationale captured during review*.\n\n2. **Issue \u002F ticket tracker investigator** (GitHub Issues through `gh`, or e.g. a Linear, Jira, Plane, Shortcut MCP). Best at surfacing *the product or business forcing function*. Strongest when the why is external to engineering.\n\n3. **Long-form documents investigator** (e.g. Notion, Confluence, Google Docs, Coda MCP). Best at surfacing *long-form design rationale*. Where the why is written out before it becomes code.\n\n4. **Real-time team chat investigator** (e.g. Slack, Discord, Microsoft Teams, Mattermost MCP). Best at surfacing *real-time deliberation that never reached a doc*. Especially important when the source control, ticket, and doc paper trail is thin.\n\n5. **Infrastructure observability investigator** (e.g. Datadog, New Relic, Honeycomb, Grafana, Splunk MCP). Infra\u002Fruntime view. Best at surfacing *infrastructure and runtime reality that motivated the code*. Strongest when the target reacts to an infra signal (timeouts, retries, rate limits, circuit breakers).\n\n6. **Error \u002F exception tracking investigator** (e.g. Sentry, Rollbar, Bugsnag, Airbrake MCP). Best at surfacing *the specific exceptions and error trajectories that motivated defensive or corrective code*. Strongest for catch blocks, null guards, type checks, retries, and other defenses.\n\n7. **Product analytics warehouse investigator** (e.g. Databricks, Snowflake, BigQuery, ClickHouse, dbt, Redshift MCP). Product\u002Fdata view. Best at surfacing *product and data reality that shaped the code*. Strongest for flag-gated code, experiment-driven ships, data migrations, and \"where did this number come from\" questions.\n\nOnly skip an investigator with an **explicit, written justification** that goes in the final \"Sources consulted\" section.\nTwo valid reasons:\n\n- **No MCP is available for that category** in this environment. Flag this as a gap, not a choice. Example: \"Real-time team chat skipped. No matching MCP available, so the conversational record was not searchable.\"\n- **The source is provably irrelevant**, not just \"probably irrelevant.\" A high bar. Example: \"Error \u002F exception tracking skipped. Target is a build-time script with no runtime code path.\"\n\nIf your scope assessment suggests a single-commit trivial target where the PR description already contains the complete answer, you may answer in one pass **only after** confirming that the searches of the other sources would be redundant.\nSay so explicitly.\nThis should be rare.\n\nThen spawn one synthesizer subagent, which also inherits the session's model and needs the tools of every source, because its quality check spot-verifies citations.\nThe synthesizer gets:\n\n1. The investigator findings, including any null results and any categories skipped with justification\n2. The code anchor (file paths, symbols, commit hashes, PR numbers, ticket IDs, decision records)\n3. The user's original question\n4. The epistemics framework from `references\u002Fepistemics.md`\n5. The synthesizer prompt template from `references\u002Fsynthesizer-prompt.md`\n\n## Present\n\nPresent the answer to the user.\nYou may lightly edit a synthesizer's output for clarity or add context from the conversation, but **do not rewrite the confidence language**.\n\n## Output format\n\nThe output structure is the one in `references\u002Fsynthesizer-prompt.md`: The question, The code in question, What we found, What we can reasonably infer, Competing hypotheses, What we don't know, Sources consulted, Confidence summary.\nAdapt as needed, but keep the confidence separation intact, and keep Sources consulted as one line per evidence category, including the ones that returned nothing, could not be reached or were skipped, with the reason.\n\nAfter the Sources consulted block, if the user's `why` question is a precursor to actually changing this code, convert the lineage findings into a Preserve \u002F Change \u002F Avoid \u002F Risk constraint set suitable for planning the change.\n\n## Common failure modes to avoid\n\n- **Recency bias**. Assuming the most recent commit is authoritative. The current shape is often the accretion of many earlier decisions. Trace back.\n\n## Reference files\n\n- `references\u002Fepistemics.md`. Confidence tiers and phrasing guide. Every answer must follow it.\n- `references\u002Finvestigator-prompt.md`. Base prompt template for investigator subagents, and the posture of a single pass.\n- `references\u002Fsource-playbook.md`. Index pointing at the category playbooks below.\n- `references\u002Fsources\u002Fcode-archaeology.md` and `references\u002Fsources\u002Fgithub-issues.md`. The playbooks for the two sources every repository has.\n- `references\u002Fsources\u002Fincident-postmortem.md`. The cross-cutting angle for defensive code.\n- `references\u002Fsynthesizer-prompt.md`. Prompt template for the synthesizer subagent, including the output format.\n","# Why\n\nInvestigate the motivation and intent behind code.\n\nCompanion to `discover:how`.\n`discover:how` answers what the code does and how it works.\nThis skill answers what forces led to its shape.\n\n## Operating posture\n\nOperate as a **careful, cautious, and precise investigator**.\nBe honest about what you know vs what you're inferring.\nRead `references\u002Fepistemics.md` for the full confidence framework and phrasing guide.\nWhoever writes the answer, you or a synthesizer, must follow it.\n\n## Understand the target and the question\n\nParse what the user is asking.\nThe **target** is usually a chunk of code, a pattern, a feature, or a named design decision.\nThe **question** is usually a design rationale, a tradeoff, a motivating edge case, an external constraint, dead code, or a broad history sweep.\n\nIf the target is vague (\"why do we do it this way?\" with no clear referent), make your best guess from conversation context (open files, recent edits, cursor location, what was just discussed).\nState your interpretation briefly so the user can redirect if you're off, then proceed.\n\n## Establish the code anchor\n\nBefore investigating, anchor the investigation in concrete code.\nYou need:\n\n- The relevant file path(s) and line range(s)\n- The key symbols (function names, class names, constants)\n- An initial commit list. The last few commits touching the target.\n- PR numbers from merge commits (pattern `(#1234)` or `Merge pull request #1234` in the subject line)\n- The decision records that name the target, in `docs\u002Fdecisions\u002F` at the root or inside a package\n\nBuild this inline.\n\n```bash\n# Blame target lines for last-touch commits\ngit blame -L \u003Cstart>,\u003Cend> \u003Cfile>\n\n# Full file history, with patches, through renames\ngit log --follow -p -- \u003Cfile>\n\n# Last N commits touching the file, PR numbers visible\ngit log --oneline -20 -- \u003Cfile>\n\n# Extract PR numbers from a commit message\ngit log -1 --format=%B \u003Ccommit>\n```\n\nPull PR bodies and discussion via `gh` for any substantive commits:\n\n```bash\ngh pr view \u003Cnumber> --json title,body,author,createdAt,mergedAt,labels,closingIssuesReferences,comments,reviews\n```\n\nCapture this as seed context (file paths, symbols, commits, PR numbers, linked ticket IDs, decision records).\n\n## Investigate\n\n### Discovery\n\nList the evidence sources this session can reach, one coverage map over seven evidence categories:\n\n1. Source control history\n2. Issue \u002F ticket tracker\n3. Long-form documents\n4. Real-time team chat\n5. Infrastructure observability\n6. Error \u002F exception tracking\n7. Product analytics warehouse\n\nSource control is always available through git, and its pull requests through `gh`.\nThe issue tracker is GitHub Issues, also through `gh`.\nFor anything else, list the MCP servers the session offers and map each one to one evidence category, using the MCP name, server instructions, tool names, and resource descriptors.\nIf an MCP could fit more than one category, choose the one matching its primary evidence.\nRecord ambiguous cases in the coverage map.\nAn MCP that holds none of these kinds of evidence, such as one for a build tool or a browser, is not a source.\n\nAim for a complete **coverage map**, not a minimal one.\nDocument the null, don't skip the search.\nA source you could not reach (`gh` missing or not signed in, no network, an MCP that refused) is a gap: report it with the error you got, never as \"nothing found\".\n\n### One pass, when git and GitHub are the only sources\n\nWhen no MCP maps to a category, run the investigation yourself, with no investigators and no synthesizer.\n\n1. Follow `references\u002Fsources\u002Fcode-archaeology.md`, then `references\u002Fsources\u002Fgithub-issues.md`.\n2. Run the queries of `references\u002Fsources\u002Fincident-postmortem.md` inside both **if the target code looks defensive** (null checks, retry logic, timeout handling, rate limiting, feature flags, egress guards, OOM handlers).\n3. Work to the sections \"Operating posture\", \"Investigation instructions\" and \"Epistemic discipline\" of `references\u002Finvestigator-prompt.md`: quote, record every query, keep the contradictions. Both sources are yours, so follow a reference from one into the other yourself.\n4. Write the answer in the output format of `references\u002Fsynthesizer-prompt.md`, and run its quality check before you present it.\n\n### Parallel investigators, when another source exists\n\nSpawn one investigator per source, each a subagent that inherits the session's model.\nLaunch them in a single message, so that they run concurrently, and go on only once every finding is back.\nDon't ask one agent to cover multiple sources.\nAn investigator needs the tools of its source, so do not give it an agent type that lacks them.\nInvestigators still shouldn't write anything.\n\nEach investigator gets:\n\n1. The base prompt from `references\u002Finvestigator-prompt.md`\n2. The playbook of its category, when `references\u002Fsource-playbook.md` lists one, adapted to the source at hand\n3. The cross-cutting `references\u002Fsources\u002Fincident-postmortem.md` **if the target code looks defensive** (null checks, retry logic, timeout handling, rate limiting, feature flags, egress guards, OOM handlers)\n4. The code anchor (file paths, symbols, commit hashes, PR numbers, ticket IDs, decision records)\n5. The user's original question\n\nEach entry of the roster names the category and the kind of \"why\" it uniquely surfaces.\nUse it to know what to expect back, how to name a gap when a category returns empty, and (only in the rare provably-irrelevant case) to justify a skip.\n\n1. **Source control investigator**. Decision records, git history, `gh` for PRs, code comments, tests. Always spawn. The only guaranteed source. Best at surfacing *implementation-time rationale captured during review*.\n\n2. **Issue \u002F ticket tracker investigator** (GitHub Issues through `gh`, or e.g. a Linear, Jira, Plane, Shortcut MCP). Best at surfacing *the product or business forcing function*. Strongest when the why is external to engineering.\n\n3. **Long-form documents investigator** (e.g. Notion, Confluence, Google Docs, Coda MCP). Best at surfacing *long-form design rationale*. Where the why is written out before it becomes code.\n\n4. **Real-time team chat investigator** (e.g. Slack, Discord, Microsoft Teams, Mattermost MCP). Best at surfacing *real-time deliberation that never reached a doc*. Especially important when the source control, ticket, and doc paper trail is thin.\n\n5. **Infrastructure observability investigator** (e.g. Datadog, New Relic, Honeycomb, Grafana, Splunk MCP). Infra\u002Fruntime view. Best at surfacing *infrastructure and runtime reality that motivated the code*. Strongest when the target reacts to an infra signal (timeouts, retries, rate limits, circuit breakers).\n\n6. **Error \u002F exception tracking investigator** (e.g. Sentry, Rollbar, Bugsnag, Airbrake MCP). Best at surfacing *the specific exceptions and error trajectories that motivated defensive or corrective code*. Strongest for catch blocks, null guards, type checks, retries, and other defenses.\n\n7. **Product analytics warehouse investigator** (e.g. Databricks, Snowflake, BigQuery, ClickHouse, dbt, Redshift MCP). Product\u002Fdata view. Best at surfacing *product and data reality that shaped the code*. Strongest for flag-gated code, experiment-driven ships, data migrations, and \"where did this number come from\" questions.\n\nOnly skip an investigator with an **explicit, written justification** that goes in the final \"Sources consulted\" section.\nTwo valid reasons:\n\n- **No MCP is available for that category** in this environment. Flag this as a gap, not a choice. Example: \"Real-time team chat skipped. No matching MCP available, so the conversational record was not searchable.\"\n- **The source is provably irrelevant**, not just \"probably irrelevant.\" A high bar. Example: \"Error \u002F exception tracking skipped. Target is a build-time script with no runtime code path.\"\n\nIf your scope assessment suggests a single-commit trivial target where the PR description already contains the complete answer, you may answer in one pass **only after** confirming that the searches of the other sources would be redundant.\nSay so explicitly.\nThis should be rare.\n\nThen spawn one synthesizer subagent, which also inherits the session's model and needs the tools of every source, because its quality check spot-verifies citations.\nThe synthesizer gets:\n\n1. The investigator findings, including any null results and any categories skipped with justification\n2. The code anchor (file paths, symbols, commit hashes, PR numbers, ticket IDs, decision records)\n3. The user's original question\n4. The epistemics framework from `references\u002Fepistemics.md`\n5. The synthesizer prompt template from `references\u002Fsynthesizer-prompt.md`\n\n## Present\n\nPresent the answer to the user.\nYou may lightly edit a synthesizer's output for clarity or add context from the conversation, but **do not rewrite the confidence language**.\n\n## Output format\n\nThe output structure is the one in `references\u002Fsynthesizer-prompt.md`: The question, The code in question, What we found, What we can reasonably infer, Competing hypotheses, What we don't know, Sources consulted, Confidence summary.\nAdapt as needed, but keep the confidence separation intact, and keep Sources consulted as one line per evidence category, including the ones that returned nothing, could not be reached or were skipped, with the reason.\n\nAfter the Sources consulted block, if the user's `why` question is a precursor to actually changing this code, convert the lineage findings into a Preserve \u002F Change \u002F Avoid \u002F Risk constraint set suitable for planning the change.\n\n## Common failure modes to avoid\n\n- **Recency bias**. Assuming the most recent commit is authoritative. The current shape is often the accretion of many earlier decisions. Trace back.\n\n## Reference files\n\n- `references\u002Fepistemics.md`. Confidence tiers and phrasing guide. Every answer must follow it.\n- `references\u002Finvestigator-prompt.md`. Base prompt template for investigator subagents, and the posture of a single pass.\n- `references\u002Fsource-playbook.md`. Index pointing at the category playbooks below.\n- `references\u002Fsources\u002Fcode-archaeology.md` and `references\u002Fsources\u002Fgithub-issues.md`. The playbooks for the two sources every repository has.\n- `references\u002Fsources\u002Fincident-postmortem.md`. The cross-cutting angle for defensive code.\n- `references\u002Fsynthesizer-prompt.md`. Prompt template for the synthesizer subagent, including the output format.\n",{"name":5,"description":7,"argument-hint":24},"\u003Cthe question, naming the code, design or decision it is about>","main","7d4c29d5ef25e4bff96b8ed951739cd04811984b","plugins\u002Fdiscover\u002Fskills\u002Fwhy","https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit","https:\u002F\u002Fwww.lyngon.com","https:\u002F\u002Fgithub.com\u002Flyngon","www.lyngon.com","2026-11-14 19:00:56",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add lyngon\u002Fdevkit --skill why",{"tool":39,"command":40},"bunx","bunx skills add lyngon\u002Fdevkit --skill why",{"tool":42,"command":43},"pnpm","pnpm dlx skills add lyngon\u002Fdevkit --skill why","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscover\u002Fskills\u002Fwhy\u002FSKILL.md",true,[47,53,57,61,65,69,73],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"references\u002Fepistemics.md","REFERENCE","参考文档",7755,"https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscover\u002Fskills\u002Fwhy\u002Freferences\u002Fepistemics.md",{"path":54,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":55,"sourceHtmlUrl":56},"references\u002Finvestigator-prompt.md",7176,"https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscover\u002Fskills\u002Fwhy\u002Freferences\u002Finvestigator-prompt.md",{"path":58,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":59,"sourceHtmlUrl":60},"references\u002Fsource-playbook.md",1160,"https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscover\u002Fskills\u002Fwhy\u002Freferences\u002Fsource-playbook.md",{"path":62,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":63,"sourceHtmlUrl":64},"references\u002Fsources\u002Fcode-archaeology.md",5043,"https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscover\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fcode-archaeology.md",{"path":66,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Fsources\u002Fgithub-issues.md",4094,"https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscover\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fgithub-issues.md",{"path":70,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fsources\u002Fincident-postmortem.md",2009,"https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscover\u002Fskills\u002Fwhy\u002Freferences\u002Fsources\u002Fincident-postmortem.md",{"path":74,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fsynthesizer-prompt.md",7970,"https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fdiscover\u002Fskills\u002Fwhy\u002Freferences\u002Fsynthesizer-prompt.md",[78,85,92,99,106,113],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":19},"01M7CTNRE8KXX2CG9Q2XYYBTDE","unslop","Remove AI writing patterns from prose and give it a voice. Use whenever writing or editing non-code text (docs, READMEs, decision records, posts, commit messages, PR descriptions), before handing it over, and on request: \"unslop\", \"humanize\", \"make this sound human\", \"clean up this writing\", \"edit for voice\", \"de-AI this text\".","https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fwriting\u002Fskills\u002Funslop\u002FSKILL.md",[],[],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":19},"01M7CTNHG9ENS5D6GCA9283V08","technical","Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use before writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages, every time, however small the document.","https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fwriting\u002Fskills\u002Ftechnical\u002FSKILL.md",[],[],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":19},"01M7CTND9T9J9P1TR6RRDVAXF4","simpler","Restate the last message in plain human language, with no jargon. Use when the reader did not follow the last message and says so: \"bro\", \"say that simpler\", \"in plain words\", \"no jargon\".","https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fwriting\u002Fskills\u002Fsimpler\u002FSKILL.md",[],[],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":19},"01M7CTN8H1N39FCQ67AM7WD4S2","init","Set up a fresh repository, or adopt an existing one, to Lyngon conventions. Interviews the owner relentlessly about purpose, failure modes, audiences, stack and constraints, then writes INTENT.md, .claude\u002FCLAUDE.md, README.md, CONCEPTS.md, decision records, devenv, git hooks, CI and every package in the kind-first Lyngon layout. User-invoked only.","https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Frepo\u002Fskills\u002Finit\u002FSKILL.md",[],[],{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":19},"01M7CTN36H4AR1GATK3KE5E85X","add-package","Create a package in a Lyngon repository in the directory its kind decides (apps\u002F, libs\u002F, contracts\u002F, tools\u002F, infra\u002F), with README.md, devenv.nix and the layer lint, and register it in its workspace and devenv. Use whenever a new app, service, CLI, library, adapter, contract, schema, tool, infra module or environment is needed, including when one feature needs several packages. Never create a package by hand.","https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Frepo\u002Fskills\u002Fadd-package\u002FSKILL.md",[],[],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":19},"01M7CTMZE95Q1FJWKJRB8WCX4E","index","The index of Lyngon's principles, one line per principle saying when it applies and what it demands, each with a file under references\u002F. Invoke before work that takes judgment, such as a design choice, a refactor, a bug fix, a test, a measurement, a script, a document or a question to the owner; then read the file of each principle that applies.","https:\u002F\u002Fgithub.com\u002Flyngon\u002Fdevkit\u002Fblob\u002Fmain\u002Fplugins\u002Fprinciples\u002Fskills\u002Findex\u002FSKILL.md",[],[]]