@punks/cli 0.1.16 → 1.0.0

package/dist/skills/agnostic/backend/backend-domain-structure/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: backend-domain-structure
+description: |
+  Organize backend code into domain-first layers with thin transport entrypoints,
+  platform composition, external integrations, and feature-owned business behavior.
+  Use when creating or refactoring backend services, API routes, repositories,
+  providers, test layout, or import boundaries across backend frameworks.
+---
+
+# Backend Domain Structure
+
+Use this skill to keep backend code domain-based instead of transport- or utility-bucket-based.
+
+Read `references/layout.md` before structure decisions or large refactors.
+
+## Quick Classifier
+
+Place code by responsibility first.
+
+- Put root runtime composition, request context, transport runners, and router assembly in `platform/`.
+- Put external system adapters and provider mechanics in `integrations/`.
+- Put business use cases, policies, repositories, models, and transport endpoints in `features/<domain>/`.
+- Put code reused across backend package boundaries in shared libraries or packages.
+
+## Boundary Rules
+
+- Keep transport thin. Parse input, call feature behavior, map errors at the boundary.
+- Keep product policy out of `platform/` and `integrations/`.
+- Let features depend on integrations and shared libraries.
+- Do not let integrations import features.
+- Do not move app-specific business logic into shared libraries.
+- Avoid root-level generic buckets like `services`, `utils`, `helpers`, or `lib` when code can belong to a domain.
+
+## Actions, Services, Repositories
+
+Default to explicit use-case actions.
+
+- Use `actions/` for orchestration, authorization checks, policy, state transitions, and business flows.
+- Use `repositories/` for persistence reads and writes.
+- Use `services/` only for reusable mechanics or capability abstractions consumed by multiple actions.
+- Use `models/` for domain data shapes, schemas, and branded identifiers when the stack supports them.
+
+## Use This Skill
+
+- Read `references/layout.md`.
+- Identify the backend root from the current repo instead of assuming a package path.
+- Classify each file by responsibility first.
+- Group business behavior under feature domains.
+- Keep dependencies flowing: `platform -> features -> integrations -> external systems`.
+- Keep tests near the feature or module that owns the behavior.

package/dist/skills/agnostic/backend/backend-domain-structure/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Backend Domain Structure"
+  short_description: "Domain-first backend structure"
+  default_prompt: "Use $backend-domain-structure to place backend code in the correct platform, integrations, features, or shared-library layer; pair it with framework-specific backend structure skills when present."

package/dist/skills/agnostic/backend/backend-domain-structure/references/layout.md

