@syntesseraai/opencode-feature-factory 0.13.4 → 0.13.6

package/AGENTS.md

@@ -9,10 +9,10 @@ This file is installed to `~/.config/opencode/AGENTS.md` by `@syntesseraai/openc
 - Stage sub-agents with default model routing:
   - `planning` -> `openai/gpt-5.5-fast` (temperature `0.2`)
   - `building` -> `openai/gpt-5.5-fast` (temperature `0.5`)
-  - `code-review` -> `openai/gpt-5.5-fast` (temperature `0.6`)
+  - `code-reviewing` -> `openai/gpt-5.5-fast` (temperature `0.6`)
   - `documenting` -> `github-copilot/gemini-3.1-pro-preview`
-  - `full-review` -> `opencode/glm-5.1`
-- Specialized agents: `feature-factory`, `planning`, `building`, `code-review`, `documenting`, and `full-review`.
+  - `full-reviewing` -> `opencode/glm-5.1`
+- Specialized agents: `feature-factory`, `planning`, `building`, `code-reviewing`, `documenting`, and `full-reviewing`.
 - Quick commands: `/ff-review [optional prompt]`, `/ff-document [optional prompt]`, and `/ff-rework [optional prompt]` (all run as main agents on the relevant stage).
 - Skills for planning, shared external research (`ff-research-methods`), command output compression (`ff-oo`), documentation governance (`ff-documentation-rules`), review quality/security/architecture/documentation, GitHub workflows (`ff-github`), reporting templates, and todo management.
 
@@ -23,10 +23,10 @@ This file is installed to `~/.config/opencode/AGENTS.md` by `@syntesseraai/openc
 3. Once scope is clear, summarize it in 1-3 bullets; clear imperative requests count as authorization to proceed without a separate confirmation or plan-approval prompt.
 4. Build.
 5. Code Review.
-6. If code-review feedback requires changes, route back to Build.
+6. If code-reviewing feedback requires changes, route back to Build.
 7. Document.
 8. Full Review for combined implementation and documentation gates.
-9. If either full-review gate is not approved, route back to Build; finish only when code-review and full-review gates are approved and no addressable follow-ups remain.
+9. If either full-reviewing gate is not approved, route back to Build; finish only when code-reviewing and full-reviewing gates are approved and no addressable follow-ups remain.
 
 Each transition carries forward the complete previous-stage last message as `RAW_PREVIOUS_STAGE_OUTPUT` by default. Parsed fields such as `FINAL_PLAN` guide routing and task ordering, but they do not replace the raw stage output. This preserves full context, rationale, and findings between stages. If context limits require truncation, explicitly label the truncation and preserve required gate/status lines and required output sections.
 
@@ -45,8 +45,8 @@ When work changes behavior, workflows, configuration, operational guidance, or r
 - Keep `read`/`glob`/`grep` as fallback when codebase-memory MCP is unavailable or the repository has not been indexed.
 - Use `read`, `glob`, and `grep` for targeted file inspection.
 - Writable agents should prefer native `edit` for file updates.
-- Keep `edit` restricted on read-only agents (`planning`, `code-review`, `full-review`).
-- Prefer explicit agent frontmatter permission restrictions for read-only stages. `code-review` and `full-review` now use `permissions` blocks with deny-first `bash` policies to provide constrained shell access where supported.
+- Keep `edit` restricted on read-only agents (`planning`, `code-reviewing`, `full-reviewing`).
+- Prefer explicit agent frontmatter restrictions for read-only stages. `code-reviewing` uses `permissions` with a deny-first `bash` policy; `full-reviewing` uses legacy `tools` disablement for GLM compatibility until that model path supports `permissions`.
 - Keep read-only agents from modifying files by disabling `edit` and other write-capable tools in frontmatter.
 - Explicitly disable PTY tools (`pty_spawn`, `pty_write`, `pty_read`, `pty_list`, `pty_kill`) on read-only agents; they must not rely on PTY as a back door.
 - Use `todowrite` for multi-step tasks to keep progress visible.

package/README.md

@@ -60,10 +60,10 @@ Instead, the `feature-factory` primary agent orchestrates workflows natively by
 
 - `feature-factory` (orchestrator) -> default model `openai/gpt-5.5-fast`
   - `planning` -> default model `openai/gpt-5.5-fast`
