@plainconceptsplatform/agent-harness 2.0.0 → 2.1.0

package/src/content/.agents/skills/pc-make-engineer/template.md

@@ -1,81 +1,81 @@
-# Agent file template
-
-The agent file is exactly this structure: frontmatter plus one identity paragraph plus the `## Abilities` section. No other sections. No other content.
-
-```markdown
----
-description: <one sentence naming the persona + top 3-5 detected technologies>
-mode: primary
-color: <pick: primary|secondary|accent|error|info: avoid colors used by existing agents; warning is reserved for the lead engineer>
-permission:
-  edit: allow
-  bash: allow
-  read: allow
-  glob: allow
-  grep: allow
----
-
-<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>, ...
-```
-
-That is the entire file: frontmatter, one identity paragraph, and the `## Abilities` section. The always-installed `pc-system-reminders` plugin loads the listed skills for every session. Replace every `<...>` placeholder with real values from your research. Remove any ability category line that has no skills assigned (besides Guardrails which is always present).
-
-## Description quality bar
-
-The `description:` field is the matching key for `/plan-apply`. The lead compares task domain text against agent descriptions to pick the right specialist. A weak description means the wrong engineer gets spawned.
-
-Bad: `"A frontend engineer for React"`
-Good: `"Frontend engineer for Ink 7 + React 19 TUI, FSD architecture, Inversify DI, design tokens, and i18n"`
-
-Rules:
-- Name the persona explicitly
-- List the top 3-5 detected technologies from Step 2
-- One sentence, no padding
-
-## Identity paragraph
-
-The identity paragraph sits between frontmatter and `## Abilities`. It tells the engineer who it is and what it owns in 2-3 sentences max. Not a spec, not a knowledge dump, a quick scoping statement.
-
-Bad: 5 paragraphs of architecture details, FSD rules, design tokens, file maps, testing patterns.
-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/."`
-
-Rules:
-- State the persona and specialization in one sentence
-- State what files or layers the engineer owns in one sentence
-- Never exceed 3 sentences
-
-## Category rules
-
-- Development = language/framework/UI/DI skills. Testing = test/lint/typecheck skills. Infrastructure = DevOps/CI/CD/cloud skills.
-- Only include ability categories that have at least one real skill (besides Guardrails which is always present).
-- Name follows `{persona}-engineer` pattern (e.g. `frontend-engineer`, `backend-engineer`).
-- Read existing agents' `color:` frontmatter first: pick a color not already used.
-- `warning` is reserved for the lead (fullstack) engineer, the planning agent. Never assign it to a spawned specialist.
-
-## Structural validation checklist
-
-After writing the agent file, verify:
-
-1. Frontmatter exists: starts with `---`, has `description`, `mode: primary`, `color`, `permission` block.
-2. No `model:` field in the frontmatter. The `pc-subagent-tiers` plugin injects it.
-3. `## Abilities` is the only `##` heading. No other `##` sections exist in the file.
-4. One identity paragraph before `## Abilities`: 2-3 sentences max, not multiple paragraphs.
-5. Abilities are categorized: each line starts with `- Guardrails:`, `- Development:`, `- Testing:`, or `- Infrastructure:`. No bare `@skill-name` lines.
-6. One file only: no `.build.md`, `.fast.md`, or `.plan.md` variant was created.
-
-If any check fails, rewrite the file to match the template exactly.
-
-## Skill reference validation
-
-1. Parse every `@skill-name` from the `## Abilities` section (excluding `@pc-guardrails-generic` and `@pc-guardrails-project` which are installed at init).
-2. For each: check `.agents/skills/<skill-name>/SKILL.md` exists.
-3. For each: check `skills-lock.json` contains the skill.
-4. If `.agents/skills/<skill-name>/SKILL.md` exists but `skills-lock.json` is missing the entry: manually patch `skills-lock.json` using the Edit tool (same procedure as in the signal mapping reference). Re-read `skills-lock.json` to confirm it is valid JSON.
-5. If `.agents/skills/<skill-name>/SKILL.md` is missing: try to install it: `npx skills add -y <owner/repo@skill-name>` (search `skills-lock.json` or `npx skills find` for the owner/repo). If install fails or the skill can't be found on skills.sh, remove the reference from the file, warn the user, and note it in the summary.
-6. Re-read the file to confirm all remaining `@skill-name` references are valid.
+# Agent file template
+
+The agent file is exactly this structure: frontmatter plus one identity paragraph plus the `## Abilities` section. No other sections. No other content.
+
+```markdown
+---
+description: <one sentence naming the persona + top 3-5 detected technologies>
+mode: subagent
+color: <pick: primary|secondary|accent|error|info: avoid colors used by existing agents; warning is reserved for the build and plan primaries>
+permission:
+  edit: allow
+  bash: allow
+  read: allow
+  glob: allow
+  grep: allow
+---
+
+<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>, ...
+```
+
+That is the entire file: frontmatter, one identity paragraph, and the `## Abilities` section. The always-installed `pc-system-reminders` plugin loads the listed skills for every session. Replace every `<...>` placeholder with real values from your research. Remove any ability category line that has no skills assigned (besides Guardrails which is always present).
+
+## Description quality bar
+
+The `description:` field is the matching key for `/plan-apply`. The lead compares task domain text against agent descriptions to pick the right specialist. A weak description means the wrong engineer gets spawned.
+
+Bad: `"A frontend engineer for React"`
+Good: `"Frontend engineer for Ink 7 + React 19 TUI, FSD architecture, Inversify DI, design tokens, and i18n"`
+
+Rules:
+- Name the persona explicitly
+- List the top 3-5 detected technologies from Step 2
+- One sentence, no padding
+
+## Identity paragraph
+
+The identity paragraph sits between frontmatter and `## Abilities`. It tells the engineer who it is and what it owns in 2-3 sentences max. Not a spec, not a knowledge dump, a quick scoping statement.
+
+Bad: 5 paragraphs of architecture details, FSD rules, design tokens, file maps, testing patterns.
+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/."`
+
+Rules:
+- State the persona and specialization in one sentence
+- State what files or layers the engineer owns in one sentence
+- Never exceed 3 sentences
+
+## Category rules
+
+- Development = language/framework/UI/DI skills. Testing = test/lint/typecheck skills. Infrastructure = DevOps/CI/CD/cloud skills.
+- Only include ability categories that have at least one real skill (besides Guardrails which is always present).
+- Name follows `{persona}-engineer` pattern (e.g. `frontend-engineer`, `backend-engineer`).
+- Read existing agents' `color:` frontmatter first: pick a color not already used.
+- `warning` is reserved for the lead (fullstack) engineer, the planning agent. Never assign it to a spawned specialist.
+
+## Structural validation checklist
+
+After writing the agent file, verify:
+
+1. Frontmatter exists: starts with `---`, has `description`, `mode: subagent`, `color`, `permission` block.
+2. No `model:` field in the frontmatter. The `pc-subagent-tiers` plugin injects it.
+3. `## Abilities` is the only `##` heading. No other `##` sections exist in the file.
+4. One identity paragraph before `## Abilities`: 2-3 sentences max, not multiple paragraphs.
+5. Abilities are categorized: each line starts with `- Guardrails:`, `- Development:`, `- Testing:`, or `- Infrastructure:`. No bare `@skill-name` lines.
+6. One file only: no `.build.md`, `.fast.md`, or `.plan.md` variant was created.
+
+If any check fails, rewrite the file to match the template exactly.
+
+## Skill reference validation
+
+1. Parse every `@skill-name` from the `## Abilities` section (excluding `@pc-guardrails-generic` and `@pc-guardrails-project` which are installed at init).
+2. For each: check `.agents/skills/<skill-name>/SKILL.md` exists.
+3. For each: check `skills-lock.json` contains the skill.
+4. If `.agents/skills/<skill-name>/SKILL.md` exists but `skills-lock.json` is missing the entry: manually patch `skills-lock.json` using the Edit tool (same procedure as in the signal mapping reference). Re-read `skills-lock.json` to confirm it is valid JSON.
+5. If `.agents/skills/<skill-name>/SKILL.md` is missing: try to install it: `npx skills add -y <owner/repo@skill-name>` (search `skills-lock.json` or `npx skills find` for the owner/repo). If install fails or the skill can't be found on skills.sh, remove the reference from the file, warn the user, and note it in the summary.
+6. Re-read the file to confirm all remaining `@skill-name` references are valid.

