@doxbrix/doxloop 0.1.0

package/skills/doxloop-authoring/references/domain-infrastructure-devops.md

@@ -0,0 +1,67 @@
+# Infrastructure and DevOps expertise
+
+Use when readers provision, deploy, configure, observe, scale, upgrade, or
+recover infrastructure, platforms, services, clusters, or developer environments.
+
+## Think like a senior platform documentation architect
+
+Treat an operational procedure as a controlled state transition. Identify
+dependencies, authority, desired state, blast radius, health signals, rollback,
+and recovery verification. Separate initial deployment, routine operations,
+change management, and incident response.
+
+## Investigate
+
+- supported topology, components, dependencies, ports, protocols, and environments;
+- installation artifacts, versions, resource requirements, and platform support;
+- configuration sources, precedence, secrets, reload or restart behavior;
+- provisioning idempotency, state storage, drift, locking, and concurrency;
+- health, readiness, metrics, logs, traces, events, and diagnostic bundles;
+- scaling, capacity signals, quotas, limits, maintenance, and scheduling;
+- upgrades, compatibility, schema or state migration, rollback, and downgrade;
+- backup scope, consistency, retention, restore, disaster recovery, and verification;
+- high availability, failure domains, traffic handling, and degraded states;
+- security boundaries, network access, administrative roles, and audit evidence.
+
+## Design coverage
+
+Give a supported reference deployment, then expose decision points rather than
+pretending one topology fits all. Every procedure must include prechecks,
+commands or actions, expected signals, abort conditions, rollback when supported,
+and post-change verification. Put destructive recovery behind explicit warnings.
+
+Use runbooks for observable incidents and reference pages for configuration and
+signals. Keep commands deterministic and scope targets explicitly. Distinguish
+development convenience from production guidance.
+
+## Navigation overlay
+
+Insert supported destinations following the operating lifecycle:
+
+```text
+Architecture and environments
+Provisioning and installation
+Configuration and secrets
+Deployment and readiness
+Observability
+Scaling and capacity
+Routine maintenance
+Upgrade and rollback
+Backup, restore, and disaster recovery
+Incident diagnostics
+```
+
+Put health verification immediately after deployment and recovery procedures.
+
+## Never assume
+
+Do not claim high availability, zero downtime, horizontal scaling, backup
+consistency, restore objectives, rollback safety, autoscaling, resource sizing,
+or production readiness without evidence. A process starting is not sufficient
+health verification.
+
+## Senior quality gate
+
+An operator must be able to deploy the supported topology, verify service
+health, understand configuration and failure scope, perform a supported change,
+and recover or escalate using observable evidence rather than guesswork.

package/skills/doxloop-authoring/references/domain-payments-fintech.md

