[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C7GFES0CDTH2YJ1F6YH66F":3,"skill-same:01M6C7GFES0CDTH2YJ1F6YH66F":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":44,"install":45,"resources":58},"01M6C7GFES0CDTH2YJ1F6YH66F","codex",null,"Use when the user asks to run Codex CLI (codex exec, codex resume) or wants Codex to review PRs, plans, or specs. Delegates to GPT-5.3-codex with preset reasoning modes.","lepahc\u002Fkynetic-spec","lepahc","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F255431765?v=4","01M6C7E6Z0C8SE1X6PJ2F9Q1CX","01M6C7E744QKNYBVZ7KV7Z69GF",1,"MIT","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodex\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,23,24,25,26,27,28,29,30,31,32],"review","cli","codex cli","preset","run","reasoning","gpt","user","use","resume","2026-11-10 10:12:30",false,"---\nname: codex\ndescription: Use when the user asks to run Codex CLI (codex exec, codex resume)\n  or wants Codex to review PRs, plans, or specs. Delegates to GPT-5.3-codex with\n  preset reasoning modes.\n---\n\u003C!-- kspec-managed -->\n\n# Codex Skill\n\nRun OpenAI Codex CLI for code analysis, reviews, and automated editing. Defaults to `gpt-5.3-codex` with preset reasoning effort per mode.\n\n## Quick Start\n\n```bash\n# PR review (posts inline comments to GitHub)\n\u002Fcodex review #123\n\n# Plan review\n\u002Fcodex review-plan @plan-slug\n\u002Fcodex review-plan .\u002Fpath\u002Fto\u002Fplan.md\n\n# Spec review\n\u002Fcodex review-spec @spec-slug\n\n# General task\n\u002Fcodex \"refactor the parser module for clarity\"\n\n# Resume last session\n\u002Fcodex resume\n\u002Fcodex resume \"follow-up prompt\"\n```\n\n## Modes and Reasoning Presets\n\n| Mode | Reasoning | Sandbox | Output |\n|------|-----------|---------|--------|\n| `review` (PR) | `high` | `danger-full-access` | Inline GitHub comments via `gh` + `\u002Ftmp` |\n| `review-plan` | `high` | `danger-full-access` | Feedback file in `\u002Ftmp` |\n| `review-spec` | `high` | `danger-full-access` | Feedback file in `\u002Ftmp` |\n| general (default) | `medium` | `danger-full-access` | Feedback file in `\u002Ftmp` |\n| general with edits | `medium` | `danger-full-access` | Direct file changes |\n\n**Model:** `gpt-5.3-codex` unless the user specifies otherwise.\n\n**Sandbox:** `danger-full-access` for all modes. Codex has full filesystem and network access — same trust level as Claude. This lets it use `gh` for GitHub API calls and `kspec` for spec\u002Ftask operations directly.\n\nUsers can override reasoning (`-c model_reasoning_effort=\"xhigh\"`) or model (`-m gpt-5.2`) explicitly.\n\n## PR Review Mode\n\n```\n\u002Fcodex review #123\n\u002Fcodex review @task-ref\n```\n\n### Resolving @task-ref to PR Number\n\nWhen the user provides a `@task-ref` instead of a PR number:\n\n```bash\n# Check task for vcs_refs\nkspec task get @task-ref --json | jq '.vcs_refs'\n\n# Or search for PR by task trailer in body\u002Fcommits\ngh pr list --search \"Task: @task-ref\" --json number,url,title\n```\n\nIf no PR is found, error: \"No PR found for task @task-ref. Create a PR first with \u002Fpr.\"\n\n### Flow\n\nFor straightforward diff review, prefer the native `codex exec review` subcommand:\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  review \\\n  \"$(cat \u003C\u003C'PROMPT'\nAlso check for:\n- Spec context discovery: check PR body, commit messages, and changed file `\u002F\u002F AC:` annotations for Task:\u002FSpec: references. Also run `kspec tasks list` and match by title\u002Fdescription to PR scope. If a task ref is found, resolve to spec via `kspec task get @task-ref`. If any spec is found, validate AC coverage below. Only skip AC checks if genuinely no spec exists.\n- Own AC coverage: every spec AC should have test with `\u002F\u002F AC: @spec-ref ac-N` annotation\n- Trait AC coverage: run `kspec item get @spec-ref` to find inherited trait ACs. Each needs test with `\u002F\u002F AC: @trait-slug ac-N` annotation\n- Run `kspec validate` — any trait AC coverage warnings are MUST-FIX\n- Spec alignment: implementation matches spec intent\n- Code quality: duplicated logic, ignored shared utilities, inconsistent patterns\n- Test quality: no fluff tests, prefer E2E over unit\n\nAfter reviewing, post your review to GitHub using `gh pr review \u003CNUMBER>`.\nFor inline comments, write a JSON body to \u002Ftmp\u002Fcodex-pr-review-body.json with this structure:\n  {\"event\":\"COMMENT\",\"body\":\"summary\",\"comments\":[{\"path\":\"src\u002Ffile.ts\",\"line\":42,\"body\":\"comment\"}]}\nThen post: gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F\u003CNUMBER>\u002Freviews --method POST --input \u002Ftmp\u002Fcodex-pr-review-body.json\n\nAlso write the full review to \u002Ftmp\u002Fcodex-pr-\u003CNUMBER>-review.md\n\nSeverity levels: MUST-FIX, SHOULD-FIX, SUGGESTION.\nPROMPT\n)\"\n```\n\nFor PR reviews that need additional context (task ref, spec ACs), use `codex exec` instead:\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"$(cat \u003C\u003C'PROMPT'\nReview PR #123 in this repository.\n\n1. Get the PR diff: `gh pr diff 123`\n2. Get PR details: `gh pr view 123 --json title,body,files`\n3. Check the PR body for `Task: @task-ref` or `Spec: @spec-ref` trailers:\n   - If `Task:` found: `kspec task get @task-ref` to get spec_ref, then `kspec item get @spec-ref`\n   - If `Spec:` found: `kspec item get @spec-ref` directly\n   - Either way, check acceptance criteria coverage\n4. Review the code for:\n   - Correctness and potential bugs\n   - Own AC coverage: every spec AC should have test with `\u002F\u002F AC: @spec-ref ac-N` annotation\n   - Trait AC coverage: run `kspec item get @spec-ref` to find inherited trait ACs (under \"Inherited from @trait-slug\" sections). Each needs test with `\u002F\u002F AC: @trait-slug ac-N` annotation\n   - Run `kspec validate` — trait AC coverage warnings are MUST-FIX\n   - Spec alignment: implementation matches spec intent, not just syntax\n   - Code quality: duplicated logic, ignored shared utilities, inconsistent patterns\n   - Test quality: no fluff tests, prefer E2E over unit\n5. Write a review body JSON file to \u002Ftmp\u002Fcodex-pr-review-body.json:\n   {\"event\":\"COMMENT\",\"body\":\"summary\",\"comments\":[{\"path\":\"file\",\"line\":N,\"body\":\"comment\"}]}\n   Then post: gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F123\u002Freviews --method POST --input \u002Ftmp\u002Fcodex-pr-review-body.json\n6. Also write the full review to \u002Ftmp\u002Fcodex-pr-123-review.md\n\nIf no Task or Spec trailer exists in the PR body, dig deeper before skipping AC checks:\n   a. Check commit messages for Task: or Spec: trailers\n   b. Search recent tasks: run `kspec tasks list` and match by title\u002Fdescription to PR scope\n   c. Check if changed files have `\u002F\u002F AC: @spec-ref` annotations pointing to specs\n   d. If a task ref is found, resolve to spec: `kspec task get @task-ref --json | jq '.spec_ref'`\n   e. If a spec is found through any of these methods, validate AC coverage identically to the trailer-present case\n   f. Only fall back to pure code review if genuinely no spec exists for the changed behavior\n\nSeverity levels: MUST-FIX, SHOULD-FIX, SUGGESTION.\nPROMPT\n)\"\n```\n\n### AC Coverage Check\n\nWhen a task ref is provided, Codex is instructed to verify:\n- Every own AC has test coverage via `\u002F\u002F AC: @spec-ref ac-N` annotations\n- Every inherited trait AC has test coverage via `\u002F\u002F AC: @trait-slug ac-N` annotations\n- `kspec validate` shows no trait AC coverage warnings for the spec\n- Missing coverage (own or trait) is flagged as `MUST-FIX`\n- Spec alignment: implementation matches spec intent, not just syntax\n\n### Integration with \u002Fpr-review\n\nFor full quality-gate PR review (CI verification, merge decision), use `\u002Fpr-review @task-ref` instead. This skill focuses on **code-level review feedback** — use both together:\n\n```\n\u002Fcodex review #123          # Codex posts inline code review\n\u002Fpr-review @task-ref        # Full quality gate workflow (AC, CI, merge)\n```\n\n## Plan Review Mode\n\n```\n\u002Fcodex review-plan @plan-slug\n\u002Fcodex review-plan .\u002Fpath\u002Fto\u002Fplan.md\n```\n\n### What Codex Checks\n\nCodex can read plans directly via `kspec plan get` or from a file path:\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"Review the plan. Get it with: kspec plan get @plan-slug (or read \u003Cpath>). $(cat \u003C\u003C'PROMPT'\nEvaluate against these criteria and write feedback to \u002Ftmp\u002Fcodex-plan-review.md:\n\n## Structure\n- Has ## Specs section with YAML array?\n- Has ## Tasks section with derive_from_specs line?\n- Has ## Implementation Notes section?\n\n## Spec Quality\n- Every spec has `title` (required)\n- Every spec has `acceptance_criteria` array (strongly recommended)\n- Each AC has id, given, when, then fields\n- AC `then` clauses are concrete and testable (not vague like \"works correctly\")\n- AC are independently testable (not compound)\n- `parent` references use @ prefix and point to valid specs\n- `traits` reference valid trait names with @ prefix\n- `type` is a valid item type (feature, requirement, constraint, decision)\n\n## Completeness\n- Implementation notes present for complex specs\n- No obvious gaps in AC coverage (behaviors described but not covered by AC)\n- Specs don't overlap or duplicate each other\n- Dependencies between specs are explicit\n\n## Red Flags\n- Vague AC: \"then: system behaves correctly\"\n- Untestable AC: \"then: performance is acceptable\"\n- Over-granular AC: one AC per line of code\n- Compound AC: \"X and Y and Z\" in single criterion\n- Missing parent for nested items\n- Trait applied to fewer than 3 specs\n\nFormat: Use ## headers for sections, bullet lists for issues.\nRate severity: MUST-FIX, SHOULD-FIX, SUGGESTION.\nPROMPT\n)\"\n```\n\n### Output\n\nFeedback is written to `\u002Ftmp\u002Fcodex-plan-review.md`. After Codex completes:\n\n```bash\n# Show the user the output path\necho \"Plan review written to \u002Ftmp\u002Fcodex-plan-review.md\"\n\n# Optionally display summary\nhead -50 \u002Ftmp\u002Fcodex-plan-review.md\n```\n\n## Spec Review Mode\n\n```\n\u002Fcodex review-spec @spec-slug\n\u002Fcodex review-spec @module-slug    # Review entire module\n```\n\n### What Codex Checks\n\nCodex can read specs directly via `kspec item get` and validate with `kspec validate`:\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"Review the spec. $(cat \u003C\u003C'PROMPT'\nGet the spec with: kspec item get @spec-slug\nFor module-level review: kspec item list --module @module-slug to get all items, then kspec item get each one.\nAlso run kspec validate for structural issues.\n\nEvaluate and write feedback to \u002Ftmp\u002Fcodex-spec-review.md:\n\n## Acceptance Criteria Quality\n- Are all ACs concrete and independently testable?\n- Do `then` clauses describe observable outcomes (not internal state)?\n- Are ACs atomic (not compound \"X and Y and Z\")?\n- Is coverage complete (all described behaviors have ACs)?\n- Are there ACs that overlap or contradict each other?\n\n## Structure\n- Appropriate item type for content?\n- Description clearly explains purpose?\n- References (depends_on, implements, relates_to) are valid?\n- Status fields consistent (maturity vs implementation)?\n\n## Trait Usage\n- Applied traits are appropriate (behavior applies to this spec)?\n- Cross-cutting behaviors that appear 3+ times should use traits\n- Trait ACs don't conflict with spec-specific ACs\n\n## Testability\n- Can each AC be validated with automated tests?\n- Are preconditions (given) realistic and reproducible?\n- Are actions (when) specific enough to implement?\n\nFormat: ## headers, bullet lists, severity ratings.\nMUST-FIX | SHOULD-FIX | SUGGESTION\nPROMPT\n)\"\n```\n\n### Output\n\nWritten to `\u002Ftmp\u002Fcodex-spec-review.md`.\n\n## General Mode\n\n```\n\u002Fcodex \"analyze the error handling patterns in src\u002Fcli\u002F\"\n\u002Fcodex \"refactor parser module for clarity\"\n```\n\n### Defaults\n\n- **Model:** `gpt-5.3-codex`\n- **Reasoning:** `medium`\n- **Sandbox:** `danger-full-access`\n\n### Command Assembly\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"medium\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"Your prompt here. Write output to \u002Ftmp\u002Fcodex-output.md\"\n```\n\n## Resuming Sessions\n\n```bash\n# Resume last session with new prompt (positional arg)\ncodex exec --skip-git-repo-check resume --last \"follow-up prompt\"\n\n# Resume last session with prompt from stdin\necho \"follow-up prompt\" | codex exec --skip-git-repo-check resume --last -\n\n# Resume with no additional prompt\ncodex exec --skip-git-repo-check resume --last\n```\n\nWhen resuming, config flags (`-c`, `-m`, `-s`) are accepted and override the original session's settings. All flags must go between `exec` and `resume`.\n\n## Output Convention\n\nAll Codex output is written to `\u002Ftmp\u002Fcodex-*` files:\n\n| Mode | Output file |\n|------|------------|\n| PR review | `\u002Ftmp\u002Fcodex-pr-{number}-review.md` |\n| Plan review | `\u002Ftmp\u002Fcodex-plan-review.md` |\n| Spec review | `\u002Ftmp\u002Fcodex-spec-review.md` |\n| General | `\u002Ftmp\u002Fcodex-output.md` |\n\nAfter every Codex run:\n1. Report the output file path to the user\n2. Summarize key findings\n3. For PR reviews, also post comments to GitHub via `gh`\n\n## Error Handling\n\n- If `codex exec` exits non-zero, report the error and ask the user how to proceed\n- If output file is empty or missing, Codex may have hit a context or timeout issue — re-run without stderr suppression to diagnose\n- For review modes, do NOT suppress stderr — review errors (auth failures, API issues) should be visible\n- For general mode, append `2>\u002Fdev\u002Fnull` to suppress thinking tokens unless debugging\n\n### Preflight Checks\n\nBefore PR review, verify `gh` auth is working:\n\n```bash\ngh auth status\n```\n\nIf auth fails, instruct the user to run `gh auth login` before retrying.\n\n## Overrides\n\nUsers can override any preset:\n\n```\n\u002Fcodex review #123 --model gpt-5.2 -c model_reasoning_effort=\"xhigh\"\n\u002Fcodex \"prompt\" -c model_reasoning_effort=\"high\"\n```\n\nParse overrides from the user's message and map to CLI flags:\n- `--model X` or `-m X` → `-m X`\n- `--effort X` → `-c model_reasoning_effort=\"X\"` (translate to config flag)\n\n## Handling Complex Prompts\n\nWhen prompts contain shell-unsafe characters (quotes, backticks, special characters, or multi-line content), use the **prompt-file pattern** instead of inline quoting:\n\n```bash\n# 1. Write prompt to temp file (use mktemp for safety)\nPROMPT_FILE=$(mktemp \u002Ftmp\u002Fcodex-prompt.XXXXXX)\ncat > \"$PROMPT_FILE\" \u003C\u003C 'EOF'\nReview the code for:\n- Edge cases with special chars like `$var` and \"quoted\" strings\n- Multi-line logic that's hard to escape inline\n- Patterns matching {curly} braces\nEOF\n\n# 2. Use $(cat file) to inject the prompt\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"medium\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"$(cat \"$PROMPT_FILE\")\"\n\n# 3. Clean up\nrm -f \"$PROMPT_FILE\"\n```\n\n### When to Use This Pattern\n\n| Prompt Content | Approach |\n|----------------|----------|\n| Simple one-liner | Inline quotes work fine |\n| Contains `$`, backticks, quotes | Use prompt file |\n| Multi-line with formatting | Use prompt file |\n| Generated or dynamic content | Use prompt file |\n\n### Why Prompt-File Over Heredocs?\n\nQuoted heredocs (`\u003C\u003C'DELIM'...DELIM`) handle quotes, backticks, and `$` literally — they don't cause parsing failures. However, the prompt-file pattern offers practical advantages:\n\n- **Delimiter collision**: If your prompt contains the delimiter string itself, heredocs fail\n- **Mixed expansion**: When you need `$var` expanded in some places but literal in others, heredocs require awkward escaping\n- **Debuggability**: You can `cat \"$PROMPT_FILE\"` to verify exact content before running\n- **Reusability**: Same prompt file can be used across multiple commands\n\nFor simple prompts, heredocs work fine. Use prompt-files when prompts are complex, generated dynamically, or need inspection before use.\n\n## Agent Dispatch Safety Guard\n\nWhen invoking Codex from inside an agent dispatch session, you **MUST** inject safety constraints into every codex prompt. Codex runs with `danger-full-access` and has no awareness of the agent runtime hosting it.\n\n### Detection\n\nBefore running any `codex exec` command, check for agent dispatch context:\n\n```bash\n# Env var set by agent runtime on spawned agent processes\nif [ -n \"$KSPEC_SESSION_ID\" ]; then\n  # We're inside an agent dispatch session — inject safety guard\nfi\n```\n\n### Required Safety Preamble\n\nWhen agent dispatch context is detected, **prepend** this safety block to every codex prompt:\n\n```\nSAFETY CONSTRAINTS (you are running inside a kspec agent dispatch session):\n- NEVER start kspec agent run, kspec serve, or any long-running kspec process\n- NEVER use pkill, kill, killall, or any process-killing command targeting kspec processes\n- NEVER run commands that would terminate or interfere with the parent agent session\n- Do NOT run CLI spot-checks that start background services\n- If you need to verify CLI behavior, use non-destructive read-only commands only\nViolating these constraints will kill the automation session hosting you.\n```\n\n### Example (PR review with safety guard)\n\n```bash\n# Detect agent dispatch context\nAGENT_GUARD=\"\"\nif [ -n \"$KSPEC_SESSION_ID\" ]; then\n  AGENT_GUARD=\"SAFETY CONSTRAINTS (you are running inside a kspec agent dispatch session):\n- NEVER start kspec agent run, kspec serve, or any long-running kspec process\n- NEVER use pkill, kill, killall, or any process-killing command targeting kspec processes\n- NEVER run commands that would terminate or interfere with the parent agent session\n- Do NOT run CLI spot-checks that start background services\n- If you need to verify CLI behavior, use non-destructive read-only commands only\nViolating these constraints will kill the automation session hosting you.\n\n\"\nfi\n\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"${AGENT_GUARD}Review PR #123 in this repository. ...\"\n```\n\n### Why This Matters\n\nIn a previous automation session, Codex ran a \"CLI spot-check\" that accidentally started a long-running kspec process, then ran `pkill` to clean up — which killed the actual automation session hosting it. The session died mid-tool-call with no clean exit.\n\n## Tips\n\n- Always use `--skip-git-repo-check` — this project uses a shadow branch worktree that confuses Codex's git detection\n- For large diffs, pipe through `head -2000` before giving to Codex to stay within context\n- Codex has full access and can run `gh`, `kspec`, `npm`, etc. directly — instruct it to use these tools in your prompt\n- Tell Codex to run `kspec` from the project root, not from inside `.kspec\u002F` (same gotcha agents hit)\n- Use `codex exec review` for straightforward diff reviews (has `--base`, `--commit`, `--uncommitted` flags built in)\n- Do NOT use `--full-auto` — it forces `workspace-write` sandbox, overriding `danger-full-access`\n- Do NOT use `REQUEST_CHANGES` review event — reviews are posted from the repo owner's account, and GitHub prohibits requesting changes on your own PR. Use `COMMENT` for findings or `APPROVE` when clean.\n","\u003C!-- kspec-managed -->\n\n# Codex Skill\n\nRun OpenAI Codex CLI for code analysis, reviews, and automated editing. Defaults to `gpt-5.3-codex` with preset reasoning effort per mode.\n\n## Quick Start\n\n```bash\n# PR review (posts inline comments to GitHub)\n\u002Fcodex review #123\n\n# Plan review\n\u002Fcodex review-plan @plan-slug\n\u002Fcodex review-plan .\u002Fpath\u002Fto\u002Fplan.md\n\n# Spec review\n\u002Fcodex review-spec @spec-slug\n\n# General task\n\u002Fcodex \"refactor the parser module for clarity\"\n\n# Resume last session\n\u002Fcodex resume\n\u002Fcodex resume \"follow-up prompt\"\n```\n\n## Modes and Reasoning Presets\n\n| Mode | Reasoning | Sandbox | Output |\n|------|-----------|---------|--------|\n| `review` (PR) | `high` | `danger-full-access` | Inline GitHub comments via `gh` + `\u002Ftmp` |\n| `review-plan` | `high` | `danger-full-access` | Feedback file in `\u002Ftmp` |\n| `review-spec` | `high` | `danger-full-access` | Feedback file in `\u002Ftmp` |\n| general (default) | `medium` | `danger-full-access` | Feedback file in `\u002Ftmp` |\n| general with edits | `medium` | `danger-full-access` | Direct file changes |\n\n**Model:** `gpt-5.3-codex` unless the user specifies otherwise.\n\n**Sandbox:** `danger-full-access` for all modes. Codex has full filesystem and network access — same trust level as Claude. This lets it use `gh` for GitHub API calls and `kspec` for spec\u002Ftask operations directly.\n\nUsers can override reasoning (`-c model_reasoning_effort=\"xhigh\"`) or model (`-m gpt-5.2`) explicitly.\n\n## PR Review Mode\n\n```\n\u002Fcodex review #123\n\u002Fcodex review @task-ref\n```\n\n### Resolving @task-ref to PR Number\n\nWhen the user provides a `@task-ref` instead of a PR number:\n\n```bash\n# Check task for vcs_refs\nkspec task get @task-ref --json | jq '.vcs_refs'\n\n# Or search for PR by task trailer in body\u002Fcommits\ngh pr list --search \"Task: @task-ref\" --json number,url,title\n```\n\nIf no PR is found, error: \"No PR found for task @task-ref. Create a PR first with \u002Fpr.\"\n\n### Flow\n\nFor straightforward diff review, prefer the native `codex exec review` subcommand:\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  review \\\n  \"$(cat \u003C\u003C'PROMPT'\nAlso check for:\n- Spec context discovery: check PR body, commit messages, and changed file `\u002F\u002F AC:` annotations for Task:\u002FSpec: references. Also run `kspec tasks list` and match by title\u002Fdescription to PR scope. If a task ref is found, resolve to spec via `kspec task get @task-ref`. If any spec is found, validate AC coverage below. Only skip AC checks if genuinely no spec exists.\n- Own AC coverage: every spec AC should have test with `\u002F\u002F AC: @spec-ref ac-N` annotation\n- Trait AC coverage: run `kspec item get @spec-ref` to find inherited trait ACs. Each needs test with `\u002F\u002F AC: @trait-slug ac-N` annotation\n- Run `kspec validate` — any trait AC coverage warnings are MUST-FIX\n- Spec alignment: implementation matches spec intent\n- Code quality: duplicated logic, ignored shared utilities, inconsistent patterns\n- Test quality: no fluff tests, prefer E2E over unit\n\nAfter reviewing, post your review to GitHub using `gh pr review \u003CNUMBER>`.\nFor inline comments, write a JSON body to \u002Ftmp\u002Fcodex-pr-review-body.json with this structure:\n  {\"event\":\"COMMENT\",\"body\":\"summary\",\"comments\":[{\"path\":\"src\u002Ffile.ts\",\"line\":42,\"body\":\"comment\"}]}\nThen post: gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F\u003CNUMBER>\u002Freviews --method POST --input \u002Ftmp\u002Fcodex-pr-review-body.json\n\nAlso write the full review to \u002Ftmp\u002Fcodex-pr-\u003CNUMBER>-review.md\n\nSeverity levels: MUST-FIX, SHOULD-FIX, SUGGESTION.\nPROMPT\n)\"\n```\n\nFor PR reviews that need additional context (task ref, spec ACs), use `codex exec` instead:\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"$(cat \u003C\u003C'PROMPT'\nReview PR #123 in this repository.\n\n1. Get the PR diff: `gh pr diff 123`\n2. Get PR details: `gh pr view 123 --json title,body,files`\n3. Check the PR body for `Task: @task-ref` or `Spec: @spec-ref` trailers:\n   - If `Task:` found: `kspec task get @task-ref` to get spec_ref, then `kspec item get @spec-ref`\n   - If `Spec:` found: `kspec item get @spec-ref` directly\n   - Either way, check acceptance criteria coverage\n4. Review the code for:\n   - Correctness and potential bugs\n   - Own AC coverage: every spec AC should have test with `\u002F\u002F AC: @spec-ref ac-N` annotation\n   - Trait AC coverage: run `kspec item get @spec-ref` to find inherited trait ACs (under \"Inherited from @trait-slug\" sections). Each needs test with `\u002F\u002F AC: @trait-slug ac-N` annotation\n   - Run `kspec validate` — trait AC coverage warnings are MUST-FIX\n   - Spec alignment: implementation matches spec intent, not just syntax\n   - Code quality: duplicated logic, ignored shared utilities, inconsistent patterns\n   - Test quality: no fluff tests, prefer E2E over unit\n5. Write a review body JSON file to \u002Ftmp\u002Fcodex-pr-review-body.json:\n   {\"event\":\"COMMENT\",\"body\":\"summary\",\"comments\":[{\"path\":\"file\",\"line\":N,\"body\":\"comment\"}]}\n   Then post: gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F123\u002Freviews --method POST --input \u002Ftmp\u002Fcodex-pr-review-body.json\n6. Also write the full review to \u002Ftmp\u002Fcodex-pr-123-review.md\n\nIf no Task or Spec trailer exists in the PR body, dig deeper before skipping AC checks:\n   a. Check commit messages for Task: or Spec: trailers\n   b. Search recent tasks: run `kspec tasks list` and match by title\u002Fdescription to PR scope\n   c. Check if changed files have `\u002F\u002F AC: @spec-ref` annotations pointing to specs\n   d. If a task ref is found, resolve to spec: `kspec task get @task-ref --json | jq '.spec_ref'`\n   e. If a spec is found through any of these methods, validate AC coverage identically to the trailer-present case\n   f. Only fall back to pure code review if genuinely no spec exists for the changed behavior\n\nSeverity levels: MUST-FIX, SHOULD-FIX, SUGGESTION.\nPROMPT\n)\"\n```\n\n### AC Coverage Check\n\nWhen a task ref is provided, Codex is instructed to verify:\n- Every own AC has test coverage via `\u002F\u002F AC: @spec-ref ac-N` annotations\n- Every inherited trait AC has test coverage via `\u002F\u002F AC: @trait-slug ac-N` annotations\n- `kspec validate` shows no trait AC coverage warnings for the spec\n- Missing coverage (own or trait) is flagged as `MUST-FIX`\n- Spec alignment: implementation matches spec intent, not just syntax\n\n### Integration with \u002Fpr-review\n\nFor full quality-gate PR review (CI verification, merge decision), use `\u002Fpr-review @task-ref` instead. This skill focuses on **code-level review feedback** — use both together:\n\n```\n\u002Fcodex review #123          # Codex posts inline code review\n\u002Fpr-review @task-ref        # Full quality gate workflow (AC, CI, merge)\n```\n\n## Plan Review Mode\n\n```\n\u002Fcodex review-plan @plan-slug\n\u002Fcodex review-plan .\u002Fpath\u002Fto\u002Fplan.md\n```\n\n### What Codex Checks\n\nCodex can read plans directly via `kspec plan get` or from a file path:\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"Review the plan. Get it with: kspec plan get @plan-slug (or read \u003Cpath>). $(cat \u003C\u003C'PROMPT'\nEvaluate against these criteria and write feedback to \u002Ftmp\u002Fcodex-plan-review.md:\n\n## Structure\n- Has ## Specs section with YAML array?\n- Has ## Tasks section with derive_from_specs line?\n- Has ## Implementation Notes section?\n\n## Spec Quality\n- Every spec has `title` (required)\n- Every spec has `acceptance_criteria` array (strongly recommended)\n- Each AC has id, given, when, then fields\n- AC `then` clauses are concrete and testable (not vague like \"works correctly\")\n- AC are independently testable (not compound)\n- `parent` references use @ prefix and point to valid specs\n- `traits` reference valid trait names with @ prefix\n- `type` is a valid item type (feature, requirement, constraint, decision)\n\n## Completeness\n- Implementation notes present for complex specs\n- No obvious gaps in AC coverage (behaviors described but not covered by AC)\n- Specs don't overlap or duplicate each other\n- Dependencies between specs are explicit\n\n## Red Flags\n- Vague AC: \"then: system behaves correctly\"\n- Untestable AC: \"then: performance is acceptable\"\n- Over-granular AC: one AC per line of code\n- Compound AC: \"X and Y and Z\" in single criterion\n- Missing parent for nested items\n- Trait applied to fewer than 3 specs\n\nFormat: Use ## headers for sections, bullet lists for issues.\nRate severity: MUST-FIX, SHOULD-FIX, SUGGESTION.\nPROMPT\n)\"\n```\n\n### Output\n\nFeedback is written to `\u002Ftmp\u002Fcodex-plan-review.md`. After Codex completes:\n\n```bash\n# Show the user the output path\necho \"Plan review written to \u002Ftmp\u002Fcodex-plan-review.md\"\n\n# Optionally display summary\nhead -50 \u002Ftmp\u002Fcodex-plan-review.md\n```\n\n## Spec Review Mode\n\n```\n\u002Fcodex review-spec @spec-slug\n\u002Fcodex review-spec @module-slug    # Review entire module\n```\n\n### What Codex Checks\n\nCodex can read specs directly via `kspec item get` and validate with `kspec validate`:\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"Review the spec. $(cat \u003C\u003C'PROMPT'\nGet the spec with: kspec item get @spec-slug\nFor module-level review: kspec item list --module @module-slug to get all items, then kspec item get each one.\nAlso run kspec validate for structural issues.\n\nEvaluate and write feedback to \u002Ftmp\u002Fcodex-spec-review.md:\n\n## Acceptance Criteria Quality\n- Are all ACs concrete and independently testable?\n- Do `then` clauses describe observable outcomes (not internal state)?\n- Are ACs atomic (not compound \"X and Y and Z\")?\n- Is coverage complete (all described behaviors have ACs)?\n- Are there ACs that overlap or contradict each other?\n\n## Structure\n- Appropriate item type for content?\n- Description clearly explains purpose?\n- References (depends_on, implements, relates_to) are valid?\n- Status fields consistent (maturity vs implementation)?\n\n## Trait Usage\n- Applied traits are appropriate (behavior applies to this spec)?\n- Cross-cutting behaviors that appear 3+ times should use traits\n- Trait ACs don't conflict with spec-specific ACs\n\n## Testability\n- Can each AC be validated with automated tests?\n- Are preconditions (given) realistic and reproducible?\n- Are actions (when) specific enough to implement?\n\nFormat: ## headers, bullet lists, severity ratings.\nMUST-FIX | SHOULD-FIX | SUGGESTION\nPROMPT\n)\"\n```\n\n### Output\n\nWritten to `\u002Ftmp\u002Fcodex-spec-review.md`.\n\n## General Mode\n\n```\n\u002Fcodex \"analyze the error handling patterns in src\u002Fcli\u002F\"\n\u002Fcodex \"refactor parser module for clarity\"\n```\n\n### Defaults\n\n- **Model:** `gpt-5.3-codex`\n- **Reasoning:** `medium`\n- **Sandbox:** `danger-full-access`\n\n### Command Assembly\n\n```bash\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"medium\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"Your prompt here. Write output to \u002Ftmp\u002Fcodex-output.md\"\n```\n\n## Resuming Sessions\n\n```bash\n# Resume last session with new prompt (positional arg)\ncodex exec --skip-git-repo-check resume --last \"follow-up prompt\"\n\n# Resume last session with prompt from stdin\necho \"follow-up prompt\" | codex exec --skip-git-repo-check resume --last -\n\n# Resume with no additional prompt\ncodex exec --skip-git-repo-check resume --last\n```\n\nWhen resuming, config flags (`-c`, `-m`, `-s`) are accepted and override the original session's settings. All flags must go between `exec` and `resume`.\n\n## Output Convention\n\nAll Codex output is written to `\u002Ftmp\u002Fcodex-*` files:\n\n| Mode | Output file |\n|------|------------|\n| PR review | `\u002Ftmp\u002Fcodex-pr-{number}-review.md` |\n| Plan review | `\u002Ftmp\u002Fcodex-plan-review.md` |\n| Spec review | `\u002Ftmp\u002Fcodex-spec-review.md` |\n| General | `\u002Ftmp\u002Fcodex-output.md` |\n\nAfter every Codex run:\n1. Report the output file path to the user\n2. Summarize key findings\n3. For PR reviews, also post comments to GitHub via `gh`\n\n## Error Handling\n\n- If `codex exec` exits non-zero, report the error and ask the user how to proceed\n- If output file is empty or missing, Codex may have hit a context or timeout issue — re-run without stderr suppression to diagnose\n- For review modes, do NOT suppress stderr — review errors (auth failures, API issues) should be visible\n- For general mode, append `2>\u002Fdev\u002Fnull` to suppress thinking tokens unless debugging\n\n### Preflight Checks\n\nBefore PR review, verify `gh` auth is working:\n\n```bash\ngh auth status\n```\n\nIf auth fails, instruct the user to run `gh auth login` before retrying.\n\n## Overrides\n\nUsers can override any preset:\n\n```\n\u002Fcodex review #123 --model gpt-5.2 -c model_reasoning_effort=\"xhigh\"\n\u002Fcodex \"prompt\" -c model_reasoning_effort=\"high\"\n```\n\nParse overrides from the user's message and map to CLI flags:\n- `--model X` or `-m X` → `-m X`\n- `--effort X` → `-c model_reasoning_effort=\"X\"` (translate to config flag)\n\n## Handling Complex Prompts\n\nWhen prompts contain shell-unsafe characters (quotes, backticks, special characters, or multi-line content), use the **prompt-file pattern** instead of inline quoting:\n\n```bash\n# 1. Write prompt to temp file (use mktemp for safety)\nPROMPT_FILE=$(mktemp \u002Ftmp\u002Fcodex-prompt.XXXXXX)\ncat > \"$PROMPT_FILE\" \u003C\u003C 'EOF'\nReview the code for:\n- Edge cases with special chars like `$var` and \"quoted\" strings\n- Multi-line logic that's hard to escape inline\n- Patterns matching {curly} braces\nEOF\n\n# 2. Use $(cat file) to inject the prompt\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"medium\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"$(cat \"$PROMPT_FILE\")\"\n\n# 3. Clean up\nrm -f \"$PROMPT_FILE\"\n```\n\n### When to Use This Pattern\n\n| Prompt Content | Approach |\n|----------------|----------|\n| Simple one-liner | Inline quotes work fine |\n| Contains `$`, backticks, quotes | Use prompt file |\n| Multi-line with formatting | Use prompt file |\n| Generated or dynamic content | Use prompt file |\n\n### Why Prompt-File Over Heredocs?\n\nQuoted heredocs (`\u003C\u003C'DELIM'...DELIM`) handle quotes, backticks, and `$` literally — they don't cause parsing failures. However, the prompt-file pattern offers practical advantages:\n\n- **Delimiter collision**: If your prompt contains the delimiter string itself, heredocs fail\n- **Mixed expansion**: When you need `$var` expanded in some places but literal in others, heredocs require awkward escaping\n- **Debuggability**: You can `cat \"$PROMPT_FILE\"` to verify exact content before running\n- **Reusability**: Same prompt file can be used across multiple commands\n\nFor simple prompts, heredocs work fine. Use prompt-files when prompts are complex, generated dynamically, or need inspection before use.\n\n## Agent Dispatch Safety Guard\n\nWhen invoking Codex from inside an agent dispatch session, you **MUST** inject safety constraints into every codex prompt. Codex runs with `danger-full-access` and has no awareness of the agent runtime hosting it.\n\n### Detection\n\nBefore running any `codex exec` command, check for agent dispatch context:\n\n```bash\n# Env var set by agent runtime on spawned agent processes\nif [ -n \"$KSPEC_SESSION_ID\" ]; then\n  # We're inside an agent dispatch session — inject safety guard\nfi\n```\n\n### Required Safety Preamble\n\nWhen agent dispatch context is detected, **prepend** this safety block to every codex prompt:\n\n```\nSAFETY CONSTRAINTS (you are running inside a kspec agent dispatch session):\n- NEVER start kspec agent run, kspec serve, or any long-running kspec process\n- NEVER use pkill, kill, killall, or any process-killing command targeting kspec processes\n- NEVER run commands that would terminate or interfere with the parent agent session\n- Do NOT run CLI spot-checks that start background services\n- If you need to verify CLI behavior, use non-destructive read-only commands only\nViolating these constraints will kill the automation session hosting you.\n```\n\n### Example (PR review with safety guard)\n\n```bash\n# Detect agent dispatch context\nAGENT_GUARD=\"\"\nif [ -n \"$KSPEC_SESSION_ID\" ]; then\n  AGENT_GUARD=\"SAFETY CONSTRAINTS (you are running inside a kspec agent dispatch session):\n- NEVER start kspec agent run, kspec serve, or any long-running kspec process\n- NEVER use pkill, kill, killall, or any process-killing command targeting kspec processes\n- NEVER run commands that would terminate or interfere with the parent agent session\n- Do NOT run CLI spot-checks that start background services\n- If you need to verify CLI behavior, use non-destructive read-only commands only\nViolating these constraints will kill the automation session hosting you.\n\n\"\nfi\n\ncodex exec \\\n  -m gpt-5.3-codex \\\n  -c model_reasoning_effort=\"high\" \\\n  -s danger-full-access \\\n  --skip-git-repo-check \\\n  \"${AGENT_GUARD}Review PR #123 in this repository. ...\"\n```\n\n### Why This Matters\n\nIn a previous automation session, Codex ran a \"CLI spot-check\" that accidentally started a long-running kspec process, then ran `pkill` to clean up — which killed the actual automation session hosting it. The session died mid-tool-call with no clean exit.\n\n## Tips\n\n- Always use `--skip-git-repo-check` — this project uses a shadow branch worktree that confuses Codex's git detection\n- For large diffs, pipe through `head -2000` before giving to Codex to stay within context\n- Codex has full access and can run `gh`, `kspec`, `npm`, etc. directly — instruct it to use these tools in your prompt\n- Tell Codex to run `kspec` from the project root, not from inside `.kspec\u002F` (same gotcha agents hit)\n- Use `codex exec review` for straightforward diff reviews (has `--base`, `--commit`, `--uncommitted` flags built in)\n- Do NOT use `--full-auto` — it forces `workspace-write` sandbox, overriding `danger-full-access`\n- Do NOT use `REQUEST_CHANGES` review event — reviews are posted from the repo owner's account, and GitHub prohibits requesting changes on your own PR. Use `COMMENT` for findings or `APPROVE` when clean.\n",{"name":5,"description":7},"main","c4b0de3035f8512bba7eb0a9b4e39ea2fbd3f08e",".claude\u002Fskills\u002Fcodex",2,"https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec","https:\u002F\u002Fgithub.com\u002Flepahc","2026-07-22 18:57:40",{"source":8,"skillName":5,"commands":46,"prompt":56,"zipAvailable":57},[47,50,53],{"tool":48,"command":49},"npx","npx skills add lepahc\u002Fkynetic-spec --skill codex",{"tool":51,"command":52},"bunx","bunx skills add lepahc\u002Fkynetic-spec --skill codex",{"tool":54,"command":55},"pnpm","pnpm dlx skills add lepahc\u002Fkynetic-spec --skill codex","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodex\u002FSKILL.md",true,[59],{"path":60,"resourceType":61,"resourceTypeDesc":62,"sizeBytes":63,"sourceHtmlUrl":64},"scripts\u002Freader.py","SCRIPT","脚本",164,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FSkillSpector\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fmcp_poisoned_tool\u002Fscripts\u002Freader.py",[66,82,88,96,105,113],{"skillNo":67,"name":68,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":79,"publishedAt":33},"01M6C7KCZE43MDZ74FV3A5TDCQ","writing-specs","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Fwriting-specs\u002FSKILL.md",[71,74],{"categoryNo":72,"categoryName":73,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[80,81],"writing","writing specs",{"skillNo":83,"name":84,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":33},"01M6C7KAK9CBJ87PX3BCW7B7YG","triage","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Ftriage\u002FSKILL.md",[],[84],{"skillNo":89,"name":90,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":33},"01M6C7K89VN6FJCT8M86K56EE8","triage-inbox","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Ftriage-inbox\u002FSKILL.md",[],[84,94,95],"inbox","triage inbox",{"skillNo":97,"name":98,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":102,"publishedAt":33},"01M6C7K6F2342AC1TJCN9PM0ZB","triage-automation","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Ftriage-automation\u002FSKILL.md",[101],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[84,103,104],"automation","triage automation",{"skillNo":106,"name":107,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":33},"01M6C7K3TFQ88QQBW3PXYDHQG2","task-work","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Ftask-work\u002FSKILL.md",[],[111,112],"work","task work",{"skillNo":114,"name":23,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":33},"01M6C7K168CH3XJCC3PDGA9H6C","https:\u002F\u002Fgithub.com\u002Flepahc\u002Fkynetic-spec\u002Fblob\u002Fmain\u002Ftemplates\u002Fskills\u002Freview\u002FSKILL.md",[],[23]]