Token导航 LogoToken导航

Agent Skill · 开发

posix-shell-pro(posix shell 专业版)

posix-shell-pro 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

posix-shell-pro 是开发类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为接触敏感数据;许可证为 MIT,第三方扫描已通过,按安装量在开发类的 21,746 个 Skill 里排第 17,767。

总安装 380周安装 16GitHub Stars 693下载 133核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:posix-shell-pro(posix shell 专业版)
来源仓库:https://github.com/rmyndharis/antigravity-skills
仓库路径:skills/posix-shell-pro
安装命令:
npx skills add https://github.com/rmyndharis/antigravity-skills --skill posix-shell-pro
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/rmyndharis/antigravity-skills --skill posix-shell-pro

这个 Skill 是做什么的

开发类 Skill 面向写代码、改代码和排查问题,一般会读写仓库文件,部分还会执行构建或测试命令。

posix-shell-pro 用于处理 GitHub 仓库、Issue、Pull Request 等协作信息,适合整理代码变更与项目状态。适用于围绕仓库状态、代码协作事项进行信息整合的 Agent 工作流。通过 npx skills add 命令从指定 GitHub 仓库安装,需参考原始 README 了解具体实现。

安装前应确认权限范围、维护状态,以及是否会触发联网或文件操作。建议在使用前检查目标仓库的访问权限和用户授权情况。

来源仓库内路径:skills/posix-shell-pro

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/rmyndharis/antigravity-skills --skill posix-sh…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要接触敏感数据,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

posix-shell-pro 怎么安装?

在终端执行 npx skills add https://github.com/rmyndharis/antigravity-skills --skill posix-shell-pro。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

posix-shell-pro 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

posix-shell-pro 需要什么权限?

权限级别是接触敏感数据。该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

posix-shell-pro 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

posix-shell-pro 用的人多吗?

公开数据是累计安装 380 次,近一周安装 16 次,下载 133 次,GitHub 693 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

posix-shell-pro 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 需要接触敏感数据,装到常用环境前要先评估影响面。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理开发类任务、又不想每次都手写提示词的人。
  • 需要许可证清楚、并且有第三方扫描结果的团队项目。

不太适合

  • 环境里有大量密钥、凭证,不方便给第三方 Skill 读取的人。
  • 需要厂商级技术支持和 SLA 的生产系统。

开发类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
skill-vetter

技能审查员 · OpenClaw

8,779,018986操作浏览器MIT-0通过
ontology

本体论 · OpenClaw

6,636,960576只读MIT-0通过
entra-app-registration

内部应用程序注册 · Codex、Claude

6,631,872764接触敏感数据未明确通过
entra-app-registration

内部应用程序注册 · Codex、Claude

3,757,680201接触敏感数据未明确通过
nano-banana-pro

纳米香蕉专业版 · OpenClaw

3,526,898364接触敏感数据MIT-0有提醒
posix-shell-pro

posix shell 专业版 · 本页

380693接触敏感数据MIT通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Use this skill when

  • Working on posix shell pro tasks or workflows
  • Needing guidance, best practices, or checklists for posix shell pro

Do not use this skill when

  • The task is unrelated to posix shell pro
  • You need a different domain or tool outside this scope

Instructions

  • Clarify goals, constraints, and required inputs.
  • Apply relevant best practices and validate outcomes.
  • Provide actionable steps and verification.
  • If detailed examples are required, open resources/implementation-playbook.md.

Focus Areas

  • Strict POSIX compliance for maximum portability
  • Shell-agnostic scripting that works on any Unix-like system
  • Defensive programming with portable error handling
  • Safe argument parsing without bash-specific features
  • Portable file operations and resource management
  • Cross-platform compatibility (Linux, BSD, Solaris, AIX, macOS)
  • Testing with dash, ash, and POSIX mode validation
  • Static analysis with ShellCheck in POSIX mode
  • Minimalist approach using only POSIX-specified features
  • Compatibility with legacy systems and embedded environments

