{ "schemaVersion": "1.0", "item": { "slug": "solo-scaffold", "name": "Scaffold", "source": "tencent", "type": "skill", "category": "开发工具", "sourceUrl": "https://clawhub.ai/fortunto2/solo-scaffold", "canonicalUrl": "https://clawhub.ai/fortunto2/solo-scaffold", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/solo-scaffold", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=solo-scaffold", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md", "references/stack-structures.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-05-07T17:22:31.273Z", "expiresAt": "2026-05-14T17:22:31.273Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-annual-report", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-annual-report", "contentDisposition": "attachment; filename=\"afrexai-annual-report-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/solo-scaffold" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/solo-scaffold", "agentPageUrl": "https://openagent3.xyz/skills/solo-scaffold/agent", "manifestUrl": "https://openagent3.xyz/skills/solo-scaffold/agent.json", "briefUrl": "https://openagent3.xyz/skills/solo-scaffold/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "/scaffold", "body": "Scaffold a complete project from PRD + stack template. Creates directory structure, configs, CLAUDE.md, git repo, and pushes to GitHub. Studies existing projects via SoloGraph for consistent patterns, uses Context7 for latest library versions." }, { "title": "Steps", "body": "Parse arguments from $ARGUMENTS — extract and .\n\nIf not provided or incomplete, use AskUserQuestion to ask for missing values.\nShow available stacks from templates/stacks/*.yaml (source of truth).\nIf MCP project_info available, also show detected stacks from active projects.\nList stack names with one-line descriptions from each YAML's description field.\nProject name should be kebab-case.\n\n\n\nLoad org defaults from ~/.solo-factory/defaults.yaml:\n\nRead org_domain (e.g. com.mycompany), apple_dev_team, github_org, projects_dir\nIf file doesn't exist, ask via AskUserQuestion:\n\n\"What is your reverse-domain prefix for bundle IDs?\" (e.g. com.mycompany)\n\"Apple Developer Team ID?\" (optional, leave empty if no iOS)\n\n\nCreate ~/.solo-factory/defaults.yaml with answers for future runs\nReplace , , placeholders in all generated files\n\n\n\nLoad stack + PRD + principles:\n\nLook for stack YAML: search for stacks/.yaml in plugin templates (via kb_search or Glob).\nIf stack YAML not found, use built-in knowledge of the stack (packages, structure, deploy).\nCheck if PRD exists: docs/prd.md or search current directory for prd.md\n\nIf not: generate a basic PRD template\n\n\nLook for dev principles: search for dev-principles.md or use built-in SOLID/DRY/KISS/TDD principles.\n\n\n\nStudy existing projects via SoloGraph (learn from your own codebase — critically):\nBefore generating code, study active projects with the same stack. Don't blindly copy — existing projects may have legacy patterns or mistakes. Evaluate what's actually useful.\na. Find sibling projects — use project_info() to list active projects, filter by matching stack.\nExample: for ios-swift, find existing projects with matching stack.\nb. Architecture overview — codegraph_explain(project=\"\") for each sibling.\nGives: directory layers, key patterns (base classes, protocols, CRUD), top dependencies, hub files.\nc. Search for reusable patterns — project_code_search(query=\"\", project=\"\"):\n\nSearch for stack-specific patterns: \"MVVM ViewModel\", \"SwiftData model\", \"AVFoundation recording\"\nSearch for shared infrastructure: \"Makefile\", \"project.yml\", \".swiftlint.yml\"\nSearch for services: \"Service protocol\", \"actor service\"\n\nd. Check shared packages — codegraph_query(\"MATCH (p:Project)-[:DEPENDS_ON]->(pkg:Package) WHERE p.name = '' RETURN pkg.name\").\nCollect package versions for reference (but verify with Context7 for latest).\ne. Critically evaluate what to adopt vs skip:\n\nAdopt: consistent directory structure, Makefile targets, config patterns (.swiftlint.yml, project.yml)\nAdopt: proven infrastructure patterns (actor services, protocol-based DIP)\nSkip if outdated: old API patterns (ObservableObject → @Observable), deprecated deps\nSkip if overcomplicated: unnecessary abstractions, patterns that don't fit the new project's needs\nAlways prefer: Context7 latest best practices over old project patterns when they conflict\n\nGoal: Generated code should feel consistent with your portfolio but use the best available patterns, not just the same old ones.\nLimit to 2-3 sibling projects to keep research focused.\n\n\nContext7 research (latest library versions and best practices):\n\nFor each key package from the stack:\n\nmcp__context7__resolve-library-id — find the Context7 library ID\nmcp__context7__query-docs — query \"latest version, project setup, recommended file structure, best practices\"\n\n\nCollect: current versions, recommended directory structure, configuration patterns, setup commands\nLimit to the 3-4 most important packages to keep research focused\n\n\n\nShow plan + get confirmation via AskUserQuestion:\n\nProject path: / (from defaults.yaml or current directory)\nStack name and key packages with versions from Context7\nProposed directory structure\nConfirm or adjust before creating files\n\n\n\nCreate project directory:\nmkdir -p /\n\n\n\nCreate file structure based on the stack. SGR-first: always start with domain schemas/models before any logic or views. Every project gets these common files:\n//\n├── CLAUDE.md # AI-friendly project docs (map, not manual — see Harness Engineering)\n├── Makefile # Common commands (run, test, build, lint, deploy, integration)\n├── README.md # Human-friendly project docs\n├── docs/\n│ ├── prd.md # Copy of PRD\n│ ├── QUALITY_SCORE.md # Domain quality grades (harness: garbage collection)\n│ └── ARCHITECTURE.md # Module boundaries and dependency rules\n├── cli/ # CLI utility — mirrors core business logic (CLI-First Testing principle)\n│ └── main.ts|py # Deterministic pipeline entry point (no LLM required)\n├── .claude/\n│ └── skills/ # Product-specific workflow skills\n│ └── dev/\n│ └── SKILL.md # Dev workflow skill (run, test, deploy)\n└── .gitignore # Stack-specific ignores\n\nCLI-First Testing: generate a cli/ directory with a stub that imports core business logic from lib/ (or equivalent). The CLI should run the main pipeline deterministically without requiring LLM, network, or UI. This enables make integration for pipeline verification. See dev-principles.md → \"CLI-First Testing\".\n.claude/skills/dev/SKILL.md — product dev workflow skill\nGenerate a skill that teaches Claude how to work with THIS specific project. Structure:\n---\nname: -dev\ndescription: Dev workflow for — run, test, build, deploy. Use when working on features, fixing bugs, or deploying changes. Do NOT use for other projects.\nlicense: MIT\nmetadata:\n author: \n version: \"1.0.0\"\nallowed-tools: Read, Grep, Glob, Bash, Write, Edit\n---\n\nBody should include:\n\nStack: key packages, versions, where configs live\nCommands: make dev, make test, make build, make deploy (from Makefile)\nArchitecture: directory structure, naming conventions, key patterns\nTesting: how to run tests, where test files live, testing conventions\nCommon tasks: add a new page/screen, add an API endpoint, add a model\n\nThis makes every scaffolded project immediately Claude-friendly — new sessions get project context via the skill.\nMCP server (optional): If PRD indicates a data/AI/developer product, also generate MCP server stub.\nSee templates/mcp-skills-bundle.md for the full \"MCP + Skills bundle\" pattern and rules for when to generate MCP.\nThen add stack-specific files. See references/stack-structures.md for per-stack file listings (8 stacks: nextjs, ios, kotlin, cloudflare, astro-static, astro-hybrid, python-api, python-ml).\n\n\nGenerate Makefile — stack-adapted with: help, dev, test, lint, format, build, clean, deploy targets.\n\nAdd integration target if the project has a CLI or deterministic pipeline (stub with a comment if not yet implemented)\nios-swift must also include: generate (xcodegen), archive (xcodebuild archive), open (open .xcarchive for Distribute)\nThe Makefile is the canonical command interface — /build and /review use make targets instead of raw commands\n\n\n\nGenerate CLAUDE.md for the new project:\n\nProject overview (problem/solution from PRD)\nTech stack (packages + versions from Context7)\nSkills section: list available .claude/skills/ with descriptions\nDirectory structure\nCommon commands (reference make help)\nSGR / Domain-First section\nArchitecture principles (from dev-principles)\nHarness Engineering section (from templates/principles/harness-engineering.md):\n\nCLAUDE.md philosophy: \"this file is a map, not a manual — keep ~100 lines, point to docs/\"\nHarness health checklist (subset relevant to this project)\nArchitectural constraints: module boundaries, data validation at boundaries\nAgent legibility: lint errors must include remediation instructions\nAnti-patterns: don't put knowledge in Slack/Docs, don't micromanage implementation\n\n\nDo/Don't sections\nMCP Integration section (optional, if MCP tools available):\nLists available MCP tools: project_code_search, kb_search, session_search, codegraph_query, project_info, web_search\n\nGenerate README.md — project name, description, prerequisites, setup, run/test/deploy.\n\n\nGenerate .gitignore — stack-specific patterns.\n\n\nCopy PRD to docs/: Copy from knowledge base or generate in place.\n\n\nGit init + first commit:\ncd /\ngit init && git add . && git commit -m \"Initial project scaffold\n\nStack: \nGenerated by /scaffold\"\n\n\n\nCreate GitHub private repo + push:\ncd /\ngh repo create --private --source=. --push\n\n\n\nRegister project + index code (optional, if MCP tools available):\n\nIf project_code_reindex MCP tool is available, index the new project for code search:\nmcp__solograph__project_code_reindex(project=\"\")\n\n\n\n\n\nOutput summary:\nProject scaffolded!\n\n Path: /\n GitHub: https://github.com//\n Stack: \n PRD: docs/prd.md\n CLAUDE: configured\n Skills: .claude/skills/dev/ (project workflow)\n\nNext steps:\n cd /\n # pnpm install / uv sync / etc.\n # pnpm dev / uv run ... / etc.\n\nThen: /setup → /plan \"First feature\" → /build" }, { "title": ".claude/skills/dev/SKILL.md — product dev workflow skill", "body": "Generate a skill that teaches Claude how to work with THIS specific project. Structure:\n\n---\nname: -dev\ndescription: Dev workflow for — run, test, build, deploy. Use when working on features, fixing bugs, or deploying changes. Do NOT use for other projects.\nlicense: MIT\nmetadata:\n author: \n version: \"1.0.0\"\nallowed-tools: Read, Grep, Glob, Bash, Write, Edit\n---\n\nBody should include:\n\nStack: key packages, versions, where configs live\nCommands: make dev, make test, make build, make deploy (from Makefile)\nArchitecture: directory structure, naming conventions, key patterns\nTesting: how to run tests, where test files live, testing conventions\nCommon tasks: add a new page/screen, add an API endpoint, add a model\n\nThis makes every scaffolded project immediately Claude-friendly — new sessions get project context via the skill.\n\nMCP server (optional): If PRD indicates a data/AI/developer product, also generate MCP server stub.\nSee templates/mcp-skills-bundle.md for the full \"MCP + Skills bundle\" pattern and rules for when to generate MCP.\n\nThen add stack-specific files. See references/stack-structures.md for per-stack file listings (8 stacks: nextjs, ios, kotlin, cloudflare, astro-static, astro-hybrid, python-api, python-ml)." }, { "title": "Verification", "body": "Before reporting \"project scaffolded\":\n\nVerify all generated files exist (ls the directory tree).\nRun the install command (pnpm install, uv sync, etc.) — must succeed.\nRun the dev/build command if applicable — must not error.\nVerify git init + first commit succeeded (git log --oneline -1).\nVerify GitHub repo creation (gh repo view or check URL).\n\nNever say \"scaffold complete\" without running the install and verifying it works." }, { "title": "Stack YAML not found", "body": "Cause: Stack template missing from templates/stacks/ or not symlinked.\nFix: Skill uses built-in knowledge if template not found. To fix: ensure solo-factory/templates/stacks/.yaml exists." }, { "title": "GitHub repo creation fails", "body": "Cause: gh CLI not authenticated or repo name already taken.\nFix: Run gh auth login first. If name taken, choose a different project name." }, { "title": "Context7 queries fail", "body": "Cause: MCP server not running or Context7 rate limited.\nFix: Skill proceeds with stack YAML versions as fallback. Context7 enhances but is not required." }, { "title": "org defaults missing", "body": "Cause: ~/.solo-factory/defaults.yaml not created.\nFix: Run /init first for one-time setup, or skill will ask for bundle ID and team ID interactively." } ], "body": "/scaffold\n\nScaffold a complete project from PRD + stack template. Creates directory structure, configs, CLAUDE.md, git repo, and pushes to GitHub. Studies existing projects via SoloGraph for consistent patterns, uses Context7 for latest library versions.\n\nSteps\n\nParse arguments from $ARGUMENTS — extract and .\n\nIf not provided or incomplete, use AskUserQuestion to ask for missing values.\nShow available stacks from templates/stacks/*.yaml (source of truth). If MCP project_info available, also show detected stacks from active projects. List stack names with one-line descriptions from each YAML's description field.\nProject name should be kebab-case.\n\nLoad org defaults from ~/.solo-factory/defaults.yaml:\n\nRead org_domain (e.g. com.mycompany), apple_dev_team, github_org, projects_dir\nIf file doesn't exist, ask via AskUserQuestion:\n\"What is your reverse-domain prefix for bundle IDs?\" (e.g. com.mycompany)\n\"Apple Developer Team ID?\" (optional, leave empty if no iOS)\nCreate ~/.solo-factory/defaults.yaml with answers for future runs\nReplace , , placeholders in all generated files\n\nLoad stack + PRD + principles:\n\nLook for stack YAML: search for stacks/.yaml in plugin templates (via kb_search or Glob).\nIf stack YAML not found, use built-in knowledge of the stack (packages, structure, deploy).\nCheck if PRD exists: docs/prd.md or search current directory for prd.md\nIf not: generate a basic PRD template\nLook for dev principles: search for dev-principles.md or use built-in SOLID/DRY/KISS/TDD principles.\n\nStudy existing projects via SoloGraph (learn from your own codebase — critically):\n\nBefore generating code, study active projects with the same stack. Don't blindly copy — existing projects may have legacy patterns or mistakes. Evaluate what's actually useful.\n\na. Find sibling projects — use project_info() to list active projects, filter by matching stack. Example: for ios-swift, find existing projects with matching stack.\n\nb. Architecture overview — codegraph_explain(project=\"\") for each sibling. Gives: directory layers, key patterns (base classes, protocols, CRUD), top dependencies, hub files.\n\nc. Search for reusable patterns — project_code_search(query=\"\", project=\"\"):\n\nSearch for stack-specific patterns: \"MVVM ViewModel\", \"SwiftData model\", \"AVFoundation recording\"\nSearch for shared infrastructure: \"Makefile\", \"project.yml\", \".swiftlint.yml\"\nSearch for services: \"Service protocol\", \"actor service\"\n\nd. Check shared packages — codegraph_query(\"MATCH (p:Project)-[:DEPENDS_ON]->(pkg:Package) WHERE p.name = '' RETURN pkg.name\"). Collect package versions for reference (but verify with Context7 for latest).\n\ne. Critically evaluate what to adopt vs skip:\n\nAdopt: consistent directory structure, Makefile targets, config patterns (.swiftlint.yml, project.yml)\nAdopt: proven infrastructure patterns (actor services, protocol-based DIP)\nSkip if outdated: old API patterns (ObservableObject → @Observable), deprecated deps\nSkip if overcomplicated: unnecessary abstractions, patterns that don't fit the new project's needs\nAlways prefer: Context7 latest best practices over old project patterns when they conflict\n\nGoal: Generated code should feel consistent with your portfolio but use the best available patterns, not just the same old ones. Limit to 2-3 sibling projects to keep research focused.\n\nContext7 research (latest library versions and best practices):\n\nFor each key package from the stack:\nmcp__context7__resolve-library-id — find the Context7 library ID\nmcp__context7__query-docs — query \"latest version, project setup, recommended file structure, best practices\"\nCollect: current versions, recommended directory structure, configuration patterns, setup commands\nLimit to the 3-4 most important packages to keep research focused\n\nShow plan + get confirmation via AskUserQuestion:\n\nProject path: / (from defaults.yaml or current directory)\nStack name and key packages with versions from Context7\nProposed directory structure\nConfirm or adjust before creating files\n\nCreate project directory:\n\nmkdir -p /\n\n\nCreate file structure based on the stack. SGR-first: always start with domain schemas/models before any logic or views. Every project gets these common files:\n\n//\n├── CLAUDE.md # AI-friendly project docs (map, not manual — see Harness Engineering)\n├── Makefile # Common commands (run, test, build, lint, deploy, integration)\n├── README.md # Human-friendly project docs\n├── docs/\n│ ├── prd.md # Copy of PRD\n│ ├── QUALITY_SCORE.md # Domain quality grades (harness: garbage collection)\n│ └── ARCHITECTURE.md # Module boundaries and dependency rules\n├── cli/ # CLI utility — mirrors core business logic (CLI-First Testing principle)\n│ └── main.ts|py # Deterministic pipeline entry point (no LLM required)\n├── .claude/\n│ └── skills/ # Product-specific workflow skills\n│ └── dev/\n│ └── SKILL.md # Dev workflow skill (run, test, deploy)\n└── .gitignore # Stack-specific ignores\n\n\nCLI-First Testing: generate a cli/ directory with a stub that imports core business logic from lib/ (or equivalent). The CLI should run the main pipeline deterministically without requiring LLM, network, or UI. This enables make integration for pipeline verification. See dev-principles.md → \"CLI-First Testing\".\n\n.claude/skills/dev/SKILL.md — product dev workflow skill\n\nGenerate a skill that teaches Claude how to work with THIS specific project. Structure:\n\n---\nname: -dev\ndescription: Dev workflow for — run, test, build, deploy. Use when working on features, fixing bugs, or deploying changes. Do NOT use for other projects.\nlicense: MIT\nmetadata:\n author: \n version: \"1.0.0\"\nallowed-tools: Read, Grep, Glob, Bash, Write, Edit\n---\n\n\nBody should include:\n\nStack: key packages, versions, where configs live\nCommands: make dev, make test, make build, make deploy (from Makefile)\nArchitecture: directory structure, naming conventions, key patterns\nTesting: how to run tests, where test files live, testing conventions\nCommon tasks: add a new page/screen, add an API endpoint, add a model\n\nThis makes every scaffolded project immediately Claude-friendly — new sessions get project context via the skill.\n\nMCP server (optional): If PRD indicates a data/AI/developer product, also generate MCP server stub. See templates/mcp-skills-bundle.md for the full \"MCP + Skills bundle\" pattern and rules for when to generate MCP.\n\nThen add stack-specific files. See references/stack-structures.md for per-stack file listings (8 stacks: nextjs, ios, kotlin, cloudflare, astro-static, astro-hybrid, python-api, python-ml).\n\nGenerate Makefile — stack-adapted with: help, dev, test, lint, format, build, clean, deploy targets.\n\nAdd integration target if the project has a CLI or deterministic pipeline (stub with a comment if not yet implemented)\nios-swift must also include: generate (xcodegen), archive (xcodebuild archive), open (open .xcarchive for Distribute)\nThe Makefile is the canonical command interface — /build and /review use make targets instead of raw commands\n\nGenerate CLAUDE.md for the new project:\n\nProject overview (problem/solution from PRD)\nTech stack (packages + versions from Context7)\nSkills section: list available .claude/skills/ with descriptions\nDirectory structure\nCommon commands (reference make help)\nSGR / Domain-First section\nArchitecture principles (from dev-principles)\nHarness Engineering section (from templates/principles/harness-engineering.md):\nCLAUDE.md philosophy: \"this file is a map, not a manual — keep ~100 lines, point to docs/\"\nHarness health checklist (subset relevant to this project)\nArchitectural constraints: module boundaries, data validation at boundaries\nAgent legibility: lint errors must include remediation instructions\nAnti-patterns: don't put knowledge in Slack/Docs, don't micromanage implementation\nDo/Don't sections\nMCP Integration section (optional, if MCP tools available): Lists available MCP tools: project_code_search, kb_search, session_search, codegraph_query, project_info, web_search\n\nGenerate README.md — project name, description, prerequisites, setup, run/test/deploy.\n\nGenerate .gitignore — stack-specific patterns.\n\nCopy PRD to docs/: Copy from knowledge base or generate in place.\n\nGit init + first commit:\n\ncd /\ngit init && git add . && git commit -m \"Initial project scaffold\n\nStack: \nGenerated by /scaffold\"\n\n\nCreate GitHub private repo + push:\n\ncd /\ngh repo create --private --source=. --push\n\n\nRegister project + index code (optional, if MCP tools available):\n\nIf project_code_reindex MCP tool is available, index the new project for code search:\nmcp__solograph__project_code_reindex(project=\"\")\n\n\nOutput summary:\n\nProject scaffolded!\n\n Path: /\n GitHub: https://github.com//\n Stack: \n PRD: docs/prd.md\n CLAUDE: configured\n Skills: .claude/skills/dev/ (project workflow)\n\nNext steps:\n cd /\n # pnpm install / uv sync / etc.\n # pnpm dev / uv run ... / etc.\n\nThen: /setup → /plan \"First feature\" → /build\n\nVerification\n\nBefore reporting \"project scaffolded\":\n\nVerify all generated files exist (ls the directory tree).\nRun the install command (pnpm install, uv sync, etc.) — must succeed.\nRun the dev/build command if applicable — must not error.\nVerify git init + first commit succeeded (git log --oneline -1).\nVerify GitHub repo creation (gh repo view or check URL).\n\nNever say \"scaffold complete\" without running the install and verifying it works.\n\nCommon Issues\nStack YAML not found\n\nCause: Stack template missing from templates/stacks/ or not symlinked. Fix: Skill uses built-in knowledge if template not found. To fix: ensure solo-factory/templates/stacks/.yaml exists.\n\nGitHub repo creation fails\n\nCause: gh CLI not authenticated or repo name already taken. Fix: Run gh auth login first. If name taken, choose a different project name.\n\nContext7 queries fail\n\nCause: MCP server not running or Context7 rate limited. Fix: Skill proceeds with stack YAML versions as fallback. Context7 enhances but is not required.\n\norg defaults missing\n\nCause: ~/.solo-factory/defaults.yaml not created. Fix: Run /init first for one-time setup, or skill will ask for bundle ID and team ID interactively." }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/fortunto2/solo-scaffold", "publisherUrl": "https://clawhub.ai/fortunto2/solo-scaffold", "owner": "fortunto2", "version": "1.5.1", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/solo-scaffold", "downloadUrl": "https://openagent3.xyz/downloads/solo-scaffold", "agentUrl": "https://openagent3.xyz/skills/solo-scaffold/agent", "manifestUrl": "https://openagent3.xyz/skills/solo-scaffold/agent.json", "briefUrl": "https://openagent3.xyz/skills/solo-scaffold/agent.md" } }