@@ -0,0 +1,69 @@
+# Payments and fintech expertise
+
+Use when the public product moves, authorizes, records, settles, reconciles, or
+reports money or other regulated financial value. Pair with the API-platform,
+SaaS, or infrastructure template when appropriate.
+
+## Think like a senior payments documentation lead
+
+Document money movement as an explicit state machine with actors, amounts,
+currency, timing, identifiers, irreversible boundaries, and failure recovery.
+Separate customer intent, provider processing, ledger or balance effects, bank
+or network settlement, and reporting when the product exposes those distinctions.
+
+## Investigate
+
+- supported payment or transfer instruments, regions, currencies, and environments;
+- amount representation, rounding, precision, fees, exchange, and balance effects;
+- authorization, capture, cancellation, refund, reversal, dispute, and settlement states;
+- idempotency, duplicate prevention, concurrency, retry, and timeout behavior;
+- synchronous responses versus asynchronous completion and event delivery;
+- webhook signatures, event versions, replay, deduplication, ordering, and recovery;
+- customer, merchant, account, mandate, payout, invoice, and reconciliation identifiers;
+- authentication, permissions, sensitive-data boundaries, logging, and redaction;
+- test data, sandbox differences, operational cutoffs, reports, and exception handling.
+
+## Design coverage
+
+Lead with a safe test-environment success path. Explain lifecycle diagrams in
+text and visuals only when every state and transition is evidenced. Put amounts,
+currency, identifiers, idempotency, error handling, and asynchronous completion
+near the first integration—not as late production notes.
+
+Show readers how to recognize accepted, pending, completed, failed, canceled,
+refunded, or disputed outcomes supported by the product. Separate customer-facing
+status from settlement or ledger status when they differ. Provide reconciliation
+and exception workflows only where public evidence supports them.
+
+## Navigation overlay
+
+Insert supported destinations into Concepts, Integration guides, Reference, and
+Operations:
+
+```text
+Money, currencies, and identifiers
+Payment or transfer lifecycle
+Idempotency and duplicate prevention
+Asynchronous processing and webhooks
+Capture, cancellation, refund, and reversal
+Disputes and exceptions
+Settlement, balances, and reconciliation
+Testing and go-live
+```
+
+Order lifecycle concepts before task guides that depend on state transitions.
+
+## Never assume
+
+Do not claim PCI, banking, privacy, sanctions, consumer-protection, tax, or other
+regulatory compliance from source inspection. Do not invent settlement times,
+fund availability, exchange rates, dispute rights, exactly-once processing,
+webhook ordering, loss guarantees, or production parity. Never place real
+financial or personal data in examples or screenshots.
+
+## Senior quality gate
+
+An integrator must be able to prevent accidental duplicates using supported
+mechanisms, represent money correctly, track the evidenced lifecycle, verify
+asynchronous notifications, distinguish retryable failure, and reconcile the
+observable outcome without relying on optimistic assumptions.

package/skills/doxloop-authoring/references/domain-saas.md

@@ -0,0 +1,71 @@
+# SaaS application expertise
+
+Use for multi-user hosted applications whose reader-visible model includes
+accounts, organizations, workspaces, roles, subscriptions, or browser-based
+workflows.
+
+## Think like a senior SaaS documentation architect
+
+Model the experience across three layers: individual identity, shared account or
+workspace, and service-wide behavior. Identify which actor owns each action,
+where settings apply, when changes take effect, and what persists across sessions
+or plan changes. Treat onboarding, daily work, administration, and offboarding as
+different journeys.
+
+## Investigate
+
+- signup, invitation, authentication, session, password, and recovery flows;
+- workspace or organization creation, switching, transfer, suspension, deletion;
+- roles, permissions, ownership, approval, and delegation boundaries;
+- the product's primary object lifecycle and collaboration behavior;
+- configuration scope, defaults, inheritance, and propagation;
+- subscription, plan, quota, trial, invoice, or billing behavior when public;
+- import, export, retention, deletion, notification, and audit capabilities;
+- UI labels, empty states, errors, accessibility labels, and responsive behavior;
+- browser, locale, region, or feature-availability commitments supported by evidence.
+
+## Design coverage
+
+Separate getting-started content by actor when setup requires both an owner and
+members. Put common daily jobs before rare settings. Give administrators a
+bounded administration area rather than mixing organization-wide changes into
+end-user pages. Connect plan or permission restrictions to the exact task they
+block.
+
+For each workflow, state the required role, starting state, scope of effect,
+observable result, and supported reversal. Explain destructive or account-wide
+actions before the reader commits them. Document alternative paths only when
+they are supported and materially useful.
+
+## Navigation overlay
+
+Insert supported destinations into the selected type blocks:
+
+```text
+Workspaces or organizations
+Users, groups, roles, and permissions
+Authentication and account recovery
+Shared configuration and integrations
+Plans, usage, and billing
+Audit, export, retention, and deletion
+```
+
+Place daily user tasks in Guides and organization-wide controls in
+Administration. Never merge personal settings with workspace policy merely
+because the UI places them near each other.
+
+## Never assume
+
+Do not infer tenant isolation, encryption, backup, regional residency, uptime,
+data retention, auditability, SSO, SCIM, regulatory compliance, accessibility
+conformance, or subscription entitlements from generic SaaS patterns. Verify
+each claim from public interfaces, tests, configuration, policies supplied as
+source, or approved product behavior.
+
+## Senior quality gate
+
+A new owner must be able to reach first value; a member must understand their
+available work; and an administrator must be able to predict the scope and
+consequence of supported configuration changes. Terminology for account,
+organization, workspace, project, member, role, and owner must remain exact and
+consistent.

