Results for “decision-record”

Use when creating, maintaining, or reviewing records of actions, decisions, changes, and events for compliance, accountability, and investigation purposes. This skill provides procedures for managing audit trails across all agent activities.

Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.

Runs a relentless interview that sharpens a plan or design and creates docs (ADRs and glossary) along the way. Use when the user wants to stress-test a plan or design, or produce decision records.

Manage Constraint entities — rules and limits the project must respect (budget, latency SLO, team size, compliance). Use when recording a rule, limit, or boundary that affects decisions — budget ceiling, latency SLO, regulatory requirement, team bandwidth.

Enriches inbound leads with firmographic and technographic data. Takes minimal lead info and enriches via WebSearch, Apollo, or ZoomInfo to produce a complete lead record with company size, revenue, tech stack, social profiles, and decision-maker details.

Create or update a runbook for an operational scenario — an incident an alert fires for, a recurring scheduled task, or a known failure mode on a live service — using a consistent template. Use when writing, drafting, authoring, or updating a runbook for an alert, incident, on-call procedure, scheduled maintenance, or operational SOP. Applies a YAGNI preflight requiring the scenario to be real before producing the runbook. Does not produce feature or system documentation — use project-documentation. Does not record architectural decisions — use architectural-decision-record. Does not create coding standards — use coding-standard.

Maintains a project's domain vocabulary and records architecturally-significant decisions as they're made — a CONTEXT.md glossary and gated ADRs, not passive documentation read once. Use when terminology conflicts or turns fuzzy, when making a decision that's hard to reverse/surprising/a real trade-off, or when a stated domain rule doesn't match what the code actually does.

Use when designing a new system, choosing between architectural patterns, planning how components will connect, evaluating scalability and reliability trade-offs, or reviewing an existing system for structural problems. For system design, service boundaries, database design, API structure, monolith vs microservices decisions, and architecture decision records (ADRs). Activate when user says "how should I structure this", "design the system", "is this architecture right", or "plan the backend".

Creates and maintains project documentation for features, systems, and components. Use when documenting how a feature, system, or component works — including writing, updating, or organizing docs. Does not scan or detect the project's technology stack — use project-discovery for repository analysis and config detection. Does not create architectural decision records — use architectural-decision-record for ADRs. Does not create or update coding standards — use coding-standard instead. Does not generate PR descriptions — use update-pr-description for that. Does not produce runbooks for operational scenarios — use runbook for that. Does not rewrite existing prose for readability — use edit-for-readability for that. Does not produce an ephemeral, understand-now overview of code or a PR — use code-overview for that.

Creates or updates project documentation for a feature, system, or component and publishes it to a user-specified Confluence location. Use when the user wants feature or system documentation written to Confluence, posted to a Confluence space or page, or synced to a Confluence location. Requires a configured Atlassian MCP server. Does not document to local files only — use project-documentation for that. Does not publish an arbitrary existing markdown file — use markdown-to-confluence for that. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence for that. Does not create architectural decision records — use architectural-decision-record. Does not create coding standards — use coding-standard. Does not produce runbooks — use runbook.

Design and verify auditable human oversight, approval gates, escalation paths, and safe state transitions for AI agent workflows. Use when deciding which agent actions require review, adding approve/reject or dual-control flows, preventing unauthorized autonomous effects, creating decision records, reducing rubber-stamping, or recovering safely from rejected, expired, or failed actions.

Architecture discovery for Sage/Acorn projects — map existing codebase, discover post types, routes, ACF field groups, Livewire components, Service Providers, identify architectural gaps, architecture decision records, ADR, component boundary map, data flow diagram, risk register, implementation sequencing, discovery session, understanding unknown codebases, use before architecting or building new features, output contract, discover-abilities

Capture an Architecture Decision Record — what was decided, why, what alternatives were considered, and when to revisit. Writes a numbered ADR file to docs/adr/ in the active repo, with consistent formatting that downstream skills (improve-codebase-architecture, refactor-plan) can read. Use right after deciding something non-obvious so the reasoning isn't lost.

Create and maintain Architecture Decision Records (ADRs) optimized for agentic coding workflows. Use when you need to propose, write, update, accept/reject, deprecate, or supersede an ADR; bootstrap an adr folder and index; consult existing ADRs before implementing changes; or enforce ADR conventions. This skill uses Socratic questioning to capture intent before drafting, and validates output against an agent-readiness checklist.

Create and maintain Architecture Decision Records (ADRs) optimized for agentic coding workflows. Use when you need to propose, write, update, accept/reject, deprecate, or supersede an ADR; bootstrap an adr folder and index; consult existing ADRs before implementing changes; or enforce ADR conventions. This skill uses Socratic questioning to capture intent before drafting, and validates output against an agent-readiness checklist.

Maintains persistent project context for Business Central AL extensions across sessions, developers, and AI agents. Combines two complementary mechanisms: Architecture Decision Records (ADRs) that capture why technical decisions were made, and Session Handoff documents that capture where the project is right now. Generates, updates, and queries both document types. Use this skill whenever starting a new coding session on an existing project, ending a session and need to document progress, onboarding a new developer or AI agent to an existing codebase, explaining why a technical decision was made, wondering why something is designed a certain way, resuming work after a break, or handing off work between team members. Also trigger when the user says 'document this decision', 'why is this designed like this', 'where did we leave off', 'catch me up', 'what was decided', 'create an ADR', 'end of session', 'handoff', or 'context for next session'.

Expert knowledge for Azure DNS development including decision making, architecture & design patterns, limits & quotas, security, configuration, and integrations & coding patterns. Use when managing DNS zones/records, DNSSEC, Private DNS/resolvers, reverse DNS, or migrating legacy Private DNS, and other Azure DNS related development tasks. Not for Azure Traffic Manager (use azure-traffic-manager), Azure Front Door (use azure-front-door), Azure Virtual Network (use azure-virtual-network), Azure Private Link (use azure-private-link).

Access ClinPGx pharmacogenomics data (the successor to PharmGKB) to query gene-drug interactions, CPIC/DPWG dosing guidelines, drug labels, and pharmacogene records. Use when interpreting pharmacogenes (CYP2D6, CYP2C19, TPMT, DPYD, SLCO1B1), looking up genotype-guided drug dosing, checking PGx drug-safety associations (e.g. HLA-B*57:01 and abacavir), or supporting precision medicine and clinical pharmacogenomics decisions. For star-allele definitions/frequencies see PharmVar; for germline/somatic variant pathogenicity see alterlab-clinvar. Part of the AlterLab Academic Skills suite.

Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use automated-test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for designing a new interface or contract — use design-an-api. Not for writing documentation or architectural decision records.