[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M72WHFBGG1VC35NNCTMFGCCD":3,"skill-same:01M72WHFBGG1VC35NNCTMFGCCD":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":31,"repositoryHtmlUrl":26,"repositoryHomepageUrl":32,"ownerHtmlUrl":33,"ownerBlogUrl":32,"ownerDescription":34,"updatedAt":35,"install":36,"resources":49},"01M72WHFBGG1VC35NNCTMFGCCD","architect",null,"Produces design and architecture work: frames a decision, weighs at least two alternatives with their trade-offs, maps the ripple effect of a change, writes Architecture Decision Records and RFCs, accounts for the bytes of a size-constrained plan, and reviews a plan or a spec with class-tagged findings. Use when a change touches several components, adds an abstraction, changes a shared contract or involves a migration, when asked for a design opinion, alternatives, a design review, an ADR, an RFC or a ripple-effect analysis, when a plan must fit a size budget, or when reviewing a plan or a spec as its reviewer. Trigger terms: design review, architecture, ADR, RFC, alternatives, trade-off, blast radius, ripple effect, plan review, byte budget. Not for implementing the change (developer), writing the spec (spec-author), reviewing a pull request (pr-reviewer) or writing documentation (doc-writer).","crewrig\u002Fcrewrig","crewrig","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F283580446?v=4","01M72WDBD9H0YW5JBHNZ0TEVWB","01M72WDBEBNRBAS94AXRPEVYNK",24,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002F.gemini\u002Fskills\u002Farchitect\u002FSKILL.md",[],[],"2026-11-10 22:39:42",false,"---\nname: architect\ndescription: \"Produces design and architecture work: frames a decision, weighs at least two alternatives with their trade-offs, maps the ripple effect of a change, writes Architecture Decision Records and RFCs, accounts for the bytes of a size-constrained plan, and reviews a plan or a spec with class-tagged findings. Use when a change touches several components, adds an abstraction, changes a shared contract or involves a migration, when asked for a design opinion, alternatives, a design review, an ADR, an RFC or a ripple-effect analysis, when a plan must fit a size budget, or when reviewing a plan or a spec as its reviewer. Trigger terms: design review, architecture, ADR, RFC, alternatives, trade-off, blast radius, ripple effect, plan review, byte budget. Not for implementing the change (developer), writing the spec (spec-author), reviewing a pull request (pr-reviewer) or writing documentation (doc-writer).\"\nlicense: Apache-2.0\ncompatibility: \"Requires Node >= 24 (scripts\u002Fmeasure-span.ts is a TypeScript file run with node) and the gh CLI (to post a plan review). The lint-verdict.ts script of the pr-reviewer skill is used when that skill is installed; a manual checklist replaces it otherwise.\"\nmetadata:\n  provenance:\n    canonical: \"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\"\n    feedback: \"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\"\n    version: \"2.0.1\"\n---\n\n\n# Architect\n\nBias toward fewer, simpler, more reversible designs. The skill exists to slow down at the right moment, not to add ceremony: a local, internal, reversible change does not need it, and the developer skill handles that.\n\nUse it when a change touches several modules or crosses a public contract, when an abstraction (interface, base class, plugin point, schema) or a migration is proposed, when someone asks for alternatives, a second opinion or an ADR, and when a plan or a spec is reviewed.\n\n## Operating mode\n\n### 1. Frame before proposing\n\nRestate the **goal** in one sentence, the **constraints** the user stated plus those the existing system implies (performance, security, compatibility, deadlines), and the **non-goal**. Solving the wrong problem is the costliest design error, so when the goal is too vague to frame, ask one question.\n\n### 2. Surface at least two alternatives\n\nA single proposal is a draft, not a design. For each non-trivial decision sketch two viable options and say in one line what each buys and what it costs:\n\n```text\nOption A: \u003Capproach>\n  Trade-off: \u003Cwhat A buys, at the cost of what>\nOption B: \u003Calternative>\n  Trade-off: \u003Cwhat B buys, at the cost of what>\nRecommendation: \u003CA or B>, because \u003Cthe constraint that breaks the tie>.\n```\n\nDo not invent a strawman to flatter the recommendation. When only one path is viable, say so and say why the others are not.\n\n### 3. Ripple-effect analysis\n\nFor the recommended option list the blast radius: the files and modules that change, the public contracts that shift (API, schema, CLI, environment variables), the downstream consumers (other repositories, services, agents) and the reversibility (trivial, awkward or one-way). A one-way change gets an ADR, an awkward one a migration plan, a trivial one neither: over-documenting is its own cost.\n\nWhen the change touches a skill's or an agent's `scripts\u002F`, the built copies of the CLI trees are regenerated by the repository's build and ship in the same commit, so name that step in the blast radius; leaving it out makes the components check fail.\n\u003C!-- crewrig-repo-only:start -->\nThe build script is `scripts\u002Fbuild-components.ts`; it exists only in the CrewRig repository.\n\u003C!-- crewrig-repo-only:end -->\n\n### 4. Byte accounting for size-constrained plans\n\nWhen a plan claims to bring something under a size, byte or token budget by moving, trimming or rewriting content, every savings figure comes from a measurement of the exact span, taken before the figure goes into the plan. Line counts and prose heuristics are not measurements, and a figure that is only a scoping estimate is labelled as one.\n\nRun `node scripts\u002Fmeasure-span.ts \u003Cfile> \u003Cfirst>-\u003Clast>... --current \u003Cbytes> --budget \u003Cbytes> --margin \u003Cbytes>` on the spans to move: it prints the exact bytes of each range, the total, the projected size and the margin. Exit `0` means the margin clears the threshold you set; exit `1` means a finding, either over budget or a margin thinner than the threshold, so add headroom (another candidate span) or flag the risk in the plan; exit `2` is a usage mistake; exit `3` means the file is unreadable or a range goes past its last line. State the threshold in the plan: a plan that lands 3 bytes under budget has no room for the next edit.\n\n### 5. Output formats\n\n| Output | When | Where |\n|---|---|---|\n| Inline summary | Local, reversible decision | Chat reply |\n| ADR (markdown) | One-way or contract change | `docs\u002Fadr\u002FNNNN-\u003Cslug>.md` |\n| RFC (issue) | Cross-team or cross-project | GitHub issue with label `rfc` |\n\nThe layout and numbering of an ADR come from the `doc-writer` skill: its `new-adr.ts` lays the ADR out and its `lint-adr.ts` checks it. That skill is a separate install, so when `doc-writer` is not installed say so explicitly and use the repository order, Status first, then Context, Decision and Consequences, the last listing the positive, negative and neutral effects. Keep each section short (the Context a few sentences, none over ten lines) and record the rejected alternatives. A Context that needs two pages means the decision is not crisp yet.\n\n### 6. Briefing sub-agents\n\nWhen delegating a focused task (tester, security, doc-writer) put the call-graph context of each file in the brief: the entry points that invoke it in production, the sibling scripts that share its lifecycle (pre-checks, cleanup, idempotency guards) and the preconditions the harness provides without enforcing them. Copy the relevant blast-radius rows verbatim. A brief that names one file in isolation produces false positives, such as a missing guard that an upstream sibling already provides; that is a brief defect, not a sub-agent defect.\n\n## Grounding discipline\n\nRead `references\u002Fshared-grounding-discipline.md`. In an ADR, an RFC or a design note, a claim about an environment variable, a command, a schema field, a path or a named guarantee (\"atomic\", \"idempotent\", \"stateless\") needs a source: a path with a line range, a command output or a sentence of the brief. A name you cannot trace is written as \"assumption — verify before relying on this\", or left out, never stated as a fact.\n\n## Finding class taxonomy\n\nRead `references\u002Fshared-finding-class-taxonomy.md`. When this skill reviews a plan or a spec, every finding it emits, blocking or not, carries exactly one `class:` line whose value is `tech`, `arch` or `spec`; when the class is ambiguous, escalate to the upstream class rather than defaulting to `tech`.\n\n## Reviewer seat\n\nPlan and spec reviews are seated: every pass is attributed to one seat, carries a `seat:` line and, from its second pass, reads a bounded scope (`docs\u002Freviewer-seat.md`). Two facts are specific to this skill:\n\n- **Plan reviewer** (`plan\u002F\u003Cticket>`): the `seat:` line goes right after the `### Verdict: …` line; identifiers are `v\u003CN>-F\u003CM>`; from pass two the verdict opens with a traceability audit of every prior identifier; plan `v2` and later are posted as deltas with a cumulative table.\n- **Spec reviewer** (`specs\u002F\u003Cticket>`): identifiers are `s\u003CN>-F\u003CM>`, where `\u003CN>` counts the seat's passes across every artifact; a delta-spec pull request is a replaced artifact, examined in full while every prior finding is still audited.\n\nA plan or verdict comment stays within 12288 bytes: check it with `wc -c \u003C comment.md`, and where the `pr-reviewer` skill is installed also with its `check-comment-size.ts` script. Check the verdict's format with the `lint-verdict.ts` script of the `pr-reviewer` skill, run as `node \u003Cthat skill's scripts directory>\u002Flint-verdict.ts --surface plan --transport plan --ordinal \u003CN> [--prior-ids \u003Cids>] \u003Cfile>`: exit `1` lists malformed tags, identifiers or a misplaced seat line to fix before posting.\n\nThat skill is a separate install, so look for it before relying on it. When it is absent, say so in the verdict (\"lint-verdict.ts not available: manual check\") and apply `references\u002Fverdict-manual-check.md` instead; skipping the check silently is not an option, since a malformed finding costs the author a round trip.\n\n## Friction\n\nRead `references\u002Fshared-friction-reporting.md`; when a signal fires, use the `harness-report` skill.\n","# Architect\n\nBias toward fewer, simpler, more reversible designs. The skill exists to slow down at the right moment, not to add ceremony: a local, internal, reversible change does not need it, and the developer skill handles that.\n\nUse it when a change touches several modules or crosses a public contract, when an abstraction (interface, base class, plugin point, schema) or a migration is proposed, when someone asks for alternatives, a second opinion or an ADR, and when a plan or a spec is reviewed.\n\n## Operating mode\n\n### 1. Frame before proposing\n\nRestate the **goal** in one sentence, the **constraints** the user stated plus those the existing system implies (performance, security, compatibility, deadlines), and the **non-goal**. Solving the wrong problem is the costliest design error, so when the goal is too vague to frame, ask one question.\n\n### 2. Surface at least two alternatives\n\nA single proposal is a draft, not a design. For each non-trivial decision sketch two viable options and say in one line what each buys and what it costs:\n\n```text\nOption A: \u003Capproach>\n  Trade-off: \u003Cwhat A buys, at the cost of what>\nOption B: \u003Calternative>\n  Trade-off: \u003Cwhat B buys, at the cost of what>\nRecommendation: \u003CA or B>, because \u003Cthe constraint that breaks the tie>.\n```\n\nDo not invent a strawman to flatter the recommendation. When only one path is viable, say so and say why the others are not.\n\n### 3. Ripple-effect analysis\n\nFor the recommended option list the blast radius: the files and modules that change, the public contracts that shift (API, schema, CLI, environment variables), the downstream consumers (other repositories, services, agents) and the reversibility (trivial, awkward or one-way). A one-way change gets an ADR, an awkward one a migration plan, a trivial one neither: over-documenting is its own cost.\n\nWhen the change touches a skill's or an agent's `scripts\u002F`, the built copies of the CLI trees are regenerated by the repository's build and ship in the same commit, so name that step in the blast radius; leaving it out makes the components check fail.\n\u003C!-- crewrig-repo-only:start -->\nThe build script is `scripts\u002Fbuild-components.ts`; it exists only in the CrewRig repository.\n\u003C!-- crewrig-repo-only:end -->\n\n### 4. Byte accounting for size-constrained plans\n\nWhen a plan claims to bring something under a size, byte or token budget by moving, trimming or rewriting content, every savings figure comes from a measurement of the exact span, taken before the figure goes into the plan. Line counts and prose heuristics are not measurements, and a figure that is only a scoping estimate is labelled as one.\n\nRun `node scripts\u002Fmeasure-span.ts \u003Cfile> \u003Cfirst>-\u003Clast>... --current \u003Cbytes> --budget \u003Cbytes> --margin \u003Cbytes>` on the spans to move: it prints the exact bytes of each range, the total, the projected size and the margin. Exit `0` means the margin clears the threshold you set; exit `1` means a finding, either over budget or a margin thinner than the threshold, so add headroom (another candidate span) or flag the risk in the plan; exit `2` is a usage mistake; exit `3` means the file is unreadable or a range goes past its last line. State the threshold in the plan: a plan that lands 3 bytes under budget has no room for the next edit.\n\n### 5. Output formats\n\n| Output | When | Where |\n|---|---|---|\n| Inline summary | Local, reversible decision | Chat reply |\n| ADR (markdown) | One-way or contract change | `docs\u002Fadr\u002FNNNN-\u003Cslug>.md` |\n| RFC (issue) | Cross-team or cross-project | GitHub issue with label `rfc` |\n\nThe layout and numbering of an ADR come from the `doc-writer` skill: its `new-adr.ts` lays the ADR out and its `lint-adr.ts` checks it. That skill is a separate install, so when `doc-writer` is not installed say so explicitly and use the repository order, Status first, then Context, Decision and Consequences, the last listing the positive, negative and neutral effects. Keep each section short (the Context a few sentences, none over ten lines) and record the rejected alternatives. A Context that needs two pages means the decision is not crisp yet.\n\n### 6. Briefing sub-agents\n\nWhen delegating a focused task (tester, security, doc-writer) put the call-graph context of each file in the brief: the entry points that invoke it in production, the sibling scripts that share its lifecycle (pre-checks, cleanup, idempotency guards) and the preconditions the harness provides without enforcing them. Copy the relevant blast-radius rows verbatim. A brief that names one file in isolation produces false positives, such as a missing guard that an upstream sibling already provides; that is a brief defect, not a sub-agent defect.\n\n## Grounding discipline\n\nRead `references\u002Fshared-grounding-discipline.md`. In an ADR, an RFC or a design note, a claim about an environment variable, a command, a schema field, a path or a named guarantee (\"atomic\", \"idempotent\", \"stateless\") needs a source: a path with a line range, a command output or a sentence of the brief. A name you cannot trace is written as \"assumption — verify before relying on this\", or left out, never stated as a fact.\n\n## Finding class taxonomy\n\nRead `references\u002Fshared-finding-class-taxonomy.md`. When this skill reviews a plan or a spec, every finding it emits, blocking or not, carries exactly one `class:` line whose value is `tech`, `arch` or `spec`; when the class is ambiguous, escalate to the upstream class rather than defaulting to `tech`.\n\n## Reviewer seat\n\nPlan and spec reviews are seated: every pass is attributed to one seat, carries a `seat:` line and, from its second pass, reads a bounded scope (`docs\u002Freviewer-seat.md`). Two facts are specific to this skill:\n\n- **Plan reviewer** (`plan\u002F\u003Cticket>`): the `seat:` line goes right after the `### Verdict: …` line; identifiers are `v\u003CN>-F\u003CM>`; from pass two the verdict opens with a traceability audit of every prior identifier; plan `v2` and later are posted as deltas with a cumulative table.\n- **Spec reviewer** (`specs\u002F\u003Cticket>`): identifiers are `s\u003CN>-F\u003CM>`, where `\u003CN>` counts the seat's passes across every artifact; a delta-spec pull request is a replaced artifact, examined in full while every prior finding is still audited.\n\nA plan or verdict comment stays within 12288 bytes: check it with `wc -c \u003C comment.md`, and where the `pr-reviewer` skill is installed also with its `check-comment-size.ts` script. Check the verdict's format with the `lint-verdict.ts` script of the `pr-reviewer` skill, run as `node \u003Cthat skill's scripts directory>\u002Flint-verdict.ts --surface plan --transport plan --ordinal \u003CN> [--prior-ids \u003Cids>] \u003Cfile>`: exit `1` lists malformed tags, identifiers or a misplaced seat line to fix before posting.\n\nThat skill is a separate install, so look for it before relying on it. When it is absent, say so in the verdict (\"lint-verdict.ts not available: manual check\") and apply `references\u002Fverdict-manual-check.md` instead; skipping the check silently is not an option, since a malformed finding costs the author a round trip.\n\n## Friction\n\nRead `references\u002Fshared-friction-reporting.md`; when a signal fires, use the `harness-report` skill.\n",{"name":5,"license":14,"metadata":23,"description":7,"compatibility":27},{"provenance":24},{"version":25,"feedback":26,"canonical":26},"2.0.1","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig","Requires Node >= 24 (scripts\u002Fmeasure-span.ts is a TypeScript file run with node) and the gh CLI (to post a plan review). The lint-verdict.ts script of the pr-reviewer skill is used when that skill is installed; a manual checklist replaces it otherwise.","main","6462aef9a402df0abfbb6ca7d7a060839ee8c474",".gemini\u002Fskills\u002Farchitect",6,"https:\u002F\u002Fcrewrig.org","https:\u002F\u002Fgithub.com\u002Fcrewrig","This is the organisation behind the crewrig framework","2026-11-15 04:46:08",{"source":8,"skillName":5,"commands":37,"prompt":47,"zipAvailable":48},[38,41,44],{"tool":39,"command":40},"npx","npx skills add crewrig\u002Fcrewrig --skill architect",{"tool":42,"command":43},"bunx","bunx skills add crewrig\u002Fcrewrig --skill architect",{"tool":45,"command":46},"pnpm","pnpm dlx skills add crewrig\u002Fcrewrig --skill architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002F.gemini\u002Fskills\u002Farchitect\u002FSKILL.md",true,[50,56,60,64,68],{"path":51,"resourceType":52,"resourceTypeDesc":53,"sizeBytes":54,"sourceHtmlUrl":55},"references\u002Fshared-finding-class-taxonomy.md","REFERENCE","参考文档",1287,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002F.gemini\u002Fskills\u002Farchitect\u002Freferences\u002Fshared-finding-class-taxonomy.md",{"path":57,"resourceType":52,"resourceTypeDesc":53,"sizeBytes":58,"sourceHtmlUrl":59},"references\u002Fshared-friction-reporting.md",769,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002F.gemini\u002Fskills\u002Farchitect\u002Freferences\u002Fshared-friction-reporting.md",{"path":61,"resourceType":52,"resourceTypeDesc":53,"sizeBytes":62,"sourceHtmlUrl":63},"references\u002Fshared-grounding-discipline.md",1656,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002F.gemini\u002Fskills\u002Farchitect\u002Freferences\u002Fshared-grounding-discipline.md",{"path":65,"resourceType":52,"resourceTypeDesc":53,"sizeBytes":66,"sourceHtmlUrl":67},"references\u002Fverdict-manual-check.md",2048,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002F.gemini\u002Fskills\u002Farchitect\u002Freferences\u002Fverdict-manual-check.md",{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"scripts\u002Fmeasure-span.ts","SCRIPT","脚本",7200,"https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002F.gemini\u002Fskills\u002Farchitect\u002Fscripts\u002Fmeasure-span.ts",[75,83,88,93,98,103],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":82},"01M76AJKRKGGYZFJJHKE32Q5ZZ","fixture","Fixture skill. Mentions scripts\u002Ffrontmatter-only.ts which must be ignored.","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Fyaml-example\u002FSKILL.md",[],[],"2026-11-12 13:55:43",{"skillNo":84,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":82},"01M76AJJHS0AHW5HJJQCVVJ4DH","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Funterminated\u002FSKILL.md",[],[],{"skillNo":89,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":82},"01M76AJH8VJ2NAE000285J1D8F","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Funresolved\u002FSKILL.md",[],[],{"skillNo":94,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":82},"01M76AJG4M862QH00H5QVVT60P","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Fstray\u002FSKILL.md",[],[],{"skillNo":99,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":82},"01M76AJEZKZVMWZXCKXCFNQQ6B","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Fresolving\u002FSKILL.md",[],[],{"skillNo":104,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":82},"01M76AJD4G4K2YK2SMN8NSEG9R","https:\u002F\u002Fgithub.com\u002Fcrewrig\u002Fcrewrig\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Fskill-scripts-citations\u002Freferences-unfenced\u002FSKILL.md",[],[]]