-- `building` -> default model `openai/gpt-5.5-fast`
-  - `code-review` -> default model `openai/gpt-5.5-fast` with temperature `0.6`
+  - `building` -> default model `openai/gpt-5.5-fast`
+  - `code-reviewing` -> default model `openai/gpt-5.5-fast` with temperature `0.6`
   - `documenting` -> default model `github-copilot/gemini-3.1-pro-preview`
-  - `full-review` -> default model `opencode/glm-5.1`
+  - `full-reviewing` -> default model `opencode/glm-5.1`
 
 ### Fixed execution path
 
@@ -87,14 +87,14 @@ The same rule applies to imperative follow-on requests derived from prior workfl
 
 Writable stage agents (`building`, `documenting`) prefer native `edit` (and `write` for new files) when needed. Read-only agents keep `edit` disabled.
 
-Stage-agent code discovery is graph-first: planning/building/code-review/documenting/full-review prefer codebase-memory MCP tools (`codebase-memory-mcp_search_graph`, `codebase-memory-mcp_get_architecture`, `codebase-memory-mcp_trace_call_path`, `codebase-memory-mcp_get_code_snippet`) for repository-local analysis, and use `gh_grep_searchGitHub` when investigating public GitHub source examples.
+Stage-agent code discovery is graph-first: planning/building/code-reviewing/documenting/full-reviewing prefer codebase-memory MCP tools (`codebase-memory-mcp_search_graph`, `codebase-memory-mcp_get_architecture`, `codebase-memory-mcp_trace_call_path`, `codebase-memory-mcp_get_code_snippet`) for repository-local analysis, and use `gh_grep_searchGitHub` when investigating public GitHub source examples.
 
 ### Agent tool-access policy
 
 Feature Factory agent assets primarily use OpenCode agent frontmatter to keep stage capabilities explicit.
 
-- `code-review` and `full-review` use `permissions` blocks with constrained command-level bash access.
-- `code-review` and `full-review` remain read-only by disabling `write`, `edit`, `task`, and all PTY tools; bash is deny-by-default with only `oo git status` / `oo git diff` patterns explicitly allowed.
+- `code-reviewing` uses `permissions` with constrained command-level bash access; `full-reviewing` uses legacy `tools` disablement for GLM compatibility.
+- `code-reviewing` remains read-only with deny-by-default bash and only `oo git status` / `oo git diff` patterns explicitly allowed; `full-reviewing` remains read-only by disabling `write`, `edit`, `task`, `bash`, and all PTY tools through `tools`.
 - Other stage agents may still use more granular permission-based shell allowances where model compatibility allows it.
 
 ### Plugin auto-handoff safety net
@@ -120,7 +120,7 @@ The plugin includes an auto-handoff hook that continues deterministic next steps
 The plugin installs global custom slash commands in `~/.config/opencode/commands/`:
 
 - `/ff-review [optional prompt]`
-  - Agent: `full-review`
+  - Agent: `full-reviewing`
   - Subtask: `false` (runs as a main agent)
   - Mode: manual standalone helper (does not continue the full pipeline automatically)
   - Default prompt when no argument is provided: `Review the changes so far`

package/agents/building.md

@@ -10,8 +10,8 @@ permissions:
   skill:
     '*': allow
   task:
-    code-review: allow
-    full-review: allow
+    code-reviewing: allow
+    full-reviewing: allow
     planning: allow
     explore: allow
   bash:
@@ -26,11 +26,6 @@ permissions:
 
 You are the building specialist.
 
-## Reasoning Depth
-
-- Use the highest available reasoning depth for the configured model.
-- Take extra deliberation before applying edits, choosing validations, and closing implementation scope.
-
 ## Core Role
 
 - Implement approved plan steps in safe, dependency-aware order.
@@ -42,7 +37,7 @@ You are the building specialist.
 - Use normalized, resolved stage handoff context from prior-stage output or existing context.
 - Treat `RAW_PREVIOUS_STAGE_OUTPUT` from Planning as the authoritative full plan context when present. Read the requirements summary, architecture validation, risks, assumptions, testing strategy, and plan-shaping rationale before implementing.
 - Use `FINAL_PLAN` for implementation task ordering, but do not ignore non-`FINAL_PLAN` planning context.