package/src/content/.agents/skills/pc-make-evidence-scaffold/SKILL.md

@@ -1,18 +1,18 @@
----
-name: pc-make-evidence-scaffold
-description: DEPRECATED. Visual evidence is now built into pc-ops-evidence using playwright-cli + pnpm run dev. No per-project scaffold is needed. This skill is kept for backward compatibility but should not be used.
-license: MIT
----
-
-# DEPRECATED
-
-This skill is no longer needed. Visual evidence uses a two-phase architecture:
-
-1. **Agent phase:** `pc-ops-evidence` writes a `capturePlan` in `evidence.json` (the agent sandbox cannot run Docker or headless Chromium)
-2. **CI phase:** A separate "Visual evidence" CI workflow reads the capturePlan and captures screenshots on a runner with full Docker and Chrome access
-
-No per-project scaffold, fixture apps, or scenario registries are required. The `pc-ops-evidence` skill handles everything generically.
-
-If you previously ran `/make-evidence-scaffold` and have a `src/visual-evidence/` directory or `visual-evidence` scripts in `package.json`, you can delete them — the new system does not use them.
-
-To capture evidence for a change, just run `/ops-evidence` or let `/plan-goal` handle it automatically.
+---
+name: pc-make-evidence-scaffold
+description: DEPRECATED. Visual evidence is now built into pc-ops-evidence using playwright-cli + pnpm run dev. No per-project scaffold is needed. This skill is kept for backward compatibility but should not be used.
+license: MIT
+---
+
+# DEPRECATED
+
+This skill is no longer needed. Visual evidence uses a two-phase architecture:
+
+1. **Agent phase:** `pc-ops-evidence` writes a `capturePlan` in `evidence.json` (the agent sandbox cannot run Docker or headless Chromium)
+2. **CI phase:** A separate "Visual evidence" CI workflow reads the capturePlan and captures screenshots on a runner with full Docker and Chrome access
+
+No per-project scaffold, fixture apps, or scenario registries are required. The `pc-ops-evidence` skill handles everything generically.
+
+If you previously ran `/make-evidence-scaffold` and have a `src/visual-evidence/` directory or `visual-evidence` scripts in `package.json`, you can delete them — the new system does not use them.
+
+To capture evidence for a change, just run `/ops-evidence` or let `/plan-goal` handle it automatically.

