メニュー
Write and maintain README.md with the required section order, reference-style badge links, and the all-contributors section. Use whenever creating or updating README.md, adding a config option that needs documenting, or adding/removing a badge.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | credfeto-readme-documentation |
| description | Write and maintain README.md with the required section order, reference-style badge links, and the all-contributors section. Use whenever creating or updating README.md, adding a config option that needs documenting, or adding/removing a badge. |
README.md accurate and up to date; rewrite template placeholder content before starting work.appsettings.json, options class, or env var) is added, removed, or renamed — include type, default, and description.dotnet add package <Name> or the NuGet Package Manager command.docs/ for more complex ones.docs/ folder and any generated API documentation (e.g. DocFX, Doxygen, GitHub Pages).CHANGELOG.md.CONTRIBUTING.md.SECURITY.md.LICENSE.Omit any section that does not apply (e.g. no Installation section for a library with no NuGet package), but never invent placeholder sections.
Place all badges near the top of the file, after the title but before the overview prose.
All badges and hyperlinks must use reference-style markdown — never inline URLs. Use descriptive named labels; never use bare numbers ([1], [2]). Collect all reference definitions at the very bottom of the file, sorted alphabetically by label.
[![Alt text][image-ref]][link-ref]
<!-- bottom of file -->
[image-ref]: https://example.com/badge.svg
[link-ref]: https://example.com/
Use a table to separate main/pre-release from release builds:
| Branch | Status |
|---------|---------------------------------------------------|
| main | [![Build: Pre-Release][pre-release-img]][pre-release] |
| release | [![Build: Release][release-img]][release] |
<!-- bottom of file -->
[pre-release-img]: https://github.com/OWNER/REPO/actions/workflows/build-and-publish-pre-release.yml/badge.svg
[pre-release]: https://github.com/OWNER/REPO/actions/workflows/build-and-publish-pre-release.yml
[release-img]: https://github.com/OWNER/REPO/actions/workflows/build-and-publish-release.yml/badge.svg
[release]: https://github.com/OWNER/REPO/actions/workflows/build-and-publish-release.yml
[![NuGet][nuget-img]][nuget]
[![NuGet Downloads][nuget-downloads-img]][nuget]
<!-- bottom of file -->
[nuget-img]: https://img.shields.io/nuget/v/PACKAGE_NAME.svg
[nuget-downloads-img]: https://img.shields.io/nuget/dt/PACKAGE_NAME.svg
[nuget]: https://www.nuget.org/packages/PACKAGE_NAME
[![codecov][codecov-img]][codecov]
<!-- bottom of file -->
[codecov-img]: https://codecov.io/gh/OWNER/REPO/branch/main/graph/badge.svg
[codecov]: https://codecov.io/gh/OWNER/REPO
[![Licence][licence-img]][licence]
<!-- bottom of file -->
[licence-img]: https://img.shields.io/github/license/OWNER/REPO
[licence]: LICENSE
[![Bugs][bugs-img]][bugs]
<!-- bottom of file -->
[bugs-img]: https://img.shields.io/github/issues/OWNER/REPO/bug
[bugs]: https://github.com/OWNER/REPO/issues?q=is%3Aopen+is%3Aissue+label%3Abug
Only include badges that are actively maintained and reflect real state. Remove any badge whose target service is unavailable or whose data is stale.
docs/ folder; template repos must not.README.md/CHANGELOG.md) in docs/; keep them current.## Contributors section in README.md using the all-contributors spec only when the repository has more than one known human contributor. Omit the section entirely when there is only one.## Contributors
<!-- ALL-CONTRIBUTORS-LIST:START - Do not remove or modify this section -->
<!-- prettier-ignore-start -->
<!-- markdownlint-disable -->
<!-- markdownlint-restore -->
<!-- prettier-ignore-end -->
<!-- ALL-CONTRIBUTORS-LIST:END -->
START and END markers — the all-contributors bot manages that block.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.