@plainconceptsplatform/agent-harness 3.8.2 → 3.8.3

package/skills/browser-automation/SKILL.md

@@ -1,72 +1,72 @@
----
-name: browser-automation
-description: Reliable, composable browser automation using agent-browser. Use when capturing screenshots of a locally running app, clicking UI elements, reading page content, or automating browser interactions on localhost.
-license: MIT
-compatibility: Requires agent-browser CLI installed (Rust binary) and running.
-metadata:
-  author: copilots
-  version: "2.0"
----
-
-This skill operates on `localhost` URLs only. Screenshots, clicks, typing, scrolling, and reads on locally running apps are in scope. External services (github.com, dev.azure.com, npmjs.com, etc.) are out of scope for browser tools.
-
-The only exception: when the user selects "Others (Browser)" as their backlog platform during onboarding, the `pc-userstory` skill may navigate to work item URLs the user explicitly provides. That is the sole case where external navigation is permitted, and only to URLs the user explicitly gives you.
-
-## Best-practice workflow
-
-1. Open the page: `agent-browser open <url>` (launches its own Chrome; reuses the running daemon)
-2. Take a snapshot: `agent-browser snapshot` to get the accessibility tree with `@ref` handles
-3. Interact by ref: `agent-browser click @e2`, `agent-browser fill @e3 "text"`
-4. Wait when needed: `agent-browser wait --load networkidle` or `agent-browser wait <selector>`
-5. Confirm the result with a fresh `snapshot`, `get text`, or `screenshot`
-
-Refs like `@e2` come from the last snapshot and go stale after page changes: retake the snapshot after navigation or dynamic updates before reusing them. When a click fails because another element covers the target (consent banner, modal), dismiss or interact with the covering element, then take a fresh snapshot before retrying.
-
-## Tool access
-
-- MCP tools (inside OpenCode): `agent_browser_open`, `agent_browser_snapshot`, `agent_browser_click`, `agent_browser_fill`, `agent_browser_type`, `agent_browser_wait_for_selector`, `agent_browser_screenshot`, `agent_browser_eval`, `agent_browser_close` — configured in `opencode.jsonc` with `--tools core`
-- CLI (any agent, any host): every command below works identically via bash
-- Diagnose the install: `agent-browser doctor`
-
-## Selecting elements
-
-- Prefer refs from `snapshot` (`@e1`, `@e2`, ...) over CSS selectors
-- CSS selectors also work: `agent-browser click "#submit"`, `agent-browser fill "#email" "text"`
-- Semantic locators: `agent-browser find role button click --name "Submit"`, `find text "Sign In" click`, `find label "Email" fill "value"`, `find testid <id> click`
-- Native selects: `agent-browser select <sel> <value>`
-
-## Reading state
-
-- `agent-browser get text <sel>` — text content of an element
-- `agent-browser get value <sel>` — input value
-- `agent-browser snapshot` — structured accessibility tree (preferred for parsing)
-- `agent-browser screenshot [path]` — `--full` for full page, `--annotate` for numbered labels
-- `agent-browser read` — agent-readable markdown of the active tab (no Chrome launch for URL reads)
-
-## Tabs and sessions
-
-- `agent-browser tab` lists tabs with stable `t1`, `t2` ids; `tab new --label <name>` and `tab <label>` switch
-- `agent-browser close` closes the browser; `close --all` closes every session
-
-## CLI-first debugging
-
-- `agent-browser doctor` — diagnose install, Chrome, and daemon state
-- `agent-browser console` — view console messages; `agent-browser errors` — uncaught exceptions
-- `agent-browser eval "<js>"` — run JavaScript in the page
-- `agent-browser network requests --filter api` — inspect tracked requests
-
-## Troubleshooting
-
-- Stale ref: take a fresh `snapshot` after any navigation or DOM change
-- Covered click: the error names the covering element; dismiss it, re-snapshot, retry
-- Selector fails: confirm the content exists with `agent-browser get text` or a snapshot before retrying
-- Daemon or Chrome issues: run `agent-browser doctor`
-
-## Scope
-
-- Screenshots of locally running app on `localhost` URLs: in scope
-- Click, type, scroll, read on `localhost` pages: in scope
-- Navigate to work item URLs the user explicitly provides (when backlog platform is "Others (Browser)"): in scope
-- Navigate to external services for non-work-item purposes: out of scope
-- DevOps or GitHub CLI operations via browser tools: out of scope
-- Reading or modifying production systems via browser tools: out of scope
+---
+name: browser-automation
+description: Reliable, composable browser automation using agent-browser. Use when capturing screenshots of a locally running app, clicking UI elements, reading page content, or automating browser interactions on localhost.
+license: MIT
+compatibility: Requires agent-browser CLI installed (Rust binary) and running.
+metadata:
+  author: copilots
+  version: "2.0"
+---
+
+This skill operates on `localhost` URLs only. Screenshots, clicks, typing, scrolling, and reads on locally running apps are in scope. External services (github.com, dev.azure.com, npmjs.com, etc.) are out of scope for browser tools.
+
+The only exception: when the user selects "Others (Browser)" as their backlog platform during onboarding, the `pc-userstory` skill may navigate to work item URLs the user explicitly provides. That is the sole case where external navigation is permitted, and only to URLs the user explicitly gives you.
+
+## Best-practice workflow
+
+1. Open the page: `agent-browser open <url>` (launches its own Chrome; reuses the running daemon)
+2. Take a snapshot: `agent-browser snapshot` to get the accessibility tree with `@ref` handles
+3. Interact by ref: `agent-browser click @e2`, `agent-browser fill @e3 "text"`
+4. Wait when needed: `agent-browser wait --load networkidle` or `agent-browser wait <selector>`
+5. Confirm the result with a fresh `snapshot`, `get text`, or `screenshot`
+
+Refs like `@e2` come from the last snapshot and go stale after page changes: retake the snapshot after navigation or dynamic updates before reusing them. When a click fails because another element covers the target (consent banner, modal), dismiss or interact with the covering element, then take a fresh snapshot before retrying.
+
+## Tool access
+
+- MCP tools (inside OpenCode): `agent_browser_open`, `agent_browser_snapshot`, `agent_browser_click`, `agent_browser_fill`, `agent_browser_type`, `agent_browser_wait_for_selector`, `agent_browser_screenshot`, `agent_browser_eval`, `agent_browser_close` — configured in `opencode.jsonc` with `--tools core`
+- CLI (any agent, any host): every command below works identically via bash
+- Diagnose the install: `agent-browser doctor`
+
+## Selecting elements
+
+- Prefer refs from `snapshot` (`@e1`, `@e2`, ...) over CSS selectors
+- CSS selectors also work: `agent-browser click "#submit"`, `agent-browser fill "#email" "text"`
+- Semantic locators: `agent-browser find role button click --name "Submit"`, `find text "Sign In" click`, `find label "Email" fill "value"`, `find testid <id> click`
+- Native selects: `agent-browser select <sel> <value>`
+
+## Reading state
+
+- `agent-browser get text <sel>` — text content of an element
+- `agent-browser get value <sel>` — input value
+- `agent-browser snapshot` — structured accessibility tree (preferred for parsing)
+- `agent-browser screenshot [path]` — `--full` for full page, `--annotate` for numbered labels
+- `agent-browser read` — agent-readable markdown of the active tab (no Chrome launch for URL reads)
+
+## Tabs and sessions
+
+- `agent-browser tab` lists tabs with stable `t1`, `t2` ids; `tab new --label <name>` and `tab <label>` switch
+- `agent-browser close` closes the browser; `close --all` closes every session
+
+## CLI-first debugging
+
+- `agent-browser doctor` — diagnose install, Chrome, and daemon state
+- `agent-browser console` — view console messages; `agent-browser errors` — uncaught exceptions
+- `agent-browser eval "<js>"` — run JavaScript in the page
+- `agent-browser network requests --filter api` — inspect tracked requests
+
+## Troubleshooting
+
+- Stale ref: take a fresh `snapshot` after any navigation or DOM change
+- Covered click: the error names the covering element; dismiss it, re-snapshot, retry
+- Selector fails: confirm the content exists with `agent-browser get text` or a snapshot before retrying
+- Daemon or Chrome issues: run `agent-browser doctor`
+
+## Scope
+
+- Screenshots of locally running app on `localhost` URLs: in scope
+- Click, type, scroll, read on `localhost` pages: in scope
+- Navigate to work item URLs the user explicitly provides (when backlog platform is "Others (Browser)"): in scope
+- Navigate to external services for non-work-item purposes: out of scope
+- DevOps or GitHub CLI operations via browser tools: out of scope
+- Reading or modifying production systems via browser tools: out of scope

