Agents and skills

agent-harness draws a hard line between two concepts.

Agents: universal behaviors

Agents define how to work. They are universal personas, with the same behavior across projects and stacks.

build                  primary. Implements. Full write access. The default.
plan                   primary. Same body as build, but cannot edit or spawn.
fullstack-engineer     subagent. The body build and plan share, and the fallback worker.
*-engineer             subagent. User-created specialists, spawned for parallel implementation.
*-engineer.<tier>      subagent. The same specialist pinned to a plan/build/fast model.

build and plan are the only agents a human selects, and they are overrides of opencode's own two primaries rather than new names. The pc-subagent-tiers plugin regenerates both from fullstack-engineer.md on every startup, so they always carry the current abilities, each on its own tier model. plan differs from build in two frontmatter lines: edit: deny and task: deny. Spawning is denied because a plan session that can call task() can have a build worker make the change for it, which is read-only by convention only. It keeps bash so planning can read git and openspec state, and pc-system-reminders holds that shell to inspection commands.

Everything else is mode: subagent and reached through task(), never picked from the agent list. Project-specific specialization comes from user-created engineers via /make-engineer. During /plan-apply the lead inspects the engineers that actually exist in .opencode/agents/ and spawns matching specialists. Prefer a specialist over fullstack-engineer; if none matches, create one.

Skills: platform knowledge

Skills define what to know. They provide project rules, platform behavior and task-specific execution guidance. Agents auto-detect and load relevant skills: you do not manually choose skills per prompt.

• pc-guardrails-generic is the mandatory baseline for every agent (git, secrets, quality rules, plus the engineer workflow)
• Baseline context rules and token-optimization guidance live in AGENTS.md (always in context), not in a skill

Default fullstack-engineer abilities:

## Abilities
- Guardrails: @pc-guardrails-generic, @pc-guardrails-project

Users are expected to create additional skills and map them into abilities over time. Skills live in .agents/skills/, and any SKILL.md file in a subdirectory is automatically discoverable.

Built-in skills

Platform operations are injected during onboarding: pull request creation into pc-ops-ship, the archive PR flow into pc-plan-archive, and pull request review plus issue creation directly into the /ops-review and /ops-backlog command files.

Platform skills ship as suffixed variants (pc-userstory-gh, pc-userstory-az, pc-userstory-jira, pc-userstory-browser) and the installer copies only the matching one, renamed to its generic name.

Rules that are denied, not requested

A rule the harness states as "never" is denied in a plugin hook wherever a predicate over the tool arguments can express it, and stated once next to the mechanism that enforces it. A denied call never runs: the model gets the rule and the fix as the tool result and keeps its turn, so it can adapt rather than stall.

Each guard fails open on its own bug: a guard that breaks the session it is guarding is worse than the rule it enforces. A skill named under ## Abilities but not installed is skipped for the same reason.