package/src/content/.agents/skills/pc-make-evidence-scaffold/evidence-contract.md

@@ -1,29 +1,29 @@
-# Evidence contract
-
-Evidence captured by `/plan-goal` lives at `openspec/changes/archive/<dated>-<id>/evidence/`. A standalone pre-archive capture may use `openspec/changes/<id>/evidence/`, but archive moves it into the archived change before publication. That folder contains only:
-- ordered capture images (`01-{label}.png/webp`, ...) and/or `flow.gif`
-- `evidence.json`: the manifest, schema below.
-
-## version 1 schema
-
-```jsonc
-{
-  "version": 1,
-  "changeId": "...",
-  "required": true,
-  "status": "passed",            // passed | skipped | failed | blocked
-  "assets": [ { "type": "screenshot", "path": "openspec/changes/archive/<dated>-<id>/evidence/01-final.png", "caption": "...", "bytes": 0, "format": "png" } ],
-  "reason": "...",                 // skipped | blocked
-  "failedStep": "...",             // failed
-  "prMarkdown": "## Evidence ..."
-}
-```
-
-## Statuses
-
-- `passed`: evidence required and produced.
-- `skipped`: evidence not required (see decision rule). Exit success.
-- `blocked`: required but could not run (no harness, app won't start, budget exceeded). Not a skip. Surface it.
-- `failed`: a project harness ran and its assertions failed. Surface it.
-
-`blocked` (required but unrunnable) is never treated as a skip.
+# Evidence contract
+
+Evidence captured by `/plan-goal` lives at `openspec/changes/archive/<dated>-<id>/evidence/`. A standalone pre-archive capture may use `openspec/changes/<id>/evidence/`, but archive moves it into the archived change before publication. That folder contains only:
+- ordered capture images (`01-{label}.png/webp`, ...) and/or `flow.gif`
+- `evidence.json`: the manifest, schema below.
+
+## version 1 schema
+
+```jsonc
+{
+  "version": 1,
+  "changeId": "...",
+  "required": true,
+  "status": "passed",            // passed | skipped | failed | blocked
+  "assets": [ { "type": "screenshot", "path": "openspec/changes/archive/<dated>-<id>/evidence/01-final.png", "caption": "...", "bytes": 0, "format": "png" } ],
+  "reason": "...",                 // skipped | blocked
+  "failedStep": "...",             // failed
+  "prMarkdown": "## Evidence ..."
+}
+```
+
+## Statuses
+
+- `passed`: evidence required and produced.
+- `skipped`: evidence not required (see decision rule). Exit success.
+- `blocked`: required but could not run (no harness, app won't start, budget exceeded). Not a skip. Surface it.
+- `failed`: a project harness ran and its assertions failed. Surface it.
+
+`blocked` (required but unrunnable) is never treated as a skip.

package/src/content/.agents/skills/pc-make-guardrails/SKILL.md

@@ -1,74 +1,74 @@
----
-name: pc-make-guardrails
-description: Generate or update the pc-guardrails-project skill from ARCHITECTURE.md and relevant project files, then wire it into every engineer agent. Invoked by the /make-guardrails command and the repo-initialize flow.
-license: MIT
----
-
-# Make Guardrails
-
-Analyze `ARCHITECTURE.md` and other project files to generate or update a `pc-guardrails-project` skill: a set of rules and constraints extracted from the project's own documentation that agents must follow.
-
-## Steps
-
-1. **Check current state**
-
-   Read `.agents/skills/pc-guardrails-project/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:
-   - `ARCHITECTURE.md` (primary source)
-   - `DESIGN.md` (design system, component conventions)
-   - `AGENTS.md` (existing agent instructions, optimizations)
-   - `README.md` (setup, conventions)
-   - `CONTRIBUTING.md` (if present)
-   - `.opencode/harness.json` (platform, models, concurrency)
-   - `openspec/config.yaml` (if present: domain context and rules)
-   - Root config files: `package.json`, `tsconfig.json`, `biome.json`, `.eslintrc*`, `Cargo.toml`, `go.mod`, `pyproject.toml`, `pom.xml`: whatever exists
-   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
-
-   Use file tools to discover constraints: `read` the documents above, `grep` for lint/formatter config rules.
-
-2b. **Update mode: incremental analysis**
-
-   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
-   - Read `ARCHITECTURE.md` and check its `<!-- Last updated:` timestamp. If ARCHITECTURE.md hasn't changed since the guardrails were last generated, report "Guardrails up to date" and stop.
-   - Run `git log --oneline --since="<date>" -- <config files, lint configs, CI workflows>` to find what convention/config files changed.
-   - If nothing changed: report "Guardrails up to date" and stop.
-   - Update only the affected rule categories. Preserve manually-added rules in unchanged categories.
-   - If changes are pervasive (new architecture, new framework, new platform), fall back to Generate mode.
-
-3. **Extract guardrails**
-
-   From the documents and code graph analysis, extract concrete, actionable rules. Follow the [category reference](category-reference.md) for the full list of categories, rule quality standards, and the skill file template.
-
-4. **Write the skill**
-
-   Write (or update) `.agents/skills/pc-guardrails-project/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real rules. Omit empty sections.
-
-5. **Update agents**
-
-   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-guardrails-project` to the Guardrails ability line (skip if already present). Keep the line's existing entries exactly as they are: only insert `@pc-guardrails-project` after `@pc-guardrails-generic`, using this pattern:
-   ```markdown
-   ## Abilities
-   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
-   ```
-
-   Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
-
-6. **Store summary in configured persistent context**
-
-   `write_note` MCP tool with title `guardrails-summary` containing:
-   - The ISO timestamp of this run
-   - Number of rules per category
-
-7. **Report**
-
-   Tell the user:
-   - Whether the skill was generated or updated (and which categories changed)
-   - Number of rules extracted per category
-   - Number of agent files updated
-   - Tip: "Rerun `/make-guardrails` any time the architecture or conventions change significantly."
+---
+name: pc-make-guardrails
+description: Generate or update the pc-guardrails-project skill from ARCHITECTURE.md and relevant project files, then wire it into every engineer agent. Invoked by the /make-guardrails command and the repo-initialize flow.
+license: MIT
+---
+
+# Make Guardrails
+
+Analyze `ARCHITECTURE.md` and other project files to generate or update a `pc-guardrails-project` skill: a set of rules and constraints extracted from the project's own documentation that agents must follow.
+
+## Steps
+
+1. **Check current state**
+
+   Read `.agents/skills/pc-guardrails-project/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:
+   - `ARCHITECTURE.md` (primary source)
+   - `DESIGN.md` (design system, component conventions)
+   - `AGENTS.md` (existing agent instructions, optimizations)
+   - `README.md` (setup, conventions)
+   - `CONTRIBUTING.md` (if present)
+   - `.opencode/harness.json` (platform, models, concurrency)
+   - `openspec/config.yaml` (if present: domain context and rules)
+   - Root config files: `package.json`, `tsconfig.json`, `biome.json`, `.eslintrc*`, `Cargo.toml`, `go.mod`, `pyproject.toml`, `pom.xml`: whatever exists
+   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
+
+   Use file tools to discover constraints: `read` the documents above, `grep` for lint/formatter config rules.
+
+2b. **Update mode: incremental analysis**
+
+   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
+   - Read `ARCHITECTURE.md` and check its `<!-- Last updated:` timestamp. If ARCHITECTURE.md hasn't changed since the guardrails were last generated, report "Guardrails up to date" and stop.
+   - Run `git log --oneline --since="<date>" -- <config files, lint configs, CI workflows>` to find what convention/config files changed.
+   - If nothing changed: report "Guardrails up to date" and stop.
+   - Update only the affected rule categories. Preserve manually-added rules in unchanged categories.
+   - If changes are pervasive (new architecture, new framework, new platform), fall back to Generate mode.
+
+3. **Extract guardrails**
+
+   From the documents and code graph analysis, extract concrete, actionable rules. Follow the [category reference](category-reference.md) for the full list of categories, rule quality standards, and the skill file template.
+
+4. **Write the skill**
+
+   Write (or update) `.agents/skills/pc-guardrails-project/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real rules. Omit empty sections.
+
+5. **Update agents**
+
+   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-guardrails-project` to the Guardrails ability line (skip if already present). Keep the line's existing entries exactly as they are: only insert `@pc-guardrails-project` after `@pc-guardrails-generic`, using this pattern:
+   ```markdown
+   ## Abilities
+   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
+   ```
+
+   Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
+
+6. **Store summary in configured persistent context**
+
+   `write_note` MCP tool with title `guardrails-summary` containing:
+   - The ISO timestamp of this run
+   - Number of rules per category
+
+7. **Report**
+
+   Tell the user:
+   - Whether the skill was generated or updated (and which categories changed)
+   - Number of rules extracted per category
+   - Number of agent files updated
+   - Tip: "Rerun `/make-guardrails` any time the architecture or conventions change significantly."

package/src/content/.agents/skills/pc-make-guardrails/category-reference.md

@@ -1,68 +1,68 @@
-# Guardrails category reference
-
-From the documents and code graph analysis, extract concrete, actionable rules in these categories. 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: avoid god-files and dumping-ground constants. Each file should have one clear responsibility. Split by domain or feature instead (e.g. `user-constants.ts`, `order-types.ts`, `auth-config.ts`). A file that imports from 5+ unrelated modules is a sign it should be split.
-- 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:
-- Concrete: "Use `pnpm` not `npm`" not "Use the right package manager"
-- Evidence-based: derive from the files/code graph you analyzed, do not invent rules
-- Actionable: an agent can check it before acting
-
-## Skill template
-
-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.
+# Guardrails category reference
+
+From the documents and code graph analysis, extract concrete, actionable rules in these categories. 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: avoid god-files and dumping-ground constants. Each file should have one clear responsibility. Split by domain or feature instead (e.g. `user-constants.ts`, `order-types.ts`, `auth-config.ts`). A file that imports from 5+ unrelated modules is a sign it should be split.
+- 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:
+- Concrete: "Use `pnpm` not `npm`" not "Use the right package manager"
+- Evidence-based: derive from the files/code graph you analyzed, do not invent rules
+- Actionable: an agent can check it before acting
+
+## Skill template
+
+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.