Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/thuandiep1707/codex-harness-javascript/progressgit clone --depth 1 https://github.com/thuandiep1707/codex-harness-javascriptWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00861 |
| Opus 5 | $0.00000 | $0.00430 |
| Sonnet 5 | $0.00000 | $0.00172 |
| Haiku 4.5 | $0.00000 | $0.00086 |
Grade A, and why
progress scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Architecture status
Implemented
- Zero-setup two-project Codex workspace model.
- Root
AGENTS.mdbootstrap with public-workflow selection + lifecycle-entry resolution. - Public
$discovery restricted to.agents/skills/workflows only. - Internal agent knowledge moved to
.agents/capabilities/**and hidden from user workflow discovery. - Public frontend workflows:
frontend-deliveryandfrontend-planning. - Separate execution intent (
deliver|plan-only) from lifecycle mode (planning|resume|pause). - Brain evidence-based
discover-project-stackcapability for framework/UI/icon/state/testing detection. - Orchestrator capability routing from analysis evidence + Subtask trigger + specialist manifest allowlist.
- Primary Controller as the sole native child-agent lifecycle and Jira connector transport owner.
- Orchestrator as decision-only workflow coordinator using
controller-actions(jira-call|dispatch-specialist). - One workflow-lived Orchestrator child reused across controller turns; specialists are short-lived sibling children.
- Confirmed controller-action results are returned to the same Orchestrator child for reconciliation/next-action decisions.
- Specialist handoff carries only routed internal capability identifiers; specialists do not load all capabilities.
- Removed baseline hard-locks that assumed shadcn/Lucide/Tailwind/TanStack simply because control-repo knowledge exists.
- Separate Brain and Orchestrator roles.
- Four isolated specialists: Design, Test Plan, Coding, Testing.
- YAML manifests and transient protocol templates.
- Specialist
.docs/prohibition. - Jira as durable work + execution-context truth.
- Functional hierarchy: Feature → Functional Task → Specialist Subtask.
- Resume flow reconstructing only parent chain + direct dependencies + routed capability identifiers + latest durable checkpoint.
- Pause flow reconciling execution evidence, persisting missing Jira result/status corrections, and writing durable
[HANDOFF]before safe pause. - Explicit child-agent close/verification and runtime-resource/process/port cleanup lifecycle.
- Brain
docs-baselinefor cheap resume/replan validation. - Coding component-decomposition gate and oversized handwritten TSX safety net.
- Git tag/GitHub Release versioning policy.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 95 lines · 0 tokens per session scan A 6363d979c607
progress is an agent published in the GitHub repository thuandiep1707/codex-harness-javascript (7 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 861 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
independent-reviewer
Fresh-context read-only independent reviewer for SPEC-based acceptance evidence and integration recommendation.
task-specialist
Bounded implementer for one ready task with an exclusive write set and approved context.
discovery-interviewer
Read-only interviewer for missing, stale, or mature-project context before implementation planning.
learning-assessor
Read-only project-learning assessor used only after explicit learning activation and observation consent.
ap-implementer
L3 executor - G4 IMPLEMENT. Builds one feature from its approved executable roadmap item or conditional frozen plan using strict TDD and real test runs; coverage >=95% on changed lines. Reports PLAN-CONFLICT rather than improvising.
ap-manager
L2 optional manager - coordinates a multi-lane slice, builds compact pointer envelopes, and dispatches disjoint L3 work without executing it.