@@ -0,0 +1,167 @@
+# Backend Domain Structure Reference
+
+## Goal
+
+Organize backend code by responsibility and domain instead of by file type.
+
+Prefer this shape inside the backend root:
+
+```text
+<backend-root>/src/
+  platform/
+  integrations/
+  features/
+```
+
+The backend root may be an app folder, package folder, service folder, or workspace package. Derive it from the current repo.
+
+## Layer Meanings
+
+### `platform/`
+
+Use `platform/` for cross-domain execution wiring.
+
+Good fits:
+
+- root app composition
+- request-scoped context construction
+- transport runners
+- router assembly
+- dependency graph assembly
+- process/runtime adapters
+
+Bad fits:
+
+- business policy
+- feature orchestration
+- direct provider details that belong to an integration
+- persistence queries that belong to repositories
+
+### `integrations/`
+
+Use `integrations/` for external systems and shared provider mechanics.
+
+Good fits:
+
+- auth provider client
+- database adapter helpers
+- email, queues, storage, billing, search, analytics, or third-party APIs
+- SDK wrappers
+- provider-specific error mapping
+
+Do not put product policy in `integrations/`. An integration says how to talk to a system; a feature decides why and when.
+
+### `features/<domain>/`
+
+Use features for business behavior.
+
+Common local folders:
+
+- `actions/`
+- `models/`
+- `repositories/`
+- `services/`
+- `tests/`
+- `errors.ts`
+- `layer.ts`, `container.ts`, `module.ts`, or equivalent composition file
+- `router.ts`, `controller.ts`, or equivalent transport adapter when the feature exposes endpoints
+
+Feature domains own use cases, policy, persistence contracts, and public behavior.
+
+## Actions vs Services
+
+Default to actions.
+
+Use `actions/` for:
+
+- orchestration
+- auth checks
+- policy
+- state transitions
+- use cases
+- multi-step workflows
+
+Use `services/` only for reusable mechanics consumed by multiple actions, such as:
+
+- provider wrappers already scoped to the feature
+- shared low-level operations
+- capability-style abstractions with stable reuse
+
+Use `repositories/` for:
+
+- persistence reads
+- persistence writes
+- query composition
+- persistence model mapping
+
+Quick rule:
+
+- "what this flow means" -> `actions/`
+- "how this reusable mechanic works" -> `services/`
+- "how data is persisted/read" -> `repositories/`
+
+Avoid broad god-services that collect unrelated use cases.
+
+## Transport Boundary
+
+Keep transport thin.
+
+- parse and validate input
+- resolve request context
+- call feature actions or query entrypoints
+- map domain failures to transport errors
+- return transport-shaped output
+
+Business logic, external side effects, and DB queries should not live directly in routers, controllers, or handlers.
+
+## Dependency Direction
+
+Prefer this direction:
+
+- `platform -> features -> integrations -> external systems`
+- `features -> shared libraries`
+- `integrations -> shared libraries`
+
+Avoid:
+
+- `integrations -> features`
+- shared libraries importing app-local code
+- transport files importing many low-level helpers instead of one feature entrypoint
+- feature domains reaching into another feature's internals
+
+Features may depend on other features only when the domain relationship is explicit, stable, and exposed through a public feature entrypoint.
+
+## Testing Layout
+
+Keep tests near the owning feature or module.
+
+Prefer:
+
+```text
+<backend-root>/src/features/<domain>/
+  tests/
+    support/
+    unit/
+    integration/
+```
+
+Testing split:
+
+- `tests/support`
+  fakes, builders, fixtures, and test-specific dependency wiring
+- `tests/unit`
+  action, guard, policy, and repository behavior with controlled dependencies
+- `tests/integration`
+  public behavior through live infrastructure or the transport/action boundary
+
+Avoid a distant package-root `tests/` folder unless the project already has a strong convention for it.
+
+## Review Checklist
+
+- Is transport thin?
+- Did business policy land in a feature?
+- Did external provider code stay in an integration?
+- Are repositories the only persistence owners?
+- Are services reusable mechanics rather than use-case buckets?
+- Are tests colocated with the owning domain?
+- Are imports flowing one way without layer inversions?

package/dist/skills/agnostic/backend/backend-recoverable-actions/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: backend-recoverable-actions
+description: |
+  Design recoverable backend action flows for multi-step mutations with explicit
+  transaction, retry, rollback, compensation, and failure-path testing strategy.
+  Use when backend work chains dependent writes, DB changes plus external side
+  effects, durable repair flows, or review of partial-failure risk.
+---
+
+# Backend Recoverable Actions
+
+Use this skill for chained multi-step backend mutations. Every mutating flow must be atomic or intentionally repairable.
+
+Do not use this for simple single-step reads or writes.
+
+Read `references/strategy-matrix.md` and `references/test-matrix.md` before implementation.
+
+## Workflow
+
+1. Enumerate the action steps in order.
+2. Classify each step:
+   - `preflight`
+   - `transactional-local`
+   - `retryable transient integration`
+   - `compensation-required external`
+   - `post-commit follow-up`
+3. Choose the failure strategy before writing code.
+4. Keep commit-path orchestration sequential unless concurrency semantics are explicit.
+5. Add failure-path tests before considering the action complete.
+
+## Hard Rules
+
+- Local multi-write groups need one explicit transaction boundary when the storage layer supports transactions.
+- Cross-system flows cannot pretend local rollback will undo auth providers, email, queues, billing, or other external writes.
+- Retries must be explicit and step-local.
+- Never retry an entire non-idempotent mutation pipeline by default.
+- External writes need compensation, durable repair state, or a documented best-effort policy.
+- Cleanup/finalization is not the same as business rollback.
+- Parallel validation is allowed before commit; parallel mutation needs explicit failure semantics.
+
+## Output Checklist
+
+- each step boundary has an explicit strategy
+- local multi-write groups have one transaction boundary
+- cross-system steps have a compensation or durable repair story
+- retries are narrow, explicit, and only for transient idempotent steps
+- expected recoverable failures stay typed or structured
+- failure-path tests cover the chosen recovery model
+- no silent partial-write risk remains undocumented

