@mrciphersmith/keryx 0.2.97 → 0.2.99

package/src/gdskills/bundled/skills/planning/docpack-review/SKILL.md

@@ -2,9 +2,8 @@
 name: docpack-review
 description: "Use when reviewing or verifying a Metaproject requirements package under docs/requirements for completeness, versioning, README/PRD/spec consistency, schema references, roadmap updates, unsupported claims, and implementation-status accuracy. Usually dispatched by docpack-orchestrator. Not for reviewing autodoc-generated current-codebase documentation."
 triggers:
-  - "review requirements package"
-  - "verify requirements package"
   - "requirements package review"
+  - "verify requirements package"
   - "check PRD spec consistency"
   - "проверь документацию"
 metadata:
@@ -62,6 +61,19 @@ Adversarial reviewer for Metaproject requirements packages.
 - Future commands are marked future/planned.
 - Integrations distinguish implemented, planned and optional.
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "The three required files are clean, so the optional ones will be too." | Iron Law 1 forbids sampling. Optional files are where unsupported claims collect precisely because nobody expects them to be read — `agent-protocol.md` and `metrics-and-validation.md` describe behavior that most often does not exist yet. |
+| "The PRD and the specification both say this command exists, so the claim is supported." | Two documents agreeing is one author repeating themselves. The Accuracy checks resolve against the repository, not against a sibling doc. If no code backs the claim, it is a blocker. |
+| "The fix is one line — faster to apply it than to describe it." | Iron Law 6: report findings and suggested fixes, never rewrite. A reviewer who edits has no reviewer, and the orchestrator loses the record of what was wrong. |
+| "It is only a missing `Version` field — that is a warning, not a blocker." | Iron Law 3 names it a blocker outright, as does a missing required file (Law 2). The severity is fixed by the law, not by how small the fix looks. |
+| "There are blockers, but the package is broadly good, so `PASS_WITH_WARNINGS`." | Any blocker means `verdict: FAIL`. Softening the verdict is how a package with a missing spec reaches implementation. |
+| "The README status is stale but harmless, so it is an INFO note." | README status disagreeing with the PRD or spec is a contradiction, and Iron Law 5 makes contradictions blockers. Stale status is the field implementers read first. |
+
 ## Output
 
 Return findings first:

package/src/gdskills/bundled/skills/planning/interview/SKILL.md

@@ -1,17 +1,14 @@
 ---
 name: interview
-description: "Use to clarify implementation-specific ambiguities AFTER context has already been collected and the goal is known — the questions that sharpen a plan, not the ones that scope the request. This is the `implement`-intent interview job-orchestrator runs at 0.3. To pin down a vague request before any context is gathered, use `interviewer` instead."
+description: "Use to clarify implementation-specific ambiguities AFTER context has already been collected and the goal is known — the questions that sharpen a plan, not the ones that scope the request. This is the `implement`-intent interview job-orchestrator runs at 0.3. NOT for: pinning down a vague request before any context is gathered — use `interviewer` instead."
 triggers:
-  - "/interview"
-  - "Interview"
-  - "Clarify requirements"
-  - "Ask questions first"
-  - "What do you need to know"
-  - "Gather requirements"
+  - "implementation interview"
+  - "interview before implementation"
+  - "clarify implementation"
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
-  category: "analysis"
+  category: "planning"
   compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
 ---
@@ -185,3 +182,28 @@ The interview skill is designed to be composable — any skill that needs user i
 - ALWAYS adapt subsequent questions based on previous answers
 - If the user seems impatient or says "just do it" — stop interviewing, document remaining unknowns as assumptions, and proceed
 - One question at a time — never dump all questions at once
+
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "They said 'sounds good', so the whole summary is approved." | A single agreeable noise is not confirmation of a list of decisions, constraints, assumptions and risks. The Assumptions block is labelled "please verify" for a reason — if the user did not address an assumption, it stays an assumption in the output contract, not a confirmed decision. |
+| "The user said 'just do it', so I can drop the unknowns." | Impatience ends the interview; it does not resolve anything. Every remaining uncertainty zone becomes an entry in `assumptions` with the risk it carries. Dropping it hides the guess from the skill that will act on it. |
+| "This is an interesting question, so it belongs in the interview." | The bar is impact: the answer must change the implementation. Questions derivable from the codebase, or whose answers change nothing, spend the user's limited patience on nothing and push the real question past the 7-question ceiling. |
+| "The user picked D) Need more context, so this question is unanswered — move on." | D is a request, not an answer. Explain or run a mini `/brainstorm --quick` on that point, then re-ask. Silently skipping it leaves the highest-uncertainty question the least answered. |
+| "The caller gave me `context`, so I should confirm what it says with the user." | Re-asking what the context already answers is the failure the Phase 2 skip rule names. Read `context` and `known_facts` first; ask only about what neither settles. |
+| "I was dispatched as a subagent with a task, and the task is ambiguous, so I'll interview." | See the SUBAGENT-STOP block at the top: a dispatched subagent proceeds with its assigned task. There is no user on the other end of a dispatch to answer. |
+
+## Verification
+
+Before returning, all of these must hold:
+
+- The output contract has all five keys — `decisions`, `constraints`, `assumptions`, `risks`, `refined_goal` — and none is a placeholder.
+- Every entry in `decisions` carries an `impact` of `high` or `medium` and traces to a question the user actually answered.
+- Anything the user skipped, deferred, or did not address is in `assumptions`, not in `decisions`.
+- No more than 7 questions were asked, one at a time, and none duplicated what `context` or `known_facts` already stated.
+- `refined_goal` is unambiguous enough that a downstream skill could act on it without re-reading the transcript.
+- The Interview Summary was shown and the user was asked "Does this look right?" — and any correction they gave is reflected in the returned contract.
+- In standalone mode, the handoff names the next skill rather than ending with the summary.

