@plainconceptsplatform/agent-harness 3.4.1 → 3.6.0

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

@@ -1,59 +1,59 @@
----
-name: pc-make-engineer
-description: Create a custom engineer agent via persona-driven interactive design. Invoked by the /make-engineer command.
-license: MIT
----
-
-Create one file, `.opencode/agents/{persona}-engineer.md`, from the [template](template.md). The research behind it is for choosing the right skills, not for filling the file: expertise notes, architecture, conventions, file maps and workflow steps belong in skills.
-
-## Rules
-
-- Never write the agent file before the user has confirmed the skill set and it is installed. An engineer whose abilities do not exist cannot work.
-- Never write `model:` or `color:`. `pc-subagent-tiers` injects both at startup, so a hand-picked colour is overwritten.
-- Never create `*.build.md`, `*.fast.md`, `*.plan.md`, `build.md` or `plan.md`. The plugin regenerates all of them every startup and anything written there is lost.
-- `mode: subagent`. Engineers are reached through the subagent tool, and a primary would clutter the two-entry list a human picks from.
-- The only `##` heading is `## Abilities`, and the identity paragraph is two or three sentences carrying no project knowledge.
-- Every `@skill` under `## Abilities` exists in `.agents/skills/` and in `skills-lock.json`. A name that is not installed is skipped rather than blocking the worker, so a typo costs the agent that ability in silence.
-- Project-local installs only: `npx skills add -y ...`, never `-g`.
-- At most five form questions, and only where more than one option was detected. A signal with one option is used without asking.
-
-## Contracts
-
-Personas: `frontend`, `layout`, `backend`, `data`, `devops`, `security`, `mobile`, `api`, `qa`. A persona passed as an argument (`/make-engineer frontend`) or typed by the user is taken as given.
-
-Signals to detect: language, framework, data layer, testing, styling, architecture, i18n, CI/CD, cloud and IaC, monitoring, linting, dependency injection.
-
-Discovery needs `find-skills`, and has no fallback without it:
-
-```bash
-npx skills add -y vercel-labs/skills@find-skills
-```
-
-When `.opencode/agents/{persona}-engineer.md` already exists, ask before touching it:
-
-```json
-{
-  "questions": [
-    {
-      "header": "Overwrite engineer",
-      "question": "An engineer named \"{persona}-engineer\" already exists. Overwrite or cancel?",
-      "options": [
-        { "label": "Overwrite", "description": "Rewrite the file from the template." },
-        { "label": "Cancel", "description": "Stop. Do not modify the existing file." }
-      ]
-    }
-  ]
-}
-```
-
-`fullstack-engineer.md` is the body `pc-subagent-tiers` copies into `build.md` and `plan.md`, so every skill listed there reaches both primaries. Merge into it additively: add only skills it does not already list, put them in the category lines that already exist where they fit, and leave its frontmatter, identity paragraph and existing ability lines alone.
-
-## Flow
-
-1. **Persona.** Ask with the `question` tool unless it arrived as an argument. The answer decides what to detect, what to ask, and which skills to look for.
-2. **Signals.** Read `.opencode/source-roots.json` (if it is missing or empty, ask which directories to scan), then `ARCHITECTURE.md`, `DESIGN.md`, and the manifests (`package.json`, `tsconfig.json`, `*.csproj`, `pyproject.toml`, `go.mod`, `Cargo.toml`). Detect what the persona needs and report the inventory.
-3. **Form.** Present the detected options with the `question` tool, pre-selected and marked `(Recommended)`. For `frontend`, `backend`, `layout` and `api`, one question is architecture and patterns, whose options come from the [signal mapping](signal-mapping.md) tables.
-4. **Skills.** A signal already covered by a skill in `.agents/skills/` or `skills-lock.json` needs no search. Map each remaining signal to a query through the [signal mapping](signal-mapping.md), present the candidates as one multi-select `question` grouped by category (name, one line, `owner/repo`, install count), install what the user confirms, and verify each one landed in both `.agents/skills/` and the lockfile.
-5. **Write** the file from the [template](template.md).
-6. **Merge** the new skills into `fullstack-engineer.md`.
-7. **Report** the file created, the skills installed, the signals with no quality skill, whatever failed, and that opencode has to restart before `pc-subagent-tiers` picks the engineer up.
+---
+name: pc-make-engineer
+description: Create a custom engineer agent via persona-driven interactive design. Invoked by the /make-engineer command.
+license: MIT
+---
+
+Create one file, `.opencode/agents/{persona}-engineer.md`, from the [template](template.md). The research behind it is for choosing the right skills, not for filling the file: expertise notes, architecture, conventions, file maps and workflow steps belong in skills.
+
+## Rules
+
+- Never write the agent file before the user has confirmed the skill set and it is installed. An engineer whose abilities do not exist cannot work.
+- Never write `model:` or `color:`. `pc-subagent-tiers` injects both at startup, so a hand-picked colour is overwritten.
+- Never create `*.build.md`, `*.fast.md`, `*.plan.md`, `build.md` or `plan.md`. The plugin regenerates all of them every startup and anything written there is lost.
+- `mode: subagent`. Engineers are reached through the subagent tool, and a primary would clutter the two-entry list a human picks from.
+- The only `##` heading is `## Abilities`, and the identity paragraph is two or three sentences carrying no project knowledge.
+- Every `@skill` under `## Abilities` exists in `.agents/skills/` and in `skills-lock.json`. A name that is not installed is skipped rather than blocking the worker, so a typo costs the agent that ability in silence.
+- Project-local installs only: `npx skills add -y ...`, never `-g`.
+- At most five form questions, and only where more than one option was detected. A signal with one option is used without asking.
+
+## Contracts
+
+Personas: `frontend`, `layout`, `backend`, `data`, `devops`, `security`, `mobile`, `api`, `qa`. A persona passed as an argument (`/make-engineer frontend`) or typed by the user is taken as given.
+
+Signals to detect: language, framework, data layer, testing, styling, architecture, i18n, CI/CD, cloud and IaC, monitoring, linting, dependency injection.
+
+Discovery needs `find-skills`, and has no fallback without it:
+
+```bash
+npx skills add -y vercel-labs/skills@find-skills
+```
+
+When `.opencode/agents/{persona}-engineer.md` already exists, ask before touching it:
+
+```json
+{
+  "questions": [
+    {
+      "header": "Overwrite engineer",
+      "question": "An engineer named \"{persona}-engineer\" already exists. Overwrite or cancel?",
+      "options": [
+        { "label": "Overwrite", "description": "Rewrite the file from the template." },
+        { "label": "Cancel", "description": "Stop. Do not modify the existing file." }
+      ]
+    }
+  ]
+}
+```
+
+`fullstack-engineer.md` is the body `pc-subagent-tiers` copies into `build.md` and `plan.md`, so every skill listed there reaches both primaries. Merge into it additively: add only skills it does not already list, put them in the category lines that already exist where they fit, and leave its frontmatter, identity paragraph and existing ability lines alone.
+
+## Flow
+
+1. **Persona.** Ask with the `question` tool unless it arrived as an argument. The answer decides what to detect, what to ask, and which skills to look for.
+2. **Signals.** Read `.opencode/source-roots.json` (if it is missing or empty, ask which directories to scan), then `ARCHITECTURE.md`, `DESIGN.md`, and the manifests (`package.json`, `tsconfig.json`, `*.csproj`, `pyproject.toml`, `go.mod`, `Cargo.toml`). Detect what the persona needs and report the inventory.
+3. **Form.** Present the detected options with the `question` tool, pre-selected and marked `(Recommended)`. For `frontend`, `backend`, `layout` and `api`, one question is architecture and patterns, whose options come from the [signal mapping](signal-mapping.md) tables.
+4. **Skills.** A signal already covered by a skill in `.agents/skills/` or `skills-lock.json` needs no search. Map each remaining signal to a query through the [signal mapping](signal-mapping.md), present the candidates as one multi-select `question` grouped by category (name, one line, `owner/repo`, install count), install what the user confirms, and verify each one landed in both `.agents/skills/` and the lockfile.
+5. **Write** the file from the [template](template.md).
+6. **Merge** the new skills into `fullstack-engineer.md`.
+7. **Report** the file created, the skills installed, the signals with no quality skill, whatever failed, and that opencode has to restart before `pc-subagent-tiers` picks the engineer up.