-- For code-review→build or full-review→build rework loops, `RAW_PREVIOUS_STAGE_OUTPUT` contains the full review last message. Preserve and follow that full review output alongside consolidated action bullets so findings, rationale, and gate context are not lost.
+- For code-reviewing→build or full-reviewing→build rework loops, `RAW_PREVIOUS_STAGE_OUTPUT` contains the full review last message. Preserve and follow that full review output alongside consolidated action bullets so findings, rationale, and gate context are not lost.
 - Never rely on unresolved placeholder aliases in handoff prompts.
 - Do not rely on intermediate artifact files for pipeline progression.
 - Persist only when explicitly requested by the user.
@@ -114,8 +109,8 @@ When implementation work changes behavior, workflows, commands, configuration, o
 
 ## Delegation Guidance
 
-- `@code-review`: focused implementation validation before documentation.
-- `@full-review`: comprehensive final validation (code, security, architecture, docs, acceptance).
+- `@code-reviewing`: focused implementation validation before documentation.
+- `@full-reviewing`: comprehensive final validation (code, security, architecture, docs, acceptance).
 - `@planning`: only when requirements become ambiguous during implementation.
 
 ## External Research

package/agents/{code-review.md → code-reviewing.md}

@@ -22,19 +22,14 @@ permissions:
 temperature: 0.6
 ---
 
-You are the code-review specialist.
-
-## Reasoning Depth
-
-- Use the highest available reasoning depth for the configured model.
-- Take extra deliberation before assigning severity, confidence, and gate outcomes.
+You are the code-reviewing specialist.
 
 ## Core Role
 
 - Validate implementation outputs before documentation begins.
 - Apply code-focused scope based on context: acceptance, code quality, security, architecture, regression risk, and test coverage.
 - Return actionable findings with severity and confidence.
-- Do not block on missing documentation updates; documentation completeness is validated by `@full-review` after the documenting stage.
+- Do not block on missing documentation updates; documentation completeness is validated by `@full-reviewing` after the documenting stage.
 
 ## File Review Guidance
 
@@ -107,8 +102,8 @@ When acting as code gate reviewer, output status line exactly:
 
 - Use normalized, resolved handoff context (summary/status/action items/issues plus full resolved prior output by default) rather than file-based artifacts.
 - Treat `RAW_PREVIOUS_STAGE_OUTPUT` from Building as the complete build last message unless it is explicitly labeled as truncated.
-- In code-review→build rework loops, return findings with enough context for Build to receive the full review output, not only consolidated action bullets.
+- In code-reviewing→build rework loops, return findings with enough context for Build to receive the full review output, not only consolidated action bullets.
 - Never rely on unresolved placeholder aliases in handoff prompts.
 - Keep reports concise, evidence-based, and directly actionable for implementation follow-up.
-- Do not delegate to implementation stages from code-review mode.
-- Never perform implementation or file-modifying work in code-review mode.
+- Do not delegate to implementation stages from code-reviewing mode.
+- Never perform implementation or file-modifying work in code-reviewing mode.

package/agents/documenting.md

@@ -14,7 +14,7 @@ permissions:
   skill:
     '*': allow
   task:
-    full-review: allow
+    full-reviewing: allow
     explore: allow
   bash:
     '*': ask
@@ -28,11 +28,6 @@ permissions:
 
 You are the documenting specialist.
 
-## Reasoning Depth
-
-- Use the highest available reasoning depth for the configured model.
-- Take extra deliberation to ensure behavior-to-documentation alignment and cross-doc consistency.
-
 ## Core Role
 
 - Translate shipped behavior into documentation that is accurate, navigable, and useful for future readers.
@@ -157,7 +152,7 @@ Update documentation in the same change whenever you modify:
 1. Do not change product behavior while editing docs.
 2. Update all impacted docs, indexes, and `README.md` navigation — not just one file.
 3. Preserve or improve discoverability; every new or moved doc must be reachable through the index chain.
-4. Escalate ambiguous behavior or conflicting sources to `@full-review`.
+4. Escalate ambiguous behavior or conflicting sources to `@full-reviewing`.
 
 ## Required Output Sections
 

package/agents/feature-factory.md

@@ -16,8 +16,8 @@ permissions:
     '*': allow
   task:
     building: allow
-    code-review: allow
-    full-review: allow
+    code-reviewing: allow
+    full-reviewing: allow
     planning: allow
     documenting: allow
 ---
@@ -40,10 +40,10 @@ For any substantive user request, prefer sub-agent execution over direct handlin
 
 - `@planning`: clarify scope, risks, assumptions, and produce `FINAL_PLAN`. The full planning response is downstream context; `FINAL_PLAN` is a structured section, not the only handoff content.
 - `@building`: implement code changes, run commands/tests, and report results.
