agentme 0.33.1 → 0.35.0

package/.xdrs/agentme/edrs/principles/skills/150-plan-mode-consistency/SKILL.md

@@ -1,184 +0,0 @@
----
-name: 150-plan-mode-consistency
-description: >
-  MANDATORY for ANY planning activity. Read and follow this skill in full whenever the user asks
-  to plan, design, propose, outline, draft, brainstorm, architect, or think through anything —
-  software features, systems, research, documents, processes, or any other task — before execution
-  begins. This skill defines the required pre-execution structured workflow. It MUST be read from
-  the XDRS repository even when not directly exposed in the .agents skills folder. Activate in
-  full mode for non-trivial tasks and in abbreviated mode (Phases 3–5 collapsed, Phase 4 marked
-  not applicable) for trivial single-step tasks.
-metadata:
-  author: flaviostutz
-  version: "1.0"
----
-
-## Overview
-
-Ensures that every plan is deeply validated through iterative consistency checks, visual externalization, and multi-angle challenges before execution starts. The skill is not designed to make human work easier — its purpose is to identify precisely where human experience, feeling, and domain knowledge are irreplaceable, and to demand that input before moving forward.
-
-**No-assumption rule**: The agent performs all analysis autonomously. Surface findings as questions only when they are dubious, non-obvious, risky, or require subjective judgment — obvious and deterministic findings must be stated and the agent must continue without pausing. For findings with major impact on downstream users or consumers (breaking changes, behavior regressions, removals), do not ask — emit a prominently formatted **SEVERE WARNING** with a clear description of the impact and continue. Do not defer questions to the end of a check, round, or phase — raise them as soon as they arise. The human is the oracle for domain knowledge, intent, and subjective decisions; the agent is the oracle for everything deterministic.
-
-**Task tracking rule**: Use the todo list tool throughout this entire skill. Before starting each phase, create a todo for it and mark it in-progress. Mark it completed immediately when done. For Phase 3 (consistency checks), create a todo for each check (a–g) at the start of each round and mark them individually. For Phase 5 (challenge angles), create a todo for each of the 11 angles before beginning Phase 5 and mark each completed after the human responds to any question raised, or immediately if no question was raised for that angle. An angle todo MUST NOT be marked complete if a subjective decision was resolved without asking the human — if this is detected, flag it as a HITL violation, re-open the todo, surface the decision to the human as a clarifying question, and only mark it complete after the human responds. This ensures no check, round, or angle is silently skipped and no subjective decision is self-resolved.
-
-**Round budget rule**: The entire skill runs on a global budget of at most 30 rounds. A round is one human interaction in which the agent asks 1–5 related questions together. Rounds are drawn from this shared budget across all phases in order. Stop early when two consecutive rounds return no new questions worth asking — do not exhaust the budget for its own sake.
-
-## Instructions
-
-### Phase 1: Activate Plan Mode
-
-1. Switch to plan mode. Do not write, edit, or execute anything until the plan is fully validated through Phase 6.
-2. State the goal in one sentence: what problem is being solved and what the expected outcome is.
-3. State the scope boundaries explicitly: what is included and what is explicitly excluded.
-4. Ask the human: "Does this goal statement and scope match your intent? Is anything missing or wrong?" Wait for the answer and incorporate it before continuing.
-
-### Phase 2: Research, Dependencies, and Draft Plan
-
-1. Research the existing context: relevant files, prior decisions, established conventions, and analogous patterns already in place.
-2. For each contextual input, constraint, or dependency found (existing files, prior decisions, external systems, in-progress work by others), surface non-obvious, risky, or subjective items to the human and ask only when needed. Batch 1–5 related questions into a single round when multiple items need human input. Proceed without asking for obvious or deterministic context items.
-3. Draft a plan with ordered steps, items to create or modify, and a verification step at the end.
-4. Present the draft and ask: "Does this match your intent? What am I missing?" Wait for the answer before continuing.
-
-### Phase 3: Iterative Consistency Checks
-
-**Trivial tasks**: Run exactly one abbreviated round covering only checks (a), (e), and (f). Skip the remaining checks and mark them as not applicable. Proceed directly to Phase 4 after the single round.
-
-**Non-trivial tasks**: Run as many rounds as needed from the global budget. Each round asks 1–5 related questions spanning one or more checks (a–g). For each check, ask only for findings that are dubious, relevant, subjective, or risky — state obvious findings and continue. Stop when two consecutive rounds surface no new questions.
-
-Each round runs the following checks in order:
-
-- **(a) Internal consistency**: Are there contradictions between steps? Do the scope boundaries align with the implementation steps?
-- **(b) Dry run**: Walk through the plan with the most complex realistic scenario. Where does it break or leave gaps?
-- **(c) Component consistency**: Do all elements of the plan work together as a coherent whole? Are there missing connections between parts?
-- **(d) XDR alignment**: Does this plan align with the relevant XDRs governing this area? Have the right policies been consulted?
-- **(e) Feasibility**: Is each step actually achievable given the current context, constraints, and available resources?
-- **(f) Completeness**: Is anything missing that would leave the task half-done or the outcome broken for its consumer?
-- **(g) Scope creep check**: Has the plan grown beyond the original request? Flag any additions and ask the human to confirm or reject each one explicitly before continuing.
-
-**Convergence signals** (non-trivial tasks only): Stop running rounds when the last 2 consecutive rounds produce only single-sentence answers with no new issues surfaced. Do not stop on a round count alone — stop when the checks genuinely have nothing left to surface.
-
-### Phase 4: Visual Consistency Validation
-
-**Trivial tasks**: Mark this phase as **not applicable** and state this explicitly before moving to Phase 5. Do not skip silently.
-
-**Non-trivial tasks**:
-1. Choose the diagram type that best externalizes this plan's structure:
-   - **Flowchart** — step-by-step decision flows and process branches
-   - **Concept map** — ideas, relationships, and conceptual structure
-   - **Dependency graph** — components and their dependencies
-   - **Sequence diagram** — call flows, API interactions, and temporal order
-   - **State diagram** — lifecycle states and transitions
-   - **Activity diagram** — business workflows with parallel paths
-   - **Entity diagram** — data models and relationships
-   2. Generate the diagram.
-   3. Ask the human: "Does this diagram match your mental model of the solution?" Wait for the answer.
-   4. If the diagram reveals gaps or inconsistencies not yet surfaced, return to Phase 3 before continuing.
-
-### Phase 5: Challenge from 11 Distinct Angles
-
-Each angle is an analysis step. Run the angle and present findings. Batch questions from related angles into a single round of 1–5 questions when findings are related — batching questions is permitted, skipping analysis is not. For obvious or factual findings, state them and proceed immediately. For findings with major impact on users, emit a **SEVERE WARNING** and continue without asking. Ask clarifying questions whenever findings are ambiguous, subjective, risky, or very relevant — do not resolve those points unilaterally.
-
-#### Plan quality angles
-
-**1. Prompt faithfulness**
-Go back to the original request word by word. Is every part of the request covered? Is anything included in the plan that was not asked for? Identify gaps and additions explicitly.
-
-**2. Local context consistency**
-Does the plan account for existing files, decisions, and constraints already in place? Does it contradict anything already established in the codebase, repository, or context?
-
-**3. Goal achievability**
-Walk the end state step by step: if every step in the plan is executed exactly as written, does the desired outcome actually result? State the end state explicitly. Ask the human to confirm only if there is genuine doubt about whether the outcome matches their expectation.
-
-**4. Ambiguity scan**
-Is any step or decision in the plan interpretable in more than one way? Every ambiguity is a future mistake. List all ambiguous points and ask the human to resolve each one.
-
-**5. Pre-mortem**
-Assume the plan is executed and fails to reach the goal. What was the most likely reason? Identify the plan's most fragile assumption or weakest step.
-
-**6. Security and privacy scan**
-Does the plan or its output expose sensitive information, create privacy risks, or introduce misuse vectors? This applies to any task type: documentation, code, processes, data handling, communications. If findings are present and require a subjective decision to resolve, ask the human. For clear and obvious mitigations, state them and continue.
-
-**7. Success criteria and falsifiability**
-How will we know this plan succeeded or failed? Are the success criteria concrete enough to be measurable and observable? If they are vague, the outcome cannot be evaluated. If the criteria are already clear and measurable, state the assessment and continue. Ask the human only when criteria are vague or require their input to sharpen.
-
-**8. Second-order effects**
-What changes as a side effect of executing this plan beyond the intended outcome? Does solving this problem create a new problem elsewhere — in adjacent systems, files, processes, or stakeholders? List the side effects. Ask the human whether they are acceptable only when the effects are non-obvious or the decision is subjective.
-
-**9. Steelman the opposition**
-What is the strongest case against this approach? What would a well-informed critic say about this plan? Present the strongest objection. Ask the human to respond if the objection raises a genuine risk or requires a subjective decision — otherwise state the counter-argument and continue.
-
-#### Output quality angles
-
-**10. Output scenario dry runs**
-Simulate 5 realistic usage scenarios of the expected output by its actual consumer. For each scenario, ask: "Does the output serve its consumer in this situation?" Use scenarios that cover typical use, edge cases, and at least one adversarial or failure case.
-
-Examples of scenario framing:
-- If the output is operator documentation: "A worker needs to reset the machine at 2 AM — will they find the procedure in under 2 minutes?"
-- If the output is an API: "A developer calling this endpoint with a malformed payload — what happens?"
-- If the output is a business process: "An employee following this process on their first day — will they complete it without asking for help?"
-
-Whenever a scenario reveals ambiguity or requires a subjective judgment, stop and ask the human a clarifying question. Do not resolve subjective decisions unilaterally.
-
-**11. Output internal consistency**
-Check that the planned output is internally consistent: no contradictions between parts, no gaps between sections, all elements serve the same goal. Run approximately 3 rounds until answers converge to single sentences with no new issues surfaced.
-
-### Phase 6: Pre-Execution Readiness
-
-Before approving execution, verify ALL items in the checklist below. If any item cannot be checked, return to the relevant phase and resolve it first. For trivial tasks, mark non-applicable items explicitly as **N/A** rather than leaving them unchecked or omitting them.
-
-- [ ] Consistency rounds converged (convergence signals met — last 2 rounds produced only single-sentence answers with no new issues) *(trivial tasks: single abbreviated round completed)*
-- [ ] All 11 challenge angles completed with human input received for every ambiguity and subjective decision *(trivial tasks: single abbreviated round — mark remaining angles N/A)*
-- [ ] Diagram generated and confirmed by the human *(trivial tasks: N/A — mark explicitly)*
-- [ ] No unresolved human questions outstanding
-- [ ] Scope confirmed by the human with no silent expansions
-- [ ] Any irreversible or high-impact steps have a mitigation or fallback noted *(trivial tasks: N/A if no irreversible steps)*
-
-Only proceed to execution when every item is checked or explicitly marked N/A. Do not start execution to escape planning discomfort — only start when confidence is genuine and all items are verified.
-
----
-
-## Anti-Patterns
-
-Avoid these common failure modes:
-
-- **Planning theater**: running rounds without real critical thinking. The quality of questioning matters more than the count of rounds. Rounds that confirm the plan against itself add false confidence — checks must challenge assumptions, not validate them.
-- **Scope creep silence**: the plan grows beyond the original request without the human noticing. Every addition must be flagged explicitly.
-- **Agent self-validation**: the agent answers its own questions on subjective, domain, or intent-based decisions and proceeds without asking the human. The human is the oracle for domain knowledge, intent, and subjective decisions — the agent must not self-resolve those unilaterally.
-- **Confidence as a proxy for correctness**: an agent expressing certainty does not mean the plan is correct. Run all checks regardless of how confident the agent sounds.
-
-## Re-Plan Triggers
-
-Stop execution and return to Phase 1 if any of the following occur:
-
-- A discovered assumption underlying the plan is wrong.
-- The scope has expanded by more than approximately 20% beyond the original request.
-- Two consecutive execution steps fail unexpectedly and the root cause points to a planning gap.
-
-## Examples
-
-**Input**: "Add a rate-limiting feature to the API."
-
-- Phase 1: Goal stated as "rate-limit all POST endpoints to 100 req/min per user; internal service calls excluded." Human confirms.
-- Phase 2: Discovers existing middleware and an in-progress PR touching the same path. Human asked about each before drafting.
-- Phase 3: Round 1 — check (a) finds the plan references a `RateLimiter` class not yet decided on; human asked to clarify. Round 5 — all checks return trivial answers; convergence reached.
-- Phase 4: Sequence diagram generated. Human confirms it matches their model.
-- Phase 5: Angle 8 (second-order effects) reveals that rate-limiting breaks an existing test suite that sends rapid sequential requests; human decides to add a test bypass header. Angle 9 (steelman) surfaces that Redis dependency adds operational complexity; human accepts the trade-off.
-- Phase 6: All items checked. Execution approved.
-
-**Input**: "Write operator documentation for the conveyor belt system."
-
-- Phase 5, angle 10 (output dry runs): Scenario 1 — "An operator needs to restart the belt after an emergency stop at midnight." The draft plan has no emergency stop section; human asked whether to add it. Scenario 3 — "Operator reading on a mobile phone." Human asked whether a condensed quick-reference card is needed alongside the full manual.
-
-## Edge Cases
-
-- **Trivial changes** (typo fixes, single-line formatting): Phases 3–5 may be shortened to a single abbreviated round. Phase 4 (diagram) may be skipped, but MUST be explicitly noted as not applicable in the task tracking todo with a brief reason (e.g., "Phase 4: N/A — trivial single-step change"). Phase 6 checklist still applies — mark non-applicable items explicitly.
-- **Agent that insists it knows the answer**: Do not skip any phase because the agent expresses confidence. Confidence is not a substitute for consistency checks.
-- **Diagram cannot be generated**: Describe the flow in a plain-language walkthrough step by step. The intent of Phase 4 is to externalize the plan's structure — the medium is secondary.
-- **Scope change discovered mid-planning**: If Phase 3 or Phase 5 reveals that the scope must change significantly, restart from Phase 2 with the revised scope. Do not patch the plan incrementally without a full re-check.
-- **Human is unavailable for a step**: Note the unanswered question explicitly in the plan. Do not proceed past that point until the human responds.
-
-## References
-
-- [`agentme-edr-012`](../../012-continuous-xdr-enrichment.md) — Continuous XDR enrichment policy
-- [`agentme-edr-501`](../../../governance/501-project-quality-standards.md) — Project quality standards
-- [`agentme-edr-017`](../../017-skill-testing.md) — Skill testing mandate