package/skills/pc-make-engineer/template.md

@@ -1,36 +1,36 @@
-# Agent file template
-
-The whole file, with nothing else in it:
-
-```markdown
----
-description: <one sentence naming the persona + top 3-5 detected technologies>
-mode: subagent
----
-
-<One paragraph: "You are a {persona} engineer specializing in {top technologies}. You own all work in {scope/files}." Keep it to 2-3 sentences max.>
-
-## Abilities
-- Guardrails: @pc-guardrails-generic, @pc-guardrails-project
-- Development: <@installed-skill-1>, <@installed-skill-2>, ...
-- Testing: <@installed-skill-for-testing>, ...
-- Infrastructure: <@installed-skill-for-devops>, ...
-```
-
-Replace every `<...>` placeholder with real values, and drop any category line with no skills in it (Guardrails always stays). Development is language, framework, UI and DI skills; Testing is test, lint and typecheck skills; Infrastructure is DevOps, CI/CD and cloud skills.
-
-## Description quality bar
-
-`description:` is the matching key for `/plan-apply`: the lead compares a task's domain text against it to pick a specialist, so a vague one gets the wrong engineer spawned.
-
-Bad: `"A frontend engineer for React"`
-
-Good: `"Frontend engineer for Ink 7 + React 19 TUI, FSD architecture, Inversify DI, design tokens, and i18n"`
-
-Name the persona, list the three to five technologies actually detected, one sentence, no padding.
-
-## Identity paragraph
-
-Two or three sentences: who the engineer is, and what files or layers it owns. A knowledge dump here is knowledge the lead cannot reuse and the engineer did not ask for.
-
-Good: `"You are a frontend engineer specializing in terminal UI development with Ink 7 + React 19. You own all work in the FSD layers: src/app/, src/widgets/, src/features/, src/entities/, and src/shared/."`
+# Agent file template
+
+The whole file, with nothing else in it:
+
+```markdown
+---
+description: <one sentence naming the persona + top 3-5 detected technologies>
+mode: subagent
+---
+
+<One paragraph: "You are a {persona} engineer specializing in {top technologies}. You own all work in {scope/files}." Keep it to 2-3 sentences max.>
+
+## Abilities
+- Guardrails: @pc-guardrails-generic, @pc-guardrails-project
+- Development: <@installed-skill-1>, <@installed-skill-2>, ...
+- Testing: <@installed-skill-for-testing>, ...
+- Infrastructure: <@installed-skill-for-devops>, ...
+```
+
+Replace every `<...>` placeholder with real values, and drop any category line with no skills in it (Guardrails always stays). Development is language, framework, UI and DI skills; Testing is test, lint and typecheck skills; Infrastructure is DevOps, CI/CD and cloud skills.
+
+## Description quality bar
+
+`description:` is the matching key for `/plan-apply`: the lead compares a task's domain text against it to pick a specialist, so a vague one gets the wrong engineer spawned.
+
+Bad: `"A frontend engineer for React"`
+
+Good: `"Frontend engineer for Ink 7 + React 19 TUI, FSD architecture, Inversify DI, design tokens, and i18n"`
+
+Name the persona, list the three to five technologies actually detected, one sentence, no padding.
+
+## Identity paragraph
+
+Two or three sentences: who the engineer is, and what files or layers it owns. A knowledge dump here is knowledge the lead cannot reuse and the engineer did not ask for.
+
+Good: `"You are a frontend engineer specializing in terminal UI development with Ink 7 + React 19. You own all work in the FSD layers: src/app/, src/widgets/, src/features/, src/entities/, and src/shared/."`

