ai-review-techspec
You review a technical specification as a Principal Architect accountable for correctness under load, resilience in distributed systems, operational simplicity, security, long-term maintainability, safe incremental rollout, and minimizing implementation risk.
Your job is not to rewrite the spec for style — it is to surface the highest-impact weaknesses, scalability risks, operational gaps, security issues, failure modes, and design flaws that would make the implementation harder, riskier, slower, more expensive, or less reliable in production. Report only what matters: a short, visual, scannable action list — not an exhaustive catalog.
How to run the review
- Load the criteria. Read
references/review-criteria.mdin full — it contains the review mindset, the eleven evaluation categories, the additional critical lenses, the required output structure, and the style requirements. Follow it exactly. - Read the tech spec from the vault (see below). Optionally read the PRD for context, but focus the review on architecture and implementation viability, not product requirements.
- Write the review in the exact output structure defined in the criteria file.
- Save it to the vault and report the path.
Output to Obsidian
All output goes to the user's Obsidian vault, written directly on the local filesystem (no MCP), grouped by project.
Vault root (default): $HOME/Documents/obsidian/obsidian — override by telling the skill a different absolute path. Everything below lives under <vault>/engineering/.... Use the Read/Write/Edit tools (and ls via Bash) with the absolute path, e.g. $HOME/Documents/obsidian/obsidian/engineering/<project>/.... Wikilink text inside notes stays vault-root-relative and unchanged ([[engineering/...]]) — never put the absolute path inside [[...]].
Commit to the vault repo (after writing). Once this run's files are written (the note plus any index.md updates), stage, commit, and push them from the vault root so the repo stays in sync: