@frankzhang2026/opencode-android-orchestrator 0.6.1 → 0.8.0

package/resources/third-party/superpowers-v6.2.0/skills/android-orchestrator-test-driven-development/references/writing-good-tests.md

@@ -0,0 +1,197 @@
+# Writing Good Tests
+
+**Load this reference when:** writing or changing tests, adding mocks, or
+adding cleanup/helper methods for tests.
+
+## Overview
+
+A test exists to catch a specific break. Two principles govern everything
+here:
+
+```
+1. Every test names the break it catches
+2. Every test exercises the real thing
+```
+
+Strict TDD produces both naturally: a test written first and watched
+failing against real code has already proven it can fail, and only earns
+a mock when the real dependency proves slow or external.
+
+## Principle 1: Name the Break
+
+Before writing the test body, answer: **what production change should
+make this test fail — and is that change a bug or a decision?** A test
+earns its place by catching a wrong branch, missing side effect, wrong
+argument, boundary case, or broken contract.
+
+**Derive expectations independently.** Use literals and hand-checked
+fixtures; table-driven tests with literal `want` values are the preferred
+shape. An expectation computed by the code under test — or its helpers —
+passes no matter what that code does:
+
+```typescript
+// ❌ Mirror assertion: the same builder computes both sides — always true
+const expected = buildSearchQuery({ tag: 'urgent' });
+expect(buildSearchQuery({ tag: 'urgent' })).toBe(expected);
+
+// ✅ Hand-derived literal
+expect(buildSearchQuery({ tag: 'urgent' })).toBe('tag:"urgent"');
+```
+
+**No change detectors.** If only intentional decisions can fail a test —
+a constant's value, exact message wording, private structure — it fires
+on redesign and sleeps through bugs. Test the behavior that depends on
+the decision: not `expect(MAX_RETRIES).toBe(5)` but "a failing call is
+retried 5 times and the 6th attempt never happens."
+
+**Behavior, not text.** Asserting that a script, skill, or config
+contains an exact line proves only that the source is the source. Run
+scripts against controlled inputs and assert outputs, side effects, or
+exit codes. Documents that instruct agents are tested by the consuming
+agent's behavior; prose for humans earns no test at all.
+
+**Your code, not the framework.** Test the contract your code makes at
+its boundaries — the route you register, the query you emit, the payload
+you produce. Upstream mechanics are their maintainers' tests to write
+(the classic: asserting your router invokes a registered handler — that
+is the framework's test, not yours). When upstream behavior genuinely
+surprised you, write one narrow characterization test naming the
+assumption. The same boundary applies inside your code: constructors,
+getters, constants, and trivial forwarding earn tests only when they
+validate, normalize, default, derive, enforce, or cause side effects —
+otherwise assert the first consumer-visible result that depends on them.
+
+### Gate Function
+
+```
+BEFORE writing the test body:
+  Name the production change that would make this test fail.
+
+  Cannot name one            → redesign around an observable behavior
+  "The source text changed"  → run the artifact and assert its effects
+  Only intentional decisions → change detector; test the behavior
+                               that depends on the decision
+
+  Confirm the expected value is derived without the code under test.
+  IF it reuses the code's logic or helpers:
+    Replace it with a literal or hand-checked fixture
+```
+
+## Principle 2: Exercise the Real Thing
+
+**The mock earns no assertions.** A mock assertion passes when the mock
+is present and fails when it is absent — it says nothing about the
+component. Assert the real component's behavior; if the mock is what you
+are checking, unmock it or delete the assertion.
+
+```typescript
+// ✅ Real behavior
+expect(screen.getByRole('navigation')).toBeInTheDocument();
+
+// ❌ Mock existence
+expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();
+```
+
+**your human partner's correction:** "Are we testing the behavior of a
+mock?"
+
+**Mock at the right level.** Learn every side effect of the real method
+before replacing it; mock the slow or external operation and keep what
+the test depends on real. When unsure, run the test against the real
+implementation first and observe what actually needs to happen.
+
+```typescript
+// ❌ The mock swallows the config write that duplicate detection reads
+vi.mock('ToolCatalog', () => ({
+  discoverAndCacheTools: vi.fn().mockResolvedValue(undefined)
+}));
+
+// ✅ Mock only the slow server startup; the config write stays real
+vi.mock('MCPServerManager');
+```
+
+**Make doubles specific.** When arguments, call counts, or ordering are
+part of the contract, assert them — a fake that accepts anything verifies
+nothing. Give each branch (success, error, malformed) its own fixture or
+spy, so the wrong branch cannot satisfy the expectation.
+
+**Mirror real data completely.** Mock the complete structure as it exists
+in reality — all documented fields — not just the ones your test reads.
+Partial mocks fail silently when downstream code reads an omitted field:
+the test passes while integration breaks.
+
+**Production classes carry production methods only.** Cleanup that only
+tests need lives in test utilities, never as a `destroy()` on the
+production class. Ask: is this method called only from tests? Does this
+class own this resource's lifecycle? Wrong answers → test utility.
+
+**Prefer real components over complex mocks.** When mock setup outgrows
+the test logic, mocks miss methods the real components have, or tests
+break when the mock changes, switch to an integration test with real
+components. **your human partner's question:** "Do we need to be using a
+mock here?"
+
+### Gate Function
+
+```
+BEFORE adding a mock or test helper:
+  List the real method's side effects; keep the ones the test
+  depends on real — mock the slow/external level below them.
+
+  Mock responses mirror the complete real structure.
+
+  A method only tests call lives in test utilities, not production.
+
+  About to assert on the mock itself?
+    Unmock it or delete the assertion.
+```
+
+## Tests Ship With the Implementation
+
+The TDD cycle — failing test, minimal implementation, refactor — is what
+"complete" means. Ship the tests the behavior needs and only those:
+trivial code and human prose earn none, and a test written to satisfy
+process costs maintenance forever.
+
+## The Mutation Check
+
+Before finishing, mentally mutate the production code; at least one test
+should fail for each realistic mutation:
+
+- Wrong constant or argument
+- Wrong branch handler
+- Missing state change or side effect
+- Empty or default return
+- Missing validation for zero, empty, nil, unauthorized, or malformed input
+
+A mutation nothing catches marks the behavior as unprotected — or the
+test as tautological.
+
+## Quick Reference
+
+| When you... | Do |
+|-------------|-----|
+| Write any test | Name the break it catches — a bug, not a decision |
+| Build an expected value | Derive it by hand; never with the code under test |
+| Test a script or document | Run it / pressure-test its consumer; never grep its text |
+| Reach for a dependency test | Test your boundary contract, not their documented mechanics |
+| Want to assert on a mocked element | Test the real component, or unmock it |
+| Are about to mock a method | Learn its side effects; mock the slow/external level |
+| Build a mock response | Mirror the real structure completely |
+| Need cleanup only tests use | Put it in test utilities |
+| Watch mock setup balloon | Switch to an integration test with real components |
+| Finish a test file | Run the mutation check |
+
+## Warning Signs
+
+- Setup and assertion share the same object, guaranteeing equality
+- The test can fail only through a panic, crash, or missing selector
+- The test fails on every intentional change, never on accidental breakage
+- Expected values are hidden behind loops, builders, or helpers
+- The test greps source text, or asserts a removed symbol stays removed
+- The test would still matter if only the framework remained
+- The test exists for coverage, checking no side effect or outcome
+- An assertion checks a `*-mock` test ID, or fails if you remove the mock
+- A method is called only from test files
+- Mock setup is more than half the test, or you can't explain why the mock is needed
+- Mocking "just to be safe"

package/resources/third-party/superpowers-v6.2.0/skills/android-orchestrator-verification-before-completion/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: android-orchestrator-verification-before-completion
+description: Require fresh command evidence before an Android Orchestrator Coder or Reviewer reports completion or approval
+license: MIT
+compatibility: opencode
+metadata:
+  upstream: obra/superpowers@v6.2.0
+  workflow: scheduled-coding
+---
+
+# Verification Before Completion
+
+## Overview
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness

package/resources/third-party/superpowers-v6.2.0/skills/android-orchestrator-writing-plans/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: android-orchestrator-writing-plans
+description: Convert an approved Android Orchestrator proposal into an implementation-ready plan that matches its sealed task contract
+license: MIT
+compatibility: opencode
+metadata:
+  upstream: obra/superpowers@v6.2.0
+  workflow: scheduled-coding
+---
+
+# Android Orchestrator writing plans
+
+Write a plan detailed enough for the restricted Coder to implement without
+guessing. The approved proposal is the scope ceiling.
+
+## Required output
+
+Create only the plan path selected by `scheduled-quality-orchestrator`:
+`docs/plans/<TASK-ID>.md`. The matching JSON contract is created separately at
+`automation/tasks/<TASK-ID>.json`; both artifacts must describe the same task.
+
+The plan must include:
+
+- task ID and title;
+- current and desired observable behavior;
+- acceptance criteria and edge cases;
+- exact files to create or modify;
+- implementation sequence with concrete symbols and interfaces;
+- the first failing behavior test and expected RED reason;
+- focused and full verification commands;
+- allowed paths, forbidden paths, maximum changed-file count, and non-goals;
+- device/emulator policy and any residual risk.
+
+## Plan quality
+
+- Use small ordered steps: test, verify RED, minimal implementation, verify
+  GREEN, then the configured quality gate.
+- Derive expected values independently from production code.
+- Do not use placeholders such as TODO, TBD, “add suitable handling”, or
+  “similar to the previous step”.
+- Keep names, signatures, resources, and paths consistent across every step
+  and with the task contract.
+- Do not introduce unapproved refactors or dependencies.
+
+## Handoff
+
+Do not offer alternate execution modes, dispatch subagents, commit, or start
+implementation. Return control to `scheduled-quality-orchestrator`, which
+validates and seals the plan and contract before the separate Coder and
+Reviewer sessions can run.

package/templates/.opencode/agents/scheduled-coder.md

@@ -77,11 +77,10 @@ permission:
   list: allow
   skill:
     "*": deny
-    "using-superpowers": allow
     "scheduled-quality-coder": allow
-    "test-driven-development": allow
-    "systematic-debugging": allow
-    "verification-before-completion": allow
+    "android-orchestrator-test-driven-development": allow
+    "android-orchestrator-systematic-debugging": allow
+    "android-orchestrator-verification-before-completion": allow
   schedule_job: deny
   list_jobs: deny
   get_version: deny

package/templates/.opencode/agents/scheduled-planner.md

@@ -68,9 +68,8 @@ permission:
   list: allow
   skill:
     "*": deny
-    "using-superpowers": allow
-    "brainstorming": allow
-    "writing-plans": allow
+    "android-orchestrator-brainstorming": allow
+    "android-orchestrator-writing-plans": allow
     "scheduled-quality-orchestrator": allow
   question: allow
   schedule_job: deny
@@ -96,8 +95,9 @@ user provides a natural-language coding request. Remain the conversational
 coordinator through planning, contract approval, unattended execution, final
 human acceptance, and local integration into the recorded original branch.
 
-Load `scheduled-quality-orchestrator`, `brainstorming`, and `writing-plans`
-before taking action, then follow the orchestrator skill literally. Run the
+Load `scheduled-quality-orchestrator`, `android-orchestrator-brainstorming`,
+and `android-orchestrator-writing-plans` before taking action, then follow the
+orchestrator skill literally. Run the
 source preflight before planning. Inspect the current repository code and
 tests, then interactively narrow the request to exactly one small, observable
 behavior change. Ask for clarification when scope, acceptance behavior, edge

package/templates/.opencode/agents/scheduled-reviewer.md

@@ -54,9 +54,8 @@ permission:
   list: allow
   skill:
     "*": deny
-    "using-superpowers": allow
     "scheduled-quality-reviewer": allow
-    "verification-before-completion": allow
+    "android-orchestrator-verification-before-completion": allow
   schedule_job: deny
   list_jobs: deny
   get_version: deny

package/templates/.opencode/skills/scheduled-quality-coder/SKILL.md

@@ -9,8 +9,8 @@ metadata:
 
 # Scheduled quality coder
 
-Execute one task contract. This skill narrows Superpowers into a deterministic,
-non-interactive Android workflow. The scripts are the source of truth for state;
+Execute one task contract through the bundled, deterministic, non-interactive
+Android workflow. The scripts are the source of truth for state;
 your prose is never proof of completion.
 
 ## Required input
@@ -28,17 +28,18 @@ it with `./scripts/automation/block-task.sh <TASK-ID> <reason>` before stopping.
 
 ## Mandatory sequence
 
-1. Load `test-driven-development` and
-   `verification-before-completion`. Do not load any other implementation
+1. Load `android-orchestrator-test-driven-development` and
+   `android-orchestrator-verification-before-completion`. Do not load any other implementation
    workflow skill.
 2. Run `./scripts/automation/status.sh <TASK-ID>` and read the contract.
 3. Branch by deterministic state:
 
    - For `PENDING`, run `./scripts/automation/claim-task.sh <TASK-ID>`. It
      performs preflight, verifies that the only orchestration-visible initial
-     changes are the two sealed, uncommitted planning artifacts, captures the
-     green baseline, and changes the task to `CODING`. The status JSON's
-     `runtime.effectiveWorktreeAllowlist` contains human-owned local paths that
+     changes are the two sealed, uncommitted planning artifacts, captures a
+     green unit-test baseline when `unitTestsEnabled` is true or records the
+     configured skip otherwise, and changes the task to `CODING`. The status
+     JSON's `runtime.effectiveWorktreeAllowlist` contains human-owned local paths that
      are outside the task; do not edit, stage, report, or reason from those
      paths or from `.automation-worktree-allowlist`. Never edit, stage, or
      remove the planning artifacts; the integrator will include them in the
@@ -64,7 +65,7 @@ it with `./scripts/automation/block-task.sh <TASK-ID> <reason>` before stopping.
 7. Run `./scripts/automation/quality-gate.sh <TASK-ID>`.
 8. If the first gate attempt in the current coding cycle fails while state
    remains `CODING`, load
-   `systematic-debugging`, diagnose the root cause, and make at most one fix
+   `android-orchestrator-systematic-debugging`, diagnose the root cause, and make at most one fix
    loop. Then run the gate once more. If it fails again, stop in
    `TEST_FAILED`.
 9. When the gate succeeds, report the changed files and evidence paths. Do not
@@ -91,7 +92,8 @@ human can revise and requeue the contract.
 
 ## Forbidden capabilities
 
-Do not invoke `brainstorming`, `writing-plans`, `using-git-worktrees`,
+Do not invoke `android-orchestrator-brainstorming`,
+`android-orchestrator-writing-plans`, `using-git-worktrees`,
 `finishing-a-development-branch`, `requesting-code-review`, parallel agents, or
 subagent-driven development. Planning and approval happen before this session;
 review happens in a separate fresh read-only session.

package/templates/.opencode/skills/scheduled-quality-orchestrator/SKILL.md

@@ -20,7 +20,8 @@ approvals; state files, hashes, tests, and Git checks grant execution.
    If `ANDROID_HOME` is missing, the working tree is dirty, the branch is detached,
    Git identity is missing, or OpenCode discovery is unsafe, report the exact
    blocker and stop.
-2. Use brainstorming and writing-plans to produce one bounded proposal. After
+2. Use `android-orchestrator-brainstorming` and
+   `android-orchestrator-writing-plans` to produce one bounded proposal. After
    displaying it, immediately call `question` once with `multiple: false` and
    `custom: false`:
 

package/templates/.opencode/skills/scheduled-quality-reviewer/SKILL.md

@@ -15,7 +15,7 @@ you review.
 
 ## Mandatory sequence
 
-1. Load `verification-before-completion`.
+1. Load `android-orchestrator-verification-before-completion`.
 2. Require exactly one task ID or the compatibility token
    `NEXT_REVIEWING`. For the selector token, first run
    `./scripts/automation/select-task.sh REVIEWING` and continue only if
@@ -51,8 +51,9 @@ you review.
 
    `./scripts/automation/submit-review.sh <TASK-ID> CHANGES_REQUESTED <summary>`
 
-   The script reruns the focused tests, full unit suite, debug build, and lint
-   before accepting `APPROVED`, and records that fresh output. Therefore do not
+   The script reruns the focused tests and full unit suite when
+   `unitTestsEnabled` is true, always runs the debug build, runs Android lint
+   when `lintEnabled` is true, and records that fresh output. Therefore do not
    run those Gradle commands separately before an approval submission. Run an
    individual verification command only to diagnose a failed submission, and
    always reserve a step for the final `submit-review.sh` call.

package/templates/README.md

@@ -14,7 +14,7 @@ Migrated template roots:
 - `.opencode/skills`: the three `scheduled-quality-*` skills
 - `scripts/automation`: all 29 deterministic V3 Bash transactions and their
   test runner, preserved as executable files
-- `automation`: the portable V3 configuration render source, both JSON Schemas,
+- `automation`: the portable V4 configuration render source, both JSON Schemas,
   and the task contract example
 - `docs/plans/README.md`: the human-approved plan authoring contract
 - `AGENTS.md.fragment`: a bounded managed block for non-destructive
@@ -38,7 +38,10 @@ adaptive render. This covers product flavors without shipping a project name,
 an absolute configuration path, or a hand-maintained JSON file. The packaged
 matrix remains the deterministic fallback for the read-only planning API;
 callers may still pass an explicit matrix when they intentionally need a custom
-policy.
+policy. Verification switches live in `automation/config.json`:
+`unitTestsEnabled` defaults to true and `lintEnabled` defaults to false.
+Discovered task lists are retained even while their corresponding gate is
+disabled.
 
 After read-only planning succeeds, `init` creates a comment-only
 `.automation-worktree-allowlist` if it is missing and preserves any existing
@@ -47,7 +50,11 @@ resource manifest so its exact-path entries can change without causing package
 integrity drift; failed first-install verification removes a newly bootstrapped
 file during rollback.
 
-The legacy Scheduler field has been removed while Superpowers remains pinned.
+The legacy Scheduler field and external Superpowers plugin dependency have
+been removed. Five namespaced workflow skills are loaded directly from the
+Orchestrator npm package; the optional Superpowers browser companion is not
+distributed.
+
 The scope gates consume generated source-set arrays, and the Shell test fixture
 uses a neutral custom module and package. No shipped template contains a local
 absolute path or project-specific package name.

package/templates/automation/config.json

@@ -1,5 +1,5 @@
 {
-  "schemaVersion": 3,
+  "schemaVersion": 4,
   "enabled": true,
   "mode": "orchestrated",
   "workspaceStrategy": "inPlaceExclusive",
@@ -8,6 +8,8 @@
   "maxFixLoops": 1,
   "maxReviewCycles": 1,
   "maxReviewerRestarts": 2,
+  "unitTestsEnabled": true,
+  "lintEnabled": false,
   "longCommandTimeoutMs": 1800000,
   "autoCleanupWorktrees": true,
   "pushAfterAcceptance": false,
@@ -18,18 +20,15 @@
     "abort": "中止任务，封存修改并恢复原分支。",
     "resume": "恢复任务，重新捕获基线并继续自动执行。"
   },
-  "plugins": {
-    "superpowers": "superpowers@git+https://github.com/obra/superpowers.git#v6.2.0"
-  },
   "requiredSkills": [
-    "brainstorming",
-    "writing-plans",
+    "android-orchestrator-brainstorming",
+    "android-orchestrator-writing-plans",
     "scheduled-quality-orchestrator",
     "scheduled-quality-coder",
     "scheduled-quality-reviewer",
-    "test-driven-development",
-    "systematic-debugging",
-    "verification-before-completion"
+    "android-orchestrator-test-driven-development",
+    "android-orchestrator-systematic-debugging",
+    "android-orchestrator-verification-before-completion"
   ],
   "gradleVerification": {
     "fullUnitTestTasks": [

package/templates/automation/config.schema.json

@@ -1,6 +1,6 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "urn:frankzhang2026:opencode-android-orchestrator:automation-config:v3",
+  "$id": "urn:frankzhang2026:opencode-android-orchestrator:automation-config:v4",
   "title": "OpenCode task orchestration configuration",
   "type": "object",
   "additionalProperties": false,
@@ -36,18 +36,19 @@
     "maxFixLoops",
     "maxReviewCycles",
     "maxReviewerRestarts",
+    "unitTestsEnabled",
+    "lintEnabled",
     "longCommandTimeoutMs",
     "autoCleanupWorktrees",
     "pushAfterAcceptance",
     "approvalPhrases",
-    "plugins",
     "requiredSkills",
     "gradleVerification",
     "androidProject",
     "protectedPaths"
   ],
   "properties": {
-    "schemaVersion": { "const": 3 },
+    "schemaVersion": { "const": 4 },
     "enabled": { "type": "boolean" },
     "mode": { "enum": ["shadow", "orchestrated"] },
     "workspaceStrategy": {
@@ -58,6 +59,8 @@
     "maxFixLoops": { "type": "integer", "minimum": 0, "maximum": 1 },
     "maxReviewCycles": { "type": "integer", "minimum": 0, "maximum": 2 },
     "maxReviewerRestarts": { "type": "integer", "minimum": 0, "maximum": 3 },
+    "unitTestsEnabled": { "type": "boolean", "default": true },
+    "lintEnabled": { "type": "boolean", "default": false },
     "longCommandTimeoutMs": {
       "type": "integer",
       "minimum": 120000,
@@ -77,14 +80,6 @@
         "resume": { "type": "string", "minLength": 4 }
       }
     },
-    "plugins": {
-      "type": "object",
-      "additionalProperties": false,
-      "required": ["superpowers"],
-      "properties": {
-        "superpowers": { "type": "string", "minLength": 1 }
-      }
-    },
     "requiredSkills": {
       "type": "array",
       "minItems": 6,