package/skills/doxloop-authoring/references/domain-security-identity.md

@@ -0,0 +1,65 @@
+# Security and identity expertise
+
+Use when identity, authentication, authorization, policy, secrets, audit, or
+security operations are primary reader-visible capabilities.
+
+## Think like a senior security documentation lead
+
+Describe trust boundaries and authority precisely. Distinguish identity proof,
+authentication, session establishment, authorization, policy evaluation,
+credential lifecycle, and auditing. State actor, resource, scope, decision, and
+observable result for every sensitive workflow.
+
+## Investigate
+
+- identity types, directories, federation, enrollment, verification, and recovery;
+- authentication factors, protocols, sessions, expiry, revocation, and step-up behavior;
+- roles, permissions, scopes, policy evaluation, inheritance, and deny/allow precedence;
+- service accounts, API credentials, keys, certificates, secrets, and rotation;
+- provisioning and deprovisioning, ownership transfer, break-glass paths, and lockout;
+- audit events, timestamps, actors, targets, retention, export, and integrity claims;
+- alerts, detections, incident states, containment, recovery, and evidence collection;
+- public data flows, storage boundaries, logging, redaction, and administrative access;
+- supported security configuration, defaults, limitations, and compatibility.
+
+## Design coverage
+
+Put secure setup and least-authority guidance before convenient shortcuts. State
+the role and scope required for every administrative action. Explain default
+behavior, propagation, revocation timing, recovery, and audit evidence where
+supported. Separate end-user access recovery from administrator incident actions.
+
+Use fictional identities and redacted tokens. Never include executable examples
+that weaken verification, bypass authorization, disable protection without
+context, or expose credentials. Explain risk before consequential configuration.
+
+## Navigation overlay
+
+Insert supported destinations by the identity and authority lifecycle:
+
+```text
+Identities and directories
+Authentication and recovery
+Sessions and factors
+Roles, permissions, and policy
+Service accounts and credentials
+Provisioning and deprovisioning
+Audit events and reporting
+Alerts, incidents, and recovery
+```
+
+Place secure setup, authority boundaries, and lockout recovery before convenient
+administrative shortcuts.
+
+## Never assume
+
+Do not claim zero trust, least privilege, encryption properties, tamper-proof
+auditing, protocol conformance, certification, compliance, breach prevention,
+revocation latency, or secure defaults without authoritative evidence. Do not
+publish internal detection logic or sensitive architecture without a reader need.
+
+## Senior quality gate
+
+A reader must understand who can perform each sensitive action, what authority
+is granted, where credentials live, how access is revoked and verified, what is
+audited, and how to recover from supported lockout or compromise scenarios.

package/skills/doxloop-authoring/references/editorial-style.md