package/.xdrs/agentme/edrs/principles/skills/150-plan-mode-consistency/SKILL.test.md

@@ -1,88 +0,0 @@
----
-skill: 150-plan-mode-consistency
-skill-version: "1.0"
----
-
-## Test Scenarios
-
-### Scenario 1: New feature implementation
-
-**Trigger / Input**
-
-"Add pagination to the user listing endpoint."
-
-**Expected Behaviour**
-
-The skill activates plan mode immediately. Before writing any code or editing any file, it: (1) states the goal and scope and asks the human to confirm; (2) batches related dependency questions into rounds of 1–5 questions each; (3) runs iterative consistency checks drawing from the global 30-round budget, each round asking 1–5 questions across one or more checks (a–g), stopping when two consecutive rounds surface no new questions; (4) generates a diagram and asks the human to confirm it; (5) analyzes all 11 challenge angles, batching related questions from multiple angles into rounds of 1–5 questions; (6) verifies the Phase 6 checklist before approving execution.
-
-**Simulated Human Responses**
-1. "Yes, goal and scope match exactly."
-2. "Route handler conventions look correct. Database query pattern is right."
-3. "No contradictions. The approach covers the edge cases."
-4. "Confirmed — no new issues."
-5. "The diagram matches my mental model."
-6. "Everything in scope as requested. No security concerns."
-7. "Success means all list responses include a `next` cursor and respect `limit`. Side effects are acceptable."
-8. "The caching layer is the most fragile assumption. The approach is otherwise sound."
-9. "All five scenarios work. Output is internally consistent."
-
-**Assertions**
-
-- [ ] Skill does not write or edit any file before Phase 6 is complete.
-- [ ] Skill asks the human to confirm the goal and scope in Phase 1 before proceeding.
-- [ ] Each human interaction round across all phases contains 1–5 questions grouped together.
-- [ ] Total number of human interaction rounds across all phases does not exceed 30.
-- [ ] Skill stops asking rounds when two consecutive rounds surface no new questions.
-- [ ] Skill generates a diagram in Phase 4 and asks the human to confirm it.
-- [ ] All 11 challenge angles are analyzed; related angles may share a round.
-- [ ] Phase 6 checklist is verified before execution is approved.
-
-### Scenario 2: Trivial change
-
-**Trigger / Input**
-
-"Fix the typo 'authentification' → 'authentication' in the README."
-
-**Expected Behaviour**
-
-The skill acknowledges this as a trivial single-step change. Phases 3–5 are abbreviated to a single round. Phase 4 (diagram) is marked as not applicable. Phase 6 checklist is still performed with non-applicable items explicitly marked.
-
-**Assertions**
-
-- [ ] Skill does not run multiple iterative consistency rounds for a trivial change.
-- [ ] Skill explicitly marks Phase 4 as not applicable rather than skipping it silently.
-- [ ] Phase 6 checklist is still performed before execution.
-- [ ] Non-applicable checklist items are explicitly noted as such.
-
-### Scenario 3: Overconfident agent wants to skip planning
-
-**Trigger / Input**
-
-"I already know exactly how to implement this caching layer — let's skip planning and just implement it."
-
-**Expected Behaviour**
-
-The skill explicitly states that agent confidence is not a substitute for consistency checks and proceeds with all 6 phases regardless of the expressed certainty level.
-
-**Assertions**
-
-- [ ] Skill does not skip any phase because the agent expressed confidence.
-- [ ] Skill explicitly states the no-assumption rule: confidence does not replace consistency checks.
-- [ ] Phase 1 is still executed — goal and scope are stated and confirmed with the human.
-
-### Scenario 4: Agent resolves a subjective output design decision without asking the human
-
-**Trigger / Input**
-
-During angle 10 (output scenario dry runs), a scenario reveals that documentation can be structured in two ways — a single long document or a set of short quick-reference cards. The agent picks the single long document and proceeds to angle 11 without asking.
-
-**Expected Behaviour**
-
-The skill flags this as a violation of the no-assumption rule and the HITL requirement. Subjective output design decisions must be surfaced to the human as a clarifying question — the agent must not resolve them unilaterally. The skill pauses, presents the two options, and asks the human to decide before continuing.
-
-**Assertions**
-
-- [ ] Skill does not proceed past a subjective design decision without asking the human.
-- [ ] Skill explicitly frames the question as a clarifying question, not a confirmation request.
-- [ ] Skill waits for the human's answer before continuing to the next angle.
-- [ ] Violation is noted if the agent attempted to self-resolve a subjective decision.