package/dist/skills/agnostic/backend/backend-recoverable-actions/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Backend Recoverable Actions"
+  short_description: "Recoverable backend mutation flows"
+  default_prompt: "Use $backend-recoverable-actions for backend action flows that chain multiple dependent operations and need explicit transaction, retry, rollback, compensation, or failure-path testing strategy; pair it with framework-specific recoverability skills when present."

package/dist/skills/agnostic/backend/backend-recoverable-actions/references/strategy-matrix.md

@@ -0,0 +1,34 @@
+# Strategy Matrix
+
+Use this table to choose the recovery model before writing code.
+
+| Flow shape | Default strategy | Notes |
+| --- | --- | --- |
+| Local read + local write + local write | One transaction around the local mutation group | Keep commit-path sequencing explicit. |
+| Local write + local write inside nested helpers | One outer transaction boundary | Helper internals should participate in the outer transaction when the stack supports it. |
+| Local write + auth provider mutation | Compensation or durable repair path | Local rollback does not undo external auth state. |
+| Local write + auth provider + email | Transaction only for local writes, explicit compensation or repair for auth, explicit delivery policy for email | Do not imply a single rollback boundary across systems. |
+| Local write + email / queue / third-party side effect | Explicit commit boundary plus post-commit recovery story | Decide whether the side effect is best-effort, compensatable, or repairable. |
+| Preflight validation over many items | Accumulate validation failures before mutation | Use before the commit path, not during it. |
+| Parallel validation or read-only fan-out | Explicit concurrency plus explicit error aggregation semantics | Be clear about fail-fast vs collect-all behavior. |
+| Commit path orchestration | Sequential by default | Introduce concurrency only when failure semantics stay safe and obvious. |
+
+## Classification Guide
+
+- `preflight`
+  Validation, lookups, and checks that can fail before any durable mutation starts.
+- `transactional-local`
+  Local writes that must commit or roll back together.
+- `retryable transient integration`
+  External call with explicit transient failure handling and safe retry semantics.
+- `compensation-required external`
+  External write that cannot be covered by local rollback.
+- `post-commit follow-up`
+  Side effect that happens after the main durable state transition and therefore needs an explicit repair story if it fails.
+
+## Approval Heuristics
+
+- If all durable mutations are in the same transaction-capable store, use one transaction.
+- If any step mutates external state, write down the compensation or repair story before implementation.
+- If a retry changes business semantics or risks duplicates, do not retry the whole pipeline.
+- If a collection helper hides which steps are concurrent or fail-fast, prefer explicit sequential composition in the commit path.

package/dist/skills/agnostic/backend/backend-recoverable-actions/references/test-matrix.md

@@ -0,0 +1,34 @@
+# Test Matrix
+
+Every multi-step mutating action needs failure-path coverage, not only happy-path coverage.
+
+## Required Scenarios
+
+- later local write fails and earlier local writes are rolled back
+- nested helper usage still preserves the outer transaction boundary
+- external step succeeds and a later local step fails, triggering compensation or leaving a deliberate repairable state
+- transient retryable integration step retries only that step
+- non-retryable integration failure surfaces once as a typed or structured error
+- preflight accumulation returns the intended set of validation failures
+- intentionally parallel validation or read fan-out uses the expected error semantics
+- simple one-step actions are not over-engineered with unnecessary orchestration machinery
+
+## Unit-Level Expectations
+
+- fake leaf services and repositories should make each failure point injectable
+- tests should assert which step ran and which step did not
+- tests should prove the chosen retry, compensation, or transaction story, not just the final error message
+
+## Integration-Level Expectations
+
+- verify rollback behavior with live infrastructure when the flow relies on transactions
+- verify public action or transport behavior exposes expected failures correctly
+- verify recoverable degraded states are observable when compensation is impossible
+
+## Review Checklist
+
+- where is the transaction boundary
+- what external writes escape the local transaction boundary
+- what is the retry scope
+- what is the compensation or repair path
+- which tests prove the story

package/dist/skills/agnostic/docs/docs-maintenance/SKILL.md