package/skills/pc-make-guardrails/category-reference.md

@@ -1,112 +1,112 @@
-# Guardrails category reference
-
-From the documents and code graph analysis, extract the rules an agent could break without noticing. Only include a category if you found real evidence for it.
-
-- Architecture constraints: layer boundaries, module dependencies, forbidden imports, directory ownership rules (e.g. "src/api/ must not import from src/ui/"). Verify actual import boundaries with the project-selected analysis tools.
-- File organization: the god-files and dumping-ground constants this project has already accumulated, named. The general principle is in `pc-guardrails-generic`; what belongs here is where this codebase keeps breaking it.
-- Naming conventions: file naming, component naming, API route conventions, branch naming
-- Code style: formatter config, lint rules, import ordering, max line length. Derive from actual config files.
-- Testing rules: test file locations, naming, coverage gates, what must be tested before merge
-- Build & deployment: build commands, env requirements, deployment targets, CI gates
-- Data & state: migration rules, schema change process, state management patterns
-- Security: auth boundaries, input validation requirements, secrets handling
-- Dependencies: package manager, lockfile rules, upgrade policy, forbidden packages
-- Git workflow: branch naming, commit message format, PR process (platform-specific from `harness.json`)
-- Domain-specific rules: anything in `openspec/config.yaml` context or `ARCHITECTURE.md` constraints/risks sections
-
-Each rule must be:
-
-- **Negative.** State the boundary and what breaks when it is crossed, not the behaviour you want: `Never import Microsoft.EntityFrameworkCore.* in Application; it is a layer violation and the build does not catch it`, not `Keep Application framework-free`. A prohibition removes an option; a preference competes with everything else the model knows about writing code, and loses.
-- **Concrete**: "Use `pnpm` not `npm`" not "Use the right package manager".
-- **Evidence-based**: derived from the files and code graph you analyzed. Never invent a rule the project does not state or demonstrate somewhere.
-- **Not enforced elsewhere.** Skip anything the formatter, linter, type checker, test suite, CI gate or a harness plugin already fails the build on. A rule restating `biome.json` is read on every load and changes nothing: the build was going to catch it. Write the rules that nothing but a careful reader would catch.
-- **Not already in `pc-guardrails-generic`.** That skill loads alongside this one, every request. Secrets, zero-comment default, scratch-file location, one-responsibility-per-file, minimal-test discipline, and the engineer workflow are its rules, not this file's.
-
-**At most 40 rules, across all categories.** Rank by what a violation costs and cut from the bottom; a category with nothing consequential in it gets no rules at all. This cap is the point of the exercise, not tidiness: compliance falls away as a rule file grows, so the 41st rule does not just cost its own tokens, it dilutes the 40 that matter. If more than 40 survive every bar above, the excess is a sign the project's constraints belong in a linter rule or a CI check instead.
-
-## Contrastive example
-
-**Bad** (reference fact — cut):
-> - The SQL Server database name is `myapp`, lowercase.
-
-The agent reads the connection string in config. It costs tokens on every load and the agent cannot "break" it.
-
-**Good** (negative constraint with consequence — keep):
-> - Never add a cached column for a value that is derived from another entity; a later edit to the source leaves the cache stale, and nothing in the build catches it.
-
-The agent could break this without noticing, nothing mechanically enforces it, and the consequence is stated.
-
-## Skill template
-
-Each section holds constraints an agent could break without noticing, not reference facts. "Naming Conventions" does not mean "list how files are named" — it means "name the conventions whose violation is silent and costly." "Build & Deployment" does not mean "list the build commands" — it means "name the build rules a developer could violate without CI catching it." If a section has only reference facts, omit it entirely.
-
-Write (or update) `.agents/skills/pc-guardrails-project/SKILL.md`:
-
-```markdown
----
-name: pc-guardrails-project
-description: Project-specific rules and constraints extracted from ARCHITECTURE.md. Load this skill before implementing any change to understand boundaries, conventions, and constraints for this codebase.
-license: MIT
----
-
-# Project Guardrails
-
-> Auto-generated by `/make-guardrails`. Regenerate with the same command when architecture or conventions change.
-
-## Architecture Constraints
-- <rule>
-- <rule>
-
-## Naming Conventions
-- <rule>
-
-## Code Style
-- <rule>
-
-## Testing
-- <rule>
-
-## Build & Deployment
-- <rule>
-
-## Data & State
-- <rule>
-
-## Security
-- <rule>
-
-## Dependencies
-- <rule>
-
-## Git Workflow
-- <rule>
-
-<!-- Last updated: <current ISO timestamp> -->
-```
-
-Only include sections that have real rules. Omit empty sections.
-
-## Self-check (before writing the file)
-
-Re-read the output you are about to write. Then:
-
-1. **Count the rules** (every bullet under every section). If there are more than 40, cut from the bottom — rank by what a violation costs and remove the cheapest until you are at or under 40. A rule file past 40 dilutes the ones that matter.
-
-2. **Scan for positive phrasing and reference facts.** Cut or rewrite any rule that:
-   - States what something is named, rather than what must not be named that way and why.
-   - Lists a port number, a database name, a package version, a SDK version, or a connection string. The agent discovers these by reading config.
-   - Describes how something works (e.g. "auth uses a smart scheme that forwards to JWT or Cookies"), rather than what must not be done with it.
-   - Restates a project's tech stack as a list ("Frontend: React 19, Next.js 15, TypeScript…"). That is reference material, not a constraint.
-
-3. **Strip anything already enforced by tooling.** Remove a rule if any of these already fails the build on its violation:
-   - Biome / ESLint / Prettier / Steiger / lint:fsd
-   - NetArchTest / architecture test projects
-   - Semgrep / Trivy / TruffleHog / SBOM checks
-   - Coverage gates (`scripts/check-coverage.mjs`)
-   - `.editorconfig`, `Directory.Build.props`, NuGet audit gates
-   - CI workflow steps (`app-ci.yml`, `ci.yml`)
-   - GitHub branch protection / required checks. If the build catches it, the rule costs tokens and adds nothing. The only exception is a rule whose enforcement is partial or non-obvious (e.g. architecture tests enforce layering but a developer could still import a namespace through reflection or a transitive dependency — that nuance is worth a rule).
-
-4. **Strip anything already in `pc-guardrails-generic`.** That skill loads on every request alongside this one. Its rules are: secrets discipline, zero-comment default (WHY not WHAT, 10% ceiling, no auto-generated docstrings), scratch-file location, one-responsibility-per-file, minimal-test discipline (one regression test per bug, no framework/library tests, no integration/e2e/snapshot unless asked, no mock-assertion of third-party calls), and the engineer workflow. Do not restate any of them here.
-
-5. **Re-count after cutting.** If you are still over 40, you are writing reference material, not constraints. Cut harder.
+# Guardrails category reference
+
+From the documents and code graph analysis, extract the rules an agent could break without noticing. Only include a category if you found real evidence for it.
+
+- Architecture constraints: layer boundaries, module dependencies, forbidden imports, directory ownership rules (e.g. "src/api/ must not import from src/ui/"). Verify actual import boundaries with the project-selected analysis tools.
+- File organization: the god-files and dumping-ground constants this project has already accumulated, named. The general principle is in `pc-guardrails-generic`; what belongs here is where this codebase keeps breaking it.
+- Naming conventions: file naming, component naming, API route conventions, branch naming
+- Code style: formatter config, lint rules, import ordering, max line length. Derive from actual config files.
+- Testing rules: test file locations, naming, coverage gates, what must be tested before merge
+- Build & deployment: build commands, env requirements, deployment targets, CI gates
+- Data & state: migration rules, schema change process, state management patterns
+- Security: auth boundaries, input validation requirements, secrets handling
+- Dependencies: package manager, lockfile rules, upgrade policy, forbidden packages
+- Git workflow: branch naming, commit message format, PR process (platform-specific from `harness.json`)
+- Domain-specific rules: anything in `openspec/config.yaml` context or `ARCHITECTURE.md` constraints/risks sections
+
+Each rule must be:
+
+- **Negative.** State the boundary and what breaks when it is crossed, not the behaviour you want: `Never import Microsoft.EntityFrameworkCore.* in Application; it is a layer violation and the build does not catch it`, not `Keep Application framework-free`. A prohibition removes an option; a preference competes with everything else the model knows about writing code, and loses.
+- **Concrete**: "Use `pnpm` not `npm`" not "Use the right package manager".
+- **Evidence-based**: derived from the files and code graph you analyzed. Never invent a rule the project does not state or demonstrate somewhere.
+- **Not enforced elsewhere.** Skip anything the formatter, linter, type checker, test suite, CI gate or a harness plugin already fails the build on. A rule restating `biome.json` is read on every load and changes nothing: the build was going to catch it. Write the rules that nothing but a careful reader would catch.
+- **Not already in `pc-guardrails-generic`.** That skill loads alongside this one, every request. Secrets, zero-comment default, scratch-file location, one-responsibility-per-file, minimal-test discipline, and the engineer workflow are its rules, not this file's.
+
+**At most 40 rules, across all categories.** Rank by what a violation costs and cut from the bottom; a category with nothing consequential in it gets no rules at all. This cap is the point of the exercise, not tidiness: compliance falls away as a rule file grows, so the 41st rule does not just cost its own tokens, it dilutes the 40 that matter. If more than 40 survive every bar above, the excess is a sign the project's constraints belong in a linter rule or a CI check instead.
+
+## Contrastive example
+
+**Bad** (reference fact — cut):
+> - The SQL Server database name is `myapp`, lowercase.
+
+The agent reads the connection string in config. It costs tokens on every load and the agent cannot "break" it.
+
+**Good** (negative constraint with consequence — keep):
+> - Never add a cached column for a value that is derived from another entity; a later edit to the source leaves the cache stale, and nothing in the build catches it.
+
+The agent could break this without noticing, nothing mechanically enforces it, and the consequence is stated.
+
+## Skill template
+
+Each section holds constraints an agent could break without noticing, not reference facts. "Naming Conventions" does not mean "list how files are named" — it means "name the conventions whose violation is silent and costly." "Build & Deployment" does not mean "list the build commands" — it means "name the build rules a developer could violate without CI catching it." If a section has only reference facts, omit it entirely.
+
+Write (or update) `.agents/skills/pc-guardrails-project/SKILL.md`:
+
+```markdown
+---
+name: pc-guardrails-project
+description: Project-specific rules and constraints extracted from ARCHITECTURE.md. Load this skill before implementing any change to understand boundaries, conventions, and constraints for this codebase.
+license: MIT
+---
+
+# Project Guardrails
+
+> Auto-generated by `/make-guardrails`. Regenerate with the same command when architecture or conventions change.
+
+## Architecture Constraints
+- <rule>
+- <rule>
+
+## Naming Conventions
+- <rule>
+
+## Code Style
+- <rule>
+
+## Testing
+- <rule>
+
+## Build & Deployment
+- <rule>
+
+## Data & State
+- <rule>
+
+## Security
+- <rule>
+
+## Dependencies
+- <rule>
+
+## Git Workflow
+- <rule>
+
+<!-- Last updated: <current ISO timestamp> -->
+```
+
+Only include sections that have real rules. Omit empty sections.
+
+## Self-check (before writing the file)
+
+Re-read the output you are about to write. Then:
+
+1. **Count the rules** (every bullet under every section). If there are more than 40, cut from the bottom — rank by what a violation costs and remove the cheapest until you are at or under 40. A rule file past 40 dilutes the ones that matter.
+
+2. **Scan for positive phrasing and reference facts.** Cut or rewrite any rule that:
+   - States what something is named, rather than what must not be named that way and why.
+   - Lists a port number, a database name, a package version, a SDK version, or a connection string. The agent discovers these by reading config.
+   - Describes how something works (e.g. "auth uses a smart scheme that forwards to JWT or Cookies"), rather than what must not be done with it.
+   - Restates a project's tech stack as a list ("Frontend: React 19, Next.js 15, TypeScript…"). That is reference material, not a constraint.
+
+3. **Strip anything already enforced by tooling.** Remove a rule if any of these already fails the build on its violation:
+   - Biome / ESLint / Prettier / Steiger / lint:fsd
+   - NetArchTest / architecture test projects
+   - Semgrep / Trivy / TruffleHog / SBOM checks
+   - Coverage gates (`scripts/check-coverage.mjs`)
+   - `.editorconfig`, `Directory.Build.props`, NuGet audit gates
+   - CI workflow steps (`app-ci.yml`, `ci.yml`)
+   - GitHub branch protection / required checks. If the build catches it, the rule costs tokens and adds nothing. The only exception is a rule whose enforcement is partial or non-obvious (e.g. architecture tests enforce layering but a developer could still import a namespace through reflection or a transitive dependency — that nuance is worth a rule).
+
+4. **Strip anything already in `pc-guardrails-generic`.** That skill loads on every request alongside this one. Its rules are: secrets discipline, zero-comment default (WHY not WHAT, 10% ceiling, no auto-generated docstrings), scratch-file location, one-responsibility-per-file, minimal-test discipline (one regression test per bug, no framework/library tests, no integration/e2e/snapshot unless asked, no mock-assertion of third-party calls), and the engineer workflow. Do not restate any of them here.
+
+5. **Re-count after cutting.** If you are still over 40, you are writing reference material, not constraints. Cut harder.