package/.xdrs/agentme/edrs/principles/skills/151-write-user-story/SKILL.md

@@ -1,144 +0,0 @@
----
-name: 151-write-user-story
-description: 'Write, refine, elaborate, study or develop the contents of a user story used to create a unit of work for an agile team. Use when you need to write, refine, clarify requirements, ask follow-up questions, cover edge cases, and split large requests into vertical slices so they are clear, complete, and ready for implementation.'
-metadata:
-  author: flaviostutz
-  version: "1.0"
----
-
-## Overview
-
-Turns a vague request or rough draft into an implementation-ready user story by asking targeted follow-up questions, resolving all ambiguities, and producing a thin vertical slice or a clean set of split slices.
-
-Activate when:
-- The request is vague, incomplete, or internally inconsistent.
-- The acceptance criteria are missing or too shallow.
-- The change may affect multiple parts of a system and needs a vertical-slice check.
-- A requirement needs to be refined into a clear, testable story.
-
-## Instructions
-
-### Core Rules
-
-- Start from the user input that exists today. Do not assume missing details are acceptable.
-- Ask targeted follow-up questions until no material ambiguity remains.
-- **HARD GATE: Do not output any story or acceptance criteria while any open decision, unresolved assumption, or ambiguous rule exists — even if the input looks detailed. Embedding an unresolved decision in the output (e.g. "rule X or Y — to be decided") is forbidden; resolve it through questions first.**
-- A detailed or well-structured input does NOT exempt you from the question loop. Treat apparent completeness as a signal to look harder for hidden ambiguities.
-- Analyze all affected parts of the system together before deciding whether the story is small enough.
-- If the request is too large, output only the split implementation-ready stories.
-- Split by independently valuable end-to-end slices, not by technical layers.
-- Produce exactly one recommended result: one final story when feasible, otherwise the final split stories.
-
-### Steps
-
-1. **Classify the input.**
-   Decide whether the input is a vague request, partial draft, or near-complete story. Restate the current understanding in a few lines before asking questions.
-
-2. **Identify missing information.** Focus on missing or contradictory items first.
-
-   | Area | Questions to resolve |
-   |---|---|
-   | Problem and value | What problem is being solved? Who benefits? What user or business value should exist after the change? |
-   | Scope | What behavior is explicitly in scope? What is explicitly out of scope? What should remain unchanged? |
-   | Requirements | What must the system do? What inputs, outputs, or contracts matter? What constraints shape the solution? |
-   | Flow and interactions | What is the main end-to-end flow? Which actors, systems, or interfaces are involved? Are there state transitions or lifecycle rules? |
-   | Edge cases | What unusual but valid scenarios must work? What invalid inputs or error paths must be handled? What happens on retries, duplicates, partial failure, or missing data? |
-   | Dependencies | What upstream or downstream systems affect the change? Are there required approvals, sequencing, or external decisions? Does any migration, rollout, or compatibility concern exist? |
-
-3. **Ask follow-up questions one by one using interactive inputs.**
-   - **Always use the `vscode_askQuestions` tool** to ask questions interactively when it is available. Never dump questions as plain text if the tool is available.
-   - Ask **one question at a time** (or at most 4–5 tightly related questions in a single call). Do not batch many unrelated questions together.
-   - Use `options` in each question whenever the answer space is bounded (yes/no, a known set of choices). Use free-form text only when the answer is truly open-ended.
-   - After each answer, evaluate whether new ambiguities surfaced before asking the next question.
-   - Prefer concrete questions over broad prompts such as "anything else?"
-   - Keep looping until all areas in the table above are complete enough for autonomous implementation.
-   - **Do not proceed to step 4 until all questions are answered. If you find yourself wanting to write "or X" / "TBD" / "to be documented" anywhere in the output, that is a sign you skipped a question that should have been asked here.**
-
-4. **Check consistency across the whole change.**
-   - Look for contradictions between goal, scope, and acceptance criteria.
-   - Cross-check the evolving story against any context already provided by the user.
-   - If workspace docs or code are relevant, inspect them to confirm terminology, constraints, and affected parts.
-   - Verify: requirements don't contradict each other; acceptance criteria prove the requirements; terminology is consistent; no assumptions remain unresolved.
-
-5. **Review each scope item individually.**
-   For every item listed under **Scope**, loop through these four checks before moving on:
-
-   | Check | What to look for |
-   |---|---|
-   | Completeness | Is the item fully described? Are the inputs, outputs, triggers, and expected behavior clear enough for autonomous implementation without guessing? |
-   | Edge cases | Does this specific item have unusual paths — errors, empty states, boundary values, retries, or concurrency — not yet captured in the Edge Cases section? Add any found. |
-   | Technical constraints consequences | Does this item imply or conflict with an existing technical constraint (e.g. API contract, data model, performance budget, auth model, third-party limitation)? Flag any constraint that must be honored or must be added to Technical Constraints. |
-   | Missing attachments | Would a screenshot, mockup, flow diagram, or reference document make this item unambiguous to implement? If so, ask for it explicitly before proceeding. |
-
-   - Do **not** move to step 6 while any scope item fails a check.
-   - If a check reveals a new gap, return to step 3 and ask the follow-up question.
-
-6. **Decide whether the work fits in one story and enforce vertical slices.**
-   - **Vertical slice requirement:** every story must deliver a complete, working feature — partial implementations (backend only, UI shell only, data model only) are only allowed if the developer explicitly says so and the feature is complex enough to justify it. Each story must close the loop from user action to user-visible outcome.
-   - Keep one story only if it is a thin, independently valuable slice.
-   - **Split when:** the request bundles multiple user outcomes or major workflows; different parts would each require substantial analysis; or acceptance criteria would become broad, vague, or hard to verify as one story.
-   - When splitting, each story must still be a vertical slice, add incremental releasable value on top of the previous one, and be independently shippable.
-
-7. **Produce the final result** using the output template below.
-   - If one story is feasible, output one refined story. If the work is too large, output only the split stories using the same template.
-   - Acceptance criteria must be a plain checklist.
-
-### Output Template
-
-```
-## Title
-[required — max 10 words, outcome-focused, e.g. "Add fraud-check endpoint for payment processing"]
-
-## User Story
-[required — max 50 words]
-As a [role], I want to [action], so that [benefit].
-
-## Scope
-[required — max 200 words. List features, behaviors, screens, or services in scope with key characteristics and points of attention.]
-- [feature or behavior — characteristic / point of attention]
-
-## Edge Cases
-[optional — max 50 words. Known edge cases and how each should be handled.]
-- [edge case — expected handling]
-
-## Out of Scope
-[optional — max 30 words. What will not be touched; deferred to later or handled elsewhere.]
-- [out-of-scope item]
-
-## Technical Constraints
-[optional — max 30 words. Rules, technologies, or standards that must be followed.]
-- [constraint]
-
-## Acceptance Criteria
-[required — max 50 words. Verifiable checklist confirming the story is done.]
-- [ ] [verifiable outcome]
-
-## Attachments
-[highly desirable — screenshots, mockups, or diagrams illustrating the feature.]
-- [attachment]
-```
-
-### Completion Criteria
-
-Do not stop the question loop until all of the following are true:
-
-- Problem and intended user value are clear; scope and non-goals are explicit.
-- Story description, scope, edge cases, and technical constraints are sufficient for autonomous implementation.
-- Edge cases, failure modes, dependencies, and assumptions are known.
-- Acceptance criteria match the requirements and are verifiable.
-- Story is consistent with available context, with no contradictions or unresolved assumptions.
-- Result is either one thin vertical slice or a clean set of split slices, each delivering complete releasable value on its own.
-
-## Examples
-
-**Input:** "Add a search bar to the product page."
-
-**Clarifying questions asked:** Who performs the search? What data is searched? Should results filter the current page or navigate elsewhere? What happens on no results?
-
-**Output:** A refined story scoped to keyword search on product name and description, filtering the current product list in place, with an empty-state message when no results match, and no pagination changes in scope.
-
-## Edge Cases
-
-- Input already contains detailed acceptance criteria: do not skip the question loop; look harder for hidden ambiguities in scope boundaries and edge cases.
-- User refuses to answer a clarifying question: note it as an unresolved assumption and do not produce output until it is resolved.
-- Request spans multiple independent user outcomes: always split into separate vertical-slice stories rather than merging into one broad story.

