[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DADXH5RFVRDGQM7Y3WVQYC":3,"skill-same:01M6DADXH5RFVRDGQM7Y3WVQYC":57},{"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":18,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":41,"ownerDescription":6,"updatedAt":42,"install":43,"resources":56},"01M6DADXH5RFVRDGQM7Y3WVQYC","architect-propose-plan",null,"Create PROPOSAL-N task with full technical plan","dayvidpham\u002Fpasture","dayvidpham","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F22456875?v=4","01M6CHR0F6J2M4QEHFR85XRNSR","David Huu Pham","01M6DA7X1WB0MK7TTV46SRZK75",1,"MIT","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Finternal\u002Ftarget\u002Fclaudecode\u002Fassets\u002Fpasture-skills\u002Fskills\u002Farchitect-propose-plan\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29],"architect","plan","architect propose plan","create","technical","task","full","proposal","create proposal","with","technical plan","2026-11-10 10:12:30",false,"---\nname: architect-propose-plan\ndescription: Create PROPOSAL-N task with full technical plan\n---\n\n# Architect: Propose Plan\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Command:** `pasture:architect:propose-plan` — Create PROPOSAL-N task with full technical plan\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-3-proposal-n)** \u003C- Phase 3\n\n**[arch-propose-bdd-format]**\n- Given: feature request\n- When: proposing\n- Then: use BDD Given\u002FWhen\u002FThen format with acceptance criteria\n- Should not: write vague requirements\n\n**[arch-propose-checklist-required]**\n- Given: plan\n- When: creating task\n- Then: include validation_checklist and tradeoffs in design field\n- Should not: leave checklist empty\n\n**[arch-propose-revision-history]**\n- Given: existing plan\n- When: revising\n- Then: create PROPOSAL-N+1 task and mark old as `pasture:superseded`\n- Should not: lose history\n\n## Task Recovery\n\nThe tracker backend is recorded once in .agents.local\u002Fpasture\u002FEPOCH.md; read that file instead of re-probing. If EPOCH.md is absent, stop and ask the orchestrator to run detection.\n\nRecover from live tracker state at session start and after compaction; never trust cached task rows. Read the `rec:` path from the header and use it as the one entry point: `\"${EPOCH_REC}\" \u003Cop>`. The operation set is closed: create, label, block, note, show, query, ready, status, close, whoami, signal.\n\nStore selection: the adapter reads PASTURE_DB_PATH when set, otherwise the header's `db:`; the probe wrote that value from the same precedence (XDG_DATA_HOME\u002Fpasture\u002Fpasture.db, HOME\u002F.local\u002Fshare\u002Fpasture\u002Fpasture.db, then .pasture\u002Fpasture.db). Use the same selected store for every command. If a recovery query fails, report its actual store path, failed operation, impact, and permission\u002Fschema\u002Fconfiguration repair; failure is not an empty work queue.\n\nThe adapter passes `--namespace` only when EPOCH.md records `namespace:`. That pin wins on both backends. Otherwise it omits the flag. Pasture then derives the namespace itself: PASTURE_NAMESPACE, else the git remote, then file:\u002F\u002F of the working directory. The ledger calls derive_namespace for the header and for every write that has no pin. That function is the one list of remote forms; do not restate it. With no origin, both backends use file:\u002F\u002F of the working directory, so invocations from different subdirectories use different namespaces. Queries without a pin follow that backend's derivation; pass `--all-namespaces` to opt out. When neither a pin nor PASTURE_NAMESPACE is set, pasture reads are unscoped and creation falls back to the git remote, then file:\u002F\u002F of the working directory. Inspect the returned full URI before choosing repository work. Separate reads are not an atomic snapshot.\n\nRun `\"${EPOCH_REC}\" ready`, `\"${EPOCH_REC}\" query --blocked`, and `\"${EPOCH_REC}\" query --status in_progress`. For each referenced active task, run `\"${EPOCH_REC}\" show \"$TASK_URI\"`, `\"${EPOCH_REC}\" show \"$TASK_URI\" --notes`, and `\"${EPOCH_REC}\" show \"$TASK_URI\" --history`. All *_URI variables in examples are inputs bound to full task URIs from an assignment, a verified tracker read, or the URI create printed; never use legacy short IDs. Resolve each variable before execution and quote it as one operand.\n\nCreate prints the new task URI directly. Persist it before any label or note: create-plus-label is non-atomic, so on failure retain the URI and retry only the failed label\u002Fnote operation, never create again. Only open, in_progress, and closed are statuses; blockage is represented by live dependencies and notes, not a blocked status.\n\nAn owner is recorded with `\"${EPOCH_REC}\" label \"$TASK_URI\" owner:\u003Crole>`. That is a claim, not an allocation: an unassigned task stays unassigned until the supervisor allocates it, and repeating an identical claim is not allocation. Never invent an owner.\n\nParent stays open and is blocked by child: `\"${EPOCH_REC}\" block \"$PARENT_URI\" --by \"$CHILD_URI\"`. Reference documents belong in description frontmatter under references:, never fabricated blockers. Workers report evidence and handoffs without closing their slices or leaves; the supervisor closes only after independent review and satisfied gates. Use git agent-commit for local commits. Never install, enable, or modify Git hooks, Git hook path configuration, or pre-commit integration without explicit user approval. Tracker writes are durable; Git history lands separately.\n\nIf the header records `backend: error`, stop before the first mutation: the store exists but cannot be used, and falling back could lose earlier epochs. A mid-epoch write failure retries 3 times. After the third failure, write the attempted record to .agents.local\u002Fpasture\u002Fpending\u002F\u003Ctimestamp>-\u003Cop>.md, keep the recorded backend, and surface the pending record to the user at the next gate. Never switch backends and never drop the record.\n\n## Task Attribution\n\nSelect the current registered author with \"${EPOCH_REC}\" whoami. It prints the author recorded in the header or PASTURE_AUTHOR, and on the pasture backend it confirms that actor with agents show. It does not list agents and it does not invent one. If neither source names an author, it stops: set author: in EPOCH.md or export PASTURE_AUTHOR. Never auto-register or guess an identity during recovery. Every note supplies --author explicitly; machine examples use the pre-registered pasture-system\u002F00000000-0000-0000-0000-000000000000 actor. If it is absent, stop and request registration from the operator rather than claiming registration is fixed. Preserve human intent verbatim and quote historical attribution as evidence, not as a forged new author.\n\n## When to Use\n\nStarting new feature design; creating formal plan for review.\n\n## PROPOSAL-N Naming\n\nProposals are numbered incrementally: PROPOSAL-1, PROPOSAL-2, etc. Each revision increments N. Old proposals are marked `pasture:superseded` with a comment explaining why.\n\n## Pasture Task Creation\n\n```bash\nPROPOSAL_ID_URI=$(\"${EPOCH_REC}\" create --kind feature --title \"PROPOSAL-1: \u003Cfeature name>\" --phase propose \\\n  --body=\"$(cat \u003C\u003CEOF\n---\nreferences:\n  request: \"${REQUEST_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n---\n\n## Problem Space\n\n**Axes of the problem:**\n- Parallelism: ...\n- Distribution: ...\n\n**Has-a \u002F Is-a:**\n- X HAS-A Y\n- Z IS-A W\n\n## Engineering Tradeoffs\n\n| Option | Pros | Cons | Decision |\n|--------|------|------|----------|\n| A | ... | ... | Selected |\n| B | ... | ... | Rejected |\n\n## MVP Milestone\n\n\u003Cscope with tradeoff rationale>\n\n## Public Interfaces\n\n\\\\`\\\\`\\\\`go\ntype Example interface { \u002F* ... *\u002F }\n\\\\`\\\\`\\\\`\n\n## Types & Enums\n\n\\\\`\\\\`\\\\`go\ntype ExampleType int\n\nconst (\n    ExampleTypeA ExampleType = iota\n    ExampleTypeB\n)\n\\\\`\\\\`\\\\`\n\n## Validation Checklist\n\n### Phase 1\n- [ ] Item 1\n- [ ] Item 2\n\n### Phase 2\n- [ ] Item 3\n\n## BDD Acceptance Criteria\n\n**Given** precondition\n**When** action\n**Then** outcome\n**Should Not** negative case\n\n## Files Affected\n- pkg\u002Fpath\u002Ffile1.go (create)\n- pkg\u002Fpath\u002Ffile2.go (modify)\nEOF\n)\")\n\"${EPOCH_REC}\" label \"$PROPOSAL_ID_URI\" pasture:p3-plan:s3-propose\n\"${EPOCH_REC}\" note \"$PROPOSAL_ID_URI\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Design: '{\\\"validation_checklist\\\":[\\\"Item 1\\\",\\\"Item 2\\\",\\\"Item 3\\\"],\\\"tradeoffs\\\":[{\\\"decision\\\":\\\"Use A\\\",\\\"rationale\\\":\\\"Because...\\\"}],\\\"acceptance_criteria\\\":[{\\\"given\\\":\\\"X\\\",\\\"when\\\":\\\"Y\\\",\\\"then\\\":\\\"Z\\\",\\\"should_not\\\":\\\"W\\\"}]}'\"\n\n# Link to request\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${PROPOSAL_ID_URI}\"\n```\n\n## Before Creating the Proposal\n\nRead the URD and Phase 1 outputs to understand full context before drafting:\n```bash\n\"${EPOCH_REC}\" show \"${URD_ID_URI}\"\n\"${EPOCH_REC}\" show \"${REQUEST_ID_URI}\"   # includes classification, research findings, explore findings as comments\n```\n\nThe URD contains the structured requirements, priorities, design choices, and MVP goals from the URE survey. The REQUEST task comments contain Phase 1 outputs: classification (4 axes), domain research findings (prior art, standards), and codebase exploration findings (entry points, related types, dependencies). Your proposal must:\n- Trace back to URD requirements\n- Incorporate research findings (prior art, domain standards) into engineering tradeoffs\n- Reference explore findings (entry points, existing patterns) in the files affected section\n\n## Plan Structure\n\n- **Requirements Traceability: URD:** `\u003Curd-id>`\n- Problem Space (axes, has-a\u002Fis-a)\n- Engineering Tradeoffs (table with decisions)\n- MVP Milestone (scope with tradeoff rationale)\n- Public Interfaces (Go)\n- Types & Enums\n- Validation Checklist (per phase)\n- BDD Acceptance Criteria\n- Files Affected\n\n## Next Steps\n\nAfter creating PROPOSAL-N task:\n1. Run `\u002Fpasture:architect-request-review` to spawn 3 reviewers\n2. Wait for all 3 reviewers to vote ACCEPT\n3. Run `\u002Fpasture:architect-ratify` to add ratify label to PROPOSAL-N\n\n## Follow-up Proposals (FOLLOWUP_PROPOSAL-N)\n\nWhen creating proposals for a follow-up epic (received via h6 from supervisor):\n- **Title prefix:** `FOLLOWUP_PROPOSAL-N:` (e.g., `FOLLOWUP_PROPOSAL-1: Add request-id correlation`)\n- **References:** Include both `original_urd: \u003Cid>` and `followup_urd: \u003Cid>` in frontmatter\n- **Content:** Address specific IMPORTANT\u002FMINOR findings scoped in FOLLOWUP_URE\u002FURD\n- Same review\u002Fratify\u002FUAT lifecycle applies (3 reviewers, ACCEPT\u002FREVISE, UAT, ratify, handoff)\n\u003C!-- END GENERATED FROM pasture schema -->\n","# Architect: Propose Plan\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Command:** `pasture:architect:propose-plan` — Create PROPOSAL-N task with full technical plan\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-3-proposal-n)** \u003C- Phase 3\n\n**[arch-propose-bdd-format]**\n- Given: feature request\n- When: proposing\n- Then: use BDD Given\u002FWhen\u002FThen format with acceptance criteria\n- Should not: write vague requirements\n\n**[arch-propose-checklist-required]**\n- Given: plan\n- When: creating task\n- Then: include validation_checklist and tradeoffs in design field\n- Should not: leave checklist empty\n\n**[arch-propose-revision-history]**\n- Given: existing plan\n- When: revising\n- Then: create PROPOSAL-N+1 task and mark old as `pasture:superseded`\n- Should not: lose history\n\n## Task Recovery\n\nThe tracker backend is recorded once in .agents.local\u002Fpasture\u002FEPOCH.md; read that file instead of re-probing. If EPOCH.md is absent, stop and ask the orchestrator to run detection.\n\nRecover from live tracker state at session start and after compaction; never trust cached task rows. Read the `rec:` path from the header and use it as the one entry point: `\"${EPOCH_REC}\" \u003Cop>`. The operation set is closed: create, label, block, note, show, query, ready, status, close, whoami, signal.\n\nStore selection: the adapter reads PASTURE_DB_PATH when set, otherwise the header's `db:`; the probe wrote that value from the same precedence (XDG_DATA_HOME\u002Fpasture\u002Fpasture.db, HOME\u002F.local\u002Fshare\u002Fpasture\u002Fpasture.db, then .pasture\u002Fpasture.db). Use the same selected store for every command. If a recovery query fails, report its actual store path, failed operation, impact, and permission\u002Fschema\u002Fconfiguration repair; failure is not an empty work queue.\n\nThe adapter passes `--namespace` only when EPOCH.md records `namespace:`. That pin wins on both backends. Otherwise it omits the flag. Pasture then derives the namespace itself: PASTURE_NAMESPACE, else the git remote, then file:\u002F\u002F of the working directory. The ledger calls derive_namespace for the header and for every write that has no pin. That function is the one list of remote forms; do not restate it. With no origin, both backends use file:\u002F\u002F of the working directory, so invocations from different subdirectories use different namespaces. Queries without a pin follow that backend's derivation; pass `--all-namespaces` to opt out. When neither a pin nor PASTURE_NAMESPACE is set, pasture reads are unscoped and creation falls back to the git remote, then file:\u002F\u002F of the working directory. Inspect the returned full URI before choosing repository work. Separate reads are not an atomic snapshot.\n\nRun `\"${EPOCH_REC}\" ready`, `\"${EPOCH_REC}\" query --blocked`, and `\"${EPOCH_REC}\" query --status in_progress`. For each referenced active task, run `\"${EPOCH_REC}\" show \"$TASK_URI\"`, `\"${EPOCH_REC}\" show \"$TASK_URI\" --notes`, and `\"${EPOCH_REC}\" show \"$TASK_URI\" --history`. All *_URI variables in examples are inputs bound to full task URIs from an assignment, a verified tracker read, or the URI create printed; never use legacy short IDs. Resolve each variable before execution and quote it as one operand.\n\nCreate prints the new task URI directly. Persist it before any label or note: create-plus-label is non-atomic, so on failure retain the URI and retry only the failed label\u002Fnote operation, never create again. Only open, in_progress, and closed are statuses; blockage is represented by live dependencies and notes, not a blocked status.\n\nAn owner is recorded with `\"${EPOCH_REC}\" label \"$TASK_URI\" owner:\u003Crole>`. That is a claim, not an allocation: an unassigned task stays unassigned until the supervisor allocates it, and repeating an identical claim is not allocation. Never invent an owner.\n\nParent stays open and is blocked by child: `\"${EPOCH_REC}\" block \"$PARENT_URI\" --by \"$CHILD_URI\"`. Reference documents belong in description frontmatter under references:, never fabricated blockers. Workers report evidence and handoffs without closing their slices or leaves; the supervisor closes only after independent review and satisfied gates. Use git agent-commit for local commits. Never install, enable, or modify Git hooks, Git hook path configuration, or pre-commit integration without explicit user approval. Tracker writes are durable; Git history lands separately.\n\nIf the header records `backend: error`, stop before the first mutation: the store exists but cannot be used, and falling back could lose earlier epochs. A mid-epoch write failure retries 3 times. After the third failure, write the attempted record to .agents.local\u002Fpasture\u002Fpending\u002F\u003Ctimestamp>-\u003Cop>.md, keep the recorded backend, and surface the pending record to the user at the next gate. Never switch backends and never drop the record.\n\n## Task Attribution\n\nSelect the current registered author with \"${EPOCH_REC}\" whoami. It prints the author recorded in the header or PASTURE_AUTHOR, and on the pasture backend it confirms that actor with agents show. It does not list agents and it does not invent one. If neither source names an author, it stops: set author: in EPOCH.md or export PASTURE_AUTHOR. Never auto-register or guess an identity during recovery. Every note supplies --author explicitly; machine examples use the pre-registered pasture-system\u002F00000000-0000-0000-0000-000000000000 actor. If it is absent, stop and request registration from the operator rather than claiming registration is fixed. Preserve human intent verbatim and quote historical attribution as evidence, not as a forged new author.\n\n## When to Use\n\nStarting new feature design; creating formal plan for review.\n\n## PROPOSAL-N Naming\n\nProposals are numbered incrementally: PROPOSAL-1, PROPOSAL-2, etc. Each revision increments N. Old proposals are marked `pasture:superseded` with a comment explaining why.\n\n## Pasture Task Creation\n\n```bash\nPROPOSAL_ID_URI=$(\"${EPOCH_REC}\" create --kind feature --title \"PROPOSAL-1: \u003Cfeature name>\" --phase propose \\\n  --body=\"$(cat \u003C\u003CEOF\n---\nreferences:\n  request: \"${REQUEST_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n---\n\n## Problem Space\n\n**Axes of the problem:**\n- Parallelism: ...\n- Distribution: ...\n\n**Has-a \u002F Is-a:**\n- X HAS-A Y\n- Z IS-A W\n\n## Engineering Tradeoffs\n\n| Option | Pros | Cons | Decision |\n|--------|------|------|----------|\n| A | ... | ... | Selected |\n| B | ... | ... | Rejected |\n\n## MVP Milestone\n\n\u003Cscope with tradeoff rationale>\n\n## Public Interfaces\n\n\\\\`\\\\`\\\\`go\ntype Example interface { \u002F* ... *\u002F }\n\\\\`\\\\`\\\\`\n\n## Types & Enums\n\n\\\\`\\\\`\\\\`go\ntype ExampleType int\n\nconst (\n    ExampleTypeA ExampleType = iota\n    ExampleTypeB\n)\n\\\\`\\\\`\\\\`\n\n## Validation Checklist\n\n### Phase 1\n- [ ] Item 1\n- [ ] Item 2\n\n### Phase 2\n- [ ] Item 3\n\n## BDD Acceptance Criteria\n\n**Given** precondition\n**When** action\n**Then** outcome\n**Should Not** negative case\n\n## Files Affected\n- pkg\u002Fpath\u002Ffile1.go (create)\n- pkg\u002Fpath\u002Ffile2.go (modify)\nEOF\n)\")\n\"${EPOCH_REC}\" label \"$PROPOSAL_ID_URI\" pasture:p3-plan:s3-propose\n\"${EPOCH_REC}\" note \"$PROPOSAL_ID_URI\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Design: '{\\\"validation_checklist\\\":[\\\"Item 1\\\",\\\"Item 2\\\",\\\"Item 3\\\"],\\\"tradeoffs\\\":[{\\\"decision\\\":\\\"Use A\\\",\\\"rationale\\\":\\\"Because...\\\"}],\\\"acceptance_criteria\\\":[{\\\"given\\\":\\\"X\\\",\\\"when\\\":\\\"Y\\\",\\\"then\\\":\\\"Z\\\",\\\"should_not\\\":\\\"W\\\"}]}'\"\n\n# Link to request\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${PROPOSAL_ID_URI}\"\n```\n\n## Before Creating the Proposal\n\nRead the URD and Phase 1 outputs to understand full context before drafting:\n```bash\n\"${EPOCH_REC}\" show \"${URD_ID_URI}\"\n\"${EPOCH_REC}\" show \"${REQUEST_ID_URI}\"   # includes classification, research findings, explore findings as comments\n```\n\nThe URD contains the structured requirements, priorities, design choices, and MVP goals from the URE survey. The REQUEST task comments contain Phase 1 outputs: classification (4 axes), domain research findings (prior art, standards), and codebase exploration findings (entry points, related types, dependencies). Your proposal must:\n- Trace back to URD requirements\n- Incorporate research findings (prior art, domain standards) into engineering tradeoffs\n- Reference explore findings (entry points, existing patterns) in the files affected section\n\n## Plan Structure\n\n- **Requirements Traceability: URD:** `\u003Curd-id>`\n- Problem Space (axes, has-a\u002Fis-a)\n- Engineering Tradeoffs (table with decisions)\n- MVP Milestone (scope with tradeoff rationale)\n- Public Interfaces (Go)\n- Types & Enums\n- Validation Checklist (per phase)\n- BDD Acceptance Criteria\n- Files Affected\n\n## Next Steps\n\nAfter creating PROPOSAL-N task:\n1. Run `\u002Fpasture:architect-request-review` to spawn 3 reviewers\n2. Wait for all 3 reviewers to vote ACCEPT\n3. Run `\u002Fpasture:architect-ratify` to add ratify label to PROPOSAL-N\n\n## Follow-up Proposals (FOLLOWUP_PROPOSAL-N)\n\nWhen creating proposals for a follow-up epic (received via h6 from supervisor):\n- **Title prefix:** `FOLLOWUP_PROPOSAL-N:` (e.g., `FOLLOWUP_PROPOSAL-1: Add request-id correlation`)\n- **References:** Include both `original_urd: \u003Cid>` and `followup_urd: \u003Cid>` in frontmatter\n- **Content:** Address specific IMPORTANT\u002FMINOR findings scoped in FOLLOWUP_URE\u002FURD\n- Same review\u002Fratify\u002FUAT lifecycle applies (3 reviewers, ACCEPT\u002FREVISE, UAT, ratify, handoff)\n\u003C!-- END GENERATED FROM pasture schema -->\n",{"name":5,"description":7},"main","5813de22110ddc609b465a982b4811646ff72d18","internal\u002Ftarget\u002Fclaudecode\u002Fassets\u002Fpasture-skills\u002Fskills\u002Farchitect-propose-plan",0,"https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture","https:\u002F\u002Fgithub.com\u002Fdayvidpham","dhpham.com","2026-11-11 16:48:48",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add dayvidpham\u002Fpasture --skill architect-propose-plan",{"tool":49,"command":50},"bunx","bunx skills add dayvidpham\u002Fpasture --skill architect-propose-plan",{"tool":52,"command":53},"pnpm","pnpm dlx skills add dayvidpham\u002Fpasture --skill architect-propose-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Finternal\u002Ftarget\u002Fclaudecode\u002Fassets\u002Fpasture-skills\u002Fskills\u002Farchitect-propose-plan\u002FSKILL.md",true,[],[58,66,81,91,103,114],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":30},"01M6DAP7307B3JVZX5DSNAE08Y","fixture","Isolated fixture skill","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Ftestdata\u002Finstall\u002Fglobal\u002Fclaude-code\u002Fnative-marketplace\u002Ffixture-plugin\u002Fskills\u002Ffixture\u002FSKILL.md",[],[60,65],"fixture skill",{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":30},"01M6DAP48A4K365N83NBG0GFVC","worker","Vertical slice implementer (full production code path)","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker\u002FSKILL.md",[],[68,73,74,75,76,25,77,78,79,80],"implementer","code","implement","Production","complete","vertical slice","slice","path",{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":30},"01M6DAP18QJM7P7N31TYGNJBCP","worker-implement","Implement assigned vertical slice following TDD layers","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-implement\u002FSKILL.md",[],[88,68,75,78,89,79,90],"worker implement","layers","tdd",{"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":97,"publishedAt":30},"01M6DANYHC7P63RFEN26F70MC2","worker-complete","Signal slice completion after quality gates pass","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-complete\u002FSKILL.md",[],[68,98,77,99,79,100,101,102],"worker complete","signal","gates","quality","quality gates",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":30},"01M6DANWZ31TRP4NN4T1BFYKSR","worker-blocked","Report a blocker to supervisor via Pasture","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-blocked\u002FSKILL.md",[],[110,68,111,112,113],"worker blocked","via","report","supervisor",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":125,"publishedAt":30},"01M6DANSVDBXBFH93B6EX3H2QK","user-uat","User Acceptance Testing with demonstrative examples","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fuser-uat\u002FSKILL.md",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[126,127,128,129,28,130,131,132,133],"uat","user uat","user","acceptance testing","user acceptance testing","examples","acceptance","testing"]