plan-lint

RustyLindquist's avatarfrom RustyLindquist

Validates a plan against documentation constraints before coding. Use after doc-discovery and before implementation. Returns PASS, WARN, or FAIL with specific issues. Gate 1 of 2-gate flow.

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 11, 2026⬇️1downloads
[Architecture Design]

When & Why to Use This Skill

The plan-lint skill is a sophisticated validation tool designed to ensure software implementation plans are strictly consistent with existing documentation and architectural constraints. By acting as a mandatory quality gate before coding begins, it identifies potential risks, calculates the 'Blast Radius' of proposed changes, and enforces safety standards like RLS and data integrity, significantly reducing technical debt and regression errors in agentic workflows.

Use Cases

  • Pre-coding Validation: Automatically check if a proposed feature plan aligns with the project's technical documentation and architectural standards to prevent design drift.
  • Risk & Blast Radius Assessment: Quantify the potential impact of a plan on sensitive areas like Auth, Billing, or Shared Components to determine the required level of human oversight.
  • Data Safety Compliance: Verify that database migrations and schema changes include necessary RLS policies and organization-scoped filtering before implementation.
  • Agentic Workflow Guardrails: Serve as the primary automated gate in a multi-agent coding pipeline to catch architectural flaws before spawning implementation agents.
  • Standardized Plan Review: Use as a checklist for peer reviews to ensure every plan includes required elements like invariants, test plans, and impacted feature lists.
nameplan-lint
descriptionValidates a plan against documentation constraints before coding. Use after doc-discovery and before implementation. Returns PASS, WARN, or FAIL with specific issues. Gate 1 of 2-gate flow.
allowed-toolsRead, Glob, Grep

Plan Lint

Ensure plan is doc-consistent before coding. Gate 1 of 2-gate flow.

When to Use

  • After /doc-discovery, before coding
  • When reviewing someone else's plan
  • Before spawning implementation agents
  • When user asks "is this plan safe?"

Required Plan Elements

Element Required
Primary Feature Yes
Impacted Features Yes
User-Facing Changes Yes
Files/Surfaces to modify Yes
Data Impact (tables, RLS) If applicable
Invariants (min 3) Yes
Test Plan Yes
Docs to Update Yes

Checks

  1. Feature Coverage: Primary named? Exists in index? Coupled features included?
  2. Invariant Coverage: At least 3? Match feature docs? High-risk addressed?
  3. Data Safety: Tables listed? RLS documented? Migration + rollback plan?
  4. Test Coverage: Verification steps? Workflow smoke test? Regression areas?
  5. Workflow Impact: Affected workflows identified? No journeys broken?
  6. Page Standards (for new pages):
    • Plan includes AIPanel with agentType
    • Plan includes contextScope configuration
    • No solid backgrounds on page containers
    • Canvas Header follows h-24, bg-white/5 pattern
  7. Org-Scoped Features (if org-specific):
    • org_id column included in relevant tables
    • RLS policies enforce org isolation
    • RAG scope includes orgId filtering

Blast Radius

Factor Points
Auth/RLS +3
Billing/credits +3
AI/prompts +2
Schema/migrations +2
3+ features +2
Org-scoped content +2
New page without AI Panel spec +2
Shared components +1
User workflow change +1

0-2: Low → Standard review 3-5: Medium → Careful review 6+: High → Doc Agent validation required

Output

## Plan Lint: [PASS/WARN/FAIL]

**Blast Radius**: [score] ([low/medium/high])

### Validation
- [x/] Primary feature: [name]
- [x/] Impacted features: [count]
- [x/] Invariants: [count]
- [x/] Test plan: [status]
- [x/] Workflow impact: [status]

### Issues (if any)
1. **[Category]**: [Problem] → [Fix]

### Ready to Implement
[Yes / Conditional / No]