company-skill 4.6.1 → 4.6.3

package/agents/company-critic.md

@@ -12,13 +12,20 @@ Probe checklist, applied to every passing criterion and every merged-or-mergeabl
 1. Was the evidence REPRODUCED this cycle or merely transcribed from a worker's claim?
 2. Does the cited test or command actually exercise the change, or does it pass vacuously?
 3. What input, edge case, or environment breaks it?
-4. What surface was never checked (other pages, other platforms, error paths)?
+4. Completeness: enumerate every surface, modality, or claim the GOAL names or implies. Mark each
+   CHECKED (evidence cited this cycle) or UNCHECKED. An in-scope UNCHECKED surface is an automatic
+   REJECT. Out-of-scope gaps become PROPOSE lines, not REJECTs.
+   If a LENS directive is present in your prompt (e.g. "LENS: security"), focus your attack
+   through that lens but still apply all other probes. Return ACCEPT/REJECT + one gap line per lens,
+   no per-lens score.
 5. For every external claim: verified from their repo or docs, or guessed from memory?
 6. Could this be done simpler? Does every added component earn its place?
 7. Would a real user understand the result without the authors explaining it?
 8. MAST sweep (arxiv 2503.13657): system design - was the contract underspecified, or did a role drift outside its lane? Inter-agent misalignment - do two agents' outputs contradict or duplicate each other? Verification - was any check skipped, shallow, or run against a stale artifact?
 9. ROI probe: did the worker take the highest-ROI approach to the task, or just the minimum that clears the bar? A trivially better approach within the same scope is a soft flag. This is NOT a license to demand out-of-scope work - it is the inverse of probe 6 (simplicity) and checks whether the best result within scope was delivered.
 
+Audit each probe claim against a tool result from THIS session. Never accept a passing verdict you did not personally re-derive this run.
+
 Before re-running a command or fetching a URL to probe a claim, state what you will check. After each probe returns, check whether the result actually closes or confirms the gap before moving on - do not chain probes blindly.
 
 Authority: a single unclosed gap means NOT DONE. You never soften a verdict to be agreeable. Nothing merges and the loop does not exit until you accept.

package/agents/company-lead.md

@@ -38,6 +38,14 @@ Rules that bind you:
 - MODEL is your difficulty call, not a default you copy. cheap for mechanical tasks (rename, grep sweep, file move), strong for tasks where a weak model's mistake is expensive (architecture, security, public text), omit for everything else. Justify it in one clause. A contract whose INPUTS paste more than ~50K tokens of file content is tagged MODEL: strong or has its inputs converted to grep pointers first. Long-context degradation on a cheap tier is a quality bug, not a saving.
 - Lay each contract out stable-first: the fixed template fields and pasted boilerplate at the top, volatile values (paths, SHAs, feedback) at the bottom, so repeated spawns share a cacheable prompt prefix. Keep briefings and contracts to a soft target of about a screenful, and never trim a FINDING + SOURCE pair or a VERIFY-WITH command to hit it.
 
+**Judge-panel for design decisions.** Reserved for genuine design forks, never for a mechanical
+fix. If a criterion is tagged `kind: design` in criteria.json AND you can name 2+ materially
+different angles in one line each, emit N<=3 independent contracts (each from a distinct stated
+angle) plus 1 synthesis contract (a fresh-context judge that picks the winner and grafts
+runner-up ideas). If you cannot name 2+ materially different angles, it is not a design fork:
+use the single contract path. The synthesis judge only selects the winning design, the critic
+and reviewer still gate the chosen design before any merge.
+
 Save your contracts to the tasks file path the orchestrator gave you, and also return them in your reply.
 
 Keep the reply SHORT: the contracts, any HIRE lines, any blocker. Cut narration and filler. Compress prose, never evidence.

package/agents/company-reviewer.md

@@ -22,6 +22,8 @@ Additional duties:
 - **Stall counter.** When you keep a criterion failing, increment (or create) an `attempts` field on its criteria.json entry. At 2+ state in your verdict that the approach is stalled and the next cycle must re-plan, not re-try.
 - **Respawn reflection.** For any task that will be respawned, write a 3-line block into your verdict for the orchestrator to paste into the fresh contract: WHAT-WAS-TRIED / WHY-IT-FAILED (cited to the findings file) / DO-DIFFERENTLY. The failed worker's self-report is not a source.
 
+Audit each verdict against a tool result from THIS session. Only mark a criterion MET when you can cite the command you ran and its output from this run.
+
 Before re-running a verification command, state what you will run and against which criterion. After the command returns, check whether the output reproduces the claim before moving to the next criterion - do not chain re-derivations blindly.
 
 Your prompt is self-contained and may be re-run. Never assume chat history.

package/agents/company-worker.md

@@ -43,6 +43,8 @@ Rate each finding's importance 1-5 (the digest keeps 4-5 in full).
 
 Report SHORT. Result first, then the evidence (FINDING + SOURCE: the command and its output, the file, the PR/SHA/CI link). No narration of your steps, no restating the task. Concise never means unsourced: cut the prose around a claim, never the source that proves it.
 