@@ -0,0 +1,105 @@
+# Doxloop editorial standard
+
+Apply this house standard unless the persisted documentation brief names a
+project-specific alternative.
+
+## Resolve conflicting guidance
+
+Use this precedence:
+
+1. confirmed project terminology, audience, and house style;
+2. verified product behavior and public interface names;
+3. this Doxloop editorial standard;
+4. the configured external style guide;
+5. general language conventions.
+
+Use Diátaxis to distinguish tutorials, how-to guides, reference, and
+explanation. Use the Google developer documentation style guide as the default
+external editorial reference and Microsoft technical-writing guidance as a
+supplement. Treat these as guidance, not proof of formal conformance. Do not
+copy external standards or style guides into the documentation.
+
+For a formal information-development program, map the workflow and quality
+evidence to a licensed copy of ISO/IEC/IEEE 26514:2022. Do not claim ISO
+conformance from this house standard or an agent review alone.
+
+## Write in a professional voice
+
+- Address the reader as **you** when giving instructions.
+- Prefer active voice, concrete verbs, and present tense.
+- Be direct, respectful, calm, and technically precise.
+- Use everyday language when it remains accurate. Define necessary specialist
+  terms on first use for readers who may not know them.
+- Avoid hype, jokes that may not translate, idioms, blame, and false certainty.
+- Use contractions only when they fit the confirmed voice.
+- Do not use *simple*, *easy*, *obvious*, or *just* to dismiss reader effort.
+
+## Make content scannable
+
+- Use sentence case for titles and headings.
+- Put the reader outcome or most important condition first.
+- Keep paragraphs focused on one idea.
+- Use a list only for genuinely parallel items.
+- Use numbered steps only for sequences.
+- Introduce tables only when readers need to compare several exact values.
+- Use descriptive link text that makes sense out of context. Never use
+  *click here*, *here*, or *read more* as the complete link text.
+- Keep notes close to the text they qualify. Reserve warnings and dangers for
+  material risk rather than general emphasis.
+
+## Keep titles and headings concise
+
+- Write task-page titles with a direct imperative verb. Prefer *Keep
+  documentation updated* over *Keeping documentation updated*.
+- Aim for 3–7 words and no more than 50 characters in a page title.
+- Aim for 2–5 words and no more than 32 characters in a navigation label.
+- Aim for 2–7 words and no more than 45 characters in a section heading that
+  appears in the page table of contents.
+- Shorten a navigation label when needed, but preserve the meaning of the page
+  title. Do not repeat the navigation group name in each child label.
+- Move qualifications and explanatory detail into the page description or
+  opening paragraph.
+- For CLI and API reference sections, use only the command, operation, or
+  resource name as the heading. Put arguments, options, methods, and paths
+  immediately below the heading.
+- Treat the length limits as warning thresholds, not hard errors. Keep an exact
+  product or interface name when shortening it would make the documentation
+  inaccurate.
+
+## Write usable procedures
+
+- State the goal and prerequisites before the first step.
+- Begin each step with the reader action.
+- Put one primary action in each step.
+- Place conditions before the action when they change what the reader must do.
+- Keep explanatory asides outside the step sequence when possible.
+- Show the observable result after a meaningful action or at the end.
+- Provide recovery guidance only when supported by product evidence.
+- End with the next useful action, not a generic conclusion.
+
+## Keep terminology stable
+
+- Use the exact names visible in the product UI, CLI, API, and configuration.
+- Apply the terminology map in `.doxloop/project.json`.
+- Use one preferred term for one concept; do not vary wording for style.
+- Expand unfamiliar abbreviations on first use unless the audience brief says
+  they are assumed knowledge.
+- Preserve capitalization used by public product interfaces.
+- Format commands, files, keys, parameters, values, and code identifiers as
+  code where the selected generator supports it.
+
+## Support global readers
+
+- Use complete, conventional sentence structures.
+- Keep the subject and verb close together.
+- Avoid ambiguous pronouns and long chains of clauses.
+- Include articles such as *a*, *an*, and *the* when required.
+- Use locale-appropriate spelling, dates, numbers, and punctuation from the
+  persisted brief.
+- Do not encode meaning in wordplay or culturally specific references.
+
+## Exclude editorial noise
+
+Do not include generic introductions, repeated product claims, invented
+benefits, internal implementation trivia, unsupported superlatives, redundant
+summaries, or prose that exists only to make a page longer.

package/skills/doxloop-authoring/references/examples-and-evidence.md

