[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H86SA421D0BC4JF9TXT0HT":3,"skill-same:01M6H86SA421D0BC4JF9TXT0HT":74},{"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":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":14,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":73},"01M6H86SA421D0BC4JF9TXT0HT","chat-to-approach",null,"Converts a pasted AI conversation summary or transcript into a canonical alignment document at .\u002Fdocs\u002Fapproach.md — the single source of truth for what we are building and why. Grills only on ambiguities, conflicts and deltas, never on settled decisions. The doc is portfolio-level: it holds many features at once, which \u002Fto-roadmap prioritises into a Now\u002FNext\u002FLater board before each feature runs the per-feature spine on its own. For a single already-chosen feature, use \u002Fto-prd instead.","O-Marsters-1997\u002Fmy-claude-code","O-Marsters-1997","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72571979?v=4","01M6H800V7V9BSXYZKDM0JXTJ2","Olly Marsters","01M6H800ZYDJR42TNRH0E6ZVZ7",0,"MIT","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fchat-to-approach\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"to approach","chat to approach","chat","single source of truth","transcript","single","for","which","true","conversation summary","now","feature","conversation","document","conflicts","alignment","deltas","roadmap","only","never","use","decisions","2026-11-10 10:12:30",false,"---\nname: chat-to-approach\ndescription: >\n  Converts a pasted AI conversation summary or transcript into a canonical alignment document at\n  .\u002Fdocs\u002Fapproach.md — the single source of truth for what we are building and why. Grills only\n  on ambiguities, conflicts and deltas, never on settled decisions. The doc is portfolio-level:\n  it holds many features at once, which \u002Fto-roadmap prioritises into a Now\u002FNext\u002FLater board\n  before each feature runs the per-feature spine on its own. For a single already-chosen\n  feature, use \u002Fto-prd instead.\ndisable-model-invocation: true\n---\n\n## Overview\n\nParse a pasted AI conversation summary into a structured, persistent alignment document: `.\u002Fdocs\u002Fapproach.md`. This is the canonical record of **what we are building and why** — agreed features, constraints, principles, and open questions. It is not a roadmap (no priority tiers) and not a PRD (no implementation detail). It is the alignment checkpoint between ideation and execution.\n\nIf `.\u002Fdocs\u002Fapproach.md` already exists, it is treated as prior settled truth. Only net-new items and conflicts require grilling — not things the doc already covers.\n\nOnce this doc exists, run `to-roadmap` to generate a kanban board without repeating the grilling —\nthen pick one card and run `to-prd` on it.\n\n## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                             ^^^^^^^^^^^^^^^^ you are here\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 non-code work: to-prd → to-tickets\n```\n\n**Portfolio → feature is a fan-out, not a step.** This doc holds *every* feature under\nconsideration. A roadmap card is one of those features — something to be built, which the spine\nlater breaks into several tickets. Six features here means six independent runs down the spine.\n\n**Never send the user backwards.** A missing upstream artifact is written inline or offered, never a\nreason to stop and run another skill first. The one hard gate is an approved plan. A user who\nalready knows the one feature they want can skip straight to `to-prd`.\n\n**Optional: Background Research section.** `approach.md` may contain a `## Background Research` section at the top, produced by the `source-synthesis` skill, containing a lit-review synthesis of existing documentation and prior art. This skill does not create or modify that section — it is out of scope here. If the section exists, preserve it verbatim when writing or updating the file.\n\nSolo\u002Findie-builder scale throughout.\n\n---\n\n## What Is a Feature (at Alignment Level)?\n\nA feature is a coherent, user-facing capability that delivers value on its own. It is not an implementation task, a ticket, or a technical decision.\n\n**Anatomy of an alignment-level feature:**\n\n| Field            | What it captures                                  | Example                                                      |\n| ---------------- | ------------------------------------------------- | ------------------------------------------------------------ |\n| **Name**         | Short, user-facing label — what it does, not how  | \"User authentication\"                                        |\n| **Problem**      | The user pain or need it addresses (one sentence) | \"Users need to log in securely to access their data\"         |\n| **Value**        | What it unlocks or enables                        | \"Unblocks all personalisation and data persistence features\" |\n| **Dependencies** | Other features that must exist first              | \"Requires: database setup\"                                   |\n\nOnly Name + Problem are required. Value and Dependencies are included when they matter for understanding what we're building.\n\n**How to group chat content into a feature:**\n\n- A feature = a cluster of related decisions that together describe one user-facing capability\n- Multiple small decisions about the same area → one feature, not many entries\n- Ask: \"Could a user describe what they'd get from this in one sentence?\" If yes, it's a feature\n- Distinguish features from:\n  - _Constraints_ — architectural or technical decisions that shape features but aren't features themselves (e.g. \"use Postgres\") — record in Constraints, not Features\n  - _Tasks_ — implementation steps inside a feature (e.g. \"wire up the ORM\") — not captured here; `to-tickets` handles this later\n  - _Principles_ — values the user expressed (\"keep it simple\", \"mobile-first\") — capture in Principles, not Features\n\n**Anti-patterns to avoid:**\n\n- Don't split one feature into multiple entries because the conversation touched it in different ways\n- Don't create an entry for every distinct sentence — synthesise first\n- Don't mistake a technical decision for a feature (\"use JWT\" is a constraint; \"user sessions\" is a feature)\n\n---\n\n## Phase 1 — Parse the Conversation\n\nRead the pasted transcript or summary carefully. Classify everything into four buckets:\n\n**Decided\u002Fcommitted** — Both parties agreed and committed to something. Look for language like \"we'll do X\", \"let's go with Y\", \"agreed: Z\", \"the plan is\", \"I'll build\", \"we'll ship\". These become candidates for approach.md.\n\n**Discussed but not resolved** — Ideas that came up, were explored, but didn't reach a clear conclusion. Do not silently drop these. Surface them for grilling in Phase 3. **An idea not explicitly accepted is not the same as an idea that was rejected.**\n\n**Explicitly discarded** — Ideas the user or conversation actively rejected or dismissed in favour of something else. Look for language like \"no, let's not\", \"actually scratch that\", \"we're not doing X\", \"that's out of scope\". These go into the \"Out of scope\" section of the doc, not into Features.\n\n**Open questions** — Things that need a decision before work can proceed. These go into the \"Open questions\" section verbatim.\n\n**Default to inclusion over exclusion.** When in doubt, treat something as either a candidate feature (pending grilling) or an open question. An approach doc that surfaces ambiguity honestly is better than one that silently drops things the user cared about.\n\n---\n\n## Phase 2 — Load Existing approach.md (If Present)\n\nCheck for an existing `.\u002Fdocs\u002Fapproach.md`. Two paths:\n\n**No existing file:** proceed directly to Phase 3 with all \"decided\u002Fcommitted\" items as candidates.\n\n**Existing file found:** read it fully, then compute the delta against the parsed chat:\n\n- **Net new** — features, constraints, or principles in the chat that aren't yet in the doc → grill if ambiguous, otherwise add directly\n- **Conflicts** — the chat contradicts something the doc already records (e.g. doc says JWT, chat says sessions) → always grill; present both versions\n- **Supersedes** — the chat clearly updates or replaces a prior decision → treat as conflict requiring explicit confirmation before updating\n- **Already covered** — the chat repeats what the doc already has → ignore; do not re-grill\n\nItems already settled in the existing doc are **treated as prior truth**. Do not re-open them unless the new chat explicitly contradicts them.\n\n---\n\n## Phase 3 — Alignment Grilling (Safeguard)\n\nBefore writing anything, run a focused grilling session using the `grilling` skill. This is the safeguard: stress-test the extraction before committing it to a durable file. `grilling` owns the grilling loop — defer to it rather than re-running the questioning yourself. This section only scopes *what* to grill; the *how* lives in `grilling`.\n\nGrill only on:\n\n- Items in the \"discussed but not resolved\" bucket\n- Conflicts between the chat and the existing doc\n- Items with ambiguous scope (\"improve X\", \"think about Y\") — is there a concrete feature here?\n- Items where it's unclear whether something is a feature, constraint, or principle\n- Items that could be the same feature described differently at two points in the conversation\n\nDo NOT grill on:\n\n- Items clearly decided in the conversation\n- Items already settled in the existing approach.md (unless the new chat conflicts with them)\n- Items that are clearly constraints, principles, or out-of-scope — classify and move on\n\nKeep grilling lean — only ask if the answer would meaningfully change what ends up in the doc. If the conversation was explicit and decisive throughout, tell the user and skip straight to Phase 4.\n\n---\n\n## Phase 4 — Write \u002F Merge .\u002Fdocs\u002Fapproach.md\n\nWrite or update the file. If `.\u002Fdocs\u002F` doesn't exist, create it.\n\n**When creating a new file:** write all sections, even if some are empty (e.g. \"No constraints recorded yet.\").\n\n**When updating an existing file:** only replace the content of sections that changed. Preserve sections untouched by the new chat verbatim. Update the \"Last updated\" line.\n\n### Document structure\n\n```markdown\n# Approach\n\n_Last updated: \u003CYYYY-MM-DD> · Canonical alignment doc — what we are building and why._\n\n## Background Research\n\u003C!-- Optional. Produced by source-synthesis, not this skill. Preserve verbatim if present. -->\n\n## Problem\n\n\u003COne paragraph: who has the pain, what the pain is, why it matters now.>\n\n## Goals\n\n- \u003COutcome-oriented goal, one per line>\n\n## Non-goals\n\n- \u003CExplicitly out of scope, one per line — so they don't re-surface in future chats>\n\n## Features\n\nEach feature is a user-facing capability. No priority tiers — use to-roadmap for Now\u002FNext\u002FLater.\n\n### \u003CFeature name>\n\n- **Problem:** \u003Cone sentence — the user pain this solves>\n- **Value:** \u003Cwhat it unlocks or enables>\n- **Dependencies:** \u003Cother features required first, if any>\n\n## Constraints\n\nTechnical and architectural decisions that shape the work but aren't features.\n\n- \u003Ce.g. Use Postgres for persistence>\n- \u003Ce.g. JWT-based auth, stateless sessions>\n\n## Principles\n\nValues and preferences that should shape all decisions.\n\n- \u003Ce.g. Keep it simple — no enterprise PM overhead>\n- \u003Ce.g. Ship weekly — no multi-month batches>\n\n## Open questions\n\nThings that still need a decision before downstream work can proceed.\n\n1. \u003CQuestion>? — \u003COne line on why it matters or what's blocked on it.>\n\n## Out of scope\n\nIdeas explicitly rejected in conversation, recorded so they don't resurface.\n\n- \u003CRejected idea> — \u003Cbrief note on why it was cut>\n```\n\n**What does NOT belong here:** Now\u002FNext\u002FLater tiers, story points, assignees, implementation tasks, ticket breakdowns, acceptance criteria. These are downstream concerns.\n\n---\n\n## Finishing Up\n\nAfter writing the file, send a brief receipt (3–5 lines max):\n\n- Number of features captured\n- Number of conflicts resolved during grilling (if any)\n- Number of open questions outstanding\n- A one-liner on anything placed in \"Out of scope\" — so the user knows you didn't silently drop things they cared about\n- Reminder: run `to-roadmap` to generate a visual kanban from this doc without repeating grilling\n\nWhen finished, ask: 'Would you like to log feedback? (yes\u002Fno)'. If yes, invoke skill-feedback-collector passing this skill's name and path.\n","## Overview\n\nParse a pasted AI conversation summary into a structured, persistent alignment document: `.\u002Fdocs\u002Fapproach.md`. This is the canonical record of **what we are building and why** — agreed features, constraints, principles, and open questions. It is not a roadmap (no priority tiers) and not a PRD (no implementation detail). It is the alignment checkpoint between ideation and execution.\n\nIf `.\u002Fdocs\u002Fapproach.md` already exists, it is treated as prior settled truth. Only net-new items and conflicts require grilling — not things the doc already covers.\n\nOnce this doc exists, run `to-roadmap` to generate a kanban board without repeating the grilling —\nthen pick one card and run `to-prd` on it.\n\n## Where this sits\n\n```\nPORTFOLIO — many features        ideate  or  chat-to-approach\n                                             ^^^^^^^^^^^^^^^^ you are here\n                                        ↓\n                            .\u002Fdocs\u002Fapproach.md  →  .\u002Fideas\u002Froadmap.html\n                                                        ↓  pick ONE card\nFEATURE — one feature per run    to-prd → to-plan → to-tickets → ticket-tracker\n                                 non-code work: to-prd → to-tickets\n```\n\n**Portfolio → feature is a fan-out, not a step.** This doc holds *every* feature under\nconsideration. A roadmap card is one of those features — something to be built, which the spine\nlater breaks into several tickets. Six features here means six independent runs down the spine.\n\n**Never send the user backwards.** A missing upstream artifact is written inline or offered, never a\nreason to stop and run another skill first. The one hard gate is an approved plan. A user who\nalready knows the one feature they want can skip straight to `to-prd`.\n\n**Optional: Background Research section.** `approach.md` may contain a `## Background Research` section at the top, produced by the `source-synthesis` skill, containing a lit-review synthesis of existing documentation and prior art. This skill does not create or modify that section — it is out of scope here. If the section exists, preserve it verbatim when writing or updating the file.\n\nSolo\u002Findie-builder scale throughout.\n\n---\n\n## What Is a Feature (at Alignment Level)?\n\nA feature is a coherent, user-facing capability that delivers value on its own. It is not an implementation task, a ticket, or a technical decision.\n\n**Anatomy of an alignment-level feature:**\n\n| Field            | What it captures                                  | Example                                                      |\n| ---------------- | ------------------------------------------------- | ------------------------------------------------------------ |\n| **Name**         | Short, user-facing label — what it does, not how  | \"User authentication\"                                        |\n| **Problem**      | The user pain or need it addresses (one sentence) | \"Users need to log in securely to access their data\"         |\n| **Value**        | What it unlocks or enables                        | \"Unblocks all personalisation and data persistence features\" |\n| **Dependencies** | Other features that must exist first              | \"Requires: database setup\"                                   |\n\nOnly Name + Problem are required. Value and Dependencies are included when they matter for understanding what we're building.\n\n**How to group chat content into a feature:**\n\n- A feature = a cluster of related decisions that together describe one user-facing capability\n- Multiple small decisions about the same area → one feature, not many entries\n- Ask: \"Could a user describe what they'd get from this in one sentence?\" If yes, it's a feature\n- Distinguish features from:\n  - _Constraints_ — architectural or technical decisions that shape features but aren't features themselves (e.g. \"use Postgres\") — record in Constraints, not Features\n  - _Tasks_ — implementation steps inside a feature (e.g. \"wire up the ORM\") — not captured here; `to-tickets` handles this later\n  - _Principles_ — values the user expressed (\"keep it simple\", \"mobile-first\") — capture in Principles, not Features\n\n**Anti-patterns to avoid:**\n\n- Don't split one feature into multiple entries because the conversation touched it in different ways\n- Don't create an entry for every distinct sentence — synthesise first\n- Don't mistake a technical decision for a feature (\"use JWT\" is a constraint; \"user sessions\" is a feature)\n\n---\n\n## Phase 1 — Parse the Conversation\n\nRead the pasted transcript or summary carefully. Classify everything into four buckets:\n\n**Decided\u002Fcommitted** — Both parties agreed and committed to something. Look for language like \"we'll do X\", \"let's go with Y\", \"agreed: Z\", \"the plan is\", \"I'll build\", \"we'll ship\". These become candidates for approach.md.\n\n**Discussed but not resolved** — Ideas that came up, were explored, but didn't reach a clear conclusion. Do not silently drop these. Surface them for grilling in Phase 3. **An idea not explicitly accepted is not the same as an idea that was rejected.**\n\n**Explicitly discarded** — Ideas the user or conversation actively rejected or dismissed in favour of something else. Look for language like \"no, let's not\", \"actually scratch that\", \"we're not doing X\", \"that's out of scope\". These go into the \"Out of scope\" section of the doc, not into Features.\n\n**Open questions** — Things that need a decision before work can proceed. These go into the \"Open questions\" section verbatim.\n\n**Default to inclusion over exclusion.** When in doubt, treat something as either a candidate feature (pending grilling) or an open question. An approach doc that surfaces ambiguity honestly is better than one that silently drops things the user cared about.\n\n---\n\n## Phase 2 — Load Existing approach.md (If Present)\n\nCheck for an existing `.\u002Fdocs\u002Fapproach.md`. Two paths:\n\n**No existing file:** proceed directly to Phase 3 with all \"decided\u002Fcommitted\" items as candidates.\n\n**Existing file found:** read it fully, then compute the delta against the parsed chat:\n\n- **Net new** — features, constraints, or principles in the chat that aren't yet in the doc → grill if ambiguous, otherwise add directly\n- **Conflicts** — the chat contradicts something the doc already records (e.g. doc says JWT, chat says sessions) → always grill; present both versions\n- **Supersedes** — the chat clearly updates or replaces a prior decision → treat as conflict requiring explicit confirmation before updating\n- **Already covered** — the chat repeats what the doc already has → ignore; do not re-grill\n\nItems already settled in the existing doc are **treated as prior truth**. Do not re-open them unless the new chat explicitly contradicts them.\n\n---\n\n## Phase 3 — Alignment Grilling (Safeguard)\n\nBefore writing anything, run a focused grilling session using the `grilling` skill. This is the safeguard: stress-test the extraction before committing it to a durable file. `grilling` owns the grilling loop — defer to it rather than re-running the questioning yourself. This section only scopes *what* to grill; the *how* lives in `grilling`.\n\nGrill only on:\n\n- Items in the \"discussed but not resolved\" bucket\n- Conflicts between the chat and the existing doc\n- Items with ambiguous scope (\"improve X\", \"think about Y\") — is there a concrete feature here?\n- Items where it's unclear whether something is a feature, constraint, or principle\n- Items that could be the same feature described differently at two points in the conversation\n\nDo NOT grill on:\n\n- Items clearly decided in the conversation\n- Items already settled in the existing approach.md (unless the new chat conflicts with them)\n- Items that are clearly constraints, principles, or out-of-scope — classify and move on\n\nKeep grilling lean — only ask if the answer would meaningfully change what ends up in the doc. If the conversation was explicit and decisive throughout, tell the user and skip straight to Phase 4.\n\n---\n\n## Phase 4 — Write \u002F Merge .\u002Fdocs\u002Fapproach.md\n\nWrite or update the file. If `.\u002Fdocs\u002F` doesn't exist, create it.\n\n**When creating a new file:** write all sections, even if some are empty (e.g. \"No constraints recorded yet.\").\n\n**When updating an existing file:** only replace the content of sections that changed. Preserve sections untouched by the new chat verbatim. Update the \"Last updated\" line.\n\n### Document structure\n\n```markdown\n# Approach\n\n_Last updated: \u003CYYYY-MM-DD> · Canonical alignment doc — what we are building and why._\n\n## Background Research\n\u003C!-- Optional. Produced by source-synthesis, not this skill. Preserve verbatim if present. -->\n\n## Problem\n\n\u003COne paragraph: who has the pain, what the pain is, why it matters now.>\n\n## Goals\n\n- \u003COutcome-oriented goal, one per line>\n\n## Non-goals\n\n- \u003CExplicitly out of scope, one per line — so they don't re-surface in future chats>\n\n## Features\n\nEach feature is a user-facing capability. No priority tiers — use to-roadmap for Now\u002FNext\u002FLater.\n\n### \u003CFeature name>\n\n- **Problem:** \u003Cone sentence — the user pain this solves>\n- **Value:** \u003Cwhat it unlocks or enables>\n- **Dependencies:** \u003Cother features required first, if any>\n\n## Constraints\n\nTechnical and architectural decisions that shape the work but aren't features.\n\n- \u003Ce.g. Use Postgres for persistence>\n- \u003Ce.g. JWT-based auth, stateless sessions>\n\n## Principles\n\nValues and preferences that should shape all decisions.\n\n- \u003Ce.g. Keep it simple — no enterprise PM overhead>\n- \u003Ce.g. Ship weekly — no multi-month batches>\n\n## Open questions\n\nThings that still need a decision before downstream work can proceed.\n\n1. \u003CQuestion>? — \u003COne line on why it matters or what's blocked on it.>\n\n## Out of scope\n\nIdeas explicitly rejected in conversation, recorded so they don't resurface.\n\n- \u003CRejected idea> — \u003Cbrief note on why it was cut>\n```\n\n**What does NOT belong here:** Now\u002FNext\u002FLater tiers, story points, assignees, implementation tasks, ticket breakdowns, acceptance criteria. These are downstream concerns.\n\n---\n\n## Finishing Up\n\nAfter writing the file, send a brief receipt (3–5 lines max):\n\n- Number of features captured\n- Number of conflicts resolved during grilling (if any)\n- Number of open questions outstanding\n- A one-liner on anything placed in \"Out of scope\" — so the user knows you didn't silently drop things they cared about\n- Reminder: run `to-roadmap` to generate a visual kanban from this doc without repeating grilling\n\nWhen finished, ask: 'Would you like to log feedback? (yes\u002Fno)'. If yes, invoke skill-feedback-collector passing this skill's name and path.\n",{"name":5,"description":51,"disable-model-invocation":52},"Converts a pasted AI conversation summary or transcript into a canonical alignment document at .\u002Fdocs\u002Fapproach.md — the single source of truth for what we are building and why. Grills only on ambiguities, conflicts and deltas, never on settled decisions. The doc is portfolio-level: it holds many features at once, which \u002Fto-roadmap prioritises into a Now\u002FNext\u002FLater board before each feature runs the per-feature spine on its own. For a single already-chosen feature, use \u002Fto-prd instead.\n",true,"main","aede9f7bc29a2d9127fa7ce29682c242596c7759","skills\u002Fworkflow\u002Fchat-to-approach","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997","https:\u002F\u002Fpersonal-portfolio-v2-phi.vercel.app","Go & TypeScript developer building tooling for AI-assisted development: git worktree workflows, Claude Code skills and agent orchestration.","2026-11-11 04:20:46",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":52},[63,66,69],{"tool":64,"command":65},"npx","npx skills add O-Marsters-1997\u002Fmy-claude-code --skill chat-to-approach",{"tool":67,"command":68},"bunx","bunx skills add O-Marsters-1997\u002Fmy-claude-code --skill chat-to-approach",{"tool":70,"command":71},"pnpm","pnpm dlx skills add O-Marsters-1997\u002Fmy-claude-code --skill chat-to-approach","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fchat-to-approach\u002FSKILL.md",[],[75,100,129,149,170,188],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":46},"01M6H88J6TYRV9T8RKWW569YM8","to-tickets","Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs\u002Fplans\u002F\u003Cfeature>.md`, from \u002Fto-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers \u002Fto-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-tickets\u002FSKILL.md",[],[82,83,84,85,86,87,88,89,90,91,92,93,94,35,95,96,97,98,32,30,99],"to tickets","tickets","github","run","code","batch","manifest","plan","repo","command","worktrees","task","signatures","plans","as","cut","ticket","new",{"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":111,"publishedAt":46},"01M6H88E98X9KGGYBGSVDS1E8H","to-seams","Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — \"record a seam for X\", \"we agreed on this schema, seam it\", \"add a seam so Y can build against Z's new field\". Halts for approval before writing either file.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-seams\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[112,113,114,115,90,116,91,44,117,118,119,120,121,96,122,123,124,125,32,126,30,127,128,99],"to seams","writing","repos","file","prompt","schema","build","but","either","record","records","it","block","interface","can","neither","when",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":136,"publishedAt":46},"01M6H889PSQM2E1ATS2JC10QRV","to-roadmap","Prioritises settled features into a Now \u002F Next \u002F Later kanban board, rendered as a self-contained .\u002Fideas\u002Froadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via \u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets. Boards the features in .\u002Fdocs\u002Fapproach.md, or the \"## Accepted ideas\" in .\u002Fideas\u002FCONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-roadmap\u002FSKILL.md",[135],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[41,137,138,89,139,43,140,141,142,143,35,96,98,144,145,83,34,146,147,32,148,128],"to roadmap","doc","board","later","next","self","ideas","via","card","about","re","features",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":156,"publishedAt":46},"01M6H885QAK839Q771ZBKBK1KA","to-prd","Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs\u002Fprds\u002F\u003Cfeature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (\u002Fto-prd -> \u002Fto-plan -> \u002Fto-tickets).","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-prd\u002FSKILL.md",[155],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[157,158,159,160,89,161,162,163,35,96,164,165,83,166,167,168,147,32,31,169],"to prd","prd","report","state","ask","say","delivery","line","problem","spine","multi","interviews","codebase",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":46},"01M6H881QEEP49HPBMDYDFJQP9","to-plan","Turns one feature's PRD into a skimmable plan in docs\u002Fplans\u002F\u003Cfeature>.md: a short overview, then per phase a glossary, the journeys it satisfies, and its new and modified definitions (types, enums, ports, schema), with the project:\u003Cslug> label. No code, branch or PR; the user's review of the file is the gate. Use for \"plan this feature\", \"write the contract\", \"what are the types\". One feature per run. Slash-only.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fto-plan\u002FSKILL.md",[],[89,177,178,86,115,179,180,181,182,183,44,117,42,184,185,35,95,186,32,30,187,99],"to plan","pr","ports","glossary","branch","short","overview","project","contract","types","\u003Cslug>",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":46},"01M6H87XEQEXSGT0PR5QWQZZ5P","ticket-tracker","Use when the request is about the *current state* of GitHub issues rather than creating new ones: \"where are my tickets\", \"show the board\", \"what's in progress\", \"what's ready to pick up\", \"move issue N to in-review\", \"mark N done\", \"update the ticket status\". Live triage board over GitHub issues via the gh CLI, moving each between backlog -> ready -> in-progress -> in-review -> done using status labels. This is the ticket-level board; .\u002Fideas\u002Froadmap.html is the feature-level one. To file new tickets, use \u002Fto-tickets, file-issue for a single ad-hoc one, or \u002Fsweep for a batch of small fixes.","https:\u002F\u002Fgithub.com\u002FO-Marsters-1997\u002Fmy-claude-code\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow\u002Fticket-tracker\u002FSKILL.md",[],[195,98,196,197,198,199,200,201,87,115,202,203,44,204,41,205,206,207,208,143,35,209,210,30,211,212,213,128,99],"tracker","ticket tracker","review","cli","current state","update","issues","gh","pick","ready","up","show","done","backlog","progress","move","fixes","labels","request"]