package/skills/pc-guardrails-generic/SKILL.md

@@ -1,53 +1,53 @@
----
-name: pc-guardrails-generic
-description: Generic guardrails, foundational rules that all agents follow. Users add specialized guardrails skills for specific concerns. Covers secrets, code quality, security, tool usage, and engineer workflow.
-license: MIT
----
-
-## Transitive loads (optimization skills)
-
-The marker sections below name the optimization skills this project selected. Load each before doing any work.
-
-## Secrets
-
-- Treat `.env` files as write-only: write to them when configuring, read credentials at runtime from the environment or secret store.
-- Never put a credential, API key, or token in a log line, output, or commit in anything but encrypted or template form.
-
-## Code
-
-- Zero comments by default. Write one only for what the code cannot show and we do not control: a vendor bug, an external contract, a legal rule. Leave every file you touch with no comment slop, old or new.
-- Never add a file that collects unrelated things — `constants.js`, `types.ts`, `utils.ts`. One responsibility per file, split by domain. A file importing from many unrelated modules is already the symptom.
-
-## Temporary files
-
-- Never write outside `$REPO_ROOT` or an OS temp directory: the next agent cannot see it and nobody cleans it up. Scratch goes under `$REPO_ROOT/.opencode/.tmp/` (enforced by pc-system-reminders).
-- Never report a `.tmp/` path as a deliverable. Copy or move the artifact to its repository path first. Never leave scratch files behind unless they are evidence for a failure you are reporting.
-
-## Tests
-
-- Never write more tests than the change requires. A bug fix gets one regression test. A new function gets tests for its public contract, not every internal branch. Never aim for a coverage number.
-- Never test framework or library internals. Test your code's contract, not that EF Core saves a tracked entity.
-- Never generate integration, e2e, or snapshot tests unless explicitly asked. Mock nothing you do not own — use a fake that records state. Never add a test that duplicates a type-check or linter rule.
-- `node .opencode/scripts/check-diff.mjs` enforces the comment and test rules on the diff and must exit 0.
-
-<!-- PC-GUARDRAILS-RTK-START -->
-<!-- PC-GUARDRAILS-RTK-END -->
-
-<!-- PC-GUARDRAILS-CODEGRAPH-START -->
-<!-- PC-GUARDRAILS-CODEGRAPH-END -->
-
-<!-- PC-GUARDRAILS-MEMORY-START -->
-<!-- PC-GUARDRAILS-MEMORY-END -->
-
-<!-- PC-GUARDRAILS-SIMPLE-ENGLISH-START -->
-<!-- PC-GUARDRAILS-SIMPLE-ENGLISH-END -->
-
-<!-- PC-GUARDRAILS-HUMANIZER-START -->
-<!-- PC-GUARDRAILS-HUMANIZER-END -->
-
-## Engineer workflow (when spawned)
-
-The lead puts your task IDs and their text in your prompt. Two things about that are not up to you:
-
-- Load every skill under your `## Abilities` before you start, guardrails first, one `skill` call per `@skill-name`. Editing, shell and spawning are blocked until you have (pc-system-reminders).
-- Edit only files in your assigned scope, then return: task IDs done, files changed, tests and lint result, decisions made. Then exit. Never poll for more work or claim a task the lead did not give you.
+---
+name: pc-guardrails-generic
+description: Generic guardrails, foundational rules that all agents follow. Users add specialized guardrails skills for specific concerns. Covers secrets, code quality, security, tool usage, and engineer workflow.
+license: MIT
+---
+
+## Transitive loads (optimization skills)
+
+The marker sections below name the optimization skills this project selected. Load each before doing any work.
+
+## Secrets
+
+- Treat `.env` files as write-only: write to them when configuring, read credentials at runtime from the environment or secret store.
+- Never put a credential, API key, or token in a log line, output, or commit in anything but encrypted or template form.
+
+## Code
+
+- Zero comments by default. Write one only for what the code cannot show and we do not control: a vendor bug, an external contract, a legal rule. Leave every file you touch with no comment slop, old or new.
+- Never add a file that collects unrelated things — `constants.js`, `types.ts`, `utils.ts`. One responsibility per file, split by domain. A file importing from many unrelated modules is already the symptom.
+
+## Temporary files
+
+- Never write outside `$REPO_ROOT` or an OS temp directory: the next agent cannot see it and nobody cleans it up. Scratch goes under `$REPO_ROOT/.opencode/.tmp/` (enforced by pc-system-reminders).
+- Never report a `.tmp/` path as a deliverable. Copy or move the artifact to its repository path first. Never leave scratch files behind unless they are evidence for a failure you are reporting.
+
+## Tests
+
+- Never write more tests than the change requires. A bug fix gets one regression test. A new function gets tests for its public contract, not every internal branch. Never aim for a coverage number.
+- Never test framework or library internals. Test your code's contract, not that EF Core saves a tracked entity.
+- Never generate integration, e2e, or snapshot tests unless explicitly asked. Mock nothing you do not own — use a fake that records state. Never add a test that duplicates a type-check or linter rule.
+- `node .opencode/scripts/check-diff.mjs` enforces the comment and test rules on the diff and must exit 0.
+
+<!-- PC-GUARDRAILS-RTK-START -->
+<!-- PC-GUARDRAILS-RTK-END -->
+
+<!-- PC-GUARDRAILS-CODEGRAPH-START -->
+<!-- PC-GUARDRAILS-CODEGRAPH-END -->
+
+<!-- PC-GUARDRAILS-MEMORY-START -->
+<!-- PC-GUARDRAILS-MEMORY-END -->
+
+<!-- PC-GUARDRAILS-SIMPLE-ENGLISH-START -->
+<!-- PC-GUARDRAILS-SIMPLE-ENGLISH-END -->
+
+<!-- PC-GUARDRAILS-HUMANIZER-START -->
+<!-- PC-GUARDRAILS-HUMANIZER-END -->
+
+## Engineer workflow (when spawned)
+
+The lead puts your task IDs and their text in your prompt. Two things about that are not up to you:
+
+- Load every skill under your `## Abilities` before you start, guardrails first, one `skill` call per `@skill-name`. Editing, shell and spawning are blocked until you have (pc-system-reminders).
+- Edit only files in your assigned scope, then return: task IDs done, files changed, tests and lint result, decisions made. Then exit. Never poll for more work or claim a task the lead did not give you.