package/src/gdskills/bundled/skills/planning/interviewer/SKILL.md

@@ -1,16 +1,18 @@
 ---
 name: interviewer
-description: "Use when a request is ambiguous and must be pinned down BEFORE any context is collected — the entry-point interview that turns a vague or expensive ask into a scoped brief. This is the `custom`-intent gate job-orchestrator runs at 0.1.5. For clarifying implementation specifics AFTER context is already collected, use `interview` instead."
+description: "Use when a request is ambiguous and must be pinned down BEFORE any context is collected — the entry-point interview that turns a vague or expensive ask into a scoped brief. This is the `custom`-intent gate job-orchestrator runs at 0.1.5. NOT for: clarifying implementation specifics AFTER context is already collected — use `interview` instead."
 triggers:
+  - "ask questions"
+  - "clarify requirements"
+  - "interview"
   - "Interview me"
   - "Ask me questions"
-  - "Clarify requirements"
   - "Gather requirements"
   - "What do you need to know"
 metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
-  category: "meta"
+  category: "planning"
   compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
 ---
@@ -43,6 +45,7 @@ context?: {             — optional, provided by calling skill
 ```
 answers: [{question, answer, confidence: "certain"|"assumption"|"unknown"}]
 derived_context: string   — all gathered info as one coherent block
+summary_confidence: "certain"|"assumption"|"unknown"   — weakest confidence in answers
 ready_to_proceed: boolean
 blockers?: string[]       — unresolved critical unknowns
 ```
@@ -82,24 +85,47 @@ blockers?: string[]       — unresolved critical unknowns
 - **Skip if already known** — if context answers a question, don't ask it
 - **Be critical** — focus on questions that would change the approach
 - **Max 8 questions** — stop when enough context is gathered
-- **Confirm before proceeding** — summarize gathered context and ask if correct
+- **Confirm before proceeding** — summarize gathered context, state the summary's own confidence (the weakest of the answers it rests on), and ask if correct
 
 ## Question Bank by Goal Type
 
 ### For implementation goals
 - What is the expected input/output?
 - What are the edge cases that must be handled?
-- Are there existing similar patterns in the codebase to follow?
 - What is the performance/scale requirement?
 - What should NOT be changed (constraints)?
 
 ### For review goals
 - What specific concerns should the review focus on?
-- Are there known existing issues to watch for?
 - What is the acceptance criteria?
 
 ### For architecture/design goals
 - What are the hard constraints (performance, compat, timeline)?
-- What does success look like in 6 months?
 - What are you most worried about?
 - Who else is affected by this decision?
+
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "These three questions are related, so I'll ask them in one message to save time." | One question at a time is the rule, and it is not politeness. A batch gets one answer to the easiest item and silence on the rest, which you then record as if it had been answered. |
+| "The answer was vague, but I understood the gist, so `ready_to_proceed: true`." | A gist is an assumption. Either ask the follow-up, or record the item in `blockers` with `confidence: "assumption"` and leave `ready_to_proceed` false. Proceeding on a gist is exactly the wasted work this gate exists to prevent. |
+| "They said 'sure, that sounds about right', so that is a yes and `ready_to_proceed: true`." | A hedge is not a refusal and it is not approval. This is not the vague-answer case above — you understood the answer perfectly, and it committed the user to nothing. Name the hedge back ("that is a 'probably' — is it a yes?") and ask the question that forces one. If no commitment comes, the item is recorded as `confidence: "assumption"`, never as confirmation. (That a hedged agreement is not approval is adapted (MIT) from [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills); naming the hedge back and the confidence enum are ours.) |
+| "I inferred the answer from the codebase, so I can mark it `certain`." | `certain` means the user said it. An inference is `assumption`, even a good one — the confidence field is the only signal downstream skills have about which parts of `derived_context` are load-bearing guesses. |
+| "I've hit the 8-question limit and still don't know, so I'll pick the likely answer." | The limit is a stop rule, not a licence to invent. Remaining unknowns go into `blockers`, `ready_to_proceed` goes false, and the caller decides. |
+| "Context-collector already ran, so anything still missing must not matter." | Collected context answers what the codebase knows, not what the user intends. Scope, priority and what must NOT change are never in the codebase, and those are the answers that change the approach. |
+| "I was dispatched as a subagent with a task, and the task is unclear, so I'll interview." | See the SUBAGENT-STOP block at the top: a dispatched subagent proceeds with its assigned task. Interviewing from inside a dispatch asks questions nobody is there to answer. |
+
+## Verification
+
+Before returning, all of these must hold:
+
+- Every entry in `answers` carries a question, an answer, and a `confidence` value from the enum — no blank or invented confidences.
+- No question was asked that the provided context already answered, and no two questions were sent in one message.
+- At most 8 questions were asked.
+- Every `assumption` or `unknown` was either resolved with a follow-up or is listed in `blockers`.
+- `summary_confidence` equals the weakest confidence in `answers`, and was stated when the summary was read back — a user approving a summary built on assumptions was told that is what they were approving.
+- `ready_to_proceed` is `false` whenever `blockers` is non-empty, and `true` only after the user confirmed the summarized context.
+- `derived_context` reads as one coherent block a downstream skill can act on, and states which of its claims are assumptions.

package/src/gdskills/bundled/skills/planning/patterns-researcher/SKILL.codex.md

@@ -5,6 +5,10 @@ description: >
   application architecture patterns. Produces constraints that PRD must follow.
   Use when: dispatched by gproject-orchestrator Phase 3.
   NOT for: direct user invocation.
+triggers:
+  - "research patterns"
+  - "architecture patterns"
+  - "best practices"
 metadata:
   version: 1.0.0
   compatible_harnesses: "cursor,codex,zed,opencode"
@@ -29,6 +33,18 @@ and architectural decisions for each technology. The output becomes a set of
 | 5 | Output MUST be structured as checkable constraints, not prose advice |
 | 6 | Existing project patterns (task_in_project) take precedence unless they're antipatterns |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "Clean Architecture is the right answer for any serious project." | Iron Law 2: patterns must fit the chosen level. Layer boundaries and ports-and-adapters on an MVP buy indirection nobody has time to maintain, and Phase 4 is then bound by a constraint that slows every task. |
+| "This is standard practice, so it needs no source." | Iron Law 1: every pattern cites official docs, community consensus, or established practice. Uncited standard practice is how a convention three major versions out of date becomes a binding constraint on the PRD. |
+| "I picked the best option, so listing the alternatives is padding." | Iron Law 3: architecture decisions list the alternatives considered. Without them, the next person to question the decision has to redo the research, and usually re-decides it differently. |
+| "The existing project does this badly, so I'll specify the correct pattern instead." | Iron Law 6: existing patterns win unless they are genuinely antipatterns — and if they are, say so explicitly with the reason. A silent replacement produces a PRD whose constraints contradict the codebase it will be implemented in. |
+| "'Use proper error handling' captures the intent well enough." | Iron Law 5: constraints must be checkable. Phase 5 validates the PRD against these line by line; prose advice passes trivially and constrains nothing. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/patterns-researcher/SKILL.cursor.md

@@ -5,6 +5,10 @@ description: >
   application architecture patterns. Produces constraints that PRD must follow.
   Use when: dispatched by gproject-orchestrator Phase 3.
   NOT for: direct user invocation.
+triggers:
+  - "research patterns"
+  - "architecture patterns"
+  - "best practices"
 metadata:
   version: 1.0.0
   compatible_harnesses: "cursor,codex,zed,opencode"
@@ -29,6 +33,18 @@ and architectural decisions for each technology. The output becomes a set of
 | 5 | Output MUST be structured as checkable constraints, not prose advice |
 | 6 | Existing project patterns (task_in_project) take precedence unless they're antipatterns |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "Clean Architecture is the right answer for any serious project." | Iron Law 2: patterns must fit the chosen level. Layer boundaries and ports-and-adapters on an MVP buy indirection nobody has time to maintain, and Phase 4 is then bound by a constraint that slows every task. |
+| "This is standard practice, so it needs no source." | Iron Law 1: every pattern cites official docs, community consensus, or established practice. Uncited standard practice is how a convention three major versions out of date becomes a binding constraint on the PRD. |
+| "I picked the best option, so listing the alternatives is padding." | Iron Law 3: architecture decisions list the alternatives considered. Without them, the next person to question the decision has to redo the research, and usually re-decides it differently. |
+| "The existing project does this badly, so I'll specify the correct pattern instead." | Iron Law 6: existing patterns win unless they are genuinely antipatterns — and if they are, say so explicitly with the reason. A silent replacement produces a PRD whose constraints contradict the codebase it will be implemented in. |
+| "'Use proper error handling' captures the intent well enough." | Iron Law 5: constraints must be checkable. Phase 5 validates the PRD against these line by line; prose advice passes trivially and constrains nothing. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/patterns-researcher/SKILL.md

@@ -5,6 +5,10 @@ description: >
   application architecture patterns. Produces constraints that PRD must follow.
   Use when: dispatched by gproject-orchestrator Phase 3.
   NOT for: direct user invocation.
+triggers:
+  - "research patterns"
+  - "architecture patterns"
+  - "best practices"
 metadata:
   version: 1.0.0
 ---
@@ -28,6 +32,18 @@ and architectural decisions for each technology. The output becomes a set of
 | 5 | Output MUST be structured as checkable constraints, not prose advice |
 | 6 | Existing project patterns (task_in_project) take precedence unless they're antipatterns |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "Clean Architecture is the right answer for any serious project." | Iron Law 2: patterns must fit the chosen level. Layer boundaries and ports-and-adapters on an MVP buy indirection nobody has time to maintain, and Phase 4 is then bound by a constraint that slows every task. |
+| "This is standard practice, so it needs no source." | Iron Law 1: every pattern cites official docs, community consensus, or established practice. Uncited standard practice is how a convention three major versions out of date becomes a binding constraint on the PRD. |
+| "I picked the best option, so listing the alternatives is padding." | Iron Law 3: architecture decisions list the alternatives considered. Without them, the next person to question the decision has to redo the research, and usually re-decides it differently. |
+| "The existing project does this badly, so I'll specify the correct pattern instead." | Iron Law 6: existing patterns win unless they are genuinely antipatterns — and if they are, say so explicitly with the reason. A silent replacement produces a PRD whose constraints contradict the codebase it will be implemented in. |
+| "'Use proper error handling' captures the intent well enough." | Iron Law 5: constraints must be checkable. Phase 5 validates the PRD against these line by line; prose advice passes trivially and constrains nothing. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/planner/SKILL.codex.md

@@ -4,6 +4,10 @@ description: >
   Generates roadmap, milestones, task breakdown, and dependency graph from PRD.
   Use when: dispatched by gproject-orchestrator Phase 6.
   NOT for: direct user invocation.
+triggers:
+  - "create plan"
+  - "roadmap"
+  - "task breakdown"
 metadata:
   version: 1.0.0
   compatible_harnesses: "cursor,codex,zed,opencode"
@@ -28,6 +32,19 @@ to feed into job-orchestrator or task-implementer.
 | 5 | Each milestone MUST be independently deployable / demonstrable |
 | 6 | Infrastructure and setup tasks come before feature tasks |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "This task is obviously needed even though no user story asks for it." | Iron Law 1: every task traces to a user story. An untraceable task is either scope the PRD did not agree to, or a story the PRD is missing — both are worth surfacing, and neither is fixed by adding the task quietly. |
+| "A single estimate is clearer to read than a three-point range." | Iron Law 3: estimates are ranges. A single number is read as a commitment, and the pessimistic case — the one that decides whether the milestone holds — was never stated. |
+| "These two tasks depend on each other, which is just how the work is." | Iron Law 2: dependencies form a DAG. A cycle means the decomposition is wrong, not that the work is circular. Split one task at the boundary where it stops needing the other. |
+| "Milestone 1 is already large, so this P0 story can move to Milestone 2." | Iron Law 4: P0 stories are in Milestone 1. If M1 is too large, the split goes elsewhere — deferring a P0 silently redefines what the PRD called essential. |
+| "Milestone 2 is a coherent chunk of work, even if it demos nothing on its own." | Iron Law 5: each milestone is independently deployable or demonstrable. A milestone with no demo has no completion signal, and slips are invisible until the next one that does. |
+| "Setup is boring — the feature tasks are what matters for the estimate." | Iron Law 6: infrastructure and setup come first, and they are estimated like anything else. Unestimated setup is the most common reason a critical path is wrong from day one. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/planner/SKILL.cursor.md

@@ -4,6 +4,10 @@ description: >
   Generates roadmap, milestones, task breakdown, and dependency graph from PRD.
   Use when: dispatched by gproject-orchestrator Phase 6.
   NOT for: direct user invocation.
+triggers:
+  - "create plan"
+  - "roadmap"
+  - "task breakdown"
 metadata:
   version: 1.0.0
   compatible_harnesses: "cursor,codex,zed,opencode"
@@ -28,6 +32,19 @@ to feed into job-orchestrator or task-implementer.
 | 5 | Each milestone MUST be independently deployable / demonstrable |
 | 6 | Infrastructure and setup tasks come before feature tasks |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "This task is obviously needed even though no user story asks for it." | Iron Law 1: every task traces to a user story. An untraceable task is either scope the PRD did not agree to, or a story the PRD is missing — both are worth surfacing, and neither is fixed by adding the task quietly. |
+| "A single estimate is clearer to read than a three-point range." | Iron Law 3: estimates are ranges. A single number is read as a commitment, and the pessimistic case — the one that decides whether the milestone holds — was never stated. |
+| "These two tasks depend on each other, which is just how the work is." | Iron Law 2: dependencies form a DAG. A cycle means the decomposition is wrong, not that the work is circular. Split one task at the boundary where it stops needing the other. |
+| "Milestone 1 is already large, so this P0 story can move to Milestone 2." | Iron Law 4: P0 stories are in Milestone 1. If M1 is too large, the split goes elsewhere — deferring a P0 silently redefines what the PRD called essential. |
+| "Milestone 2 is a coherent chunk of work, even if it demos nothing on its own." | Iron Law 5: each milestone is independently deployable or demonstrable. A milestone with no demo has no completion signal, and slips are invisible until the next one that does. |
+| "Setup is boring — the feature tasks are what matters for the estimate." | Iron Law 6: infrastructure and setup come first, and they are estimated like anything else. Unestimated setup is the most common reason a critical path is wrong from day one. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/planner/SKILL.md

@@ -4,6 +4,10 @@ description: >
   Generates roadmap, milestones, task breakdown, and dependency graph from PRD.
   Use when: dispatched by gproject-orchestrator Phase 6.
   NOT for: direct user invocation.
+triggers:
+  - "create plan"
+  - "roadmap"
+  - "task breakdown"
 metadata:
   version: 1.0.0
 ---
@@ -27,6 +31,19 @@ to feed into job-orchestrator or task-implementer.
 | 5 | Each milestone MUST be independently deployable / demonstrable |
 | 6 | Infrastructure and setup tasks come before feature tasks |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "This task is obviously needed even though no user story asks for it." | Iron Law 1: every task traces to a user story. An untraceable task is either scope the PRD did not agree to, or a story the PRD is missing — both are worth surfacing, and neither is fixed by adding the task quietly. |
+| "A single estimate is clearer to read than a three-point range." | Iron Law 3: estimates are ranges. A single number is read as a commitment, and the pessimistic case — the one that decides whether the milestone holds — was never stated. |
+| "These two tasks depend on each other, which is just how the work is." | Iron Law 2: dependencies form a DAG. A cycle means the decomposition is wrong, not that the work is circular. Split one task at the boundary where it stops needing the other. |
+| "Milestone 1 is already large, so this P0 story can move to Milestone 2." | Iron Law 4: P0 stories are in Milestone 1. If M1 is too large, the split goes elsewhere — deferring a P0 silently redefines what the PRD called essential. |
+| "Milestone 2 is a coherent chunk of work, even if it demos nothing on its own." | Iron Law 5: each milestone is independently deployable or demonstrable. A milestone with no demo has no completion signal, and slips are invisible until the next one that does. |
+| "Setup is boring — the feature tasks are what matters for the estimate." | Iron Law 6: infrastructure and setup come first, and they are estimated like anything else. Unestimated setup is the most common reason a critical path is wrong from day one. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/prd-creator/SKILL.md

@@ -1,8 +1,10 @@
 ---
 name: prd-creator
-description: "Use when a vague or unstructured request needs to be converted into a formal, testable Product Requirements Document."
+description: "Use when a vague or unstructured request needs to be converted into a formal, testable Product Requirements Document. NOT for: exploring which option to build before requirements exist (use brainstorm)."
 triggers:
-  - "Create a PRD"
+  - "create PRD"
+  - "product requirements"
+  - "specify feature"
   - "Formulate requirements"
   - "Write a product requirements document"
   - "Draft PRD"
@@ -11,7 +13,7 @@ metadata:
   author: "MrCipherSmith"
   version: "1.0.0"
   category: "planning"
-  compatible_harnesses: "cursor,codex,zed,opencode"
+  compatible_harnesses: "cursor,codex,zed,opencode,claude"
 license: "MIT"
 ---
 
@@ -93,6 +95,8 @@ When generating the final PRD, follow this exact structure:
 ```markdown
 # PRD: {Feature Name}
 
+Version: 0.1.0
+
 ## 1. Overview
 Brief summary of the feature.
 
@@ -145,13 +149,11 @@ Then
 ## 6. Output Location & Format
 
 **Direct Mode:**
-- You MUST follow `rules/core/documentation-management.mdc` for the `requirements` category.
+- You MUST follow `rules/core/requirements-package-standard.mdc` (via `rules/core/documentation-management.mdc` for the `requirements` category).
 - Before saving, ASK the user to confirm the feature name (`<name>`) or to suggest a custom path.
-- The default target path is: `<current_project_root>/docs/requirements/<name>-<YYYY-MM-DD>/`
-- You MUST generate 3 synchronized language variants:
-  - `ru/<name>.md` (Russian for humans)
-  - `en/<name>.md` (English for humans)
-  - `ai/<name>.md` (AI-readable format, heavily using Gherkin)
+- The default target path is: `<current_project_root>/docs/requirements/<name>/prd.md` — no date-stamped folder.
+- If the requirements package (`README.md`, `prd.md`, `specification.md`) does not exist yet, create it; otherwise update `prd.md` in place and bump its `Version` field rather than creating a parallel copy.
+- Default to a single document in the project's documentation language (`en` unless the project states otherwise). Generate additional language variants only when the user explicitly asks for them, and keep any variants you create synchronized.
 - You MUST NOT create a single file in the generic `docs/` root.
 
 **Orchestrated Mode:**
@@ -184,7 +186,22 @@ Before finalizing PRD, the agent MUST verify:
 
 ---
 
-## 9. Intended Usage
+## 9. Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "The request is detailed, so there is nothing left to clarify." | Detail settles *what* to build; it almost never states non-goals, constraints, or how the result will be verified. Those are three of the six checklist items in Section 8, and a long request that omits them is exactly as ambiguous as a short one. |
+| "The missing constraint follows obviously from the stack, so I'll fill it in." | "The agent MUST NOT assume missing context" is a Section 2 prohibition, not advice. An inferred constraint reads in the finished PRD exactly like a confirmed one, and nothing downstream can tell them apart. Ask, or leave the gap visible. |
+| "The acceptance criteria describe the behaviour clearly, so Gherkin is just formatting." | Gherkin forces a concrete Given (the precondition) and a concrete Then (the observable outcome). Prose AC passes review while hiding both. Untestable criteria are a NO on the checklist and block finalization. |
+| "Five of the six checklist items are yes, so I'll finalize and note the sixth." | Any NO stops finalization. A PRD with a noted gap ships as a finished document and the note is the first thing dropped when it is summarized downstream. |
+| "A PRD for this feature already exists, so I'll write mine alongside it." | Section 6 requires updating `prd.md` in place and bumping its `Version`. Two PRDs for one feature means the implementer picks one, and it will not always be the newer. |
+| "I have asked 7 questions and ambiguity remains, so I'll write the PRD as best I can." | The 7-question limit is per iteration, not per request. Return the remaining questions to the user or orchestrator and run another round. |
+
+---
+
+## 10. Intended Usage
 
 Designed for multi-agent orchestration pipelines, such as:
 

package/src/gdskills/bundled/skills/planning/problem-definer/SKILL.codex.md

@@ -4,6 +4,10 @@ description: >
   Defines core problems, goals, non-goals, and success metrics from discovery data.
   Use when: dispatched by gproject-orchestrator Phase 1.
   NOT for: direct user invocation.
+triggers:
+  - "define problem"
+  - "goals non-goals"
+  - "success metrics"
 metadata:
   version: 1.0.0
   compatible_harnesses: "cursor,codex,zed,opencode"
@@ -26,6 +30,18 @@ This phase answers: "Why are we doing this?" and "How will we know we succeeded?
 | 4 | NEVER introduce solutions in the problem statement |
 | 5 | If discovery brief has low confidence areas, flag them — don't paper over |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "'Improve onboarding' is a real goal — the metric can come later." | Iron Law 1: every goal carries a measurable success metric, here. Phase 5 checks each user story against a goal's metric; a goal without one passes every check by being uncheckable. |
+| "The obvious fix is a dashboard, so the problem is 'users have no dashboard'." | Iron Law 4: no solutions in the problem statement. A problem phrased as a missing solution pre-decides the PRD, and the stack and architecture phases then optimise for the wrong thing with nothing to notice. |
+| "Non-goals are filler — two obvious ones are enough." | Iron Law 2 sets a floor of three, and non-goals are the only part of this document that stops scope growth later. The useful ones are the plausible features you are deliberately not building, not the absurd ones. |
+| "The discovery brief was thin on this area, but I can reason my way to the goal." | Iron Law 5: flag low-confidence areas. Reasoning over a gap produces a goal that reads as firm as the evidenced ones, and no later phase can tell them apart. |
+| "This problem is really about the database schema, which is the true root cause." | Iron Law 3: problems are stated from the user's perspective. A technical root cause belongs in the architecture phase; stated here it becomes the thing success is measured against, instead of what the user experiences. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/problem-definer/SKILL.cursor.md

@@ -4,6 +4,10 @@ description: >
   Defines core problems, goals, non-goals, and success metrics from discovery data.
   Use when: dispatched by gproject-orchestrator Phase 1.
   NOT for: direct user invocation.
+triggers:
+  - "define problem"
+  - "goals non-goals"
+  - "success metrics"
 metadata:
   version: 1.0.0
   compatible_harnesses: "cursor,codex,zed,opencode"
@@ -26,6 +30,18 @@ This phase answers: "Why are we doing this?" and "How will we know we succeeded?
 | 4 | NEVER introduce solutions in the problem statement |
 | 5 | If discovery brief has low confidence areas, flag them — don't paper over |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "'Improve onboarding' is a real goal — the metric can come later." | Iron Law 1: every goal carries a measurable success metric, here. Phase 5 checks each user story against a goal's metric; a goal without one passes every check by being uncheckable. |
+| "The obvious fix is a dashboard, so the problem is 'users have no dashboard'." | Iron Law 4: no solutions in the problem statement. A problem phrased as a missing solution pre-decides the PRD, and the stack and architecture phases then optimise for the wrong thing with nothing to notice. |
+| "Non-goals are filler — two obvious ones are enough." | Iron Law 2 sets a floor of three, and non-goals are the only part of this document that stops scope growth later. The useful ones are the plausible features you are deliberately not building, not the absurd ones. |
+| "The discovery brief was thin on this area, but I can reason my way to the goal." | Iron Law 5: flag low-confidence areas. Reasoning over a gap produces a goal that reads as firm as the evidenced ones, and no later phase can tell them apart. |
+| "This problem is really about the database schema, which is the true root cause." | Iron Law 3: problems are stated from the user's perspective. A technical root cause belongs in the architecture phase; stated here it becomes the thing success is measured against, instead of what the user experiences. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/problem-definer/SKILL.md

@@ -4,6 +4,10 @@ description: >
   Defines core problems, goals, non-goals, and success metrics from discovery data.
   Use when: dispatched by gproject-orchestrator Phase 1.
   NOT for: direct user invocation.
+triggers:
+  - "define problem"
+  - "goals non-goals"
+  - "success metrics"
 metadata:
   version: 1.0.0
 ---
@@ -25,6 +29,18 @@ This phase answers: "Why are we doing this?" and "How will we know we succeeded?
 | 4 | NEVER introduce solutions in the problem statement |
 | 5 | If discovery brief has low confidence areas, flag them — don't paper over |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "'Improve onboarding' is a real goal — the metric can come later." | Iron Law 1: every goal carries a measurable success metric, here. Phase 5 checks each user story against a goal's metric; a goal without one passes every check by being uncheckable. |
+| "The obvious fix is a dashboard, so the problem is 'users have no dashboard'." | Iron Law 4: no solutions in the problem statement. A problem phrased as a missing solution pre-decides the PRD, and the stack and architecture phases then optimise for the wrong thing with nothing to notice. |
+| "Non-goals are filler — two obvious ones are enough." | Iron Law 2 sets a floor of three, and non-goals are the only part of this document that stops scope growth later. The useful ones are the plausible features you are deliberately not building, not the absurd ones. |
+| "The discovery brief was thin on this area, but I can reason my way to the goal." | Iron Law 5: flag low-confidence areas. Reasoning over a gap produces a goal that reads as firm as the evidenced ones, and no later phase can tell them apart. |
+| "This problem is really about the database schema, which is the true root cause." | Iron Law 3: problems are stated from the user's perspective. A technical root cause belongs in the architecture phase; stated here it becomes the thing success is measured against, instead of what the user experiences. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/project-discovery/SKILL.codex.md

@@ -4,6 +4,10 @@ description: >
   Collects and structures initial project information from multiple sources.
   Use when: dispatched by gproject-orchestrator Phase 0.
   NOT for: direct user invocation — always called through orchestrator.
+triggers:
+  - "project discovery"
+  - "discover project"
+  - "initial analysis"
 metadata:
   version: 1.0.0
   compatible_harnesses: "cursor,codex,zed,opencode"
@@ -27,6 +31,18 @@ depends on the quality of discovery.
 | 4 | Web research MUST cite sources |
 | 5 | Codebase analysis MUST reference actual file paths |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "The domain is obvious from the request, so `D_domain` is safe to fill in." | Iron Law 1 and 2: an inference is an assumption and must be labelled one. `D_domain` is a decision every later phase treats as settled — an unlabelled guess here becomes a stack choice in Phase 2 nobody re-examines. |
+| "One area has no data, but the rest is solid — I'll note the gap and return `DONE`." | Iron Law 3: a critical area with no data is `NEEDS_CONTEXT` with a concrete A/B/C/D question. A gap recorded as a note is read by the next phase as something already handled. |
+| "I recognise this framework's layout, so I can describe the codebase without opening files." | Iron Law 5 requires actual file paths. A described layout that does not match the repository misdirects every phase that follows, and nothing downstream reads the code again to catch it. |
+| "The best-practice claim is common knowledge, so a citation is ceremony." | Iron Law 4: web research cites sources. Uncited common knowledge is where a stale convention enters the brief and survives to the architecture document as a constraint. |
+| "The user already explained this in the request — restating it in the brief is redundant." | The brief is the only artifact Phase 1 receives; the original request is not passed along. Anything left out of it is lost to the entire pipeline. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/project-discovery/SKILL.cursor.md

@@ -4,6 +4,10 @@ description: >
   Collects and structures initial project information from multiple sources.
   Use when: dispatched by gproject-orchestrator Phase 0.
   NOT for: direct user invocation — always called through orchestrator.
+triggers:
+  - "project discovery"
+  - "discover project"
+  - "initial analysis"
 metadata:
   version: 1.0.0
   compatible_harnesses: "cursor,codex,zed,opencode"
@@ -27,6 +31,18 @@ depends on the quality of discovery.
 | 4 | Web research MUST cite sources |
 | 5 | Codebase analysis MUST reference actual file paths |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "The domain is obvious from the request, so `D_domain` is safe to fill in." | Iron Law 1 and 2: an inference is an assumption and must be labelled one. `D_domain` is a decision every later phase treats as settled — an unlabelled guess here becomes a stack choice in Phase 2 nobody re-examines. |
+| "One area has no data, but the rest is solid — I'll note the gap and return `DONE`." | Iron Law 3: a critical area with no data is `NEEDS_CONTEXT` with a concrete A/B/C/D question. A gap recorded as a note is read by the next phase as something already handled. |
+| "I recognise this framework's layout, so I can describe the codebase without opening files." | Iron Law 5 requires actual file paths. A described layout that does not match the repository misdirects every phase that follows, and nothing downstream reads the code again to catch it. |
+| "The best-practice claim is common knowledge, so a citation is ceremony." | Iron Law 4: web research cites sources. Uncited common knowledge is where a stale convention enters the brief and survives to the architecture document as a constraint. |
+| "The user already explained this in the request — restating it in the brief is redundant." | The brief is the only artifact Phase 1 receives; the original request is not passed along. Anything left out of it is lost to the entire pipeline. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/project-discovery/SKILL.md

@@ -4,6 +4,10 @@ description: >
   Collects and structures initial project information from multiple sources.
   Use when: dispatched by gproject-orchestrator Phase 0.
   NOT for: direct user invocation — always called through orchestrator.
+triggers:
+  - "project discovery"
+  - "discover project"
+  - "initial analysis"
 metadata:
   version: 1.0.0
 ---
@@ -26,6 +30,18 @@ depends on the quality of discovery.
 | 4 | Web research MUST cite sources |
 | 5 | Codebase analysis MUST reference actual file paths |
 
+## Red Flags
+
+Stop and re-read this skill if you are thinking:
+
+| Rationalization | Rebuttal |
+|---|---|
+| "The domain is obvious from the request, so `D_domain` is safe to fill in." | Iron Law 1 and 2: an inference is an assumption and must be labelled one. `D_domain` is a decision every later phase treats as settled — an unlabelled guess here becomes a stack choice in Phase 2 nobody re-examines. |
+| "One area has no data, but the rest is solid — I'll note the gap and return `DONE`." | Iron Law 3: a critical area with no data is `NEEDS_CONTEXT` with a concrete A/B/C/D question. A gap recorded as a note is read by the next phase as something already handled. |
+| "I recognise this framework's layout, so I can describe the codebase without opening files." | Iron Law 5 requires actual file paths. A described layout that does not match the repository misdirects every phase that follows, and nothing downstream reads the code again to catch it. |
+| "The best-practice claim is common knowledge, so a citation is ceremony." | Iron Law 4: web research cites sources. Uncited common knowledge is where a stale convention enters the brief and survives to the architecture document as a constraint. |
+| "The user already explained this in the request — restating it in the brief is redundant." | The brief is the only artifact Phase 1 receives; the original request is not passed along. Anything left out of it is lost to the entire pipeline. |
+
 ---
 
 ## Input Contract

package/src/gdskills/bundled/skills/planning/spec-writer/SKILL.codex.md

@@ -5,6 +5,10 @@ description: >
   architecture doc, and best practices. Does NOT invent new architectural decisions.
   Use when: dispatched by gproject-orchestrator Phase 4.
   NOT for: direct user invocation.
+triggers:
+  - "write spec"
+  - "technical specification"
+  - "implementation plan"
 metadata:
   version: 1.0.0
   compatible_harnesses: "cursor,codex,zed,opencode"