[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C58SFXKCSHN37W4XVFXP5F":3,"skill-same:01M6C58SFXKCSHN37W4XVFXP5F":61},{"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":23,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M6C58SFXKCSHN37W4XVFXP5F","boot-concept",null,"Research and write the concept-zero high-level design for a project.","Lyther\u002Fagent-surface","Lyther","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F29906124?v=4","01M6C587M9T34T0SAGJSRK043Y","Enderaoe","01M6C587R0TXH3MFR8SRFPV61G",65,"MIT","https:\u002F\u002Fgithub.com\u002FLyther\u002Fagent-surface\u002Fblob\u002Fmain\u002Fskills\u002Fboot-concept\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33],"boot","boot concept","concept","design","research","ZeRO","write","project","high","for","2026-11-10 10:12:30",false,"---\nname: boot-concept\ndescription: \"Research and write the concept-zero high-level design for a project.\"\n---\n\n## Objective\n\nCreate or update `docs\u002Fcontext\u002Fconcept-zero.md`, the canonical concept-level HLD for a new or existing project. It answers: what problem is solved, for whom, what success and unacceptable failure look like, what the system must and must not do, which existing products, OSS projects, standards, papers, protocols, managed services, and reference implementations already cover the problem, which concept is selected and why, what remains uncertain before detailed architecture, and what credible path leads to real production use.\n\nCapture the concept, the evidence, and the decision. Write no source code, detailed schemas, endpoint-level APIs, migrations, UI mockups, or task-level plans, and present screenshots, snippets, scaffolds, or API schemas as concept work only when they are existing evidence. Never create `docs\u002Farchitecture.md` or `docs\u002Froadmap.md`; `arch-roadmap` derives them from this document.\n\n## Modes\n\n- `boot-concept check`: read-only inventory of existing context, evidence gaps, contradictions, and whether a credible concept HLD can be written.\n- `boot-concept run`: write or update `docs\u002Fcontext\u002Fconcept-zero.md`; add `docs\u002Fcontext\u002Fconcept-zero-research.md` only when the evidence ledger would dominate the main document.\n- Bare `boot-concept`: check first, then run when the inputs are coherent enough. When product intent is ambiguous, state a working assumption and continue unless the next step would lock in the wrong product.\n\n## Authority\n\nBe skeptical without inflating process: the document should be dense enough to prevent bad architecture and small enough to stay read. You may narrow implementation scope to preserve the core outcome and production path, and recommend adoption, adaptation, procurement, partnership, or research instead of custom development. Never silently change the target problem, users, hard constraints, legal obligations, or explicit user decisions. Research, challenge, and recommend one direction instead of handing the user an unfiltered option list; ask only when alternatives represent different product intent that evidence cannot resolve.\n\n## Input\n\n1. The user brief, goals, constraints, corrections, and explicit exclusions.\n2. Existing `docs\u002Fcontext\u002F`, `docs\u002Fdesign\u002F`, `docs\u002Fresearch\u002F`, `docs\u002Fadr\u002F`, and project-specific equivalents.\n3. Prior concepts, PRDs, architecture docs, roadmaps, reviews, ADRs, benchmark notes, incident notes, and feasibility reports.\n4. Repository evidence when implementation exists: manifests, tests, CI, schemas, package managers, deployment config, APIs, data models, and runtime boundaries.\n5. Authoritative external research.\n\nDetect concept-HLD equivalents by content, not name; still write `docs\u002Fcontext\u002Fconcept-zero.md` unless the project has a stronger established convention.\n\n## Labels\n\nLabel material statements when the distinction matters: `FACT` (repository evidence, authoritative docs, or cited research), `USER_DECISION` (chosen by the user or project authority), `INFERENCE` (derived from facts, reasoning stated), `ASSUMPTION` (unverified working premise), `PROPOSAL` (selected or candidate design choice), `OPEN_QUESTION` (unresolved), `INVALIDATED` (contradicted by evidence). Never invent users, requirements, metrics, benchmarks, user research, legal obligations or analysis, performance, maintenance status, repository state, production readiness, or implementation status.\n\n## Principles\n\n- Define users, outcomes, scope, and failure modes before selecting technology.\n- Select the smallest coherent system that creates real user value and survives production constraints; reject microservices, event buses, custom auth, bespoke billing, custom databases, multi-region deployment, heavy governance, and large framework stacks unless a named driver requires them. When a static site, CLI, local script, or single-process service suffices, say so.\n- Optimize the few architecture characteristics that matter most and make the trade-offs explicit.\n- Defer expensive irreversible choices when a small spike or staged rollout can resolve the uncertainty.\n- Give every critical capability a credible real implementation, data, integration, deployment, support, and cost route.\n\n## Research\n\nResearch every claim and choice that can materially change feasibility, architecture, cost, user access, schedule, legal posture, or operations. Source order: official standards, specifications, vendor docs, project repositories, release notes, datasets, protocol docs, and primary product material; maintainer examples, reference implementations, and migration guides; peer-reviewed papers and author-maintained implementations; reproducible independent evaluations; secondary analysis for context only.\n\nFor current tools and services, verify the latest relevant release, maintenance state, platform support, documented limits, pricing or cost shape when relevant, license, compatibility, operating model, and ecosystem health. For OSS, check whether it can be used directly, wrapped, extended through supported APIs, or only forked. Stop when each critical capability has at least one credible route, materially different approaches are represented, more sources no longer change the decision, and known gaps are explicit; never research just to add citations.\n\n## Procedure\n\n1. Frame:\n   - Inventory context documents, repository evidence, and external research needs.\n   - State the problem in product language, without implementation vocabulary.\n   - Identify users, operators, administrators, buyers, developers, affected external parties, and excluded audiences.\n   - Separate goals, non-goals, constraints, preferences, assumptions, and open questions.\n   - Define unacceptable outcomes: user exclusion, data loss, unbounded cost, unsafe behavior, operational fragility, lock-in, or dependence on a nonexistent capability.\n   - Write a glossary for overloaded domain terms.\n\n   If inputs contradict each other on user, problem, or a hard constraint, record the conflict and proceed on a stated working interpretation only when that is safe and reversible.\n2. Plan research across the applicable categories only:\n   - Problem and user evidence: current workflow, pain, failure cost, access constraints, devices, localization, bandwidth, data sensitivity.\n   - Comparable systems: commercial products, internal systems, OSS projects, reference architectures, failed approaches, adoption barriers.\n   - OSS prior art: maintenance, license, governance, contributors, security posture, documentation, extension points, migration or replacement path.\n   - Technical literature: assumptions, datasets, metrics, hardware, reproduction, source availability, domain mismatch, maintained implementation route.\n   - Standards and ecosystem: protocols, formats, accessibility, platform policy, regulatory obligations, interoperability.\n   - Production feasibility: data sources, integrations, deployment environments, compute, storage, support model, cost drivers, failure modes.\n3. Record evidence in a concise table in `docs\u002Fcontext\u002Fconcept-zero.md`, or in `docs\u002Fcontext\u002Fconcept-zero-research.md` linked from it when the table would dominate. Every important dependency, service, standard, model, dataset, protocol, and paper needs enough evidence to justify adoption, adaptation, rejection, or a spike.\n\n   | ID | Claim \u002F question | Source | Date \u002F version | Finding | Confidence | Impact |\n   |---|---|---|---|---|---|---|\n   | `E-01` | ... | official docs \u002F repo \u002F paper | ... | ... | high \u002F medium \u002F low | ... |\n\n4. Capture architecture-significant requirements before candidate designs. Make quality scenarios concrete enough to test later; when no precise number is known, use the best current threshold and mark it `ASSUMPTION` or `SPIKE_REQUIRED`.\n\n   | ID | Type | Statement | Evidence | Notes |\n   |---|---|---|---|---|\n   | `G-01` | goal | ... | ... | ... |\n   | `N-01` | non-goal | ... | ... | ... |\n   | `C-01` | constraint | ... | ... | ... |\n   | `Q-01` | quality scenario | stimulus -> response -> measure | ... | ... |\n\n5. Map prior art as a landscape, not a shopping list:\n\n   | Capability | Existing route | Adopt \u002F adapt \u002F build | Evidence | Rejection \u002F risk |\n   |---|---|---|---|---|\n   | ... | OSS \u002F standard \u002F service \u002F paper | ... | ... | ... |\n\n   Default to adopting maintained OSS, standards, protocols, managed services, and reference implementations. Build custom only when the capability is the product differentiator; available routes are incompatible, abandoned, unsafe, legally unusable, or more complex than implementing it; the project needs a narrow wrapper rather than a general platform; or a spike shows custom work is cheaper and less risky.\n6. Generate two or three materially different concepts, including the simplest credible one, unless only one credible path exists. For each: user-facing experience and main workflow; system boundary and external dependencies; major subsystems and data flow at HLD level; adopted OSS, services, and standards; what is intentionally not built; production path and operating model; the strongest risk and how to falsify it.\n7. Challenge the candidates, then revise them, dropping weak concepts kept for symmetry:\n   - What makes this concept fail in its first real deployment?\n   - Which component is overkill for the first release?\n   - Which existing OSS, service, or standard makes custom work unnecessary?\n   - Which claimed dependency is unmaintained, unavailable, incompatible, or too expensive?\n   - Which quality attribute is optimized without user or business evidence?\n   - Which production blocker hides as \"future work\"?\n   - Which simpler concept preserves the core outcome?\n8. Select one concept and state why: goals it satisfies, non-goals and deferred scope, adopted, adapted, and built capabilities, unresolved assumptions and spikes, intentionally accepted risk and debt, rejected alternatives, and triggers that would reopen the decision.\n\n## Template\n\nUse this structure for `docs\u002Fcontext\u002Fconcept-zero.md` unless an established project format is stronger. State the selected concept early and show evidence after it; prefer tables where they replace prose; keep sections short when the decision is simple, since empty template ceremony is worse than a concise documented decision.\n\n```markdown\n# Concept Zero\n\nStatus: PROPOSED\nLast updated: YYYY-MM-DD\n\n## Executive Decision\nOne dense paragraph: selected concept, target user, core value, production path, and what is deliberately not included.\n\n## Problem and Evidence\n| ID | Claim | Evidence | Confidence | Impact |\n|---|---|---|---|---|\n\n## Users and Stakeholders\n| Actor | Need | Constraints | Success signal |\n|---|---|---|---|\n\n## Goals, Non-Goals, and Constraints\n| ID | Type | Statement | Evidence |\n|---|---|---|---|\n\n## Unacceptable Outcomes\n| Outcome | Why it matters | Prevention \u002F detection |\n|---|---|---|\n\n## Glossary\n| Term | Meaning |\n|---|---|\n\n## Critical Journeys\n| Journey | Current pain | Proposed experience | Evidence needed |\n|---|---|---|---|\n\n## Quality Scenarios\n| ID | Scenario | Measure | Later architecture gate |\n|---|---|---|---|\n\n## Research Landscape\n| Capability | Candidate route | Evidence | Verdict |\n|---|---|---|---|\n\n## Adopt \u002F Adapt \u002F Build Decisions\n| Capability | Decision | Rationale | Risk |\n|---|---|---|---|\n\n## Candidate Concepts\n### Candidate A: ...\n...\n\n## Adversarial Review\n| Finding | Revision |\n|---|---|\n\n## Selected Concept HLD\nSystem boundary, subsystems, data, integrations, deployment shape, operations, required risk posture, cost drivers, and failure behavior at high level.\n\n## First Production Slice\nThe smallest production-shaped release that proves the concept with real data, real users or operators, real checks, and realistic deployment constraints.\n\n## Open Questions and Spikes\n| Question | Why it matters | How to resolve | Owner \u002F next command |\n|---|---|---|---|\n\n## Handoff to Architecture and Roadmap\nDecisions, quality scenarios, risks, and spikes that `arch-roadmap` must carry forward into `docs\u002Farchitecture.md` and `docs\u002Froadmap.md`.\n```\n\n## Report\n\nIf no write is safe, produce a check report with the exact blockers and how a human can unblock them. Otherwise report Changed (full paths to the written files), Checks (commands or scenarios as `passed`, `failed`, or `not run`), Blockers (unresolved issues, whether a human must act, and the unblock path), and the next command, normally `arch-roadmap` once `concept-zero.md` is complete.\n","## Objective\n\nCreate or update `docs\u002Fcontext\u002Fconcept-zero.md`, the canonical concept-level HLD for a new or existing project. It answers: what problem is solved, for whom, what success and unacceptable failure look like, what the system must and must not do, which existing products, OSS projects, standards, papers, protocols, managed services, and reference implementations already cover the problem, which concept is selected and why, what remains uncertain before detailed architecture, and what credible path leads to real production use.\n\nCapture the concept, the evidence, and the decision. Write no source code, detailed schemas, endpoint-level APIs, migrations, UI mockups, or task-level plans, and present screenshots, snippets, scaffolds, or API schemas as concept work only when they are existing evidence. Never create `docs\u002Farchitecture.md` or `docs\u002Froadmap.md`; `arch-roadmap` derives them from this document.\n\n## Modes\n\n- `boot-concept check`: read-only inventory of existing context, evidence gaps, contradictions, and whether a credible concept HLD can be written.\n- `boot-concept run`: write or update `docs\u002Fcontext\u002Fconcept-zero.md`; add `docs\u002Fcontext\u002Fconcept-zero-research.md` only when the evidence ledger would dominate the main document.\n- Bare `boot-concept`: check first, then run when the inputs are coherent enough. When product intent is ambiguous, state a working assumption and continue unless the next step would lock in the wrong product.\n\n## Authority\n\nBe skeptical without inflating process: the document should be dense enough to prevent bad architecture and small enough to stay read. You may narrow implementation scope to preserve the core outcome and production path, and recommend adoption, adaptation, procurement, partnership, or research instead of custom development. Never silently change the target problem, users, hard constraints, legal obligations, or explicit user decisions. Research, challenge, and recommend one direction instead of handing the user an unfiltered option list; ask only when alternatives represent different product intent that evidence cannot resolve.\n\n## Input\n\n1. The user brief, goals, constraints, corrections, and explicit exclusions.\n2. Existing `docs\u002Fcontext\u002F`, `docs\u002Fdesign\u002F`, `docs\u002Fresearch\u002F`, `docs\u002Fadr\u002F`, and project-specific equivalents.\n3. Prior concepts, PRDs, architecture docs, roadmaps, reviews, ADRs, benchmark notes, incident notes, and feasibility reports.\n4. Repository evidence when implementation exists: manifests, tests, CI, schemas, package managers, deployment config, APIs, data models, and runtime boundaries.\n5. Authoritative external research.\n\nDetect concept-HLD equivalents by content, not name; still write `docs\u002Fcontext\u002Fconcept-zero.md` unless the project has a stronger established convention.\n\n## Labels\n\nLabel material statements when the distinction matters: `FACT` (repository evidence, authoritative docs, or cited research), `USER_DECISION` (chosen by the user or project authority), `INFERENCE` (derived from facts, reasoning stated), `ASSUMPTION` (unverified working premise), `PROPOSAL` (selected or candidate design choice), `OPEN_QUESTION` (unresolved), `INVALIDATED` (contradicted by evidence). Never invent users, requirements, metrics, benchmarks, user research, legal obligations or analysis, performance, maintenance status, repository state, production readiness, or implementation status.\n\n## Principles\n\n- Define users, outcomes, scope, and failure modes before selecting technology.\n- Select the smallest coherent system that creates real user value and survives production constraints; reject microservices, event buses, custom auth, bespoke billing, custom databases, multi-region deployment, heavy governance, and large framework stacks unless a named driver requires them. When a static site, CLI, local script, or single-process service suffices, say so.\n- Optimize the few architecture characteristics that matter most and make the trade-offs explicit.\n- Defer expensive irreversible choices when a small spike or staged rollout can resolve the uncertainty.\n- Give every critical capability a credible real implementation, data, integration, deployment, support, and cost route.\n\n## Research\n\nResearch every claim and choice that can materially change feasibility, architecture, cost, user access, schedule, legal posture, or operations. Source order: official standards, specifications, vendor docs, project repositories, release notes, datasets, protocol docs, and primary product material; maintainer examples, reference implementations, and migration guides; peer-reviewed papers and author-maintained implementations; reproducible independent evaluations; secondary analysis for context only.\n\nFor current tools and services, verify the latest relevant release, maintenance state, platform support, documented limits, pricing or cost shape when relevant, license, compatibility, operating model, and ecosystem health. For OSS, check whether it can be used directly, wrapped, extended through supported APIs, or only forked. Stop when each critical capability has at least one credible route, materially different approaches are represented, more sources no longer change the decision, and known gaps are explicit; never research just to add citations.\n\n## Procedure\n\n1. Frame:\n   - Inventory context documents, repository evidence, and external research needs.\n   - State the problem in product language, without implementation vocabulary.\n   - Identify users, operators, administrators, buyers, developers, affected external parties, and excluded audiences.\n   - Separate goals, non-goals, constraints, preferences, assumptions, and open questions.\n   - Define unacceptable outcomes: user exclusion, data loss, unbounded cost, unsafe behavior, operational fragility, lock-in, or dependence on a nonexistent capability.\n   - Write a glossary for overloaded domain terms.\n\n   If inputs contradict each other on user, problem, or a hard constraint, record the conflict and proceed on a stated working interpretation only when that is safe and reversible.\n2. Plan research across the applicable categories only:\n   - Problem and user evidence: current workflow, pain, failure cost, access constraints, devices, localization, bandwidth, data sensitivity.\n   - Comparable systems: commercial products, internal systems, OSS projects, reference architectures, failed approaches, adoption barriers.\n   - OSS prior art: maintenance, license, governance, contributors, security posture, documentation, extension points, migration or replacement path.\n   - Technical literature: assumptions, datasets, metrics, hardware, reproduction, source availability, domain mismatch, maintained implementation route.\n   - Standards and ecosystem: protocols, formats, accessibility, platform policy, regulatory obligations, interoperability.\n   - Production feasibility: data sources, integrations, deployment environments, compute, storage, support model, cost drivers, failure modes.\n3. Record evidence in a concise table in `docs\u002Fcontext\u002Fconcept-zero.md`, or in `docs\u002Fcontext\u002Fconcept-zero-research.md` linked from it when the table would dominate. Every important dependency, service, standard, model, dataset, protocol, and paper needs enough evidence to justify adoption, adaptation, rejection, or a spike.\n\n   | ID | Claim \u002F question | Source | Date \u002F version | Finding | Confidence | Impact |\n   |---|---|---|---|---|---|---|\n   | `E-01` | ... | official docs \u002F repo \u002F paper | ... | ... | high \u002F medium \u002F low | ... |\n\n4. Capture architecture-significant requirements before candidate designs. Make quality scenarios concrete enough to test later; when no precise number is known, use the best current threshold and mark it `ASSUMPTION` or `SPIKE_REQUIRED`.\n\n   | ID | Type | Statement | Evidence | Notes |\n   |---|---|---|---|---|\n   | `G-01` | goal | ... | ... | ... |\n   | `N-01` | non-goal | ... | ... | ... |\n   | `C-01` | constraint | ... | ... | ... |\n   | `Q-01` | quality scenario | stimulus -> response -> measure | ... | ... |\n\n5. Map prior art as a landscape, not a shopping list:\n\n   | Capability | Existing route | Adopt \u002F adapt \u002F build | Evidence | Rejection \u002F risk |\n   |---|---|---|---|---|\n   | ... | OSS \u002F standard \u002F service \u002F paper | ... | ... | ... |\n\n   Default to adopting maintained OSS, standards, protocols, managed services, and reference implementations. Build custom only when the capability is the product differentiator; available routes are incompatible, abandoned, unsafe, legally unusable, or more complex than implementing it; the project needs a narrow wrapper rather than a general platform; or a spike shows custom work is cheaper and less risky.\n6. Generate two or three materially different concepts, including the simplest credible one, unless only one credible path exists. For each: user-facing experience and main workflow; system boundary and external dependencies; major subsystems and data flow at HLD level; adopted OSS, services, and standards; what is intentionally not built; production path and operating model; the strongest risk and how to falsify it.\n7. Challenge the candidates, then revise them, dropping weak concepts kept for symmetry:\n   - What makes this concept fail in its first real deployment?\n   - Which component is overkill for the first release?\n   - Which existing OSS, service, or standard makes custom work unnecessary?\n   - Which claimed dependency is unmaintained, unavailable, incompatible, or too expensive?\n   - Which quality attribute is optimized without user or business evidence?\n   - Which production blocker hides as \"future work\"?\n   - Which simpler concept preserves the core outcome?\n8. Select one concept and state why: goals it satisfies, non-goals and deferred scope, adopted, adapted, and built capabilities, unresolved assumptions and spikes, intentionally accepted risk and debt, rejected alternatives, and triggers that would reopen the decision.\n\n## Template\n\nUse this structure for `docs\u002Fcontext\u002Fconcept-zero.md` unless an established project format is stronger. State the selected concept early and show evidence after it; prefer tables where they replace prose; keep sections short when the decision is simple, since empty template ceremony is worse than a concise documented decision.\n\n```markdown\n# Concept Zero\n\nStatus: PROPOSED\nLast updated: YYYY-MM-DD\n\n## Executive Decision\nOne dense paragraph: selected concept, target user, core value, production path, and what is deliberately not included.\n\n## Problem and Evidence\n| ID | Claim | Evidence | Confidence | Impact |\n|---|---|---|---|---|\n\n## Users and Stakeholders\n| Actor | Need | Constraints | Success signal |\n|---|---|---|---|\n\n## Goals, Non-Goals, and Constraints\n| ID | Type | Statement | Evidence |\n|---|---|---|---|\n\n## Unacceptable Outcomes\n| Outcome | Why it matters | Prevention \u002F detection |\n|---|---|---|\n\n## Glossary\n| Term | Meaning |\n|---|---|\n\n## Critical Journeys\n| Journey | Current pain | Proposed experience | Evidence needed |\n|---|---|---|---|\n\n## Quality Scenarios\n| ID | Scenario | Measure | Later architecture gate |\n|---|---|---|---|\n\n## Research Landscape\n| Capability | Candidate route | Evidence | Verdict |\n|---|---|---|---|\n\n## Adopt \u002F Adapt \u002F Build Decisions\n| Capability | Decision | Rationale | Risk |\n|---|---|---|---|\n\n## Candidate Concepts\n### Candidate A: ...\n...\n\n## Adversarial Review\n| Finding | Revision |\n|---|---|\n\n## Selected Concept HLD\nSystem boundary, subsystems, data, integrations, deployment shape, operations, required risk posture, cost drivers, and failure behavior at high level.\n\n## First Production Slice\nThe smallest production-shaped release that proves the concept with real data, real users or operators, real checks, and realistic deployment constraints.\n\n## Open Questions and Spikes\n| Question | Why it matters | How to resolve | Owner \u002F next command |\n|---|---|---|---|\n\n## Handoff to Architecture and Roadmap\nDecisions, quality scenarios, risks, and spikes that `arch-roadmap` must carry forward into `docs\u002Farchitecture.md` and `docs\u002Froadmap.md`.\n```\n\n## Report\n\nIf no write is safe, produce a check report with the exact blockers and how a human can unblock them. Otherwise report Changed (full paths to the written files), Checks (commands or scenarios as `passed`, `failed`, or `not run`), Blockers (unresolved issues, whether a human must act, and the unblock path), and the next command, normally `arch-roadmap` once `concept-zero.md` is complete.\n",{"name":5,"description":7},"main","bb71e1631303bd27cb8ac18dc04830c97db8ac4d","skills\u002Fboot-concept",0,"https:\u002F\u002Fgithub.com\u002FLyther\u002Fagent-surface","https:\u002F\u002Fgithub.com\u002FLyther","Why so serious?","2026-11-13 17:36:21",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add Lyther\u002Fagent-surface --skill boot-concept",{"tool":53,"command":54},"bunx","bunx skills add Lyther\u002Fagent-surface --skill boot-concept",{"tool":56,"command":57},"pnpm","pnpm dlx skills add Lyther\u002Fagent-surface --skill boot-concept","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLyther\u002Fagent-surface\u002Fblob\u002Fmain\u002Fskills\u002Fboot-concept\u002FSKILL.md",true,[],[62,86,100,114,133,144],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":71,"publishedAt":34},"01M6C5CQAHK34J7RNHEJE1G366","workflow-runtime","Prove skill or workflow discovery, full-autonomy tool execution, and task-shaped materialization before assigning a CLI, extension, provider, or model to a workflow role.","https:\u002F\u002Fgithub.com\u002FLyther\u002Fagent-surface\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-runtime\u002FSKILL.md",[68],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[72,73,74,75,76,77,78,79,80,81,82,83,84,85],"workflow","workflow runtime","runtime","execution","cli","discovery","tool","model","autonomy","provider","task","full","extension","role",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":34},"01M6C5CNCTDS39453E66MQYTTQ","workflow-reviewer","Review batched implementation output against the BOSS spec and evidence.","https:\u002F\u002Fgithub.com\u002FLyther\u002Fagent-surface\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-reviewer\u002FSKILL.md",[],[93,94,72,95,96,97,98,99],"workflow reviewer","reviewer","spec","review","evidence","implementation","output",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"publishedAt":34},"01M6C5CKVKQF6NE9263HGRB2K3","workflow-rescue","Resolve repeated workflow failures with a single decisive action.","https:\u002F\u002Fgithub.com\u002FLyther\u002Fagent-surface\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-rescue\u002FSKILL.md",[106],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},[72,108,109,110,111,112,113],"workflow rescue","rescue","single","decisive action","with","action",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":121,"publishedAt":34},"01M6C5CHCW474Y5F49WME2G12H","workflow-orchestrator","Run risk-adaptive development, review, multi-agent, and release workflows with runtime preflight, bounded retries, liveness checks, isolated writers, and evidence-backed handoffs.","https:\u002F\u002Fgithub.com\u002FLyther\u002Fagent-surface\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-orchestrator\u002FSKILL.md",[120],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},[122,123,72,112,124,96,125,126,127,128,129,130,97,74,131,132],"orchestrator","workflow orchestrator","development","workflows","run","release","risk","preflight","multi-agent","multi","retries",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":34},"01M6C5CFCYEW1J4ETBNDD4EQPK","workflow-judger","Arbitrate repeated task failures and decide merge, rework, or escalation.","https:\u002F\u002Fgithub.com\u002FLyther\u002Fagent-surface\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-judger\u002FSKILL.md",[],[140,72,141,142,143,82],"workflow judger","merge","escalation","decide",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":151,"publishedAt":34},"01M6C5CDADZX0YM26H2QWWDJMF","workflow-doctor","Validate active workflow state before any role acts on it.","https:\u002F\u002Fgithub.com\u002FLyther\u002Fagent-surface\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-doctor\u002FSKILL.md",[150],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},[72,152,153,154,155,156,157,85],"workflow doctor","doctor","validate","state","active","it"]