MrPointer
21 verified skills42 total stars
documenting-business-processes
Document business processes and workflows that a system implements. Describes end-to-end flows like user registration, order fulfillment, or payment processing — how domain entities move through the system. Use when (1) business workflows are undocumented, (2) a flow spans multiple components and no single component's docs tell the full story, (3) agents need to understand end-to-end behavior to implement changes, or (4) stakeholders need visibility into how the system handles a business process. NOT for development processes — those belong in skills and contribution guidelines.
development2
documenting-components
Create documentation for specific components or areas of a codebase. Analyzes targeted code sections and produces structured documentation useful to both humans and AI agents. Use when (1) documenting an undocumented component or module, (2) building initial docs for a new area, (3) an agent discovers documentation gaps during codebase exploration, or (4) onboarding documentation is needed for a complex subsystem. Always targets a specific component — never documents the entire codebase at once.
development2
documenting-library-guides
Create user-facing documentation for libraries — the kind of docs you'd find on a static documentation site. Guides readers through the library with an engaging, conversational tone, real code examples drawn from the actual codebase, and a navigable site-like structure. Use when (1) a library has no user-facing docs beyond inline code comments, (2) existing docs are API references with no narrative guidance, (3) users need task-oriented guides to accomplish common goals, or (4) a library's docs need restructuring into a browsable, site-ready format.
development2
documenting-domain
Document business domain concepts, terminology, entity relationships, and domain rules for a project. Produces documentation that establishes the shared language used by both humans and AI agents. Use when (1) a project's domain concepts are undocumented, (2) agents misinterpret business terminology, (3) onboarding new team members who need to understand the business model, or (4) domain knowledge is scattered across code and needs consolidation. This is the most foundational documentation layer — all other docs reference it.
development2
documenting-architecture
Document system architecture, design decisions, layer boundaries, and how components connect and communicate. Use when (1) a project's architecture is undocumented, (2) agents can't figure out how the system fits together, (3) after major refactoring that changed system structure, or (4) onboarding developers who need to understand the big picture. References domain concepts — never redefines them.
development2
planning-project-features-direct
Create implementation plans directly from user requirements when no reviewed RFC is available or the user explicitly declines RFC-first planning. Decomposes work into self-contained sub-plans with full iterative multi-agent plan review.
tools2
executing-plans
Use when executing implementation plans. Orchestrates task execution with testability-gated TDD, progress checkpointing, and dispute batching. Works with any plan structure that has identifiable tasks and acceptance criteria. Handles resumption after interruptions.
testing2
planning-project-features-from-rfc
Create implementation plans from a reviewed RFC. Uses the RFC as the approved design baseline, decomposes it into executable sub-plans, and runs RFC-specific plan review.
testing2
authoring-rfcs
Use when turning a settled design direction, brainstorming outcome, context anchor, or architecture discussion into a codebase-grounded RFC. Produces self-contained RFC documents with verified current architecture, chosen design, tradeoffs, risks, stable references, and planning handoff context without creating implementation plans.
development2
planning-project-epics-from-rfc
Decompose a reviewed RFC into sequenced features for a single project. Uses the RFC as the approved design baseline and produces a persistent epic plan reviewed for RFC fidelity and feature decomposition.
content-media2
applying-architecture-patterns
Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design. Use when (1) designing new backend systems from scratch, (2) refactoring monolithic applications for better maintainability, (3) establishing architecture standards for a team, (4) migrating from tightly coupled to loosely coupled architectures, (5) implementing domain-driven design principles, (6) creating testable and mockable codebases, or (7) planning microservices decomposition.
development2
applying-effective-go
Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use when writing, reviewing, or refactoring Go code to ensure idiomatic, clean, and efficient implementations.
development2
developing-plan-reviewers
Create project-specific plan reviewer agents that integrate with the planning-project-features workflow. Use when a project needs domain-specialized reviewers for sub-plans (e.g., Go code reviewer, API layer reviewer, database reviewer) or when the planner warns that no suitable local reviewer exists for a sub-plan's domain.
development2
test-driven-development
Use when implementing features or fixes. Write tests first from acceptance criteria, confirm they fail, then implement to make them pass. Prevents the common agent failure mode of writing tests that rationalize implementation rather than verify requirements.
development2
planning-project-epics-direct
Decompose large efforts directly from user requirements when no reviewed RFC is available or the user explicitly declines RFC-first epic planning. Produces a persistent epic plan with rich feature descriptions that feed into planning-project-features separately.
tools2
creating-github-pull-requests
Create GitHub Pull Requests with consistent, high-quality titles and descriptions. Use when opening a PR on GitHub — covers title formatting, summary, decision log, and before/after comparison.
development2
creating-azure-devops-pull-requests
Create Azure DevOps Pull Requests with consistent, high-quality titles and descriptions. Use when opening a PR in Azure DevOps - covers JIRA-based title formatting, summary, decision log, and before/after comparison.
development2
planning-project-epics
Route epic planning to the correct workflow. Recommends RFC-first design when no RFC exists, sends reviewed RFCs to RFC-backed epic planning, and sends explicit opt-outs to direct epic planning.
testing2
anchoring-context
Maintain concise feature-level working memory across sessions, teammates, and agents. Use when work spans multiple conversations; involves meaningful decisions, rejected alternatives, unresolved questions, or teammate/subagent handoffs; requires durable context before, during, or after brainstorming, planning, debugging, or implementation; or when the user asks to resume, continue, hand off, or preserve context for a feature. Skip for quick one-off questions, trivial edits, and work whose full context fits safely in a single short interaction.
development2
brainstorming
Use when exploring a problem space before implementation or planning. Turns rough ideas into validated, codebase-grounded RFCs through collaborative dialogue — challenges assumptions, explores alternatives, and converges on a committed design direction before final RFC authoring.
development2
planning-project-features
Route feature planning to the correct workflow. Recommends RFC-first design when no RFC exists, sends reviewed RFCs to RFC-backed planning, and sends explicit opt-outs to direct planning.
testing2