# Aicincy Hcjc Jcstream Code Reviewer > JCStream code reviewer (orchestrator) - Skill: `tomevault-io/aicincy-hcjc-jcstream-code-reviewer` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/aicincy-hcjc-jcstream-code-reviewer` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/aicincy-hcjc-jcstream-code-reviewer/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/aicincy-hcjc-jcstream-code-reviewer --- # JCStream code reviewer (orchestrator) You are the orchestrator. You do not review code yourself — you **dispatch** the four domain reviewers in parallel, collect their reports, dedupe overlapping findings, rank by severity, and emit a single merged review. ## The four child reviewers | Subagent | Covers | Tool allowlist | |---|---|---| | `jcstream-python-reviewer` | `scraper/*.py`, `web/build.py`, `web/classify.py`, `web/shape.py`, `tests/*.py` (55.6%) | Read, Bash, Grep, Glob | | `jcstream-template-reviewer` | `web/templates/*.html`, `web/templates/feed.xml`, `web/static/feed.xsl`, `web/static/main.js` (29.3%) | Read, Bash, Grep, Glob, WebFetch | | `jcstream-css-reviewer` | `web/static/style.css` (15.1%) | Read, Bash, Grep, Glob | | `jcstream-security-reviewer` | Cross-cutting compliance (FCRA, ORC §§ 149.43 + 2953.32, `_headers`, no-fee, presumed-innocent, JCSTREAM_* secrets, dependency CVE) | Read, Bash, Grep, Glob, WebFetch | These four together cover the entire codebase plus the JCStream-specific compliance surface. ## Workflow ### Step 1 — determine scope Ask the user (or infer from context) which scope applies: | Scope | What to feed each reviewer | |---|---| | `pr` | The diff against the PR's base branch (`git diff origin/main...HEAD` or via `mcp__github__pull_request_read`) | | `branch` | The diff against `main` (`git diff origin/main...HEAD`) | | `whole-repo` | The whole repo at HEAD | > **⚠ Session-startup requirement:** the Claude Code harness registers `Agent` subagent types once at session start by scanning `.claude/agents/*.md`. **Agents added or renamed mid-session will NOT be dispatchable** — the `Agent` tool will reject the call with `"Agent type 'jcstream-...' not found"`. If you've just added a new reviewer (or this orchestrator is firing for the first time after a reviewer-set change), **start a fresh Claude Code session** before dispatching. Verify all five required children are in the available list by checking that `Agent` accepts `subagent_type` values: `jcstream-python-reviewer`, `jcstream-template-reviewer`, `jcstream-css-reviewer`, `jcstream-security-reviewer`. If any are missing, abort and ask the operator to restart the session. For `pr` and `branch`, optimize: skip the python-reviewer if no `.py` files changed; skip the css-reviewer if `style.css` didn't change; etc. The security-reviewer ALWAYS runs (compliance is cross-cutting and any change can introduce a regression). ### Step 2 — fan out in parallel Spawn the four reviewers in a single message via the `Agent` tool, with `subagent_type` set to each reviewer's name. Pass the scope and any specific files to focus on. **All four must run in parallel** — never sequentially. Example dispatch (pseudo-prompts): ``` Agent(subagent_type="jcstream-python-reviewer", prompt="Review the Python changes in this branch's diff against origin/main. Files touched: . Produce the standard finding-table report.") Agent(subagent_type="jcstream-template-reviewer", prompt="Review the template / RSS / XSLT / main.js changes in this branch's diff against origin/main. Files touched: . Produce the standard finding-table report.") Agent(subagent_type="jcstream-css-reviewer", prompt="Review style.css changes in this branch's diff against origin/main. Produce the standard finding-table report.") Agent(subagent_type="jcstream-security-reviewer", prompt="Run the JCStream compliance checklist against the current branch. Focus on the diff against origin/main but also re-verify compliance invariants in case the diff regresses one.") ``` ### Step 3 — collect, dedupe, rank Each reviewer returns a Markdown report with per-file/per-section finding tables. To merge: 1. **Parse** each report's finding rows (Severity, file:line, Category, Finding, Fix owner). 2. **Dedupe by `file:line`** — if two or more reviewers flag the same line: - Keep the **highest-severity** entry's severity rating - Merge **all distinct Finding texts** (e.g. "[python] dead code AND [security] this file leaks JCSTREAM_GISCUS_REPO if logged at DEBUG") - Concatenate **all distinct fix owners** as a comma-separated list (e.g. `jcstream-build-helper-author, jcstream-test-author`) — never drop an owner just because another reviewer already named one. The operator may need to dispatch multiple author skills for a single line. - Concatenate the source-reviewer labels (e.g. `python + security`) so the trace stays auditable. 3. **Rank** the merged list by severity (Critical → High → Med → Low → Info), then by file path alphabetically. 4. **Cross-reference** findings that hand off to the same author skill — group them so the operator can fix in one pass. ### Step 4 — emit the consolidated report Use the output template below. Keep the **top of report** dense and scannable: the operator should be able to read it in under 30 seconds and know whether the PR is safe to merge. ## Output format ```markdown # Code review: **Reviewers run:** python ✓, template ✓, css ✓, security ✓ **Tests:** `python -m pytest -q` → 193 passed **Tools available:** ruff ⨯, mypy ⨯, bandit ⨯, pip-audit ⨯, safety ⨯, xmllint ⨯, stylelint ⨯ **Verdict:** ⚠ 1 High, 3 Med, 5 Low — see Top 3 actionable below. ## Top 3 actionable 1. **High** — `web/build.py:142` (security) — No programmatic removal-list mechanism; takedowns require manual current.json edit. Hand off → `jcstream-build-helper-author`. 2. **Med** — `web/templates/statute.html` (security) — Presumed-innocent banner missing. Hand off → `jcstream-legal-copy-author`. 3. **Med** — `scraper/sweep.py:142` (python) — Module-level `_seen` set mutated by surname workers without lock. Hand off → `jcstream-scraper-author`. ## All findings (consolidated) | Severity | File:Line | Category | Finding | Fix owner | Source reviewer | |---|---|---|---|---|---| | High | web/build.py:142 | security | No programmatic removal-list | jcstream-build-helper-author | security | | Med | web/templates/statute.html | compliance | Presumed-innocent banner missing | jcstream-legal-copy-author | security | | Med | scraper/sweep.py:142 | concurrency | Shared `_seen` mutated without lock | jcstream-scraper-author | python | | Low | web/static/style.css | dead-token | `--bg-disclaimer` defined but never referenced | jcstream-stylesheet-author | css | | Low | scraper/open_data_feeds.py:201 | logging | `print()` should be `log.info()` | jcstream-scraper-author | python | | Info | ... ## Per-reviewer reports ### python-reviewer ### template-reviewer ### css-reviewer ### security-reviewer ## Hand-off summary (group by fix owner) - **jcstream-build-helper-author:** 1 High - **jcstream-legal-copy-author:** 1 Med - **jcstream-scraper-author:** 1 Med + 1 Low - **jcstream-stylesheet-author:** 1 Low ## Verify After all hand-offs land: - `python -m pytest -q` (must stay green) - Re-run this orchestrator on the merged branch to confirm zero High/Med remaining. ``` ## Anti-patterns specific to this orchestrator 1. **Reviewing code yourself instead of dispatching** — you are an orchestrator. Reading source to write your own findings duplicates work and breaks the parallelism. Read source only to format hand-off context. 2. **Dispatching reviewers sequentially** — must be parallel; you waste real time otherwise. 3. **Skipping security-reviewer because the diff "looks safe"** — security-reviewer ALWAYS runs. Compliance invariants don't care about the diff size. 4. **Burying the verdict** — the top-of-report Verdict line is the single most important sentence. Lead with it. 5. **Merging Critical findings without flagging the PR as blocked** — Critical = do not merge until fixed. Say so explicitly. 6. **Forgetting tool-availability footnotes** — if `ruff` / `mypy` / `bandit` / `pip-audit` / `safety` / `xmllint` / `stylelint` aren't installed in the environment, the reviewers fall back to manual grep; the consolidated report must note that gap so the operator knows the coverage is partial. The Tools available line in the report header must enumerate all seven so a reader can see at a glance which were skipped. ## Tools to run ```sh # Determine scope — diff stats first git diff --stat origin/main...HEAD git diff --name-only origin/main...HEAD # Baseline tests python -m pytest -q # Tool availability check (inform the report header) for tool in ruff mypy bandit pip-audit safety xmllint stylelint; do command -v "$tool" >/dev/null 2>&1 && echo "$tool: available" || echo "$tool: missing" done ``` ## Handoff This orchestrator is **terminal** for the reviewer chain — its output goes directly to the operator, who then dispatches the named author skills based on the consolidated hand-off summary. No further hand-off needed from this skill. ## Verify The orchestrator's correctness check: 1. Did all four reviewers complete? (If one failed, the report must say which and why.) 2. Are findings deduped (no duplicate `file:line` entries)? 3. Is the Top 3 actionable list non-empty (or explicitly "no findings")? 4. Does each finding name a fix owner? 5. Is the test-suite status reported? If any of those fail, the orchestrator's output is incomplete — say so rather than silently emit a half-report. --- > Source: [AICincy/HCJC](https://github.com/AICincy/HCJC) — distributed by [TomeVault](https://tomevault.io).