feat: 7 - living doc copilot

.github/agents/evals/living-doc-bdd-copilot/fixture-map.md

@@ -0,0 +1,27 @@
+# Fixture Map — living-doc-bdd-copilot agent evals
+
+## Eval coverage summary
+
+| Eval ID | Category | Description | Fixture files |
+|---------|----------|-------------|---------------|
+| 1 | happy-path | Business Seed assembly — seed.yaml structure | — |
+| 2 | happy-path | Create mode: PageObject generation from crawled surface | — |
+| 3 | happy-path | Scenario generation from US ACs | — |
+| 4 | regression | RE-SCAN mode — selector drift detection and repair | — |
+| 5 | regression | HEALING mode — broken step definitions | — |
+| 6 | negative | Create User Story request stays in this agent — no handoff | — |
+| 7 | paraphrase | "fix failing tests" → HEALING mode trigger | — |
+| 8 | regression | REMOVE mode — full feature removal with pre-deletion checklist | — |
+| 9 | regression | Partial state rule: seed.yaml present, manifest.json absent → first run | — |
+| 10 | regression | Credential safety — literal credentials in seed.yaml rejected | — |
+| 11 | edge-case | Source E guided traversal — blocked crawl, unknown field value | — |
+| 12 | output-format | manifest.json entry structure for a scanned route | — |
+| 25 | negative | Unit test request → decline + point to test-unit-write skill | — |
+
+## Trigger eval summary
+
+| Count | Triggers (should_trigger=true) | Non-triggers (should_trigger=false) |
+|-------|-------------------------------|--------------------------------------|
+| 44 total | 22 true | 22 false |
+
+> No fixture files — all evals use inline prompt/expected_output; agent behavior is assessed against the agent.md operating rules and skill definitions.

.github/copilot-instructions.md

@@ -1,5 +1,13 @@
 # Copilot Instructions
 
+## Always Active
+
+The **token-saving** skill is always active in this workspace. Every response applies concise formatting rules and removes noise (no filler, no closing platitudes, structured output). 
+
+See [Token-Saving Skill](../docs/guides/token-saving.md) for details, including override behavior when you explicitly request depth.
+
+---
+
 ## PR Review
 
 When reviewing a pull request, load and apply:

.github/workflows/test-scripts.yml

@@ -0,0 +1,60 @@
+name: Test Operational Scripts
+
+on:
+  pull_request:
+    paths:
+      - "skills/**/*.py"
+      - ".github/workflows/test-scripts.yml"
+
+permissions:
+  contents: read
+
+jobs:
+  run-tests:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+
+      - name: Install dependencies
+        run: pip install pyyaml
+
+      - name: Discover and run test_*.py scripts
+        env:
+          PYTHONIOENCODING: utf-8
+        run: |
+          set -euo pipefail
+
+          mapfile -t test_files < <(find skills -type f -name "test_*.py" | sort)
+
+          if [ "${#test_files[@]}" -eq 0 ]; then
+            echo "No test_*.py files found under skills/ — nothing to run."
+            exit 0
+          fi
+
+          echo "Found ${#test_files[@]} test file(s):"
+          printf '  %s\n' "${test_files[@]}"
+          echo
+
+          failures=()
+          for f in "${test_files[@]}"; do
+            echo "::group::$f"
+            if ! python "$f"; then
+              failures+=("$f")
+            fi
+            echo "::endgroup::"
+          done
+
+          echo
+          if [ "${#failures[@]}" -ne 0 ]; then
+            echo "FAILED (${#failures[@]}/${#test_files[@]}):"
+            printf '  %s\n' "${failures[@]}"
+            exit 1
+          fi
+
+          echo "All ${#test_files[@]} test file(s) passed."

.gitignore

