north-star

Define reusable API architecture and governance rules for Plate.

16.5k|995|Updated Dec 2, 2019
One-click install
npx skills add https://github.com/udecode/plate --skill north-star-udecode
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: north-star
Source: https://github.com/udecode/plate/tree/main/.agents/skills/north-star
Command: npx skills add https://github.com/udecode/plate --skill north-star-udecode

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

North-Star codifies the governing rules for reusable Plate architecture and public API design, preventing drift by clarifying ownership, layering, and decision criteria.

Core Features & Use Cases

  • Establish canonical ownership and layering for reusable APIs across Plate surfaces.
  • Provide decision ladders and routing guidance for when to apply north-star guidance versus execution companions.
  • Define reaffirmation and update protocols to evolve patterns without breaking contracts.

Quick Start

Review existing reusable API patterns and route changes through the north-star doctrine before implementation.

Frequently Asked Questions about north-star

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

FAQPage Schema
How do I prevent design drift in reusable public APIs?

Prevent design drift in reusable public APIs by codifying governing rules for architecture, ownership, and layering using a north-star doctrine that specifies mandatory rules and reaffirmation protocols for consistent pattern evolution.

What is API architecture governance for Plate?

API architecture governance for Plate is a set of canonical rules and decision matrices that establish ownership, layering, and routing guidance to ensure consistent pattern ownership across reusable API surfaces.

How do I manage runtime and service boundary changes in Plate?

Manage runtime and service boundary changes in Plate by routing the architecture decisions through a decision matrix that evaluates layering rules and performance sensitivity before implementation to avoid breaking contracts.

When do I need governance rules for performance-sensitive architecture decisions?

You need governance rules for performance-sensitive architecture decisions when introducing or changing public APIs, as mandatory layering and naming rules prevent inconsistent pattern ownership and ensure reliable runtime boundaries.

Can I use this API governance approach for naming and layering rules across different surfaces?

Yes, you can apply this API governance approach to establish canonical naming and layering rules across different Plate surfaces, ensuring consistent pattern ownership and clear decision criteria for all public API changes.