package/skills/pc-guardrails-project/SKILL.md

@@ -1,8 +1,8 @@
----
-name: pc-guardrails-project
-description: Project-specific guardrails extracted from ARCHITECTURE.md and project config files. Populated by /make-guardrails. Load this skill before implementing any change to understand boundaries, conventions, and constraints for this codebase.
-license: MIT
----
-
-<!-- This skill is a placeholder until /make-guardrails is run. -->
-<!-- /make-guardrails will populate this file with project-specific rules. -->
+---
+name: pc-guardrails-project
+description: Project-specific guardrails extracted from ARCHITECTURE.md and project config files. Populated by /make-guardrails. Load this skill before implementing any change to understand boundaries, conventions, and constraints for this codebase.
+license: MIT
+---
+
+<!-- This skill is a placeholder until /make-guardrails is run. -->
+<!-- /make-guardrails will populate this file with project-specific rules. -->

package/skills/pc-make-architecture/SKILL.md

@@ -1,33 +1,33 @@
----
-name: pc-make-architecture
-description: Generate or update ARCHITECTURE.md by analyzing the codebase structure. Safe to run at any time. Invoked by the /make-architecture command and the repo-initialize flow.
-license: MIT
----
-
-# Make Architecture
-
-Write `ARCHITECTURE.md` in the project root from what the codebase actually contains, following the [structure template](structure-template.md).
-
-## Rules
-
-- Never regenerate over a file that carries a `<!-- Last updated:` footer. That footer is what makes the next run incremental, and a full rewrite silently drops whatever a human added by hand. Read the file first and pick the mode.
-- Never analyze outside `.opencode/source-roots.json` when it exists, plus this repo's own docs and config.
-- When `.platform/contract.yml` lists paths under `reuse.docs` (`docs/platform/`, for example), the template named in its `source` owns the code those pages document. For those topics link to the page instead of describing them again: a second description drifts on the next template update.
-- The footer is the file's last line, and it is the run's own ISO timestamp: `<!-- Last updated: <ISO date> -->`.
-- Follow the writing rules and self-check defined in the [structure template](structure-template.md). After generating, re-read each section: if a section only describes what exists without stating what breaks when its constraints are violated, rewrite it as constraint-embedded prose or cut it. The file is not written until the self-check passes.
-
-## Modes
-
-| The existing file | Mode |
-|---|---|
-| Missing, or a placeholder with no real content | Generate |
-| Has content and a `<!-- Last updated:` footer | Update |
-| Has content but no footer | Warn the user, then Generate |
-
-**Generate.** Discover the architecture with the file tools: `glob` for structure, `grep` for routes, models and schemas, `read` for config, CI workflows, Dockerfiles, README, changelogs and ADRs.
-
-**Update.** `git log --oneline --since="<footer date>" -- <source roots>` says what moved. Nothing changed means nothing to write: say "Architecture unchanged since last update" and stop. Otherwise rewrite only the affected sections and leave the rest, including anything hand-written, as it stands. Past roughly 40% of sections affected, fall back to Generate.
-
-## Report
-
-Whether the file was generated or updated and which sections changed, the top-level components found, and that `/make-architecture` can be re-run whenever the architecture moves.
+---
+name: pc-make-architecture
+description: Generate or update ARCHITECTURE.md by analyzing the codebase structure. Safe to run at any time. Invoked by the /make-architecture command and the repo-initialize flow.
+license: MIT
+---
+
+# Make Architecture
+
+Write `ARCHITECTURE.md` in the project root from what the codebase actually contains, following the [structure template](structure-template.md).
+
+## Rules
+
+- Never regenerate over a file that carries a `<!-- Last updated:` footer. That footer is what makes the next run incremental, and a full rewrite silently drops whatever a human added by hand. Read the file first and pick the mode.
+- Never analyze outside `.opencode/source-roots.json` when it exists, plus this repo's own docs and config.
+- When `.platform/contract.yml` lists paths under `reuse.docs` (`docs/platform/`, for example), the template named in its `source` owns the code those pages document. For those topics link to the page instead of describing them again: a second description drifts on the next template update.
+- The footer is the file's last line, and it is the run's own ISO timestamp: `<!-- Last updated: <ISO date> -->`.
+- Follow the writing rules and self-check defined in the [structure template](structure-template.md). After generating, re-read each section: if a section only describes what exists without stating what breaks when its constraints are violated, rewrite it as constraint-embedded prose or cut it. The file is not written until the self-check passes.
+
+## Modes
+
+| The existing file | Mode |
+|---|---|
+| Missing, or a placeholder with no real content | Generate |
+| Has content and a `<!-- Last updated:` footer | Update |
+| Has content but no footer | Warn the user, then Generate |
+
+**Generate.** Discover the architecture with the file tools: `glob` for structure, `grep` for routes, models and schemas, `read` for config, CI workflows, Dockerfiles, README, changelogs and ADRs.
+
+**Update.** `git log --oneline --since="<footer date>" -- <source roots>` says what moved. Nothing changed means nothing to write: say "Architecture unchanged since last update" and stop. Otherwise rewrite only the affected sections and leave the rest, including anything hand-written, as it stands. Past roughly 40% of sections affected, fall back to Generate.
+
+## Report
+
+Whether the file was generated or updated and which sections changed, the top-level components found, and that `/make-architecture` can be re-run whenever the architecture moves.

