@torus-engineering/tas-kit 1.11.1 → 1.13.0

package/{.claude → .tas}/commands/tas-plan.md

@@ -1,198 +1,198 @@
-# /tas-plan $ARGUMENTS
-
-Role: SE - Software Engineer
-Bridge between business (Story) and technical (code).
-Analyze Story, create technical plan, break tasks — before implementing.
-
-**Required output:** Technical Plan written to Story file + `plan_status: completed`.
-
-## Always / Ask / Never
-
-| | Action |
-|---|---|
-| **Always** | Read Story file before doing anything |
-| **Always** | Wait for user to approve plan before writing to Story |
-| **Always** | Write Technical Plan to Story file after approval |
-| **Ask** | When need to reference SAD/ADR — confirm with user before reading |
-| **Ask** | When Story scope > 8 hours — suggest splitting Story |
-| **Never** | Start implementing in this command |
-| **Never** | Read SAD/ADR without asking user first |
-| **Never** | Write plan to Story without approval |
-
-## Actions
-
-### Step 1 — Identify Story
-
-`$ARGUMENTS` can be: Story ID (`Story-005`), file path, or Story description.
-
-- If Story ID: find file via glob `docs/epics/**/*-Story-{ID}-*.md`
-- If file path: read directly
-- If description: ask user for specific Story ID/file
-- Read Story file
-
-**Check re-plan:** If `plan_status: completed` → ask user:
-> "This Story already has a Technical Plan. Do you want to re-plan?"
-If user confirms → continue. If not → stop.
-
-### Step 2 — Parallel Context Gathering
-
-Launch 2 agents SIMULTANEOUSLY:
-
-**Agent 1 — `code-explorer`** (always run):
-> Survey codebase related to Story: "{Story title + AC summary}".
-> Find: entry points, files likely to change, existing patterns, dependencies.
-> Read max 10 most relevant files.
-> Return: concise map — what exists, what needs to change, potential conflicts.
-
-**Agent 2 — `architect`** (only run if Story shows architectural changes:
-new service/module, data flow changes, external system integration,
-database schema changes, new design pattern):
-> Evaluate architectural implications of Story: "{Story title}".
-> Read `docs/sad.md` (if exists) and files in `docs/adr/`.
-> Read `.claude/rules/common/patterns.md`.
-> Return: which ADRs relate, patterns to follow, architectural risks, constraints.
-
-Wait for ALL agents to finish, synthesize findings.
-
-### Step 3 — Ask about SAD/ADR (if still unclear)
-
-After seeing agent findings, if need to reference specific SAD or ADR:
-> "I need to read [SAD / ADR-XXX] to clarify [reason]. OK?"
-
-Only read after user confirms.
-
-### Step 4 — API Design (if Story involves backend API)
-
-**If Story shows API design** (new endpoint, API contract change, exposing service):
-Invoke skill `api-design` to design API Spec before planning:
-- URL structure, HTTP methods, status codes
-- Request/response payload shape
-- Pagination, filtering if needed
-- Error response format
-
-Attach API Spec to **Technical Plan → API Contract** section in Story.
-If Story not API-related → skip this step.
-
-### Step 5 — Technical Analysis
-
-Based on Story + agent findings, list clearly:
-
-**Files to change:**
-| File | What change | Why |
-
-**Files to create** (if any):
-| File | Purpose |
-
-**Database changes** (if any): migration, schema changes, seed data
-
-**Config/Infrastructure changes** (if any): env vars, feature flags, new dependencies
-
-**Need to update SAD?** Yes/No + brief reason
-
-**Need new ADR?** Yes/No + brief reason
-
-### Step 6 — Propose approach
-
-If multiple feasible approaches, list 2-3 options:
-```
-Option A: [short description]
-  + [pro]
-  - [con]
-
-Option B: [short description]
-  + [pro]
-  - [con]
-```
-Recommend best option and reason. If only 1 approach → present directly.
-
-### Step 7 — Break Tasks
-
-Break down into implementation-order tasks. Each task ~1-2 hours:
-```
-- [ ] Task 1: [specific action — which file, what change]
-- [ ] Task 2: [specific action]
-- [ ] Task 3: Write unit tests for [AC-1, AC-2...]
-- [ ] Task 4: [if needed] Create ADR / update SAD
-```
-
-If total estimate > 8 hours → suggest splitting Story before continuing.
-
-### Step 8 — Wait for approval
-
-**STOP.** Display entire plan and ask:
-> "Does the Technical Plan above look OK? Any adjustments?"
-
-- If user approves → Step 9
-- If user has feedback → update plan, ask again
-- DO NOT write anything to Story before approval
-
-### Step 9 — Write Technical Plan to Story
-
-After approval, update Story file:
-
-**1. Add section `## Technical Plan`** to Story (replace comment placeholder):
-
-```markdown
-## Technical Plan
-> **Plan by:** {SE name} | **Date:** {current date}
-
-### Approach
-{Brief description of chosen approach and reason}
-
-### Files to Change
-| File | Change | Reason |
-|------|--------|--------|
-
-### Files to Create
-| File | Purpose |
-|------|---------|
-
-### Database Changes
-{If none: "None"}
-
-### Config Changes
-{If none: "None"}
-
-### Architecture Notes
-- SAD update needed: Yes/No
-- New ADR needed: Yes/No — {title if Yes}
-
-### Tasks
-- [ ] Task 1: ...
-- [ ] Task 2: ...
-- [ ] Task 3: Write unit tests
-```
-
-**2. Update frontmatter:**
-- `plan_status: completed`
-- `plan_date: {current datetime}`
-
-**3. Update `project-status.yaml`:**
-- `last_updated: {current date}`
-- `epics.{EPIC_ID}.features.{FEATURE_ID}.stories.{STORY_ID}.plan_status: completed`
-
-**4. If ADR needed:** run `/tas-adr "{Decision title}"` immediately after writing plan.
-
-### Step 10 — Notify next step
-> "Technical Plan written to Story. SE can start implementing with `/tas-dev {Story-ID}`."
-
----
-
-## Quick Mode (require_plan: false in tas.yaml)
-
-For: solo dev, prototype, spike, urgent hotfix.
-
-- `/tas-dev` will NOT require running `/tas-plan` first
-- `/tas-plan` can still be run voluntarily when Story is complex
-- Trade-off: higher speed, lower traceability
-
-## Principles
-- Technical Plan lives in Story file — no separate plan file
-- Each task ~1-2 hours; whole Story ~4-8 hours
-- If estimate > 8 hours → split Story
-- If task affects architecture → suggest ADR
-- Keep plan concise, actionable — don't write essays
-
-## Final Step — Token Log
-
-Invoke skill `token-logger`: write AI Usage Log to working Story file.
+# /tas-plan $ARGUMENTS
+
+Role: SE - Software Engineer
+Bridge between business (Story) and technical (code).
+Analyze Story, create technical plan, break tasks — before implementing.
+
+**Required output:** Technical Plan written to Story file + `plan_status: completed`.
+
+## Always / Ask / Never
+
+| | Action |
+|---|---|
+| **Always** | Read Story file before doing anything |
+| **Always** | Wait for user to approve plan before writing to Story |
+| **Always** | Write Technical Plan to Story file after approval |
+| **Ask** | When need to reference SAD/ADR — confirm with user before reading |
+| **Ask** | When Story scope > 8 hours — suggest splitting Story |
+| **Never** | Start implementing in this command |
+| **Never** | Read SAD/ADR without asking user first |
+| **Never** | Write plan to Story without approval |
+
+## Actions
+
+### Step 1 — Identify Story
+
+`$ARGUMENTS` can be: Story ID (`Story-005`), file path, or Story description.
+
+- If Story ID: find file via glob `docs/epics/**/*-Story-{ID}-*.md`
+- If file path: read directly
+- If description: ask user for specific Story ID/file
+- Read Story file
+
+**Check re-plan:** If `plan_status: completed` → ask user:
+> "This Story already has a Technical Plan. Do you want to re-plan?"
+If user confirms → continue. If not → stop.
+
+### Step 2 — Parallel Context Gathering
+
+Launch 2 agents SIMULTANEOUSLY:
+
+**Agent 1 — `code-explorer`** (always run):
+> Survey codebase related to Story: "{Story title + AC summary}".
+> Find: entry points, files likely to change, existing patterns, dependencies.
+> Read max 10 most relevant files.
+> Return: concise map — what exists, what needs to change, potential conflicts.
+
+**Agent 2 — `architect`** (only run if Story shows architectural changes:
+new service/module, data flow changes, external system integration,
+database schema changes, new design pattern):
+> Evaluate architectural implications of Story: "{Story title}".
+> Read `docs/sad.md` (if exists) and files in `docs/adr/`.
+> Read `.tas/rules/common/patterns.md`.
+> Return: which ADRs relate, patterns to follow, architectural risks, constraints.
+
+Wait for ALL agents to finish, synthesize findings.
+
+### Step 3 — Ask about SAD/ADR (if still unclear)
+
+After seeing agent findings, if need to reference specific SAD or ADR:
+> "I need to read [SAD / ADR-XXX] to clarify [reason]. OK?"
+
+Only read after user confirms.
+
+### Step 4 — API Design (if Story involves backend API)
+
+**If Story shows API design** (new endpoint, API contract change, exposing service):
+Read `.tas/rules/common/api-design.md` for REST API conventions, then design API Spec before planning:
+- URL structure, HTTP methods, status codes
+- Request/response payload shape
+- Pagination, filtering if needed
+- Error response format
+
+Attach API Spec to **Technical Plan → API Contract** section in Story.
+If Story not API-related → skip this step.
+
+### Step 5 — Technical Analysis
+
+Based on Story + agent findings, list clearly:
+
+**Files to change:**
+| File | What change | Why |
+
+**Files to create** (if any):
+| File | Purpose |
+
+**Database changes** (if any): migration, schema changes, seed data
+
+**Config/Infrastructure changes** (if any): env vars, feature flags, new dependencies
+
+**Need to update SAD?** Yes/No + brief reason
+
+**Need new ADR?** Yes/No + brief reason
+
+### Step 6 — Propose approach
+
+If multiple feasible approaches, list 2-3 options:
+```
+Option A: [short description]
+  + [pro]
+  - [con]
+
+Option B: [short description]
+  + [pro]
+  - [con]
+```
+Recommend best option and reason. If only 1 approach → present directly.
+
+### Step 7 — Break Tasks
+
+Break down into implementation-order tasks. Each task ~1-2 hours:
+```
+- [ ] Task 1: [specific action — which file, what change]
+- [ ] Task 2: [specific action]
+- [ ] Task 3: Write unit tests for [AC-1, AC-2...]
+- [ ] Task 4: [if needed] Create ADR / update SAD
+```
+
+If total estimate > 8 hours → suggest splitting Story before continuing.
+
+### Step 8 — Wait for approval
+
+**STOP.** Display entire plan and ask:
+> "Does the Technical Plan above look OK? Any adjustments?"
+
+- If user approves → Step 9
+- If user has feedback → update plan, ask again
+- DO NOT write anything to Story before approval
+
+### Step 9 — Write Technical Plan to Story
+
+After approval, update Story file:
+
+**1. Add section `## Technical Plan`** to Story (replace comment placeholder):
+
+```markdown
+## Technical Plan
+> **Plan by:** {SE name} | **Date:** {current date}
+
+### Approach
+{Brief description of chosen approach and reason}
+
+### Files to Change
+| File | Change | Reason |
+|------|--------|--------|
+
+### Files to Create
+| File | Purpose |
+|------|---------|
+
+### Database Changes
+{If none: "None"}
+
+### Config Changes
+{If none: "None"}
+
+### Architecture Notes
+- SAD update needed: Yes/No
+- New ADR needed: Yes/No — {title if Yes}
+
+### Tasks
+- [ ] Task 1: ...
+- [ ] Task 2: ...
+- [ ] Task 3: Write unit tests
+```
+
+**2. Update frontmatter:**
+- `plan_status: completed`
+- `plan_date: {current datetime}`
+
+**3. Update `project-status.yaml`:**
+- `last_updated: {current date}`
+- `epics.{EPIC_ID}.features.{FEATURE_ID}.stories.{STORY_ID}.plan_status: completed`
+
+**4. If ADR needed:** run `/tas-adr "{Decision title}"` immediately after writing plan.
+
+### Step 10 — Notify next step
+> "Technical Plan written to Story. SE can start implementing with `/tas-dev {Story-ID}`."
+
+---
+
+## Quick Mode (require_plan: false in tas.yaml)
+
+For: solo dev, prototype, spike, urgent hotfix.
+
+- `/tas-dev` will NOT require running `/tas-plan` first
+- `/tas-plan` can still be run voluntarily when Story is complex
+- Trade-off: higher speed, lower traceability
+
+## Principles
+- Technical Plan lives in Story file — no separate plan file
+- Each task ~1-2 hours; whole Story ~4-8 hours
+- If estimate > 8 hours → split Story
+- If task affects architecture → suggest ADR
+- Keep plan concise, actionable — don't write essays
+
+## Final Step — Token Log
+
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to working Story file.

