{
  "markdown": "# Planning Skills for Agents and Humans\n\nTurn a fuzzy feature into a selected, testable, vertically sliced implementation packet—without letting the agent invent scope.\n\nThese skills help product and engineering teams preserve intent from raw evidence through implementation. They are most useful for strategically important feature work with a bounded appetite, usually a 2–6 week bet for a small launch team.\n\n**New here? Start with the [10-minute guide](./docs/start-here.md).**\n\n## Interactive documentation portal\n\nThe repository includes a self-contained documentation portal at [`site/index.html`](./site/index.html). Download that one file and open it in a modern browser; it does not need a web server, package install, or network connection at runtime.\n\nThe portal includes the workflow explorer, searchable skills catalog, full guide reader, canonical skill references and templates, and example artifact trails. Its content is generated from this repository's canonical Markdown files and works offline after download. See [`site/README.md`](./site/README.md) for browser support, rebuild, and validation commands.\n\n## When should I use these skills?\n\nYou do not have to begin your idea inside this repo.\n\nStart wherever it is easiest to think: a conversation, whiteboard, document, Claude Design, Codex, rough prototype, pile of notes, a set of requirements, or a solution already in your head.\n\nUse these skills when the idea becomes important enough that you do not want its meaning to live only inside a conversation or disappear between prompts. This repo is the bridge between **playing with an idea** and **building it deliberately**.\n\nThat usually happens when:\n\n- there are several plausible ways to solve the problem\n- you already have a solution idea but do not yet know which needs or constraints it truly serves\n- a prototype looks promising, but you do not yet understand how it should behave\n- an agent is about to modify a real codebase\n- the work will take days or weeks rather than minutes\n- several people or agents need to share the same understanding\n- important requirements, boundaries, or decisions could easily be forgotten\n- you need to hand the work from exploration into implementation\n- implementation may be drifting away from the original intent\n\n### The core principle\n\n> **Start where the useful thinking already is. Exploration is fluid. Commitment is gated.**\n\nDuring collaborative shaping, you can start from requirements (**R-first**), a proposed solution (**S-first**), a prototype, current-system evidence, a fit question, or an unknown worth spiking.\n\nRequirements, shapes, fit checks, focused spikes, sketches, and candidate breadboards may inform one another in any useful order while they remain working material:\n\n```text\nrequirements (R) ↔ shapes (S) ↔ fit checks\n      ↑                ↕             │\n      └── discoveries ← spikes / candidate breadboards / sketches\n```\n\nWhat stays strict is promotion:\n\n- working requirements must be accepted before they judge final selection\n- Appetite and cut line must be accepted before shape selection\n- a human explicitly selects the direction\n- candidate evidence does not become selected-design intent without reconciliation\n- selected-design intent is accepted before slicing\n- a human-selected slice bounds implementation\n\nIf a team, CI harness, or multi-agent planner needs deterministic prerequisites, use the **gated/orchestrated profile** in `.agent-orchestration.yaml`. The formal route remains available; it is no longer the only legal order for exploration.\n\n### It is a mode switch, not necessarily a tool switch\n\nYou can use the same agent for exploration, planning, and implementation. What changes is what you ask it to do:\n\n- **Explore:** “Help me think through this idea. Show me possibilities.”\n- **Shape collaboratively:** “Capture what I have, separate requirements from mechanisms, and move among R, S, fit, spikes, and candidate breadboards as useful. Do not select for me.”\n- **Shape with strict gates:** “Use the gated profile and enforce each prerequisite before the next controlled step.”\n- **Build:** “Implement only this selected slice. Preserve these requirements and verify it against the breadboard.”\n\nA practical workflow is:\n\n1. Start with whatever you actually have: R, S, evidence, or a prototype.\n2. Use the smallest move that resolves the current uncertainty.\n3. Let working R and S revise one another through fit checks, spikes, sketches, and candidate breadboards.\n4. Accept requirements and Appetite when they are good enough to constrain a real decision.\n5. Make the human decisions about direction and scope.\n6. Reconcile the selected direction into accepted behavior.\n7. Give the coding agent a bounded slice and compact context packet.\n8. Check drift as implementation evolves.\n\nFor example, you might begin in Claude Design with a rough interface or in Claude Code with a solution idea. Capture that as candidate Shape A, extract provisional requirements from it, run a working fit check, spike the uncertain parts, breadboard only the behavior that is still hard to judge, then accept the judging criteria and Appetite before choosing a direction.\n\nIf you are using Claude Design together with the Planning Skills repository, see **[Using Claude Design with the Planning Skills Repository](./docs/claude-design-workflow.md)**.\n\nYou can also begin directly in Codex. For a small, obvious task, just make the change. For a larger or ambiguous task, tell Codex to use the relevant planning skill. You can choose collaborative shaping or the gated profile explicitly.\n\nDo not add planning ceremony where it provides no value. A small copy change, contained bug fix, disposable experiment, low-risk script, or already-clear change may not need the full workflow.\n\n> Use the smallest planning move that prevents an important misunderstanding.\n\n### Use the skills in the repository where the product is being built\n\nInstall or reference these skills once, then open the product repository you are actually working on. The Planning Skills repository supplies the method and reusable instructions; project-specific frames, shaping decisions, breadboards, slices, and implementation packets should normally live beside the product code they govern.\n\nDo not replace an existing project `AGENTS.md` with this repository's file. Prefer an installed plugin, point the agent at the relevant canonical `SKILL.md`, or selectively merge the planning rules that fit the project. Existing product-specific instructions remain authoritative for that codebase unless the team explicitly changes them.\n\nSee [Using Planning Skills in a product repository](./docs/using-in-a-product-repo.md) for the practical setup.\n\n### Recommended project layout\n\nA simple default is:\n\n```text\nplanning/\n  wayfinding/          # optional multi-session coordination maps and tickets\n  frame.md\n  shaping.md\n  appetite.md          # optional when the appetite needs its own decision record\n  candidate-A-breadboard.md  # optional exploratory evidence during shaping\n  breadboard.md        # accepted selected-design intent\n  sketch-reconciliation.md\n  statechart.md\n  slices.md\n  interface-contracts.md\n  executable-breadboard.md\n  dumplink.md\n  kickoff.md\n  context-packet.md\n  spikes/\n  runs/\n```\n\nThis is a convention, not a requirement. Keep one clearly active artifact for each authoritative planning level unless the project intentionally versions them. Candidate breadboards remain subordinate to their named candidate and shaping artifact. Preserve rejected alternatives in shaping, keep tables authoritative over generated diagrams, and treat run logs as audit records rather than product truth.\n\n### Choose the handoff artifact by its job\n\n| Artifact | Use it for |\n| --- | --- |\n| **Wayfinding map** | A low-resolution index of dependent planning questions across sessions. It coordinates work but never becomes product truth or an implementation backlog. |\n| **Appetite card** | The fixed time budget, cut line, accepted uncertainty, and revisit conditions that selection must fit. |\n| **Candidate-shape breadboard** | Exploratory evidence about one unselected shape when its behavior must be clarified. In collaborative mode it may use provisional judging inputs; it is never build scope. |\n| **Selected-design breadboard** | Accepted normative behavior after human selection and explicit reconciliation. |\n| **Kickoff document** | A durable, human-readable map of the shaped product territory. It is not the build sequence. |\n| **Executable breadboard** | The behavioral and test contract for one selected slice. |\n| **Dumplink plan** | A selected project decomposed into sequenced vertical task groups, with risk, dependencies, and appetite-based cuts. |\n| **Context packet** | The exact subset of authoritative planning material handed to the active implementation agent. |\n\nA common **controlled** path is: accepted criteria and Appetite → candidate shapes ↔ candidate breadboards or focused spikes when needed → human-selected shape and project boundary → accepted selected-design breadboard → optional Dumplink to create sequenced vertical task groups → human-selected active task group or other demoable slice → interface contracts and executable breadboard when needed → optional kickoff reference → context packet → implementation.\n\nThat path is useful for automation and teams that want stronger ceremony. Collaborative shaping may enter and move among R, S, fit, spikes, and candidate breadboards before those judging inputs are accepted. The same promotion gates apply before selection and build.\n\nSet Appetite before selecting a shape. Use the `Appetite` section in the [shaping template](./templates/shaping.md) for a compact decision or the standalone [appetite card](./templates/appetite-card.md) when ownership, rationale, and revisit conditions need their own record.\n\nAn estimate is not a prediction made before the work. It is the output of preliminary design work.\nFirst, decide how much the problem or opportunity is worth pursuing. That determines the time budget. Then dig into the problem, reduce the important unknowns, and shape a solution whose scope is commensurate with that budget.\nYou do not first estimate the ideal solution and then decide whether you can afford it. You decide what the opportunity is worth, then design the best solution that fits within that constraint.\n\n## Opportunity underwriting\n\nWhen the unresolved question is **whether a business or market opportunity is worth pursuing at all**—rather than what product to build—use the sibling **[Opportunity Underwriting for Agents and Humans](https://github.com/mattlane66/opportunity-underwriting-for-agents-and-humans)** repository.\n\nIts first canonical skill, **Market Opportunity Underwriting**, uses crux-first research, fatal gates, bottom-up sizing, explicit `NOT_KNOWABLE_FROM_DESK_RESEARCH` states, reachability rather than arbitrary “percent of TAM” SOM, and adversarial evidence to support a `PURSUE / TEST / HOLD / REJECT` decision. It is a business-level evidence and economics method, not a mandatory stage of this product-planning workflow.\n\nThe relationship is bidirectional rather than a conveyor belt. Opportunity Underwriting may invoke Lead User Research when a load-bearing uncertainty concerns future-facing needs, advanced users, emerging workarounds, or transferability. Lead User Research may in turn hand off to Opportunity Underwriting when it establishes an important need but the remaining question is whether that need constitutes a sufficiently large, reachable, economically attractive market. Neither research method automatically promotes its conclusions into accepted product-planning truth.\n\n## Lead User research\n\nFor future-facing opportunity discovery, use **[Lead User Research](./lead-user-research/README.md)**. It applies Eric von Hippel's Lead User Method through a lightweight, phase-gated research workflow with persistent evidence state, pyramiding, advanced analogs, coverage-bias controls, and proportionate SCOUT / STANDARD / FULL modes.\n\nIt is designed to work across ChatGPT, Claude, Gemini, Codex, Cursor, and other tool-using AI environments. For the lowest-friction path, copy the **[portable prompt](./lead-user-research/PORTABLE_PROMPT.md)** into the AI platform of your choice and fill in the research brief: domain/problem space, target market, what you want to understand, the human decision the research should inform, desired innovation altitude, optional hypotheses, and mode. You may also provide optional discovery seeds (sources, communities, files, people, experts), candidate-profile hypotheses (types of users or situations worth looking for), and explicit search constraints. Seeds and candidate profiles guide discovery without prequalifying Lead Users or closing the search universe unless the human explicitly imposes a constraint. The **[quick guide](./lead-user-research/QUICKSTART.md)** and **[fill-in research template](./lead-user-research/study-templates/research-input.md)** cover file-backed and no-file workflows. If only the domain and decision are known, Phase A can draft the missing fields as PROVISIONAL rather than silently inventing them. The full protocol stays available for audit without requiring one giant memory-dependent prompt.\n\nLead User Research is an optional upstream evidence lane, not a mandatory stage before framing. Use it when the opportunity itself depends on future-facing trend and advanced-user evidence. After completion, its implications require explicit human acceptance before they feed `framing-doc`; the research record remains cited evidence rather than automatically becoming product-planning truth.\n\nClaude Code and Gemini CLI provide `/lead-user` to start or resume the smallest valid phase, plus `/lead-user-frame`, `/lead-user-discover`, `/lead-user-evidence`, `/lead-user-freeze`, `/lead-user-interpret`, `/lead-user-shape`, `/lead-user-decide`, and `/lead-user-deliver` for explicit phase control. Codex and other skill-capable agents invoke the same canonical skill and name the phase in natural language. Every phase ends by recommending exactly one next move, looping back when sufficiency fails and skipping concept generation when no need passes the gate.\n\n## The core workflow\n\n### Collaborative shaping loop\n\n```text\nstart from R, S, evidence, prototype, fit question, or unknown\n  ↕\nrequirements ↔ shapes ↔ fit checks\n      ↕         ↕\n  focused spikes / sketches / candidate breadboards\n  ↕\naccept requirements + Appetite when decision-ready\n  → human selection\n  → reconcile selected direction into selected-design behavior\n  ↔ return to shaping if concrete behavior exposes a consequential conflict\n  → optionally model complex state\n  → select a demoable slice\n  → give the build agent bounded context\n  → check drift while building\n```\n\nWhen future-facing opportunity evidence is the active uncertainty, an optional Lead User study may precede this loop. It hands accepted evidence implications to framing; it does not force research in front of already-concrete product work.\n\n### Gated / orchestrated route\n\n```text\naccepted frame\n  → accepted requirements\n  → accepted Appetite\n  → candidate shapes\n  ↔ candidate breadboards or focused spikes when needed\n  → decision-ready fit checks\n  → human selection\n  → selected-design breadboard\n  → selected slice\n  → bounded context\n  → build\n```\n\nShaping and breadboarding are distinct but composable. Shaping owns working and accepted requirements, Appetite, comparison, focused spikes, and human selection. Breadboarding maps behavior in one of three modes:\n\n- `current-state` — descriptive evidence about what exists\n- `candidate-shape` — exploratory evidence about one unselected shape during shaping\n- `selected-design` — accepted normative intent after selection and reconciliation\n\nA candidate breadboard cannot select itself, produce build scope, or automatically become selected-design intent.\n\nWhen the bounded planning route itself is too large for one session, use Wayfinding as an outer loop around these moves. It keeps a shared frontier of decision, evidence, prototype, and prerequisite tickets while every accepted result still lands in the ordinary canonical artifact.\n\nWhen the opportunity itself is not yet grounded, the optional upstream move is\n[`lead-user-research`](./lead-user-research/SKILL.md). It produces an\nevidence-traceable research decision and a proposed handoff; a human must accept\nthe implications before they feed framing.\n\nThe three core moves are:\n\n| Move | Use it when | Output |\n| --- | --- | --- |\n| [`framing-doc`](./framing-doc/SKILL.md) | You have notes, transcripts, requests, or an unclear problem that cannot yet be judged honestly. | Source, current approach/result, problem, desired outcome, boundaries, and criteria candidates. |\n| [`shaping`](./shaping/SKILL.md) | You have R, S, mixed evidence, or a proposed solution and need to make the problem/solution space decision-ready. | Working and accepted R/S, Appetite, fit evidence, focused spikes, and a human-selected direction or decision-ready stop. |\n| [`breadboarding`](./breadboarding/SKILL.md) | Existing behavior needs an evidence map, one candidate needs behavioral clarification, or a selected direction needs to become concrete. | A declared current-state, candidate-shape, or selected-design map; only accepted selected-design mode produces slice candidates. |\n\nStart there. Add the advanced moves only when the work needs them.\n\n## Advanced workflow\n\n| Skill | Add it when | Output |\n| --- | --- | --- |\n| [`wayfinding`](./wayfinding/SKILL.md) | A bounded planning destination requires multiple dependent decisions or investigations across sessions. | A shared map, queryable frontier, precise tickets, fog, and exit check; never a second source of product truth. |\n| [`sketch-reconciliation`](./sketch-reconciliation/SKILL.md) | A sketch, screenshot, wireframe, mockup, or whiteboard may clarify or contradict accepted planning. | Visual observations mapped to stable IDs, explicit deltas, a human decision gate, and synchronized accepted updates. |\n| [`statechart`](./statechart/SKILL.md) | A selected portion of an accepted selected-design breadboard has retries, timeouts, approvals, lifecycle stages, or other state complexity. | A derived state inventory, transition table, Mermaid statechart, and explicit gaps. |\n| [`interface-contracts`](./interface-contracts/SKILL.md) | A selected slice crosses a meaningful data or system boundary. | Plain-language inputs, outputs, branches, errors, and open decisions. |\n| [`executable-breadboards`](./executable-breadboards/SKILL.md) | A slice needs fixtures, example runs, edge cases, and acceptance tests before build handoff. | A buildable, testable slice contract. |\n| [`dumplink`](./dumplink/SKILL.md) | A selected project needs to be decomposed into vertical task groups with dependency-aware sequencing, risk states, or appetite-based cuts. | A project-wide task-group plan; after human selection, one active group becomes the bounded implementation slice. |\n| [`kickoff-doc`](./kickoff-doc/SKILL.md) | Builders need a durable orientation reference after selected artifacts converge. | A builder-facing map that does not replace build scope or sequence. |\n| [`feed-planning-context`](./feed-planning-context/SKILL.md) | An implementation agent needs the exact relevant subset of the authoritative planning stack. | A compact context packet with an execution contract and verification target; working alternatives and candidate breadboards are excluded as build scope. |\n| [`breadboard-reflection`](./breadboard-reflection/SKILL.md) | Implementation exists and may differ from accepted intent. | Separate intent/reality records, drift evidence, design smells, and an explicit correction decision. |\n\nSee the [sketch reconciliation guide](./docs/sketch-reconciliation.md) for the visual-to-plan procedure and command examples.\n\n## First useful prompt\n\n```text\nUse this repository's planning workflow in collaborative mode.\n\nStart from whatever is already concrete in my material: requirements, a proposed solution, a prototype, current-system evidence, or a specific unknown.\nDuring shaping, move among R, S, fit checks, focused spikes, sketches, and candidate-shape breadboards whenever that is the smallest useful move.\nKeep working material separate from accepted intent.\nDo not force me through a fixed exploration sequence.\nDo not select a shape until requirements and Appetite are accepted and the comparison is decision-ready.\nDo not treat candidate evidence as selected intent or build scope.\nDo not implement until selected-design behavior or an equally clear accepted boundary and a demoable slice are explicitly selected.\n\nSource material:\n[paste notes, transcript, request, solution idea, screenshots, or links here]\n```\n\nFor deterministic automation, replace “collaborative mode” with “gated/orchestrated mode” and enforce `.agent-orchestration.yaml` prerequisites.\n\nThe tool-neutral operating rules live in [`AGENTS.md`](./AGENTS.md). The machine-readable profiles, modes, promotion gates, allowed outputs, forbidden moves, artifacts, and hooks live in [`.agent-orchestration.yaml`](./.agent-orchestration.yaml).\n\n## Why this exists\n\nAI coding tools can one-shot simple applications. Larger bets fail differently: the agent fills missing product decisions, requirements collapse into mechanisms, rejected ideas return as scope, exploratory evidence gets mistaken for accepted intent, or implementation silently drifts from the selected direction.\n\nThis repository makes the planning stack explicit enough for humans and agents to share:\n\n- what problem is being solved\n- which dependent planning questions remain open across sessions\n- which requirements are working versus accepted\n- which shape was selected and which were rejected\n- which breadboards are descriptive, exploratory, or selected intent\n- how the accepted behavior and state fit together\n- what the current slice includes and excludes\n- what the implementation agent must preserve\n- what proves the slice is complete\n- when reality requires the plan to change\n\nThe operating philosophy is in [The Work Should Get Clearer](./MANIFESTO.md).\n\n## Planning Skills, Spec Kit, and implementation harnesses\n\nThese tools address different layers:\n\n| Layer | Primary question |\n| --- | --- |\n| **Planning Skills** | What should we build, which path fits, and what intent must survive implementation? |\n| **Spec Kit** | How should the selected slice become an implementation-specific plan, task structure, and technical specification? |\n| **Implementation harnesses** | How should agents execute, test, review, and recover reliably inside a real codebase? |\n\nPlanning Skills is the upstream planning and alignment layer, not a replacement for either downstream category.\n\n![Human–Agent Software Factory](./docs/assets/human-agent-software-factory.svg)\n\n## Use across agent tools\n\nThe method is tool-agnostic. Invocation differs by environment:\n\n| Environment | Recommended surface |\n| --- | --- |\n| Claude Code | Plugin skills plus `.claude/commands/` wrappers |\n| Codex | Codex plugin, `AGENTS.md`, and prompt recipes |\n| Gemini CLI | `GEMINI.md` plus `.gemini/commands/` wrappers |\n| Claude / Claude Design | Uploadable canonical skills; request collaborative or gated mode in natural language |\n| MCP-compatible clients | The optional server under `mcp-server/` |\n| Cursor and other agents | `AGENTS.md`, canonical `SKILL.md` files, and templates |\n\nSee the [invocation matrix](./docs/agent-invocation-matrix.md) for exact mappings.\n\nFor a complete workflow that combines Claude Code and Claude Design, see **[Using Claude Design with the Planning Skills Repository](./docs/claude-design-workflow.md)**.\n\n### Claude Code\n\nClone the repository, build the complete plugin layout, and use the generated bundle:\n\n```bash\ngit clone https://github.com/mattlane66/planning-skills-for-agents-and-humans.git ~/.local/share/planning-skills-for-agents-and-humans\ncd ~/.local/share/planning-skills-for-agents-and-humans\nbash scripts/build-claude-plugin.sh\nclaude --plugin-dir dist/claude-code-plugin\n```\n\nPlugin entries are namespaced, for example `/planning-skills:frame`, `/planning-skills:shape`, and `/planning-skills:spike`.\n\nSee [Claude Code plugin guidance](./docs/claude-code-plugin.md) and [slash commands](./docs/claude-slash-commands.md).\n\n### Codex\n\nUse the packaged skills through [`.codex-plugin/plugin.json`](./.codex-plugin/plugin.json), with `AGENTS.md` as the repo-level instruction surface.\n\nSee [Codex plugin installation](./docs/codex-plugin.md) and [Codex prompt recipes](./docs/codex-usage.md).\n\n### Gemini CLI\n\nFor work on this Planning Skills repository, open it directly so `GEMINI.md` imports the shared agent instructions. For real product work, copy or symlink the needed skill folders into the product repository, or use the MCP adapter. The repo-local TOML commands are adapter examples: if you copy them, update their `@{...}` includes to the installed skill and support-file paths. Keep the product repository's own instructions authoritative.\n\nSee [Gemini CLI usage](./docs/gemini-usage.md) and the [Gemini/MCP integration guide](./integrations/gemini/README.md).\n\n### MCP server\n\n```bash\ncd mcp-server\nnpm ci\nnpm run check\nnpm start\n```\n\nSee the [MCP server README](./mcp-server/README.md) for client configuration and exposed tools.\n\n### Live Mermaid viewer\n\nWatch the diagrams in one or more planning artifacts and refresh them in a local browser after every save:\n\n```bash\nbash scripts/watch-planning-diagrams.sh examples/simple-grocery-list/03-breadboard.md\n```\n\nThe viewer uses a pinned local Mermaid package, binds to localhost, and uploads nothing. See [visual hot reload](./docs/visual-hot-reload.md).\n\n## Examples\n\n- [`simple-grocery-list`](./examples/simple-grocery-list/) is a deliberately small walkthrough of the foundational workflow.\n- [`existing-codebase-drift`](./examples/existing-codebase-drift/) demonstrates how to surface differences between an intended breadboard and implementation reality.\n- [`statechart-retry-workflow`](./examples/statechart-retry-workflow/) shows how to derive a traceable statechart when retries, cancellation, and timeouts make breadboard wiring harder to review.\n- [`sketch-reconciliation`](./examples/sketch-reconciliation/) shows how a dropped visual becomes mapped observations and accepted planning deltas without silently overriding the selected shape.\n- [`solution-first-shaping`](./examples/solution-first-shaping/) shows S-first collaborative shaping: rough Shape A → provisional R → working fit → spike / candidate evidence → accepted judging inputs → human selection.\n\nThese are teaching examples, not evidence of comparative model performance.\n\n## Repository integrity\n\nThe root skill folders are canonical. [`skill-inventory.txt`](./skill-inventory.txt) defines the complete set, and the `skills/` directory is generated packaging for plugin consumers.\n\nAfter changing a canonical skill:\n\n```bash\nbash scripts/sync-packaged-skills.sh\nbash scripts/check-repo-health.sh\n```\n\nThe health check verifies packaged-skill parity, manifest and artifact references, version parity, command wrappers, generated plugin output, the visual hot-reload viewer, and the MCP build and tests. See [CI health](./docs/ci-health-workflow.md).\n\nThe fixtures under `evals/` include structural contracts and deterministic behavior-runner checks; real model runs remain runtime-specific evaluations rather than universal benchmarks.\n\nSee [Contributing](./CONTRIBUTING.md) for the development and review workflow. Report vulnerabilities through the private process in the [Security Policy](./SECURITY.md), not through a public issue.\n\n## License\n\nReleased under the [MIT License](./LICENSE).\n\n## Optional lightweight demo\n\nFor a quick conversational feel before installing the repository, try the [Shape to Slice Assistant](https://chatgpt.com/g/g-699222e353288191afb01ea178db6da6-shape-to-slice-assistant).\n",
  "bytes": 28104,
  "sha": "e22e26530bb8f31f98c338416b01c07e0c84b3d3071273179e20a456227ed160",
  "repo_slug": "mattlane66/planning-skills-for-agents-and-humans",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_mattlane66_planning_skills_for_agents_an_d7bc92f0/readme"
}