[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BZRDAMNDXGDZNXD2CSARRS":3,"skill-same:01M6BZRDAMNDXGDZNXD2CSARRS":60},{"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":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":14,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":6,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M6BZRDAMNDXGDZNXD2CSARRS","auto-dev",null,"Autonomous PR development methodology. Use ONLY when the user explicitly invokes \u002Fauto-dev or explicitly asks to load this skill — never auto-activate. Reviews every PR twice, monitors all CI pipelines in background, replies to and resolves every review comment from any reviewer (automated systems like CodeRabbit and human reviewers alike), merges PRs (apps or infra) when green, then monitors post-merge and deployment pipelines, iterating on failures.","twidxuga\u002Fdotfiles","twidxuga","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F12471681?v=4","01M6BZR45BH8JCC79Q9SKSS6SC","Ricardo Santos","01M6BZR49CRKSBZYQD1WNQWCXW",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fauto-dev\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33],"dev","auto dev","review","merge","pr","deployment","development","ci","methodology","reviewer","2026-11-10 10:12:30",false,"---\nname: auto-dev\ndescription: Autonomous PR development methodology. Use ONLY when the user explicitly invokes \u002Fauto-dev or explicitly asks to load this skill — never auto-activate. Reviews every PR twice, monitors all CI pipelines in background, replies to and resolves every review comment from any reviewer (automated systems like CodeRabbit and human reviewers alike), merges PRs (apps or infra) when green, then monitors post-merge and deployment pipelines, iterating on failures.\n---\n\n# auto-dev\n\nYou are running the **auto-dev** workflow: an autonomous development methodology applied to every PR you work on in this session.\n\n## Invocation Guard (read first)\n\n- **Explicit-invoke only.** Do NOT load or apply this skill on your own initiative. It activates only when the user runs `\u002Fauto-dev` or explicitly says to use auto-dev. If you find yourself reaching for this skill without an explicit user request, STOP.\n- This is intentionally an autonomous, high-authority skill (it self-merges and self-deploys). It must never run as a silent default.\n\n## Operating Philosophy — No Waits, No Blocks, No Stops\n\nauto-dev is built for **long-running, self-feeding sessions**. After the single up-front consent, it runs fully automated:\n\n- **Never block on a human.** Apart from the one-time consent, do not pause to ask the user for permission, scope, or guidance. Pick the sensible default and proceed.\n- **Never block the main thread.** All pipeline\u002FCI\u002Fdeploy monitoring runs in background agents (Phase 3). You stay free to keep working and answer queries while they run.\n- **Never stop the session on a blocker.** If something can't be auto-resolved (unfixable failure, hit iteration cap, ambiguous scope), **record it, report it inline, and move on** to the next PR \u002F queued work — do not halt and wait. The loop keeps feeding itself.\n- The only safety brakes are *local* (per-PR\u002Fper-deployment): they stop a futile sub-loop, not the session.\n\n## Consent Model\n\nThis skill requires **one-time consent per session**. When you first load this skill, ask the user:\n\n> \"auto-dev is active. This means I will: review every PR twice, monitor all CI pipelines in background agents, reply to and resolve every review comment from any reviewer — CodeRabbit, other review bots, and human reviewers — (fixing the ones that need it), and monitor post-merge + deployment pipelines. I'll merge PRs myself (apps or infra) when all gates are green. Confirm to activate for this session?\"\n\nOnce confirmed, **do not ask again** for the remainder of the session — apply auto-dev to every relevant PR action automatically, including merges and deployments. This is the single allowed interruption; after it, the session is fully automated.\n\n**Compaction note:** if context compaction later drops the consent exchange, treat the skill being active as the standing consent — do NOT re-ask and do NOT block the loop. The user opted into autonomous merging\u002Fdeploying for the whole session when they invoked auto-dev.\n\n---\n\n## Core Principles\n\n- **Two independent review passes before any merge** — both are *your own* passes. Pass 1: your first review, incorporating CI + reviewer signals (CodeRabbit, other bots, human reviewers), where you fix everything actionable. Pass 2: your second, fresh review of the settled diff at the merge gate.\n- **All CI must be green** — zero tolerance for red pipelines before merge.\n- **Every review comment is handled, from any reviewer** — automated systems (CodeRabbit, other review bots) and human reviewers alike. Triage all of them, fix the ones that need it, then **reply to and resolve every thread** (fixed or not). The mechanism is identical for all reviewers — GitHub review threads are reviewer-agnostic. You do NOT need a human reviewer's formal approval to merge — only that their comments are verified and the relevant ones fixed.\n- **You merge yourself** — apps or infra. Do not instruct the user to merge; do it via `gh pr merge`.\n- **Post-merge pipelines are your responsibility** — monitor them; fix failures that originate from your changes.\n- **Background pipeline monitors** — never block the main thread; always monitor in background agents so you can answer queries and work in parallel.\n\n---\n\n## Workflow\n\n### Phase 1 — Pre-Review Setup\n\nWhen a PR is ready for review (created or handed to you). Run `gh` from inside the repo, or pass `--repo \u003Cowner>\u002F\u003Crepo>` explicitly on every command:\n\n1. Fetch PR details:\n   ```bash\n   gh pr view \u003CPR> --repo \u003Cowner>\u002F\u003Crepo> --json number,title,url,headRefName,baseRefName,body,state,reviews,statusCheckRollup\n   ```\n\n2. Read the full diff:\n   ```bash\n   gh pr diff \u003CPR> --repo \u003Cowner>\u002F\u003Crepo>\n   ```\n\n3. Fetch all review threads with their node IDs (needed for replying + resolving later). This GitHub API is reviewer-agnostic — it returns threads from every reviewer: automated bots (CodeRabbit appears as `coderabbitai[bot]`, other bots have their own `[bot]` logins) and human reviewers (their GitHub handle). The `author.login` field on each comment tells you who left it, so you can tailor the reply, but you handle them all:\n   ```bash\n   gh api graphql \\\n     -f query='query($owner:String!, $repo:String!, $pr:Int!, $first:Int!) {\n       repository(owner: $owner, name: $repo) {\n         pullRequest(number: $pr) {\n           reviewThreads(first: $first) {\n             nodes {\n               id\n               isResolved\n               isOutdated\n               comments(first: 100) {\n                 nodes { databaseId author { login } body }\n               }\n             }\n           }\n         }\n       }\n     }' \\\n     -f owner='\u003Cowner>' -f repo='\u003Crepo>' -F pr=\u003CPR> -F first=100\n   ```\n   Record every unresolved thread's `id` (`PRRT_...`) along with its author login(s) — you will reply to and resolve every one in Phase 2, regardless of whether the reviewer is a bot or a human. Skip threads already `isResolved: true`.\n\n4. Launch a background CI monitor (see Phase 3) immediately — don't wait for CI before starting your review.\n\n---\n\n### Phase 2 — First Review (your first pass)\n\nThis is **your own** first review pass. CI and reviewer comments (CodeRabbit, other bots, human reviewers) are inputs to it, not a substitute for it.\n\n1. Triage every review comment, from any reviewer (bot or human):\n   - `fix-required` — correctness, security, logic error, broken test, type error\n   - `fix-recommended` — style, naming, clarity (fix unless trivial churn)\n   - `nitpick` — optional, low-value; note but don't block\n   - `stale` — comment on code already changed; no fix needed\n   - Treat a human reviewer's `fix-required`\u002F`fix-recommended` with at least the same weight as a bot's — and prefer fixing over dismissing when a human raised it.\n\n2. Read the diff yourself, independent of the reviewers. Look for:\n   - Logic errors not caught by any reviewer\n   - Missing tests for new behaviour\n   - Undocumented breaking changes\n   - Obvious performance issues\n\n3. Compile a **first-pass action list** — all `fix-required` and `fix-recommended` items (reviewer-found, bot or human, + your own findings).\n\n4. If the action list is non-empty:\n   - Check out the branch, apply all fixes\n   - Commit clearly (e.g. `fix: address first-round review comments`)\n   - Push (re-triggers CI)\n   - Launch a NEW background CI monitor for the new commit\n   - **Do not proceed to the Phase 4 merge gate until the new CI run completes**\n\n5. **Reply to and resolve EVERY review thread** — from any reviewer (bot or human), regardless of whether it produced a fix. For each thread `id` recorded in Phase 1:\n\n   Reply (note the input field is `pullRequestReviewThreadId`). Write a real, courteous reply — especially for human reviewers, the reply should explain what you did or why no change was needed, not just \"done\":\n   ```bash\n   gh api graphql \\\n     -f query='mutation($threadId: ID!, $body: String!) {\n       addPullRequestReviewThreadReply(input: { pullRequestReviewThreadId: $threadId, body: $body }) {\n         comment { id }\n       }\n     }' \\\n     -f threadId='PRRT_...' \\\n     -f body='Fixed in \u003Ccommit-sha>.'        # or: 'Acknowledged — no change needed: \u003Creason>.'\n   ```\n\n   Resolve (note this mutation's input field is `threadId`, NOT `pullRequestReviewThreadId`):\n   ```bash\n   gh api graphql \\\n     -f query='mutation($threadId: ID!) {\n       resolveReviewThread(input: { threadId: $threadId }) {\n         thread { isResolved }\n       }\n     }' \\\n     -f threadId='PRRT_...'\n   ```\n\n   The merge gate requires **every** review thread (any reviewer) replied-to and `isResolved: true`.\n\n---\n\n### Phase 3 — Pipeline Monitoring (Background, Always)\n\n**Rule: every CI run you care about gets its own background monitor. Never block on pipelines yourself.**\n\nThe monitor must NOT poll in an LLM loop — it runs a single **blocking shell command** (`gh pr checks --watch`), which waits in the shell with zero token cost and exits non-zero on failure. Use the cheapest tier (`quick`):\n\n```\ntask(\n  category=\"quick\",\n  load_skills=[],\n  run_in_background=true,\n  description=\"Monitor CI for PR #\u003CN>\",\n  prompt=\"\"\"\n  TASK: Monitor CI for PR #\u003CN> (\u003Cbranch>) until all checks settle, then report.\n\n  REQUIRED TOOLS: Bash (gh CLI) only.\n\n  MUST DO:\n  - Run exactly one blocking command and let it wait for you:\n      gh pr checks \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --watch --interval 60\n    This blocks until every check reaches a terminal state, then exits:\n      exit 0 = all passed | exit 1 = a check failed | exit 8 = still pending\u002Fnone\n  - If exit code is non-zero, identify the failed run and fetch its logs:\n      gh run list --repo \u003Cowner>\u002F\u003Crepo> --branch \u003Cbranch> --limit 5\n      gh run view \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo> --log-failed\n  - Report: each check name + status, the exit code, and (on failure) the\n    failing check, the log URL, and a ~50-line error summary.\n\n  MUST NOT DO:\n  - Do NOT poll in a model loop (no repeated single `gh pr checks` calls) —\n    the --watch command blocks for you in the shell.\n  - Do NOT fix anything or modify files.\n  - Do NOT report success while exit code is 8 (still pending) — re-run --watch.\n\n  CONTEXT:\n  - PR: #\u003CN> — \u003Ctitle> | Branch: \u003Cbranch> → \u003Cbase> | Repo: \u003Cowner>\u002F\u003Crepo>\n  \"\"\"\n)\n```\n\nStore the background task ID (`bg_...`) and continuation session ID (`ses_...`). When the `\u003Csystem-reminder>` fires, collect results via `background_output` and act on failures.\n\n**Simultaneous monitors are normal.** You may have 3–5 running at once (pre-fix CI, post-fix CI, post-merge deploy, etc.). This is expected and correct.\n\n---\n\n### Phase 4 — Second Review (Merge Gate, your second pass)\n\nThis is **your own** second, fresh review of the settled diff. Perform it **only after**:\n- All CI checks are green on the latest commit\n- **Every** review thread (any reviewer — bot or human) is replied-to and resolved (`isResolved: true`)\n\nYou do NOT wait on a human reviewer's formal approval — verifying and resolving their comments (fixing the relevant ones) is sufficient.\n\nSecond-pass checklist:\n1. Re-read the full diff one more time: `gh pr diff \u003CPR> --repo \u003Cowner>\u002F\u003Crepo>`\n2. Re-verify no thread is left unresolved (re-run the Phase 1 GraphQL query; all should be `isResolved: true`)\n3. Verify commit history is clean (no stray debug\u002FWIP commits)\n4. Confirm the PR description matches what's being merged\n\nIf anything new surfaces → fix it, push, and restart from Phase 2 (new reviewer\u002FCI cycle). If clean → proceed to merge.\n\n---\n\n### Phase 5 — Merge\n\nMerge synchronously yourself — no waiting, no confirmation prompt (consent was granted once at session start). You are the gate, so do **not** use `--auto` (that would defer the merge to GitHub and fire before\u002Findependent of your gate):\n\n```bash\n# Feature branches → squash:\ngh pr merge \u003CPR> --repo \u003Cowner>\u002F\u003Crepo> --squash --delete-branch\n# Release\u002Finfra branches with meaningful history → merge commit:\ngh pr merge \u003CPR> --repo \u003Cowner>\u002F\u003Crepo> --merge --delete-branch\n```\n\nDefault to `--squash` unless the branch warrants a merge commit (release trains, infra PRs with meaningful history).\n\nConfirm the merge actually happened before starting post-merge monitoring:\n```bash\ngh pr view \u003CPR> --repo \u003Cowner>\u002F\u003Crepo> --json state,mergedAt,mergedBy\n```\n`state` must be `MERGED` and `mergedAt` non-null before proceeding to Phase 6.\n\n---\n\n### Phase 6 — Post-Merge Pipeline Monitoring\n\nImmediately after a confirmed merge, identify and monitor all downstream pipelines.\n\n**App repos (pipeline triggers on push to the base branch):**\n```bash\ngh run list --repo \u003Cowner>\u002F\u003Crepo> --branch \u003Cbase_branch> --limit 10\n```\nTake the new run and monitor it with a Phase 3-style background monitor (`gh run watch \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo>` blocks until it settles).\n\n**Infra repos (pipeline does NOT trigger on push to main — only on PR or `workflow_dispatch`):**\nFor infra, merging produces a push-to-main that triggers **no** deployment pipeline. Do not wait on a run that will never start. Instead, trigger the deployment explicitly via `workflow_dispatch`, then monitor that run:\n```bash\n# Trigger the deployment workflow (only when a deploy is intended):\ngh workflow run \u003Cdeploy-workflow>.yml --repo \u003Cowner>\u002F\u003Crepo> --ref \u003Cbranch> [-f \u003Cinput>=\u003Cvalue> ...]\n# Find the run it created and monitor it:\ngh run list --repo \u003Cowner>\u002F\u003Crepo> --workflow \u003Cdeploy-workflow>.yml --limit 5\ngh run watch \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo>\n```\nDispatch the deployment automatically — do not pause to ask which services. Default scope: deploy the service(s) changed by the merge (infer from the changed paths \u002F affected service dirs). If the repo has an obvious \"deploy everything\" workflow and no per-service split, use it. State the scope you chose inline and proceed.\n\n**ArgoCD \u002F Kubernetes (only if you have cluster access — check first):**\n```bash\nkubectl rollout status deployment\u002F\u003Cname> -n \u003Cnamespace>   # requires kubeconfig\u002Fcontext\n```\nIf there is no cluster context available, skip and report rather than guessing.\n\nLaunch a background monitor for each downstream pipeline (Phase 3 pattern).\n\n**You are responsible for failures that trace back to your merged changes.** If a post-merge pipeline fails:\n1. Determine whether the failure is caused by your change (logs, compare to pre-merge baseline)\n2. If yes → fix forward: new branch, fix, new PR, full auto-dev cycle (subject to the iteration cap below)\n3. If no (pre-existing\u002Funrelated) → report to user; do not attempt to fix\n\n---\n\n### Phase 7 — Service Deployment Monitoring\n\nIf the merge (or a `workflow_dispatch` you triggered) launches a service deployment (Kubernetes rollout, ECS task update, Lambda deploy, etc.):\n\n1. Launch a dedicated background monitor for the deployment\n2. Monitor until it reaches a stable terminal state (`rollout complete`, `deployment available`, `task running`, etc.)\n3. If it fails or rolls back:\n   - Collect the failure reason (pod logs, deployment events, CloudWatch logs as applicable)\n   - Determine if caused by your change\n   - If yes → investigate, fix, re-deploy following this same methodology (subject to the iteration cap)\n   - Report to user with full context\n\n---\n\n## Iteration Rule\n\nEvery fix cycle (reviewer comment — bot or human, CI failure, or post-merge issue) follows the same methodology:\n\n1. Fix on the appropriate branch\n2. Push → triggers CI\n3. Launch background CI monitor (Phase 3)\n4. CI green → reply+resolve threads → second review → merge (or re-merge for post-merge fixes)\n5. Launch post-merge \u002F deployment monitor\n6. Repeat until stable\n\n**Local safety brakes (per-PR\u002Fper-deployment — they stop a futile sub-loop, NOT the session):**\n- **Maximum 5 fix-forward cycles** per PR\u002Fdeployment. On reaching 5, stop iterating *that* PR, **park it** (post an inline note on the PR + report in-session summarizing what was attempted), and **move on** to the next PR \u002F queued work. Do not halt the session or wait for the user.\n- **Circuit breaker:** if the *same* check\u002Ferror fails twice in a row despite a fix, stop pushing fixes for *that* failure immediately — never shotgun the same error. Park the PR with a note and continue the session.\n\nThese brakes bound a single PR's effort; they never stop the overall self-feeding loop. Within the brakes, a PR has no exit until its deployment is stable and all pipelines are green — but a parked PR is set aside, not blocked-on.\n\n---\n\n## Background Agent Management\n\n- Store every background task ID (`bg_...`) you launch and its continuation session ID (`ses_...`)\n- When a `\u003Csystem-reminder>` fires, immediately `background_output(task_id=\"bg_...\")` to collect results\n- Cancel monitors superseded by a new commit via `background_cancel(taskId=\"bg_...\")`\n- **Never** use `background_cancel(all=true)` — cancel individually\n\n---\n\n## User Communication\n\n- Launching a monitor: \"Monitoring [pipeline] in background — I'll alert you when it completes.\"\n- About to merge: \"All checks green, every review thread resolved, second review clean — merging now.\"\n- Background failure: \"⚠️ [check] failed on PR #N — [brief error]. Fixing now (cycle X\u002F5).\"\n- Parked a PR (cap\u002Fbreaker hit): \"⏸ Parked PR #N after [N cycles \u002F repeated failure] — [summary]. Moving on; flagged for later.\" (report, don't wait)\n- After stable deploy: \"✅ PR #N merged and [service] deployed successfully.\"\n- You may answer user queries at any time while monitors run in the background.\n\n---\n\n## Tool Reference\n\n```bash\n# PR operations (pass --repo \u003Cowner>\u002F\u003Crepo> or run from inside the repo)\ngh pr view \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --json number,title,url,headRefName,baseRefName,body,state,statusCheckRollup\ngh pr diff \u003CN> --repo \u003Cowner>\u002F\u003Crepo>\ngh pr checks \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --watch --interval 60   # blocks; exit 0 pass \u002F 1 fail \u002F 8 pending\ngh pr view \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --comments\ngh pr merge \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --squash --delete-branch  # synchronous; NO --auto\ngh pr merge \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --merge  --delete-branch\n\n# CI run operations\ngh run list  --repo \u003Cowner>\u002F\u003Crepo> --branch \u003Cbranch> --limit 10\ngh run view  \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo>\ngh run view  \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo> --log-failed\ngh run watch \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo>                      # blocks until settled\n\n# Infra deployment (workflow_dispatch — infra does not deploy on push to main)\ngh workflow run \u003Cdeploy>.yml --repo \u003Cowner>\u002F\u003Crepo> --ref \u003Cbranch> [-f key=value ...]\n\n# Review threads — any reviewer (CodeRabbit, other bots, humans): list (get PRRT_ ids), reply, resolve — all GitHub GraphQL\n# List threads + comment authors (author.login shows bot vs human):\ngh api graphql -f query='query($owner:String!,$repo:String!,$pr:Int!,$first:Int!){repository(owner:$owner,name:$repo){pullRequest(number:$pr){reviewThreads(first:$first){nodes{id isResolved isOutdated comments(first:100){nodes{databaseId author{login} body}}}}}}}' -f owner='\u003Cowner>' -f repo='\u003Crepo>' -F pr=\u003CN> -F first=100\n# Reply to a thread (input field: pullRequestReviewThreadId):\ngh api graphql -f query='mutation($threadId:ID!,$body:String!){addPullRequestReviewThreadReply(input:{pullRequestReviewThreadId:$threadId,body:$body}){comment{id}}}' -f threadId='PRRT_...' -f body='Fixed in \u003Csha>.'\n# Resolve a thread (input field: threadId):\ngh api graphql -f query='mutation($threadId:ID!){resolveReviewThread(input:{threadId:$threadId}){thread{isResolved}}}' -f threadId='PRRT_...'\n```\n\n> GraphQL var typing with `gh api graphql`: use `-F` for Int\u002FBoolean (`pr`, `first`), `-f` for strings (`owner`, `repo`, `threadId`, `body`).\n","# auto-dev\n\nYou are running the **auto-dev** workflow: an autonomous development methodology applied to every PR you work on in this session.\n\n## Invocation Guard (read first)\n\n- **Explicit-invoke only.** Do NOT load or apply this skill on your own initiative. It activates only when the user runs `\u002Fauto-dev` or explicitly says to use auto-dev. If you find yourself reaching for this skill without an explicit user request, STOP.\n- This is intentionally an autonomous, high-authority skill (it self-merges and self-deploys). It must never run as a silent default.\n\n## Operating Philosophy — No Waits, No Blocks, No Stops\n\nauto-dev is built for **long-running, self-feeding sessions**. After the single up-front consent, it runs fully automated:\n\n- **Never block on a human.** Apart from the one-time consent, do not pause to ask the user for permission, scope, or guidance. Pick the sensible default and proceed.\n- **Never block the main thread.** All pipeline\u002FCI\u002Fdeploy monitoring runs in background agents (Phase 3). You stay free to keep working and answer queries while they run.\n- **Never stop the session on a blocker.** If something can't be auto-resolved (unfixable failure, hit iteration cap, ambiguous scope), **record it, report it inline, and move on** to the next PR \u002F queued work — do not halt and wait. The loop keeps feeding itself.\n- The only safety brakes are *local* (per-PR\u002Fper-deployment): they stop a futile sub-loop, not the session.\n\n## Consent Model\n\nThis skill requires **one-time consent per session**. When you first load this skill, ask the user:\n\n> \"auto-dev is active. This means I will: review every PR twice, monitor all CI pipelines in background agents, reply to and resolve every review comment from any reviewer — CodeRabbit, other review bots, and human reviewers — (fixing the ones that need it), and monitor post-merge + deployment pipelines. I'll merge PRs myself (apps or infra) when all gates are green. Confirm to activate for this session?\"\n\nOnce confirmed, **do not ask again** for the remainder of the session — apply auto-dev to every relevant PR action automatically, including merges and deployments. This is the single allowed interruption; after it, the session is fully automated.\n\n**Compaction note:** if context compaction later drops the consent exchange, treat the skill being active as the standing consent — do NOT re-ask and do NOT block the loop. The user opted into autonomous merging\u002Fdeploying for the whole session when they invoked auto-dev.\n\n---\n\n## Core Principles\n\n- **Two independent review passes before any merge** — both are *your own* passes. Pass 1: your first review, incorporating CI + reviewer signals (CodeRabbit, other bots, human reviewers), where you fix everything actionable. Pass 2: your second, fresh review of the settled diff at the merge gate.\n- **All CI must be green** — zero tolerance for red pipelines before merge.\n- **Every review comment is handled, from any reviewer** — automated systems (CodeRabbit, other review bots) and human reviewers alike. Triage all of them, fix the ones that need it, then **reply to and resolve every thread** (fixed or not). The mechanism is identical for all reviewers — GitHub review threads are reviewer-agnostic. You do NOT need a human reviewer's formal approval to merge — only that their comments are verified and the relevant ones fixed.\n- **You merge yourself** — apps or infra. Do not instruct the user to merge; do it via `gh pr merge`.\n- **Post-merge pipelines are your responsibility** — monitor them; fix failures that originate from your changes.\n- **Background pipeline monitors** — never block the main thread; always monitor in background agents so you can answer queries and work in parallel.\n\n---\n\n## Workflow\n\n### Phase 1 — Pre-Review Setup\n\nWhen a PR is ready for review (created or handed to you). Run `gh` from inside the repo, or pass `--repo \u003Cowner>\u002F\u003Crepo>` explicitly on every command:\n\n1. Fetch PR details:\n   ```bash\n   gh pr view \u003CPR> --repo \u003Cowner>\u002F\u003Crepo> --json number,title,url,headRefName,baseRefName,body,state,reviews,statusCheckRollup\n   ```\n\n2. Read the full diff:\n   ```bash\n   gh pr diff \u003CPR> --repo \u003Cowner>\u002F\u003Crepo>\n   ```\n\n3. Fetch all review threads with their node IDs (needed for replying + resolving later). This GitHub API is reviewer-agnostic — it returns threads from every reviewer: automated bots (CodeRabbit appears as `coderabbitai[bot]`, other bots have their own `[bot]` logins) and human reviewers (their GitHub handle). The `author.login` field on each comment tells you who left it, so you can tailor the reply, but you handle them all:\n   ```bash\n   gh api graphql \\\n     -f query='query($owner:String!, $repo:String!, $pr:Int!, $first:Int!) {\n       repository(owner: $owner, name: $repo) {\n         pullRequest(number: $pr) {\n           reviewThreads(first: $first) {\n             nodes {\n               id\n               isResolved\n               isOutdated\n               comments(first: 100) {\n                 nodes { databaseId author { login } body }\n               }\n             }\n           }\n         }\n       }\n     }' \\\n     -f owner='\u003Cowner>' -f repo='\u003Crepo>' -F pr=\u003CPR> -F first=100\n   ```\n   Record every unresolved thread's `id` (`PRRT_...`) along with its author login(s) — you will reply to and resolve every one in Phase 2, regardless of whether the reviewer is a bot or a human. Skip threads already `isResolved: true`.\n\n4. Launch a background CI monitor (see Phase 3) immediately — don't wait for CI before starting your review.\n\n---\n\n### Phase 2 — First Review (your first pass)\n\nThis is **your own** first review pass. CI and reviewer comments (CodeRabbit, other bots, human reviewers) are inputs to it, not a substitute for it.\n\n1. Triage every review comment, from any reviewer (bot or human):\n   - `fix-required` — correctness, security, logic error, broken test, type error\n   - `fix-recommended` — style, naming, clarity (fix unless trivial churn)\n   - `nitpick` — optional, low-value; note but don't block\n   - `stale` — comment on code already changed; no fix needed\n   - Treat a human reviewer's `fix-required`\u002F`fix-recommended` with at least the same weight as a bot's — and prefer fixing over dismissing when a human raised it.\n\n2. Read the diff yourself, independent of the reviewers. Look for:\n   - Logic errors not caught by any reviewer\n   - Missing tests for new behaviour\n   - Undocumented breaking changes\n   - Obvious performance issues\n\n3. Compile a **first-pass action list** — all `fix-required` and `fix-recommended` items (reviewer-found, bot or human, + your own findings).\n\n4. If the action list is non-empty:\n   - Check out the branch, apply all fixes\n   - Commit clearly (e.g. `fix: address first-round review comments`)\n   - Push (re-triggers CI)\n   - Launch a NEW background CI monitor for the new commit\n   - **Do not proceed to the Phase 4 merge gate until the new CI run completes**\n\n5. **Reply to and resolve EVERY review thread** — from any reviewer (bot or human), regardless of whether it produced a fix. For each thread `id` recorded in Phase 1:\n\n   Reply (note the input field is `pullRequestReviewThreadId`). Write a real, courteous reply — especially for human reviewers, the reply should explain what you did or why no change was needed, not just \"done\":\n   ```bash\n   gh api graphql \\\n     -f query='mutation($threadId: ID!, $body: String!) {\n       addPullRequestReviewThreadReply(input: { pullRequestReviewThreadId: $threadId, body: $body }) {\n         comment { id }\n       }\n     }' \\\n     -f threadId='PRRT_...' \\\n     -f body='Fixed in \u003Ccommit-sha>.'        # or: 'Acknowledged — no change needed: \u003Creason>.'\n   ```\n\n   Resolve (note this mutation's input field is `threadId`, NOT `pullRequestReviewThreadId`):\n   ```bash\n   gh api graphql \\\n     -f query='mutation($threadId: ID!) {\n       resolveReviewThread(input: { threadId: $threadId }) {\n         thread { isResolved }\n       }\n     }' \\\n     -f threadId='PRRT_...'\n   ```\n\n   The merge gate requires **every** review thread (any reviewer) replied-to and `isResolved: true`.\n\n---\n\n### Phase 3 — Pipeline Monitoring (Background, Always)\n\n**Rule: every CI run you care about gets its own background monitor. Never block on pipelines yourself.**\n\nThe monitor must NOT poll in an LLM loop — it runs a single **blocking shell command** (`gh pr checks --watch`), which waits in the shell with zero token cost and exits non-zero on failure. Use the cheapest tier (`quick`):\n\n```\ntask(\n  category=\"quick\",\n  load_skills=[],\n  run_in_background=true,\n  description=\"Monitor CI for PR #\u003CN>\",\n  prompt=\"\"\"\n  TASK: Monitor CI for PR #\u003CN> (\u003Cbranch>) until all checks settle, then report.\n\n  REQUIRED TOOLS: Bash (gh CLI) only.\n\n  MUST DO:\n  - Run exactly one blocking command and let it wait for you:\n      gh pr checks \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --watch --interval 60\n    This blocks until every check reaches a terminal state, then exits:\n      exit 0 = all passed | exit 1 = a check failed | exit 8 = still pending\u002Fnone\n  - If exit code is non-zero, identify the failed run and fetch its logs:\n      gh run list --repo \u003Cowner>\u002F\u003Crepo> --branch \u003Cbranch> --limit 5\n      gh run view \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo> --log-failed\n  - Report: each check name + status, the exit code, and (on failure) the\n    failing check, the log URL, and a ~50-line error summary.\n\n  MUST NOT DO:\n  - Do NOT poll in a model loop (no repeated single `gh pr checks` calls) —\n    the --watch command blocks for you in the shell.\n  - Do NOT fix anything or modify files.\n  - Do NOT report success while exit code is 8 (still pending) — re-run --watch.\n\n  CONTEXT:\n  - PR: #\u003CN> — \u003Ctitle> | Branch: \u003Cbranch> → \u003Cbase> | Repo: \u003Cowner>\u002F\u003Crepo>\n  \"\"\"\n)\n```\n\nStore the background task ID (`bg_...`) and continuation session ID (`ses_...`). When the `\u003Csystem-reminder>` fires, collect results via `background_output` and act on failures.\n\n**Simultaneous monitors are normal.** You may have 3–5 running at once (pre-fix CI, post-fix CI, post-merge deploy, etc.). This is expected and correct.\n\n---\n\n### Phase 4 — Second Review (Merge Gate, your second pass)\n\nThis is **your own** second, fresh review of the settled diff. Perform it **only after**:\n- All CI checks are green on the latest commit\n- **Every** review thread (any reviewer — bot or human) is replied-to and resolved (`isResolved: true`)\n\nYou do NOT wait on a human reviewer's formal approval — verifying and resolving their comments (fixing the relevant ones) is sufficient.\n\nSecond-pass checklist:\n1. Re-read the full diff one more time: `gh pr diff \u003CPR> --repo \u003Cowner>\u002F\u003Crepo>`\n2. Re-verify no thread is left unresolved (re-run the Phase 1 GraphQL query; all should be `isResolved: true`)\n3. Verify commit history is clean (no stray debug\u002FWIP commits)\n4. Confirm the PR description matches what's being merged\n\nIf anything new surfaces → fix it, push, and restart from Phase 2 (new reviewer\u002FCI cycle). If clean → proceed to merge.\n\n---\n\n### Phase 5 — Merge\n\nMerge synchronously yourself — no waiting, no confirmation prompt (consent was granted once at session start). You are the gate, so do **not** use `--auto` (that would defer the merge to GitHub and fire before\u002Findependent of your gate):\n\n```bash\n# Feature branches → squash:\ngh pr merge \u003CPR> --repo \u003Cowner>\u002F\u003Crepo> --squash --delete-branch\n# Release\u002Finfra branches with meaningful history → merge commit:\ngh pr merge \u003CPR> --repo \u003Cowner>\u002F\u003Crepo> --merge --delete-branch\n```\n\nDefault to `--squash` unless the branch warrants a merge commit (release trains, infra PRs with meaningful history).\n\nConfirm the merge actually happened before starting post-merge monitoring:\n```bash\ngh pr view \u003CPR> --repo \u003Cowner>\u002F\u003Crepo> --json state,mergedAt,mergedBy\n```\n`state` must be `MERGED` and `mergedAt` non-null before proceeding to Phase 6.\n\n---\n\n### Phase 6 — Post-Merge Pipeline Monitoring\n\nImmediately after a confirmed merge, identify and monitor all downstream pipelines.\n\n**App repos (pipeline triggers on push to the base branch):**\n```bash\ngh run list --repo \u003Cowner>\u002F\u003Crepo> --branch \u003Cbase_branch> --limit 10\n```\nTake the new run and monitor it with a Phase 3-style background monitor (`gh run watch \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo>` blocks until it settles).\n\n**Infra repos (pipeline does NOT trigger on push to main — only on PR or `workflow_dispatch`):**\nFor infra, merging produces a push-to-main that triggers **no** deployment pipeline. Do not wait on a run that will never start. Instead, trigger the deployment explicitly via `workflow_dispatch`, then monitor that run:\n```bash\n# Trigger the deployment workflow (only when a deploy is intended):\ngh workflow run \u003Cdeploy-workflow>.yml --repo \u003Cowner>\u002F\u003Crepo> --ref \u003Cbranch> [-f \u003Cinput>=\u003Cvalue> ...]\n# Find the run it created and monitor it:\ngh run list --repo \u003Cowner>\u002F\u003Crepo> --workflow \u003Cdeploy-workflow>.yml --limit 5\ngh run watch \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo>\n```\nDispatch the deployment automatically — do not pause to ask which services. Default scope: deploy the service(s) changed by the merge (infer from the changed paths \u002F affected service dirs). If the repo has an obvious \"deploy everything\" workflow and no per-service split, use it. State the scope you chose inline and proceed.\n\n**ArgoCD \u002F Kubernetes (only if you have cluster access — check first):**\n```bash\nkubectl rollout status deployment\u002F\u003Cname> -n \u003Cnamespace>   # requires kubeconfig\u002Fcontext\n```\nIf there is no cluster context available, skip and report rather than guessing.\n\nLaunch a background monitor for each downstream pipeline (Phase 3 pattern).\n\n**You are responsible for failures that trace back to your merged changes.** If a post-merge pipeline fails:\n1. Determine whether the failure is caused by your change (logs, compare to pre-merge baseline)\n2. If yes → fix forward: new branch, fix, new PR, full auto-dev cycle (subject to the iteration cap below)\n3. If no (pre-existing\u002Funrelated) → report to user; do not attempt to fix\n\n---\n\n### Phase 7 — Service Deployment Monitoring\n\nIf the merge (or a `workflow_dispatch` you triggered) launches a service deployment (Kubernetes rollout, ECS task update, Lambda deploy, etc.):\n\n1. Launch a dedicated background monitor for the deployment\n2. Monitor until it reaches a stable terminal state (`rollout complete`, `deployment available`, `task running`, etc.)\n3. If it fails or rolls back:\n   - Collect the failure reason (pod logs, deployment events, CloudWatch logs as applicable)\n   - Determine if caused by your change\n   - If yes → investigate, fix, re-deploy following this same methodology (subject to the iteration cap)\n   - Report to user with full context\n\n---\n\n## Iteration Rule\n\nEvery fix cycle (reviewer comment — bot or human, CI failure, or post-merge issue) follows the same methodology:\n\n1. Fix on the appropriate branch\n2. Push → triggers CI\n3. Launch background CI monitor (Phase 3)\n4. CI green → reply+resolve threads → second review → merge (or re-merge for post-merge fixes)\n5. Launch post-merge \u002F deployment monitor\n6. Repeat until stable\n\n**Local safety brakes (per-PR\u002Fper-deployment — they stop a futile sub-loop, NOT the session):**\n- **Maximum 5 fix-forward cycles** per PR\u002Fdeployment. On reaching 5, stop iterating *that* PR, **park it** (post an inline note on the PR + report in-session summarizing what was attempted), and **move on** to the next PR \u002F queued work. Do not halt the session or wait for the user.\n- **Circuit breaker:** if the *same* check\u002Ferror fails twice in a row despite a fix, stop pushing fixes for *that* failure immediately — never shotgun the same error. Park the PR with a note and continue the session.\n\nThese brakes bound a single PR's effort; they never stop the overall self-feeding loop. Within the brakes, a PR has no exit until its deployment is stable and all pipelines are green — but a parked PR is set aside, not blocked-on.\n\n---\n\n## Background Agent Management\n\n- Store every background task ID (`bg_...`) you launch and its continuation session ID (`ses_...`)\n- When a `\u003Csystem-reminder>` fires, immediately `background_output(task_id=\"bg_...\")` to collect results\n- Cancel monitors superseded by a new commit via `background_cancel(taskId=\"bg_...\")`\n- **Never** use `background_cancel(all=true)` — cancel individually\n\n---\n\n## User Communication\n\n- Launching a monitor: \"Monitoring [pipeline] in background — I'll alert you when it completes.\"\n- About to merge: \"All checks green, every review thread resolved, second review clean — merging now.\"\n- Background failure: \"⚠️ [check] failed on PR #N — [brief error]. Fixing now (cycle X\u002F5).\"\n- Parked a PR (cap\u002Fbreaker hit): \"⏸ Parked PR #N after [N cycles \u002F repeated failure] — [summary]. Moving on; flagged for later.\" (report, don't wait)\n- After stable deploy: \"✅ PR #N merged and [service] deployed successfully.\"\n- You may answer user queries at any time while monitors run in the background.\n\n---\n\n## Tool Reference\n\n```bash\n# PR operations (pass --repo \u003Cowner>\u002F\u003Crepo> or run from inside the repo)\ngh pr view \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --json number,title,url,headRefName,baseRefName,body,state,statusCheckRollup\ngh pr diff \u003CN> --repo \u003Cowner>\u002F\u003Crepo>\ngh pr checks \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --watch --interval 60   # blocks; exit 0 pass \u002F 1 fail \u002F 8 pending\ngh pr view \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --comments\ngh pr merge \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --squash --delete-branch  # synchronous; NO --auto\ngh pr merge \u003CN> --repo \u003Cowner>\u002F\u003Crepo> --merge  --delete-branch\n\n# CI run operations\ngh run list  --repo \u003Cowner>\u002F\u003Crepo> --branch \u003Cbranch> --limit 10\ngh run view  \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo>\ngh run view  \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo> --log-failed\ngh run watch \u003Crun_id> --repo \u003Cowner>\u002F\u003Crepo>                      # blocks until settled\n\n# Infra deployment (workflow_dispatch — infra does not deploy on push to main)\ngh workflow run \u003Cdeploy>.yml --repo \u003Cowner>\u002F\u003Crepo> --ref \u003Cbranch> [-f key=value ...]\n\n# Review threads — any reviewer (CodeRabbit, other bots, humans): list (get PRRT_ ids), reply, resolve — all GitHub GraphQL\n# List threads + comment authors (author.login shows bot vs human):\ngh api graphql -f query='query($owner:String!,$repo:String!,$pr:Int!,$first:Int!){repository(owner:$owner,name:$repo){pullRequest(number:$pr){reviewThreads(first:$first){nodes{id isResolved isOutdated comments(first:100){nodes{databaseId author{login} body}}}}}}}' -f owner='\u003Cowner>' -f repo='\u003Crepo>' -F pr=\u003CN> -F first=100\n# Reply to a thread (input field: pullRequestReviewThreadId):\ngh api graphql -f query='mutation($threadId:ID!,$body:String!){addPullRequestReviewThreadReply(input:{pullRequestReviewThreadId:$threadId,body:$body}){comment{id}}}' -f threadId='PRRT_...' -f body='Fixed in \u003Csha>.'\n# Resolve a thread (input field: threadId):\ngh api graphql -f query='mutation($threadId:ID!){resolveReviewThread(input:{threadId:$threadId}){thread{isResolved}}}' -f threadId='PRRT_...'\n```\n\n> GraphQL var typing with `gh api graphql`: use `-F` for Int\u002FBoolean (`pr`, `first`), `-f` for strings (`owner`, `repo`, `threadId`, `body`).\n",{"name":5,"description":7},"main","e25eb555e87aa9eeb59b520834f46fd926ad19a3","opencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fauto-dev","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Ftwidxuga","Software developer, data scientist, applications architect and all round computer geek.","2026-10-28 03:46:24",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add twidxuga\u002Fdotfiles --skill auto-dev",{"tool":52,"command":53},"bunx","bunx skills add twidxuga\u002Fdotfiles --skill auto-dev",{"tool":55,"command":56},"pnpm","pnpm dlx skills add twidxuga\u002Fdotfiles --skill auto-dev","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fauto-dev\u002FSKILL.md",true,[],[61,91,105,122,138,150],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":73,"publishedAt":34},"01M6C9Z7VKBN4HAFBDXD67K3E1","terraform-test","Comprehensive guide for writing and running Terraform tests. Use when creating test files (.tftest.hcl), writing test scenarios with run blocks, validating infrastructure behavior with assertions, mocking providers and data sources, testing module outputs and resource configurations, or troubleshooting Terraform test syntax and execution.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-test\u002FSKILL.md",[67,70],{"categoryNo":68,"categoryName":69,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90],"test","terraform","terraform test","testing","writing","infrastructure","run","data","ibm","Providers","execution","troubleshooting","syntax","behavior","guide","use","files",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":98,"publishedAt":34},"01M6C9Z4GWWTXCXAS8NK747K07","terraform-style-guide","Generate Terraform HCL code following HashiCorp's official style conventions and best practices. Use when writing, reviewing, or generating Terraform configurations.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-style-guide\u002FSKILL.md",[97],{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},[99,88,75,100,101,102,103,78,104,89],"terraform style guide","official","generate","code","best practices","hashicorp",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":34},"01M6C9Z1DCAC8YQQ1WS0AHBB14","terraform-stacks","Comprehensive guide for working with HashiCorp Terraform Stacks. Use when creating, modifying, or validating Terraform Stack configurations (.tfcomponent.hcl, .tfdeploy.hcl files), working with stack components and deployments from local modules, public registry, or private registry sources, managing multi-region or multi-environment infrastructure, or troubleshooting Terraform Stacks syntax and structure.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-stacks\u002FSKILL.md",[111],{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},[75,113,114,90,115,116,117,118,79,119,82,104,120,85,86,121,88,89],"terraform stacks","multi-environment","deployments","public","modules","components","registry","stack","environment",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":34},"01M6C9YYAVCNTR81V4HGZWPFW1","terraform-search-import","Discover existing cloud resources using Terraform Search queries and bulk import them into Terraform management. Use when bringing unmanaged infrastructure under Terraform control, auditing cloud resources, or migrating to IaC.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-search-import\u002FSKILL.md",[128],{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,75,89,132,79,133,82,83,134,135,136,137],"terraform search import","search","support","cloud","list","management","version","iac",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":142,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":146,"publishedAt":34},"01M6BZS7EAXHWK32RG213VE65G","run-acceptance-tests","Guide for running acceptance tests for a Terraform provider. Use this when asked to run an acceptance test or to run a test with the prefix `TestAcc`.","MPL-2.0","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-run-acceptance-tests\u002FSKILL.md",[145],{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},[147,148,80,74,75,149,82],"run acceptance tests","acceptance","terraform provider",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":163,"publishedAt":34},"01M6BZS4MJD31PY7M7654ZWQ56","refactor-module","Transform monolithic Terraform configurations into reusable, maintainable modules following HashiCorp's module design principles and community best practices.","https:\u002F\u002Fgithub.com\u002Ftwidxuga\u002Fdotfiles\u002Fblob\u002Fmain\u002Fopencode\u002Fdot-config\u002Fopencode\u002Fskills\u002Fterraform-refactor-module\u002FSKILL.md",[156,159,160],{"categoryNo":157,"categoryName":158,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":71,"categoryName":72,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":161,"categoryName":162,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[164,165,103,75,82,104,166],"refactor module","refactor","design"]