@@ -0,0 +1,193 @@
+---
+name: docs-maintenance
+description: Ingest a spec folder into the wiki domain layer by extracting and writing flow pages first, then concept pages, then syncing ingest metadata. Secondary: update docs/ when code changes alter architecture, setup, contracts, or operator workflow. Use when a spec is ready to be captured as domain knowledge after review or implementation, or when a code task changes non-obvious behavior that docs/ should reflect.
+---
+
+# Docs Maintenance
+
+## Contract
+
+- **Role:** higher-order ingest and repo-docs orchestrator
+- **Entrypoint type:** public entrypoint
+- **Upstream:** reviewed or implemented spec folder, or code changes that may require `docs/` updates
+- **Delegates to:** internal flow-writing phase, then internal concept-writing phase
+- **Downstream:** synced wiki indexes, ingest metadata, wiki log, and any required `docs/` updates
+- **Entry conditions:** resolved spec folder for ingest work, or a concrete docs-affecting code change
+- **Stop conditions:** ingest bookkeeping complete, required docs updates complete, failures reported honestly
+
+## Overview
+
+**Primary purpose:** synthesize `<wiki-root>/specs/<domain>/<spec>/SPEC.md` (and optionally `IMPLEMENTATION-NOTES.md`) into the wiki domain knowledge layer. Write flow pages first, then concept pages, then sync ingest bookkeeping.
+
+**Secondary purpose:** keep `docs/` accurate when code changes alter architecture, setup, contracts, decisions, or operator-facing behavior.
+
+Read `<wiki-root>/AGENTS.md` before touching any wiki content.
+
+`<wiki-root>` is repo-shape dependent:
+- monorepo: `apps/wiki`
+- single-repo: `wiki`
+
+---
+
+## Primary: Wiki Ingest Orchestration
+
+### Pipeline
+
+```
+docs-maintenance (orchestrator)
+  └─ 1. flow-writing phase    — writes flows/, updates domain index
+  └─ 2. concept-writing phase — reads flows/ for cross-linking, writes concepts/, updates domain index
+```
+
+**Why this order is required:** concept writing reads existing flow pages to cross-link concepts. Flow pages must exist before concept pages are written.
+
+### Inputs
+
+Accept any of:
+- A spec folder path: `<wiki-root>/specs/<domain>/<spec>/`
+- A domain name + spec name
+- An explicit `SPEC.md` path
+
+Resolve all inputs to a full spec folder path before continuing. If the target is still ambiguous, ask only for the missing folder.
+
+### Step 1: Guard
+
+Check `SPEC.md` frontmatter for `ingested: true`. If set, exit with a clear no-op message.
+
+Verify the spec has `domain:` in frontmatter. Error if absent.
+
+### Step 2: Read the source
+
+Read in order:
+1. `SPEC.md` — mandatory. If missing, stop and report.
+2. `IMPLEMENTATION-NOTES.md` — optional. If present, flows and concepts become `status: implemented`. If absent, status is `proposed`.
+   - Check its frontmatter. If it lacks frontmatter (no YAML block), add it now before continuing:
+     ```yaml
+     ---
+     domain: <domain from SPEC.md>
+     type: implementation-notes
+     spec: <spec id from SPEC.md>
+     links:
+       - "[[specs/<domain>/<spec>/SPEC]]"
+     ingested: false
+     last_ingested: null
+     created: <today>
+     updated: <today>
+     ---
+     ```
+
+Verify `<wiki-root>/domains/<domain>/` exists with a `<domain>.md` index file. If the domain is missing, stop and scaffold the wiki/domain structure first.
+
+### Step 3: Extract flows
+
+A flow exists when the spec describes a **sequence of user or system actions with a defined start, steps, and end outcome**.
+
+Look for flows in:
+- Multi-step acceptance criteria (e.g. "On save, the system runs duplicate detection → blocks if exact match → redirects operator on success")
+- Explicit user journeys or process descriptions in the Context section
+- "When X, then Y" conditional chains across multiple acceptance criteria
+- Any section titled Flow, Process, Journey, or similar
+
+For each flow found:
+- Assign a descriptive `flow_name` (e.g., "Create Patient", "Document Upload", "Duplicate Check")
+- Extract `flow_content`: triggering event, actors involved, ordered steps with decision points, terminal outcome
+- When `IMPLEMENTATION-NOTES.md` is present: note deviations, surprises, or blocked steps inline
+
+If no multi-step sequence is discernible (e.g., a purely data-model spec), record the absence and skip flow delegation.
+
+### Step 4: Write flow pages
+
+Read [references/flow-pages.md](references/flow-pages.md) and apply that contract to every extracted flow.
+
+Wait for all flow pages to complete before proceeding.
+
+If any flow write fails, stop immediately. Do not proceed to concept writing. Report the failure so the run can be resumed cleanly.
+
+### Step 5: Extract concepts
+
+A concept exists when the spec **names a domain entity or term with defined attributes, invariants, or bounded scope**.
+
+Look for concepts in:
+- Fields listed in acceptance criteria (e.g., `first_name`, `email`, `acquisition_channel`, `nin`)
+- Explicit data model or entity sections
+- Nouns that recur across multiple acceptance criteria with their own distinct attributes or rules
+- Enum sets representing a bounded domain state (e.g., `acquisition_channel` values)
+- Entities referenced via `[[wikilinks]]` to other specs or domain pages
+
+**Grouping rule:** collect related fields under one owning entity rather than creating a concept per field. All patient registry fields → one "Patient" concept. All acquisition channel variants → one "Acquisition Channel" concept.
+
+If no distinct domain entity is identifiable, record the absence and skip concept delegation.
+
+### Step 6: Write concept pages
+
+Read [references/concept-pages.md](references/concept-pages.md) and apply that contract to every extracted concept.
+
+Wait for all concept pages to complete.
+
+### Step 7: Mark sources as ingested
+
+Update `SPEC.md` frontmatter:
+```yaml
+ingested: true
+last_ingested: YYYY-MM-DD
+```
+
+If `IMPLEMENTATION-NOTES.md` is present, update its frontmatter:
+```yaml
+ingested: true
+last_ingested: YYYY-MM-DD
+```
+
+Also populate its `links` array with every flow and concept page written in Steps 4 and 6 (in addition to the SPEC link that was set in Step 2). This is the only moment where IMPLEMENTATION-NOTES links are updated — do not leave them pointing only at the SPEC.
+
+### Step 8: Log entry
+
+Append to `<wiki-root>/log.md` (cap at 50 entries; drop oldest when over):
+```md
+## [YYYY-MM-DD] ingest | <spec title>
+- Source: [[specs/<domain>/<spec>/SPEC]]
+- Flows written: <count>
+- Concepts written: <count>
+```
+
+### Step 9: Update wiki index
+
+If new pages were created, update the Concepts and Flows counts in the relevant Domains table row in `<wiki-root>/index.md`.
+
+### Resumability
+
+Output pages are the checkpoints. On re-invocation of the same source:
+
+- Flow pages with `ingested: true` → skip Step 4 for those flows
+- Any expected flow page missing → re-run Step 4 for it before Step 6
+- Concept pages with `ingested: true` → skip Step 6 for those concepts
+
+---
+
+## Secondary: docs/ Maintenance
+
+Update `docs/` when a code task changes **architecture, setup, contracts, decisions, or non-obvious operator-facing behavior**. Do not let docs/ work displace or delay wiki ingest.
+
+1. Read `docs/README.md` and the nearest affected section README before editing.
+2. Prefer editing an existing leaf doc over creating a new one.
+3. When a doc is added, removed, or renamed: update `docs/README.md` and the nearest section README in the same task.
+4. Record repo-wide behavior changes in `docs/architecture/decisions/`.
+
+**Route by owned behavior:**
+- Backend/runtime surface → `docs/reference/domains/backend-effect-sql.md` or `docs/runbooks/`
+- Auth/user-management → `docs/reference/domains/user-management.md`
+- Frontend/app structure → `docs/reference/domains/frontend-application-structure.md`
+- AI workflow/agent infrastructure → `docs/runbooks/subagent-templates.md` or `docs/runbooks/claude-code-hooks.md`
+
+---
+
+## Never Do
+
+- Ingest a spec with `ingested: true` — exit early instead
+- Ingest an `IMPLEMENTATION-NOTES.md` with `ingested: true` — treat it as already reflected in domain pages
+- Proceed to concept writing when a flow write has failed
+- Create `docs/prd`, `docs/dev`, roadmap, sprint, or backlog-mirror folders
+- Document speculative or future-state features as current truth
+- Put agent task instructions inside human-facing docs pages
+- Leave docs orphaned from `docs/README.md` after adding or renaming them
+- Duplicate content between `<wiki-root>/domains/` (the "what") and `docs/reference/domains/` (the "how")