+Before reporting progress, audit each factual claim against a tool result from THIS session. Only report work you can point to evidence for.
+
 Before a consequential action, state the action and its target in one line (what you will do, to what). Name the tool and the target, not your internal reasoning. A silent agent is harder to audit, and the action trail is the product. After the tool or command returns, check whether the result actually proves what you needed before the next action - do not chain blindly.
 
 **HUMAN VOICE RULE - ORDER MATTERS:** your findings-write and your draft-PR creation are ALWAYS

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "company-skill",
-  "version": "4.6.1",
+  "version": "4.6.3",
   "description": "Goal-driven multi-employee company for Claude Code. Give it a goal, it runs until done.",
   "bin": {
     "company-skill": "./bin/install.js"

package/skill/SKILL.md

@@ -256,6 +256,10 @@ Do not ask agents to echo or explain their internal reasoning as response text.
 transcribe its internal reasoning can trigger the reasoning_extraction refusal on Fable 5, causing
 a silent fallback to a weaker model - the opposite of the intended effect.
 
+Anti-fabrication: every agent (worker, reviewer, critic) audits each factual claim against a tool
+result from the current session before reporting it. This is stated once here and repeated in each
+agent file because sub-agents never see SKILL.md.
+
 ## Loop
 
 Print as plain text (NOT Bash):
@@ -273,7 +277,7 @@ Write `.company/cycles/cycle-{N}-briefing.md` first (exact name, the PreCompact
 
 As CEO, read the GOAL and COMPANY.md. Decide which departments and employees are RELEVANT to this specific goal. Only activate relevant ones. A mobile app goal does not need a Topologist. Write `.company/active-roster.md`: each activated employee with a one-line reason.
 
-**Effort scaling:** size the spawn to the goal before spawning anything. Trivial goal (single surface, known fix): no leads, 1-2 contracts written by you. Medium (one department's scope, one wave): 1-2 leads. Complex (multi-surface or unknown root cause): full parallel leads + dependency waves. State the chosen tier in the cycle briefing so the critic can challenge over- or under-spawn. Tie effort to ROI: spend heavier spawn on the highest-value decomposition of the goal, not the most obvious. When two decompositions are both sound, pick the one that unblocks more downstream work or closes the riskiest criterion first.
+**Effort scaling:** size the spawn to the goal before spawning anything. Trivial goal (single surface, known fix): no leads, 1-2 contracts written by you. Medium (one department's scope, one wave): 1-2 leads. Complex (multi-surface or unknown root cause): full parallel leads + dependency waves. State the chosen tier in the cycle briefing so the critic can challenge over- or under-spawn. Tie effort to ROI and stakes: spend heavier spawn on the highest-value decomposition of the goal, not the most obvious. When two decompositions are both sound, pick the one that unblocks more downstream work or closes the riskiest criterion first.
 
 Spawn ALL relevant department leads in parallel: one `company-lead` Agent call per department, every Agent call in a SINGLE message. Sequential lead spawns are a bug. If an Agent call fails transiently, retry once, then record the lead as unavailable and fold its planning into your own.
 
@@ -289,6 +293,8 @@ Collect every lead's contracts from the per-dept files (`cycle-{N}-tasks-{dept}.
 
 ### EXECUTE (orchestrator spawns workers in dependency waves)
 
+**Prefer short contracts over mega-contracts.** Fresh-context verification (reviewer + critic) runs at the cycle level. A single worker contract expected to run very long bypasses that interval. Split it into two smaller contracts, or add a mid-contract orchestrator checkpoint, so the verify layers can catch errors early rather than at the end of a long run.
+
 Spawn one `company-worker` Agent call per contract, mapping the contract's `MODEL:` tag to a spawn-time model per Model assignment (no tag means mid). Contracts with `DEPENDS-ON: none` (or every dependency already completed) form the current wave and ALL go in a single message. Dependents wait for their wave. A task whose dependency FAILED is returned to THINK with the failure evidence, never spawned on a broken foundation. When no contract declares dependencies the whole cycle is one wave, exactly as before. Each worker prompt is the full delegation contract verbatim plus the failed approaches from the playbook. A worker prompt that depends on chat history is a bug: the same prompt run twice must be safe (idempotent: check before create, no duplicate PRs or comments).
 
 If a contract assigns a skill, the worker invokes it via the Skill tool FIRST. If the skill is not installed, the worker falls back to raw tools and notes `SKILL-MISSING`.
@@ -322,6 +328,8 @@ SKILL-MISSING.
 
 **Long waits** (CI, builds, deploys): launch the wait in background (`run_in_background`, for example `gh pr checks --watch` or an until-loop with sleep) and continue other work. Never foreground-sleep and never assume success without reading the watcher's output. When the harness offers scheduled wakeups, prefer one long wakeup over polling sleeps. A watcher script must FAIL LOUD on tool errors: distinguish "the status command itself failed" (auth outage, network) from "zero items pending", or an outage reads as success. The orchestrator applies the same primitive to its own layer: a long-running independent Agent call can run with `run_in_background` so other workers and merges proceed, with the result read when the notification arrives.
 
+**Async-first for independent work.** Within a wave, agents with no cross-dependency SHOULD be launched with `run_in_background` so the orchestrator continues other contracts rather than blocking at a barrier. Reserve the blocking join for agents whose output is a genuine input to the next step. Independent long-running build agents are the clearest case: launch async, merge their results when the notifications arrive.
+
 **Deferred tools:** the harness may defer tool schemas (MCP servers, platform tools) behind ToolSearch. A worker whose contract needs a tool it cannot call directly first loads it via ToolSearch (`select:<name>` or keyword search); only after ToolSearch returns nothing does it report `SKILL-MISSING` or `BLOCKED`.
 
 Every finding MUST have:
@@ -347,6 +355,15 @@ Before spawning the reviewer, run the findings shape gate: `node <skill-scripts-
 
 Then spawn `company-critic` (the Devil's Advocate) on everything marked passing. Its probes: was the evidence reproduced or just transcribed? Does the test actually exercise the change? What input breaks it? What surface was never checked? Could this be simpler? Would a real user understand it? For every external claim: verified from their repo or docs, or guessed? A single unclosed gap means NOT DONE.
 
+**Perspective-diverse verify for high-stakes criteria.** This generalizes the restart-debate
+3-role panel (see Restart mode) and Anthropic's evaluator-optimizer/fresh-verifier pattern to
+in-loop high-stakes criteria. Normal-stakes criteria keep the single critic above.
+For a criterion tagged `stakes: high` in criteria.json (irreversible action, security surface,
+public-facing claim, or `attempts >= 2`), spawn the critic in THREE fresh contexts, each with a
+distinct `LENS:` directive in its prompt: correctness, security, reproducibility. Each returns a
+binary ACCEPT/REJECT + one gap line. Any REJECT blocks (unanimous ACCEPT required to pass).
+No per-lens numeric score. Record all three verdicts in the cycle review.
+
 **MERGE GATE:** nothing merges during EXECUTE. A worker's output stops at a draft PR. Only after the reviewer grades the relevant criterion MET on reproduced evidence AND the critic accepts it does the ORCHESTRATOR merge, recording the verdict in the cycle review. Workers never merge, ever. The merge gate reads the PR's Proof of work block against the reviewer's reproduction.
 
 **BRANCH AND WORKTREE HYGIENE (MANDATORY after every merge):** after merging a PR, the orchestrator MUST delete the merged branch with `gh pr merge --delete-branch` (the flag deletes the remote branch atomically with the merge) and remove its worktree with `git worktree remove --force <worktree-path>` followed by `git worktree prune`. A merged branch left on origin and a stale worktree are both bugs. Runs that touch multiple repos MUST apply this to every merged PR, not just the last one.
@@ -385,6 +402,8 @@ The digest also: (a) appends any FAILED -> USE INSTEAD or INEFFICIENT -> FASTER
 
 Do not try to run `/compact` yourself. It is a user command, not a tool. Context pressure is handled by the PreCompact and SessionStart hooks plus Restart mode.
 
+**Mid-run deliverables.** When a generated artifact, screenshot, or ready link must reach a watching human before the run ends, surface it via the harness send-to-user capability where available (a proactive file write or message the user can see without reading the whole cycle review). Do not bury mid-run deliverables in findings only.
+
 **CYCLE CLOSE HYGIENE (MANDATORY):** at the end of every COMPRESS phase, the orchestrator MUST run `node <skill-scripts-dir>/cleanup.js` to prune any remaining merged branches and stale worktrees. A run MUST NOT end with leftover merged branches or orphaned worktrees. Run with `--dry-run` first to see what would be removed, then without to apply.
 
 ## After Done
@@ -466,8 +485,6 @@ Claude 4.6+ and unsupported on Fable 5.
 
 ## Token cost discipline
 
-Cost discipline compresses prose, never evidence. The floor under every measure: FINDING + SOURCE pairs, VERIFY-WITH output, and error lines are evidence and ship verbatim, whatever a size target says.
-
 - **Cache-aware prompt layout.** Order agent prompts and contracts stable-first: the fixed boilerplate (role text, rules, pasted playbook lines) at the top, the volatile values (paths, SHAs, cycle numbers, feedback) at the bottom. The prompt cache matches prefixes, so a stable shared prefix turns repeated spawns into cheap cache reads.
 - **Worker tool-output discipline.** grep, head, and tail over cat. Slice the lines the task needs and never paste raw logs or whole files into findings or replies. Carve-out: VERIFY-WITH output and error lines are evidence, pasted verbatim and never summarized.
 - **Digest retrieval pointers.** Below importance 4 the digest stores a one-line pointer (findings file path plus a grep-able anchor) instead of restating the finding, and the next THINK greps it on demand. Importance 4-5 findings stay in full with their SOURCE lines intact.