cucumber-features
Use when editing or creating Cucumber feature files (*.feature). Provides API documentation guidelines.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when editing or creating Cucumber feature files (*.feature). Provides API documentation guidelines.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Batch, validate, and consolidate open Dependabot pull requests for memory-service. Use when asked to inspect the Dependabot queue, verify dependency PRs efficiently, reproduce dependency-update CI failures, combine compatible dependency PRs, or create a validated consolidated dependency PR.
Implement or review Memory Service backend operational logging. Use for REST or gRPC boundaries, provider errors, error wrapping, background workers and task attempts, indexers and maintenance jobs, SSE or gRPC streams, request correlation, and changes under internal/operationevent.
Prepare Memory Service changes for pull request submission. Use whenever Codex is asked to create, open, submit, publish, or ready a pull request, or to perform final PR preflight. Require `task generate` before the final PR commit so generated sources and repository-wide formatting are included.
Use when writing or debugging tests for memory-service. Covers Cucumber BDD patterns and failure reporting.
Use when you need build, test, or dev commands for memory-service across Go, Java, frontend, or Python modules.
Use when writing or editing enhancement documents in docs/enhancements/. Provides format, conventions, and numbering guidance.
| name | cucumber-features |
| description | Use when editing or creating Cucumber feature files (*.feature). Provides API documentation guidelines. |
| autoTrigger | [{"files":["**/*.feature"]}] |
Feature files should serve as API documentation for new users without needing to review step implementations.
First occurrence of an API: Use raw HTTP steps to document the exact URL and JSON structure:
When I call POST "/v1/conversations/${conversationId}/entries" with body:
"""
{
"channel": "HISTORY",
"contentType": "history",
"content": [{"text": "Hello", "role": "USER"}]
}
"""
Then the response status should be 201
And the response body should be json:
"""
{
"id": "${response.body.id}",
"conversationId": "${conversationId}",
"channel": "history",
"contentType": "history",
"content": [{"text": "Hello", "role": "USER"}],
"createdAt": "${response.body.createdAt}"
}
"""
Subsequent occurrences: Use shorthand steps since API is already documented:
Given the conversation has an entry "Hello"
When I list entries for the conversation
Then the response should contain 1 entry
When I call GET "/v1/conversations/${conversationId}"
When I call POST "/v1/path" with body:
When I call DELETE "/v1/path"
And set "myVar" to the json response field "id"
And set "myVar" to "${response.body.id}"
# Use later: "/v1/conversations/${myVar}"