@@ -0,0 +1,71 @@
+# Evidence and example standard
+
+Use this standard whenever documentation states product behavior or contains a
+command, request, configuration, or code sample.
+
+## Track claim status
+
+Classify material while researching:
+
+- **Verified by execution**: a safe local command or example completed and its
+  observable result matched the documentation.
+- **Verified by source**: a public interface, schema, test, or fixture directly
+  supports the claim.
+- **Inferred**: several sources support the conclusion, but no public contract
+  states it directly.
+- **Unverified**: the available evidence cannot establish the behavior.
+
+Publish verified claims. Include an inference only when it is necessary, label
+the uncertainty, and avoid promising unsupported behavior. Do not publish an
+unverified claim as fact.
+
+Keep a working evidence map from each planned page or public capability to the
+configured source file, schema, test, fixture, or safe execution that supports
+it. Use configured source names and relative paths in working notes. Never copy
+local absolute paths into reader-facing documentation or deployment content.
+
+## Build trustworthy examples
+
+For every example:
+
+1. Define what the reader will accomplish.
+2. State required versions, permissions, setup, files, and environment.
+3. Use the smallest realistic input that demonstrates the supported behavior.
+4. Use exact public names, flags, keys, types, and values.
+5. Use visibly fake credentials and reserved example domains where needed.
+6. Show the command, request, configuration, or code in a copyable form.
+7. Show the expected output or explain the observable success condition.
+8. Include cleanup when the example creates billable, persistent, or sensitive
+   resources.
+9. Verify the example safely by execution when possible; otherwise verify every
+   material detail against public source and tests.
+
+Keep example output short and stable. Replace volatile IDs, timestamps, and
+paths with clearly marked placeholders without changing their required shape.
+Never place a placeholder where a literal value is required without explaining
+how the reader obtains it.
+
+## Protect readers and source
+
+- Never use or reveal real credentials, tokens, personal data, internal hosts,
+  private identifiers, or unpublished endpoints.
+- Do not run destructive, billable, privileged, or remote actions solely to
+  verify documentation without explicit user approval.
+- Explain security consequences before a risky action.
+- Prefer least-privilege permissions in examples.
+- Do not recommend disabling security controls as a generic fix.
+- Do not copy implementation details into reference material when the public
+  contract provides the correct reader-facing description.
+
+## Cover specialized public interfaces
+
+For CLI reference, verify commands, arguments, flags, defaults, environment
+behavior, output, exit behavior, and failure cases.
+
+For API reference, prefer the project's declared OpenAPI or equivalent schema.
+Cover authentication, methods and paths, parameters, request and response
+shapes, status or error behavior, limits, and one verified example. Follow the
+version of the interface description present in the configured source.
+
+For configuration reference, verify keys, types, defaults, allowed values,
+precedence, restart or reload behavior, security implications, and examples.

package/skills/doxloop-authoring/references/navigation-architecture.md