@@ -0,0 +1,6 @@
+**/__pycache__/*
+**/.DS_Store
+skills-eval-workspace/*
+agents-eval-workspace/*
+.playwright-mcp/*
+review-fix-roadmap.md

CONTRIBUTING.md

@@ -38,8 +38,14 @@ skills/
 | `scripts/`    | Deterministic or repetitive logic better run as code than described in prose (e.g. a validation script, a formatter, a data transformer) |
 | `references/` | Domain docs, API specs, decision tables, or anything too large to keep in `SKILL.md` without exceeding 500 lines                         |
 | `assets/`     | Template files, example inputs/outputs, icons — anything the skill produces or consumes                                                  |
-| `evals/`      | Test prompts and assertions to verify skill behavior and trigger accuracy. See [skill-testing.md](./docs/skill-testing.md)               |
+| `evals/`      | Test prompts and assertions to verify skill behavior and trigger accuracy. See [skill-testing.md](./docs/testing/skill-testing.md)               |
 
+#### `references/` — shared vs. skill-specific
+
+- **`skills/<skill>/references/`** — skill-specific docs loaded only by that skill's instructions
+- **`skills/shared/references/`** — shared docs used by multiple skills (e.g., schemas, glossaries, common API specs)
+
+If a reference file is used by 2+ skills, place it in `skills/shared/references/` instead of duplicating it. See [living-doc-bdd-schemas.md](skills/shared/references/living-doc-bdd-schemas.md) and [living-doc-glossary.md](skills/shared/references/living-doc-glossary.md) for examples.
 ---
 
 ## 2. Frontmatter schema
@@ -177,6 +183,21 @@ should be run") — it is clearer and easier for the agent to follow.
 
 If every test run of your skill independently writes the same helper script (a formatter, a validator, a transformer), bundle it in `scripts/` and reference it from `SKILL.md`. This saves every future invocation from reinventing the wheel.
 
+### Shared utilities and assets across multiple skills
+
+**Pattern:** If code, references, or assets are used by 2+ skills, place them in `skills/shared/`:
+
+- **`skills/shared/lib/`** for shared Python modules → each skill has a wrapper
+- **`skills/shared/references/`** for shared documentation → skills link directly
+- **`skills/shared/assets/`** for shared templates/data → skills reference relative paths
+
+Examples:
+- `skills/shared/lib/living_doc_id.py` — shared by three living-doc skills
+- `skills/shared/references/living-doc-glossary.md` — shared by multiple living-doc skills
+- See [skills/shared/lib/README.md](skills/shared/lib/README.md) for implementation details
+
+**Benefits:** Single source of truth, prevents drift, easier maintenance, each skill remains independently deployable.
+
 ### Format conventions
 
 - Use `##` and `###` headings to structure the body
@@ -201,7 +222,7 @@ If every test run of your skill independently writes the same helper script (a f
 Before proposing a PR, verify that your skill activates correctly and produces good output. The full testing
 methodology — eval creation, fixture management, with/without comparisons, trigger testing, and description
 optimization using the Anthropic [`skill-creator`](https://github.com/anthropics/skills/tree/main/skills/skill-creator)
-skill — is covered in **[docs/skill-testing.md](./docs/skill-testing.md)**.
+skill — is covered in **[docs/testing/skill-testing.md](./docs/testing/skill-testing.md)**.
 
 ---
 

README.md

@@ -77,7 +77,20 @@ its purpose, trigger phrases, and full instructions.
 
 | Skill                                                | Description                                                                                                                         |
 |------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------|
+| **[bdd-maintain](./skills/bdd-maintain/)** | REMOVE and DEAD CODE AUDIT modes — delete feature files, step definitions, and PageObjects linked to 
 | **[create-repository](./skills/create-repository/)** | Creates and configures a GitHub repository under AbsaOSS (open source) or absa-group (internal). Runs a short interview, then shows an annotated `gh` command plan and executes it on confirmation — visibility, naming, admins, CODEOWNERS, labels, merge settings, and project links. |
+| **[data-cy-instrument](./skills/data-cy-instrument/)** | Resolve missing `data-cy` attributes in Angular component templates and sync PageObjects to use `getByTestId()` — run after a crawl when `coverage_gaps` are non-empty. |
+| **[gherkin-living-doc-sync](./skills/gherkin-living-doc-sync/)** | Synchronise Gherkin feature files with the living documentation catalog — fix missing AC traceability headers, step text drift, and stale scenario links. |
+| **[gherkin-step](./skills/gherkin-step/)** | Implement clean, reusable step definitions — behave (Python), Cucumber (Java, TypeScript, Scala), parameter types, DataTable, DocString, and hooks. |
+| **[living-doc-create-user-story](./skills/living-doc-create-user-story/)** | Create a well-formed User Story with business-level Acceptance Criteria that are traceable, testable, and E2E-ready. |
+| **[living-doc-create-feature](./skills/living-doc-create-feature/)** | Document a system surface (UI screen, API endpoint, service) as a Feature entity with ownership and traceability links. |
+| **[living-doc-create-functionality](./skills/living-doc-create-functionality/)** | Define an atomic, testable behaviour (Functionality) with AC designed for fast unit or integration tests. |
+| **[living-doc-update](./skills/living-doc-update/)** | Amend or deprecate existing User Story, Feature, or Functionality entities — add ACs, change status, update ownership. |
+| **[living-doc-impact-analysis](./skills/living-doc-impact-analysis/)** | Trace which Features, Functionalities, User Stories, and Gherkin scenarios are affected by a code change or PR. |
+| **[living-doc-gap-finder](./skills/living-doc-gap-finder/)** | Identify undocumented behaviours, orphan tests, and untested ACs. Used by `@living-doc-bdd-copilot` top-down (catalog gaps) and bottom-up (scenario coverage). |
+| **[living-doc-pageobject-scan](./skills/living-doc-pageobject-scan/)** | Discover, create, and maintain PageObject classes from a live web application — bootstrapping from scratch and detecting selector drift after UI changes. |
+deprecated entities; audit unused steps and PageObject methods. |
+| **[living-doc-scenario-creator](./skills/living-doc-scenario-creator/)** | Generate full Gherkin feature files from User Story and Functionality ACs — feature file header, @AC:-tagged scenarios, complete Given/When/Then step bodies, coverage report, and step definition resolution. |
 | **[pr-review](./skills/pr-review/)**                 | Pull request code review — reviews diffs for risk, security issues, API contract changes, dependency bumps, CI/CD and infrastructure changes. Produces concise Blocker / Important / Nit comments. |
 | **[tdd-workflow](./skills/tdd-workflow/)**           | Test-driven development: upfront SPEC.md planning + confirmation gate (avoids batch design), then vertical-sliced implementation (one test → one code cycle at a time, not all tests then all code). |
 | **[test-data-management](./skills/test-data-management/)** | Test data setup and management — factory functions, parametrised tests, deterministic seeds, fixture reuse, and production-data rules for unit and integration tests. |
@@ -87,6 +100,16 @@ its purpose, trigger phrases, and full instructions.
 | **[test-unit-review](./skills/test-unit-review/)**   | Systematically audit unit test suites. Runs test runner, checks isolation/scope/naming/assertions/coverage standards, and reports findings by severity (Blocker / Important / Nit). |
 | **[token-saving](./skills/token-saving/)**           | Always-active response discipline — enforces brevity, no filler openers or closers, structured output, and a What/Why/How footer on code responses. Suspends on explicit "full detail" requests. |
 
+## Agent Roster
+
+Agents are pre-configured AI personas that orchestrate multiple skills for a specific engineering phase. Agent files live in **[.github/agents/](./.github/agents/)**.
+
+
+
+| Agent | Description |
+|---|---|
+| **[@living-doc-bdd-copilot](./.github/agents/living-doc-bdd-copilot.agent.md)** | Living documentation and BDD automation — catalog management (User Stories, Features, Functionalities, AC updates, impact analysis, gap finding) and automation (webapp exploration, PageObjects, Gherkin scenarios, step definitions, BDD suite maintenance). |
+
 ## Finding More Skills
 
 Before building a new skill, check whether one already exists:
@@ -96,11 +119,13 @@ Before building a new skill, check whether one already exists:
 | [github/awesome-copilot](https://github.com/github/awesome-copilot/tree/main/skills) | 200+ community skills: cloud, languages, security, DevOps, productivity |
 | [skills.sh](https://skills.sh)                                                       | Open registry — install with `npx skills add <owner/repo>`              |
 | [anthropics/skills](https://github.com/anthropics/skills)                            | Anthropic reference skills including `skill-creator`                    |
+| [absa-group/agent-skills](https://github.com/absa-group/agent-skills)                | Broader ABSA-owned skill collection                                     |
+| [absa-group/cps-agentic-toolkit](https://github.com/absa-group/cps-agentic-toolkit)  | CPS team's extended skill set (ABSA-internal)                           |
 
 ## Contributing
 
 See **[CONTRIBUTING.md](./CONTRIBUTING.md)** for the skill authoring guide — folder layout, frontmatter schema, writing
-effective descriptions and bodies, [testing](./docs/skill-testing.md), and the PR checklist.
+effective descriptions and bodies, [testing](./docs/testing/skill-testing.md), and the PR checklist.
 
 To propose a new skill — or to propose expanding the repo into agents, MCP servers, or
 plugins — [open an issue](https://github.com/AbsaOSS/agentic-toolkit/issues/new).