package/skills/pc-make-architecture/structure-template.md

@@ -1,64 +1,64 @@
-# ARCHITECTURE.md structure template
-
-Write (or update) `ARCHITECTURE.md` following this structure. Only include sections relevant to the project; omit sections with no evidence.
-
-- Architecture Overview: what the system is, what problem it solves, major architectural style
-- 1. Project Structure: annotated directory tree with purpose of each major directory
-- 2. High-Level System Diagram: Mermaid diagram of actors, services, data stores, external systems
-- 3. Core Components: each major component: name, responsibility, key files, technologies, inputs/outputs
-  - 3.1 Frontend / User Interface (if present)
-  - 3.2 Backend / Server / API (if present)
-  - 3.3 Shared Libraries / Common Code (if present)
-  - 3.4 CLI / Scripts / Automation (if present)
-- 4. Data Flow: request lifecycle, key user journeys, sequence diagram for main runtime flow
-- 5. Data Stores: all persistent storage: type, purpose, schemas, migration approach
-- 6. External Integrations / APIs: each integration: method, config location, auth, failure behavior
-- 7. Key Technologies: full stack summary with architectural relevance of each
-- 8. Deployment & Infrastructure: build artifacts, env config, containerization, CI/CD, hosting
-- 9. Security Architecture: auth, authz, secrets, input validation, trust boundaries
-- 10. Monitoring & Observability: logging, metrics, tracing, error reporting
-- 11. Performance & Scalability: caching, batching, concurrency, known bottlenecks
-- 12. Development Workflow: local setup, install/dev/test/build/lint commands
-- 13. Testing Strategy: test frameworks, locations, coverage gates, gaps
-- 14. Architectural Decisions & Rationale: key choices with evidence and tradeoffs
-- 15. Constraints, Risks, and Technical Debt: tight coupling, TODOs, operational risks
-- 16. Future Considerations: documented roadmap + reasonable recommendations (labeled as such)
-- 17. Project Identification: name, language, type, runtime, date of review, maintainer
-- 18. Glossary / Acronyms: project-specific terms an agent or new developer needs to know
-
-Append at the very end of the file:
-```
-<!-- Last updated: <current ISO timestamp> -->
-```
-
-Rules:
-- Be specific and concrete: include actual directories, files, modules, commands.
-- Mark anything undiscoverable as "Not evident from the repository".
-- Use Mermaid diagrams where helpful.
-- Write as if this document will be committed and maintained over time.
-
-## Writing rules
-
-These rules govern the voice and shape of every section. The ARCHITECTURE.md is the primary artifact an agent reads to understand the system's invariants — it must teach constraints, not just inventory structure. These are enforced by re-reading each section after generation (see the self-check in the skill).
-
-1. **Every section must answer "what breaks if this is violated," not just "what exists."** A section that only describes structure without stating the constraint it protects and the consequence of crossing it is reference material, not architecture. "The system has four modules" is structure; "Modules must not cross-reference each other in Domain or Application, and flow goes through port interfaces or domain events" is a constraint.
-
-2. **Architectural decisions must carry their rationale and what they superseded.** A decision table row that says "Adopt X" is a fact; "Adopt X because Y, supersedes decision Z which assumed W" is a constraint that teaches an agent why a change would be wrong. If a decision was reached after rejecting an alternative, name the alternative and why it was rejected.
-
-3. **State boundaries as prohibitions with consequences.** "Layering is enforced: Api → Application → Domain" is a constraint. "Api → Application → Domain" alone is a dependency list. "Only the Composition namespace in Api reaches Infrastructure" is a constraint; "Api depends on Infrastructure" is a fact. Prefer the constraint form: name the boundary, state who must not cross it, and what breaks when it is crossed.
-
-4. **Include what was tried and rejected, not just what was chosen.** The most valuable architecture decisions are the ones where an alternative was tested and found wanting. A section that says "dynamic sessions were rejected because they accept no volumes, cost more at scale, and are blocked by policy" teaches an agent more than "the engine runs as a container app."
-
-5. **Narrative over inventory.** Describe how the system behaves, what holds it together, and where the seams are. A reader who understands the constraints can infer the structure; a reader who only sees the structure cannot infer the constraints.
-
-## Self-check (before writing the file)
-
-Re-read every section you are about to write. Then:
-
-1. **Identify inventory-only sections.** If a section describes what exists without stating what breaks when its constraints are violated, rewrite it as constraint-embedded prose or cut it.
-
-2. **Check decision rows.** Every row in the decisions table must carry its rationale. If a decision has no "why," it is a fact, not a decision — cut it or find the rationale.
-
-3. **Scan for bare dependency lists.** "Api depends on Application depends on Domain" is a fact. Rewrite it as: name the boundary, state who must not cross it, and what breaks when it is crossed.
-
-4. **Verify rejected alternatives are present where they matter.** If a significant architectural choice was made, the rejected alternative and the reason for rejection should be in the document. An agent that does not know what was rejected will propose it again.
+# ARCHITECTURE.md structure template
+
+Write (or update) `ARCHITECTURE.md` following this structure. Only include sections relevant to the project; omit sections with no evidence.
+
+- Architecture Overview: what the system is, what problem it solves, major architectural style
+- 1. Project Structure: annotated directory tree with purpose of each major directory
+- 2. High-Level System Diagram: Mermaid diagram of actors, services, data stores, external systems
+- 3. Core Components: each major component: name, responsibility, key files, technologies, inputs/outputs
+  - 3.1 Frontend / User Interface (if present)
+  - 3.2 Backend / Server / API (if present)
+  - 3.3 Shared Libraries / Common Code (if present)
+  - 3.4 CLI / Scripts / Automation (if present)
+- 4. Data Flow: request lifecycle, key user journeys, sequence diagram for main runtime flow
+- 5. Data Stores: all persistent storage: type, purpose, schemas, migration approach
+- 6. External Integrations / APIs: each integration: method, config location, auth, failure behavior
+- 7. Key Technologies: full stack summary with architectural relevance of each
+- 8. Deployment & Infrastructure: build artifacts, env config, containerization, CI/CD, hosting
+- 9. Security Architecture: auth, authz, secrets, input validation, trust boundaries
+- 10. Monitoring & Observability: logging, metrics, tracing, error reporting
+- 11. Performance & Scalability: caching, batching, concurrency, known bottlenecks
+- 12. Development Workflow: local setup, install/dev/test/build/lint commands
+- 13. Testing Strategy: test frameworks, locations, coverage gates, gaps
+- 14. Architectural Decisions & Rationale: key choices with evidence and tradeoffs
+- 15. Constraints, Risks, and Technical Debt: tight coupling, TODOs, operational risks
+- 16. Future Considerations: documented roadmap + reasonable recommendations (labeled as such)
+- 17. Project Identification: name, language, type, runtime, date of review, maintainer
+- 18. Glossary / Acronyms: project-specific terms an agent or new developer needs to know
+
+Append at the very end of the file:
+```
+<!-- Last updated: <current ISO timestamp> -->
+```
+
+Rules:
+- Be specific and concrete: include actual directories, files, modules, commands.
+- Mark anything undiscoverable as "Not evident from the repository".
+- Use Mermaid diagrams where helpful.
+- Write as if this document will be committed and maintained over time.
+
+## Writing rules
+
+These rules govern the voice and shape of every section. The ARCHITECTURE.md is the primary artifact an agent reads to understand the system's invariants — it must teach constraints, not just inventory structure. These are enforced by re-reading each section after generation (see the self-check in the skill).
+
+1. **Every section must answer "what breaks if this is violated," not just "what exists."** A section that only describes structure without stating the constraint it protects and the consequence of crossing it is reference material, not architecture. "The system has four modules" is structure; "Modules must not cross-reference each other in Domain or Application, and flow goes through port interfaces or domain events" is a constraint.
+
+2. **Architectural decisions must carry their rationale and what they superseded.** A decision table row that says "Adopt X" is a fact; "Adopt X because Y, supersedes decision Z which assumed W" is a constraint that teaches an agent why a change would be wrong. If a decision was reached after rejecting an alternative, name the alternative and why it was rejected.
+
+3. **State boundaries as prohibitions with consequences.** "Layering is enforced: Api → Application → Domain" is a constraint. "Api → Application → Domain" alone is a dependency list. "Only the Composition namespace in Api reaches Infrastructure" is a constraint; "Api depends on Infrastructure" is a fact. Prefer the constraint form: name the boundary, state who must not cross it, and what breaks when it is crossed.
+
+4. **Include what was tried and rejected, not just what was chosen.** The most valuable architecture decisions are the ones where an alternative was tested and found wanting. A section that says "dynamic sessions were rejected because they accept no volumes, cost more at scale, and are blocked by policy" teaches an agent more than "the engine runs as a container app."
+
+5. **Narrative over inventory.** Describe how the system behaves, what holds it together, and where the seams are. A reader who understands the constraints can infer the structure; a reader who only sees the structure cannot infer the constraints.
+
+## Self-check (before writing the file)
+
+Re-read every section you are about to write. Then:
+
+1. **Identify inventory-only sections.** If a section describes what exists without stating what breaks when its constraints are violated, rewrite it as constraint-embedded prose or cut it.
+
+2. **Check decision rows.** Every row in the decisions table must carry its rationale. If a decision has no "why," it is a fact, not a decision — cut it or find the rationale.
+
+3. **Scan for bare dependency lists.** "Api depends on Application depends on Domain" is a fact. Rewrite it as: name the boundary, state who must not cross it, and what breaks when it is crossed.
+
+4. **Verify rejected alternatives are present where they matter.** If a significant architectural choice was made, the rejected alternative and the reason for rejection should be in the document. An agent that does not know what was rejected will propose it again.