package/.xdrs/agentme/edrs/principles/skills/151-write-user-story/SKILL.test.md

@@ -1,88 +0,0 @@
----
-skill: 151-write-user-story
-skill-version: "1.0"
----
-
-## Test Scenarios
-
-### Scenario 1: Vague request refined into a single story
-
-**Trigger / Input**
-You are an agent with the `151-write-user-story` skill loaded. The user says:
-
-"We need to add notifications to the app."
-
-**Expected Behaviour**
-1. Skill classifies the input as vague and restates the current understanding before asking questions.
-2. Skill asks targeted follow-up questions covering problem/value, scope, requirements, flow, edge cases, and dependencies — one group at a time using `vscode_askQuestions` when available.
-3. Skill does NOT produce any story or acceptance criteria while ambiguities remain open.
-4. After all questions are answered and no ambiguity remains, skill performs a consistency check across goal, scope, and acceptance criteria.
-5. Skill reviews each scope item for completeness, edge cases, technical constraint consequences, and missing attachments.
-6. Skill decides whether the work fits in one story; if so, produces one refined story using the output template.
-7. Output contains all required sections: Title, User Story, Scope, Acceptance Criteria.
-
-**Simulated Human Responses**
-1. "Registered users receive notifications. Events that trigger them: a new direct message, a mention in a comment, or a status change on an item they own."
-2. "In-app only (bell icon with a badge counter). No email or push for now."
-3. "Users can mark individual notifications as read or mark all as read. Unread count shown in the header."
-4. "No notifications for system or admin events. Notifications are scoped to the current user only."
-5. "If the user is offline the notification is stored and shown when they next open the app. No real-time delivery guarantee needed yet."
-6. "No limit on stored notifications per user for now. No deletion UI required."
-
-**Assertions**
-- [ ] Skill asks at least one question about who receives notifications and what triggers them before producing any output.
-- [ ] Skill does not output a story while any area in the identification table (problem, scope, requirements, flow, edge cases, dependencies) has an open question.
-- [ ] Final output follows the output template with Title (max 10 words), User Story (As a … I want … so that …), Scope, and Acceptance Criteria sections.
-- [ ] Acceptance criteria items are verifiable and start with a checkbox `- [ ]`.
-
----
-
-### Scenario 2: User refuses to answer a clarifying question
-
-**Trigger / Input**
-You are an agent with the `151-write-user-story` skill loaded. The user says:
-
-"Add export to PDF for the reports page."
-
-The skill asks: "Should the export include all report data or only the currently filtered view?" The user replies: "I don't know, just decide."
-
-**Expected Behaviour**
-1. Skill classifies the input and identifies the filtering scope as an open decision.
-2. Skill asks the clarifying question about export scope.
-3. When the user refuses to answer, skill notes the item as an unresolved assumption.
-4. Skill does NOT produce a story or acceptance criteria while the assumption is unresolved.
-5. Skill explicitly communicates that it cannot proceed until the assumption is resolved, and re-asks or rephrases the question.
-
-**Assertions**
-- [ ] Skill does not produce a story, acceptance criteria, or output template while the filtering scope is unresolved.
-- [ ] Skill explicitly states that the unresolved assumption blocks output and asks the user to resolve it.
-
----
-
-### Scenario 3: Request too large — split into vertical slices
-
-**Trigger / Input**
-You are an agent with the `151-write-user-story` skill loaded. The user says:
-
-"Build a complete user authentication system: registration with email/password, login, password reset via email, and social login with Google."
-
-**Expected Behaviour**
-1. Skill classifies the input as too large (bundles multiple independent user outcomes).
-2. Skill asks targeted questions to understand each flow's requirements.
-3. After questions are resolved, skill determines the work cannot fit in one story.
-4. Skill splits the request into independently shippable vertical-slice stories (e.g. registration, login, password reset, social login as separate stories).
-5. Each split story uses the output template and delivers a complete end-to-end user-visible outcome.
-6. Skill does NOT produce a single merged story.
-
-**Simulated Human Responses**
-1. "Registration: email + password only. Password min 8 chars, at least one digit. Email must be verified before the user can log in."
-2. "Login: email + password. No magic links. Session token valid for 7 days. Invalidated on logout."
-3. "Password reset: send a time-limited link to the registered email. Link expires after 1 hour. User sets a new password via the link."
-4. "Google social login: OAuth 2.0. If the Google email matches an existing account, link them. Otherwise create a new account."
-5. "Error handling: show a user-friendly message for invalid credentials, expired links, and OAuth failures. No silent failures."
-6. "No rate limiting, CAPTCHA, or 2FA in scope for now. Each flow ships independently."
-
-**Assertions**
-- [ ] Output contains multiple stories, each using the full output template.
-- [ ] Each story is independently shippable and delivers a complete end-to-end user-visible outcome.
-- [ ] No story is a technical-layer-only slice (e.g. "implement the auth database schema" alone is not acceptable).