[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M718SBVB1SYRG6Z15422162M":3,"skill-same:01M718SBVB1SYRG6Z15422162M":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":6,"updatedAt":51,"install":52,"resources":65},"01M718SBVB1SYRG6Z15422162M","project-setup",null,"Prepare or repair a project's Dev Container configuration for Graftty remote worktrees, and verify its build, test, resource, and authentication requirements. Use for project environment setup, not for provisioning cloud machines.","btucker\u002Fgraftty","btucker","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6181?v=4","01M718RRE00PW0CG044W7CPC35","Ben Tucker","01M718RRF1B2D0WH71867N2DP1",6,"MIT","https:\u002F\u002Fgithub.com\u002Fbtucker\u002Fgraftty\u002Fblob\u002Fmain\u002FSources\u002FGrafttyKit\u002FAgentPlugins\u002Fcodex\u002Fplugins\u002Fgraftty\u002Fskills\u002Fproject-setup\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"setup","project","project setup","graftty","test","for","environment setup","remote","dev container","requirements","repair","build","worktrees","container","use","environment","verify","provisioning","dev","authentication","2026-11-10 10:12:30",false,"---\nname: project-setup\ndescription: Prepare or repair a project's Dev Container configuration for Graftty remote worktrees, and verify its build, test, resource, and authentication requirements. Use for project environment setup, not for provisioning cloud machines.\n---\n\n# Project setup\n\nProduce version-controlled configuration that lets a new worktree prepare its development environment on demand. Use the existing Dev Container CLI and the project's own setup commands. Keep user-specific AWS profiles, instance pools, and preferred instance types out of the repository.\n\nInspect the repository's instructions, CI, dependency locks, existing `.devcontainer` configuration, and build scripts. Preserve a working setup. Identify which tasks require macOS and which can run on Linux. Do not represent a Linux container as capable of running Xcode or Apple-only tests.\n\nUse the [Dev Container specification](https:\u002F\u002Fcontainers.dev\u002Fimplementors\u002Fjson_reference\u002F) for configuration and the [Dev Container CLI](https:\u002F\u002Fgithub.com\u002Fdevcontainers\u002Fcli) for execution. Check the installed CLI's version and command help before relying on flags. Graftty's placement command creates a host worktree by default. `graftty remote placement create --dev-container` explicitly prepares an image or Dockerfile environment and opens its shell; `--dev-container-config` selects a configuration inside the new worktree. Explicit `--skill-revision` selections install staged skills, and `--agent codex` or `--agent claude` launches an installed native runtime with a matching revision. Managed placements retain their private agent profiles on the host when containers are removed. Compose placement, automatic profile refresh, session replication, and automatic recovery remain pending.\n\nSkill installation requires POSIX shell utilities, `base64`, and `diff` in the container. Publishing missing project skill directories also requires GNU `mv` or `gmv` with verified `-T --no-clobber` behavior. Install GNU coreutils in images that need project skill publication. User-only skills and identical existing project skills do not require that mover. Configure the container remote user to match the Linux host user's UID for the private profile mount. Profile retention does not establish a parent backup or authenticate the agent to its model service.\n\n## Configure the project\n\nCreate or repair `.devcontainer\u002Fdevcontainer.json` or the repository's existing supported configuration. Use a Dockerfile, Compose services, or Features only where the project needs them. Follow the project's established dependency versions and lockfiles. Make setup repeatable when a second worktree arrives on an already-used host.\n\nRecord required CPU, memory, and storage with standard `hostRequirements` properties where applicable. Document supported CPU architectures and measured resource requirements alongside the configuration. Separate requirements from unmeasured estimates. A suggested instance type is a user preference, not a project requirement.\n\nGive each worktree its own mutable environment. Check for fixed Compose project names, container names, host ports, database directories, and writable volumes that could cause different worktrees or projects to share state accidentally. Share image layers and suitable dependency caches without sharing mutable project data.\n\nLifecycle commands execute project code, sometimes on the host. Inspect the configuration, Features, Dockerfile, Compose files, and setup scripts before executing them. Preserve the user's authorized scope. Document any required privileged access or host service dependency rather than adding it incidentally.\n\nDo not copy or mount SSH private keys, AWS credential files, Git credential stores, agent authentication stores, or a user's entire home into the environment. Do not enable automatic credential forwarding. Document independent login requirements for private registries, packages, Git remotes, Claude, and Codex. Existing credentials may be used where independently configured; do not print their contents in verification output.\n\nDocument required MCP server IDs and whether each tool must operate on the Linux checkout or on the parent Mac. Explicit parent-proxied stdio MCP access is available through `graftty remote mcp connect` on the parent and placement `--mcp-grants \u003Cfile>` with selected skill revisions. Follow the remote-host skill for that setup and its scoped bridge requirements. Upstream authentication stays on the parent; project configuration must not contain tokens or private credential references. Automatic grant creation, HTTP servers, and app connector authentication adapters remain pending. MCP access and the agent runtime's model-service login are separate prerequisites.\n\n## Verify worktree behavior\n\nCheck Git metadata access inside the container. A linked worktree's `.git` file points outside its checkout; merely mounting the checkout can leave `git status` broken. Inspect `git rev-parse --git-common-dir` and the existing worktree layout before choosing mounts.\n\nThe upstream CLI supports `--mount-git-worktree-common-dir` for relative Git worktrees. Check the installed command help and verify that the worktree uses the compatible relative layout before using it. Both host and container Git must support the relative-worktree repository extension. Do not silently rewrite existing Git worktree metadata or mount a whole parent home directory as a shortcut. If an existing absolute layout needs another mounting arrangement, document the exact Git metadata directory and verify access without bringing unrelated files into the container.\n\nUse an existing worktree for verification. If a second worktree is needed, follow Graftty's worktree coordination workflow through the graftty-team skill. Do not create an agent workspace with `git worktree add` directly.\n\nRun the CLI against the actual workspace and selected configuration. For a default configuration in an ordinary checkout, the basic sequence is:\n\n```sh\ndevcontainer read-configuration --workspace-folder \"$project_workspace\"\ndevcontainer up --workspace-folder \"$project_workspace\"\ndevcontainer exec --workspace-folder \"$project_workspace\" git status --short\n```\n\nSet `project_workspace` to the absolute checkout path. Add supported configuration and Git worktree options consistently to the commands that need them. Wait for successful process exit and completion of required lifecycle commands. A running container or an early success JSON record does not prove that setup or project verification finished.\n\nRun the repository's documented build, test, and development-start commands with `devcontainer exec`. Verify the expected listening port and writable paths. Check two worktrees for port, volume, and Compose-name collisions when that verification is available and authorized. Test each architecture you claim to support; report untested architectures explicitly.\n\nIf Docker, the CLI, an architecture, credentials, or another prerequisite is unavailable, finish the reviewable configuration and list the exact verification still needed. Do not call the environment ready based only on a valid JSON document or a successful image build.\n\n## Leave useful project guidance\n\nUpdate the existing developer documentation or add a short `.devcontainer\u002FREADME.md` with the supported platform and architecture, setup and verification commands, resource estimates, worktree isolation choices, and independent authentication prerequisites. Include what was actually tested and any remaining incompatibility.\n\nCommit the project configuration and documentation through the repository's normal workflow. This skill does not launch AWS instances, choose a user's account settings, publish images, move credentials, or claim that parent replication and Spot recovery have been configured.\n","# Project setup\n\nProduce version-controlled configuration that lets a new worktree prepare its development environment on demand. Use the existing Dev Container CLI and the project's own setup commands. Keep user-specific AWS profiles, instance pools, and preferred instance types out of the repository.\n\nInspect the repository's instructions, CI, dependency locks, existing `.devcontainer` configuration, and build scripts. Preserve a working setup. Identify which tasks require macOS and which can run on Linux. Do not represent a Linux container as capable of running Xcode or Apple-only tests.\n\nUse the [Dev Container specification](https:\u002F\u002Fcontainers.dev\u002Fimplementors\u002Fjson_reference\u002F) for configuration and the [Dev Container CLI](https:\u002F\u002Fgithub.com\u002Fdevcontainers\u002Fcli) for execution. Check the installed CLI's version and command help before relying on flags. Graftty's placement command creates a host worktree by default. `graftty remote placement create --dev-container` explicitly prepares an image or Dockerfile environment and opens its shell; `--dev-container-config` selects a configuration inside the new worktree. Explicit `--skill-revision` selections install staged skills, and `--agent codex` or `--agent claude` launches an installed native runtime with a matching revision. Managed placements retain their private agent profiles on the host when containers are removed. Compose placement, automatic profile refresh, session replication, and automatic recovery remain pending.\n\nSkill installation requires POSIX shell utilities, `base64`, and `diff` in the container. Publishing missing project skill directories also requires GNU `mv` or `gmv` with verified `-T --no-clobber` behavior. Install GNU coreutils in images that need project skill publication. User-only skills and identical existing project skills do not require that mover. Configure the container remote user to match the Linux host user's UID for the private profile mount. Profile retention does not establish a parent backup or authenticate the agent to its model service.\n\n## Configure the project\n\nCreate or repair `.devcontainer\u002Fdevcontainer.json` or the repository's existing supported configuration. Use a Dockerfile, Compose services, or Features only where the project needs them. Follow the project's established dependency versions and lockfiles. Make setup repeatable when a second worktree arrives on an already-used host.\n\nRecord required CPU, memory, and storage with standard `hostRequirements` properties where applicable. Document supported CPU architectures and measured resource requirements alongside the configuration. Separate requirements from unmeasured estimates. A suggested instance type is a user preference, not a project requirement.\n\nGive each worktree its own mutable environment. Check for fixed Compose project names, container names, host ports, database directories, and writable volumes that could cause different worktrees or projects to share state accidentally. Share image layers and suitable dependency caches without sharing mutable project data.\n\nLifecycle commands execute project code, sometimes on the host. Inspect the configuration, Features, Dockerfile, Compose files, and setup scripts before executing them. Preserve the user's authorized scope. Document any required privileged access or host service dependency rather than adding it incidentally.\n\nDo not copy or mount SSH private keys, AWS credential files, Git credential stores, agent authentication stores, or a user's entire home into the environment. Do not enable automatic credential forwarding. Document independent login requirements for private registries, packages, Git remotes, Claude, and Codex. Existing credentials may be used where independently configured; do not print their contents in verification output.\n\nDocument required MCP server IDs and whether each tool must operate on the Linux checkout or on the parent Mac. Explicit parent-proxied stdio MCP access is available through `graftty remote mcp connect` on the parent and placement `--mcp-grants \u003Cfile>` with selected skill revisions. Follow the remote-host skill for that setup and its scoped bridge requirements. Upstream authentication stays on the parent; project configuration must not contain tokens or private credential references. Automatic grant creation, HTTP servers, and app connector authentication adapters remain pending. MCP access and the agent runtime's model-service login are separate prerequisites.\n\n## Verify worktree behavior\n\nCheck Git metadata access inside the container. A linked worktree's `.git` file points outside its checkout; merely mounting the checkout can leave `git status` broken. Inspect `git rev-parse --git-common-dir` and the existing worktree layout before choosing mounts.\n\nThe upstream CLI supports `--mount-git-worktree-common-dir` for relative Git worktrees. Check the installed command help and verify that the worktree uses the compatible relative layout before using it. Both host and container Git must support the relative-worktree repository extension. Do not silently rewrite existing Git worktree metadata or mount a whole parent home directory as a shortcut. If an existing absolute layout needs another mounting arrangement, document the exact Git metadata directory and verify access without bringing unrelated files into the container.\n\nUse an existing worktree for verification. If a second worktree is needed, follow Graftty's worktree coordination workflow through the graftty-team skill. Do not create an agent workspace with `git worktree add` directly.\n\nRun the CLI against the actual workspace and selected configuration. For a default configuration in an ordinary checkout, the basic sequence is:\n\n```sh\ndevcontainer read-configuration --workspace-folder \"$project_workspace\"\ndevcontainer up --workspace-folder \"$project_workspace\"\ndevcontainer exec --workspace-folder \"$project_workspace\" git status --short\n```\n\nSet `project_workspace` to the absolute checkout path. Add supported configuration and Git worktree options consistently to the commands that need them. Wait for successful process exit and completion of required lifecycle commands. A running container or an early success JSON record does not prove that setup or project verification finished.\n\nRun the repository's documented build, test, and development-start commands with `devcontainer exec`. Verify the expected listening port and writable paths. Check two worktrees for port, volume, and Compose-name collisions when that verification is available and authorized. Test each architecture you claim to support; report untested architectures explicitly.\n\nIf Docker, the CLI, an architecture, credentials, or another prerequisite is unavailable, finish the reviewable configuration and list the exact verification still needed. Do not call the environment ready based only on a valid JSON document or a successful image build.\n\n## Leave useful project guidance\n\nUpdate the existing developer documentation or add a short `.devcontainer\u002FREADME.md` with the supported platform and architecture, setup and verification commands, resource estimates, worktree isolation choices, and independent authentication prerequisites. Include what was actually tested and any remaining incompatibility.\n\nCommit the project configuration and documentation through the repository's normal workflow. This skill does not launch AWS instances, choose a user's account settings, publish images, move credentials, or claim that parent replication and Spot recovery have been configured.\n",{"name":5,"description":7},"main","71369bd649bcc56891f420ef192d668a9bbe652d","Sources\u002FGrafttyKit\u002FAgentPlugins\u002Fcodex\u002Fplugins\u002Fgraftty\u002Fskills\u002Fproject-setup",1,"https:\u002F\u002Fgithub.com\u002Fbtucker\u002Fgraftty","https:\u002F\u002Fgithub.com\u002Fbtucker","http:\u002F\u002Fbtucker.net","2026-11-12 04:12:20",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add btucker\u002Fgraftty --skill project-setup",{"tool":58,"command":59},"bunx","bunx skills add btucker\u002Fgraftty --skill project-setup",{"tool":61,"command":62},"pnpm","pnpm dlx skills add btucker\u002Fgraftty --skill project-setup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbtucker\u002Fgraftty\u002Fblob\u002Fmain\u002FSources\u002FGrafttyKit\u002FAgentPlugins\u002Fcodex\u002Fplugins\u002Fgraftty\u002Fskills\u002Fproject-setup\u002FSKILL.md",true,[],[67,94,104,128,141,146],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":78,"publishedAt":39},"01M718SEPNH6NEF97Z6F0292JJ","remote-host","Work in a Graftty-managed remote worktree using its recorded parent, prepared environment, Git publication route, and MCP access. Use for remote agent work and handoff, not for generic SSH administration.","https:\u002F\u002Fgithub.com\u002Fbtucker\u002Fgraftty\u002Fblob\u002Fmain\u002FSources\u002FGrafttyKit\u002FAgentPlugins\u002Fcodex\u002Fplugins\u002Fgraftty\u002Fskills\u002Fremote-host\u002FSKILL.md",[73],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[79,80,26,24,81,82,83,34,84,85,33,86,87,88,22,89,90,91,92,93],"remote host","host","generic","mcp access","handoff","managed","MCP","access","administration","route","work","worktree","ssh","git","remote agent",{"skillNo":95,"name":22,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":39},"01M718SANZNZ60BB37WWZJ0K12","Report a brief Graftty Attention recap before ending a tracked agent turn.","https:\u002F\u002Fgithub.com\u002Fbtucker\u002Fgraftty\u002Fblob\u002Fmain\u002FSources\u002FGrafttyKit\u002FAgentPlugins\u002Fcodex\u002Fplugins\u002Fgraftty\u002Fskills\u002Fgraftty\u002FSKILL.md",[],[22,100,101,102,103],"report","recap","attention","brief",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":39},"01M718S7EZQ1TSCG7J6BYV391B","graftty-preview","Use whenever an explanation would be clearer visually, even when no artifact exists yet. Create self-contained HTML and show it with graftty preview. Also use when the user asks to see a file, asks to see it again, or you produce a finished artifact for review. Use graftty-open for URLs or explicit requests to open files in their default app.","https:\u002F\u002Fgithub.com\u002Fbtucker\u002Fgraftty\u002Fblob\u002Fmain\u002FSources\u002FGrafttyKit\u002FAgentPlugins\u002Fcodex\u002Fplugins\u002Fgraftty\u002Fskills\u002Fgraftty-preview\u002FSKILL.md",[],[111,112,22,113,114,115,116,117,24,118,119,120,121,33,122,123,124,125,126,127],"preview","graftty preview","artifact","requests","app","create","show","default","open","files","produce","when","you","file","review","with","self",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":39},"01M718S4WCXNP36KAK5MJN79Q9","graftty-open","Open HTTP(S) URLs or files explicitly requested in their default app on the pane leader's device. Use graftty-preview for visual explanations, file previews, and finished review artifacts.","https:\u002F\u002Fgithub.com\u002Fbtucker\u002Fgraftty\u002Fblob\u002Fmain\u002FSources\u002FGrafttyKit\u002FAgentPlugins\u002Fcodex\u002Fplugins\u002Fgraftty\u002Fskills\u002Fgraftty-open\u002FSKILL.md",[],[135,119,22,115,136,24,118,120,33,137,138,139,111,124,140,125],"graftty open","leader","http","artifacts","visual","device",{"skillNo":142,"name":69,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":39},"01M718S2SVRBB0RRX1JD6EY5FP","https:\u002F\u002Fgithub.com\u002Fbtucker\u002Fgraftty\u002Fblob\u002Fmain\u002FSources\u002FGrafttyKit\u002FAgentPlugins\u002Fclaude\u002Fplugins\u002Fgraftty\u002Fskills\u002Fremote-host\u002FSKILL.md",[],[79,80,26],{"skillNo":147,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":39},"01M718S14VT387WHKX2F7J2QM5","https:\u002F\u002Fgithub.com\u002Fbtucker\u002Fgraftty\u002Fblob\u002Fmain\u002FSources\u002FGrafttyKit\u002FAgentPlugins\u002Fclaude\u002Fplugins\u002Fgraftty\u002Fskills\u002Fproject-setup\u002FSKILL.md",[],[20,21,19]]