package/{.claude → .tas}/commands/tas-prd.md

@@ -16,14 +16,14 @@ Create or update Product Requirements Document.
    - What are core features?
    - Any technical/business constraints?
 6. Create file docs/prd.md per template
-7. Update `project-status.yaml` per `.claude/rules/common/project-status.md` — add `artifacts.prd`.
+7. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add `artifacts.prd`.
 
 ### UPDATE mode (file exists):
 3. Need context from current docs/prd.md
 4. $ARGUMENTS is change description. If not provided, ask user which section to update.
 5. Update file, keep unchanged sections as-is
 6. Add line to Changelog section at end: date, change description
-7. Update `project-status.yaml` per `.claude/rules/common/project-status.md` — update `artifacts.prd`.
+7. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `artifacts.prd`.
 
 ## Principles
 - Write at sufficient detail for SE to understand and design architecture
@@ -34,4 +34,4 @@ Create or update Product Requirements Document.
 
 ## Final Step — Token Log
 
-Invoke skill `token-logger`: write AI Usage Log to `docs/prd.md`.
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to `docs/prd.md`.

package/{.claude → .tas}/commands/tas-review.md

@@ -4,7 +4,7 @@ Review recently changed code or a specific file/PR.
 Includes hygiene scan, test run, and parallel multi-agent review.
 
 ## Stack Detection
