メニュー
[QA Process · ISTQB CTFL v4.0] Test Plan creation — objectives, schedule, resources, entry/exit criteria, and risk mitigation. Run after qa-strategy, before test execution.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/aibot88/sec_skill_store --skill qa-planコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Guides the creation of agile user stories and Gherkin feature files. Use when the user wants to create a user story, write acceptance criteria, define Gherkin scenarios, or author BDD feature files. This should trigger for requests such as Create a user story; Write a user story; I need to write a user story. Part of cursor-rules-java project
Guía técnica completa para integrar 250+ servicios externos con agentes IA usando Composio. Cubre instalación, autenticación OAuth, gestión de herramientas, triggers y flujos multi-servicio.
Facilitates conversational discovery to create Architectural Decision Records (ADRs) for non-functional requirements using the ISO/IEC 25010:2023 quality model. Use when the user wants to document quality attributes, NFR decisions, security/performance/scalability architecture, or design systems with measurable quality criteria. This should trigger for requests such as Create ADR for Non-functional requirements; Document Non-functional requirements; Capture Non-functional requirements; Generate Non-functional requirements in an ADR. Part of cursor-rules-java project
SOC 職業分類に基づく
SKILL.md を表示中
| name | qa-plan |
| description | [QA Process · ISTQB CTFL v4.0] Test Plan creation — objectives, schedule, resources, entry/exit criteria, and risk mitigation. Run after qa-strategy, before test execution. |
📚 Knowledge References (loaded automatically):
qa-plan-patterns.md— ISTQB test plan structure (IEEE 829), entry/exit criteria templates, resource planning
A Test Plan translates the Test Strategy into a concrete, time-bound execution plan for a specific release or sprint.
Check if docs/qa/qa-strategy.md exists. If yes, load it. If no, ask user to run /helix qa-strategy first or provide key details inline.
1. What release / sprint is this plan for?
2. What features / changes are in scope?
3. Target release date?
4. Available testing resources (people / environments)?
5. Known risks or dependencies?
Conditions that must be met before testing starts:
Conditions that define "testing done":
| Phase | Start | End | Responsible |
|---|---|---|---|
| Tier 1 — Functional | |||
| Tier 2 — Non-Functional Quality | |||
| Exploratory Testing | |||
| Defect Fix + Retest | |||
| Sign-off |
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| Environment instability | Medium | High | Backup env ready |
| Late code freeze | Medium | High | Buffer days in schedule |
| Test data gaps | Low | Medium | qa-data skill |
Save to docs/qa/qa-plan-YYYY-MM-DD.md:
# Test Plan — [Release Name]
**Version:** 1.0 | **Date:** YYYY-MM-DD
## Scope
## Entry Criteria
## Exit Criteria
## Test Schedule
## Resources
## Risk & Mitigation
## Sign-off
Commit to repo.
Present plan path + schedule table.
Suggest next step: /helix qa-risk
1. Entry/exit criteria วัดได้จริงไหม?
2. Schedule realistic ไหม?
3. Risk มี mitigation ครบไหม?
4. สอดคล้องกับ qa-strategy ไหม?