[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D9SNRHPBGR6C7YV8CJJJ60":3,"skill-same:01M6D9SNRHPBGR6C7YV8CJJJ60":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":39,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":41,"install":42,"resources":55},"01M6D9SNRHPBGR6C7YV8CJJJ60","fflow-author",null,"Create or edit FreeFlow workflow files.","freematters\u002Ffreematters","freematters","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F266749953?v=4","01M6D9S9REGCVDFCTZ7BM853DS","01M6D9S9WY29PTMRNB7X58QGTP",27,"MIT","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fskills\u002Ffflow-author\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28],"fflow author","workflow","create","edit","files","freeflow","2026-11-10 10:12:30",false,"---\nname: fflow-author\ndescription: Create or edit FreeFlow workflow files.\n---\n\n# Create Workflow\n\nPrimary goal: co-create a workflow with the user interactively. The user knows what they\nwant to achieve — your job is to help structure it as a minimal, effective workflow.\nYou MUST NOT make users feel like they are filling a schema.\n\n## Background (internal — do not expose to user)\n\nThis skill does NOT call the `fflow` CLI. It generates YAML and saves it with the Write tool.\n\nFreeFlow is a CLI-first workflow runtime for agent workflows.\nThe YAML definition is authoritative for allowed transitions at runtime.\nEach state provides guidance (`prompt`, optional `todos`) and named transition labels to next states.\n\nCore runtime flow:\n- `fflow start \u003Cpath>` initializes a run at the configured initial state.\n- `fflow goto \u003Ctarget> --run-id \u003Cid> --on \u003Clabel>` validates exact transition label\u002Ftarget match, then advances state.\n\n### Key design principles\n\n**Every state transition is a context boundary.** The agent loses working memory when\ntransitioning between states. More states = more context loss. Fewer states = better coherence.\n\n**The `guide` field persists across ALL states.** Rules that apply everywhere belong in\n`guide`, not repeated in each state prompt. Keep `guide` concise and high-level — only\ncross-cutting constraints and conventions. Detailed instructions belong in each state's\n`prompt`. Never duplicate content between `guide` and state prompts.\n\n**State prompts describe WHAT, not HOW.** The agent already knows how to code, research,\nwrite tests, etc. Prompts add value by providing domain context, constraints, and success\ncriteria the agent wouldn't otherwise know. Don't micro-manage.\n\n**Transition labels are outcome contracts**, not action descriptions. They describe what\nhappened (\"tests pass\", \"user approves\", \"gaps found\") not what to do (\"run tests\",\n\"ask user\", \"go back\").\n\n## When to create a state\n\nCreate a separate state ONLY when one or more of these apply:\n\n1. **Context isolation** — a step involves enough work that keeping it in the same state\n   would cause the agent to drift or lose focus on the overall workflow.\n2. **Branching** — there are multiple possible outcomes that lead to genuinely different\n   next steps (not just success\u002Ffailure of the same task).\n3. **Cycles \u002F loops** — a step may need to repeat (e.g., implement → review → fix → review).\n4. **Role change** — the agent switches from one mode to another (e.g., researcher → implementer)\n   and needs different context framing.\n5. **Human gate** — a hard checkpoint where the user must approve before proceeding,\n   and the approval outcome determines the next path.\n\nIf none of these apply, keep it in one state. A single-state workflow is perfectly valid —\nit's just a structured prompt with a clean start\u002Fdone lifecycle.\n\n## Process\n\n1. **Discover the workflow**\n\n   Ask these one at a time (each depends on the previous):\n\n   1. **Purpose**: What outcome should this workflow produce? Encourage the user to describe\n      their current human workflow — they can paste existing docs, notes, or step-by-step descriptions.\n   2. **Heavy lifting**: What parts of the workflow involve the most work? These are automation\n      opportunities. Ask the user to think about which parts would benefit from being separate\n      states — but push back if a proposed state doesn't meet the criteria above.\n   3. **Decision points**: Are there moments where human approval or input is required?\n      These become either hard todos within a state or transition gates between states.\n\n2. **Model the workflow**\n\n   - Create the YAML at user-specified path, or default to `.\u002Fworkflows\u002F\u003Cname>.workflow.yaml`.\n     Start with only `guide:`, `version:`, `initial:`, `states:` with state names\n     (blank prompts and transitions). Do not validate yet.\n   - Create a TODO\u002FTask for each state to fill collaboratively.\n   - For each state, propose the prompt and transitions. Ask the user to review.\n     - Put cross-cutting rules in `guide`, not in individual state prompts.\n     - Keep state prompts focused on WHAT to achieve and constraints, not HOW to do it.\n     - Use outcome-based transition labels (\"user approves\", \"tests pass\") not action labels\n       (\"run tests\", \"ask user\").\n   - Ask about must-do todos for each state.\n   - Update the YAML after each approval.\n   - You MUST work with the user to fill all states before moving on.\n\n3. **Iterate**\n\n   Ask the user to review the workflow YAML and iterate on changes — either by editing\n   the file directly or through conversation.\n\n4. **Validate before saving**\n\n   - Ensure YAML passes the internal validation checklist (below).\n   - Challenge unnecessary states: \"Could this be folded into the previous state?\"\n   - Verify transition labels describe outcomes, not actions.\n   - Ensure prompts are self-contained and agent-agnostic (work across Claude, Codex, etc.).\n   - Ensure at least one rework\u002Ffailure path when appropriate.\n\n4.5. **Generate SKILL.md**\n\n   After validation succeeds, generate a `SKILL.md` file in the same directory as the\n   workflow YAML. This makes the workflow installable as an agent skill.\n\n   **How to derive the fields:**\n   - `{name}`: the workflow directory name (e.g., if the workflow is at\n     `workflows\u002Fspec-gen\u002Fworkflow.yaml`, the name is `spec-gen`).\n   - `{description}`: derive from the entire `guide` field of the workflow YAML — read the\n     full guide and write a concise one-line summary that captures the workflow's purpose.\n     If `guide` is empty or missing, use `\"Run the {name} workflow\"`.\n   - `{title}`: convert the name to title case, replacing hyphens with spaces\n     (e.g., `spec-gen` -> `Spec Gen`).\n\n   **Write this exact template** to `SKILL.md` in the workflow directory:\n\n   ```markdown\n   ---\n   name: {name}\n   description: {description}\n   ---\n\n   # {title}\n\n   Run `\u002Ffflow {name}` with any arguments passed to this skill.\n   ```\n\n5. **Present results in user's language**\n\n   - Summarize as phases and decision points.\n   - Show a one-line flow (e.g., `gather → design → implement → done`).\n   - Show saved file path.\n   - Show YAML only if user asks.\n\n## Cross-Agent Authoring Rules\n\nDefault to agent-agnostic workflows:\n\n- Make prompts self-contained: assumptions, required outputs, decision criteria.\n- Put universal rules in `guide`, not in state prompts.\n- Don't reference agent-specific tools or features in prompts unless necessary.\n\n### Heading levels in prompts\n\nState prompts are rendered under `### Instructions:` in the markdown workflow format,\nwhich is itself under `## State: xxx`. To avoid heading conflicts, use these levels\ninside prompts:\n\n- `####` for top-level sections within a state prompt\n- `**bold text**` for sub-sections and emphasis\n- Never use `##` or `###` inside prompts — those levels are reserved for the markdown format structure\n\nThis ensures the markdown renders correctly when the workflow is converted to `.workflow.md`.\n\n## Workflow Reuse\n\nWhen the user wants to build on an existing workflow or share structure across workflows,\nread `composability.md` (in this skill directory) for full syntax\nand merge rules for `from:`, `extends_guide`, `workflow:`, and `subagent:`.\n\n## Internal Validation Checklist (do not expose unless asked)\n\n- `version: 1.3` (always use latest version)\n- `guide` is present and contains cross-cutting rules\n- one valid `initial` state exists\n- terminal `done` state exists with `transitions: {}`\n- non-`done` states have non-empty transitions\n- transition targets point to existing states\n- transition labels describe outcomes, not actions\n- state names match `[A-Za-z_-][A-Za-z0-9_-]*`\n- if `todos` are used, they are non-empty unique strings\n- no state prompt repeats rules already in `guide`\n- if `from:` is used, the referenced workflow and state exist\n- if `extends_guide:` is used, the referenced workflow exists and has a `guide` field\n- SKILL.md exists alongside workflow.yaml with correct `name` (matching directory name) and `description` (derived from guide)\n","# Create Workflow\n\nPrimary goal: co-create a workflow with the user interactively. The user knows what they\nwant to achieve — your job is to help structure it as a minimal, effective workflow.\nYou MUST NOT make users feel like they are filling a schema.\n\n## Background (internal — do not expose to user)\n\nThis skill does NOT call the `fflow` CLI. It generates YAML and saves it with the Write tool.\n\nFreeFlow is a CLI-first workflow runtime for agent workflows.\nThe YAML definition is authoritative for allowed transitions at runtime.\nEach state provides guidance (`prompt`, optional `todos`) and named transition labels to next states.\n\nCore runtime flow:\n- `fflow start \u003Cpath>` initializes a run at the configured initial state.\n- `fflow goto \u003Ctarget> --run-id \u003Cid> --on \u003Clabel>` validates exact transition label\u002Ftarget match, then advances state.\n\n### Key design principles\n\n**Every state transition is a context boundary.** The agent loses working memory when\ntransitioning between states. More states = more context loss. Fewer states = better coherence.\n\n**The `guide` field persists across ALL states.** Rules that apply everywhere belong in\n`guide`, not repeated in each state prompt. Keep `guide` concise and high-level — only\ncross-cutting constraints and conventions. Detailed instructions belong in each state's\n`prompt`. Never duplicate content between `guide` and state prompts.\n\n**State prompts describe WHAT, not HOW.** The agent already knows how to code, research,\nwrite tests, etc. Prompts add value by providing domain context, constraints, and success\ncriteria the agent wouldn't otherwise know. Don't micro-manage.\n\n**Transition labels are outcome contracts**, not action descriptions. They describe what\nhappened (\"tests pass\", \"user approves\", \"gaps found\") not what to do (\"run tests\",\n\"ask user\", \"go back\").\n\n## When to create a state\n\nCreate a separate state ONLY when one or more of these apply:\n\n1. **Context isolation** — a step involves enough work that keeping it in the same state\n   would cause the agent to drift or lose focus on the overall workflow.\n2. **Branching** — there are multiple possible outcomes that lead to genuinely different\n   next steps (not just success\u002Ffailure of the same task).\n3. **Cycles \u002F loops** — a step may need to repeat (e.g., implement → review → fix → review).\n4. **Role change** — the agent switches from one mode to another (e.g., researcher → implementer)\n   and needs different context framing.\n5. **Human gate** — a hard checkpoint where the user must approve before proceeding,\n   and the approval outcome determines the next path.\n\nIf none of these apply, keep it in one state. A single-state workflow is perfectly valid —\nit's just a structured prompt with a clean start\u002Fdone lifecycle.\n\n## Process\n\n1. **Discover the workflow**\n\n   Ask these one at a time (each depends on the previous):\n\n   1. **Purpose**: What outcome should this workflow produce? Encourage the user to describe\n      their current human workflow — they can paste existing docs, notes, or step-by-step descriptions.\n   2. **Heavy lifting**: What parts of the workflow involve the most work? These are automation\n      opportunities. Ask the user to think about which parts would benefit from being separate\n      states — but push back if a proposed state doesn't meet the criteria above.\n   3. **Decision points**: Are there moments where human approval or input is required?\n      These become either hard todos within a state or transition gates between states.\n\n2. **Model the workflow**\n\n   - Create the YAML at user-specified path, or default to `.\u002Fworkflows\u002F\u003Cname>.workflow.yaml`.\n     Start with only `guide:`, `version:`, `initial:`, `states:` with state names\n     (blank prompts and transitions). Do not validate yet.\n   - Create a TODO\u002FTask for each state to fill collaboratively.\n   - For each state, propose the prompt and transitions. Ask the user to review.\n     - Put cross-cutting rules in `guide`, not in individual state prompts.\n     - Keep state prompts focused on WHAT to achieve and constraints, not HOW to do it.\n     - Use outcome-based transition labels (\"user approves\", \"tests pass\") not action labels\n       (\"run tests\", \"ask user\").\n   - Ask about must-do todos for each state.\n   - Update the YAML after each approval.\n   - You MUST work with the user to fill all states before moving on.\n\n3. **Iterate**\n\n   Ask the user to review the workflow YAML and iterate on changes — either by editing\n   the file directly or through conversation.\n\n4. **Validate before saving**\n\n   - Ensure YAML passes the internal validation checklist (below).\n   - Challenge unnecessary states: \"Could this be folded into the previous state?\"\n   - Verify transition labels describe outcomes, not actions.\n   - Ensure prompts are self-contained and agent-agnostic (work across Claude, Codex, etc.).\n   - Ensure at least one rework\u002Ffailure path when appropriate.\n\n4.5. **Generate SKILL.md**\n\n   After validation succeeds, generate a `SKILL.md` file in the same directory as the\n   workflow YAML. This makes the workflow installable as an agent skill.\n\n   **How to derive the fields:**\n   - `{name}`: the workflow directory name (e.g., if the workflow is at\n     `workflows\u002Fspec-gen\u002Fworkflow.yaml`, the name is `spec-gen`).\n   - `{description}`: derive from the entire `guide` field of the workflow YAML — read the\n     full guide and write a concise one-line summary that captures the workflow's purpose.\n     If `guide` is empty or missing, use `\"Run the {name} workflow\"`.\n   - `{title}`: convert the name to title case, replacing hyphens with spaces\n     (e.g., `spec-gen` -> `Spec Gen`).\n\n   **Write this exact template** to `SKILL.md` in the workflow directory:\n\n   ```markdown\n   ---\n   name: {name}\n   description: {description}\n   ---\n\n   # {title}\n\n   Run `\u002Ffflow {name}` with any arguments passed to this skill.\n   ```\n\n5. **Present results in user's language**\n\n   - Summarize as phases and decision points.\n   - Show a one-line flow (e.g., `gather → design → implement → done`).\n   - Show saved file path.\n   - Show YAML only if user asks.\n\n## Cross-Agent Authoring Rules\n\nDefault to agent-agnostic workflows:\n\n- Make prompts self-contained: assumptions, required outputs, decision criteria.\n- Put universal rules in `guide`, not in state prompts.\n- Don't reference agent-specific tools or features in prompts unless necessary.\n\n### Heading levels in prompts\n\nState prompts are rendered under `### Instructions:` in the markdown workflow format,\nwhich is itself under `## State: xxx`. To avoid heading conflicts, use these levels\ninside prompts:\n\n- `####` for top-level sections within a state prompt\n- `**bold text**` for sub-sections and emphasis\n- Never use `##` or `###` inside prompts — those levels are reserved for the markdown format structure\n\nThis ensures the markdown renders correctly when the workflow is converted to `.workflow.md`.\n\n## Workflow Reuse\n\nWhen the user wants to build on an existing workflow or share structure across workflows,\nread `composability.md` (in this skill directory) for full syntax\nand merge rules for `from:`, `extends_guide`, `workflow:`, and `subagent:`.\n\n## Internal Validation Checklist (do not expose unless asked)\n\n- `version: 1.3` (always use latest version)\n- `guide` is present and contains cross-cutting rules\n- one valid `initial` state exists\n- terminal `done` state exists with `transitions: {}`\n- non-`done` states have non-empty transitions\n- transition targets point to existing states\n- transition labels describe outcomes, not actions\n- state names match `[A-Za-z_-][A-Za-z0-9_-]*`\n- if `todos` are used, they are non-empty unique strings\n- no state prompt repeats rules already in `guide`\n- if `from:` is used, the referenced workflow and state exist\n- if `extends_guide:` is used, the referenced workflow exists and has a `guide` field\n- SKILL.md exists alongside workflow.yaml with correct `name` (matching directory name) and `description` (derived from guide)\n",{"name":5,"description":7},"main","898550a01eca98e666c6c16aef03ee6bbd04175c","packages\u002Ffreeflow\u002Fskills\u002Ffflow-author",5,"https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters","https:\u002F\u002Ffreematters.vercel.app","https:\u002F\u002Fgithub.com\u002Ffreematters","2026-05-19 20:22:18",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add freematters\u002Ffreematters --skill fflow-author",{"tool":48,"command":49},"bunx","bunx skills add freematters\u002Ffreematters --skill fflow-author",{"tool":51,"command":52},"pnpm","pnpm dlx skills add freematters\u002Ffreematters --skill fflow-author","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fskills\u002Ffflow-author\u002FSKILL.md",true,[56,62],{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"agents\u002Fopenai.yaml","REFERENCE","参考文档",82,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcyber-operating-havoc-c2\u002Fagents\u002Fopenai.yaml",{"path":63,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":64,"sourceHtmlUrl":65},"composability.md",2938,"https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fskills\u002Ffflow-author\u002Fcomposability.md",[67,81,99,116,129,141],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":77,"publishedAt":29},"01M6D9TNZ52Y3DXX3PTGTR1Q0K","verifier","E2E test verifier workflow.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fverifier\u002FSKILL.md",[73,76],{"categoryNo":74,"categoryName":75,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[69,78,79,80,24],"e2e test","e2e","test",{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":92,"publishedAt":29},"01M6D9TJSJDF87RMDCDSXRBZHT","spec-to-code","Implement a spec into working code, one plan step at a time.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fspec-to-code\u002FSKILL.md",[87],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[93,94,95,96,97,98],"spec to code","code","spec","time","plan","implement",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":29},"01M6D9TFTDG16JC379AD3TT9E8","spec-gen","Generate a complete specification from a rough idea through interactive requirements gathering, research, design, and implementation planning.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fspec-gen\u002FSKILL.md",[],[106,95,107,108,109,110,111,112,113,114,115],"spec gen","implementation","requirements","idea","specification","interactive","planning","generate","research","design",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"publishedAt":29},"01M6D9TDFC5MDPJW068JGGMB1W","spec-driven","End-to-end pipeline from rough idea to merged pull request. Passing --quick forwards the flag to the spec-gen sub workflow.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fspec-driven\u002FSKILL.md",[122],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[124,95,125,109,126,127,128,24],"spec driven","end","pipeline","pull","pull request",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":136,"publishedAt":29},"01M6D9TB81ZTY2ATQRCTDKPXZK","release","General release workflow for GitHub projects.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Frelease\u002FSKILL.md",[135],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[131,137,24,138,139,140],"github","general","projects","github projects",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":29},"01M6D9T8Y48YE2YM0HYXPV59PM","pr-lifecycle","Monitor a PR\u002FMR until it is merged or closed.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fpr-lifecycle\u002FSKILL.md",[],[148,149,150,151],"pr","pr lifecycle","lifecycle","monitor"]