-- `@code-review`: perform first-pass implementation validation and return the code-review gate.
+- `@code-reviewing`: perform first-pass implementation validation and return the code-review gate.
 - `@documenting`: update docs to match shipped behavior after code-review approval.
-- `@full-review`: validate implementation and documentation together for final gates.
-- Do not use built-in `@explore`; route exploration-like investigation and validation work to `@code-review` or `@full-review`.
+- `@full-reviewing`: validate implementation and documentation together for final gates.
+- Do not use built-in `@explore`; route exploration-like investigation and validation work to `@code-reviewing` or `@full-reviewing`.
 - Do not use built-in `@general`; route general implementation, maintenance, and rework to `@building`.
 - For external dependency or standards uncertainty, instruct stage agents to load the shared `ff-research-methods` skill.
 
@@ -162,7 +162,7 @@ CURRENT_STAGE_OBJECTIVE:
 
 Never pass unresolved placeholder aliases (for example unresolved result-alias syntax) in stage handoff prompts.
 
-`RAW_PREVIOUS_STAGE_OUTPUT` is the complete previous-stage last message by default. Parsed summaries, action items, open issues, gates, verdicts, and `FINAL_PLAN` are routing aids and quick references; they must not replace the raw prior-stage context. Preserve full outputs for planning -> building, building -> code-review, code-review -> building rework, code-review -> documenting, documenting -> full-review, and full-review -> build rework loops so downstream agents retain discovered context, rationale, assumptions, validations, and findings.
+`RAW_PREVIOUS_STAGE_OUTPUT` is the complete previous-stage last message by default. Parsed summaries, action items, open issues, gates, verdicts, and `FINAL_PLAN` are routing aids and quick references; they must not replace the raw prior-stage context. Preserve full outputs for planning -> building, building -> code-reviewing, code-reviewing -> building rework, code-reviewing -> documenting, documenting -> full-reviewing, and full-reviewing -> build rework loops so downstream agents retain discovered context, rationale, assumptions, validations, and findings.
 
 Only truncate `RAW_PREVIOUS_STAGE_OUTPUT` when platform context limits make the full prior-stage output impossible to include. If truncation is unavoidable, clearly label it as truncated, preserve all required gate/status lines and required output sections, and summarize omitted content without presenting the summary as the full raw output.
 
@@ -205,14 +205,14 @@ When planning is approved, parse `PLANNING_GATE` and `FINAL_PLAN` for routing an
 For each iteration `n`:
 
 1. Call `@building {as:build_iter_n}` using full `RAW_PREVIOUS_STAGE_OUTPUT`, `FINAL_PLAN` task ordering, and prior action items.
-2. Call `@code-review {as:code_review_iter_n}` for implementation review with full Build output preserved.
+2. Call `@code-reviewing {as:code_review_iter_n}` for implementation review with full Build output preserved.
 3. Read code-review gate lines exactly as:
    - `CODE_REVIEW_GATE=APPROVED|REWORK|ESCALATE`
 4. If `CODE_REVIEW_GATE=REWORK`, route back to Build with consolidated code-review action items and the full Code Review output preserved as raw rework context.
 5. If `CODE_REVIEW_GATE=ESCALATE`, stop and escalate to the user with the full Code Review output preserved.
 6. If `CODE_REVIEW_GATE=APPROVED` but explicit addressable `OPEN_ISSUES`, `NON_BLOCKING_ISSUES`, action items, minor issues, or non-blocking follow-ups remain, route back to Build with consolidated code-review action items and the full Code Review output preserved as raw rework context.
 7. Call `@documenting {as:doc_iter_n}` using the full Build output plus approved Code Review output as `RAW_PREVIOUS_STAGE_OUTPUT` and current implementation context.
-8. Call `@full-review {as:full_review_iter_n}` for combined implementation and documentation review with full Documentation output and relevant Build and Code Review context preserved.
+8. Call `@full-reviewing {as:full_review_iter_n}` for combined implementation and documentation review with full Documentation output and relevant Build and Code Review context preserved.
 9. Read full-review gate lines exactly as:
    - `REVIEW_GATE=APPROVED|REWORK|ESCALATE`
    - `DOCUMENTATION_GATE=APPROVED|REWORK|ESCALATE`