package/dist/skills/agnostic/docs/docs-maintenance/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Docs Maintenance"
+  short_description: "Wiki ingest plus repo docs maintenance"
+  default_prompt: "Use $docs-maintenance to own the wiki ingest pipeline, then keep docs/ human-facing and implementation-grounded when code changes affect durable knowledge."

package/dist/skills/agnostic/docs/docs-maintenance/references/concept-pages.md

@@ -0,0 +1,48 @@
+# Concept Pages
+
+Use this reference during Step 6 of `docs-maintenance`.
+
+## Input expansion
+
+For each extracted concept:
+
+1. Read existing flow pages under `<wiki-root>/domains/<domain>/flows/` for cross-linking.
+2. Scan `<wiki-root>/raw/` recursively and collect files where frontmatter `ingested: false` or `ingested` is absent.
+3. Use relevant raw content only as supplementary material. Do not mark raw files as ingested here.
+
+## Output contract
+
+4. Synthesize concept content in this precedence order:
+   - `IMPLEMENTATION-NOTES.md` deviations, surprises, and judgment calls
+   - `SPEC.md` acceptance criteria, data model, and technical notes
+   - relevant sections from flow pages
+   - relevant raw file content
+5. Determine status:
+   - `proposed` when only `SPEC.md` is present
+   - `implemented` when `IMPLEMENTATION-NOTES.md` is present
+6. Derive the output path:
+   - slugify the concept name to kebab-case
+   - write to `<wiki-root>/domains/<domain>/concepts/<concept-name>.md`
+7. Write or merge the concept page:
+   - preserve established facts
+   - append new information under `## [Source: <origin>]`
+   - flag contradictions inline: `> [!warning] CONTRADICTS [[source]]`
+8. Every concept page must include:
+   - frontmatter:
+     ```yaml
+     ---
+     domain: <domain>
+     type: concept
+     status: proposed | implemented
+     ingested: true
+     last_ingested: YYYY-MM-DD
+     links: []
+     created: YYYY-MM-DD
+     updated: YYYY-MM-DD
+     ---
+     ```
+   - `Definition`
+   - `Attributes` table
+   - `Related flows`
+   - `## [Source: <origin>]`
+9. Update `<wiki-root>/domains/<domain>/<domain>.md` to link the concept page if not already present

