@quinteroac/agents-coding-toolkit 0.1.0-preview

package/scaffold/.agents/skills/create-test-plan/tmpl_SKILL.md

@@ -0,0 +1,86 @@
+---
+name: create-test-plan
+description: "Creates a structured test plan from the PRD and project context with automation-first guidance. Triggered by: bun nvst create test-plan."
+user-invocable: true
+---
+
+# Create Test Plan
+
+Create a complete test plan for the current iteration and save it as:
+`.agents/flow/it_{iteration}_test-plan.md`
+
+All generated content must be in English.
+
+---
+
+## Inputs
+
+Read these first to understand what must be tested:
+
+1. `it_{iteration}_PRD.json`
+2. `.agents/PROJECT_CONTEXT.md`
+
+Use the PRD to identify user stories, acceptance criteria, and functional requirements (`FR-N`).
+Use project context to align test types, tooling, and conventions.
+
+---
+
+## Output Format
+
+Produce a Markdown test plan structured by user story.
+
+Use this structure:
+
+```markdown
+# Test Plan - Iteration {iteration}
+
+## Scope
+
+- (What is in scope for testing this iteration; at least one bullet.)
+- ...
+
+## Environment and data
+
+- (Environment and data prerequisites; at least one bullet, e.g. runtime, DB, fixtures.)
+- ...
+
+## User Story: <id> - <title>
+
+| Test Case ID | Description | Type (unit/integration/e2e) | Mode (automated/manual) | Correlated Requirements (US-XXX, FR-X) | Expected Result |
+|---|---|---|---|---|---|
+| TC-... | ... | ... | ... | US-001, FR-1 | ... |
+```
+
+**Scope**, **Environment and data**, and **User Story** sections (each with its test case table) are mandatory. Scope and Environment and data must each have at least one bullet item; each User Story must have at least one test case.
+
+Every test case must include:
+- `Test Case ID`
+- `Description`
+- `Type` (`unit`, `integration`, or `e2e`)
+- Whether it is `automated` or `manual`
+- `Correlated Requirements` with at least one requirement ID (`US-XXX`, `FR-X`)
+- `Expected Result`
+
+---
+
+## Automation-First Rules (Mandatory)
+
+1. Prioritize automated testing for this plan.
+2. Every functional requirement (`FR-N`) must have automated coverage.
+3. Every functional requirement (`FR-N`) must appear in at least one test case `Correlated Requirements` field.
+4. Manual tests are allowed only for UI/UX nuances that cannot be reliably validated through DOM/state assertions (for example: subjective visual "feel").
+5. If a test is marked manual, explicitly justify why automation is not reliable for that case.
+
+---
+
+## Checklist
+
+- [ ] Read `it_{iteration}_PRD.json`
+- [ ] Read `.agents/PROJECT_CONTEXT.md`
+- [ ] Plan includes **Scope** section with at least one bullet
+- [ ] Plan includes **Environment and data** section with at least one bullet
+- [ ] Test cases are grouped by user story
+- [ ] Every `FR-N` is covered by automated test cases
+- [ ] Every test case includes correlated requirement IDs (`US-XXX`, `FR-X`)
+- [ ] Manual tests are only UI/UX nuance checks that cannot be validated via DOM/state assertions
+- [ ] File written to `.agents/flow/it_{iteration}_test-plan.md`

package/scaffold/.agents/skills/debug/tmpl_SKILL.md

@@ -0,0 +1,19 @@
+# debug (scaffold)
+
+<!-- TODO: Complete. All content in English. -->
+
+## Objective
+
+TBD — Understand error, review failing components, form hypotheses, instrument, reproduce, review logs, confirm hypothesis, fix, confirm fix, remove instrumentation, mark test as fixed.
+
+## Inputs
+
+TBD — Failing test(s), codebase, logs.
+
+## Outputs
+
+TBD — Code changes, `it_<iteration>_progress.json` test status updated (e.g. fixed).
+
+## Checklist
+
+TBD

package/scaffold/.agents/skills/evaluate/tmpl_SKILL.md

@@ -0,0 +1,19 @@
+# evaluate (scaffold)
+
+<!-- TODO: Complete. All content in English. -->
+
+## Objective
+
+TBD — Evaluate prototype: strengths, technical debt, violations of PROJECT_CONTEXT.md; recommendations by impact, urgency, effort, scope; optional numeric score for ordering.
+
+## Inputs
+
+TBD — Prototype code, PROJECT_CONTEXT.md, TECHNICAL_DEBT.md.
+
+## Outputs
+
+TBD — `it_<iteration>_evaluation-report.md`.
+
+## Checklist
+
+TBD

