pragmatic-devx-plugin

This skill should be used when the user asks to "check if the code conforms to the architecture spec", "verify architecture conformance", "does the code follow the arch spec?", "check if the project respects the architecture", "validate architecture rules in the codebase", "run an architecture check", "arch conformance check", or wants to verify that the actual project structure and code comply with documented architecture technical specifications.

This skill should be used when the user asks to "create an architecture spec", "document the architecture", "write an architecture document", "create arch spec for this module", "document this system's architecture", "generate an ADR", "create architecture documentation for this service", "write arch spec for integration", or needs to formally document the architecture of a system, module, layer, or integration.

This skill should be used when the user asks to "update an architecture spec", "revise the arch spec", "update this architecture document", "add a new ADR", "change the component boundaries", "fill in the TODOs in the arch spec", "correct the architecture spec", or wants to apply new decisions, corrections, or intentional deviations to an existing architecture technical specification document.

This skill should be used when the user asks to "validate an architecture spec", "check the arch spec", "review this architecture document", "is this arch spec complete?", "audit the architecture spec", "check architecture quality", "validate the ADRs", "is this arch spec ready for approval?", "is the architecture document ready to use?", or wants a structured quality review of an existing architecture technical specification document.

This skill should be used when the user asks "what pragmatic skills are available", "how do I use this plugin", "what can pragmatic do", "show me the skill map", "which skill should I use", "how do I document a feature", "how do I create a spec or architecture doc", "what is the pragmatic workflow", or when starting a session with the pragmatic-devx plugin installed and there is no clear skill to invoke yet — establishes the document hierarchy and maps each skill to its purpose and trigger.

This skill should be used when the user asks to "create a project constitution", "define global project rules", "set up project governance", "create a constitution", "define what the AI can decide alone", "define cross-module rules", "document global architecture decisions", "establish project-wide constraints", or wants a single source of truth for decisions that apply across all modules, features, and architecture specs — above any individual arch spec or feature spec.

This skill should be used when the user asks to "update the constitution", "update the project constitution", "add a global rule", "change a tech stack decision in the constitution", "add a cross-module constraint", "update the AI guardrails", "add a compliance requirement to the constitution", "revise the constitution", "add a new rule that applies to all modules", or wants to apply targeted changes to an existing project constitution document without replacing it.

This skill should be used when the user asks to "reverse engineer a spec from this code", "generate a spec from the existing code", "document what this code already does", "backfill a spec for this legacy module", "create a spec by reading the implementation, not from a description", "this module has no documentation, can you write a spec from what's actually there", or wants a feature spec or architecture spec produced primarily by reading existing, undocumented code rather than from a stated feature idea or architecture decision.

This skill should be used when the user asks to "implement the spec", "build this feature from the spec", "start implementing docs/specs/X.md", "build based on the spec", "implement the acceptance criteria", "code this feature", "build it following the spec", or wants to translate an approved specification document into a working implementation — guided by spec decisions, architecture constraints, and project rules.

This skill should be used when the user asks to "verify if the implementation follows the spec", "check conformance with the spec", "is the code aligned with the spec?", "audit implementation against the spec", "check if the acceptance criteria were implemented", "does the code match the spec", or wants to compare an existing implementation against a specification document.

This skill should be used when the user asks to "create a spec", "write a technical specification", "document this feature as a spec", "create a spec for this story", "create spec for module", "generate a spec", "write a spec document", or needs to formalize a feature, story, or module as a structured technical specification document.

This skill should be used when the user asks to "update a spec", "update this specification", "revise the spec", "add requirements to the spec", "change the spec", "fill in the TODOs in the spec", "correct the spec", or wants to apply new decisions, corrections, or requirements to an existing specification document.

This skill should be used when the user asks to "validate a spec", "check if this spec is complete", "review the spec for completeness", "is this spec good?", "check the spec quality", "review this specification", "audit the spec", or wants a structured quality review of an existing specification document.