package/dist/skills/agnostic/docs/docs-maintenance/references/flow-pages.md

@@ -0,0 +1,41 @@
+# Flow Pages
+
+Use this reference during Step 4 of `docs-maintenance`.
+
+## Output contract
+
+For each extracted flow:
+
+1. Derive the output path:
+   - slugify `flow_name` to kebab-case
+   - write to `<wiki-root>/domains/<domain>/flows/<flow-name>.md`
+2. Determine status:
+   - `proposed` when only `SPEC.md` is present
+   - `implemented` when `IMPLEMENTATION-NOTES.md` is present
+3. Reconcile implementation notes when present:
+   - use `SPEC.md` acceptance criteria as the skeleton
+   - override or annotate steps where `IMPLEMENTATION-NOTES.md` records a deviation, surprise, or judgment call
+   - mark blocked or unmet steps: `⚠ blocked — <reason>`
+4. Write or merge the flow page:
+   - preserve established facts
+   - append new information under `## [Source: <origin>]`
+   - flag contradictions inline: `> [!warning] CONTRADICTS [[source]]`
+5. Every flow page must include:
+   - frontmatter:
+     ```yaml
+     ---
+     domain: <domain>
+     type: flow
+     status: proposed | implemented
+     ingested: true
+     last_ingested: YYYY-MM-DD
+     links:
+       - "[[specs/<domain>/<spec>/SPEC]]"
+       - "[[specs/<domain>/<spec>/IMPLEMENTATION-NOTES]]" # only when notes exist
+     created: YYYY-MM-DD
+     updated: YYYY-MM-DD
+     ---
+     ```
+   - a Mermaid diagram
+   - a numbered step list aligned to the diagram nodes
+6. Update `<wiki-root>/domains/<domain>/<domain>.md` to link the flow page if not already present

package/dist/skills/agnostic/frontend/agent-browser/.clawdhub/origin.json

@@ -0,0 +1,7 @@
+{
+  "version": 1,
+  "registry": "https://clawdhub.com",
+  "slug": "agent-browser",
+  "installedVersion": "0.1.0",
+  "installedAt": 1768436984598
+}