@@ -285,7 +285,7 @@ Rules:
 - Omit `RECOMMENDED_NEXT_STEP` when the recommendation is "None", "Nothing", "No further steps", or similar.
 - In the fixed workflow, successful Build continues to Code Review; approved Code Review continues to Document; successful Document continues to Full Review.
 - Successful Build, approved Code Review, and successful Document are stage-complete but not workflow-complete, so they normally require `RECOMMENDED_NEXT_STEP`.
-- For normal workflow progression, continue by delegating to stage agents directly (`@building`, `@code-review`, `@documenting`, `@full-review`), not by invoking slash commands such as `/ff-review`, `/ff-document`, or `/ff-rework`.
+- For normal workflow progression, continue by delegating to stage agents directly (`@building`, `@code-reviewing`, `@documenting`, `@full-reviewing`), not by invoking slash commands such as `/ff-review`, `/ff-document`, or `/ff-rework`.
 
 Examples:
 

package/agents/{full-review.md → full-reviewing.md}

@@ -3,30 +3,20 @@ description: Full validation agent for code and documentation. Performs acceptan
 mode: subagent
 color: '#8b5cf6'
 model: opencode/glm-5.1
-permissions:
-  write: deny
-  edit: deny
-  task:
-    '*': deny
-  bash:
-    '*': deny
-    'oo git status': allow
-    'oo git status *': allow
-    'oo git diff': allow
-    'oo git diff *': allow
-  pty_spawn: deny
-  pty_write: deny
-  pty_read: deny
-  pty_list: deny
-  pty_kill: deny
+tools:
+  write: false
+  edit: false
+  apply_patch: false
+  bash: false
+  task: false
+  pty_spawn: false
+  pty_write: false
+  pty_read: false
+  pty_list: false
+  pty_kill: false
 ---
 
-You are the full-review specialist.
-
-## Reasoning Depth
-
-- Use the highest available reasoning depth for the configured model.
-- Take extra deliberation before assigning severity, confidence, and gate outcomes.
+You are the full-reviewing specialist.
 
 ## Core Role
 
