@torus-engineering/tas-kit 1.13.0 → 2.1.0

package/.tas/commands/tas-review-pr.md

@@ -0,0 +1,174 @@
+---
+model: opus
+---
+
+# /tas-review-pr $ARGUMENTS
+
+Review a Pull Request automatically: detect platform (ADO or GitHub), fetch diff, run parallel review agents, post inline comments per finding, post summary comment, and vote.
+
+## Input
+
+`$ARGUMENTS` can be:
+- PR ID / number: `1234`
+- PR URL: extract the numeric ID from the URL
+
+## Step 0 — Detect Platform
+
+Run: `git remote get-url origin`
+
+Parse the output:
+- Contains `github.com` → `PLATFORM=github`, `SCRIPT=python .tas/tools/tas-github.py`
+- Contains `dev.azure.com` or `visualstudio.com` → `PLATFORM=ado`, `SCRIPT=python .tas/tools/tas-ado.py`
+- Neither → report "Cannot detect platform from git remote. Unsupported remote URL." and stop.
+
+For ADO: also read `tas.yaml`, check `ado.enabled`. If false or missing: stop.
+
+## Step 1 — Get PR Info
+
+Run: `{SCRIPT} pr-get <pr-id>`
+
+Record output fields:
+- `TITLE`, `SOURCE_BRANCH`, `TARGET_BRANCH`, `CREATOR`, `STATUS`
+- `REPO_ID` — ADO: repository GUID | GitHub: `owner/repo`
+- `HEAD_COMMIT` — GitHub only (used for inline comments)
+- `WORK_ITEMS` — ADO only
+
+## Step 2 — Fetch Diff & Changed Files
+
+Run: `{SCRIPT} pr-diff <pr-id>`
+
+Record:
+- `SOURCE_BRANCH`, `TARGET_BRANCH`, `FETCH_HEAD`
+- `CHANGED_FILES` — list with status prefix (M/A/D + path)
+
+## Step 3 — Stack Detection
+
+Read `.tas/rules/common/stack-detection.md`.
+Detect stack from changed file extensions and project structure.
+
+## Step 4 — Review Agents (launch simultaneously)
+
+Read each changed file with: `git show FETCH_HEAD:<file-path>`
+Only review M (modified) and A (added) files — skip D (deleted).
+
+**Inline general review** (main session, always run):
+Read `.tas/rules/common/code-review.md`. Apply full review criteria to all changed files.
+
+**Agent 1 — `security-reviewer`** (always run):
+> Security audit of PR #{pr-id} diff. Changed files: {changed_files_list}.
+> Read each file with `git show FETCH_HEAD:<path>`.
+> 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 by Critical / High / Medium / Low, each with file:line and remediation.
+
+**Agent 2 — Language reviewer** (per `lang_agent` from stack detection):
+> Language-specific review of PR #{pr-id} diff. Changed files: {changed_files_list}.
+> Read each file with `git show FETCH_HEAD:<path>`.
+> 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 scope touches schema/migrations/queries):
+> Database review of PR #{pr-id} diff. Changed files: {changed_files_list}.
+> Read each file with `git show FETCH_HEAD:<path>`.
+> Focus: schema correctness, migration safety, missing indexes, N+1 patterns, unsafe queries, data integrity.
+> Format: findings by Critical / High / Medium / Low with file:line.
+
+Wait for ALL agents to complete, then synthesize.
+
+## Step 5 — Synthesize
+
+Combine findings from main session + agents. Deduplicate same file:line. Sort by severity.
+
+```
+### Critical (must fix before merge)
+- `file:line` — issue — Fix: ...
+
+### High (should fix before merge)
+- `file:line` — issue — Fix: ...
+
+### Medium (consider fixing)
+- `file:line` — issue — Fix: ...
+
+### Low / Info
+- `file:line` — issue — ...
+```
+
+## Step 6 — Post Inline Comments
+
+For each Critical and High finding with a specific file:line:
+
+**ADO (`PLATFORM=ado`):**
+```
+python .tas/tools/tas-ado.py pr-inline <pr-id> --repo-id <REPO_ID> --file "<file-path>" --line <line> --comment "[Severity] issue — Fix: fix"
+```
+
+**GitHub (`PLATFORM=github`):**
+```
+python .tas/tools/tas-github.py pr-inline <pr-id> --file "<file-path>" --line <line> --comment "[Severity] issue — Fix: fix"
+```
+
+Rules:
+- File path: forward slashes, no leading slash
+- Skip findings without a specific line number
+- Skip findings on deleted (D) files
+
+## Step 7 — Post Summary Comment
+
+Format:
+
+```markdown
+## AI Code Review — TAS Kit
+
+**PR:** #{pr-id} — {title}
+**Date:** {today}
+**Model:** claude-sonnet-4-6
+**Platform:** {ADO | GitHub}
+
+> ⚠️ Tests not run — diff-only review (no local checkout)
+
+### Critical
+- `file:line` — issue — Fix: ...
+
+### High
+...
+
+### Medium
+...
+
+### Low / Info
+...
+
+---
+**Verdict:** APPROVED ✅ | CHANGES REQUESTED ❌
+```
+
+Post it:
+```
+{SCRIPT} pr-comment <pr-id> --comment "<summary-markdown>"
+```
+
+## Step 8 — Vote
+
+- Zero Critical AND zero High → `{SCRIPT} pr-vote <pr-id> --vote approve`
+- Any Critical or High found → `{SCRIPT} pr-vote <pr-id> --vote reject`
+
+## Step 9 — Report to User
+
+```
+PR #{pr-id} reviewed: {title}
+Platform: {ADO | GitHub}
+Critical: N | High: N | Medium: N | Low: N
+Inline comments posted: N
+Vote: APPROVED ✅ / CHANGES REQUESTED ❌
+```
+
+## Principles
+
+- Review PR diff only — do not review unrelated files in repo
+- Each inline comment: specific, actionable, fix included
+- Summary always posted even if no issues ("No issues found — clean PR")
+- Auto-approve only when zero Critical AND zero High
+- Note "Tests not run — diff-only mode" in summary
+- Read `.tas/rules/ado-integration.md` for ADO operating rules (ADO platform only)