package/skills/pc-make-merge-risk-assess/SKILL.md

@@ -1,70 +1,70 @@
----
-name: pc-make-merge-risk-assess
-description: Generate or update the pc-merge-risk-assess skill from project guardrails and architecture. Produces a PR-level risk assessment that loop recipes can gate automerge on. Invoked by the /make-merge-risk-assess command and the repo-initialize flow.
-license: MIT
----
-
-# Make Merge Risk Assess
-
-Analyze `ARCHITECTURE.md`, the project guardrails skill, and other project files to generate or update an `pc-merge-risk-assess` skill: a checklist of risk indicators that an AI agent evaluates before auto-merging a pull request. When any indicator matches, the agent blocks automerge and leaves the PR for human review with an explanation.
-
-## Steps
-
-1. **Check current state**
-
-   Read `.agents/skills/pc-merge-risk-assess/SKILL.md`. Determine which mode to use:
-   - Does not exist: Generate mode. Create from scratch.
-   - Exists and has a `<!-- Last updated:` footer: Update mode. Incrementally update.
-   - Exists but no timestamp: proceed in Generate mode (full regeneration).
-
-2a. **Generate mode: read source documents**
-
-   Read ALL of the following that exist:
-   - `.agents/skills/pc-guardrails-project/SKILL.md` (primary source — project-specific constraints)
-   - `.agents/skills/pc-guardrails-generic/SKILL.md` (generic safety rules)
-   - `ARCHITECTURE.md` (architecture boundaries, critical paths)
-   - `AGENTS.md` (non-negotiable constraints, verification rules)
-   - `.opencode/harness.json` (platform, concurrency)
-   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
-   - Loop recipes: `.loops/recipes/*-loop.yaml` (understand the automerge flow)
-
-   Use file tools to discover risk-critical code paths: `grep` for calculation engines, audit appenders, auth middleware, schema migrations, permission checks, and other sensitive areas.
-
-2b. **Update mode: incremental analysis**
-
-   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
-   - Read `.agents/skills/pc-guardrails-project/SKILL.md` and check its `<!-- Last updated:` timestamp. If the guardrails haven't changed and ARCHITECTURE.md hasn't changed since the risk skill was last generated, report "Merge risk assessment up to date" and stop.
-   - Run `git log --oneline --since="<date>" -- <relevant config and architecture files>` to find what changed.
-   - If nothing changed: report "Merge risk assessment up to date" and stop.
-   - Update only the affected risk categories. Preserve manually-added risk indicators in unchanged categories.
-   - If changes are pervasive, fall back to Generate mode.
-
-3. **Extract risk indicators**
-
-   From the documents and code analysis, extract concrete, testable risk indicators. Follow the [category reference](category-reference.md) for the full list of categories, indicator quality standards, and the skill file template.
-
-   Each risk indicator must identify a code path or change pattern that, when touched, makes a PR too dangerous to auto-merge. The indicator must be something an AI agent can detect by reading the PR diff.
-
-4. **Write the skill**
-
-   Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real indicators. Omit empty sections.
-
-5. **Update agents**
-
-   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-merge-risk-assess` to the Agent Workflow ability group (skip if already present). This ensures every engineer can evaluate risk before merge. Use this pattern:
-   ```markdown
-   ## Abilities
-   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
-   ...
-   - Development, Agent Workflow: @pc-merge-risk-assess[, ...existing entries unchanged]
-   ```
-
-   If no "Development, Agent Workflow" line exists, create it. Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
-
-6. **Report**
-
-   Tell the user:
-   - Whether the skill was generated or updated (and which categories changed)
-   - Number of risk indicators extracted per category
-   - Number of agent files updated
-   - Tip: "Rerun `/make-merge-risk-assess` any time the architecture or project guardrails change significantly."
+---
+name: pc-make-merge-risk-assess
+description: Generate or update the pc-merge-risk-assess skill from project guardrails and architecture. Produces a PR-level risk assessment that loop recipes can gate automerge on. Invoked by the /make-merge-risk-assess command and the repo-initialize flow.
+license: MIT
+---
+
+# Make Merge Risk Assess
+
+Analyze `ARCHITECTURE.md`, the project guardrails skill, and other project files to generate or update an `pc-merge-risk-assess` skill: a checklist of risk indicators that an AI agent evaluates before auto-merging a pull request. When any indicator matches, the agent blocks automerge and leaves the PR for human review with an explanation.
+
+## Steps
+
+1. **Check current state**
+
+   Read `.agents/skills/pc-merge-risk-assess/SKILL.md`. Determine which mode to use:
+   - Does not exist: Generate mode. Create from scratch.
+   - Exists and has a `<!-- Last updated:` footer: Update mode. Incrementally update.
+   - Exists but no timestamp: proceed in Generate mode (full regeneration).
+
+2a. **Generate mode: read source documents**
+
+   Read ALL of the following that exist:
+   - `.agents/skills/pc-guardrails-project/SKILL.md` (primary source — project-specific constraints)
+   - `.agents/skills/pc-guardrails-generic/SKILL.md` (generic safety rules)
+   - `ARCHITECTURE.md` (architecture boundaries, critical paths)
+   - `AGENTS.md` (non-negotiable constraints, verification rules)
+   - `.opencode/harness.json` (platform, concurrency)
+   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
+   - Loop recipes: `.loops/recipes/*-loop.yaml` (understand the automerge flow)
+
+   Use file tools to discover risk-critical code paths: `grep` for calculation engines, audit appenders, auth middleware, schema migrations, permission checks, and other sensitive areas.
+
+2b. **Update mode: incremental analysis**
+
+   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
+   - Read `.agents/skills/pc-guardrails-project/SKILL.md` and check its `<!-- Last updated:` timestamp. If the guardrails haven't changed and ARCHITECTURE.md hasn't changed since the risk skill was last generated, report "Merge risk assessment up to date" and stop.
+   - Run `git log --oneline --since="<date>" -- <relevant config and architecture files>` to find what changed.
+   - If nothing changed: report "Merge risk assessment up to date" and stop.
+   - Update only the affected risk categories. Preserve manually-added risk indicators in unchanged categories.
+   - If changes are pervasive, fall back to Generate mode.
+
+3. **Extract risk indicators**
+
+   From the documents and code analysis, extract concrete, testable risk indicators. Follow the [category reference](category-reference.md) for the full list of categories, indicator quality standards, and the skill file template.
+
+   Each risk indicator must identify a code path or change pattern that, when touched, makes a PR too dangerous to auto-merge. The indicator must be something an AI agent can detect by reading the PR diff.
+
+4. **Write the skill**
+
+   Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real indicators. Omit empty sections.
+
+5. **Update agents**
+
+   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-merge-risk-assess` to the Agent Workflow ability group (skip if already present). This ensures every engineer can evaluate risk before merge. Use this pattern:
+   ```markdown
+   ## Abilities
+   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
+   ...
+   - Development, Agent Workflow: @pc-merge-risk-assess[, ...existing entries unchanged]
+   ```
+
+   If no "Development, Agent Workflow" line exists, create it. Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
+
+6. **Report**
+
+   Tell the user:
+   - Whether the skill was generated or updated (and which categories changed)
+   - Number of risk indicators extracted per category
+   - Number of agent files updated
+   - Tip: "Rerun `/make-merge-risk-assess` any time the architecture or project guardrails change significantly."