@@ -107,7 +97,7 @@ For external/library uncertainty needed to validate findings, load and follow `f
 
 ## Gate Contract
 
-When acting as full-review gate reviewer, output status lines exactly:
+When acting as full-reviewing gate reviewer, output status lines exactly:
 
 - `REVIEW_GATE=APPROVED|REWORK|ESCALATE`
 - `DOCUMENTATION_GATE=APPROVED|REWORK|ESCALATE`
@@ -116,8 +106,8 @@ When acting as full-review gate reviewer, output status lines exactly:
 
 - Use normalized, resolved handoff context (summary/status/action items/issues plus full resolved prior output by default) rather than file-based artifacts.
 - Treat `RAW_PREVIOUS_STAGE_OUTPUT` as the complete prior-stage last message unless it is explicitly labeled as truncated. Preserve the full Documentation output plus relevant Build and Code Review context.
-- In full-review→build rework loops, return findings with enough context for Build to receive the full review output, not only consolidated action bullets.
+- In full-reviewing→build rework loops, return findings with enough context for Build to receive the full review output, not only consolidated action bullets.
 - Never rely on unresolved placeholder aliases in handoff prompts.
 - Keep reports concise, evidence-based, and directly actionable for implementation follow-up.
-- Do not delegate to implementation stages from full-review mode.
-- Never perform implementation or file-modifying work in full-review mode.
+- Do not delegate to implementation stages from full-reviewing mode.
+- Never perform implementation or file-modifying work in full-reviewing mode.

package/agents/planning.md

@@ -30,11 +30,6 @@ permissions:
 
 You are the planning specialist.
 
-## Reasoning Depth
-
-- Use the highest available reasoning depth for the configured model.
-- Take extra deliberation before finalizing scope, risks, and gate decisions.
-
 ## Core Role
 
 - Produce clear, implementation-ready plans.
@@ -117,7 +112,7 @@ When producing plans, include:
 
 ## Delegation Guidance
 
-- Do not delegate to `@building`, `@code-review`, `@documenting`, `@full-review`, `@planning`, or `@explore`.
+- Do not delegate to `@building`, `@code-reviewing`, `@documenting`, `@full-reviewing`, `@planning`, or `@explore`.
 - Never perform implementation or file-modifying work in planning mode.
 
 ## Gate Contract

package/bin/ff-deploy.js

@@ -475,8 +475,8 @@ async function deploy() {
       console.log('   - Restart OpenCode or run /reload to load new agents and commands');
       console.log('   - Use @planning to create implementation plans');
       console.log('   - Use @building to execute plans');
-      console.log('   - Use @code-review for first-pass code validation');
-      console.log('   - Use @full-review for combined code and documentation validation');
+      console.log('   - Use @code-reviewing for first-pass code validation');
+      console.log('   - Use @full-reviewing for combined code and documentation validation');
       console.log('   - Use /ff-review, /ff-document, or /ff-rework for quick subtask runs');
       console.log('   - Load ff-research-methods in stage agents for external research');
     }

package/commands/ff-review.md

@@ -1,6 +1,6 @@
 ---
 description: Quick review helper (defaults to "Review the changes so far")
-agent: full-review
+agent: full-reviewing
 subtask: false
 ---
 

package/dist/agent-config.d.ts

@@ -1,11 +1,11 @@
 /**
  * Built-in opencode agents that should be disabled when the Feature Factory
  * plugin is active. These are the standard opencode agents that overlap with
- * the plugin's own agents (planning, building, code-review, full-review) or should be routed
+ * the plugin's own agents (planning, building, code-reviewing, full-reviewing) or should be routed
  * through Feature Factory stage agents instead.
  *
  * Note: This disables built-in `build`, `plan`, `explore`, and `general` agents.
- * The plugin's own agents (planning, building, code-review, full-review) remain active.
+ * The plugin's own agents (planning, building, code-reviewing, full-reviewing) remain active.
  */
 export declare const DEFAULT_DISABLED_AGENTS: Record<string, {
     disable: boolean;

package/dist/agent-config.js

@@ -1,11 +1,11 @@
 /**
  * Built-in opencode agents that should be disabled when the Feature Factory
  * plugin is active. These are the standard opencode agents that overlap with
- * the plugin's own agents (planning, building, code-review, full-review) or should be routed
+ * the plugin's own agents (planning, building, code-reviewing, full-reviewing) or should be routed
  * through Feature Factory stage agents instead.
  *
  * Note: This disables built-in `build`, `plan`, `explore`, and `general` agents.
- * The plugin's own agents (planning, building, code-review, full-review) remain active.
+ * The plugin's own agents (planning, building, code-reviewing, full-reviewing) remain active.
  */
 export const DEFAULT_DISABLED_AGENTS = {
     build: { disable: true },

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "@syntesseraai/opencode-feature-factory",
-  "version": "0.13.4",
+  "version": "0.13.6",
   "type": "module",
   "description": "OpenCode plugin for Feature Factory agents - provides sub-agents and skills for validation, review, security, and architecture assessment",
   "license": "MIT",

package/skills/ff-reviewing-architecture/SKILL.md

@@ -10,7 +10,7 @@ metadata:
 
 # Reviewing Architecture Skill
 
-Use this skill when `@code-review` or `@full-review` evaluates architectural quality and system-level trade-offs.
+Use this skill when `@code-reviewing` or `@full-reviewing` evaluates architectural quality and system-level trade-offs.
 
 ## Focus Areas
 

package/skills/ff-reviewing-code-quality/SKILL.md

@@ -10,7 +10,7 @@ metadata:
 
 # Reviewing Code Quality Skill
 
-Use this skill when `@code-review` or `@full-review` is validating implementation quality.
+Use this skill when `@code-reviewing` or `@full-reviewing` is validating implementation quality.
 
 ## Focus Areas
 

package/skills/ff-reviewing-documentation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ff-reviewing-documentation
-description: Documentation validation checklist for full-review agents. Use for accuracy, completeness, and repository consistency checks.
+description: Documentation validation checklist for full-reviewing agents. Use for accuracy, completeness, and repository consistency checks.
 license: MIT
 compatibility: opencode
 metadata:
@@ -10,7 +10,7 @@ metadata:
 
 # Reviewing Documentation Skill
 
-Use this skill when `@full-review` validates documentation-stage outputs.
+Use this skill when `@full-reviewing` validates documentation-stage outputs.
 
 ## Focus Areas
 

package/skills/ff-reviewing-security/SKILL.md

@@ -10,7 +10,7 @@ metadata:
 
 # Reviewing Security Skill
 
-Use this skill when `@code-review` or `@full-review` performs security-focused validation.
+Use this skill when `@code-reviewing` or `@full-reviewing` performs security-focused validation.
 
 ## Focus Areas