diff --git a/agents/pm-agent.md b/agents/pm-agent.md
index 905525f..b217b31 100644
--- a/agents/pm-agent.md
+++ b/agents/pm-agent.md
@@ -77,7 +77,7 @@ The PM must not:
 - Write pseudocode
 - Write code
 
-The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints to keep requirements grounded, but must not derive or prescribe implementation design from internal code structure.
+The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints when needed for scope clarity, but must not derive or prescribe implementation design from internal code structure.
 
 PM defines WHAT.
 Engineering defines HOW.
@@ -130,8 +130,10 @@ Examples by context:
 - Regulated domains: retention, privacy, compliance logging
 
 ## Output Format
-PM must always output:
-- `## Research Inputs` (optional when relevant)
+PM must always output the following sections.
+If a section is not applicable, write `N/A` with a brief reason.
+
+- `## Research Inputs`
 - `## Problem`
 - `## Goals`
 - `## Non Goals`
@@ -164,11 +166,11 @@ Bad example:
 - `The system should work correctly`
 
 Good examples:
-- `Given a valid create-job request, when the request is submitted, then the system returns HTTP 201`
-- `Given a successful job creation, when the response is returned, then the response contains job_id`
-- `Given a successful job creation, when the response is returned, then job_id is a valid UUID v7`
-- `Given a successful job creation, when the job is queried, then it is queryable within 1 second`
-- `Given the same payload and the same idempotency key, when the request is repeated, then the system does not create a duplicate record`
+- `Given a valid create-job request, when the request is submitted, then the API returns HTTP 201`
+- `Given a successful job creation, when the response is returned, then it contains job_id`
+- `Given a successful job creation, when job_id is returned, then it must be a valid UUID v7`
+- `Given a job is created successfully, when it is queried within 1 second, then the job can be retrieved`
+- `Given the same request payload is retried with the same idempotency key, when the request is repeated, then no duplicate job is created`
 
 ## Context-Driven Coverage Rules
 The PM must decide which requirement categories are necessary for the feature. Do not force irrelevant categories, but do not omit categories that are materially required by the user context.
@@ -210,10 +212,6 @@ Before handing off a PRD, verify it contains:
 - Risks
 
 Strongly recommended when relevant:
-- Research Inputs
-- Assumptions
-- Dependencies
-- Open Questions
 - Error handling
 - Idempotency
 - Observability
diff --git a/skills/write-a-prd/README.zh-TW.md b/skills/write-a-prd/README.zh-TW.md
index e6698fd..e43ac34 100644
--- a/skills/write-a-prd/README.zh-TW.md
+++ b/skills/write-a-prd/README.zh-TW.md
@@ -20,7 +20,7 @@
 - 次要輸出：GitHub Issue（僅限使用者明確要求時）
 
 ## PRD 結構
-- `## Research Inputs`（有需要才填）
+- `## Research Inputs`
 - `## Problem`
 - `## Goals`
 - `## Non Goals`
@@ -36,6 +36,8 @@
 - `## Dependencies`
 - `## Open Questions`
 
+若某段不適用，請填 `N/A` 並附一句原因。
+
 ## 規則
 - 驗收標準必須使用 `Given / When / Then`
 - 每條驗收標準必須可觀察、可測試、可拒收、可衡量、不可歧義
diff --git a/skills/write-a-prd/SKILL.md b/skills/write-a-prd/SKILL.md
index 3049b4d..9af26a9 100644
--- a/skills/write-a-prd/SKILL.md
+++ b/skills/write-a-prd/SKILL.md
@@ -34,7 +34,7 @@ Before finalizing the PRD, verify that every acceptance criterion maps to at lea
 
 ## Research Inputs
 
-Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. Omit this section if no research was needed.
+Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. If no research was needed, write `N/A` with a brief reason.
 
 ## Problem
 
@@ -126,15 +126,15 @@ List product, operational, compliance, or adoption risks that could affect deliv
 
 ## Assumptions
 
-List assumptions this PRD depends on being true.
+List assumptions this PRD depends on being true. If there are no material assumptions, write `N/A` with a brief reason.
 
 ## Dependencies
 
-List dependencies on teams, systems, policies, vendors, or external events.
+List dependencies on teams, systems, policies, vendors, or external events. If there are no material dependencies, write `N/A` with a brief reason.
 
 ## Open Questions
 
-List unresolved product questions that must be answered before implementation or release.
+List unresolved product questions that must be answered before implementation or release. If there are no open questions, write `N/A` with a brief reason.
 
 </prd-template>
 
@@ -157,7 +157,7 @@ Do not:
 - Break work into engineering tasks
 - Write pseudocode or code
 
-The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints to keep requirements grounded, but must not derive or prescribe implementation design from internal code structure.
+The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints when needed for scope clarity, but must not derive or prescribe implementation design from internal code structure.
 
 ## Minimum Completeness Gate
 
@@ -175,10 +175,6 @@ The PRD must contain:
 - Risks
 
 Add these when relevant:
-- Research Inputs
-- Assumptions
-- Dependencies
-- Open Questions
 - Error handling
 - Idempotency
 - Observability