POSIX Constraints

  • No arrays (use positional parameters or delimited strings)
  • No [[ conditionals (use [ test command only)
  • No process substitution <() or >()
  • No brace expansion {1..10}
  • No local keyword (use function-scoped variables carefully)
  • No declare, typeset, or readonly for variable attributes
  • No += operator for string concatenation
  • No ${var//pattern/replacement} substitution
  • No associative arrays or hash tables
  • No source command (use . for sourcing files)

Approach

  • Always use #!/bin/sh shebang for POSIX shell
  • Use set -eu for error handling (no pipefail in POSIX)
  • Quote all variable expansions: "$var" never $var
  • Use [] for all conditional tests, never [[
  • Implement argument parsing with while and case (no getopts for long options)
  • Create temporary files safely with mktemp and cleanup traps
  • Use printf instead of echo for all output (echo behavior varies)
  • Use . script.sh instead of source script.sh for sourcing
  • Implement error handling with explicit || exit 1 checks
  • Design scripts to be idempotent and support dry-run modes
  • Use IFS manipulation carefully and restore original value
  • Validate inputs with [-n "$var"] and [-z "$var"] tests
  • End option parsing with -- and use rm -rf -- "$dir" for safety
  • Use command substitution $() instead of backticks for readability
  • Implement structured logging with timestamps using date
  • Test scripts with dash/ash to verify POSIX compliance

Compatibility & Portability

  • Use #!/bin/sh to invoke the system's POSIX shell
  • Test on multiple shells: dash (Debian/Ubuntu default), ash (Alpine/BusyBox), bash --posix
  • Avoid GNU-specific options; use POSIX-specified flags only
  • Handle platform differences: uname -s for OS detection
  • Use command -v instead of which (more portable)
  • Check for command availability: command -v cmd >/dev/null 2>&1 || exit 1
  • Provide portable implementations for missing utilities
  • Use [-e "$file"] for existence checks (works on all systems)
  • Avoid /dev/stdin, /dev/stdout (not universally available)
  • Use explicit redirection instead of &> (bash-specific)

Readability & Maintainability

  • Use descriptive variable names in UPPER_CASE for exports, lower_case for locals
  • Add section headers with comment blocks for organization
  • Keep functions under 50 lines; extract complex logic
  • Use consistent indentation (spaces only, typically 2 or 4)
  • Document function purpose and parameters in comments
  • Use meaningful names: validate_input not check
  • Add comments for non-obvious POSIX workarounds
  • Group related functions with descriptive headers
  • Extract repeated code into functions
  • Use blank lines to separate logical sections

Safety & Security Patterns

  • Quote all variable expansions to prevent word splitting
  • Validate file permissions before operations: [-r "$file"] || exit 1
  • Sanitize user input before using in commands
  • Validate numeric input: case $num in *[!0-9]*) exit 1;; esac
  • Never use eval on untrusted input
  • Use -- to separate options from arguments: rm -- "$file"
  • Validate required variables: [-n "$VAR"] || {echo "VAR required" >&2; exit 1;}
  • Check exit codes explicitly: cmd || {echo "failed" >&2; exit 1;}
  • Use trap for cleanup: trap 'rm -f "$tmpfile"' EXIT INT TERM
  • Set restrictive umask for sensitive files: umask 077
  • Log security-relevant operations to syslog or file
  • Validate file paths don't contain unexpected characters
  • Use full paths for commands in security-critical scripts: /bin/rm not rm

Performance Optimization

  • Use shell built-ins over external commands when possible
  • Avoid spawning subshells in loops: use while read not for i in $(cat)
  • Cache command results in variables instead of repeated execution
  • Use case for multiple string comparisons (faster than repeated if)
  • Process files line-by-line for large files
  • Use expr or $(()) for arithmetic (POSIX supports $(()))
  • Minimize external command calls in tight loops
  • Use grep -q when you only need true/false (faster than capturing output)
  • Batch similar operations together
  • Use here-documents for multi-line strings instead of multiple echo calls

Documentation Standards

  • Implement -h flag for help (avoid --help without proper parsing)
  • Include usage message showing synopsis and options
  • Document required vs optional arguments clearly
  • List exit codes: 0=success, 1=error, specific codes for specific failures
  • Document prerequisites and required commands
  • Add header comment with script purpose and author
  • Include examples of common usage patterns
  • Document environment variables used by script
  • Provide troubleshooting guidance for common issues
  • Note POSIX compliance in documentation

Working Without Arrays

Since POSIX sh lacks arrays, use these patterns:

  • Positional Parameters: set -- item1 item2 item3; for arg; do echo "$arg"; done
  • Delimited Strings: items="a:b:c"; IFS=:; set -- $items; IFS=' '
  • Newline-Separated: items="a\nb\nc"; while IFS= read -r item; do echo "$item"; done <<EOF
  • Counters: i=0; while [$i -lt 10]; do i=$((i+1)); done
  • Field Splitting: Use cut, awk, or parameter expansion for string splitting

Portable Conditionals

Use [] test command with POSIX operators:

  • File Tests: [-e file] exists, [-f file] regular file, [-d dir] directory
  • String Tests: [-z "$str"] empty, [-n "$str"] not empty, ["$a" = "$b"] equal
  • Numeric Tests: ["$a" -eq "$b"] equal, ["$a" -lt "$b"] less than
  • Logical: [cond1] && [cond2] AND, [cond1] || [cond2] OR
  • Negation: [! -f file] not a file
  • Pattern Matching: Use case not [[=~]]

CI/CD Integration

  • Matrix testing: Test across dash, ash, bash --posix, yash on Linux, macOS, Alpine
  • Container testing: Use alpine:latest (ash), debian:stable (dash) for reproducible tests
  • Pre-commit hooks: Configure checkbashisms, shellcheck -s sh, shfmt -ln posix
  • GitHub Actions: Use shellcheck-problem-matchers with POSIX mode
  • Cross-platform validation: Test on Linux, macOS, FreeBSD, NetBSD
  • BusyBox testing: Validate on BusyBox environments for embedded systems
  • Automated releases: Tag versions and generate portable distribution packages
  • Coverage tracking: Ensure test coverage across all POSIX shells
  • Example workflow: shellcheck -s sh *.sh && shfmt -ln posix -d *.sh && checkbashisms *.sh

Embedded Systems & Limited Environments

  • BusyBox compatibility: Test with BusyBox's limited ash implementation
  • Alpine Linux: Default shell is BusyBox ash, not bash
  • Resource constraints: Minimize memory usage, avoid spawning excessive processes
  • Missing utilities: Provide fallbacks when common tools unavailable (mktemp, seq)
  • Read-only filesystems: Handle scenarios where /tmp may be restricted
  • No coreutils: Some environments lack GNU coreutils extensions
  • Signal handling: Limited signal support in minimal environments
  • Startup scripts: Init scripts must be POSIX for maximum compatibility
  • Example: Check for mktemp: command -v mktemp >/dev/null 2>&1 || mktemp() {...}

Migration from Bash to POSIX sh

  • Assessment: Run checkbashisms to identify bash-specific constructs
  • Array elimination: Convert arrays to delimited strings or positional parameters
  • Conditional updates: Replace [[ with [ and adjust regex to case patterns
  • Local variables: Remove local keyword, use function prefixes instead
  • Process substitution: Replace <() with temporary files or pipes
  • Parameter expansion: Use sed/awk for complex string manipulation
  • Testing strategy: Incremental conversion with continuous validation
  • Documentation: Note any POSIX limitations or workarounds
  • Gradual migration: Convert one function at a time, test thoroughly
  • Fallback support: Maintain dual implementations during transition if needed

Quality Checklist

  • Scripts pass ShellCheck with -s sh flag (POSIX mode)
  • Code is formatted consistently with shfmt using -ln posix
  • Test on multiple shells: dash, ash, bash --posix, yash
  • All variable expansions are properly quoted
  • No bash-specific features used (arrays, [[, local, etc.)
  • Error handling covers all failure modes
  • Temporary resources cleaned up with EXIT trap
  • Scripts provide clear usage information
  • Input validation prevents injection attacks
  • Scripts portable across Unix-like systems (Linux, BSD, Solaris, macOS, Alpine)
  • BusyBox compatibility validated for embedded use cases
  • No GNU-specific extensions or flags used

Output

  • POSIX-compliant shell scripts maximizing portability
  • Test suites using shellspec or bats-core validating across dash, ash, yash
  • CI/CD configurations for multi-shell matrix testing
  • Portable implementations of common patterns with fallbacks
  • Documentation on POSIX limitations and workarounds with examples
  • Migration guides for converting bash scripts to POSIX sh incrementally
  • Cross-platform compatibility matrices (Linux, BSD, macOS, Solaris, Alpine)
  • Performance benchmarks comparing different POSIX shells
  • Fallback implementations for missing utilities (mktemp, seq, timeout)
  • BusyBox-compatible scripts for embedded and container environments
  • Package distributions for various platforms without bash dependency

Essential Tools

Static Analysis & Formatting

  • ShellCheck: Static analyzer with -s sh for POSIX mode validation
  • shfmt: Shell formatter with -ln posix option for POSIX syntax
  • checkbashisms: Detects bash-specific constructs in scripts (from devscripts)
  • Semgrep: SAST with POSIX-specific security rules
  • CodeQL: Security scanning for shell scripts

POSIX Shell Implementations for Testing

  • dash: Debian Almquist Shell - lightweight, strict POSIX compliance (primary test target)
  • ash: Almquist Shell - BusyBox default, embedded systems
  • yash: Yet Another Shell - strict POSIX conformance validation
  • posh: Policy-compliant Ordinary Shell - Debian policy compliance
  • osh: Oil Shell - modern POSIX-compatible shell with better error messages
  • bash --posix: GNU Bash in POSIX mode for compatibility testing

Testing Frameworks

  • bats-core: Bash testing framework (works with POSIX sh)
  • shellspec: BDD-style testing that supports POSIX sh
  • shunit2: xUnit-style framework with POSIX sh support
  • sharness: Test framework used by Git (POSIX-compatible)

Common Pitfalls to Avoid

  • Using [[ instead of [ (bash-specific)
  • Using arrays (not in POSIX sh)
  • Using local keyword (bash/ksh extension)
  • Using echo without printf (behavior varies across implementations)
  • Using source instead of . for sourcing scripts
  • Using bash-specific parameter expansion: ${var//pattern/replacement}
  • Using process substitution <() or >()
  • Using function keyword (ksh/bash syntax)
  • Using $RANDOM variable (not in POSIX)
  • Using read -a for arrays (bash-specific)
  • Using set -o pipefail (bash-specific)
  • Using &> for redirection (use >file 2>&1)

Advanced Techniques

  • Error Trapping: trap 'echo "Error at line $LINENO" >&2; exit 1' EXIT; trap - EXIT on success
  • Safe Temp Files: tmpfile=$(mktemp) || exit 1; trap 'rm -f "$tmpfile"' EXIT INT TERM
  • Simulating Arrays: set -- item1 item2 item3; for arg; do process "$arg"; done
  • Field Parsing: IFS=:; while read -r user pass uid gid; do...; done < /etc/passwd
  • String Replacement: echo "$str" | sed 's/old/new/g' or use parameter expansion ${str%suffix}
  • Default Values: value=${var:-default} assigns default if var unset or null
  • Portable Functions: Avoid function keyword, use func_name() {...}
  • Subshell Isolation: (cd dir && cmd) changes directory without affecting parent
  • Here-documents: cat <<'EOF' with quotes prevents variable expansion
  • Command Existence: command -v cmd >/dev/null 2>&1 && echo "found" || echo "missing"

POSIX-Specific Best Practices

  • Always quote variable expansions: "$var" not $var
  • Use [] with proper spacing: ["$a" = "$b"] not ["$a"="$b"]
  • Use = for string comparison, not == (bash extension)
  • Use . for sourcing, not source
  • Use printf for all output, avoid echo -e or echo -n
  • Use $(()) for arithmetic, not let or declare -i
  • Use case for pattern matching, not [[=~]]
  • Test scripts with sh -n script.sh to check syntax
  • Use command -v not type or which for portability
  • Explicitly handle all error conditions with || exit 1

References & Further Reading

POSIX Standards & Specifications

Portability & Best Practices

Tools & Testing

平台分布

Codex

28.89%
按下载量换算38

windsurf

26.53%
按下载量换算35

trae

16.88%
按下载量换算22

Claude Code

12.85%
按下载量换算17

Antigravity

9.24%
按下载量换算12

qoder

3.88%
按下载量换算5

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

接触敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

继续浏览同类 Skills