{
  "markdown": "# Skills\n\n[![skills.sh](https://skills.sh/b/toy-crane/skills)](https://skills.sh/toy-crane/skills)\n\nA composable, model-agnostic set of skills for product definition, shaping,\nprototyping, task splitting, implementation, runtime verification, human\nreview, project knowledge, verified follow-up resolution, test-first\ndevelopment, writing publications and pieces, project skill updates with\ncross-client custom-agent synchronization, and safe Git delivery. Install selected skills or the complete plugin.\n\n## Install\n\nChoose copy-in installation or the managed plugin.\n\n### skills.sh (copy into your project)\n\nCopies selected skill folders into your project for local editing.\n\n```bash\nnpx skills@latest add toy-crane/skills\n```\n\nChoose the skills and coding agents to install.\n\nIf an existing copy was installed before the source catalog moved into the\n`git`, `workflow`, and `expo` groups, run the add command once more instead of\nrelying on `skills update`. The CLI tracks the exact upstream skill path, while\nthe reinstallation keeps the same skill names and refreshes that path.\n`update-project-skills` reports such entries instead of reinstalling them.\n\nThe product-context workflow replaces `discover-opportunity` with\n`define-product` and renames `compact-decisions` to\n`maintain-project-context`. A copy-in installation does not receive aliases for\nthe retired names; remove those old copied folders after installing the\nreplacements.\n\n### Project update (installed skills + companion agents)\n\nInstall `update-project-skills` once, then invoke it whenever a project should\nfollow the latest published skills:\n\n```bash\nnpx -y skills@latest add toy-crane/skills \\\n  --skill update-project-skills \\\n  --agent codex claude-code \\\n  -y\n```\n\nUse `/update-project-skills` in Claude Code or `$update-project-skills` in\nCodex. It updates every skill recorded in `skills-lock.json` through\n`skills update`, whatever its source, then reconciles the Toycrane set:\ninstalls newly published skills that apply to the project's stack, retires\nunpublished managed skills, and materializes any companion custom agents into\nboth `.claude/agents/` and `.codex/agents/`. Third-party skills are refreshed in\nplace only, and the locks preserve project-owned skills and agents unless the\nuser explicitly approves adopting a colliding name.\n\nThis is the cross-client installation path for companion agents. A skill folder\ncan carry their source payload, but neither client discovers that nested payload\nas a native custom agent on its own.\n\n### Claude Code plugin (managed bundle)\n\nInstalls the complete set as a read-only bundle. Updates arrive with new plugin\nversions.\n\nInside Claude Code:\n\n```\n/plugin marketplace add toy-crane/skills\n/plugin install toycrane-skills@toycrane\n```\n\nOr from your shell:\n\n```bash\nclaude plugin marketplace add toy-crane/skills\nclaude plugin install toycrane-skills@toycrane\n```\n\nThe plugin installs the managed skill bundle for Claude Code. Run the\nproject-local sync workflow above when the same project also needs companion\nagents in Claude Code and Codex.\n\n## The pipeline\n\nSix skills cover product definition through implementation.\n\n```mermaid\nflowchart LR\n    DP[\"define-product<br/>(rough direction known)\"] --> READY{\"whole direction clear<br/>without guessing?\"}\n    READY -- \"no\" --> ASK[\"ask about real use<br/>(no guessed answers)\"]\n    ASK --> READY\n    READY -- \"yes\" --> REQUEST{\"writing already<br/>requested?\"}\n    REQUEST -- \"yes\" --> PRODUCT[/PRODUCT.md/]\n    REQUEST -- \"no\" --> DRAFT[\"show the whole direction\"]\n    DRAFT --> CONFIRM{\"confirmed?\"}\n    CONFIRM -- \"not yet\" --> ASK\n    CONFIRM -- \"yes\" --> PRODUCT\n    PRODUCT -. \"read when present\" .-> SI[\"shape-idea<br/>(one work unit)\"]\n    SI --> BP[\"build-prototype<br/>(judge it by using it)\"]\n    SI --> SPEC[/spec folder/]\n    BP --> SPEC\n    SPEC --> ST[\"split-into-tasks<br/>(shallow outcome map)\"]\n    SPEC --> IM[\"implement<br/>(spec folder)\"]\n    ST --> IM\n    IM --> ONE[\"build one outcome\"]\n    ONE --> CHECK[\"check real behavior\"]\n    CHECK --> MATCH{\"still matches the spec<br/>and remaining tasks?\"}\n    MATCH -- \"technical facts changed\" --> UPDATE[\"update active tasks\"]\n    UPDATE --> ONE\n    MATCH -- \"work-unit promise changed\" --> SI\n    MATCH -- \"app premise changed\" --> DP\n    MATCH -- \"yes\" --> MORE{\"more outcomes?\"}\n    MORE -- \"yes\" --> ONE\n    MORE -- \"no\" --> FULL[\"full deterministic checks\"]\n    FULL --> REVIEW[\"complete one code review\"]\n    REVIEW -- \"result for intended diff\" --> TRIAGE{\"breaks a criterion or<br/>reproduces as a defect?\"}\n    REVIEW -- \"no completed result\" --> PENDING[\"review pending<br/>share verified result + blocker\"]\n    PENDING -- \"failure resolved or authority granted\" --> REVIEW\n    PENDING -- \"explicit user waiver\" --> FINAL\n    TRIAGE -- \"yes\" --> FIX[\"repair, recheck<br/>(no second review)\"]\n    FIX --> FINAL[\"final changed/core loop<br/>on every claimed platform\"]\n    TRIAGE -- \"no\" --> REC[\"record: follow-up,<br/>note, or user decision\"]\n    REC --> FINAL\n    FINAL -- \"in-scope defect\" --> FIX\n    FINAL -- \"blocked\" --> BLOCKED[\"runtime pending<br/>share evidence + prerequisite\"]\n    BLOCKED -- \"prerequisite restored\" --> FINAL\n    FINAL -- \"passes\" --> DONE[\"verified and runnable<br/>reviewed or explicitly waived\"]\n    IM -. \"uses at public seams\" .-> TDD[tdd]\n    IM -. \"proves affected surfaces\" .-> RV[\"matching runtime skill<br/>or strongest usable path\"]\n    IM -. \"open workaround or<br/>out-of-scope defect\" .-> FU[\"follow-up\"]\n```\n\nInvoke `define-product` when starting a from-scratch app whose rough direction\nor problem is already known. It starts from a concrete use scene and draws out\nthe user's product meaning instead of filling gaps from the initial solution\nidea. After the complete direction is confirmed, it creates or revises root\n`PRODUCT.md` with the users and situations, problem and alternatives, promised\nchange, core loop, capabilities and boundaries, experience principles, success\nsignals, assumptions, and unknowns. Blank-page idea discovery is outside this\nworkflow.\n\nStart with `shape-idea` when one concrete problem and broad work-unit direction\nare already known. It reads `PRODUCT.md` when present but remains independently\nusable when the file is absent, and it neither creates nor edits app-level\nproduct context.\n\n`shape-idea` records one stable product contract in\n`docs/specs/<slug>/spec.md`: user-visible outcomes, scope, observable acceptance\ncriteria, settled constraints and rationale, assumptions, off-limits areas and\nreasons, deferrals, and risks. `build-prototype` can start from the current\nconversation alone; when a whole interface is approved and consequential\nnon-visual behavior is settled or explicitly deferred, it creates or updates\nthat same contract and preserves `prototype.html` beside it. Use\n`split-into-tasks` only\nwhen the spec contains outcomes that should be delivered separately. It also\ncreates the complete shallow outcome map without predicting files, functions,\ncode structure, or a step-by-step implementation sequence. It marks only the\nfew intermediate reviews justified by material or downstream risk.\n\nThen pass the spec folder to `implement`. Before each outcome, it reloads the\ncurrent spec, active unfinished tasks, and any completed or superseded task\nimplicated by current evidence, plus code, Git state, and verification evidence,\nthen plans only that outcome in detail. After focused verification, it checks\nthe observed result against the product contract and every active unfinished\ntask. It may update technical assumptions and affected active tasks when the\napproved product behavior stays the same. If an approved outcome, observable\nacceptance criterion, scope, or other product constraint must change, it stops\nand returns that exact decision to shaping. A task marked `completed` is\nreopened if later evidence shows its criteria no longer pass. When an approved\nbreakdown replaces historically completed work, its still-required obligations\nmove to the replacement; the old task remains only as inactive `superseded`\nevidence and cannot block or re-enter the delivery frontier.\n\nAfter every outcome passes that check, the current harness's automated\ncode-review process reads the integrated result once against the selected spec\nand acceptance criteria. `implement` picks the depth that change warrants, and\nits findings are triaged rather than looped: `implement` repairs only what\nbreaks an approved acceptance criterion or reproduces as a defect on an\nordinary path, then records the rest as follow-ups, disposed trade-offs, or\ndecisions the user owns. Completion requires a finished review of the intended\ndiff or an explicit user waiver; it does not require zero findings. Failed,\npartial, silent, or mistargeted attempts do not count as the one pass.\n`implement` recovers execution errors within the authorized scope and retries.\nIt accurately identifies any model service and source context, reuses existing\nuser authorization without asking again, and requests only missing authority.\nAn explicit policy denial requires a permitted safer path or the needed\nauthority before retrying. If review cannot finish, overall completion stays\npending while verified outcomes, the blocker, and the next action are provided.\nWhen the repository exposes the result through a\nuser-reviewable local server, `implement` verifies the changed surface and\nshares an address while leaving that server available until the user finishes\nreview or later delivery cleanup. `implement` uses `tdd` where behavior can be\nverified through public seams it selects from the agreed behavior and existing\ninterfaces. For an affected product surface, it\nuses an available matching runtime-verification skill. When none is available,\nit autonomously investigates the repository and current environment and builds\nthe strongest usable runtime path instead of asking the user to approve the\nmethod. After focused checks and reconciliation, it runs the complete\ndeterministic checks, then the whole-diff review and any must-fix repairs with\naffected verification. It finally verifies the changed flow and the\n`PRODUCT.md` core loop on every claimed platform, including when review is\nexplicitly waived; missing core-loop coverage is reported rather than invented.\nAn in-scope defect found at that final gate returns to repair, affected checks,\nand final verification of the repaired revision without a second review.\nCurrent-scope gaps stay in implementation. A workaround with an open root cause\nor an evidenced out-of-scope defect becomes a durable follow-up.\n\nPass the folder itself, not an individual spec or task file.\n\nClaude Code:\n\n```text\n/implement docs/specs/checkout/\n```\n\nCodex:\n\n```text\n$implement docs/specs/checkout/\n```\n\nThe handoff lives at one stable path:\n\n```text\ndocs/specs/checkout/\n├── spec.md\n├── prototype.html      # optional\n└── tasks/              # optional approved task files\n```\n\nInvoke the same folder again after an interruption. `implement` reconstructs\nprogress from the folder, Git, the current diff, and verification results; a\nnew session or a closing-message handoff is not required for correctness.\n\n- **[define-product](./skills/workflow/define-product/SKILL.md)**: Draw out the\n  product meaning behind a rough app direction, confirm it with the user, and\n  preserve it in one current root `PRODUCT.md`. Keep app-level users, problem,\n  promise, core loop, boundaries, experience principles, success signals,\n  assumptions, and unknowns available across later work units without\n  absorbing technical or feature-level detail.\n- **[shape-idea](./skills/workflow/shape-idea/SKILL.md)**: Clarify a chosen problem and\n  direction through correctable drafts, project evidence, and rendered UI\n  variants. Maintain project terms and write the stable product contract that\n  later task splitting and implementation must preserve.\n- **[build-prototype](./skills/workflow/build-prototype/SKILL.md)**: Build every screen in\n  one dummy-data HTML file using the project's design system, or the shell's\n  minimal style when none exists. Review the rendered screens and preserve the\n  approved prototype beside the same product contract used by shaping.\n- **[split-into-tasks](./skills/workflow/split-into-tasks/SKILL.md)**: Split an existing\n  spec into the complete shallow map of the fewest approved, independently\n  deliverable vertical tasks, without predicting code-level implementation.\n  Include explicit blockers, acceptance criteria, focused verification, minimal\n  state, and only risk-justified intermediate review checkpoints, each one\n  bounded review pass.\n  Adapted from [mattpocock/skills](https://github.com/mattpocock/skills) (MIT).\n- **[babysit-specs](./skills/workflow/babysit-specs/SKILL.md)**: Bring queued spec\n  folders back in line with what shipped since their last commit. Fix the\n  staleness that preserves the approved meaning as an overridable assumption,\n  ask one question about each point that would change it, and hand affected\n  tasks, drifted prototypes, and retirement candidates to their owners without\n  editing product source.\n- **[implement](./skills/workflow/implement/SKILL.md)**: Implement an approved spec\n  folder one outcome at a time. Reload repository evidence before each outcome,\n  reconcile verified behavior with the product contract and active unfinished\n  tasks, ignore superseded history unless current evidence implicates it, reopen\n  invalidated work, and return to shaping when a product decision must change.\n  Then finish with full verification and one completed, triaged automated\n  review, unless explicitly waived by the user. Recover review execution\n  failures and reuse granted authority; blocked review leaves completion pending\n  while the verified result and runnable product address remain available.\n- **[tdd](./skills/workflow/tdd/SKILL.md)**: Select public test seams from the agreed\n  behavior and existing interfaces, then implement one red → green slice at a\n  time. Includes rules for stable seams and behavioral tests.\n  Adapted from\n  [mattpocock/skills](https://github.com/mattpocock/skills) (MIT).\n\n## The writing pipeline\n\nThree skills carry the same premise → brief → draft structure over to prose,\nfor a publication that lives in the same repository as its code, such as a\nproduct blog inside a monorepo. They share `GLOSSARY.md`,\n`docs/decisions/README.md`, and `project-knowledge` with the code pipeline, so\na piece about the product uses the product's own terms.\n\n```mermaid\nflowchart LR\n    DPUB[\"define-publication<br/>(one medium)\"] --> PUB[/\"docs/publications/&lt;slug&gt;.md\"/]\n    PUB -. \"read when briefing\" .-> DPI[\"define-piece<br/>(one topic)\"]\n    DPI --> BRIEF[/\"docs/briefs/&lt;slug&gt;/brief.md\"/]\n    BRIEF --> DR[\"draft-piece<br/>(brief folder)\"]\n    DR --> SEC[\"write one section,<br/>run its code\"]\n    SEC --> CHANGE{\"thesis, reader, or<br/>scope must change?\"}\n    CHANGE -- \"yes\" --> DPI\n    CHANGE -- \"no\" --> MORE{\"more sections?\"}\n    MORE -- \"yes\" --> SEC\n    MORE -- \"no\" --> CHECK[\"reader questions by a<br/>fresh-context agent<br/>+ every marked command runs\"]\n    CHECK --> FIX[\"revise once:<br/>failed questions and facts only\"]\n    FIX --> HAND[\"draft at the content location<br/>+ local preview\"]\n    HAND -. \"after the user reads\" .-> GIT[\"commit / pr\"]\n```\n\nSkill bodies are medium-neutral. Everything that differs by medium, such as\nform, length, where finished pieces live, how they are previewed, and what\nevidences a finished piece, lives in the publication file, so a newsletter or\nbrand site later adds a file rather than a skill.\n\n- **[define-publication](./skills/writing/define-publication/SKILL.md)**: Interview\n  the user about one medium's readers, promised change, voice, coverage,\n  conventions, and evidence, then preserve the confirmed premise in\n  `docs/publications/<slug>.md`, one file per medium. Recommend voice with a\n  short sample paragraph and retain the accepted example.\n- **[define-piece](./skills/writing/define-piece/SKILL.md)**: Turn one topic into a\n  confirmed brief through correctable candidates: thesis, titles, outline,\n  three to five checkable reader questions, scope, material, and which code is\n  execution-checked. Reuse confirmed writing criteria and preserve feedback as\n  it is settled. Writes no body prose into the brief.\n- **[draft-piece](./skills/writing/draft-piece/SKILL.md)**: Write the piece from its\n  brief folder section by section, running embedded code as it is written.\n  Verify with a fresh-context agent answering the reader questions and with\n  every marked command, and compare confirmed writing criteria. Use one bounded\n  automatic revision, preview locally, and stop before commit. Later user\n  corrections, including edits to an article without a brief, preserve scoped\n  reusable feedback in the repository for either Claude or Codex to read.\n\nClaude Code:\n\n```text\n/draft-piece docs/briefs/monorepo-move/\n```\n\nCodex:\n\n```text\n$draft-piece docs/briefs/monorepo-move/\n```\n\n## Git delivery\n\nFive standalone skills cover the repository handoff from a local change to a\nmerged base branch, and a sixth clears the worktrees that pile up afterward.\nInvoke them directly with `/commit`, `/pull`, `/push`, `/pr`, `/merge`, or\n`/clean-worktrees` in Claude Code and `$commit`, `$pull`, `$push`, `$pr`,\n`$merge`, or `$clean-worktrees` in Codex.\n\nWhen Codex exposes the managed plugin namespace, or a user-level skill with the\nsame short name is also installed, use `$toycrane-skills:commit`,\n`$toycrane-skills:pull`, `$toycrane-skills:push`, `$toycrane-skills:pr`,\n`$toycrane-skills:merge`, or `$toycrane-skills:clean-worktrees` to select this\nbundle unambiguously.\n\n```mermaid\nflowchart LR\n    C[\"commit<br/>record in-scope changes\"] --> P[\"push<br/>publish existing commits\"]\n    P --> PR[\"pr<br/>open ready-for-review PR\"]\n    PR --> M[\"merge<br/>verify merge and clean up\"]\n    L[\"pull<br/>rebase onto remote base\"] -. \"synchronize when needed\" .-> C\n    L -. \"synchronize when needed\" .-> P\n```\n\nEach skill is independently installable and owns its whole advertised outcome.\n`push` deliberately leaves dirty changes local. `pr` may perform the necessary\ncommit, synchronization, and publication, but stops before merge. `merge`\ncontinues through verified remote merge and cleans up only the merged worktree,\nreleasing its resources through the project's declared cleanup commands.\n\n- **[commit](./skills/git/commit/SKILL.md)**: Record only the current request's\n  changes as logical Conventional Commits while preserving unrelated work.\n- **[pull](./skills/git/pull/SKILL.md)**: Rebase the current checkout onto the fetched\n  requested base, or remote default, without treating a dirty tree as permission\n  to modify local work.\n- **[push](./skills/git/push/SKILL.md)**: Publish existing commits on a named branch,\n  reconciling remote state and using lease protection for intentional rewrites.\n- **[pr](./skills/git/pr/SKILL.md)**: Turn the current change into a ready-for-review\n  GitHub pull request with a proportionate behavior explanation, verification\n  evidence, and attached before-and-after screen comparisons when applicable;\n  return its URL without merging it. With an issue tracker configured, first\n  create the issue for each carried spec folder that has no `Issue:` line and\n  commit that line.\n- **[merge](./skills/git/merge/SKILL.md)**: Carry a change through verified pull\n  request merge with the same self-contained body and visual-evidence guidance,\n  choose squash or rebase by commit meaning, then safely clean up the merged\n  worktree with the project's declared cleanup commands.\n- **[clean-worktrees](./skills/git/clean-worktrees/SKILL.md)**: Sweep a\n  repository's accumulated worktrees in one pass. Remove those whose pull\n  request merged or closed, detached ones the base already contains, and\n  left-over folders that lost their Git registration; report open,\n  uncommitted, session-attached, and Codex-managed ones with the reason they\n  stayed.\n\nA project that gives each worktree its own servers, devices, or databases\ndeclares how to release them in `AGENTS.md` or `CLAUDE.md`. `merge` and\n`clean-worktrees` run the commands in order inside a worktree before removing\nit. Without the section they stop no process, and they leave a worktree that\nanother session or terminal still uses.\n\n````md\n## Worktree cleanup\n\nRelease this worktree's development resources. Agents run these from the worktree root.\n\n```sh\nbun run dev:remove\nbun run db:remove\n```\n````\n\n## Supporting workflows\n\nTen additional skills can run independently. They handle stack setup, issue\ntracker coordination for parallel spec work, Expo runtime verification,\npre-delivery both-platform checks, cross-client skill and agent\nsynchronization, incremental project knowledge, verified follow-up resolution,\nvisual explanation, final human judgment, and periodic context maintenance.\n`implement` also uses a matching runtime-verification skill when one is\navailable for an affected product surface.\n\n- **[add-stack-context](./skills/workflow/add-stack-context/SKILL.md)**: Audit the\n  technologies that define a project's stack, discover vendor-controlled skills,\n  keep changing official guidance live, and surface community skills for\n  approval. Runs during agent setup, after stack changes, or on entering an\n  unaudited project.\n- **[setup-issue-tracker](./skills/workflow/setup-issue-tracker/SKILL.md)**: Record\n  once per repository which issue tracker coordinates spec folders and, when\n  requested, general-issue triage. Each spec folder names its one issue with an\n  `Issue:` line: the PR that first carries the folder creates the issue, and a\n  spec that starts from an existing issue records that one. Every lookup uses\n  the recorded ID. `implement` claims the issue, and context maintenance repairs\n  drift. Without the convention every skill behaves as before.\n- **[triage-issues](./skills/workflow/triage-issues/SKILL.md)**: On a schedule or\n  by hand, handle one named issue or up to three new human-written issues no\n  earlier run triaged, including Backlog, each once.\n  Investigate and raise one verified implementation or spec PR when ready, or\n  ask for only the missing information or product decision with evidence.\n  Preserve the original issue throughout and prevent competing runs from\n  handling it together through an atomic remote claim.\n- **[expo-dev-loop](./skills/expo/expo-dev-loop/SKILL.md)**: Verify Expo and React\n  Native changes in a running app with `agent-device`, first proving target\n  readiness and the scenario's required state, then selecting Metro reload or\n  native rebuild and completing only with device evidence.\n- **[expo-smoke-test](./skills/expo/expo-smoke-test/SKILL.md)**: Before delivery,\n  prepare a known-app, fresh-device, or preserved-prior state as the scenario\n  requires, then drive the current change and the `PRODUCT.md` core loop on iOS\n  and Android development builds through one isolated `expo-smoke-runner` per\n  platform.\n- **[update-project-skills](./skills/workflow/update-project-skills/SKILL.md)**:\n  Update every skill installed in the project to its latest published version\n  with `skills.sh`, reconcile the Toycrane set, and install, refresh, or retire\n  its project-local companion agents for both Claude Code and Codex without\n  taking ownership of unrelated artifacts.\n- **[project-knowledge](./skills/workflow/project-knowledge/SKILL.md)**: Maintain project\n  terms and settled decisions that future work should reuse whenever they are\n  taking shape, including while a plan weighs alternatives. Keeps root\n  `DESIGN.md`, the entry point for design work, mapped to the contracts that\n  own each on-screen element. Does not run for lookup, routine implementation\n  details, or execution of settled decisions.\n- **[resolve-follow-ups](./skills/workflow/resolve-follow-ups/SKILL.md)**: Sweep\n  evidence-backed `docs/follow-ups/` items in bounded batches, reproduce each\n  symptom before editing, and publish verified fixes as independent\n  worktree-isolated pull requests without automatic merge.\n- **[explain-visually](./skills/workflow/explain-visually/SKILL.md)**: Render explanations\n  with the best available tool. Use one sentence instead when one sentence fully\n  answers the question.\n- **[human-review](./skills/workflow/human-review/SKILL.md)**: Help a human understand\n  AI-authored work through before-and-after behavior and nearby evidence. Keep\n  the whole change available to inspect, surface unsettled choices, and leave\n  a clear place to resume after switching tasks.\n- **[maintain-project-context](./skills/workflow/maintain-project-context/SKILL.md)**:\n  Periodically reconcile `PRODUCT.md`, the glossary, decision contracts, shipped\n  specs, agent instructions, and any configured spec issues after work\n  accumulates. Apply only meaning that is already settled, refresh each spec\n  issue found by its `Issue:` line from the remote default branch, and leave\n  ambiguous conflicts for\n  explicit clarification.\n\n## Output styles\n\n- **[natural-korean](./output-styles/natural-korean.md)**: A Claude Code\n  response style for natural, spoken-register Korean instead of\n  translated-sounding Korean. Ships with the Claude Code plugin only —\n  skills.sh copies skill folders, not output styles. Select it with\n  `/output-style` after installing the plugin.\n\n## Acknowledgements\n\nThe skill-writing philosophy behind this project is deeply inspired by\n[Matt Pocock](https://github.com/mattpocock)'s work—especially his approach to\nmaking stochastic systems more predictable through clear, compact, and\ncheckable instructions. Thank you to Matt for articulating and openly sharing\nthese ideas through [mattpocock/skills](https://github.com/mattpocock/skills).\n\n## License\n\nMIT. See [LICENSE](./LICENSE).\n",
  "bytes": 25852,
  "sha": "41ab258ddeea95a7b06335da09c665618c7388df1c6453e2da8ff5badf0e6ebf",
  "repo_slug": "toy-crane/skills",
  "fonte": "repo",
  "truncated": false,
  "api": "https://api.agentalog.com/api/listings/skl_toy_crane_skills_tdd_b5650c08/readme"
}