[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71F1GFEPWYTGCGW5V68YCC2":3,"skill-same:01M71F1GFEPWYTGCGW5V68YCC2":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M71F1GFEPWYTGCGW5V68YCC2","plan-build-flow",null,"Ambient change workflow. Classify planning depth, produce reviewable artifacts, stop for authorization, then implement, validate, and close without exposing slash commands. Block PR creation without planning files; archive before merge.","parada1104\u002Fai-specs-cli","parada1104","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F57575053?v=4","01M71EZZV71KAFZKJ47FQ99ZVS","01M71EZZW7JJBY2VAWA5HRD944",0,"MIT","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Fcatalog\u002Frecipes\u002Fplan-build-flow\u002Fskills\u002Fplan-build-flow\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"plan build flow","flow","build","build flow","plan","how","orchestrator","classify","pre-merge","change","tasks","code","workflow","when","files","only","how to","fix","memory","creation","2026-11-10 10:12:30",false,"---\nname: plan-build-flow\ndescription: >\n  Ambient change workflow. Classify planning depth, produce reviewable artifacts,\n  stop for authorization, then implement, validate, and close without exposing\n  slash commands. Block PR creation without planning files; archive before merge.\nlicense: MIT\nmetadata:\n  author: ai-specs\n  version: \"1.0\"\n  scope: runtime\n  auto_invoke:\n    - \"Starting a substantial feature, fix, or refactor that will modify code or artifacts\"\n    - \"User gives a direct implementation task without prior planning artifacts\"\n    - \"User describes a multi-step change that needs planning before implementation\"\n    - \"Continuing implementation after the user authorizes a plan\"\n    - \"Opening a PR or finishing a change: validate artifacts, archive pre-merge, close out\"\n    - \"Deciding how much planning ceremony a change needs (full vs spec+tasks vs tasks-only)\"\n    - \"Deciding how to run planning\u002Fbuild phases when no orchestrator or memory is available\"\n---\n\n# Ambient Plan \u002F Build Flow\n\nThis skill runs invisibly behind normal agent work. There are **no** `\u002Fplan` or\n`\u002Fbuild` slash commands. Classify every substantial request, plan to the\nappropriate depth, stop for authorization, then implement, validate, and close.\n\n## 1. What plan and build mean (internal)\n\n| Phase | Contract |\n|---|---|\n| **Plan** | Classify depth, write the minimum reviewable planning artifacts for that tier, stop and wait for human review\u002Fauthorization. Never implement production code. |\n| **Build** | Implement an authorized plan, validate, ensure planning files are committed on the review branch, open PR only when the artifact gate passes, and run archive-tail **before merge**. |\n\nSpeak to the user in plain language (\"here is the plan\", \"implementing now\") —\nnever expose internal phase names, tier names, or slash verbs.\n\n## 2. Change depth classifier\n\nBefore any production edit, classify the request into exactly one tier. Always\ncompute the signal tier from size and scope, then separately detect an explicit\ndepth request when the user names a tier or a clearly equivalent planning depth.\nRecord the decided tier in `tasks.md` as one standalone lowercase line, for\nexample `Depth: standard`. Downgrade is allowed when new facts appear; upgrade\nwhen scope grows.\n\nIllustrative request phrases include (this is an illustrative set, not an\nexhaustive parser or fixed token whitelist):\n\n- **Full** — \"full SDD\", \"full planning\", \"flujo completo\", or\n  \"planificación completa\".\n- **Standard** — \"standard\", \"spec + tasks\", or \"acotado con spec\".\n- **Light** — \"light\", \"tasks only\", \"solo tasks\", or \"solo tareas\".\n\nThe explicit request is compared with the signal; it never replaces signal\nclassification. If they match, proceed with that shared tier. If they differ,\nthis is a **depth conflict**: do not silently adopt either side. Ask the user\nwhich value wins before writing planning artifacts for the decided tier. The ask\nmust fire in both directions, including when the user requests a deeper tier\nthan the signal suggests; it may recommend a tier, but the user decides.\n\nThe ask is required unless the same user turn already states which side wins,\nsuch as \"use full even if it looks standard\". A same-turn resolution adopts the\nstated value without a second ask and records `Decision source: user`. Merely\nrestating the requested tier or adding scope detail does not resolve the\nconflict. Until the conflict is resolved, do not implement production code or\npretend that a tier is decided. With no explicit request, preserve signal-only\nclassification and proceed without conflict handling.\n\nWhenever a conflict was detected, annotate `tasks.md` with the following labels\non separate lines. Keep the `Depth:` line standalone; never append annotation to\nit:\n\nDepth: full\n\nRequested depth: full\nSignal depth: standard\nDecided depth: full\nDecision source: user\n\n`Decided depth` MUST equal the tier on the `Depth:` line. Use\n`Decision source: user` whenever a human chose, including same-turn resolution.\nWhen there is no conflict, the ordinary standalone `Depth:` line remains\nsufficient and no conflict annotation is required.\nThe annotation labels are prefixed so existing tier inference sees exactly one\n`Depth:` line. If conflict resolution selects a deeper tier than the signal,\ncomplete the entire planning chain required by that decided tier before build\nauthorization counts as satisfied; never relabel a shallower artifact set as a\ndeeper chain.\n\n| Tier | When to use | Planning chain (private) | Minimum artifacts before build |\n|---|---|---|---|\n| **Full** | New capability, architecture or cross-cutting refactor, breaking change, ambiguous scope, or user cannot point to concrete files | explore → proposal → spec → design → tasks | `tasks.md` plus `proposal.md` or `design.md`, and at least one spec delta under `specs\u002F` |\n| **Standard** | Scoped feature or multi-file fix in a known area; intent is clear but needs written requirements | conditional explore → proposal → spec → tasks | `proposal.md`, `tasks.md`, and at least one spec delta under `specs\u002F`; explore when criteria below fire |\n| **Light** | Small bugfix, single-file tweak, typo, or user names exact file(s) and expected edit | proposal → tasks | `proposal.md` and `tasks.md` |\n\n### Standard and Full explore criteria\n\nAt Standard, write `explore.md` before authorization when any of these signals\napply: **multi-approach** (two or more plausible approaches with material\ntrade-offs), **unknown surface** (concrete files cannot yet be named), a docs or\nskill **conflict**, user **uncertainty** about the approach or location, or a\nprior attempt on the same intent that failed or was reverted. Full keeps\n`explore.md` first in its chain.\n\nSkip explore only when concrete paths and expected behavior are known, one\nobvious approach exists in a known area, and no conflict, uncertainty, or retry\nsignal applies. Record the decision in `tasks.md` as one line:\n`Explore: skipped — \u003Cshort reason>`. Missing `explore.md` is a plan-phase gap;\nthe archive and merge guardians never block on it.\n\n### Classifier signals (quick)\n\n| Signal | Tier |\n|---|---|\n| \"Add OAuth\", \"redesign sync\", \"new recipe\", \"breaking v3\" | Full |\n| \"Add field to X\", \"extend handler for Y\", bounded multi-file feature | Standard |\n| \"Fix typo in README\", \"change default in config.toml line 12\", one-line bug | Light |\n| User says \"implement\u002Fbuild\u002Ffix now\" but **no** `openspec\u002Fchanges\u002F\u003Cslug>\u002F` exists yet | Classify first — verbs do **not** skip planning |\n| User says \"go ahead\" and a matching change folder already exists | Build (tier already chosen) |\n\nTrivial read-only questions skip the classifier entirely.\n\n## 3. Full phase compatibility (private)\n\nFull planning runs these logical phases in order:\n\n`explore -> proposal -> spec\u002Fdesign -> tasks`\n\n| Phase | Required inputs | Output artifact | Dependency |\n|---|---|---|---|\n| **explore** | User intent, repository context, and known constraints | `explore.md` | None |\n| **proposal** | `explore.md` plus the original intent | `proposal.md` | After explore |\n| **spec** | `proposal.md` | `specs\u002F**\u002F*.md` | After proposal |\n| **design** | `proposal.md` | `design.md` | After proposal |\n| **tasks** | `proposal.md`, the spec delta, and `design.md` | `tasks.md` | After both spec and design |\n\nSpec and design may run in parallel only after proposal is complete. Tasks waits\nfor both outputs. Each phase owns its output artifact and must leave prior\nartifacts intact.\n\nThe host may advertise a **host-advertised executor** for the **current** logical phase. The\nadvertisement is an optional capability boundary consisting of the phase name,\nthe required input artifacts, and the output artifact it can produce. The\nrecipe remains provider-neutral: it does not select a runtime, model, or\nexternal execution service.\n\nDispatch one phase at a time. If no phase executor is advertised, run the\ncurrent phase inline. An advertised executor that is unavailable may also use\nthe inline fallback. A complete result is accepted only after its output is\npresent and matches the current phase contract.\n\nMalformed, partial, or blocked executor results are a stop condition. Stop and\npreserve all existing artifacts and state, report the blocked phase and result status,\nand wait for a decision. Do not silently rerun the executor, accept an\nincomplete artifact, or skip the phase. Do not skip phases because an earlier\nexecutor was unavailable; inline fallback still completes that phase.\n\nThis phase compatibility applies only to Full. Standard and Light remain\ncollapsed and unchanged; they do not acquire Full's phase dispatch.\n\n## 3.1 Preflight composition\n\nPreflight is one session-level authority for **execution mode**, **artifact\nstore**, **review budget**, **delivery strategy**, and **chain strategy**.\nPlan-build consumes those resolved values and passes them through the flow; it\nmust never recollect or override them, and phase executors cannot replace them.\n\nInteractive mode asks once for unresolved preflight choices, then asks only\nphase-specific product questions. Automatic mode does not duplicate those\nprompts; it records the resolved values and proceeds according to them. The\nartifact store remains a persistence preference, while file-backed readiness and\nthe existing worktree, verify, archive, topology, and PR gates remain\nauthoritative.\n\n## 3.2 Artifact-derived plan presentation\n\nAt each review point, derive a concise technical presentation from the\nartifacts available so far:\n\n| Field | Evidence |\n|---|---|\n| **Intent** | Original request and `proposal.md` |\n| **Scope** | `proposal.md` in-scope and out-of-scope boundaries |\n| **Key decisions** | Proposal, spec, design, and task choices |\n| **Affected areas** | Proposal\u002Fdesign paths and task work units |\n| **Risks** | `explore.md`, design trade-offs, and unresolved constraints |\n| **Open questions** | Questions recorded by the phase that exposed them |\n| **Recommendations \u002F assumptions** | Explicitly labeled conclusions derived from the artifacts |\n\nInteractive mode asks open questions after the phase that exposed them,\nespecially after explore, and then offers **accept**, **adjust**, or **stop**.\nAutomatic mode records recommendations as labeled assumptions or decision notes;\nunresolved product decisions block rather than being silently decided. The final\nplan always requires an explicit **accept**, **adjust**, or **stop**. A\nrecommendation may be accepted or adjusted; it is never treated as an implicit\nproduct decision.\n\n## 3.3 Plan\u002Fbuild lifecycle\n\n- **Plan** runs the chain for the classified tier (Section 2), then **stops**.\n- **Build** runs: apply -> verify -> artifact\u002FPR gates -> archive-tail (pre-merge).\n\n## 4. When to invoke\n\n| Situation | Invoke plan? | Invoke build? |\n|---|---|---|\n| Quick question \u002F read-only exploration | No | No |\n| Substantial or direct implementation request without prior change folder | Yes — classify, plan, stop | No |\n| User approves a pending plan (\"go ahead\", \"implement it\", \"build it\") | No | Yes |\n| User asks to open a PR | No | Yes — but only after artifact gate (Section 7) |\n| Trivial one-line fix explicitly scoped by user | Light tier — plan (`proposal.md` + `tasks.md`) then may build inline | Maybe same turn after micro-plan |\n\nPrefer the project's native plan\u002Freview UX when available (e.g. plan mode) —\nthis skill supplies the artifact trail behind that surface. **All classified\nplanning artifacts MUST be written during plan mode**; production code is never\nmodified while planning. Do not tell the user to \"run \u002Fplan\" or similar —\nrespond to natural requests (\"necesito implementar…\") by classifying and\nplanning.\n\n## 5. Orchestrator degradation policy\n\n- **Orchestrator present** — let it drive phases via sub-agents.\n- **Orchestrator absent** — run equivalent phases inline in one conversation.\n\n## 6. Persistence and readiness\n\nPersistence is separate from readiness. `artifact_store_default` is an\nexternal-session persistence preference rendered into the generated brief; it\nnever proves readiness.\n\n- **Persistent memory present** — Engram MAY mirror planning artifacts, but a\n  memory-only presence never satisfies any readiness check.\n- **Absent** — fall back to file artifacts under `openspec\u002Fchanges\u002F\u003Cslug>\u002F`.\n- **Default** — when Engram is available but no preflight resolved a store,\n  artifacts are written as files under `openspec\u002Fchanges\u002F\u003Cslug>\u002F`, never\n  memory-only.\n\nReadiness is always proven by file-backed artifacts in the canonical\nchange-folder tree — `tasks.md`, tier minimum planning files, and\n`verify-report.md`. The resolved store (`openspec|engram|both`) is never\nconsulted for readiness and never alters any classifier, PR\u002Farchive gate,\nstaged verify gate, or pre-merge guardian decision. Engram MAY mirror artifacts\nbut never replaces them.\n\n## 7. Artifact, PR, and merge gates\n\n### 7.1 Change folder required\n\nEvery non-trivial change MUST have a slug folder at `openspec\u002Fchanges\u002F\u003Cslug>\u002F`\n(excluding `archive\u002F`) before implementation begins on that change. If the user\njumps straight to \"implement X\", create the folder and run the classified plan\nfirst.\n\n### 7.2 PR creation gate (hard stop)\n\nDo **not** run `gh pr create`, `glab mr create`, or equivalent until:\n\n1. The matching `openspec\u002Fchanges\u002F\u003Cslug>\u002F` folder exists on the current branch.\n2. Tier minimum files from Section 2 are present and **committed**.\n3. Implementation and verification for that slug are complete (or the user\n   explicitly accepts opening a draft-only PR for review of planning — still\n   requires the tier minimum files).\n\nIf the gate fails, stop with a plain-language blocker: complete planning for\nthe classified depth, commit the files, then retry PR creation.\n\n### 7.3 Pre-merge archive gate (hard stop)\n\nArchive-tail MUST run on the **review branch** before merge — never defer until\nafter the merge lands on the base branch. Standard and Full changes require a\nconforming `verify-report.md` before this step; Light verification is advisory.\n\nThe canonical evidence block in `verify-report.md` is:\n\n```markdown\n## Verify evidence\n- Verdict: PASS\n- Command: `.\u002Ftests\u002Fvalidate.sh`\n- Exit: 0\n- Date: 2026-08-07\n- Commit: 604a441\n- ready_for_archive: true\n\n## Success-criteria mapping\n- Criterion 1: PASS — concise evidence for the first criterion\n- Criterion 2: PASS — concise evidence for the second criterion\n```\n\nStandard requires the dedicated report with a non-failing verdict, command,\nexit `0`, date, and 7–40 character commit SHA. Full additionally requires\nstrict `PASS` and `ready_for_archive: true`, plus exactly one `Criterion N: PASS`\nmapping row for every top-level bullet under `## Success Criteria` in the\nauthoritative source: `proposal.md` when present, otherwise `design.md`.\nMissing or empty criteria in an existing `proposal.md` block Full; the guardian\ndoes not fall back to `design.md`. Duplicate `## Success Criteria` headings in\nthe authoritative source are also rejected. Criterion numbers are 1-based and\ncontiguous; duplicate mapping rows, missing numbers, unknown numbers, and\nnon-PASS mapping statuses block Full. The guardian enforces this deterministic\nmapping at both gates. Light may warn when evidence is absent but MUST NOT block\nsolely for it.\n\nEnforce the evidence gate twice: before archive-tail and again in the guardian\nbefore merge. There is no bypass flag. Labels may use `Status`\u002F`Overall`,\n`Exit code`\u002F`Exit status`, and `SHA`\u002F`Revision` synonyms.\nVerification enforcement is advisory for Light, blocking for Standard, and\nrequired for Full at both stages.\n\nSequence on the review branch:\n\n1. Implement and verify.\n2. Commit and push implementation **and** planning files.\n3. Open a PR (artifact gate satisfied).\n4. Promote canonical specs. Compose every delta under\n   `openspec\u002Fchanges\u002F\u003Cslug>\u002Fspecs\u002F\u003Cdomain>\u002Fspec.md` into\n   `openspec\u002Fspecs\u002F\u003Cdomain>\u002Fspec.md` with the promotion helper and commit the\n   result on the review branch:\n\n```bash\npython3 \"${AI_SPECS_HOME:-$HOME\u002F.ai-specs}\u002Flib\u002F_internal\u002Fspec_promotion.py\" \\\n  \u003Cslug> --root \u003Cplanning-root>\n```\n\n   Composition follows the archive contract: `## ADDED Requirements` appends,\n   `## MODIFIED Requirements` replaces the full canonical block with the exact\n   same requirement name, unrelated canonical requirements and sections survive,\n   a missing canonical domain is created from the delta, and a rerun after an\n   interruption is a no-op. A colliding `ADDED`, a `MODIFIED` target that does\n   not exist, or an unsupported `## RENAMED Requirements` delta blocks without\n   writing. A destructive `## REMOVED Requirements` delta blocks unless the\n   removal was explicitly approved, in which case re-run with `--allow-removed`.\n   Only the promoter writes canonical specs; the guardian only validates them\n   and never mutates `openspec\u002Fspecs\u002F`. Light and changes with no `specs\u002F`\n   deltas have nothing to promote.\n\n5. Before moving the change folder, run the executable pre-archive gate and stop\nif it exits nonzero. `--root` is the resolved planning root from the request\ncontext — required, never the process cwd; a subrepo request passes the proven\nsuperproject root:\n\n```bash\npython3 \"${AI_SPECS_HOME:-$HOME\u002F.ai-specs}\u002Flib\u002F_internal\u002Fpremerge_guardian.py\" \\\n  \u003Cslug> --root \u003Cplanning-root> --stage pre-archive\n```\n\nThe command must pass for Standard and Full; do not archive or continue when it\nreports missing or failed evidence, or an unpromoted or unresolved delta. Light\nremains advisory. This is the pre-archive check; the pre-merge guardian below\nremains required after archive.\n\n6. After the pre-archive gate passes, run archive-tail — move\n   `openspec\u002Fchanges\u002F\u003Cslug>\u002F` → `openspec\u002Fchanges\u002Farchive\u002FYYYY-MM-DD-\u003Cslug>\u002F`,\n   using a valid ISO calendar date, then commit and push to the review branch.\n   The exact undated `openspec\u002Fchanges\u002Farchive\u002F\u003Cslug>\u002F` form remains readable\n   only as a legacy fallback for historical archives; new archives use the\n   dated provider form. The guardian fails closed when multiple dated\n   candidates, dated-plus-undated candidates, invalid dates, or near-match\n   names are present.\n7. Run the pre-merge guardian; merge only after explicit user approval.\n\n### 7.4 Pre-merge merge guardian (hard stop)\n\nBefore `gh pr merge` \u002F `glab mr merge` \u002F Bitbucket merge (or equivalent), verify\nthe archive is complete. Prefer the shared helper when available. `--root` is\nthe propagated planning root from the request context (required, never the\nprocess cwd): for a subrepo-context change whose planning root is the proven\nsuperproject, pass `\u003Csuper>\u002Fopenspec`'s parent — the superproject root — so the\nguardian inspects the canonical tree and never a subrepo-local change folder.\n\n```bash\npython3 \"${AI_SPECS_HOME:-$HOME\u002F.ai-specs}\u002Flib\u002F_internal\u002Fpremerge_guardian.py\" \\\n  \u003Cslug> --root \u003Cplanning-root>\n# optional: --tier light|standard|full\n```\n\nThe helper ships with the CLI install under `~\u002F.ai-specs` (not copied into\nconsumer projects).\n\nHard blockers (do **not** merge):\n\n1. `openspec\u002Fchanges\u002F\u003Cslug>\u002F` still exists (active, not archived).\n2. No exact valid archive candidate exists at\n   `openspec\u002Fchanges\u002Farchive\u002FYYYY-MM-DD-\u003Cslug>\u002F`; the exact undated\n   `openspec\u002Fchanges\u002Farchive\u002F\u003Cslug>\u002F` form is accepted only as a legacy\n   fallback when no dated candidate exists.\n3. Archived folder lacks the tier minimum files (Light: `proposal.md` +\n   `tasks.md`; Standard: `proposal.md` + `tasks.md` + `specs\u002F**\u002F*.md`; Full:\n   `tasks.md` + `proposal.md` or `design.md` + `specs\u002F**\u002F*.md`).\n4. Standard lacks a conforming dedicated `verify-report.md`.\n5. Full lacks a conforming dedicated `verify-report.md` with strict `PASS` and\n   `ready_for_archive: true`.\n6. A Standard or Full delta under `specs\u002F\u003Cdomain>\u002Fspec.md` is not promoted into\n   `openspec\u002Fspecs\u002F\u003Cdomain>\u002Fspec.md`, or cannot be composed (collision, missing\n   `MODIFIED` target, unsupported `RENAMED`, destructive `REMOVED` without\n   explicit approval). Run the promoter first; the guardian only validates and\n   never writes canonical specs or tracker state.\n\nThe promotion check is tier-scoped: Light changes and changes with no `specs\u002F`\ndeltas are never blocked by it.\n\nTracker item closure (`tracker-card-gate.sh --root \u003Croot> --checkpoint\narchive-close`) is a separate Tracker-domain checkpoint: it is not this OpenSpec\narchive, it never moves the change folder, and this guardian never grades or\nwrites tracker state.\n\n### In-flight plans and stale PRs\n\nPlans already in flight when these minima ship are grandfathered only through\ntheir current work: add missing `proposal.md` or verify evidence before PR or\narchive, without restarting the plan. Historical archives are never rewritten;\na stale PR is handled by its owning agent when that change resumes.\nMissing `explore.md` is never a guardian blocker. The guardian evaluates only\nthe slug under check; older archived changes and stale PRs are not rewritten.\n\nPost-merge archive is **rejected** — if merge already happened, do not treat the\nmerged base branch as the archive boundary.\n\n## 8. Change-slug derivation\n\n- On plan, derive a kebab-case slug from intent.\n- On build, resolve slug from outstanding change folders under\n  `openspec\u002Fchanges\u002F` (excluding `archive\u002F`).\n- If multiple outstanding plans exist, ask which to build.\n\n## 9. Worktree deference\n\n- Plan artifacts may be written before a worktree exists when small.\n- Build **must** use a dedicated worktree when `worktree-flow` is enabled.\n\n## 10. Cross-repository planning boundaries\n\n- For a recognized initialized submodule linked worktree in the supported shared\n  layout, derive the planning root from repository **topology** and use the\n  containing **superproject** as the central source of truth.\n- The canonical `openspec\u002Fchanges\u002F\u003Cslug>\u002F` tree belongs to that superproject.\n  Central active-plan lookup and planning-artifact writes are allowed only under\n  `openspec\u002Fchanges\u002F**`, including its archive subtree; this is not a bypass for\n  superproject production paths.\n- **Standalone** repositories and non-submodule worktrees retain nearest-root\n  behavior. If the relationship cannot be established, resolution is **fail-safe**\n  and falls back to that nearest repository rather than guessing a parent.\n- Keep one canonical plan: no duplication, synchronization, or orchestration\n  across subrepositories, and no worktree, branch, or pull-request side effects.\n\n## 11. Archive-tail graceful no-op\n\nArchive-tail runs at step 6 of Section 7.3 (before merge):\n\n- **Change-folder close** — move `openspec\u002Fchanges\u002F\u003Cslug>\u002F` →\n  `openspec\u002Fchanges\u002Farchive\u002FYYYY-MM-DD-\u003Cslug>\u002F` using a valid ISO calendar date\n  (required for new archives). The exact undated\n  `openspec\u002Fchanges\u002Farchive\u002F\u003Cslug>\u002F` form is a legacy fallback only.\n- **Vault summary** — no-op with note if canonical store absent.\n- **Tracker comment** — no-op with note if tracker absent.\n","# Ambient Plan \u002F Build Flow\n\nThis skill runs invisibly behind normal agent work. There are **no** `\u002Fplan` or\n`\u002Fbuild` slash commands. Classify every substantial request, plan to the\nappropriate depth, stop for authorization, then implement, validate, and close.\n\n## 1. What plan and build mean (internal)\n\n| Phase | Contract |\n|---|---|\n| **Plan** | Classify depth, write the minimum reviewable planning artifacts for that tier, stop and wait for human review\u002Fauthorization. Never implement production code. |\n| **Build** | Implement an authorized plan, validate, ensure planning files are committed on the review branch, open PR only when the artifact gate passes, and run archive-tail **before merge**. |\n\nSpeak to the user in plain language (\"here is the plan\", \"implementing now\") —\nnever expose internal phase names, tier names, or slash verbs.\n\n## 2. Change depth classifier\n\nBefore any production edit, classify the request into exactly one tier. Always\ncompute the signal tier from size and scope, then separately detect an explicit\ndepth request when the user names a tier or a clearly equivalent planning depth.\nRecord the decided tier in `tasks.md` as one standalone lowercase line, for\nexample `Depth: standard`. Downgrade is allowed when new facts appear; upgrade\nwhen scope grows.\n\nIllustrative request phrases include (this is an illustrative set, not an\nexhaustive parser or fixed token whitelist):\n\n- **Full** — \"full SDD\", \"full planning\", \"flujo completo\", or\n  \"planificación completa\".\n- **Standard** — \"standard\", \"spec + tasks\", or \"acotado con spec\".\n- **Light** — \"light\", \"tasks only\", \"solo tasks\", or \"solo tareas\".\n\nThe explicit request is compared with the signal; it never replaces signal\nclassification. If they match, proceed with that shared tier. If they differ,\nthis is a **depth conflict**: do not silently adopt either side. Ask the user\nwhich value wins before writing planning artifacts for the decided tier. The ask\nmust fire in both directions, including when the user requests a deeper tier\nthan the signal suggests; it may recommend a tier, but the user decides.\n\nThe ask is required unless the same user turn already states which side wins,\nsuch as \"use full even if it looks standard\". A same-turn resolution adopts the\nstated value without a second ask and records `Decision source: user`. Merely\nrestating the requested tier or adding scope detail does not resolve the\nconflict. Until the conflict is resolved, do not implement production code or\npretend that a tier is decided. With no explicit request, preserve signal-only\nclassification and proceed without conflict handling.\n\nWhenever a conflict was detected, annotate `tasks.md` with the following labels\non separate lines. Keep the `Depth:` line standalone; never append annotation to\nit:\n\nDepth: full\n\nRequested depth: full\nSignal depth: standard\nDecided depth: full\nDecision source: user\n\n`Decided depth` MUST equal the tier on the `Depth:` line. Use\n`Decision source: user` whenever a human chose, including same-turn resolution.\nWhen there is no conflict, the ordinary standalone `Depth:` line remains\nsufficient and no conflict annotation is required.\nThe annotation labels are prefixed so existing tier inference sees exactly one\n`Depth:` line. If conflict resolution selects a deeper tier than the signal,\ncomplete the entire planning chain required by that decided tier before build\nauthorization counts as satisfied; never relabel a shallower artifact set as a\ndeeper chain.\n\n| Tier | When to use | Planning chain (private) | Minimum artifacts before build |\n|---|---|---|---|\n| **Full** | New capability, architecture or cross-cutting refactor, breaking change, ambiguous scope, or user cannot point to concrete files | explore → proposal → spec → design → tasks | `tasks.md` plus `proposal.md` or `design.md`, and at least one spec delta under `specs\u002F` |\n| **Standard** | Scoped feature or multi-file fix in a known area; intent is clear but needs written requirements | conditional explore → proposal → spec → tasks | `proposal.md`, `tasks.md`, and at least one spec delta under `specs\u002F`; explore when criteria below fire |\n| **Light** | Small bugfix, single-file tweak, typo, or user names exact file(s) and expected edit | proposal → tasks | `proposal.md` and `tasks.md` |\n\n### Standard and Full explore criteria\n\nAt Standard, write `explore.md` before authorization when any of these signals\napply: **multi-approach** (two or more plausible approaches with material\ntrade-offs), **unknown surface** (concrete files cannot yet be named), a docs or\nskill **conflict**, user **uncertainty** about the approach or location, or a\nprior attempt on the same intent that failed or was reverted. Full keeps\n`explore.md` first in its chain.\n\nSkip explore only when concrete paths and expected behavior are known, one\nobvious approach exists in a known area, and no conflict, uncertainty, or retry\nsignal applies. Record the decision in `tasks.md` as one line:\n`Explore: skipped — \u003Cshort reason>`. Missing `explore.md` is a plan-phase gap;\nthe archive and merge guardians never block on it.\n\n### Classifier signals (quick)\n\n| Signal | Tier |\n|---|---|\n| \"Add OAuth\", \"redesign sync\", \"new recipe\", \"breaking v3\" | Full |\n| \"Add field to X\", \"extend handler for Y\", bounded multi-file feature | Standard |\n| \"Fix typo in README\", \"change default in config.toml line 12\", one-line bug | Light |\n| User says \"implement\u002Fbuild\u002Ffix now\" but **no** `openspec\u002Fchanges\u002F\u003Cslug>\u002F` exists yet | Classify first — verbs do **not** skip planning |\n| User says \"go ahead\" and a matching change folder already exists | Build (tier already chosen) |\n\nTrivial read-only questions skip the classifier entirely.\n\n## 3. Full phase compatibility (private)\n\nFull planning runs these logical phases in order:\n\n`explore -> proposal -> spec\u002Fdesign -> tasks`\n\n| Phase | Required inputs | Output artifact | Dependency |\n|---|---|---|---|\n| **explore** | User intent, repository context, and known constraints | `explore.md` | None |\n| **proposal** | `explore.md` plus the original intent | `proposal.md` | After explore |\n| **spec** | `proposal.md` | `specs\u002F**\u002F*.md` | After proposal |\n| **design** | `proposal.md` | `design.md` | After proposal |\n| **tasks** | `proposal.md`, the spec delta, and `design.md` | `tasks.md` | After both spec and design |\n\nSpec and design may run in parallel only after proposal is complete. Tasks waits\nfor both outputs. Each phase owns its output artifact and must leave prior\nartifacts intact.\n\nThe host may advertise a **host-advertised executor** for the **current** logical phase. The\nadvertisement is an optional capability boundary consisting of the phase name,\nthe required input artifacts, and the output artifact it can produce. The\nrecipe remains provider-neutral: it does not select a runtime, model, or\nexternal execution service.\n\nDispatch one phase at a time. If no phase executor is advertised, run the\ncurrent phase inline. An advertised executor that is unavailable may also use\nthe inline fallback. A complete result is accepted only after its output is\npresent and matches the current phase contract.\n\nMalformed, partial, or blocked executor results are a stop condition. Stop and\npreserve all existing artifacts and state, report the blocked phase and result status,\nand wait for a decision. Do not silently rerun the executor, accept an\nincomplete artifact, or skip the phase. Do not skip phases because an earlier\nexecutor was unavailable; inline fallback still completes that phase.\n\nThis phase compatibility applies only to Full. Standard and Light remain\ncollapsed and unchanged; they do not acquire Full's phase dispatch.\n\n## 3.1 Preflight composition\n\nPreflight is one session-level authority for **execution mode**, **artifact\nstore**, **review budget**, **delivery strategy**, and **chain strategy**.\nPlan-build consumes those resolved values and passes them through the flow; it\nmust never recollect or override them, and phase executors cannot replace them.\n\nInteractive mode asks once for unresolved preflight choices, then asks only\nphase-specific product questions. Automatic mode does not duplicate those\nprompts; it records the resolved values and proceeds according to them. The\nartifact store remains a persistence preference, while file-backed readiness and\nthe existing worktree, verify, archive, topology, and PR gates remain\nauthoritative.\n\n## 3.2 Artifact-derived plan presentation\n\nAt each review point, derive a concise technical presentation from the\nartifacts available so far:\n\n| Field | Evidence |\n|---|---|\n| **Intent** | Original request and `proposal.md` |\n| **Scope** | `proposal.md` in-scope and out-of-scope boundaries |\n| **Key decisions** | Proposal, spec, design, and task choices |\n| **Affected areas** | Proposal\u002Fdesign paths and task work units |\n| **Risks** | `explore.md`, design trade-offs, and unresolved constraints |\n| **Open questions** | Questions recorded by the phase that exposed them |\n| **Recommendations \u002F assumptions** | Explicitly labeled conclusions derived from the artifacts |\n\nInteractive mode asks open questions after the phase that exposed them,\nespecially after explore, and then offers **accept**, **adjust**, or **stop**.\nAutomatic mode records recommendations as labeled assumptions or decision notes;\nunresolved product decisions block rather than being silently decided. The final\nplan always requires an explicit **accept**, **adjust**, or **stop**. A\nrecommendation may be accepted or adjusted; it is never treated as an implicit\nproduct decision.\n\n## 3.3 Plan\u002Fbuild lifecycle\n\n- **Plan** runs the chain for the classified tier (Section 2), then **stops**.\n- **Build** runs: apply -> verify -> artifact\u002FPR gates -> archive-tail (pre-merge).\n\n## 4. When to invoke\n\n| Situation | Invoke plan? | Invoke build? |\n|---|---|---|\n| Quick question \u002F read-only exploration | No | No |\n| Substantial or direct implementation request without prior change folder | Yes — classify, plan, stop | No |\n| User approves a pending plan (\"go ahead\", \"implement it\", \"build it\") | No | Yes |\n| User asks to open a PR | No | Yes — but only after artifact gate (Section 7) |\n| Trivial one-line fix explicitly scoped by user | Light tier — plan (`proposal.md` + `tasks.md`) then may build inline | Maybe same turn after micro-plan |\n\nPrefer the project's native plan\u002Freview UX when available (e.g. plan mode) —\nthis skill supplies the artifact trail behind that surface. **All classified\nplanning artifacts MUST be written during plan mode**; production code is never\nmodified while planning. Do not tell the user to \"run \u002Fplan\" or similar —\nrespond to natural requests (\"necesito implementar…\") by classifying and\nplanning.\n\n## 5. Orchestrator degradation policy\n\n- **Orchestrator present** — let it drive phases via sub-agents.\n- **Orchestrator absent** — run equivalent phases inline in one conversation.\n\n## 6. Persistence and readiness\n\nPersistence is separate from readiness. `artifact_store_default` is an\nexternal-session persistence preference rendered into the generated brief; it\nnever proves readiness.\n\n- **Persistent memory present** — Engram MAY mirror planning artifacts, but a\n  memory-only presence never satisfies any readiness check.\n- **Absent** — fall back to file artifacts under `openspec\u002Fchanges\u002F\u003Cslug>\u002F`.\n- **Default** — when Engram is available but no preflight resolved a store,\n  artifacts are written as files under `openspec\u002Fchanges\u002F\u003Cslug>\u002F`, never\n  memory-only.\n\nReadiness is always proven by file-backed artifacts in the canonical\nchange-folder tree — `tasks.md`, tier minimum planning files, and\n`verify-report.md`. The resolved store (`openspec|engram|both`) is never\nconsulted for readiness and never alters any classifier, PR\u002Farchive gate,\nstaged verify gate, or pre-merge guardian decision. Engram MAY mirror artifacts\nbut never replaces them.\n\n## 7. Artifact, PR, and merge gates\n\n### 7.1 Change folder required\n\nEvery non-trivial change MUST have a slug folder at `openspec\u002Fchanges\u002F\u003Cslug>\u002F`\n(excluding `archive\u002F`) before implementation begins on that change. If the user\njumps straight to \"implement X\", create the folder and run the classified plan\nfirst.\n\n### 7.2 PR creation gate (hard stop)\n\nDo **not** run `gh pr create`, `glab mr create`, or equivalent until:\n\n1. The matching `openspec\u002Fchanges\u002F\u003Cslug>\u002F` folder exists on the current branch.\n2. Tier minimum files from Section 2 are present and **committed**.\n3. Implementation and verification for that slug are complete (or the user\n   explicitly accepts opening a draft-only PR for review of planning — still\n   requires the tier minimum files).\n\nIf the gate fails, stop with a plain-language blocker: complete planning for\nthe classified depth, commit the files, then retry PR creation.\n\n### 7.3 Pre-merge archive gate (hard stop)\n\nArchive-tail MUST run on the **review branch** before merge — never defer until\nafter the merge lands on the base branch. Standard and Full changes require a\nconforming `verify-report.md` before this step; Light verification is advisory.\n\nThe canonical evidence block in `verify-report.md` is:\n\n```markdown\n## Verify evidence\n- Verdict: PASS\n- Command: `.\u002Ftests\u002Fvalidate.sh`\n- Exit: 0\n- Date: 2026-08-07\n- Commit: 604a441\n- ready_for_archive: true\n\n## Success-criteria mapping\n- Criterion 1: PASS — concise evidence for the first criterion\n- Criterion 2: PASS — concise evidence for the second criterion\n```\n\nStandard requires the dedicated report with a non-failing verdict, command,\nexit `0`, date, and 7–40 character commit SHA. Full additionally requires\nstrict `PASS` and `ready_for_archive: true`, plus exactly one `Criterion N: PASS`\nmapping row for every top-level bullet under `## Success Criteria` in the\nauthoritative source: `proposal.md` when present, otherwise `design.md`.\nMissing or empty criteria in an existing `proposal.md` block Full; the guardian\ndoes not fall back to `design.md`. Duplicate `## Success Criteria` headings in\nthe authoritative source are also rejected. Criterion numbers are 1-based and\ncontiguous; duplicate mapping rows, missing numbers, unknown numbers, and\nnon-PASS mapping statuses block Full. The guardian enforces this deterministic\nmapping at both gates. Light may warn when evidence is absent but MUST NOT block\nsolely for it.\n\nEnforce the evidence gate twice: before archive-tail and again in the guardian\nbefore merge. There is no bypass flag. Labels may use `Status`\u002F`Overall`,\n`Exit code`\u002F`Exit status`, and `SHA`\u002F`Revision` synonyms.\nVerification enforcement is advisory for Light, blocking for Standard, and\nrequired for Full at both stages.\n\nSequence on the review branch:\n\n1. Implement and verify.\n2. Commit and push implementation **and** planning files.\n3. Open a PR (artifact gate satisfied).\n4. Promote canonical specs. Compose every delta under\n   `openspec\u002Fchanges\u002F\u003Cslug>\u002Fspecs\u002F\u003Cdomain>\u002Fspec.md` into\n   `openspec\u002Fspecs\u002F\u003Cdomain>\u002Fspec.md` with the promotion helper and commit the\n   result on the review branch:\n\n```bash\npython3 \"${AI_SPECS_HOME:-$HOME\u002F.ai-specs}\u002Flib\u002F_internal\u002Fspec_promotion.py\" \\\n  \u003Cslug> --root \u003Cplanning-root>\n```\n\n   Composition follows the archive contract: `## ADDED Requirements` appends,\n   `## MODIFIED Requirements` replaces the full canonical block with the exact\n   same requirement name, unrelated canonical requirements and sections survive,\n   a missing canonical domain is created from the delta, and a rerun after an\n   interruption is a no-op. A colliding `ADDED`, a `MODIFIED` target that does\n   not exist, or an unsupported `## RENAMED Requirements` delta blocks without\n   writing. A destructive `## REMOVED Requirements` delta blocks unless the\n   removal was explicitly approved, in which case re-run with `--allow-removed`.\n   Only the promoter writes canonical specs; the guardian only validates them\n   and never mutates `openspec\u002Fspecs\u002F`. Light and changes with no `specs\u002F`\n   deltas have nothing to promote.\n\n5. Before moving the change folder, run the executable pre-archive gate and stop\nif it exits nonzero. `--root` is the resolved planning root from the request\ncontext — required, never the process cwd; a subrepo request passes the proven\nsuperproject root:\n\n```bash\npython3 \"${AI_SPECS_HOME:-$HOME\u002F.ai-specs}\u002Flib\u002F_internal\u002Fpremerge_guardian.py\" \\\n  \u003Cslug> --root \u003Cplanning-root> --stage pre-archive\n```\n\nThe command must pass for Standard and Full; do not archive or continue when it\nreports missing or failed evidence, or an unpromoted or unresolved delta. Light\nremains advisory. This is the pre-archive check; the pre-merge guardian below\nremains required after archive.\n\n6. After the pre-archive gate passes, run archive-tail — move\n   `openspec\u002Fchanges\u002F\u003Cslug>\u002F` → `openspec\u002Fchanges\u002Farchive\u002FYYYY-MM-DD-\u003Cslug>\u002F`,\n   using a valid ISO calendar date, then commit and push to the review branch.\n   The exact undated `openspec\u002Fchanges\u002Farchive\u002F\u003Cslug>\u002F` form remains readable\n   only as a legacy fallback for historical archives; new archives use the\n   dated provider form. The guardian fails closed when multiple dated\n   candidates, dated-plus-undated candidates, invalid dates, or near-match\n   names are present.\n7. Run the pre-merge guardian; merge only after explicit user approval.\n\n### 7.4 Pre-merge merge guardian (hard stop)\n\nBefore `gh pr merge` \u002F `glab mr merge` \u002F Bitbucket merge (or equivalent), verify\nthe archive is complete. Prefer the shared helper when available. `--root` is\nthe propagated planning root from the request context (required, never the\nprocess cwd): for a subrepo-context change whose planning root is the proven\nsuperproject, pass `\u003Csuper>\u002Fopenspec`'s parent — the superproject root — so the\nguardian inspects the canonical tree and never a subrepo-local change folder.\n\n```bash\npython3 \"${AI_SPECS_HOME:-$HOME\u002F.ai-specs}\u002Flib\u002F_internal\u002Fpremerge_guardian.py\" \\\n  \u003Cslug> --root \u003Cplanning-root>\n# optional: --tier light|standard|full\n```\n\nThe helper ships with the CLI install under `~\u002F.ai-specs` (not copied into\nconsumer projects).\n\nHard blockers (do **not** merge):\n\n1. `openspec\u002Fchanges\u002F\u003Cslug>\u002F` still exists (active, not archived).\n2. No exact valid archive candidate exists at\n   `openspec\u002Fchanges\u002Farchive\u002FYYYY-MM-DD-\u003Cslug>\u002F`; the exact undated\n   `openspec\u002Fchanges\u002Farchive\u002F\u003Cslug>\u002F` form is accepted only as a legacy\n   fallback when no dated candidate exists.\n3. Archived folder lacks the tier minimum files (Light: `proposal.md` +\n   `tasks.md`; Standard: `proposal.md` + `tasks.md` + `specs\u002F**\u002F*.md`; Full:\n   `tasks.md` + `proposal.md` or `design.md` + `specs\u002F**\u002F*.md`).\n4. Standard lacks a conforming dedicated `verify-report.md`.\n5. Full lacks a conforming dedicated `verify-report.md` with strict `PASS` and\n   `ready_for_archive: true`.\n6. A Standard or Full delta under `specs\u002F\u003Cdomain>\u002Fspec.md` is not promoted into\n   `openspec\u002Fspecs\u002F\u003Cdomain>\u002Fspec.md`, or cannot be composed (collision, missing\n   `MODIFIED` target, unsupported `RENAMED`, destructive `REMOVED` without\n   explicit approval). Run the promoter first; the guardian only validates and\n   never writes canonical specs or tracker state.\n\nThe promotion check is tier-scoped: Light changes and changes with no `specs\u002F`\ndeltas are never blocked by it.\n\nTracker item closure (`tracker-card-gate.sh --root \u003Croot> --checkpoint\narchive-close`) is a separate Tracker-domain checkpoint: it is not this OpenSpec\narchive, it never moves the change folder, and this guardian never grades or\nwrites tracker state.\n\n### In-flight plans and stale PRs\n\nPlans already in flight when these minima ship are grandfathered only through\ntheir current work: add missing `proposal.md` or verify evidence before PR or\narchive, without restarting the plan. Historical archives are never rewritten;\na stale PR is handled by its owning agent when that change resumes.\nMissing `explore.md` is never a guardian blocker. The guardian evaluates only\nthe slug under check; older archived changes and stale PRs are not rewritten.\n\nPost-merge archive is **rejected** — if merge already happened, do not treat the\nmerged base branch as the archive boundary.\n\n## 8. Change-slug derivation\n\n- On plan, derive a kebab-case slug from intent.\n- On build, resolve slug from outstanding change folders under\n  `openspec\u002Fchanges\u002F` (excluding `archive\u002F`).\n- If multiple outstanding plans exist, ask which to build.\n\n## 9. Worktree deference\n\n- Plan artifacts may be written before a worktree exists when small.\n- Build **must** use a dedicated worktree when `worktree-flow` is enabled.\n\n## 10. Cross-repository planning boundaries\n\n- For a recognized initialized submodule linked worktree in the supported shared\n  layout, derive the planning root from repository **topology** and use the\n  containing **superproject** as the central source of truth.\n- The canonical `openspec\u002Fchanges\u002F\u003Cslug>\u002F` tree belongs to that superproject.\n  Central active-plan lookup and planning-artifact writes are allowed only under\n  `openspec\u002Fchanges\u002F**`, including its archive subtree; this is not a bypass for\n  superproject production paths.\n- **Standalone** repositories and non-submodule worktrees retain nearest-root\n  behavior. If the relationship cannot be established, resolution is **fail-safe**\n  and falls back to that nearest repository rather than guessing a parent.\n- Keep one canonical plan: no duplication, synchronization, or orchestration\n  across subrepositories, and no worktree, branch, or pull-request side effects.\n\n## 11. Archive-tail graceful no-op\n\nArchive-tail runs at step 6 of Section 7.3 (before merge):\n\n- **Change-folder close** — move `openspec\u002Fchanges\u002F\u003Cslug>\u002F` →\n  `openspec\u002Fchanges\u002Farchive\u002FYYYY-MM-DD-\u003Cslug>\u002F` using a valid ISO calendar date\n  (required for new archives). The exact undated\n  `openspec\u002Fchanges\u002Farchive\u002F\u003Cslug>\u002F` form is a legacy fallback only.\n- **Vault summary** — no-op with note if canonical store absent.\n- **Tracker comment** — no-op with note if tracker absent.\n",{"name":5,"license":14,"metadata":43,"description":55},{"scope":44,"author":45,"version":46,"auto_invoke":47},"runtime","ai-specs","1.0",[48,49,50,51,52,53,54],"Starting a substantial feature, fix, or refactor that will modify code or artifacts","User gives a direct implementation task without prior planning artifacts","User describes a multi-step change that needs planning before implementation","Continuing implementation after the user authorizes a plan","Opening a PR or finishing a change: validate artifacts, archive pre-merge, close out","Deciding how much planning ceremony a change needs (full vs spec+tasks vs tasks-only)","Deciding how to run planning\u002Fbuild phases when no orchestrator or memory is available","Ambient change workflow. Classify planning depth, produce reviewable artifacts, stop for authorization, then implement, validate, and close without exposing slash commands. Block PR creation without planning files; archive before merge.\n","main","c092fc1f51280350a4434827e2f6d6d99e3431ca","catalog\u002Frecipes\u002Fplan-build-flow\u002Fskills\u002Fplan-build-flow",2,"https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli","https:\u002F\u002Fgithub.com\u002Fparada1104","2026-11-14 03:51:03",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add parada1104\u002Fai-specs-cli --skill plan-build-flow",{"tool":69,"command":70},"bunx","bunx skills add parada1104\u002Fai-specs-cli --skill plan-build-flow",{"tool":72,"command":73},"pnpm","pnpm dlx skills add parada1104\u002Fai-specs-cli --skill plan-build-flow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Fcatalog\u002Frecipes\u002Fplan-build-flow\u002Fskills\u002Fplan-build-flow\u002FSKILL.md",true,[],[78,100,114,123,132,145],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":92,"publishedAt":38},"01M71F2TF9TS9DNCJ68M7C3B5S","test-skill","Test skill for fixture purposes.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Frecipes\u002Ftest-fixture\u002Fskills\u002Ftest-skill\u002FSKILL.md",[84,89],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":90,"categoryName":91,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000023","Skill与智能体开发",[93,94,95,96,97,98,99],"Test Skill","test","for","root","fixtures","fixture","testing",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":109,"publishedAt":38},"01M71F2RTH94ZB7XEAW4P6ZG0D","obsidian-markdown","Fixture skill for obsidian-markdown.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fobsidian-markdown\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000002","文档处理",[110,111,112,95,98,113],"markdown","obsidian markdown","obsidian","fixture skill",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":38},"01M71F2R20CPTJXD9F7DP4JPP6","obsidian-cli","Fixture skill for obsidian-cli.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fobsidian-cli\u002FSKILL.md",[],[121,112,122,95,98,113],"obsidian cli","cli",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":38},"01M71F2PCH4NWVTT1J57SHJX33","obsidian-bases","Fixture skill for obsidian-bases.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fobsidian-bases\u002FSKILL.md",[],[130,131,112,95,98,113],"bases","obsidian bases",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":141,"publishedAt":38},"01M71F2MSS6EVFEYVYAA1KBYCC","json-canvas","Fixture skill for json-canvas.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fjson-canvas\u002FSKILL.md",[138],{"categoryNo":139,"categoryName":140,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000015","视觉设计",[142,143,144,113,98,95],"json","json canvas","canvas",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":38},"01M71F2KY5QVNEN1Q3REFB0MQZ","defuddle","Fixture skill for defuddle.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fdefuddle\u002FSKILL.md",[],[147,113,98,95]]