菜单
Maintain .gitignore files correctly — never commit IDE-specific files, treat the root .gitignore as owned by credfeto/cs-template, and add repo-specific entries at the right directory level. Use whenever creating or modifying any .gitignore file.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | credfeto-gitignore-management |
| description | Maintain .gitignore files correctly — never commit IDE-specific files, treat the root .gitignore as owned by credfeto/cs-template, and add repo-specific entries at the right directory level. Use whenever creating or modifying any .gitignore file. |
Never commit IDE-specific files or folders, including:
.idea/ — JetBrains IDEs.vscode/ — Visual Studio Code.vs/ — Visual StudioThese belong in the root .gitignore.
.gitignoreThe root .gitignore is the global baseline, owned by credfeto/cs-template:
.gitignore directly in credfeto/cs-template. In any other repository, treat it as distributed via the standard template update mechanism..gitignore in a non-template repository, raise the gap in credfeto/cs-template rather than adding it locally..gitignore FilesDerived repositories may add .gitignore files for repo-specific concerns (language build output, generated content, local tooling artefacts), placed at the appropriate directory level (e.g. a nested .gitignore inside a subproject that has its own generated-output pattern).
When creating or modifying any .gitignore, check it against the root .gitignore to ensure no duplication or conflicts.
Triage deprecation warnings seen in test output — fix ones caused by your change immediately, track pre-existing ones with a GitHub issue. Use whenever a deprecation warning (framework or runtime warning about a deprecated API) appears while running tests.
Write .NET unit tests using FunFair.Test.Common/FunFair.Test.Infrastructure base classes, mocking helpers, date sources, and xunit assertion patterns instead of hand-rolled equivalents. Use whenever writing or reviewing a .NET unit test (a *.Tests project).
Create, name, and maintain git branches — branching rules, Conventional Commits-style branch naming, rebasing against main, resuming interrupted work, and resolving version conflicts in dependency manifests during merges/rebases. Use when starting new work, creating a branch, resuming work on an existing branch, rebasing, or resolving merge conflicts.
Commit and push changes safely — branch checks, build/test gates, Conventional Commits format, and push cadence. Use whenever about to commit, stage, or push changes in any repository, or when acting as the Committer agent.
Create and manage GitHub issues correctly — duplicate search, planned descriptions, priority/status labels, assignment, and the Blocked label rules for AI-initiated issues, including the mandatory tracking issue required before starting any ad-hoc task. Use when asked to create a GitHub issue, when raising an issue autonomously, when a human asks you to do something and no existing issue or PR is already specified, when a PR or issue comment asks you to raise an issue, when selecting the next issue to work on, or when asking a blocking question and needing to mark an item Blocked.
Design and optimise performance-critical code, and back optimisations with committed benchmarks and measured allocation thresholds. Use when writing or optimising performance-critical code, or when asked to add or update a benchmark.