arkaos 4.24.0 → 4.26.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -1
- package/THE-ARKAOS-GUIDE.md +1 -1
- package/VERSION +1 -1
- package/arka/SKILL.md +1 -1
- package/bin/arka +8 -0
- package/config/claude-agents/dba.md +3 -3
- package/config/claude-agents/shadcn-padronizer.md +3 -3
- package/departments/brand/agents/design-ops/shadcn-padronizer.yaml +1 -1
- package/departments/dev/agents/dba.yaml +1 -1
- package/departments/dev/skills/build-fix/SKILL.md +122 -0
- package/departments/dev/skills/opensource-release/SKILL.md +96 -0
- package/departments/dev/skills/react-review/SKILL.md +86 -0
- package/departments/ops/skills/harness-tune/SKILL.md +79 -0
- package/departments/ops/skills/hookify/SKILL.md +89 -0
- package/departments/ops/skills/session-retro/SKILL.md +81 -0
- package/departments/ops/skills/workspace-audit/SKILL.md +88 -0
- package/departments/pm/skills/epic-coordination/SKILL.md +79 -0
- package/harness/codex/AGENTS.md +139 -0
- package/harness/copilot/copilot-instructions.md +139 -0
- package/harness/cursor/rules/arkaos-stack-laravel.mdc +16 -0
- package/harness/cursor/rules/arkaos-stack-node.mdc +14 -0
- package/harness/cursor/rules/arkaos-stack-nuxt.mdc +15 -0
- package/harness/cursor/rules/arkaos-stack-php.mdc +14 -0
- package/harness/cursor/rules/arkaos-stack-python.mdc +14 -0
- package/harness/cursor/rules/arkaos-stack-react.mdc +14 -0
- package/harness/cursor/rules/arkaos-stack-vue.mdc +14 -0
- package/harness/cursor/rules/arkaos.mdc +72 -0
- package/harness/gemini/GEMINI.md +139 -0
- package/harness/opencode/AGENTS.md +139 -0
- package/harness/zed/.rules +139 -0
- package/installer/adapters/codex-cli.js +16 -27
- package/installer/adapters/cursor.js +22 -26
- package/installer/adapters/gemini-cli.js +15 -30
- package/installer/cli.js +1 -1
- package/installer/doctor.js +225 -0
- package/installer/harness-bundle.js +39 -0
- package/knowledge/agents-registry-v2.json +3 -3
- package/knowledge/skills-manifest.json +105 -1
- package/package.json +2 -1
- package/pyproject.toml +1 -1
- package/scripts/harness_gen.py +287 -0
package/README.md
CHANGED
package/THE-ARKAOS-GUIDE.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# The ArkaOS Guide
|
|
2
2
|
|
|
3
|
-
> v4.
|
|
3
|
+
> v4.26.0 — 86 agents, 17 departments, 302 skills, 270 commands, 16 ADRs.
|
|
4
4
|
> One file, everything you need to start. Generated by `scripts/guide_gen.py` — never hand-edited.
|
|
5
5
|
|
|
6
6
|
## What it is
|
package/VERSION
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
4.
|
|
1
|
+
4.26.0
|
package/arka/SKILL.md
CHANGED
|
@@ -47,7 +47,7 @@ complementary, not alternatives.
|
|
|
47
47
|
# ArkaOS — Main Orchestrator
|
|
48
48
|
|
|
49
49
|
> **The Operating System for AI Agent Teams**
|
|
50
|
-
> 86 agents. 17 departments.
|
|
50
|
+
> 86 agents. 17 departments. 302 skills. Multi-runtime. Dashboard. Knowledge RAG.
|
|
51
51
|
|
|
52
52
|
## ⛔ Evidence flow — 4 gates (NON-NEGOTIABLE)
|
|
53
53
|
|
package/bin/arka
CHANGED
|
@@ -66,6 +66,14 @@ case "${1:-}" in
|
|
|
66
66
|
;;
|
|
67
67
|
doctor)
|
|
68
68
|
shift
|
|
69
|
+
# Issue #358: the node doctor is canonical (engine/venv/hooks/security
|
|
70
|
+
# + the migrated Claude-layer checks). The bash doctor only audits the
|
|
71
|
+
# legacy v1 layout — keep it strictly as the no-npx fallback.
|
|
72
|
+
if command -v npx &>/dev/null; then
|
|
73
|
+
npx arkaos doctor "$@"
|
|
74
|
+
exit $?
|
|
75
|
+
fi
|
|
76
|
+
echo "npx not found — falling back to the legacy v1 doctor (limited scope)." >&2
|
|
69
77
|
bash "$HOME/.local/bin/arka-doctor" "$@"
|
|
70
78
|
exit $?
|
|
71
79
|
;;
|
|
@@ -1,15 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: dba
|
|
3
3
|
description: >
|
|
4
|
-
Vasco — Data Platform Lead
|
|
4
|
+
Vasco — Data Platform Lead — Database & Data Engineer (dev squad). Executes: PostgreSQL (advanced), Supabase, schema design & normalization, migration planning.
|
|
5
5
|
model: sonnet
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- generated by core/agents/behavioral_compiler.py from departments/dev/agents/dba.yaml — DO NOT EDIT; edit the YAML and re-run -->
|
|
9
9
|
|
|
10
|
-
# Vasco — Data Platform Lead
|
|
10
|
+
# Vasco — Data Platform Lead — Database & Data Engineer
|
|
11
11
|
|
|
12
|
-
You are Vasco, Data Platform Lead
|
|
12
|
+
You are Vasco, Data Platform Lead — Database & Data Engineer of the dev squad (Tier 2). What drives you: Data systems that are fast, reliable, and correctly modeled. The failure you exist to prevent: Data loss, corruption, or slow queries bringing down production.
|
|
13
13
|
|
|
14
14
|
## How you work
|
|
15
15
|
|
|
@@ -1,15 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: shadcn-padronizer
|
|
3
3
|
description: >
|
|
4
|
-
Leo — Component Library
|
|
4
|
+
Leo — Component Library Standardizer (brand squad). Executes: shadcn/ui component generation and customisation, Radix UI primitives integration, Tailwind configuration and theme tokens, CVA variants and slot patterns.
|
|
5
5
|
model: sonnet
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
<!-- generated by core/agents/behavioral_compiler.py from departments/brand/agents/design-ops/shadcn-padronizer.yaml — DO NOT EDIT; edit the YAML and re-run -->
|
|
9
9
|
|
|
10
|
-
# Leo — Component Library
|
|
10
|
+
# Leo — Component Library Standardizer
|
|
11
11
|
|
|
12
|
-
You are Leo, Component Library
|
|
12
|
+
You are Leo, Component Library Standardizer of the brand squad (Tier 2). What drives you: One canonical component, used everywhere, evolving cleanly. The failure you exist to prevent: Five teams shipping five Button components that diverge over a quarter.
|
|
13
13
|
|
|
14
14
|
## How you work
|
|
15
15
|
|
|
@@ -0,0 +1,122 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dev/build-fix
|
|
3
|
+
description: >
|
|
4
|
+
Systematic build-failure diagnosis: read the FIRST error bottom-up,
|
|
5
|
+
reproduce it in isolation, classify it (dependency, config, code,
|
|
6
|
+
toolchain, cache), fix the root cause, and prove the fix with two
|
|
7
|
+
clean builds — with per-ecosystem playbooks for the failure
|
|
8
|
+
signatures of Laravel/PHP, Node/TS, Vue/Nuxt, React/Next, and Python.
|
|
9
|
+
TRIGGER: "/dev build-fix", "the build is broken", "o build está a
|
|
10
|
+
falhar", "compila localmente mas falha no CI", "npm run build
|
|
11
|
+
rebenta", "composer install falha", "arranja o build"; any red build
|
|
12
|
+
whose error output exists. SKIP: the code builds but tests fail ->
|
|
13
|
+
dev/code-review or dev/app-test wins; designing the pipeline itself
|
|
14
|
+
-> dev/ci-cd-pipeline wins; a production outage -> dev/incident wins.
|
|
15
|
+
allowed-tools: [Read, Grep, Glob, Bash]
|
|
16
|
+
metadata:
|
|
17
|
+
origin: arkaos
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
# Build Fix — `/dev build-fix`
|
|
21
|
+
|
|
22
|
+
> **Agent:** Paulo (Tech Lead) | **Framework:** Root-cause classification, first-error discipline
|
|
23
|
+
|
|
24
|
+
A failing build is the most honest bug report you will ever receive:
|
|
25
|
+
deterministic, reproducible, and pointing at itself. Almost every hour
|
|
26
|
+
lost to a broken build is lost the same way — fixing the LAST error on
|
|
27
|
+
the screen, which is usually a cascade symptom of the first one, or
|
|
28
|
+
reaching for the folk remedy (delete the lockfile, clear every cache,
|
|
29
|
+
reinstall the world) before reading what the tool actually said.
|
|
30
|
+
|
|
31
|
+
## Method
|
|
32
|
+
|
|
33
|
+
1. **Find the first error.** Scroll past the cascade; the root error is
|
|
34
|
+
the earliest one, and everything after it is noise until proven
|
|
35
|
+
otherwise.
|
|
36
|
+
2. **Reproduce in isolation.** Run the failing step alone, from a clean
|
|
37
|
+
shell, with the project's pinned tool versions. A build that only
|
|
38
|
+
fails inside CI is still reproducible — replicate the CI's inputs
|
|
39
|
+
(env vars, lockfile, node/php/python version) locally before
|
|
40
|
+
touching anything.
|
|
41
|
+
3. **Classify** the root error into exactly one bucket:
|
|
42
|
+
| Bucket | Signature |
|
|
43
|
+
|---|---|
|
|
44
|
+
| Dependency | resolver conflicts, missing package, lockfile drift |
|
|
45
|
+
| Config | tool config rejects input, wrong paths, env var absent |
|
|
46
|
+
| Code | type error, syntax error, failed macro/codegen |
|
|
47
|
+
| Toolchain | wrong runtime version, missing system binary |
|
|
48
|
+
| Cache | passes clean, fails incrementally (or the reverse) |
|
|
49
|
+
4. **Fix the root, not the symptom.** A cast that silences a type error
|
|
50
|
+
the compiler was right about is a deferred production bug.
|
|
51
|
+
5. **Prove it.** Two consecutive clean builds — one incremental, one
|
|
52
|
+
from clean — with exit codes on record. One green build after a
|
|
53
|
+
cache clear proves nothing about the fix.
|
|
54
|
+
|
|
55
|
+
## Ecosystem playbooks
|
|
56
|
+
|
|
57
|
+
### Laravel / PHP
|
|
58
|
+
|
|
59
|
+
- `Class not found` after moving a file → regenerate the autoload map
|
|
60
|
+
(`composer dump-autoload`); if it persists, the namespace does not
|
|
61
|
+
match the path — fix the namespace, not the autoloader.
|
|
62
|
+
- `composer install` resolver conflict → read WHICH two constraints
|
|
63
|
+
collide before touching version pins; widening the wrong one
|
|
64
|
+
downgrades half the tree.
|
|
65
|
+
- Migration failure mid-build → the schema state is now ahead of the
|
|
66
|
+
migration table; inspect before re-running, never loop `migrate:fresh`
|
|
67
|
+
on shared databases.
|
|
68
|
+
|
|
69
|
+
### Node / TypeScript
|
|
70
|
+
|
|
71
|
+
- `tsc` errors that runtime never hits → the types drifted from the
|
|
72
|
+
code; fix the types, do not add `as any` (the compiler is the only
|
|
73
|
+
reviewer that reads every call site).
|
|
74
|
+
- Works locally, fails in CI → lockfile drift: CI runs `npm ci` (exact
|
|
75
|
+
lockfile) while local `npm install` mutated it. Commit the lockfile
|
|
76
|
+
the build actually needs.
|
|
77
|
+
- `ERR_REQUIRE_ESM` / `Cannot use import` → an ESM-only dependency in a
|
|
78
|
+
CJS context; align the importing module's format instead of pinning
|
|
79
|
+
the dependency to a dead major.
|
|
80
|
+
|
|
81
|
+
### Vue / Nuxt
|
|
82
|
+
|
|
83
|
+
- Auto-import resolution failures (`X is not defined` only in build) →
|
|
84
|
+
the dev server tolerates what nitro's build does not; add the
|
|
85
|
+
explicit import.
|
|
86
|
+
- Hydration-safe code that fails at BUILD time in SSR → browser-only
|
|
87
|
+
API executed at module top level; move it inside a lifecycle hook or
|
|
88
|
+
guard it.
|
|
89
|
+
|
|
90
|
+
### React / Next.js
|
|
91
|
+
|
|
92
|
+
- Server/client boundary violations (`useState in a Server Component`)
|
|
93
|
+
→ mark the leaf `"use client"`, never the whole tree — pushing the
|
|
94
|
+
directive up quietly moves the entire subtree to the client bundle.
|
|
95
|
+
- Build-time data fetching failures → a page assumed a runtime env var
|
|
96
|
+
at static-generation time; decide dynamic vs static explicitly.
|
|
97
|
+
|
|
98
|
+
### Python
|
|
99
|
+
|
|
100
|
+
- Import works in the repl, fails in the build → the venv the build
|
|
101
|
+
uses is not the venv you activated; print `sys.executable` in the
|
|
102
|
+
failing context before debugging imports.
|
|
103
|
+
- Resolver backtracking forever → over-constrained pins; loosen the
|
|
104
|
+
pins you own, never the transitive ones.
|
|
105
|
+
- Circular import only at build/collect time → the cycle was always
|
|
106
|
+
there; imports inside functions defer it, moving the shared symbol
|
|
107
|
+
out removes it.
|
|
108
|
+
|
|
109
|
+
## Output
|
|
110
|
+
|
|
111
|
+
```markdown
|
|
112
|
+
## Build Fix Report
|
|
113
|
+
|
|
114
|
+
**Failing step:** {command} · **First error:** {file}:{line} — {message}
|
|
115
|
+
**Bucket:** {dependency|config|code|toolchain|cache}
|
|
116
|
+
**Root cause:** {one sentence}
|
|
117
|
+
**Fix:** {what changed and why it addresses the root}
|
|
118
|
+
**Proof:** incremental build exit 0 · clean build exit 0 (commands on record)
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
A build fixed without the two-build proof, or a symptom silenced with a
|
|
122
|
+
cast or a cache clear, does not close this skill.
|
|
@@ -0,0 +1,96 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dev/opensource-release
|
|
3
|
+
description: >
|
|
4
|
+
Takes an internal module or repo public WITHOUT taking its secrets
|
|
5
|
+
with it: extract the component, scrub content AND history (secrets,
|
|
6
|
+
client identifiers, internal URLs, embarrassing commits), package it
|
|
7
|
+
as a standalone citizen (license, README, CI, versioning), and verify
|
|
8
|
+
the published artifact with an adversarial re-scan before anyone
|
|
9
|
+
else can. TRIGGER: "/dev opensource-release", "open-source this",
|
|
10
|
+
"vamos abrir este módulo", "prepara isto para publicar",
|
|
11
|
+
"extrai isto para um repo público", any internal-to-public extraction.
|
|
12
|
+
SKIP: releasing a version of an already-public package ->
|
|
13
|
+
dev/release wins; secrets hygiene inside a private repo ->
|
|
14
|
+
dev/env-secrets wins; redacting a document, not a repo ->
|
|
15
|
+
kb/doc-redaction wins.
|
|
16
|
+
allowed-tools: [Read, Grep, Glob, Bash]
|
|
17
|
+
metadata:
|
|
18
|
+
origin: arkaos
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
# Open-Source Release — `/dev opensource-release`
|
|
22
|
+
|
|
23
|
+
> **Agent:** Bruno (Security Engineer) | **Framework:** History-aware scrubbing, adversarial pre-publication review
|
|
24
|
+
|
|
25
|
+
Publishing is the one deploy you cannot roll back. The moment a repo
|
|
26
|
+
goes public, every commit it ever had goes public with it — the API key
|
|
27
|
+
someone removed in 2024 but never rotated, the client name in a test
|
|
28
|
+
fixture, the TODO that names an unshipped product. Mirrors and scrapers
|
|
29
|
+
archive within minutes; deleting the repo afterwards deletes your copy,
|
|
30
|
+
not theirs.
|
|
31
|
+
|
|
32
|
+
## Phase 1 — Extract
|
|
33
|
+
|
|
34
|
+
1. Decide the boundary: what goes public, and what the public part is
|
|
35
|
+
allowed to import. An internal dependency that cannot come along
|
|
36
|
+
must be replaced by an interface or the boundary is wrong.
|
|
37
|
+
2. Extract into a FRESH repository with a FRESH history. Carrying the
|
|
38
|
+
internal git history into the public repo is the default disaster —
|
|
39
|
+
the scrub target becomes every blob ever committed instead of the
|
|
40
|
+
current tree. Start public history at the first public commit;
|
|
41
|
+
record the internal provenance (repo + commit hash) in a private
|
|
42
|
+
note, not in the public tree.
|
|
43
|
+
|
|
44
|
+
## Phase 2 — Scrub, then prove the scrub
|
|
45
|
+
|
|
46
|
+
Sweep the candidate tree for, at minimum:
|
|
47
|
+
|
|
48
|
+
| Class | Examples |
|
|
49
|
+
|---|---|
|
|
50
|
+
| Credentials | keys, tokens, connection strings, `.env*`, CI secrets |
|
|
51
|
+
| Identity leaks | client names, internal hostnames/URLs, employee data in fixtures |
|
|
52
|
+
| Business leaks | pricing internals, unshipped product names, internal roadmap refs |
|
|
53
|
+
| Path leaks | absolute paths exposing usernames or internal layout |
|
|
54
|
+
|
|
55
|
+
Two rules make the scrub real:
|
|
56
|
+
|
|
57
|
+
- **Scan the ARTIFACT, not the intention** — after packaging, run the
|
|
58
|
+
full sweep again on the exact tarball/tree that will be published
|
|
59
|
+
(the `npm pack --dry-run` + grep discipline). A scrub verified on the
|
|
60
|
+
working tree and published from a different state proves nothing.
|
|
61
|
+
- **Found secrets get ROTATED, not just removed.** A credential that
|
|
62
|
+
ever sat in a candidate tree is compromised-by-assumption; removal
|
|
63
|
+
cleans the repo, rotation cleans the risk.
|
|
64
|
+
|
|
65
|
+
## Phase 3 — Package as a citizen
|
|
66
|
+
|
|
67
|
+
- LICENSE chosen deliberately (permissive vs copyleft is a strategy
|
|
68
|
+
decision — route it to the operator, never default silently).
|
|
69
|
+
- README that stands alone: what it does, install, quickstart, no
|
|
70
|
+
internal context assumed.
|
|
71
|
+
- CI on the public repo running the public tests; versioning from
|
|
72
|
+
1.0.0 or 0.x with the same discipline as any product.
|
|
73
|
+
- Contribution surface decided explicitly: issues on/off, PR policy,
|
|
74
|
+
security contact.
|
|
75
|
+
|
|
76
|
+
## Phase 4 — Adversarial verification
|
|
77
|
+
|
|
78
|
+
Before flipping visibility, a second pass in a fresh context reviews
|
|
79
|
+
the exact publishable state as a hostile outsider: what can I learn
|
|
80
|
+
about the company from this tree that I should not? Only after that
|
|
81
|
+
pass returns clean does the repo go public — and the first
|
|
82
|
+
post-publication act is re-running the sweep against the LIVE public
|
|
83
|
+
artifact.
|
|
84
|
+
|
|
85
|
+
## Output
|
|
86
|
+
|
|
87
|
+
```markdown
|
|
88
|
+
## Open-Source Release Report
|
|
89
|
+
|
|
90
|
+
**Component:** {name} · **Boundary:** {what ships / what stayed}
|
|
91
|
+
**History:** fresh (internal provenance recorded privately at {ref})
|
|
92
|
+
**Scrub:** {classes swept} · findings {n} · rotations {n, with owners}
|
|
93
|
+
**Package:** {license} · README ✓ · CI ✓ · version {v}
|
|
94
|
+
**Adversarial pass:** {clean / findings and their fixes}
|
|
95
|
+
**Published:** {url} · post-publication re-scan: {clean}
|
|
96
|
+
```
|
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dev/react-review
|
|
3
|
+
description: >
|
|
4
|
+
React / Next.js review for the framework's own traps — stale closures
|
|
5
|
+
in hooks, dependency arrays that lie, derived state stored instead of
|
|
6
|
+
computed, keys that force remounts, effects doing render work, and
|
|
7
|
+
server/client boundary leaks in the App Router — with the fix each
|
|
8
|
+
needs. Hooks and TypeScript assumed. TRIGGER: "/dev react-review",
|
|
9
|
+
"review this React", "review the Next.js", "revê este componente
|
|
10
|
+
React", "revê o hook", "porque é que o efeito corre duas vezes?", any
|
|
11
|
+
diff touching *.tsx components or custom hooks. SKIP:
|
|
12
|
+
language-agnostic review -> dev/code-review wins; TypeScript type
|
|
13
|
+
design without React specifics -> dev/typescript-review wins; a
|
|
14
|
+
handler-ordering/state-cancellation bug -> dev/click-path-audit wins;
|
|
15
|
+
visual/brand review -> brand/design-review wins.
|
|
16
|
+
allowed-tools: [Read, Grep, Glob]
|
|
17
|
+
metadata:
|
|
18
|
+
origin: arkaos
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
# React Review — `/dev react-review`
|
|
22
|
+
|
|
23
|
+
> **Agent:** Diana (Senior Frontend Developer) | **Framework:** Hooks semantics, render-cycle discipline, RSC boundaries
|
|
24
|
+
|
|
25
|
+
Where Vue's traps announce themselves — reactivity silently lost is
|
|
26
|
+
still lost — React's traps ship working code that is wrong later: the
|
|
27
|
+
closure that captured last render's state, the dependency array that
|
|
28
|
+
omits what the effect reads, the memo that never invalidates. This
|
|
29
|
+
review walks the render cycle, not the file: what each render reads,
|
|
30
|
+
what it captures, and what survives to the next one.
|
|
31
|
+
|
|
32
|
+
## The traps, and the fix each needs
|
|
33
|
+
|
|
34
|
+
| # | Trap | Signature | Fix |
|
|
35
|
+
|---|------|-----------|-----|
|
|
36
|
+
| 1 | Stale closure | callback reads state captured N renders ago | functional updater (`setX(v => ...)`) or include the dep and let the callback re-create |
|
|
37
|
+
| 2 | Lying dependency array | effect reads `a`, deps say `[b]` | list what the effect READS; if that loops, the effect does too much — split it |
|
|
38
|
+
| 3 | Derived state stored | `useState` mirroring a computable value, synced by effect | compute during render (`useMemo` if costly); delete the effect |
|
|
39
|
+
| 4 | Keys without identity | `key={index}` on reorderable lists (state mis-binds to the POSITION after a reorder), or key changing identity every render (full remount each time) | stable identity key; component state follows the item |
|
|
40
|
+
| 5 | Effects doing render work | formatting/filtering in `useEffect` + `setState` | that is render logic — move it into render; effects are for the outside world |
|
|
41
|
+
| 6 | Boundary leak (App Router) | `"use client"` at the top of a tree because one leaf needs a hook | push the directive to the leaf; a client parent drags every child into the bundle |
|
|
42
|
+
| 7 | Context re-render storm | one broad context carrying fast-changing values | split contexts by change rate, memoize the provider value |
|
|
43
|
+
| 8 | Unstable references as props | inline objects/functions into memoized children | hoist or `useCallback`/`useMemo` — or drop the memo, half-memoized is unmemoized |
|
|
44
|
+
|
|
45
|
+
## Process
|
|
46
|
+
|
|
47
|
+
For every component and custom hook in scope:
|
|
48
|
+
|
|
49
|
+
1. **Trace one render**: what it reads, what it computes, what it
|
|
50
|
+
captures in closures handed to children, effects, or timers.
|
|
51
|
+
2. **Interrogate every `useEffect`**: does it synchronize with an
|
|
52
|
+
external system (fetch, subscription, DOM)? If it only moves state
|
|
53
|
+
around, it is a trap-3 or trap-5 candidate.
|
|
54
|
+
3. **Check every dependency array against the closure it feeds** — the
|
|
55
|
+
array documents what the closure reads; any omission is a latent
|
|
56
|
+
staleness bug, not an optimization.
|
|
57
|
+
4. **Walk the server/client boundary** (Next.js App Router): where does
|
|
58
|
+
`"use client"` sit, and does anything serialize a non-serializable
|
|
59
|
+
prop across it?
|
|
60
|
+
5. **Confirm list keys carry identity**, not position.
|
|
61
|
+
|
|
62
|
+
## Proactive Triggers
|
|
63
|
+
|
|
64
|
+
Surface these WITHOUT being asked:
|
|
65
|
+
|
|
66
|
+
- an async callback using state without a functional updater → the
|
|
67
|
+
stale-closure race it hides
|
|
68
|
+
- `useEffect` + `setState` whose only input is other state → the
|
|
69
|
+
derived-state rewrite that deletes both
|
|
70
|
+
- a `"use client"` higher than the hook that needs it → the bundle cost
|
|
71
|
+
and the RSC benefits silently forfeited
|
|
72
|
+
|
|
73
|
+
## Output
|
|
74
|
+
|
|
75
|
+
```markdown
|
|
76
|
+
## React Review Report
|
|
77
|
+
|
|
78
|
+
**Scope:** {components / hooks reviewed}
|
|
79
|
+
|
|
80
|
+
### {Component / hook} — {file}:{line}
|
|
81
|
+
**Trap:** {#N name} · **Evidence:** {what the render trace shows}
|
|
82
|
+
**Consequence:** {what goes wrong, when}
|
|
83
|
+
**Fix:** {the specific rewrite}
|
|
84
|
+
|
|
85
|
+
**Verdict:** {clean / N findings, ranked by user impact}
|
|
86
|
+
```
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ops/harness-tune
|
|
3
|
+
description: >
|
|
4
|
+
Telemetry-driven tuning of the ArkaOS harness itself: reads the
|
|
5
|
+
recorded usage (MCP call telemetry, LLM cost lines, skill-budget
|
|
6
|
+
report, curated-mode leftovers) and proposes the cuts and switches
|
|
7
|
+
the data supports — MCP servers nothing called, skill surface beyond
|
|
8
|
+
the context budget, department packs installed but idle. Propose-only;
|
|
9
|
+
the operator applies. TRIGGER: "/ops harness-tune", "tune my setup",
|
|
10
|
+
"otimiza o meu harness", "o que posso cortar?", "porque está o
|
|
11
|
+
contexto tão cheio?", "que MCPs não uso?". SKIP: install health ->
|
|
12
|
+
the doctor (npx arkaos doctor) wins; cost VISIBILITY without action
|
|
13
|
+
-> /arka costs wins; business-process bottlenecks ->
|
|
14
|
+
ops/bottleneck-find wins.
|
|
15
|
+
allowed-tools: [Read, Grep, Glob, Bash]
|
|
16
|
+
metadata:
|
|
17
|
+
origin: arkaos
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
# Harness Tune — `/ops harness-tune`
|
|
21
|
+
|
|
22
|
+
> **Agent:** Daniel (Operations Lead) | **Framework:** Usage-evidence pruning, propose-only changes
|
|
23
|
+
|
|
24
|
+
Every MCP server registered, every skill deployed, every pack installed
|
|
25
|
+
pays rent in the scarcest currency the harness has — context — whether
|
|
26
|
+
it gets used or not. The bill arrives silently, every single turn. This
|
|
27
|
+
skill reads the meters before proposing anything: a recommendation that
|
|
28
|
+
is not backed by a telemetry line is an opinion, and opinions do not
|
|
29
|
+
get to delete configuration.
|
|
30
|
+
|
|
31
|
+
## Read the meters
|
|
32
|
+
|
|
33
|
+
| Meter | Source | Answers |
|
|
34
|
+
|---|---|---|
|
|
35
|
+
| MCP usage | `~/.arkaos/telemetry/mcp-usage.jsonl` (aggregate: `core.runtime.mcp_telemetry`) | which servers were actually called, when last |
|
|
36
|
+
| LLM cost | `core.runtime.llm_cost_telemetry` summaries | which sessions burn, cache hit rate |
|
|
37
|
+
| Skill surface | skill-budget linter + `skills-mode.json` + manifest | deployed vs curated cut, leftovers on a curated machine |
|
|
38
|
+
| Enforcement | `core.governance.enforcement_telemetry` | gates that fire often (candidates for tuning, not removal) |
|
|
39
|
+
|
|
40
|
+
A meter that has no data is reported as "no data", never extrapolated —
|
|
41
|
+
two days of telemetry cannot justify removing anything.
|
|
42
|
+
|
|
43
|
+
## Propose (never apply)
|
|
44
|
+
|
|
45
|
+
For each finding, the proposal names the evidence, the change, the
|
|
46
|
+
saving, and the reversal:
|
|
47
|
+
|
|
48
|
+
- MCP server with zero calls in the observation window → propose
|
|
49
|
+
removing it from the project `.mcp.json` files that carry it; note
|
|
50
|
+
the one-line restore.
|
|
51
|
+
- Curated-mode machine carrying plugin-eligible leftovers → propose the
|
|
52
|
+
pack-by-pack install path instead (the doctor's skills-surface check
|
|
53
|
+
names them).
|
|
54
|
+
- Full-mode machine using two departments → propose curated + the two
|
|
55
|
+
packs.
|
|
56
|
+
- A gate firing constantly with high compliance → nothing to remove;
|
|
57
|
+
flag as healthy enforcement, not noise. Tuning never trades
|
|
58
|
+
governance for tokens.
|
|
59
|
+
|
|
60
|
+
Hard line: user-added MCPs and project-specific servers are proposed
|
|
61
|
+
for removal ONLY on zero usage, and always labeled as user-added —
|
|
62
|
+
the harness does not know why the operator installed them, so the
|
|
63
|
+
proposal says that too.
|
|
64
|
+
|
|
65
|
+
## Output
|
|
66
|
+
|
|
67
|
+
```markdown
|
|
68
|
+
## Harness Tune Report — {date}
|
|
69
|
+
|
|
70
|
+
**Observation window:** {days}d of telemetry ({lines} events)
|
|
71
|
+
|
|
72
|
+
| # | Evidence | Proposal | Saves | Restore |
|
|
73
|
+
|---|---|---|---|---|
|
|
74
|
+
| 1 | {server}: 0 calls in {n}d | remove from {k} projects | {context/startup} | {one-liner} |
|
|
75
|
+
|
|
76
|
+
**No-data meters:** {list, or none}
|
|
77
|
+
**Healthy, untouched:** {enforcement surfaces left alone, and why}
|
|
78
|
+
**Apply:** every change above is a diff the operator runs — nothing was changed by this audit.
|
|
79
|
+
```
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ops/hookify
|
|
3
|
+
description: >
|
|
4
|
+
Compiles a repeated correction into a deterministic hook: identify
|
|
5
|
+
the behavior that keeps being corrected by hand, express it as a
|
|
6
|
+
machine-checkable predicate, and install it on the right ArkaOS hook
|
|
7
|
+
surface (PreToolUse deny, Stop lint, UserPromptSubmit nudge) —
|
|
8
|
+
warn-first with telemetry, hard only when the false-positive rate
|
|
9
|
+
earns it. TRIGGER: "/ops hookify", "make this automatic", "torna isto
|
|
10
|
+
automático", "estou farto de corrigir isto", "enforce this rule",
|
|
11
|
+
"isto devia ser um hook"; the third manual correction of the same
|
|
12
|
+
behavior. SKIP: capturing a reusable feature build -> arka-recipes
|
|
13
|
+
wins; automating a business process -> ops/workflow-automate wins;
|
|
14
|
+
writing an SOP for humans -> ops/sop-create wins.
|
|
15
|
+
allowed-tools: [Read, Grep, Glob, Bash, Write, Edit]
|
|
16
|
+
metadata:
|
|
17
|
+
origin: arkaos
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
# Hookify — `/ops hookify`
|
|
21
|
+
|
|
22
|
+
> **Agent:** Daniel (Operations Lead) | **Framework:** Correction-to-predicate compilation, warn-first enforcement
|
|
23
|
+
|
|
24
|
+
A hook is a correction that stopped needing you. The third time the
|
|
25
|
+
same behavior gets fixed by hand — the commit message pattern, the file
|
|
26
|
+
that must never be edited directly, the command that needs a flag — the
|
|
27
|
+
correction has stopped being feedback and become a specification
|
|
28
|
+
nobody wrote down. This skill writes it down as executable policy.
|
|
29
|
+
|
|
30
|
+
## Step 1 — Extract the predicate
|
|
31
|
+
|
|
32
|
+
From the repeated correction, derive a predicate a machine can decide
|
|
33
|
+
WITHOUT judgment calls:
|
|
34
|
+
|
|
35
|
+
- **Good**: "Edit on `config/claude-agents/*.md` → deny (generated
|
|
36
|
+
file; the YAML is the source)."
|
|
37
|
+
- **Not hookifiable**: "commit messages should be clearer" — no
|
|
38
|
+
decidable predicate. Route vague quality intents to review skills,
|
|
39
|
+
not hooks; a hook that needs judgment produces false positives that
|
|
40
|
+
teach the operator to ignore every hook.
|
|
41
|
+
|
|
42
|
+
State the predicate as: *surface* (which tool calls / which moment),
|
|
43
|
+
*condition* (decidable test), *action* (deny / warn / inject context).
|
|
44
|
+
|
|
45
|
+
## Step 2 — Pick the surface
|
|
46
|
+
|
|
47
|
+
| Surface | When it fires | Right for | House examples |
|
|
48
|
+
|---|---|---|---|
|
|
49
|
+
| PreToolUse (`core/hooks/pre_tool_use.py`) | before a tool call | preventing an edit/command that must not happen | frontend gate, research gate |
|
|
50
|
+
| Stop (`core/hooks/stop.py`) | end of turn | measuring compliance, scoped lint over changed files | stop-lint, KB-cite check |
|
|
51
|
+
| UserPromptSubmit (`config/hooks/user-prompt-submit.sh`) | before the turn | nudges and context injection, never blocking | token hygiene checks |
|
|
52
|
+
|
|
53
|
+
Constraints that are not negotiable: hooks respect their timeout budget
|
|
54
|
+
(UserPromptSubmit 10s, PostToolUse 5s), never block on network, exit 0
|
|
55
|
+
on the non-blocking surfaces, and parse JSON with jq (python3
|
|
56
|
+
fallback). A hook that exceeds its budget degrades every turn to save
|
|
57
|
+
one correction — that trade is always refused.
|
|
58
|
+
|
|
59
|
+
## Step 3 — Warn first, harden on evidence
|
|
60
|
+
|
|
61
|
+
New enforcement ALWAYS lands warn-only with telemetry (house pattern:
|
|
62
|
+
the stop-lint and frontend-gate flips). The hook logs would-block
|
|
63
|
+
events to `~/.arkaos/telemetry/`; promotion to hard deny is a separate,
|
|
64
|
+
deliberate change gated on the observed false-positive rate — a gate
|
|
65
|
+
that fires wrongly even 1 turn in 50 gets disabled by hand and trains
|
|
66
|
+
contempt for the ones that fire rightly.
|
|
67
|
+
|
|
68
|
+
## Step 4 — Install with proof
|
|
69
|
+
|
|
70
|
+
1. Implement on the chosen surface, following that surface's existing
|
|
71
|
+
pattern (read the sibling hooks first).
|
|
72
|
+
2. Reproduce the original correction scenario and show the hook
|
|
73
|
+
catching it — a hook whose trigger was never exercised is a hope,
|
|
74
|
+
not a control.
|
|
75
|
+
3. Show a benign scenario passing untouched (the false-positive probe).
|
|
76
|
+
4. Register the telemetry line and, if the hook grows a flag, document
|
|
77
|
+
it where the surface's flags live.
|
|
78
|
+
|
|
79
|
+
## Output
|
|
80
|
+
|
|
81
|
+
```markdown
|
|
82
|
+
## Hookify Report
|
|
83
|
+
|
|
84
|
+
**Correction observed:** {what kept being fixed by hand, with instances}
|
|
85
|
+
**Predicate:** {surface} · {condition} · {action}
|
|
86
|
+
**Mode:** warn-only (telemetry: {file}) · hard-flip criterion: {rate}
|
|
87
|
+
**Proof:** trigger scenario caught ✓ · benign scenario untouched ✓
|
|
88
|
+
**Files:** {hook file, config, telemetry}
|
|
89
|
+
```
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ops/session-retro
|
|
3
|
+
description: >
|
|
4
|
+
Post-session friction analysis over the actual transcript: finds the
|
|
5
|
+
corrections the operator made more than once, the tool loops, the
|
|
6
|
+
redone work, and the vague asks that cost a round-trip — and turns
|
|
7
|
+
each recurring pattern into its structural fix (a hookify predicate,
|
|
8
|
+
a recipe, a refined prompt template, a missing skill). TRIGGER:
|
|
9
|
+
"/ops session-retro", "analisa esta sessão", "what went wrong this
|
|
10
|
+
session", "porque é que isto demorou tanto?", "retro da sessão", end
|
|
11
|
+
of a long or frustrating working session. SKIP: capturing an
|
|
12
|
+
APPROVED feature build for reuse -> arka-recipes wins; you already
|
|
13
|
+
know the predicate to enforce -> ops/hookify wins; team/human
|
|
14
|
+
retrospectives -> lead/team-health wins.
|
|
15
|
+
allowed-tools: [Read, Grep, Glob, Bash]
|
|
16
|
+
metadata:
|
|
17
|
+
origin: arkaos
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
# Session Retro — `/ops session-retro`
|
|
21
|
+
|
|
22
|
+
> **Agent:** Daniel (Operations Lead) | **Framework:** Transcript friction mining, pattern-to-fix routing
|
|
23
|
+
|
|
24
|
+
You shipped. The tests are green, the PR is merged, and nobody asks
|
|
25
|
+
what the session cost to get there — the correction typed three times,
|
|
26
|
+
the file re-read five, the plan that bounced twice for the same reason.
|
|
27
|
+
That cost repeats next session, and the one after, until someone reads
|
|
28
|
+
the transcript looking for it. The deliverable was reviewed; the
|
|
29
|
+
PROCESS never is. This is that review.
|
|
30
|
+
|
|
31
|
+
## Mine the transcript
|
|
32
|
+
|
|
33
|
+
Sources, in order of reliability: the session transcript itself, the
|
|
34
|
+
telemetry the hooks recorded during it (`~/.arkaos/telemetry/` —
|
|
35
|
+
stop-lint events, tool-loop detections, compliance lines), and the git
|
|
36
|
+
reflog of the period. Findings must quote their instances — a friction
|
|
37
|
+
claim without at least two concrete occurrences is an anecdote and is
|
|
38
|
+
reported as such or dropped.
|
|
39
|
+
|
|
40
|
+
| Pattern | Signature in the transcript |
|
|
41
|
+
|---|---|
|
|
42
|
+
| Repeated correction | operator states the same guidance ≥2 times, any phrasing |
|
|
43
|
+
| Tool loop | same call, same target, no state change between (the tool-loop detector's events, plus manual scan) |
|
|
44
|
+
| Redone work | an artifact written, then rewritten from scratch after a bounce that named a knowable-in-advance defect |
|
|
45
|
+
| Vague-ask round-trip | request → clarification exchange → the ACTUAL request (the refine pattern, observed after the fact) |
|
|
46
|
+
| Context churn | the same file read repeatedly far apart — a sign the fact belonged in memory or a doc |
|
|
47
|
+
|
|
48
|
+
## Route each pattern to its structural fix
|
|
49
|
+
|
|
50
|
+
The retro's output is not a list of regrets — every confirmed pattern
|
|
51
|
+
maps to exactly one fix owner:
|
|
52
|
+
|
|
53
|
+
- Repeated correction with a decidable predicate → **ops/hookify**
|
|
54
|
+
(hand it the instances; they are the evidence Step 1 needs).
|
|
55
|
+
- Correction that needs judgment → memory entry or department skill
|
|
56
|
+
gap, named explicitly.
|
|
57
|
+
- Redone work after a preventable bounce → the checklist/skill that
|
|
58
|
+
would have caught it BEFORE the first attempt.
|
|
59
|
+
- Vague-ask round-trips → the prompt template or refine flow that
|
|
60
|
+
front-loads the missing parameters.
|
|
61
|
+
- Context churn → the doc, memory, or CLAUDE.md line where the fact
|
|
62
|
+
should permanently live.
|
|
63
|
+
|
|
64
|
+
A pattern with no viable fix is stated as accepted cost — visible,
|
|
65
|
+
priced, and chosen, rather than silently paid again.
|
|
66
|
+
|
|
67
|
+
## Output
|
|
68
|
+
|
|
69
|
+
```markdown
|
|
70
|
+
## Session Retro — {session/date}
|
|
71
|
+
|
|
72
|
+
**Shipped:** {what the session delivered} · **Friction cost:** {rough
|
|
73
|
+
turns/time attributable to the patterns below}
|
|
74
|
+
|
|
75
|
+
| # | Pattern | Instances | Fix | Owner |
|
|
76
|
+
|---|---|---|---|---|
|
|
77
|
+
| 1 | {repeated correction: "stage by explicit path"} | {turn refs} | hookify predicate | ops/hookify |
|
|
78
|
+
|
|
79
|
+
**Accepted costs:** {none, or the priced list}
|
|
80
|
+
**One change for next session:** {the single highest-leverage fix}
|
|
81
|
+
```
|