{"id":"073fba0f-478f-4274-966c-d1c8a069b328","entityType":"agent","slug":"clawhub-binggg-spec-workflow-guide","name":"需求与设计流程 · Spec Workflow","canonicalUrl":"https://www.xpersona.co/agent/clawhub-binggg-spec-workflow-guide","canonicalPath":"/agent/clawhub-binggg-spec-workflow-guide","generatedAt":"2026-10-09T08:19:32.234Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T05:00:42.130Z","emptyReason":null},"description":"Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests. Skill: 需求与设计流程 · Spec Workflow Owner: binggg Summary: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests. Tags: latest:1.18.54 Version history: v1.18.54 | 2026-10-09T04:59:03.202Z | user Recent commits / 最近提交: | - feat(mcp): retire MySQL provisioning from t","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 4.7K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17cgdbxp195f7dy8f5h6p0d9183h6nq:spec-workflow-guide","sourceUrl":"https://clawhub.ai/binggg/spec-workflow-guide","homepage":"https://clawhub.ai/binggg/skills/spec-workflow-guide","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/binggg/spec-workflow-guide","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/binggg/skills/spec-workflow-guide","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":41,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclea"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T05:00:42.130Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T05:00:42.130Z","emptyReason":null},"stars":null,"forks":null,"downloads":4697,"packageName":null,"latestVersion":"1.18.54","tractionLabel":"4.7K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T05:00:42.129Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T05:00:42.130Z","lastCrawledAt":"2026-10-09T05:00:42.129Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T05:00:42.129Z","lastVerifiedAt":null,"highlights":[{"version":"1.18.54","createdAt":"2026-10-09T04:59:03.202Z","changelog":"Recent commits / 最近提交: | - feat(mcp): retire MySQL provisioning from the tool surface (#1137) | - chore(deps): 🔒 把安全 overrides 顶到已修复版本 (#1135) | - feat(mcp): harden hosted requests without a shared server (#1133) | - fix(mcp): 🔐 让项目级凭据优先于账号级登录态 (#1134) | - docs: 🔄 sync CloudBase CloudAPI reference page","fileCount":2,"zipByteSize":2651},{"version":"1.18.53","createdAt":"2026-09-30T13:46:14.093Z","changelog":"Recent commits / 最近提交: | - fix(clawhub): 🏷️ publish the curated display name and topics (#1124) | - docs: 🔄 sync CloudBase CloudAPI reference page | - feat(evals): ✨ score the secret and migration tasks (#1122) | - feat(evals): add the scenario runner and point it at a local endpoint (#1119) | - fix(mcp): 🔧 report local endpoint failures directly (#1118)","fileCount":3,"zipByteSize":3530},{"version":"1.18.52","createdAt":"2026-09-30T06:15:55.260Z","changelog":"Recent commits / 最近提交: | - chore(release): bump version to v2.34.8 | - fix(mcp): 🔒 bind the two-phase function deploy to the upload target it signed (#1114) | - feat(mcp): route cloud API calls to a local endpoint (#1116) | - feat(evals): ✨ point the public dry run at a scored task (#1113) | - fix(dsh-plugin): 📝 describe database, storage, auth, and deploy (#1117)","fileCount":3,"zipByteSize":3572},{"version":"1.18.51","createdAt":"2026-09-21T13:26:10.631Z","changelog":"Recent commits / 最近提交: | - chore(release): bump version to v2.34.6 | - chore: sync cloudbase plugin skills from upstream | - chore(connectors): sync generated cloudbase-intl package [skip ci] | - chore(experts): auto-bump versions for changed packs [skip ci] | - Merge branch 'feat/function-publish-version-9cb1bf6e'","fileCount":3,"zipByteSize":3751},{"version":"1.18.50","createdAt":"2026-09-20T09:29:24.103Z","changelog":"Recent commits / 最近提交: | - chore(release): bump version to v2.34.5 | - fix(internal-sync): 🧹 keep atomic-write temp files out of the archive (#1070) | - chore(experts): auto-bump versions for changed packs [skip ci] | - chore(dsh-plugin): bump version to 0.1.2 | - chore(experts): auto-bump versions for changed packs [skip ci]","fileCount":3,"zipByteSize":3717},{"version":"1.18.49","createdAt":"2026-09-16T09:35:11.244Z","changelog":"Recent commits / 最近提交: | - chore(release): bump version to v2.34.4 | - chore: sync cloudbase plugin skills from upstream | - feat(skills): 📚 add PostgreSQL access-pattern best practices (#1046) | - fix(mcp): 🧭 按 OpenAI hosted Scan 收紧工具注解 (#1047) | - docs: 🔄 sync CloudBase CloudAPI reference page","fileCount":3,"zipByteSize":3639},{"version":"1.18.48","createdAt":"2026-09-14T05:11:46.766Z","changelog":"Recent commits / 最近提交: | - chore(release): bump version to v2.34.3 | - fix(mcp): 🐛 harden hosted tool contracts and error signalling (#1039) | - fix(ci): 🔧 run the plugin-skill pull-back after the upstream push (#1038) | - chore: sync cloudbase plugin skills from upstream | - chore: sync claude skills mirror from source","fileCount":3,"zipByteSize":3757},{"version":"1.18.47","createdAt":"2026-09-13T16:36:15.702Z","changelog":"Recent commits / 最近提交: | - chore(release): bump version to v2.34.2 | - fix(mcp): 🐛 align the login_by_api_key hint with the parameter the tool reads (envId → apiKeyEnvId) (#1037) | - chore: sync cloudbase plugin skills from upstream | - chore: sync claude skills mirror from source | - chore(release): bump version to v2.34.1","fileCount":3,"zipByteSize":3670}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17cgdbxp195f7dy8f5h6p0d9183h6nq:spec-workflow-guide","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-09T08:19:32.232Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-binggg-spec-workflow-guide/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T05:00:42.130Z","emptyReason":null},"readme":"Skill: 需求与设计流程 · Spec Workflow\n\nOwner: binggg\n\nSummary: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\n\nTags: latest:1.18.54\n\nVersion history:\n\nv1.18.54 | 2026-10-09T04:59:03.202Z | user\n\nRecent commits / 最近提交: | - feat(mcp): retire MySQL provisioning from the tool surface (#1137) | - chore(deps): 🔒 把安全 overrides 顶到已修复版本 (#1135) | - feat(mcp): harden hosted requests without a shared server (#1133) | - fix(mcp): 🔐 让项目级凭据优先于账号级登录态 (#1134) | - docs: 🔄 sync CloudBase CloudAPI reference page\n\nv1.18.53 | 2026-09-30T13:46:14.093Z | user\n\nRecent commits / 最近提交: | - fix(clawhub): 🏷️ publish the curated display name and topics (#1124) | - docs: 🔄 sync CloudBase CloudAPI reference page | - feat(evals): ✨ score the secret and migration tasks (#1122) | - feat(evals): add the scenario runner and point it at a local endpoint (#1119) | - fix(mcp): 🔧 report local endpoint failures directly (#1118)\n\nv1.18.52 | 2026-09-30T06:15:55.260Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.34.8 | - fix(mcp): 🔒 bind the two-phase function deploy to the upload target it signed (#1114) | - feat(mcp): route cloud API calls to a local endpoint (#1116) | - feat(evals): ✨ point the public dry run at a scored task (#1113) | - fix(dsh-plugin): 📝 describe database, storage, auth, and deploy (#1117)\n\nv1.18.51 | 2026-09-21T13:26:10.631Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.34.6 | - chore: sync cloudbase plugin skills from upstream | - chore(connectors): sync generated cloudbase-intl package [skip ci] | - chore(experts): auto-bump versions for changed packs [skip ci] | - Merge branch 'feat/function-publish-version-9cb1bf6e'\n\nv1.18.50 | 2026-09-20T09:29:24.103Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.34.5 | - fix(internal-sync): 🧹 keep atomic-write temp files out of the archive (#1070) | - chore(experts): auto-bump versions for changed packs [skip ci] | - chore(dsh-plugin): bump version to 0.1.2 | - chore(experts): auto-bump versions for changed packs [skip ci]\n\nv1.18.49 | 2026-09-16T09:35:11.244Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.34.4 | - chore: sync cloudbase plugin skills from upstream | - feat(skills): 📚 add PostgreSQL access-pattern best practices (#1046) | - fix(mcp): 🧭 按 OpenAI hosted Scan 收紧工具注解 (#1047) | - docs: 🔄 sync CloudBase CloudAPI reference page\n\nv1.18.48 | 2026-09-14T05:11:46.766Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.34.3 | - fix(mcp): 🐛 harden hosted tool contracts and error signalling (#1039) | - fix(ci): 🔧 run the plugin-skill pull-back after the upstream push (#1038) | - chore: sync cloudbase plugin skills from upstream | - chore: sync claude skills mirror from source\n\nv1.18.47 | 2026-09-13T16:36:15.702Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.34.2 | - fix(mcp): 🐛 align the login_by_api_key hint with the parameter the tool reads (envId → apiKeyEnvId) (#1037) | - chore: sync cloudbase plugin skills from upstream | - chore: sync claude skills mirror from source | - chore(release): bump version to v2.34.1\n\nv1.18.46 | 2026-09-13T16:01:08.423Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.34.1 | - chore: sync cloudbase plugin skills from upstream | - chore(experts): auto-bump versions for changed packs [skip ci] | - feat: 把部署后分享环节送到专家包与实际部署路径上 (#1036) | - fix(mcp): keep the OpenAPI doc list order stable across builds (#1035)\n\nv1.18.45 | 2026-09-13T14:50:52.651Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.34.0 | - chore(release): refresh generated tools artifacts | - chore(gitignore): 忽略 plugin 发布产物的带时间戳变体 | - fix(mcp): 放宽 STS 资源级 E2E 的超时预算，消除云存储用例偶发超时 (#1034) | - fix(tools): CNB 链接存活检查区分「待合并后可见」，并刷掉自己的 compat 欠账 (#1033)\n\nv1.18.44 | 2026-09-08T13:00:10.029Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.33.2 | - chore: sync claude skills mirror from source | - Merge pull request #980 from yulinlin2020/feature/deploy0831 | - Merge pull request #1009 from TencentCloudBase/feat/webdev-expert-prereq-checks | - feat(experts): add connector & skill prerequisite checks to cloudbase-webdev-expert\n\nv1.18.43 | 2026-09-08T04:25:46.946Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.33.1 | - chore(release): build artifacts for v2.33.1 | - Merge branch 'feature/tool-naming-env-domain-converge' | - feat(telemetry): add client param and region/site reporting for hosted MCP | - Merge pull request #1006 from TencentCloudBase/fix/intl-device-flow-auth-url\n\nv1.18.42 | 2026-09-04T09:55:36.171Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.33.0 (eea512f9) | - feat(functions): 支持云函数自定义镜像部署与异步部署状态查询 (#985) | - chore: sync cloudbase plugin skills from upstream | - chore: sync claude skills mirror from source | - refactor(env): converge env domain tool naming into query*/manage* system (#997)\n\nv1.18.41 | 2026-09-01T10:42:12.231Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.32.5 (4e6ca71c) | - fix(auth): international-site (TCB_SITE=intl) API key routing, device flow and diagnostics (#972) | - fix(mcp): queryEnv(list) pin to bound env for hosted OAuth token (环境级 STS) (#968) | - refactor(rag): remove vector mode from searchKnowledgeBase (#973) | - fix(cloudrun): mask service env params by default in queryCloudRun detail (#975)\n\nv1.18.40 | 2026-08-28T04:24:16.318Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.32.4 (a9cd97d2) | - chore: sync claude skills mirror from source | - fix(auth): give OTP sdkHints full call context and messageId caution (#964) | - chore: sync cloudbase plugin skills from upstream | - docs(release): add v2.32.3 release notes (7b513c4e)\n\nv1.18.39 | 2026-08-26T13:23:47.962Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.32.3 (7b513c4e) | - fix(auth): 🔧 resolve ambiguous-region credentials from the only usable site slot (#962) | - fix(tests): 🔨 retry temp dir cleanup in cloudbase-sites-plugin tests (#961) | - feat(pg): default ExecutePGSql role to cloudbase_postgres, reserve cloudbase_admin (#959) | - feat(dsh-plugin): @cloudbase/dsh-plugin — CloudBase backend for DeepSeek Harness (#933)\n\nv1.18.38 | 2026-08-25T10:35:46.750Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.32.2 (eec8ec79) | - Merge pull request #958 from TencentCloudBase/feat/msg-push-container-mode | - chore(deps): ⬆️ bump @cloudbase/manager-node to 5.8.2 (requestFn support, MR !150) | - Merge pull request #956 from TencentCloudBase/feat/git-guard-pre-push | - Revert \"fix(nosql): 🐛 route tcb-domain DB calls via requestFn when present (WeChat IDE has no Tencent creds) (dc0eaaf9)\"\n\nv1.18.37 | 2026-08-25T05:13:38.756Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.32.1 (82a92358) | - Merge pull request #957 from TencentCloudBase/feat/msg-push-container-mode | - docs(skill): 🔧 use WeChat-side tool names (cloud_query_msg_push/cloud_manage_msg_push) in skill docs (dc0eaaf9) | - docs(skill): 📚 add push-mode (cloudfunction/container) chapter to message-push reference (dc0eaaf9) | - fix(msg-push): ⚠️ degrade function-existence check when host hook absent (compat with WeChat IDE, dc0eaaf9)\n\nv1.18.36 | 2026-08-24T13:19:57.612Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.32.0 (e30ee663) | - chore: sync cloudbase plugin skills from upstream | - Merge pull request #949 from TencentCloudBase/feat/virtual-payment-mcp | - fix(skill): 📏 compress miniprogram-development description under Codex 1024-char limit (dc0eaaf9) | - Merge remote-tracking branch 'origin/main' into feat/virtual-payment-mcp\n\nv1.18.35 | 2026-08-20T15:36:34.093Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.31.0 (7efa4dd50) | - Merge pull request #947 from TencentCloudBase/feat/getdeploylog-coding-fix | - fix(cloudrun): 🔧 align getDeployLog coding fallback next_step action union (b2cb3661) | - task: queryCloudRun getDeployLog 遇 CODING 未登录改 (18efa60c) | - chore: sync cloudbase plugin skills from upstream\n\nv1.18.34 | 2026-08-20T12:27:12.080Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.30.1 (9326243c1) | - Merge pull request #944 from TencentCloudBase/feat/kimi-plugin-zip-cleanup | - refactor(kimi): 🧹 assemble sibling skills into cloudbase/references | - chore: sync cloudbase plugin skills from upstream | - chore: sync claude skills mirror from source\n\nv1.18.33 | 2026-08-20T08:10:15.447Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.30.0 (a84f982e) | - Merge pull request #943 from TencentCloudBase/feat/kimi-plugin-zip-cleanup | - refactor(kimi): 🧹 whitelist-only zip with version-free asset name | - Merge pull request #942 from TencentCloudBase/feat/mcp-region-env-scope | - chore: sync claude skills mirror from source\n\nv1.18.32 | 2026-08-20T07:40:24.519Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.29.0 (3636e6c7) | - Merge pull request #941 from TencentCloudBase/feat/kimi-plugin-publish | - feat(kimi): 📦 pack Kimi plugin zip and attach to release assets | - chore: sync cloudbase plugin skills from upstream | - chore: sync claude skills mirror from source\n\nv1.18.31 | 2026-08-18T12:13:44.178Z | user\n\nRecent commits / 最近提交: | - chore(release): merge main into v2.28.1 bump (52383793) | - Merge pull request #932 from TencentCloudBase/feat/kimi-plugin-shared-manifest | - chore(release): 🚀 bump version to v2.28.1 (52383793) | - fix(kimi): drop tcb CLI from skillInstructions — login via MCP auth tool | - docs(kimi): align interface copy with Vercel/Supabase Codex plugin pattern\n\nv1.18.30 | 2026-08-18T02:48:22.753Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.28.0 (5520bd3b) | - Merge pull request #926 from TencentCloudBase/task/cloudbase-mcp-20260818 | - fix(compat): pass-through copies only git-tracked files; refresh baseline without gitignored skills | - fix(compat): support .yaml/.yml in compat baseline classifier + refresh baseline | - docs(cloudrun): add container deploy failure SOP (bde80f9c)\n\nv1.18.29 | 2026-08-14T16:30:51.576Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.27.0 | - chore(release): 🛠️ refresh generated tools docs before v2.27.0 | - Merge pull request #909 from TencentCloudBase/fix/remove-download-path-test | - fix: 移除 downloadRemoteFile 遗留集成测试与文档分类映射 | - Merge pull request #908 from TencentCloudBase/feat/remove-downloadRemoteFile\n\nv1.18.28 | 2026-08-10T03:07:25.459Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.26.0 | - chore(release): 🛠️ refresh generated tools docs before v2.26.0 | - feat(gateway): 🔌 add enableRoute/disableRoute for gateway routes (#901) | - chore: sync cloudbase plugin skills from upstream | - chore: sync claude skills mirror from source\n\nv1.18.27 | 2026-08-05T10:33:45.168Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.25.10 | - fix(ci): 🩹 refresh compat baseline after codebuddy plugin.json change (#892) | - fix(deps): 🔒 upgrade MCP SDK to 1.30.0 and retain category annotations (#873) | - fix(env): detect RuntimeBackends.nosql from flexdb tnt InstanceId (#891) | - fix(partner): 🩹 post-#886 prewarm cleanup, skill install path, CI sync (#888)\n\nv1.18.26 | 2026-08-05T09:19:17.545Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.25.9 | - fix(ci): 📦 install examples scripts deps before build-zips (#890) | - feat(skills): add minimal-web-baas-demo and publish path (#886) | - docs(marketplace): mark Trae community MCP and skills listed (#885) | - chore(ci): ⬆️ bump clawhub CLI pin to 0.23.3 after upload-ticket fix (#884)\n\nv1.18.25 | 2026-08-05T05:52:38.868Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.25.8 | - fix(cli): break cloud-mode↔logger cycle crashing --cloud-mode (#879) | - Merge pull request #877 from TencentCloudBase/docs/awesome-copilot-intake-rerun-status | - docs(marketplace): ✅ note Awesome Copilot intake re-pass and ready-for-review | - docs(marketplace): 📝 record Awesome Copilot intake re-pass after skill-fetch strip\n\nv1.18.24 | 2026-08-05T04:25:22.990Z | user\n\nRecent commits / 最近提交: | - Merge pull request #875 from TencentCloudBase/fix/awesome-copilot-strip-remote-skill-urls | - fix(security): 🛡️ strip remote skill-fetch URLs for Copilot review | - chore: sync claude skills mirror from source | - chore(release): 🚀 bump version to v2.25.7 | - fix(ci): 🛡️ use rsync --checksum for skills repo sync (#874)\n\nv1.18.23 | 2026-08-05T03:42:16.079Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.25.7 | - fix(ci): 🛡️ use rsync --checksum for skills repo sync (#874) | - fix(deps): Dependabot security overrides + vitest 3.2.7 (#871) | - fix(ci): 🛡️ use rsync --checksum for plugin repo sync (#872) | - fix(ci): 🩹 restore workflow_dispatch inputs after concurrency insert (#870)\n\nv1.18.22 | 2026-08-04T09:48:29.167Z | user\n\nRecent commits / 最近提交: | - fix(ci): 🩹 pin clawhub CLI and harden plugin skills sync push (#868) | - chore: sync claude skills mirror from source | - chore(release): 🚀 bump version to v2.25.6 | - chore(release): 🏗️ build artifacts for v2.25.6 | - fix(functions): 🩹 accept func.name as functionName fallback\n\nv1.18.21 | 2026-08-03T15:05:58.316Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.25.5 | - fix(pg-mcp): hydrate remote migration history + poll DescribeTaskResult in applyMigration (#859) | - chore: sync cloudbase plugin skills from upstream | - feat(gateway): 🔗 add bindCustomDomain accessType/customCname (#858) | - fix(gateway): ❓ report unknown status when privilege fields are missing (#856)\n\nv1.18.20 | 2026-08-03T10:43:48.243Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.25.4 | - chore(release): build artifacts for v2.25.3 | - chore: sync claude skills mirror from source | - chore: sync cloudbase plugin skills from upstream | - feat(gateway): 🔌 add HTTP gateway privilege query and switch actions (#855)\n\nv1.18.19 | 2026-08-03T09:43:48.384Z | user\n\nRecent commits / 最近提交: | - chore(release): 🚀 bump version to v2.25.3 | - chore: sync cloudbase plugin skills from upstream | - feat(mcp): harden manageEnv billing UX and gateway HTTPSERVICE defaults (#854) | - fix(pg): 🛡️ fail closed when applyMigration does not land (#852) | - chore: sync claude skills mirror from source\n\nv1.18.18 | 2026-07-30T07:15:29.595Z | user\n\nRecent commits / 最近提交: | - chore(release): 🔖 bump version to v2.25.2 | - chore(release): 📦 rebuild prompts for v2.25.2 | - chore: sync cloudbase plugin skills from upstream | - Merge pull request #841 from TencentCloudBase/feature/multi-region-refactor-research | - Merge pull request #842 from TencentCloudBase/feature/sync-codebuddy-marketplace-fork\n\nv1.18.17 | 2026-07-28T11:59:01.856Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.25.1 | - chore: sync cloudbase plugin skills from upstream | - Merge pull request #837 from TencentCloudBase/feature/gateway-path-transmission-drop-invite | - feat(gateway): 🧭 unify upstreamResourceType and drop invite-code | - Merge pull request #836 from TencentCloudBase/fix/claude-skills-mirror-race\n\nv1.18.16 | 2026-07-28T08:44:25.312Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.25.0 | - chore(release): build artifacts for v2.25.0 | - Merge pull request #835 from TencentCloudBase/docs/cursor-directory-submitted | - docs(marketplace): 📝 track cursor.directory cloudbase listing | - Merge pull request #834 from TencentCloudBase/feature/open-plugin-logo\n\nv1.18.15 | 2026-07-28T05:31:37.175Z | user\n\nRecent commits / 最近提交: | - Merge pull request #830 from TencentCloudBase/feature/vally-skill-dir-rename | - fix(tests): 🔧 expect renamed kiro auth-web-cloudbase path | - fix(skills): 🔧 align skill directories with frontmatter names for vally | - Merge pull request #829 from TencentCloudBase/feature/cnb-plugin-mirror | - feat(plugins): mirror OPS plugin repos to CNB like skills\n\nv1.18.14 | 2026-07-21T05:52:55.493Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.24.1 | - Merge pull request #819 from TencentCloudBase/feat/plugin-beacon-dau-telemetry | - feat(plugin): 📡 add Vercel-style DAU telemetry via Beacon | - Merge pull request #818 from TencentCloudBase/feat/telemetry-mcp-client-info | - chore: sync claude skills mirror from source\n\nv1.18.13 | 2026-07-20T12:54:22.065Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.24.0 | - Merge pull request #813 from TencentCloudBase/feat/pg-migration-contract-hardening | - Merge pull request #814 from TencentCloudBase/fix/dedicated-repo-ops-only | - fix(plugin): 📦 keep dedicated repos Open Plugin Spec only | - feat(pg): 🔒 require explicit migrationVersion and default DDL to applyMigration\n\nv1.18.12 | 2026-07-15T13:07:13.515Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.23.11 | - chore(release): build artifacts for v2.23.11 | - Merge pull request #806 from TencentCloudBase/feat/plugin-review-and-skill-inject-eval | - fix: 🐛 remove unused imports flagged by github-code-quality review | - fix(compat): 🐛 fix cloudbaase typo in build-compat-config.mjs guideline targets\n\nv1.18.11 | 2026-07-14T09:12:02.025Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.23.10 | - chore(release): build artifacts | - Merge pull request #803 from TencentCloudBase/fix/search-knowledgebase-skill-search-roots | - chore: 📦 update compat baseline for .agents/skills and .claude/skills | - fix(mcp): 🔧 add .agents/skills and .claude/skills to build and searchKnowledgeBase\n\nv1.18.10 | 2026-07-13T09:23:17.340Z | user\n\nRecent commits / 最近提交: | - chore(release): 🔖 bump version to v2.23.9 | - Merge pull request #800 from TencentCloudBase/feat/pg-context-stateless | - feat(pg): ♻️ remove stateful init step, derive context per call | - Merge pull request #799 from TencentCloudBase/feat/plugin-hooks-commands-agents | - chore(deps): 🔒 update pnpm-lock.yaml for @cloudbase/manager-node\n\nv1.18.9 | 2026-07-09T06:55:23.225Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.23.8 | - chore(release): build artifacts for v2.23.8 | - feat(cloudrun): 🚀 add 12 new serverConfig params from manager-node v5.6.1 | - feat(cloudrun): 🚀 add 12 new serverConfig params from manager-node v5.6.1 | - chore: sync cloudbase plugin skills from upstream\n\nv1.18.8 | 2026-07-08T10:28:07.934Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.23.7 | - chore(release): build artifacts for v2.23.7 | - fix: 🐛 resolve deleteAccess failure when only accessId is provided | - fix: 🐛 resolve deleteAccess failure when only accessId is provided | - fix: 🐛 sanitize agent name to avoid invalid alias characters\n\nv1.18.7 | 2026-06-30T05:59:55.617Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.23.6 | - chore: sync claude skills mirror from source | - feat(mcp): ✨ rename querySqlDatabase/manageSqlDatabase to queryMysqlDatabase/manageMysqlDatabase (#782) | - chore: sync cloudbase plugin skills from upstream | - chore: sync cloudbase plugin skills from upstream\n\nv1.18.6 | 2026-06-26T11:22:20.455Z | user\n\nRecent commits / 最近提交: | - chore(release): bump version to v2.23.5 | - chore(release): build artifacts for v2.23.5 | - feat(mcp): ✨ add CustomImage imageConfig support to manageFunctions for TCR→SCF deploy (#781) | - fix(mcp): 🔧 sync package-lock.json with package.json (#780) | - fix(issue-auto): 🤖 attempt fix for issue #771 (#776)\n\nv1.18.5 | 2026-06-26T10:49:02.620Z | user\n\nRecent commits / 最近提交: | - feat(mcp): ✨ add CustomImage imageConfig support to manageFunctions for TCR→SCF deploy (#781) | - fix(mcp): 🔧 sync package-lock.json with package.json (#780) | - fix(issue-auto): 🤖 attempt fix for issue #771 (#776) | - fix(issue-auto): 🤖 attempt fix for issue #772 (#777) | - fix(issue-auto): 🤖 attempt fix for issue #773 (#778)\n\nArchive index:\n\nArchive v1.18.54: 2 files, 2651 bytes\n\nFiles: SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.54:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.35.0\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.54:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.54\",\n \"publishedAt\": 1791521943202\n}\n\nArchive v1.18.53: 3 files, 3530 bytes\n\nFiles: skill-card.md (1432b), SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.53:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.34.8\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.53:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.53\",\n \"publishedAt\": 1790775974093\n}\n\nFile v1.18.53:skill-card.md\n\n## Description:\n\nGuides medium-to-large software changes through confirmed requirements, technical design, and actionable tasks before implementation.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[binggg](https://clawhub.ai/user/binggg)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and teams use this skill to clarify acceptance criteria, agree on architecture, and plan traceable implementation tasks for complex changes.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The staged confirmation process may delay straightforward changes.\n\nMitigation: Use the full workflow for medium-to-large or ambiguous work; proceed directly for small, clearly scoped changes.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/binggg/skills/spec-workflow-guide)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Guidance]\n\n**Output Format:** [Markdown requirements, design, and task documents]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [EARS-style acceptance criteria and tasks traceable to requirements]\n\n## Skill Version(s):\n\n1.18.53 (source: ClawHub release)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.18.52: 3 files, 3572 bytes\n\nFiles: skill-card.md (1553b), SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.52:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.34.8\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.52:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.52\",\n \"publishedAt\": 1790748955260\n}\n\nFile v1.18.52:skill-card.md\n\n## Description:\n\nGuides developers through requirements, design, and task planning before implementing medium-to-large changes with unclear scope or complex architecture.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[binggg](https://clawhub.ai/user/binggg)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to turn complex feature requests into confirmed requirements, a technical design, and traceable implementation tasks before coding.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The staged planning process can slow larger changes before implementation begins.\n\nMitigation: Use the full workflow only when the change warrants it; review generated specs and confirm each phase before acting.\n\n## Reference(s):\n\n- [Spec Workflow Guide on ClawHub](https://clawhub.ai/binggg/skills/spec-workflow-guide)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Guidance]\n\n**Output Format:** [Markdown requirements, design, and task documents]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires user confirmation between planning phases and before implementation.]\n\n## Skill Version(s):\n\n1.18.52 (source: ClawHub release metadata; artifact frontmatter: 2.34.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.18.51: 3 files, 3751 bytes\n\nFiles: skill-card.md (1970b), SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.51:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.34.6\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.51:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.51\",\n \"publishedAt\": 1789997170631\n}\n\nFile v1.18.51:skill-card.md\n\n## Description:\n\nUse when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[binggg](https://clawhub.ai/user/binggg)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineering agents use this skill to structure medium-to-large or unclear software changes into requirements, design, task planning, and confirmed execution.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can slow larger coding tasks by routing them through requirements, design, and task-confirmation phases.\n\nMitigation: Use it for medium-to-large or unclear work, and skip the full workflow when the scope and acceptance criteria are already clear.\n\nRisk: The skill can create local spec Markdown files containing project requirements, design notes, and task plans.\n\nMitigation: Review generated spec files before implementation and avoid including secrets or sensitive business data unless the workspace is authorized for them.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/binggg/skills/spec-workflow-guide)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, markdown]\n\n**Output Format:** [Markdown planning documents and concise procedural guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May create requirements.md, design.md, and tasks.md under specs// when the workflow is used.]\n\n## Skill Version(s):\n\n1.18.51 (source: server release metadata; artifact frontmatter reports 2.34.6)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.18.50: 3 files, 3717 bytes\n\nFiles: skill-card.md (1941b), SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.50:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.34.5\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.50:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.50\",\n \"publishedAt\": 1789896564103\n}\n\nFile v1.18.50:skill-card.md\n\n## Description:\n\nUse when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[binggg](https://clawhub.ai/user/binggg)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to decide when a coding request needs structured requirements, design, task planning, and staged confirmation before implementation.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may add planning overhead to larger coding tasks and create specification files in the project.\n\nMitigation: Use the workflow for medium-to-large or ambiguous changes, and skip it for small, precise, low-risk edits.\n\nRisk: Specification guidance can produce incorrect or misleading requirements, designs, or task plans if accepted without review.\n\nMitigation: Review generated planning documents and confirm each phase before implementation.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/binggg/skills/spec-workflow-guide)\n- [Publisher profile](https://clawhub.ai/user/binggg)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown, Files]\n\n**Output Format:** [Markdown planning documents and concise workflow guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May create requirements.md, design.md, and tasks.md under a specs directory when the workflow applies.]\n\n## Skill Version(s):\n\n1.18.50 (source: ClawHub release metadata; source skill frontmatter: 2.34.5)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.18.49: 3 files, 3639 bytes\n\nFiles: skill-card.md (1770b), SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.49:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.34.4\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.49:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.49\",\n \"publishedAt\": 1789551311244\n}\n\nFile v1.18.49:skill-card.md\n\n## Description:\n\nUse when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[binggg](https://clawhub.ai/user/binggg)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and agents use this skill to decide when structured planning is warranted and to produce concise requirements, design, and task documents before implementation.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The workflow can slow larger work by requiring requirements, design, and task planning before coding.\n\nMitigation: Use it for medium-to-large or unclear changes, and skip the full workflow for small, precise fixes as the artifact instructs.\n\nRisk: The skill may create local planning files in a repository.\n\nMitigation: Review generated spec documents and require user confirmation before moving between planning phases or implementation.\n\n## Reference(s):\n\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Guidance]\n\n**Output Format:** [Markdown planning documents and concise agent guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May create local requirements, design, and task files after user confirmation.]\n\n## Skill Version(s):\n\n1.18.49 (source: server release metadata; artifact frontmatter reports 2.34.4)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.18.48: 3 files, 3757 bytes\n\nFiles: skill-card.md (2096b), SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.48:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.34.3\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.48:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.48\",\n \"publishedAt\": 1789362706766\n}\n\nFile v1.18.48:skill-card.md\n\n## Description:\n\nUse when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[binggg](https://clawhub.ai/user/binggg)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and coding agents use this skill to turn medium-to-large implementation requests into requirements, designs, and task plans before code changes begin. It is suited for multi-module changes, unclear acceptance criteria, architecture-heavy work, database planning, and UI-heavy workflows.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated requirements, designs, or task lists may contain incomplete or misleading planning guidance.\n\nMitigation: Review the planning documents and require user confirmation before moving from requirements to design, from design to tasks, and from tasks to implementation.\n\nRisk: The skill may cause the agent to create planning documents or pause for confirmations on larger tasks.\n\nMitigation: Use the workflow only for medium-to-large or unclear changes, and skip it for small, precise, low-risk work as documented by the skill.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/binggg/skills/spec-workflow-guide)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown planning documents and concise agent guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May produce requirements.md, design.md, and tasks.md planning artifacts when the full workflow is appropriate.]\n\n## Skill Version(s):\n\n1.18.48 (source: release metadata; artifact frontmatter version is 2.34.3)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.18.47: 3 files, 3670 bytes\n\nFiles: skill-card.md (1869b), SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.47:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.34.2\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.47:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.47\",\n \"publishedAt\": 1789317375702\n}\n\nFile v1.18.47:skill-card.md\n\n## Description:\n\nUse when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[binggg](https://clawhub.ai/user/binggg)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and coding agents use this skill to decide when a medium-to-large change needs a structured requirements, design, task planning, and confirmed execution workflow.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can add planning overhead to larger coding tasks by requiring a requirements, design, and task breakdown flow.\n\nMitigation: Use it for medium-to-large or ambiguous work, and skip the full workflow for small, low-risk tasks with clear acceptance criteria.\n\nRisk: The workflow creates local spec files and delays implementation until the task plan is confirmed.\n\nMitigation: Review the generated requirements, design, and tasks before authorizing execution.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/binggg/skills/spec-workflow-guide)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, markdown, configuration]\n\n**Output Format:** [Markdown planning documents and agent workflow guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces requirements.md, design.md, and tasks.md guidance for structured implementation planning.]\n\n## Skill Version(s):\n\n1.18.47 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.18.46: 3 files, 3843 bytes\n\nFiles: skill-card.md (2300b), SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.46:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.34.1\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.46:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.46\",\n \"publishedAt\": 1789315268423\n}\n\nFile v1.18.46:skill-card.md\n\n## Description:\n\nUse when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[binggg](https://clawhub.ai/user/binggg)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and agent operators use this skill to turn medium or large implementation requests into explicit requirements, technical design, and task plans before coding. It is most useful when scope, acceptance criteria, UI behavior, data modeling, or architecture decisions need staged confirmation.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The workflow can slow implementation by requiring requirements, design, task breakdown, and confirmation before coding.\n\nMitigation: Use it for medium-to-large or unclear changes, and skip the full workflow for small, low-risk tasks with clear acceptance criteria.\n\nRisk: Over-planning a small change can add unnecessary review overhead.\n\nMitigation: Apply the skill's decision rule before creating spec documents, and proceed directly when scope and acceptance criteria are already clear.\n\nRisk: Missing sibling skills can leave specialized UI or data-model planning guidance unavailable.\n\nMitigation: Install the full CloudBase plugin or the missing sibling skill before relying on referenced local skill files.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/binggg/skills/spec-workflow-guide)\n- [Publisher profile](https://clawhub.ai/user/binggg)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown documents and agent guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May produce requirements, design, and task-plan documents when the full workflow applies.]\n\n## Skill Version(s):\n\n1.18.46 (source: server release metadata; artifact frontmatter declares 2.34.1)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.18.45: 3 files, 3770 bytes\n\nFiles: skill-card.md (2037b), SKILL.md (5145b), _meta.json (140b)\n\nFile v1.18.45:SKILL.md\n\n---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.34.0\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user explicitly wants a direct code change with no planning phase\n\n## Core workflow\n\n### Phase 1: Requirements\n\nCreate `specs//requirements.md`.\n\nWhat to do:\n\n- Restate the problem and scope\n- Write user stories\n- Write acceptance criteria in EARS style\n- Clarify business rules, constraints, and non-goals\n\nEARS pattern:\n\n```text\nWhile , when , the shall \n```\n\nExample:\n\n```text\nWhen the user submits the form, the booking system shall validate required fields before creating the record.\n```\n\n### Phase 2: Design\n\nCreate `specs//design.md`.\n\nWhat to do:\n\n- Describe architecture and module boundaries\n- Explain technology choices and trade-offs\n- Define data model, API, security, and testing strategy as needed\n- Use Mermaid only when a diagram materially improves clarity\n\n### Phase 3: Tasks\n\nCreate `specs//tasks.md`.\n\nWhat to do:\n\n- Break the design into executable tasks\n- Keep tasks specific and reviewable\n- Link each task back to the relevant requirement\n- Update task status as work progresses\n\nTask format:\n\n```markdown\n# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1\n```\n\n### Phase 4: Execution\n\nOnly start implementation after the user confirms the task plan.\n\nDuring execution:\n\n- Keep task status current\n- Finish one meaningful unit at a time\n- Preserve traceability from change -> task -> requirement\n\n## Working rules for the agent\n\n1. Ask follow-up questions when the request is underspecified; do not guess core product behavior.\n2. Require confirmation between requirements, design, and task breakdown.\n3. Pull in `ui-design` early when the change includes end-user pages or visual decisions.\n4. Keep documents concise but testable.\n5. Prefer user-visible outcomes over implementation-detail task names.\n\n## Output expectations\n\n- `requirements.md` -> problem, scope, user stories, EARS acceptance criteria\n- `design.md` -> architecture, technical approach, data/API/security/test notes\n- `tasks.md` -> actionable implementation checklist tied to requirements\n\nFile v1.18.45:_meta.json\n\n{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.45\",\n \"publishedAt\": 1789311052651\n}\n\nFile v1.18.45:skill-card.md\n\n## Description:\n\nUse when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[binggg](https://clawhub.ai/user/binggg)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineering agents use this skill to decide when a larger change needs explicit requirements, design, and implementation tasks before coding. It guides creation of structured Markdown spec documents with user stories, EARS-style acceptance criteria, architecture notes, and task checklists.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill adds planning steps and can create requirements, design, and task documents that may shape later implementation work.\n\nMitigation: Review the generated spec documents before approving implementation.\n\nRisk: For small, low-risk changes, unnecessary use of the full workflow can slow direct execution.\n\nMitigation: Apply the skill's decision rule and skip the full workflow when scope and acceptance criteria are already clear.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/binggg/skills/spec-workflow-guide)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Files, Guidance]\n\n**Output Format:** [Markdown documents and concise agent guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May produce specs//requirements.md, specs//design.md, and specs//tasks.md after appropriate user confirmation.]\n\n## Skill Version(s):\n\n1.18.45 (source: ClawHub release metadata; artifact frontmatter declares 2.34.0)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.","readmeExcerpt":"Skill: 需求与设计流程 · Spec Workflow Owner: binggg Summary: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests. Tags: latest:1.18.54 Version history: v1.18.54 | 2026-10-09T04:59:03.202Z | user Recent commits / 最近提交: | - feat(mcp): retire MySQL provisioning from t","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"While , when , the shall "},{"language":"text","snippet":"When the user submits the form, the booking system shall validate required fields before creating the record."},{"language":"markdown","snippet":"# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1"},{"language":"text","snippet":"While , when , the shall "},{"language":"text","snippet":"When the user submits the form, the booking system shall validate required fields before creating the record."},{"language":"markdown","snippet":"# Implementation Plan\n\n- [ ] 1. Task title\n - Specific work item\n - Another concrete step\n - _Requirement: 1"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: spec-workflow-guide\ndescription: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests.\nversion: 2.35.0\nalwaysApply: false\n---\n\n## Sibling skills (local only)\n\nSibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.\n\nIf a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.\n\n# Spec Workflow\n\n## Activation Contract\n\n### Use this first when\n\n- The request is a new feature, multi-step product change, cross-module integration, or architecture/design task.\n- Acceptance criteria are unclear and need to be made explicit before implementation.\n- The work involves multiple files, user flows, database design, or UI design that needs staged confirmation.\n\n### Read before writing code if\n\n- You are unsure whether the task should go straight to coding or should first go through requirements, design, and task planning.\n- The request mentions a new page, a new system, a redesign, a workflow, or a multi-module refactor.\n\n### Then also read\n\n- Frontend page or visual design work -> `../ui-design/SKILL.md`\n- Advanced data-model work -> `../data-model-creation/SKILL.md`\n\n### Do NOT use for\n\n- Small bug fixes with clear scope.\n- One-file documentation updates.\n- Straightforward config changes.\n- Tiny refactors where the user already gave exact implementation instructions.\n\n### Common mistakes / gotchas\n\n- Jumping into coding before acceptance criteria are explicit.\n- Skipping user confirmation between requirements, design, and tasks.\n- Writing vague tasks that do not map back to user-visible outcomes.\n- Treating UI work as purely technical implementation without clarifying design intent.\n\n### Minimal checklist\n\n- Decide whether the change really needs the full spec flow.\n- If yes, stop and produce requirements first.\n- If the change is small, low-risk, and acceptance is already clear, allow direct execution without forcing spec artifacts.\n- Use EARS-style acceptance criteria.\n- Get confirmation before moving to the next phase.\n\n## When to use this skill\n\nUse this workflow for structured development when you need to:\n\n- Define or refine a new feature\n- Design complex architecture\n- Coordinate changes across modules\n- Plan database or UI-heavy work\n- Improve requirement quality and acceptance boundaries\n\n## Decision rule\n\n### Use the full workflow when\n\n- The task is medium or large\n- The impact spans multiple modules\n- Acceptance boundaries are fuzzy\n- The user wants disciplined planning before implementation\n\n### Skip the full workflow when\n\n- The task is small, low-risk, and already precise\n- Goal, scope, and acceptance are already clear enough to execute directly\n- The user e"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7emfp36dbn1xx4fz4s5q4a6180439j\",\n \"slug\": \"spec-workflow-guide\",\n \"version\": \"1.18.54\",\n \"publishedAt\": 1791521943202\n}"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests. Skill: 需求与设计流程 · Spec Workflow Owner: binggg Summary: Use when medium-to-large changes need explicit requirements, technical design, and task planning before implementation, especially for multi-module work, unclear acceptance criteria, or architecture-heavy requests. Tags: latest:1.18.54 Version history: v1.18.54 | 2026-10-09T04:59:03.202Z | user Recent commits / 最近提交: | - feat(mcp): retire MySQL provisioning from t","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1206,"uniquenessScore":48,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T05:00:42.130Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T05:00:42.130Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-09T08:19:32.234Z","emptyReason":null},"items":[{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-10T18:48:31.762Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}