agents in

skills/documentation/architecture-decision-records.md

@@ -0,0 +1,45 @@
+# Architecture Decision Records
+
+## Purpose
+
+Capture significant technical decisions so future contributors understand what was chosen, why it was chosen, and what tradeoffs were accepted.
+
+## When to use
+
+- A meaningful architectural or platform choice has been made
+- Multiple alternatives were considered and context would otherwise be lost
+- A decision will affect future implementation, migration, or team habits
+- You want to prevent repeated re-litigation of the same tradeoff
+
+## Inputs to gather
+
+- The decision being made
+- Alternatives considered
+- Relevant constraints, drivers, and consequences
+- Current status: proposed, accepted, superseded, or rejected
+
+## How to work
+
+- Record the decision close to when it is made.
+- Keep the record concise but concrete enough to survive future context loss.
+- Explain why the selected option won, not just what it is.
+- Include consequences so future readers understand the cost of the choice.
+- Update or supersede older records rather than leaving conflicting guidance unresolved.
+
+## Output expectations
+
+- A crisp decision record with context, choice, alternatives, and consequences
+- Status that reflects whether the decision is still tentative or settled
+- Links to implementation or follow-up docs when useful
+
+## Quality checklist
+
+- The decision is clear and specific.
+- Alternatives and tradeoffs are visible.
+- Future readers can understand the reasoning without redoing the whole discussion.
+- The record stays short enough to remain useful.
+
+## Handoff notes
+
+- Reference the implementation, technical docs, or migration plan that operationalizes the decision.
+- Pair with architecture and system design for major system changes.

skills/documentation/onboarding-docs.md

@@ -0,0 +1,45 @@
+# Onboarding Documentation
+
+## Purpose
+
+Help new contributors or users become productive quickly by reducing ambiguity, setup friction, and missing context.
+
+## When to use
+
+- Improving setup or first-run guidance
+- Writing contributor onboarding docs
+- Creating "start here" guides for internal or external users
+- Simplifying confusing developer or product entry points
+
+## Inputs to gather
+
+- Current setup steps and prerequisites
+- Common failure points, hidden assumptions, and missing context
+- Existing onboarding flow and repository conventions
+- Intended audience: contributor, operator, customer, or teammate
+
+## How to work
+
+- Optimize for first success, not exhaustiveness.
+- Put prerequisites, setup order, and validation steps in the order a new person needs them.
+- Surface gotchas early rather than burying them after failures occur.
+- Use concrete commands, examples, and expected outcomes when they reduce confusion.
+- Trim insider jargon unless it is explained.
+
+## Output expectations
+
+- A cleaner onboarding path with clear first steps
+- Documentation that reduces setup ambiguity and dead ends
+- Helpful validation or troubleshooting guidance where needed
+
+## Quality checklist
+
+- A new person can tell where to start.
+- Steps are ordered logically and are easy to verify.
+- Prerequisites and common failures are not hidden.
+- The doc avoids assuming too much existing context.
+
+## Handoff notes
+
+- Note any setup steps you could not verify directly.
+- Pair with technical docs when onboarding depends on deeper conceptual explanation.

skills/documentation/technical-docs.md

@@ -0,0 +1,45 @@
+# Technical Documentation
+
+## Purpose
+
+Create or update documentation that helps developers, operators, or advanced users understand how the system works and how to use it correctly.
+
+## When to use
+
+- Updating docs after engineering changes
+- Writing usage guides, architecture notes, or operational docs
+- Explaining APIs, workflows, configuration, or system behavior
+- Improving stale or incomplete technical documentation
+
+## Inputs to gather
+
+- The current implementation and the user-visible workflow
+- Existing docs, terminology, and structure in the repo
+- Intended audience and their technical depth
+- Any setup steps, caveats, or common failure points
+
+## How to work
+
+- Document the real behavior of the system, not the hoped-for design.
+- Prefer task-oriented structure when users need to get something done.
+- Use precise terminology that matches the code and UI.
+- Include examples, prerequisites, and pitfalls when they materially improve clarity.
+- Keep docs aligned with adjacent pages and avoid fragmenting the source of truth.
+
+## Output expectations
+
+- Clear, accurate documentation update or new draft
+- Audience-appropriate level of technical detail
+- Explicit caveats, prerequisites, and compatibility notes when relevant
+
+## Quality checklist
+
+- Instructions are accurate against the current implementation.
+- The document helps someone complete a real task or understand a real concept.
+- Terms and examples are consistent with the product and codebase.
+- Important caveats are easy to find.
+
+## Handoff notes
+
+- Mention what was verified directly in code versus inferred from context.
+- Note any related docs that should be updated later to stay consistent.