Create a git commit with clear, conventional commit messages. You MUST read this when the user wants to commit staged changes, write a commit message, or finalize code changes with proper conventional commit format since it describes how to follow the user's specific requirements.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Create git commits with conventional commit messages.
git log -3 --format=%B to review the last three commit messages and understand the existing commit message pattern.git --no-pager diff to review the full changes.type: description)n as a substitute for a line break.Co-Authored-By: model-name <model-email>-s to write Signed-off-by with the current username <email>.IMPORTANT: Prefer a multiline message source that preserves line breaks exactly, such as git commit -F - with a heredoc, or use separate -m arguments for separate paragraphs.
IMPORTANT: Treat the rendered commit message as the source of truth. After committing, verify it with git log -1 --format=%B when newline handling is uncertain.
IMPORTANT: Do not allow the final commit message to contain the literal two-character sequence backslash + n as a substitute for a line break.
git commit -s -F - <<'EOF'
chore: standardize linting, centralize guides, pin Python
- Introduce a root .flake8 config enforcing a 100-character line limit and ignoring specific style checks
- Remove inlined Python and Zsh guideline sections from copilot-instructions.md in favor of dedicated files
- Pin project Python version to 3.12 via a new .python-version file
- Rename docs/testing-guideline.md to docs/zsh-testing-guideline.md
- Refactor fetch_tags.py for consistent double-quoted strings, streamlined pattern definitions, logging calls, and URL assignment
Resolves issue #42
EOF
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Add SLSA build-provenance attestations to existing GitHub Actions workflows. Use when the user wants to add artifact attestations, build provenance, or SLSA attestations to Docker container image builds in GitHub Actions CI/CD pipelines.
The English summary is being prepared. Showing the original description.
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.
The English summary is being prepared. Showing the original description.
Guideline for designing, implementing, and verifying secure APIs following OWASP API Security Top 10 (2023) best practices. Use when the user wants to: (1) review API code or design for security vulnerabilities, (2) design a secure REST, GraphQL, or gRPC API architecture, (3) implement API authentication and authorization (OAuth2, JWT, API keys, mTLS), (4) configure rate limiting, input validation, or CORS, (5) audit API endpoints for BOLA, BFLA, or mass assignment vulnerabilities, (6) create API security checklists or verification plans, (7) fix API security bugs or harden existing APIs, (8) set up API security testing (OWASP ZAP, Schemathesis, Burp Suite), or (9) handle any API security concern including SSRF prevention, resource consumption limits, business flow protection, API inventory management, and secure third-party API consumption.
The English summary is being prepared. Showing the original description.
Write, review, and optionally test Bash and Zsh shell scripts following project coding standards. Use for ANY shell scripting task: (1) creating a new Bash or Zsh script, (2) editing, fixing, or reviewing an existing .sh, .bash, or .zsh file, (3) adding error handling, dependency checks, or cleanup traps to shell scripts, (4) implementing API integration or file processing in shell, (5) writing or fixing ShellSpec tests (spec/*_spec.sh), or (6) deciding whether a script should be written in Bash or Zsh. Defaults to Bash; Zsh-specific guidance lives in a reference file that is loaded only when writing Zsh.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
Create, run, and maintain API test collections using Bruno (OpenCollection YAML format and legacy Bru format). Use when the user wants to: (1) create a Bruno API test collection from scratch or from OpenAPI/Swagger specs, (2) write API request files with tests and assertions, (3) run API tests using bru CLI, (4) generate test reports (HTML, JUnit, JSON), (5) set up CI/CD pipelines (GitHub Actions) for automated API testing, (6) debug or fix failing Bruno API tests, (7) add environment configurations for API testing, (8) chain API requests with data extraction, or (9) work with any .yml/.bru Bruno collection files. Triggers on mentions of 'Bruno', 'bru CLI', 'API testing collection', 'OpenCollection', or requests to automate API testing with file-based collections.
The English summary is being prepared. Showing the original description.