@@ -0,0 +1,152 @@
+# Professional navigation architecture
+
+Use this reference when creating a site, adding a reader journey, restructuring
+documentation, or reviewing information architecture. Define a semantic
+navigation plan first; then use the selected generator skill to implement it in
+native configuration.
+
+## Compose navigation
+
+Build navigation in this order:
+
+1. start with the common site frame;
+2. add the blocks from each selected documentation-type playbook;
+3. apply the primary and adjacent domain overlays;
+4. use audience flavor to change emphasis, ordering, terminology, and depth;
+5. remove unsupported, empty, duplicate, or out-of-scope destinations;
+6. translate the semantic plan into the generator's top navigation, sidebar,
+   menu, toctree, page map, or manifest.
+
+Templates propose reader destinations; configured product evidence determines
+whether the destination exists and what it says.
+
+## Common top navigation
+
+Use top navigation for major documentation surfaces, not for every content
+group. Keep approximately five primary items and preserve project conventions.
+
+| Slot | Default label | Include when |
+| --- | --- | --- |
+| Primary | Documentation | always for a documentation site |
+| Reference surface | API, SDKs, CLI, or Reference | a substantial maintained lookup surface exists |
+| Integration surface | Integrations | integrations are a primary product destination |
+| Lifecycle | Release notes | release-visible change is maintained |
+| Help | Support | a verified support destination exists |
+
+Search, version, locale, theme, repository, status, and product-dashboard links
+are utilities. Place them in generator-native utility controls or secondary
+links instead of displacing the primary reader journey. Never invent a support,
+status, repository, changelog, or product URL.
+
+Promote at most two product surfaces such as API, SDKs, CLI, Integrations, or
+Administration. Keep the rest inside Documentation. Use one stable label for a
+destination across desktop, mobile, breadcrumbs, and side navigation.
+
+## Common left-navigation grammar
+
+Order groups by the reader's progression:
+
+```text
+Overview
+
+Getting started
+  Prerequisites
+  Installation or access
+  Quickstart
+  Next steps
+
+Guides
+  Common workflows
+  Advanced workflows
+  Integrations
+
+Concepts
+  Core concepts
+  Resource or object lifecycle
+  Security or trust model
+
+Reference
+  Public interface reference
+  Configuration
+  Errors and limits
+
+Operations
+  Deployment or administration
+  Observability
+  Backup and recovery
+
+Troubleshooting
+  Diagnose problems
+  Error reference
+  Get support
+
+Releases
+  Migration guides
+  Deprecations
+  Release notes
+```
+
+This is a grammar, not a mandatory page tree. Omit a group when no selected
+type/domain module contributes a supported reader destination.
+
+## Size the structure
+
+### Compact
+
+Use for one primary workflow and a small public surface. Keep Overview, Getting
+started, Guides, Reference, and Troubleshooting as needed. Prefer pages over
+single-item groups.
+
+### Standard
+
+Use by default for a product with several workflows. Include distinct Getting
+started, Guides, Concepts, Reference, and Troubleshooting groups; add Operations
+or Releases when supported.
+
+### Comprehensive
+
+Use when several reader journeys or public surfaces need independent depth.
+Create top-level surfaces or spaces only when they have their own overview,
+onboarding path, tasks, concepts, reference, and maintenance needs. Avoid one
+sidebar that mixes unrelated audiences and becomes difficult to scan.
+
+## Merge type blocks
+
+- Keep one Overview destination for the site or major surface.
+- Merge duplicate Getting started groups and order their pages by dependency.
+- Put outcome-focused pages under Guides; do not group by source directory.
+- Share a concept page only when its mental model is identical for all readers.
+- Keep API, SDK, and CLI reference boundaries distinct even if top navigation
+  exposes only one `Reference` destination.
+- Merge troubleshooting articles by symptom, not by the page that links to them.
+- Put migration guides before chronological release notes when readers must act.
+- Do not place the same page in primary navigation more than once; cross-link it.
+
+## Apply audience flavor
+
+- Developers see first success, guides, examples, and reference early.
+- Administrators see setup, identities, policy, configuration effect, and audit
+  before ordinary end-user workflows.
+- End users see goal-oriented tasks and personal settings before concepts.
+- Platform engineers and operators see architecture, deployment, health,
+  observability, change, and recovery early.
+- Support readers see symptom-led diagnostics and escalation evidence early.
+
+When audiences have different permissions, tools, risks, or success criteria,
+use separate navigation journeys or spaces. Do not create top-level audience
+labels merely because several audiences exist.
+
+## Navigation quality gate
+
+- Every reader-facing page is reachable exactly once through primary navigation.
+- The primary reader can identify the first step and common jobs without search.
+- Labels are 2–5 words where possible, use reader vocabulary, and remain distinct.
+- Group order follows task dependency and frequency, not alphabetic filenames.
+- Navigation normally stays within three visible levels.
+- Empty, speculative, single-item, and duplicate groups are removed.
+- Top navigation contains only verified destinations and remains usable at
+  narrow widths and keyboard zoom.
+- Routes and labels remain stable during updates unless the user requested an
+  information-architecture change or the old structure blocks reader success.
+- Breadcrumbs, previous/next links, landing-page cards, and side navigation use
+  the same hierarchy and terminology where the generator supports them.