grill-feature

Perform adversarial design reviews for cross-service software changes.

4|Updated Jul 20, 2026
One-click install
npx skills add https://github.com/highflame-ai/ai-factory --skill grill-feature
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grill-feature
Source: https://github.com/highflame-ai/ai-factory/tree/main/skills/grill-feature
Command: npx skills add https://github.com/highflame-ai/ai-factory --skill grill-feature

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill prevents costly architectural drift and structural ambiguity by forcing a rigorous, adversarial review of high-stakes changes before any implementation begins.

Core Features & Use Cases

  • Adversarial Interrogation: Systematically interviews the user to uncover hidden risks in cross-service contracts, authz schemas, and platform invariants.
  • Evidence-Based Anchoring: Mandates the use of project-specific design sources like ADRs, architecture docs, and checklists to ensure decisions are grounded in reality rather than memory.
  • Decision Capture: Automates the creation of spec-registry entries, ADR drafts, or PR-ready assumption blocks to ensure design intent is preserved.

Quick Start

Invoke the grill-feature skill to perform an architectural review on your proposed cross-service feature change.

Frequently Asked Questions about grill-feature

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review architecture for cross-service changes before implementation?

To review architecture for cross-service changes, perform an adversarial design review that interrogates scope, platform invariants, and shared contracts. This process anchors decisions in project-specific documentation like ADRs to uncover hidden structural risks.

What is adversarial design review in software engineering?

Adversarial design review is a rigorous interrogation process that evaluates high-stakes architectural changes before implementation. It systematically interviews stakeholders to uncover hidden risks in cross-service contracts, authz schemas, and platform invariants using established checklists.

How do I document architectural decisions and design assumptions for a new feature?

Document architectural decisions by capturing the design review outcomes as spec-registry entries, ADR drafts, or PR-ready assumption blocks. This ensures design intent is preserved and prevents structural ambiguity during implementation.

When do I need an architectural review for spec-driven development?

You need an architectural review for spec-driven development when proposing cross-service, contract-touching, or platform-invariant changes. It prevents costly architectural drift by forcing a rigorous evaluation of scope and shared contracts before implementation begins.

Can I use existing architecture docs and checklists to validate high-stakes software changes?

Yes, you can validate high-stakes software changes by anchoring the review in existing architecture docs, ADRs, and established checklists. This evidence-based approach ensures design decisions are grounded in project-specific documentation rather than memory.

What is the best way to prevent architectural drift in distributed systems?

The best way to prevent architectural drift is to mandate an adversarial design review that interrogates cross-service contracts and platform invariants before implementation. Capturing these decisions in ADR drafts and spec-registry entries preserves structural integrity.