package/.tas/commands/tas-review.md

@@ -1,113 +1,115 @@
-# /tas-review $ARGUMENTS
-
-Review recently changed code or a specific file/PR.
-Includes hygiene scan, test run, and parallel multi-agent review.
-
-## Stack Detection
-Read `.tas/rules/common/stack-detection.md`.
-
-## Actions
-
-### Step 1 — Determine review scope
-`$ARGUMENTS` can be: file path, Story ID, or empty (review git diff).
-- If empty: get `git diff HEAD` (staged + unstaged) or last commit
-- If Story ID: find corresponding Story file to get changed files list
-- If file path: review that file directly
-
-### Step 2 — Pre-checks (MUST pass before continuing)
-
-**Hygiene scan** — quick scan of files in scope:
-- Debug code leftovers: `console.log`, `print(`, `Debug.WriteLine`, `debugger`
-- Hardcoded secrets: password/key/token/secret assigned as string literal
-- Large commented-out code blocks (>5 lines) without reason comment
-
-→ If blockers found: list immediately, require fix before continuing.
-
-**Run tests** — detect from project structure:
-- `package.json` → `yarn test --ci` or `npm test`
-- `*.csproj` / `*.sln` → `dotnet test`
-- `pytest.ini` / `pyproject.toml` → `python -m pytest`
-
-→ If **FAIL**: add finding **"Unit Test Failure"** severity **Critical**, stop, DO NOT continue review.
-→ If **PASS**: note "Unit Tests: ✓ PASS" in Review Summary.
-→ If cannot detect: note "No test runner detected" and continue.
-
-### Step 3 — Review
-
-**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.
-
-**Specialized agents** — launch SIMULTANEOUSLY (don't wait for each other):
-
-**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 2 — Language reviewer** (per `lang_agent` from stack detection):
-> Language-specific review [scope].
-> 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.
-> Format: findings by Critical / High / Medium / Low.
-
-Wait for ALL agents to complete, then synthesize.
-
-### Step 4 — Synthesize results
-
-Combine inline review findings + agent findings, deduplicate (same file:line → merge), sort by severity:
-
-```
-## Review Summary
-
-### Critical (must fix before merge)
-- [file:line] Issue — Fix: ...
-
-### High (should fix before merge)
-- [file:line] Issue — Fix: ...
-
-### Medium (consider fixing)
-- [file:line] Issue — Fix: ...
-
-### Low / Info (optional)
-- [file:line] Issue — Fix: ...
-```
-
-## After review
-
-**If Critical/High present:**
-→ List clearly, require human fix. DO NOT continue flow.
-
-**If only Medium/Low:**
-→ List suggestions, ask if human wants to fix, then continue.
-
-**When human confirms fixed:**
-1. Tick `- [x] Code review passed` in Story's `## Definition of Done` section
-2. Ask: "Have you tested locally again? If OK, want to move ticket to Deploy Test?"
-3. If Yes:
-   a. Update Story `Status:` → `Deploy Test`
-   b. Add Changelog line in Story: date, "Code review passed, moved to Deploy Test"
-   c. Update parent Feature `Status:` → `In Progress`, update Stories table
-   d. Add Changelog in Feature
-   e. Update `project-status.yaml`
-   f. Suggest: run `/ado-update story <ado-id> --status "Deploy Test"` if using ADO
-
-## Principles
-- Objective review — point to specific file:line and reason
-- Propose specific fix, don't just say "code is bad"
-- Check if code violates any ADR (read from Story's Technical Notes)
-- DO NOT auto-change status without human confirmation
-
-## Final Step — Token Log
-
-Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to Story file being reviewed (if any).
+---
+model: opus
+---
+
+# /tas-review $ARGUMENTS
+
+Review recently changed code or a specific file/PR.
+Includes hygiene scan, test run, and parallel multi-agent review.
+
+## Stack Detection
+Read `.tas/rules/common/stack-detection.md`.
+
+## Actions
+
+### Step 1 — Determine review scope
+`$ARGUMENTS` can be: file path, Feature ID, or empty (review git diff).
+- If empty: get `git diff HEAD` (staged + unstaged) or last commit
+- If Feature ID: find corresponding Feature file (`docs/features/{CODE}-Feature-{ID}-*/`) to get changed files list (cross-ref with Technical file's File Changes table)
+- If file path: review that file directly
+
+### Step 2 — Pre-checks (MUST pass before continuing)
+
+**Hygiene scan** — quick scan of files in scope:
+- Debug code leftovers: `console.log`, `print(`, `Debug.WriteLine`, `debugger`
+- Hardcoded secrets: password/key/token/secret assigned as string literal
+- Large commented-out code blocks (>5 lines) without reason comment
+
+→ If blockers found: list immediately, require fix before continuing.
+
+**Run tests** — detect from project structure:
+- `package.json` → `yarn test --ci` or `npm test`
+- `*.csproj` / `*.sln` → `dotnet test`
+- `pytest.ini` / `pyproject.toml` → `python -m pytest`
+
+→ If **FAIL**: add finding **"Unit Test Failure"** severity **Critical**, stop, DO NOT continue review.
+→ If **PASS**: note "Unit Tests: ✓ PASS" in Review Summary.
+→ If cannot detect: note "No test runner detected" and continue.
+
+### Step 3 — Review
+
+**Inline general review** (main session, always run):
+Read `.tas/rules/common/code-review.md`. Apply review criteria priority order, output format from rule. Feature context (CLAUDE.md, SAD, ADRs) already in session — don't re-read.
+
+**Specialized agents** — launch SIMULTANEOUSLY (don't wait for each other):
+
+**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 2 — Language reviewer** (per `lang_agent` from stack detection):
+> Language-specific review [scope].
+> 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.
+> Format: findings by Critical / High / Medium / Low.
+
+Wait for ALL agents to complete, then synthesize.
+
+### Step 4 — Synthesize results
+
+Combine inline review findings + agent findings, deduplicate (same file:line → merge), sort by severity:
+
+```
+## Review Summary
+
+### Critical (must fix before merge)
+- [file:line] Issue — Fix: ...
+
+### High (should fix before merge)
+- [file:line] Issue — Fix: ...
+
+### Medium (consider fixing)
+- [file:line] Issue — Fix: ...
+
+### Low / Info (optional)
+- [file:line] Issue — Fix: ...
+```
+
+## After review
+
+**If Critical/High present:**
+→ List clearly, require human fix. DO NOT continue flow.
+
+**If only Medium/Low:**
+→ List suggestions, ask if human wants to fix, then continue.
+
+**When human confirms fixed:**
+1. Tick `- [x] Code review passed` in Feature's `## Definition of Done` section
+2. Ask: "Tested locally? If OK, mark Feature `Done` and prepare release?"
+3. If Yes:
+   a. Update Feature `Status:` → `Done`, fill `Done Date`
+   b. Add Changelog line in Feature: date, "Code review passed, marked Done"
+   c. Update `project-status.yaml`: `features.{FEATURE_ID}.status: Done`
+   d. Suggest: run `/ado-update feature <ado-id> --status "Done"` if using ADO
+
+## Principles
+- Objective review — point to specific file:line and reason
+- Propose specific fix, don't just say "code is bad"
+- Check if code violates any ADR (cross-ref Feature-Technical's "Need new ADR" section)
+- DO NOT auto-change status without human confirmation
+
+## Final Step — Token Log
+
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to Feature file being reviewed (if any).

package/.tas/commands/tas-sad.md

@@ -1,43 +1,47 @@
-# /tas-sad $ARGUMENTS
-
-Role: SE - Software Engineer
-Create or update Solution Architecture Document.
-
-## Prerequisite
-- docs/prd.md must exist. If not, notify user to run /tas-prd first.
-
-## Actions
-1. Need context from root/tas.yaml for project info, workflow config
-2. Need context from docs/prd.md to understand requirements
-3. If brownfield: need context from docs/codebase-overview.md if available
-4. Check if docs/sad.md already exists:
-
-### 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 `.tas/rules/common/project-status.md` — add `artifacts.sad`.
-
-### UPDATE mode (file exists):
-5. Need context from current docs/sad.md
-6. $ARGUMENTS is change description. If not provided, ask user which section to update.
-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 `.tas/rules/common/project-status.md` — update `artifacts.sad`.
-
-## Mermaid Rules
-- C4 diagrams MUST use Mermaid flow diagram
-- Start with :::mermaid, end with :::
-- DO NOT use () in node labels, use [] instead
-- Example: A["Web App"] --> B["API Gateway"]
-- Include views: System Context, Container, Component, Data, Deployment
-
-## Principles
-- SAD must align with tech stack in CLAUDE.md
-- Each important architectural decision should reference ADR
-- ERD must use Mermaid erDiagram
-- Sequence diagram uses Mermaid sequenceDiagram
-
-## Final Step — Token Log
-
-Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to `docs/sad.md`.
+---
+model: opus
+---
+
+# /tas-sad $ARGUMENTS
+
+Role: SE - Software Engineer
+Create or update Solution Architecture Document.
+
+## Prerequisite
+- docs/prd.md must exist. If not, notify user to run /tas-prd first.
+
+## Actions
+1. Need context from root/tas.yaml for project info, workflow config
+2. Need context from docs/prd.md to understand requirements
+3. If brownfield: need context from docs/codebase-overview.md if available
+4. Check if docs/sad.md already exists:
+
+### 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 `.tas/rules/common/project-status.md` — add `artifacts.sad`.
+
+### UPDATE mode (file exists):
+5. Need context from current docs/sad.md
+6. $ARGUMENTS is change description. If not provided, ask user which section to update.
+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 `.tas/rules/common/project-status.md` — update `artifacts.sad`.
+
+## Mermaid Rules
+- C4 diagrams MUST use Mermaid flow diagram
+- Start with :::mermaid, end with :::
+- DO NOT use () in node labels, use [] instead
+- Example: A["Web App"] --> B["API Gateway"]
+- Include views: System Context, Container, Component, Data, Deployment
+
+## Principles
+- SAD must align with tech stack in CLAUDE.md
+- Each important architectural decision should reference ADR
+- ERD must use Mermaid erDiagram
+- Sequence diagram uses Mermaid sequenceDiagram
+
+## Final Step — Token Log
+
+Follow `.tas/rules/common/token-logging.md`: write AI Usage Log to `docs/sad.md`.