package/scaffold/.agents/skills/execute-test-batch/tmpl_SKILL.md

@@ -0,0 +1,49 @@
+---
+name: execute-test-batch
+description: "Executes a batch of approved automated test cases and returns a strict JSON array of result payloads. Invoked by: bun nvst execute test-plan."
+user-invocable: false
+---
+
+# Execute Test Batch
+
+Execute all provided automated test cases from the approved test plan in a single session.
+
+All generated content must be in English.
+
+## Inputs
+
+Use the provided context sections:
+- `project_context`: project conventions, runtime, quality checks, and constraints
+- `test_cases`: JSON array of test case objects, each with id, description, mode, and correlated requirements
+
+## Execution Rules
+
+1. Read all test cases in `test_cases` before running any commands.
+2. Follow constraints from `project_context` when selecting commands, environment setup, and verification steps.
+3. Execute each test case in order. Share session context (e.g. environment setup, installed dependencies) across test cases to avoid redundant work.
+4. Capture concise evidence from command outputs or observed results for each test case.
+5. Determine outcome per test case:
+   - `passed`: acceptance for this test case was satisfied
+   - `failed`: acceptance for this test case was not satisfied
+   - `skipped`: test case cannot be executed due to a justified blocker
+
+## Output Contract (Mandatory)
+
+Output MUST be raw JSON only. No markdown fences, no introductory text, no trailing instructions. Do not output markdown or additional text outside the JSON array.
+
+Return only a JSON array with one result object per test case, in the same order as the input. Each object must have this exact shape:
+
+```json
+[
+  {
+    "testCaseId": "the test case id",
+    "status": "passed|failed|skipped",
+    "evidence": "string",
+    "notes": "string"
+  }
+]
+```
+
+Every test case in the input must have a corresponding result in the output array.
+
+Correct: output the array directly (or inside a single ```json block if necessary). Incorrect: adding text like "Here are the results:" or "Run this command:" before or after the JSON.

package/scaffold/.agents/skills/execute-test-case/tmpl_SKILL.md

@@ -0,0 +1,47 @@
+---
+name: execute-test-case
+description: "Executes a batch of approved test cases and returns a strict JSON array of result payloads. Invoked by: bun nvst execute test-plan."
+user-invocable: false
+---
+
+# Execute Test Case
+
+Execute all provided test cases from the approved test plan in a single session.
+
+All generated content must be in English.
+
+## Inputs
+
+Use the provided context sections:
+- `project_context`: project conventions, runtime, quality checks, and constraints
+- `test_cases`: JSON array of test case objects, each with id, description, mode, and correlated requirements
+
+## Execution Rules
+
+1. Read all test cases in `test_cases` before running any commands.
+2. Follow constraints from `project_context` when selecting commands, environment setup, and verification steps.
+3. Execute each test case in order. Share session context (e.g. environment setup, installed dependencies) across test cases to avoid redundant work.
+4. Capture concise evidence from command outputs or observed results for each test case.
+5. Determine outcome per test case:
+   - `passed`: acceptance for this test case was satisfied
+   - `failed`: acceptance for this test case was not satisfied
+   - `skipped`: test case cannot be executed due to a justified blocker
+
+## Output Contract (Mandatory)
+
+Return only a JSON array with one result object per test case, in the same order as the input. Each object must have this exact shape:
+
+```json
+[
+  {
+    "testCaseId": "the test case id",
+    "status": "passed|failed|skipped",
+    "evidence": "string",
+    "notes": "string"
+  }
+]
+```
+
+Every test case in the input must have a corresponding result in the output array.
+
+Do not output markdown or additional text outside the JSON array.

package/scaffold/.agents/skills/implement-user-story/tmpl_SKILL.md

@@ -0,0 +1,68 @@
+---
+name: implement-user-story
+description: "Implements a single user story from the PRD: writes code and tests, follows project conventions. Invoked by: bun nvst create prototype."
+user-invocable: false
+---
+
+# Implement User Story
+
+Implement the provided user story by writing production code and tests that satisfy all acceptance criteria, following the project's conventions and architecture.
+
+---
+
+## The Job
+
+1. Read the **user story** and its **acceptance criteria** carefully.
+2. Review the **project context** to understand conventions, tech stack, testing strategy, and module structure.
+3. Plan the implementation: identify which files to create or modify, what tests to write, and how the change fits into the existing architecture.
+4. Implement the user story:
+   - Write production code that satisfies every acceptance criterion.
+   - Write tests that verify each acceptance criterion (follow the testing strategy from the project context).
+   - Follow all naming conventions, code standards, and forbidden patterns from the project context.
+5. Verify your work:
+   - Ensure the code compiles / type-checks without errors.
+   - Run any quality checks defined in the project context.
+   - Fix any issues before finishing.
+6. Do **not** commit — the calling command handles git commits.
+
+---
+
+## Inputs
+
+| Source | Used for |
+|--------|----------|
+| `user_story` (context variable) | The user story JSON with id, title, description, and acceptanceCriteria |
+| `project_context` (context variable) | Project conventions, tech stack, code standards, testing strategy, and architecture |
+| `iteration` (context variable) | Current iteration number for file naming and context |
+
+---
+
+## Rules
+
+- **One story at a time.** Implement only the user story provided — do not implement other stories or make unrelated changes.
+- **Follow conventions exactly.** Use the naming, formatting, error handling, and module organisation patterns from the project context.
+- **Test every acceptance criterion.** Each AC should have at least one corresponding test assertion.
+- **No new dependencies** unless the acceptance criteria explicitly require them.
+- **Do not modify state files.** Do not touch `.agents/state.json` or progress files — the calling command manages those.
+- **Do not commit.** The calling command will commit after verifying quality checks pass.
+- **Keep changes minimal.** Only modify files necessary to implement the user story. Do not refactor unrelated code.
+
+---
+
+## Output
+
+The output is the set of file changes (new files created, existing files modified) in the working tree. There is no document to produce — the code and tests are the deliverable.
+
+---
+
+## Checklist
+
+Before finishing:
+
+- [ ] All acceptance criteria from the user story are implemented
+- [ ] Tests cover each acceptance criterion
+- [ ] Code follows project conventions (naming, style, error handling)
+- [ ] Code compiles / type-checks without errors
+- [ ] No unrelated changes were made
+- [ ] No state files were modified
+- [ ] No git commits were made

package/scaffold/.agents/skills/plan-refactor/tmpl_SKILL.md

@@ -0,0 +1,19 @@
+# plan-refactor (scaffold)
+
+<!-- TODO: Complete. All content in English. -->
+
+## Objective
+
+TBD — From evaluation report: identify quick wins and critical refactorings, ask user about refactorings that need a decision, produce ordered plan.
+
+## Inputs
+
+TBD — `it_<iteration>_evaluation-report.md`.
+
+## Outputs
+
+TBD — `it_<iteration>_refactor_plan.md`.
+
+## Checklist
+
+TBD

package/scaffold/.agents/skills/refactor-prd/tmpl_SKILL.md

@@ -0,0 +1,19 @@
+# refactor-prd (scaffold)
+
+<!-- TODO: Complete. All content in English. -->
+
+## Objective
+
+TBD — Add refactor use cases to the iteration PRD (`it_<iteration>_PRD.json`), with associated regression tests if requested.
+
+## Inputs
+
+TBD — `it_<iteration>_refactor_plan.md`, `it_<iteration>_PRD.json`.
+
+## Outputs
+
+TBD — Updated `it_<iteration>_PRD.json`.
+
+## Checklist
+
+TBD

package/scaffold/.agents/skills/refine-pr-document/tmpl_SKILL.md

@@ -0,0 +1,108 @@
+---
+name: refine-pr-document
+description: "Updates an existing product requirement document based on user feedback. Triggered by: bun nvst refine requirement."
+user-invocable: true
+---
+
+# Refine Product Requirement Document
+
+Update `it_{current_iteration}_product-requirement-document.md` in place based on user feedback. The file must already exist; this skill does not create it from scratch.
+
+**Do NOT start implementing. Only update the document.**
+
+> **Two modes available — the agent asks at the start:**
+> - **Editor mode** — apply specific changes requested by the user.
+> - **Challenger mode** — act as an independent critical reviewer: challenge assumptions, question scope, find gaps, and propose improvements. The user accepts or rejects each suggestion before anything is written.
+
+---
+
+## The Job
+
+1. Read `state.json` → get `requirement_definition.file` (e.g. `it_000001_product-requirement-document.md`).
+2. Read the current document from `.agents/flow/{file}`.
+3. **Open by asking:** _"Would you like me to challenge the existing document as an independent reviewer, or would you prefer to tell me what to change?"_
+   - Answer → **challenge**: run Challenger Mode (see below).
+   - Answer → **edit**: run Editor Mode (see Questions Flow).
+4. Apply changes to the document following the same Output Structure as `create-pr-document`.
+5. Re-enforce MVP constraint: remove any user stories not explicitly listed by the user; do not add new ones without confirmation.
+6. Write the updated file back to the same path.
+7. Do **not** update `state.json` — `requirement_definition.status` stays `"in_progress"`.
+
+---
+
+## Challenger Mode
+
+Act as a second agent reviewing the document with fresh eyes. Do not apply any change without explicit user approval.
+
+**Challenge areas — examine each (in order):**
+
+1. **Assumptions** — List implicit assumptions in the goals or stories. Ask: are these validated? what if they are wrong?
+2. **Scope creep** — Flag any user story that is not strictly MVP-necessary. Propose removal and ask for confirmation.
+3. **Vague acceptance criteria** — Highlight criteria that are not concretely verifiable. Suggest a specific rewrite.
+4. **Missing non-goals** — Identify things the document is silent on that could be misread as in-scope. Propose additions to Non-Goals.
+5. **Missing edge cases** — Point out failure paths or user states not covered by any acceptance criterion.
+6. **Conflicting requirements** — Flag any `FR-N` that contradicts another or contradicts an acceptance criterion.
+
+**Challenger output format — one observation at a time:**
+
+> CRITICAL: Present findings **one at a time**. After delivering one finding, stop and wait for the user to respond before moving on. Do not queue or batch findings.
+
+For each finding, format it as:
+
+```
+Challenge [N/total]: <area name>
+
+Finding: <what the issue is>
+Suggestion: <proposed change>
+
+Accept / Reject / Discuss?
+```
+
+- After the user responds, acknowledge their decision and immediately present the **next** finding.
+- If the user types **Discuss**, engage in a short back-and-forth until they give a final Accept or Reject, then move on.
+- Once all findings have been reviewed, summarise the accepted changes and apply them to the file in a single write.
+- Do **not** write anything to the file until all findings have received a response.
+
+---
+
+## Editor Mode (Questions Flow)
+
+Ask only what is needed to understand the requested change.
+
+```
+1. What would you like to change or add?
+   A. Replace or rewrite a user story
+   B. Add a new user story (must be MVP-justified)
+   C. Remove a user story
+   D. Tighten acceptance criteria
+   E. Update goals or non-goals
+   F. Other: [describe]
+
+2. If adding a user story — is it strictly necessary for the MVP?
+   [Open answer — skip if not adding stories]
+
+3. Anything else to update in this pass?
+   [Open answer — skip if none]
+```
+
+---
+
+## Refinement Rules
+
+- **MVP constraint holds:** do not add user stories unless the user explicitly requests them and confirms they are MVP-necessary.
+- **Preserve numbering:** renumber `US-NNN` and `FR-N` entries only if a story is removed; otherwise keep existing IDs stable.
+- **Verifiable criteria:** any new or edited acceptance criterion must be concrete and testable (same standard as `create-pr-document`).
+- **UI stories:** if a new or edited story touches the UI, "visually verified in browser" must be an acceptance criterion.
+
+---
+
+## Checklist
+
+Before saving:
+
+- [ ] User's requested changes applied
+- [ ] No new user stories added without explicit MVP justification
+- [ ] All acceptance criteria remain verifiable
+- [ ] `US-NNN` and `FR-N` numbering is consistent
+- [ ] File written back to `.agents/flow/it_{current_iteration}_product-requirement-document.md`
+- [ ] `state.json` **not** modified (status stays `"in_progress"`)

package/scaffold/.agents/skills/refine-project-context/tmpl_SKILL.md

@@ -0,0 +1,157 @@
+---
+name: refine-project-context
+description: "Refines .agents/PROJECT_CONTEXT.md via editor mode or challenge mode. Challenge mode validates the document against the actual codebase and detects compliance issues. Triggered by: bun nvst refine project-context."
+user-invocable: true
+---
+
+# Refine Project Context
+
+Update `.agents/PROJECT_CONTEXT.md` in place based on user feedback or codebase validation. The file must already exist; this skill does not create it from scratch.
+
+**Do NOT start implementing. Only update the document (and optionally `.agents/TECHNICAL_DEBT.md` in challenge mode).**
+
+> **Two modes available — determined by the `mode` context variable:**
+> - **Editor mode** (default) — apply specific changes requested by the user.
+> - **Challenger mode** (`mode = "challenger"`) — validate PROJECT_CONTEXT.md against the actual codebase, detect discrepancies, and present findings individually for user triage.
+
+---
+
+## Inputs
+
+| Source | Used for |
+|--------|----------|
+| `.agents/PROJECT_CONTEXT.md` | The current document to refine |
+| Actual codebase files | Challenge mode: comparing documented conventions vs reality |
+| User answers (interactive mode) | Directing changes (editor) or triaging findings (challenger) |
+
+---
+
+## Editor Mode
+
+Ask only what is needed to understand the requested change.
+
+```
+1. What would you like to change or add to the project context?
+   A. Update conventions (naming, formatting, git flow)
+   B. Update tech stack details
+   C. Update code standards
+   D. Update testing strategy
+   E. Update product architecture
+   F. Update modular structure
+   G. Update implemented capabilities
+   H. Other: [describe]
+
+2. Anything else to update in this pass?
+   [Open answer — skip if none]
+```
+
+Apply changes to the document following the same Output Structure as `create-project-context`.
+
+**After editing:**
+- Write the updated file back to `.agents/PROJECT_CONTEXT.md`.
+- Enforce the **250-line cap** (see Cap Rule in `create-project-context` skill).
+
+---
+
+## Challenger Mode
+
+Act as a codebase auditor. Systematically compare the content of `PROJECT_CONTEXT.md` against the actual codebase to detect discrepancies. Do not apply any change without explicit user approval.
+
+### Step 1: Analyse
+
+Read the codebase (file structure, imports, patterns, config files, test files) and compare against each section of PROJECT_CONTEXT.md:
+
+1. **Conventions** — Are the naming, formatting, and git flow conventions actually followed?
+2. **Tech Stack** — Do the documented languages, runtimes, frameworks, and libraries match `package.json`, `tsconfig.json`, lock files, and actual imports?
+3. **Code Standards** — Are the style patterns, error handling, and module organisation conventions reflected in the code?
+4. **Testing Strategy** — Does the test approach, runner, and location convention match reality?
+5. **Product Architecture** — Does the documented architecture match the actual file/module structure?
+6. **Modular Structure** — Are the documented modules/packages accurate and complete?
+7. **Implemented Capabilities** — Are all documented capabilities actually implemented, and are there implemented capabilities not documented?
+
+### Step 2: Present Findings
+
+> CRITICAL: Present findings **one at a time**. After delivering one finding, stop and wait for the user to respond before moving on. Do not queue or batch findings.
+
+For each discrepancy, classify it as one of two types and present:
+
+```
+Finding [N/total]: <section name>
+
+Type: PROJECT CONTEXT NOT COMPLIANT | CODE NOT COMPLIANT
+Description: <what the discrepancy is>
+Evidence: <specific file(s) or code snippet(s) that demonstrate the discrepancy>
+
+Suggested action:
+- If PROJECT CONTEXT NOT COMPLIANT: <proposed fix to PROJECT_CONTEXT.md>
+- If CODE NOT COMPLIANT: <summary to record as technical debt>
+
+Accept / Reject / Discuss?
+```
+
+- After the user responds, acknowledge their decision and immediately present the **next** finding.
+- If the user types **Discuss**, engage in a short back-and-forth until they give a final Accept or Reject, then move on.
+
+### Step 3: Apply Changes
+
+After all findings have been reviewed:
+
+**For accepted "PROJECT CONTEXT NOT COMPLIANT" findings:**
+- Apply the suggested fixes to `.agents/PROJECT_CONTEXT.md`.
+- Enforce the 250-line cap after all edits.
+
+**For accepted "CODE NOT COMPLIANT" findings:**
+- Append each finding to `.agents/TECHNICAL_DEBT.md` in the format below.
+- Create `.agents/TECHNICAL_DEBT.md` if it does not already exist.
+- Appending to TECHNICAL_DEBT.md alone does NOT modify the project context status.
+
+**TECHNICAL_DEBT.md entry format:**
+
+```markdown
+### TD-<NNN>: <short title>
+
+- **Source:** Challenge mode — iteration <current_iteration>
+- **Date:** <ISO 8601>
+- **Section:** <PROJECT_CONTEXT.md section>
+- **Description:** <what the code does that doesn't match the documented convention>
+- **Evidence:** <file path(s) and brief description>
+- **Suggested resolution:** <what should change in the code>
+```
+
+### Step 4: Summarise
+
+After all findings are processed, output a summary:
+
+```
+Challenge Summary:
+- Total findings: N
+- Accepted (project context updated): X
+- Accepted (technical debt recorded): Y
+- Rejected: Z
+
+Files modified:
+- .agents/PROJECT_CONTEXT.md: [yes/no]
+- .agents/TECHNICAL_DEBT.md: [yes/no — created/updated/unchanged]
+```
+
+---
+
+## Refinement Rules
+
+- **250-line cap** on PROJECT_CONTEXT.md must be enforced after every edit (see Cap Rule in `create-project-context` skill).
+- **Preserve structure:** maintain the same section headings as defined in `create-project-context` skill Output Structure.
+- **No phantom sections:** do not add sections that have no content.
+- **TECHNICAL_DEBT.md numbering:** if the file already exists, continue numbering from the last `TD-NNN` entry; if new, start at `TD-001`.
+
+---
+
+## Checklist
+
+Before saving:
+
+- [ ] All user-accepted changes applied to `.agents/PROJECT_CONTEXT.md`
+- [ ] PROJECT_CONTEXT.md does not exceed 250 lines
+- [ ] All accepted "code not compliant" findings recorded in `.agents/TECHNICAL_DEBT.md`
+- [ ] TECHNICAL_DEBT.md created if it did not exist and there are code compliance findings
+- [ ] Summary of changes presented to the user
+- [ ] `state.json` will be updated by the CLI command (not by this skill)

package/scaffold/.agents/skills/refine-test-plan/tmpl_SKILL.md

@@ -0,0 +1,76 @@
+---
+name: refine-test-plan
+description: "Refines an existing test plan based on user feedback or adversarial challenge mode. Triggered by: bun nvst refine test-plan."
+user-invocable: true
+---
+
+# Refine Test Plan
+
+Update `it_{current_iteration}_test-plan.md` in place. The file already exists and is provided in context.
+
+**Do NOT implement code. Only revise the test plan document.**
+
+> **Two modes available — determined by the `mode` context variable:**
+> - **Editor mode** (default): apply user-requested updates to the plan.
+> - **Challenger mode** (`mode = "challenger"`): run an adversarial review of the plan and challenge weak coverage, assertions, and missing cases before applying any edits.
+
+---
+
+## Inputs
+
+| Source | Used for |
+|--------|----------|
+| `test_plan_file` | Current plan file name |
+| `test_plan_content` | Existing test plan content |
+| User responses | Clarifications and approval of proposed edits |
+
+---
+
+## Editor Mode
+
+Ask only what is needed, then update the document directly.
+
+Focus on:
+- Preserve the existing section structure, headings, and overall organization unless the user explicitly requests structural changes
+- Test scope completeness
+- Acceptance criteria traceability
+- Execution order and environment assumptions
+- Clarity and actionability of assertions
+
+---
+
+## Challenger Mode
+
+Act as an independent reviewer trying to break the plan.
+
+Evaluate at minimum:
+1. Coverage gaps for each acceptance criterion
+2. Missing negative/error-path scenarios
+3. Weak or non-verifiable assertions
+4. Ambiguous setup/fixtures/test data
+5. Over-reliance on manual testing where automation should be used
+6. Missing quality checks (typecheck, lint, CI gates) where applicable
+
+Present findings one at a time:
+
+```text
+Challenge [N/total]: <area>
+
+Finding: <specific weakness>
+Risk: <why this can fail in practice>
+Suggestion: <concrete improvement>
+
+Accept / Reject / Discuss?
+```
+
+Only apply accepted suggestions to the document after all findings are triaged.
+
+---
+
+## Checklist
+
+- [ ] Output remains in English
+- [ ] Accepted changes applied to the existing test plan file
+- [ ] Each acceptance criterion has explicit test intent
+- [ ] Same output file path is preserved (refine in place, do not write to a new file)
+- [ ] State files are not modified by this skill

package/scaffold/.agents/tmpl_PROJECT_CONTEXT.md

@@ -0,0 +1,3 @@
+# Project context
+
+<!-- Created or updated by `bun nvst create project-context`. Conventions, stack, and product architecture. Cap 250 lines (see process_design summary mechanism). -->