菜单
Use when preparing to commit or push code and you must satisfy GitHub Actions CI requirements first. Enforce repository-scoped pre-commit checks based on workflow files, block commit/push on failures, and verify CI readiness before submitting to GitHub.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use after requirement-analysis, tech-stack-confirmation, and project-architecture-init skills have all been completed — PRD, BDD JSON files, architecture design document, and walking skeleton must already exist. This skill first generates a prioritized execution plan document in docs/plans/, then drives the full development cycle for each feature using BDD-guided TDD based on that plan. Technology-stack agnostic — all tech-specific details (build commands, test frameworks, directory paths) are read from the architecture document at runtime. Triggers on requests like 'start development', 'execute BDD features', 'implement features from PRD', 'run bdd-driven development', or when BDD JSON files exist and implementation has not started.
This skill should be used after the requirement-analysis and tech-stack-confirmation skills have been completed (PRD, technology stack decisions, and ADRs already exist). It reads existing artifacts and produces three deliverables: (1) a detailed architecture design document defining package structure, module boundaries, and dependency rules, (2) a runnable walking skeleton that validates all technology integrations, and (3) automated safeguards including unit tests, integration tests, architecture fitness functions, and CI pipeline configuration. Triggers on requests like 'initialize project architecture', 'scaffold project', 'set up project structure', 'create walking skeleton', 'generate design document from tech stack', or 'bootstrap project from PRD'.
Use when a user brings a new requirement, feature request, or problem statement that needs to be analyzed, refined, and documented before any implementation begins. This skill guides the full requirements engineering process: stripping away solution bias to find the real need, refining requirements through structured dialogue, producing a formal PRD, and generating BDD acceptance criteria. It should NOT be used for technical design, architecture decisions, or implementation planning.
Use after the tech-stack-confirmation skill has been completed and a confirmed tech stack document exists. This skill reads the confirmed tech stack, ADRs, and NFR documents, then generates project-specific coding rules (.claude/rules/*.md files) with YAML frontmatter `paths` scoping, based on the best practices of each selected technology. It produces 4–5 consolidated rule files focused on code quality and best practices. It should be triggered when a user asks to 'generate project rules', 'create coding standards', 'set up code quality rules', 'generate rules from tech stack', or 'create best-practice rules'. It should NOT be used for technology selection (use tech-stack-confirmation instead) or for detailed system design.
Use after completing the requirement-analysis skill and producing a PRD document. This skill guides the process of confirming the technology stack (development languages, frameworks, databases, testing tools, infrastructure) based on PRD requirements. It should be triggered when a user has a PRD and needs to make technology selection decisions, or when the user asks to 'confirm tech stack', 'select technologies', 'do technology evaluation', or 'create architecture decisions' for a project. It should NOT be used for requirements gathering (use requirement-analysis instead) or for detailed system design/implementation planning.
| name | run-github-ci-before-commit |
| description | Use when preparing to commit or push code and you must satisfy GitHub Actions CI requirements first. Enforce repository-scoped pre-commit checks based on workflow files, block commit/push on failures, and verify CI readiness before submitting to GitHub. |
Enforce a hard gate before git commit or git push: run the same required checks defined by the target repository's GitHub workflow. Never assume the skill folder is the target repository.
Determine repo in this order:
git rev-parse --show-toplevel).Hard rules:
~/.codex/skills/<skill-name> as target repo unless user explicitly says so.Read workflow definitions from target repo:
.github/workflows/*.yml.github/workflows/*.yamlPrioritize jobs triggered by push / pull_request.
Extract required quality steps from run: commands first.
Focus on jobs that are quality gates for pull requests or pushes:
Ignore deployment-only jobs unless the user asks to run them locally.
If no workflow file exists, derive a best-effort default set from project scripts/toolchain and clearly state this is fallback mode.
Build a deterministic ordered list matching CI intent, for example:
Use repository-native tooling and scripts first (bun run ..., npm run ..., pnpm ..., yarn ..., pytest, go test, etc.).
Do not invent non-existent commands.
If workflow has explicit commands, run those exact commands.
Run checks in deterministic order and stop at first failure when speed matters, or run all and produce a full failure list when diagnostics matter.
When a command fails:
git commit while required checks are failing.git push while required checks are failing.When user asks "提交到 GitHub":
git remote -v).gh auth status) when available.gh run list, gh run view).When user asks to create PR (or asks to complete GitHub submission end-to-end):
gh pr create).Hard rules:
Always report:
CI Gate: PASS - Safe to commitCI Gate: FAIL - Commit blocked