package/skills/pc-make-design/SKILL.md

@@ -1,45 +1,45 @@
----
-name: pc-make-design
-description: Generate or update DESIGN.md by analyzing the codebase design system (Tailwind, CSS vars, tokens, UI framework config). Safe to run at any time. Invoked by the /make-design command and the repo-initialize flow.
-license: MIT
----
-
-# Make Design
-
-Write `DESIGN.md` in the project root from the design system the codebase actually uses.
-
-The format is Google's design.md spec:
-
-- Overview: https://stitch.withgoogle.com/docs/design-md/overview/
-- Format: https://stitch.withgoogle.com/docs/design-md/format/
-- Spec and examples: https://github.com/google-labs-code/design.md
-
-## Rules
-
-- Never regenerate over a file that carries a `<!-- Last updated:` footer. That footer is what makes the next run incremental, and a full rewrite silently drops whatever a human added by hand. Read the file first and pick the mode.
-- Never reference a file, variable or path from the codebase. `DESIGN.md` is handed to tools that cannot see this repository, so it has to stand alone.
-- Never analyze outside `.opencode/source-roots.json` when it exists.
-
-## Contract
-
-YAML frontmatter holding every structured token (colours, typography, spacing, elevation, motion, radii, shadows), valid as YAML design tokens. Then free-form Markdown for the look and feel, which is where intent that token values cannot carry belongs. The last line is the run's own ISO timestamp:
-
-```
-<!-- Last updated: <ISO date> -->
-```
-
-## Modes
-
-| The existing file | Mode |
-|---|---|
-| Missing, or a placeholder with no real content | Generate |
-| Has content and a `<!-- Last updated:` footer | Update |
-| Has content but no footer | Warn the user, then Generate |
-
-**Generate.** `glob` for CSS, Tailwind and PostCSS config, component files, token definitions (JS, TS, JSON, YAML), theme files, and UI framework config (shadcn, MUI, Chakra).
-
-**Update.** `git log --oneline --since="<footer date>" -- <source roots>` says what moved. Nothing changed means nothing to write: say "Design system unchanged since last update" and stop. Otherwise update only the affected tokens and sections. A replaced token system is a Generate.
-
-## Report
-
-Whether the file was generated or updated and which tokens changed, the palette, fonts and spacing scale found, and that `/make-design` can be re-run whenever the design system moves.
+---
+name: pc-make-design
+description: Generate or update DESIGN.md by analyzing the codebase design system (Tailwind, CSS vars, tokens, UI framework config). Safe to run at any time. Invoked by the /make-design command and the repo-initialize flow.
+license: MIT
+---
+
+# Make Design
+
+Write `DESIGN.md` in the project root from the design system the codebase actually uses.
+
+The format is Google's design.md spec:
+
+- Overview: https://stitch.withgoogle.com/docs/design-md/overview/
+- Format: https://stitch.withgoogle.com/docs/design-md/format/
+- Spec and examples: https://github.com/google-labs-code/design.md
+
+## Rules
+
+- Never regenerate over a file that carries a `<!-- Last updated:` footer. That footer is what makes the next run incremental, and a full rewrite silently drops whatever a human added by hand. Read the file first and pick the mode.
+- Never reference a file, variable or path from the codebase. `DESIGN.md` is handed to tools that cannot see this repository, so it has to stand alone.
+- Never analyze outside `.opencode/source-roots.json` when it exists.
+
+## Contract
+
+YAML frontmatter holding every structured token (colours, typography, spacing, elevation, motion, radii, shadows), valid as YAML design tokens. Then free-form Markdown for the look and feel, which is where intent that token values cannot carry belongs. The last line is the run's own ISO timestamp:
+
+```
+<!-- Last updated: <ISO date> -->
+```
+
+## Modes
+
+| The existing file | Mode |
+|---|---|
+| Missing, or a placeholder with no real content | Generate |
+| Has content and a `<!-- Last updated:` footer | Update |
+| Has content but no footer | Warn the user, then Generate |
+
+**Generate.** `glob` for CSS, Tailwind and PostCSS config, component files, token definitions (JS, TS, JSON, YAML), theme files, and UI framework config (shadcn, MUI, Chakra).
+
+**Update.** `git log --oneline --since="<footer date>" -- <source roots>` says what moved. Nothing changed means nothing to write: say "Design system unchanged since last update" and stop. Otherwise update only the affected tokens and sections. A replaced token system is a Generate.
+
+## Report
+
+Whether the file was generated or updated and which tokens changed, the palette, fonts and spacing scale found, and that `/make-design` can be re-run whenever the design system moves.