-Read `.claude/rules/common/stack-detection.md`.
+Read `.tas/rules/common/stack-detection.md`.
 
 ## Actions
 
@@ -32,28 +32,30 @@ Read `.claude/rules/common/stack-detection.md`.
 → If **PASS**: note "Unit Tests: ✓ PASS" in Review Summary.
 → If cannot detect: note "No test runner detected" and continue.
 
-### Step 3 — Parallel Multi-Agent Review
+### Step 3 — Review
 
-Launch agents SIMULTANEOUSLY (don't wait for each other):
+**Inline general review** (main session, always run):
+Read `.tas/rules/common/code-review.md`. Apply review criteria priority order, output format from rule. Story context (CLAUDE.md, SAD, ADRs) already in session — don't re-read.
 
-**Agent 1 — `code-reviewer`** (always run):
-> Review [scope]. Read `.tas/checklists/code-review.md` and `.claude/rules/common/code-review.md`.
-> Focus: naming, architecture alignment, error handling, DRY, function size, nesting depth.
-> Format: findings grouped by Critical / High / Medium / Low, each with file:line and specific fix.
+**Specialized agents** — launch SIMULTANEOUSLY (don't wait for each other):
 
-**Agent 2 — `security-reviewer`** (always run):
-> Security audit [scope]. Read `.claude/rules/common/security.md`.
-> If stack identified, also read `.claude/rules/[stack]/security.md`.
+**Agent 1 — `security-reviewer`** (always run):
+> Security audit [scope]. Read `.tas/rules/common/security.md`.
+> If stack identified, also read `.tas/rules/[stack]/security.md`.
 > Focus: OWASP Top 10, injection, hardcoded secrets, auth/authz, data exposure.
 > Format: findings grouped by Critical / High / Medium / Low, each with file:line and remediation.
 
-**Agent 3 — Language reviewer** (per `lang_agent` from stack detection):
+**Agent 2 — Language reviewer** (per `lang_agent` from stack detection):
 > Language-specific review [scope].
-> Read `.claude/rules/[stack]/coding-style.md`, `.claude/rules/[stack]/patterns.md`, `.claude/rules/[stack]/testing.md`.
-> If stack has React: also read `.claude/rules/web/design-quality.md`, `.claude/rules/web/testing.md`, `.claude/rules/web/performance.md`.
+> Read `.tas/rules/[stack]/coding-style.md`, `.tas/rules/[stack]/patterns.md`, `.tas/rules/[stack]/testing.md`.
+> If stack has React: also read `.tas/rules/web/design-quality.md`, `.tas/rules/web/testing.md`, `.tas/rules/web/performance.md`.
 > Focus: async/await patterns, null handling, type safety, stack-specific anti-patterns.
 > Format: findings by Critical / High / Medium / Low with file:line.
 
+**Agent 3 — `database-reviewer`** (only when `db_agent = database-reviewer`, and scope touches schema/migrations/queries):
+> Database review [scope]. Focus: schema correctness, migration safety, missing indexes, N+1 patterns, unsafe queries, data integrity.
+> Format: findings by Critical / High / Medium / Low with file:line.
+
 **Agent 4 — `aws-reviewer`** (only when `infra_agent = aws-reviewer`):
 > AWS infrastructure review [scope].
 > Focus: IAM policies, secrets in env/config, S3 permissions, Lambda security.
@@ -63,7 +65,7 @@ Wait for ALL agents to complete, then synthesize.
 
 ### Step 4 — Synthesize results
 
-Combine findings from all agents, deduplicate (same file:line from multiple agents → merge), sort by severity:
+Combine inline review findings + agent findings, deduplicate (same file:line → merge), sort by severity:
 
 ```
 ## Review Summary
@@ -108,4 +110,4 @@ Combine findings from all agents, deduplicate (same file:line from multiple agen
 
 ## Final Step — Token Log
 
-Invoke skill `token-logger`: write AI Usage Log to Story file being reviewed (if any).
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to Story file being reviewed (if any).

package/{.claude → .tas}/commands/tas-sad.md

@@ -15,7 +15,7 @@ Create or update Solution Architecture Document.
 ### CREATE mode (file doesn't exist):
 5. Need context from .tas/templates/SAD.md
 6. Create file docs/sad.md per Torus SAD template
-7. Update `project-status.yaml` per `.claude/rules/common/project-status.md` — add `artifacts.sad`.
+7. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — add `artifacts.sad`.
 
 ### UPDATE mode (file exists):
 5. Need context from current docs/sad.md
@@ -23,7 +23,7 @@ Create or update Solution Architecture Document.
 7. Update file, keep unchanged sections as-is
 8. Add line to Changelog section at end
 9. If change is important architectural decision, suggest user run /tas-adr
-10. Update `project-status.yaml` per `.claude/rules/common/project-status.md` — update `artifacts.sad`.
+10. Update `project-status.yaml` per `.tas/rules/common/project-status.md` — update `artifacts.sad`.
 
 ## Mermaid Rules
 - C4 diagrams MUST use Mermaid flow diagram
@@ -40,4 +40,4 @@ Create or update Solution Architecture Document.
 
 ## Final Step — Token Log
 
-Invoke skill `token-logger`: write AI Usage Log to `docs/sad.md`.
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to `docs/sad.md`.

package/{.claude → .tas}/commands/tas-security.md

@@ -3,7 +3,7 @@
 Check codebase security, save report to docs/security-report.md.
 
 ## Stack Detection
-Read `.claude/rules/common/stack-detection.md`.
+Read `.tas/rules/common/stack-detection.md`.
 
 ## Actions
 
@@ -15,7 +15,7 @@ Read `.claude/rules/common/stack-detection.md`.
 
 With `--staged`: get list from `git diff --cached --name-only --diff-filter=ACM` and only review those files. Use same regex patterns as `.tas/hooks/security-scan.js` then supplement with deep review by agents below.
 
-Read `.tas/checklists/security.md` for checklist.
+Read `.tas/rules/common/security.md` for general checks. If stack identified, also read `.tas/rules/[stack]/security.md` for stack-specific items.
 
 ### Step 2 — Parallel Security Scan
 
@@ -23,8 +23,8 @@ Launch agents SIMULTANEOUSLY based on stack:
 
 **Agent 1 — `security-reviewer`** (always run):
 > Security audit [scope].
-> Read `.claude/rules/common/security.md`.
-> If stack identified, also read `.claude/rules/[stack]/security.md`.
+> Read `.tas/rules/common/security.md`.
+> If stack identified, also read `.tas/rules/[stack]/security.md`.
 > Check OWASP Top 10: injection, broken auth, XSS, IDOR, security misconfiguration,
 > sensitive data exposure, insecure deserialization, vulnerable components, logging/monitoring.
 > Also check: hardcoded secrets, CORS config, anti-forgery tokens, rate limiting.

package/{.claude → .tas}/commands/tas-story.md

@@ -66,7 +66,7 @@ Write all to `## Unit Test Cases` section.
 - Frontmatter: `plan_status: pending`, `plan_date:` left empty
 
 **Step 7 — Update project-status.yaml**
-Per `.claude/rules/common/project-status.md` — add entry to `epics.{EPIC_ID}.features.{FEATURE_ID}.stories`.
+Per `.tas/rules/common/project-status.md` — add entry to `epics.{EPIC_ID}.features.{FEATURE_ID}.stories`.
 
 **Step 8 — Notify next step**
 > "Story created. Before SE starts coding, run `/tas-plan {Story-ID}` for technical planning."
@@ -79,7 +79,7 @@ Per `.claude/rules/common/project-status.md` — add entry to `epics.{EPIC_ID}.f
 2. Read current Story file
 3. Ask user what needs changing (update AC, change status, add test cases, fix business rule...)
 4. Update file, add entry to Changelog
-5. Update `project-status.yaml` per `.claude/rules/common/project-status.md`.
+5. Update `project-status.yaml` per `.tas/rules/common/project-status.md`.
 
 ## Principles
 - Story must be small enough to complete in **4-8 hours**; if larger → split into multiple Stories
@@ -88,4 +88,4 @@ Per `.claude/rules/common/project-status.md` — add entry to `epics.{EPIC_ID}.f
 
 ## Final Step — Token Log
 
-Invoke skill `token-logger`: write AI Usage Log to working Story file.
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to working Story file.

package/.tas/platforms.json

@@ -0,0 +1,5 @@
+{
+  "platforms": [
+    "claude-code"
+  ]
+}

package/.tas/project-status-example.yaml

@@ -1,17 +1,17 @@
-# .tas/project-status-example.yaml - Reference template for root/project-status.yaml
-# /tas-init will create root/project-status.yaml from this template.
-# Human can edit manually. Run /tas-init to re-sync if drifted.
-last_updated: ""
-
-artifacts:
-  prd: {}
-  design_spec: {}
-  sad: {}
-  security_report: {}
-  performance_report: {}
-
-adrs: {}
-
-bugs: {}
-
-epics: {}
+# .tas/project-status-example.yaml - Reference template for root/project-status.yaml
+# /tas-init will create root/project-status.yaml from this template.
+# Human can edit manually. Run /tas-init to re-sync if drifted.
+last_updated: ""
+
+artifacts:
+  prd: {}
+  design_spec: {}
+  sad: {}
+  security_report: {}
+  performance_report: {}
+
+adrs: {}
+
+bugs: {}
+
+epics: {}

package/{.claude/skills/ado-integration/SKILL.md → .tas/rules/ado-integration.md}

@@ -1,22 +1,12 @@
----
-name: ado-integration
-description: |
-  Azure DevOps integration. Auto-invoke when user mentions:
-  sync ADO, push to board, pull work item, update status on ADO,
-  create work item on ADO, or any Azure DevOps related operation.
-allowed-tools: Read, Write, Edit, Bash, Grep
----
-
-# ADO Integration Skill
-
-Enables bidirectional sync between .md files in repo and work items on Azure DevOps.
+# ADO Integration Rules
+
+Bidirectional sync between .md files in repo and work items on Azure DevOps.
 ADO sync is **intentional operation** — not automatic after each file edit.
 
-## When to Use
+## When to Apply
 
-- User requests sync, push, pull work item to/from ADO
 - User runs `/ado-create`, `/ado-update`, `/ado-status`, `/ado-get`, `/ado-delete`
-- DO NOT invoke when: user only edits .md file normally without mentioning ADO
+- DO NOT apply when: user only edits .md file normally without mentioning ADO
 
 ## Always / Ask / Never