@harness-forge/cli 1.2.2 → 1.2.4
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/.agents/skills/hforge-analyze/SKILL.md +35 -0
- package/.agents/skills/hforge-decide/SKILL.md +29 -0
- package/.agents/skills/hforge-init/SKILL.md +34 -0
- package/.agents/skills/hforge-refresh/SKILL.md +28 -0
- package/.agents/skills/hforge-review/SKILL.md +29 -0
- package/.agents/skills/token-budget-optimizer/SKILL.md +26 -0
- package/AGENTS.md +6 -3
- package/README.md +9 -5
- package/commands/hforge-cartograph.md +35 -0
- package/commands/hforge-commands.md +34 -0
- package/commands/hforge-decide.md +35 -0
- package/commands/hforge-init.md +37 -0
- package/commands/hforge-recommend.md +34 -0
- package/commands/hforge-recursive.md +34 -0
- package/commands/hforge-refresh.md +35 -0
- package/commands/hforge-review.md +36 -0
- package/commands/hforge-status.md +34 -0
- package/commands/hforge-task.md +35 -0
- package/commands/hforge-update.md +34 -0
- package/dist/application/install/agent-manifest.d.ts +8 -0
- package/dist/application/install/agent-manifest.d.ts.map +1 -1
- package/dist/application/install/agent-manifest.js +7 -0
- package/dist/application/install/agent-manifest.js.map +1 -1
- package/dist/application/recommendations/recommend-bundles.d.ts.map +1 -1
- package/dist/application/recommendations/recommend-bundles.js +41 -2
- package/dist/application/recommendations/recommend-bundles.js.map +1 -1
- package/dist/application/runtime/command-catalog.d.ts +7 -0
- package/dist/application/runtime/command-catalog.d.ts.map +1 -1
- package/dist/application/runtime/command-catalog.js +101 -0
- package/dist/application/runtime/command-catalog.js.map +1 -1
- package/dist/cli/commands/commands.d.ts.map +1 -1
- package/dist/cli/commands/commands.js +5 -1
- package/dist/cli/commands/commands.js.map +1 -1
- package/dist/domain/intelligence/repo-intelligence.js +1 -1
- package/dist/domain/intelligence/repo-intelligence.js.map +1 -1
- package/docs/agent-usage-playbook.md +34 -4
- package/docs/agents.md +5 -0
- package/docs/authoring/token-budget-optimizer-port.md +78 -0
- package/docs/commands.md +12 -1
- package/manifests/bundles/core.json +11 -0
- package/manifests/catalog/compatibility-matrix.json +205 -1
- package/manifests/catalog/index.json +1 -0
- package/manifests/catalog/package-surface.json +57 -0
- package/manifests/catalog/token-budget-optimizer-import-inventory.json +146 -0
- package/package.json +1 -1
- package/scripts/intelligence/shared.mjs +187 -51
- package/skills/README.md +6 -0
- package/skills/hforge-analyze/SKILL.md +40 -0
- package/skills/hforge-analyze/references/analysis-order.md +15 -0
- package/skills/hforge-analyze/references/decision-promotion.md +9 -0
- package/skills/hforge-analyze/references/output-contract.md +7 -0
- package/skills/hforge-decide/SKILL.md +58 -0
- package/skills/hforge-decide/references/decision-rubric.md +18 -0
- package/skills/hforge-decide/references/output-contract.md +7 -0
- package/skills/hforge-init/SKILL.md +58 -0
- package/skills/hforge-init/references/bootstrap-order.md +7 -0
- package/skills/hforge-init/references/output-contract.md +7 -0
- package/skills/hforge-refresh/SKILL.md +52 -0
- package/skills/hforge-refresh/references/output-contract.md +7 -0
- package/skills/hforge-refresh/references/refresh-order.md +5 -0
- package/skills/hforge-review/SKILL.md +57 -0
- package/skills/hforge-review/references/output-contract.md +7 -0
- package/skills/hforge-review/references/review-order.md +7 -0
- package/skills/token-budget-optimizer/SKILL.md +56 -0
- package/skills/token-budget-optimizer/references/audit-dimensions.md +37 -0
- package/skills/token-budget-optimizer/references/promotion-ladder.md +44 -0
- package/skills/token-budget-optimizer/references/report-template.md +25 -0
- package/skills/token-budget-optimizer/references/scoring-model.md +43 -0
- package/skills/token-budget-optimizer/scripts/inspect_token_surfaces.py +68 -0
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: hforge-analyze
|
|
3
|
+
description: repository analysis, runtime fact refresh, evidence-backed notes, and decision capture using harness forge surfaces. use when the user asks to analyze the repo, understand what matters next, gather findings, inspect risks, or turn architecture-significant changes into durable decision records.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# HForge Analyze
|
|
7
|
+
|
|
8
|
+
## Trigger Signals
|
|
9
|
+
|
|
10
|
+
- the user asks for repo analysis, understanding, onboarding, or a summary of what matters next
|
|
11
|
+
- the repo already has Harness Forge runtime artifacts that should be reused instead of rediscovered
|
|
12
|
+
- there are risks, validation gaps, stale findings, or architecture-significant changes to capture
|
|
13
|
+
- the next safe step depends on understanding repo shape, runtime findings, or decision coverage
|
|
14
|
+
|
|
15
|
+
## Inspect First
|
|
16
|
+
|
|
17
|
+
- `AGENTS.md`
|
|
18
|
+
- `.hforge/agent-manifest.json`
|
|
19
|
+
- `.hforge/runtime/index.json`
|
|
20
|
+
- `.hforge/runtime/repo/repo-map.json`
|
|
21
|
+
- `.hforge/runtime/repo/recommendations.json`
|
|
22
|
+
- `.hforge/runtime/repo/instruction-plan.json`
|
|
23
|
+
- `.hforge/runtime/findings/risk-signals.json`
|
|
24
|
+
- `.hforge/runtime/findings/validation-gaps.json`
|
|
25
|
+
- `.hforge/runtime/decisions/index.json`
|
|
26
|
+
|
|
27
|
+
## Workflow
|
|
28
|
+
|
|
29
|
+
1. confirm the workspace is initialized with `hforge status --root . --json`
|
|
30
|
+
2. if runtime artifacts are missing, initialize first with `hforge bootstrap --root . --yes`
|
|
31
|
+
3. if runtime artifacts are stale, run `hforge refresh --root . --json`
|
|
32
|
+
4. run `hforge review --root . --json` when runtime health, decision coverage, or stale task artifacts matter
|
|
33
|
+
5. summarize repo shape, dominant implementation surfaces, risks, validation gaps, and next actions using the existing runtime as the primary source of truth
|
|
34
|
+
6. when the analysis reveals architecture-significant work, create or update a durable ASR or ADR under `.hforge/runtime/decisions/`
|
|
35
|
+
|
|
36
|
+
## References
|
|
37
|
+
|
|
38
|
+
- `skills/hforge-analyze/references/analysis-order.md`
|
|
39
|
+
- `skills/hforge-analyze/references/output-contract.md`
|
|
40
|
+
- `skills/hforge-analyze/references/decision-promotion.md`
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Analysis order
|
|
2
|
+
|
|
3
|
+
Use this order to keep analysis deterministic and low-noise.
|
|
4
|
+
|
|
5
|
+
1. `hforge status --root . --json`
|
|
6
|
+
2. `.hforge/agent-manifest.json`
|
|
7
|
+
3. `.hforge/runtime/index.json`
|
|
8
|
+
4. `.hforge/runtime/repo/repo-map.json`
|
|
9
|
+
5. `.hforge/runtime/repo/recommendations.json`
|
|
10
|
+
6. `.hforge/runtime/repo/instruction-plan.json`
|
|
11
|
+
7. `.hforge/runtime/findings/risk-signals.json`
|
|
12
|
+
8. `.hforge/runtime/findings/validation-gaps.json`
|
|
13
|
+
9. `.hforge/runtime/decisions/index.json`
|
|
14
|
+
10. `hforge review --root . --json` when runtime health or stale tasks matter
|
|
15
|
+
11. `hforge refresh --root . --json` only when the existing runtime is missing or stale
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
# Decision promotion
|
|
2
|
+
|
|
3
|
+
Promote a finding into `.hforge/runtime/decisions/` when one or more of these are true:
|
|
4
|
+
- the change affects runtime boundaries, package layout, support posture, or multi-target behavior
|
|
5
|
+
- the choice has meaningful trade-offs and should stay reviewable later
|
|
6
|
+
- the work changes upgrade, migration, validation, or release expectations
|
|
7
|
+
|
|
8
|
+
Use an ASR when the direction is still being evaluated.
|
|
9
|
+
Use an ADR when the decision is accepted enough to guide future work.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Output contract
|
|
2
|
+
|
|
3
|
+
A good `/hforge-analyze` result should include:
|
|
4
|
+
- a short repo-shape summary
|
|
5
|
+
- 3 to 7 high-signal findings, not a raw dump
|
|
6
|
+
- the concrete runtime artifact or command that supports each next step
|
|
7
|
+
- explicit decision candidates when the work is architecture-significant
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: hforge-decide
|
|
3
|
+
description: create or update durable asr or adr records for harness forge workspaces. use when an analysis or implementation choice changes runtime behavior, package boundaries, support posture, migration strategy, or any other architecture-significant concern that should remain reviewable after the current session.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# HForge Decide
|
|
7
|
+
|
|
8
|
+
## Trigger Signals
|
|
9
|
+
|
|
10
|
+
- an analysis or implementation choice has architecture-significant consequences
|
|
11
|
+
- the repo already has decision records and the new work should link to them
|
|
12
|
+
- multiple credible options exist and the rationale should stay durable
|
|
13
|
+
- a task pack, impact analysis, or review surfaced a decision candidate that should not stay implicit
|
|
14
|
+
|
|
15
|
+
## Inspect First
|
|
16
|
+
|
|
17
|
+
- `.hforge/runtime/decisions/index.json`
|
|
18
|
+
- `.hforge/runtime/tasks/`
|
|
19
|
+
- `.hforge/runtime/findings/`
|
|
20
|
+
- `.hforge/runtime/repo/recommendations.json`
|
|
21
|
+
- the most relevant existing ASR or ADR if one already exists
|
|
22
|
+
|
|
23
|
+
## Workflow
|
|
24
|
+
|
|
25
|
+
1. frame the decision clearly before writing anything
|
|
26
|
+
2. inspect related task packs, impact analysis, risk signals, and existing decision records
|
|
27
|
+
3. create an ASR when the direction is still being evaluated and an ADR when the decision is accepted enough to guide future work
|
|
28
|
+
4. write the record under `.hforge/runtime/decisions/` with context, decision, consequences, constraints, risks, and follow-up actions
|
|
29
|
+
5. update supersession or related-record links when the new decision changes an earlier one
|
|
30
|
+
|
|
31
|
+
## Output Contract
|
|
32
|
+
|
|
33
|
+
- a concise ASR or ADR with explicit status and rationale
|
|
34
|
+
- links to related tasks, impacts, and superseded records
|
|
35
|
+
- follow-up actions or open questions when the work is not fully settled
|
|
36
|
+
|
|
37
|
+
## Validation Path
|
|
38
|
+
|
|
39
|
+
- `.hforge/runtime/decisions/index.json`
|
|
40
|
+
- `schemas/runtime/decision-record.schema.json`
|
|
41
|
+
- `schemas/runtime/architecture-significance.schema.json`
|
|
42
|
+
|
|
43
|
+
## Failure Modes
|
|
44
|
+
|
|
45
|
+
- the real decision is still too vague to record
|
|
46
|
+
- there is not enough evidence to justify a durable record yet
|
|
47
|
+
- the new record conflicts with an existing one and the supersession path is unclear
|
|
48
|
+
|
|
49
|
+
## Escalation
|
|
50
|
+
|
|
51
|
+
- escalate when the decision changes public support or target guarantees
|
|
52
|
+
- escalate when migration or rollback cost is materially different across options
|
|
53
|
+
- escalate when a new record would contradict an existing accepted ADR
|
|
54
|
+
|
|
55
|
+
## References
|
|
56
|
+
|
|
57
|
+
- `skills/hforge-decide/references/decision-rubric.md`
|
|
58
|
+
- `skills/hforge-decide/references/output-contract.md`
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
# Decision rubric
|
|
2
|
+
|
|
3
|
+
Create or update a record when the choice affects one or more of these:
|
|
4
|
+
- runtime behavior
|
|
5
|
+
- package or bundle boundaries
|
|
6
|
+
- target support posture
|
|
7
|
+
- migration or rollback strategy
|
|
8
|
+
- validation, release, or maintenance guarantees
|
|
9
|
+
|
|
10
|
+
Prefer ASR when:
|
|
11
|
+
- exploration is still active
|
|
12
|
+
- the trade-offs are being narrowed
|
|
13
|
+
- the work needs a reviewable candidate before acceptance
|
|
14
|
+
|
|
15
|
+
Prefer ADR when:
|
|
16
|
+
- the direction is stable enough to guide future work
|
|
17
|
+
- the team needs a durable accepted rationale
|
|
18
|
+
- the decision supersedes an earlier record
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: hforge-init
|
|
3
|
+
description: initialize harness forge in the current repository, bootstrap the target-aware runtime, and establish the managed surfaces needed for later review, analysis, and decision tracking. use when the repo is not initialized, when runtime files are missing, or when the user asks to set up hforge in a project.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# HForge Init
|
|
7
|
+
|
|
8
|
+
## Trigger Signals
|
|
9
|
+
|
|
10
|
+
- the repository is not yet initialized for Harness Forge
|
|
11
|
+
- `.hforge/agent-manifest.json` or `.hforge/runtime/index.json` is missing
|
|
12
|
+
- target runtime files such as `.codex/` or `.claude/` are missing or incomplete
|
|
13
|
+
- the user asks to initialize, bootstrap, or wire Harness Forge into a repo
|
|
14
|
+
|
|
15
|
+
## Inspect First
|
|
16
|
+
|
|
17
|
+
- repository root files such as `README.md`, `package.json`, and CI or target config files
|
|
18
|
+
- `AGENTS.md` and `.agents/skills/` when present
|
|
19
|
+
- `.hforge/agent-manifest.json` and `.hforge/runtime/index.json` when present
|
|
20
|
+
- `.codex/` and `.claude/` bridge surfaces when present
|
|
21
|
+
|
|
22
|
+
## Workflow
|
|
23
|
+
|
|
24
|
+
1. inspect the current workspace state with `hforge status --root . --json`
|
|
25
|
+
2. if the repo is not initialized or target runtime files are absent, run `hforge bootstrap --root . --yes`
|
|
26
|
+
3. run `hforge refresh --root . --json` after bootstrap so shared runtime summaries are current
|
|
27
|
+
4. inspect `hforge catalog --json` when bundle or profile visibility matters
|
|
28
|
+
5. summarize detected targets, installed surfaces, runtime artifacts, and the recommended next command
|
|
29
|
+
|
|
30
|
+
## Output Contract
|
|
31
|
+
|
|
32
|
+
- initialization status and whether bootstrap was needed
|
|
33
|
+
- detected targets and managed runtime surfaces now present
|
|
34
|
+
- runtime artifacts now available under `.hforge/runtime/`
|
|
35
|
+
- the best next command to run, such as `/hforge-analyze` or `/hforge-review`
|
|
36
|
+
|
|
37
|
+
## Validation Path
|
|
38
|
+
|
|
39
|
+
- `hforge status --root . --json`
|
|
40
|
+
- `hforge bootstrap --root . --yes`
|
|
41
|
+
- `hforge refresh --root . --json`
|
|
42
|
+
|
|
43
|
+
## Failure Modes
|
|
44
|
+
|
|
45
|
+
- the repo is not writable
|
|
46
|
+
- the `hforge` launcher is not available
|
|
47
|
+
- target detection is incomplete or no supported target is installed yet
|
|
48
|
+
|
|
49
|
+
## Escalation
|
|
50
|
+
|
|
51
|
+
- escalate when bootstrap cannot write the project-owned runtime
|
|
52
|
+
- escalate when targets are ambiguous and the repo needs explicit operator intent
|
|
53
|
+
- escalate when package installation or shell setup is missing
|
|
54
|
+
|
|
55
|
+
## References
|
|
56
|
+
|
|
57
|
+
- `skills/hforge-init/references/bootstrap-order.md`
|
|
58
|
+
- `skills/hforge-init/references/output-contract.md`
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Bootstrap order
|
|
2
|
+
|
|
3
|
+
1. Run `hforge status --root . --json` first to avoid bootstrapping blindly.
|
|
4
|
+
2. Prefer `hforge bootstrap --root . --yes` when the repo needs one-pass setup.
|
|
5
|
+
3. Run `hforge refresh --root . --json` immediately after bootstrap so the runtime summary, repo intelligence, and generated indexes are current.
|
|
6
|
+
4. Only inspect `hforge catalog --json` after the workspace exists and targets are known.
|
|
7
|
+
5. If bare `hforge` is unavailable, use the workspace-local launcher under `.hforge/generated/bin/` once the repo is initialized.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Output contract
|
|
2
|
+
|
|
3
|
+
A good `/hforge-init` result should include:
|
|
4
|
+
- whether the repo was already initialized or required bootstrap
|
|
5
|
+
- detected target runtimes
|
|
6
|
+
- the highest-value managed surfaces now available
|
|
7
|
+
- the next recommended command and why it should be run next
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: hforge-refresh
|
|
3
|
+
description: refresh shared runtime summaries and generated harness forge artifacts after install changes, repo changes, or stale analysis state. use when the runtime is present but outdated, incomplete, or no longer trustworthy.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# HForge Refresh
|
|
7
|
+
|
|
8
|
+
## Trigger Signals
|
|
9
|
+
|
|
10
|
+
- runtime summaries are stale after installs or content changes
|
|
11
|
+
- repo-intelligence artifacts no longer match the current repository state
|
|
12
|
+
- the user explicitly asks to refresh the project-owned runtime
|
|
13
|
+
- a later review or analysis should not rely on outdated runtime state
|
|
14
|
+
|
|
15
|
+
## Inspect First
|
|
16
|
+
|
|
17
|
+
- `.hforge/runtime/index.json`
|
|
18
|
+
- `.hforge/generated/agent-command-catalog.json`
|
|
19
|
+
- `.hforge/runtime/repo/`
|
|
20
|
+
|
|
21
|
+
## Workflow
|
|
22
|
+
|
|
23
|
+
1. run `hforge refresh --root . --json`
|
|
24
|
+
2. follow with `hforge status --root . --json` when install-state confirmation matters
|
|
25
|
+
3. summarize regenerated artifacts, remaining gaps, and the best next action
|
|
26
|
+
|
|
27
|
+
## Output Contract
|
|
28
|
+
|
|
29
|
+
- confirmation that refresh ran or why it could not
|
|
30
|
+
- refreshed runtime artifacts and any remaining missing prerequisites
|
|
31
|
+
- the next command to run, usually `/hforge-analyze` or `/hforge-review`
|
|
32
|
+
|
|
33
|
+
## Validation Path
|
|
34
|
+
|
|
35
|
+
- `hforge refresh --root . --json`
|
|
36
|
+
- `hforge status --root . --json`
|
|
37
|
+
|
|
38
|
+
## Failure Modes
|
|
39
|
+
|
|
40
|
+
- the repo is not initialized
|
|
41
|
+
- required runtime files or launchers are missing
|
|
42
|
+
- refresh cannot reconcile the current install state
|
|
43
|
+
|
|
44
|
+
## Escalation
|
|
45
|
+
|
|
46
|
+
- escalate when refresh cannot complete without a fresh bootstrap
|
|
47
|
+
- escalate when runtime summaries regenerate but still disagree with the repo
|
|
48
|
+
|
|
49
|
+
## References
|
|
50
|
+
|
|
51
|
+
- `skills/hforge-refresh/references/refresh-order.md`
|
|
52
|
+
- `skills/hforge-refresh/references/output-contract.md`
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: hforge-review
|
|
3
|
+
description: runtime health review for harness forge workspaces. use when the user wants drift checks, decision coverage, stale task review, managed-surface integrity, or a clear pass-fail summary of the current runtime state.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# HForge Review
|
|
7
|
+
|
|
8
|
+
## Trigger Signals
|
|
9
|
+
|
|
10
|
+
- the user asks whether the current Harness Forge setup is healthy
|
|
11
|
+
- runtime drift, stale task artifacts, or missing managed surfaces are suspected
|
|
12
|
+
- a handoff, release, or package refresh needs a concise review first
|
|
13
|
+
- decision coverage and runtime governance need to be checked before moving on
|
|
14
|
+
|
|
15
|
+
## Inspect First
|
|
16
|
+
|
|
17
|
+
- `.hforge/runtime/index.json`
|
|
18
|
+
- `.hforge/runtime/decisions/index.json`
|
|
19
|
+
- `.hforge/runtime/tasks/`
|
|
20
|
+
- `.hforge/generated/agent-command-catalog.json`
|
|
21
|
+
- `.hforge/agent-manifest.json`
|
|
22
|
+
|
|
23
|
+
## Workflow
|
|
24
|
+
|
|
25
|
+
1. run `hforge review --root . --json`
|
|
26
|
+
2. if installation drift is suspected, run `hforge doctor --root . --json`
|
|
27
|
+
3. if package-surface integrity is suspected, run `hforge audit --root . --json`
|
|
28
|
+
4. summarize blockers, warnings, stale runtime artifacts, decision gaps, and the best cleanup order
|
|
29
|
+
|
|
30
|
+
## Output Contract
|
|
31
|
+
|
|
32
|
+
- runtime health summary with blocker, warning, and cleanup sections
|
|
33
|
+
- decision-coverage and stale-task callouts when relevant
|
|
34
|
+
- the next remediation command to run
|
|
35
|
+
|
|
36
|
+
## Validation Path
|
|
37
|
+
|
|
38
|
+
- `hforge review --root . --json`
|
|
39
|
+
- `hforge doctor --root . --json`
|
|
40
|
+
- `hforge audit --root . --json`
|
|
41
|
+
|
|
42
|
+
## Failure Modes
|
|
43
|
+
|
|
44
|
+
- the workspace is not initialized
|
|
45
|
+
- review signals are incomplete because runtime summaries are stale
|
|
46
|
+
- doctor or audit cannot read the current install state
|
|
47
|
+
|
|
48
|
+
## Escalation
|
|
49
|
+
|
|
50
|
+
- escalate when install drift risks losing managed state
|
|
51
|
+
- escalate when audit shows package-surface mismatches that need a maintainer fix
|
|
52
|
+
- escalate when runtime findings and source-of-truth manifests disagree
|
|
53
|
+
|
|
54
|
+
## References
|
|
55
|
+
|
|
56
|
+
- `skills/hforge-review/references/review-order.md`
|
|
57
|
+
- `skills/hforge-review/references/output-contract.md`
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Output contract
|
|
2
|
+
|
|
3
|
+
A good `/hforge-review` result should include:
|
|
4
|
+
- whether the runtime is healthy enough to trust
|
|
5
|
+
- what is stale, drifted, or missing
|
|
6
|
+
- what can be fixed by refresh versus what needs a maintainer change
|
|
7
|
+
- the single best next remediation step
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Review order
|
|
2
|
+
|
|
3
|
+
1. `hforge review --root . --json`
|
|
4
|
+
2. `.hforge/runtime/decisions/index.json`
|
|
5
|
+
3. `.hforge/runtime/tasks/`
|
|
6
|
+
4. `hforge doctor --root . --json` when managed surfaces look incomplete
|
|
7
|
+
5. `hforge audit --root . --json` when package-surface integrity matters
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: token-budget-optimizer
|
|
3
|
+
description: compact context, reuse existing runtime artifacts, and choose the smallest authoritative surface before expanding prompt history. use when the task is growing large, when earlier repo intelligence already exists, or when repeated rescans would waste tokens without adding new evidence.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Token Budget Optimizer
|
|
7
|
+
|
|
8
|
+
## Trigger Signals
|
|
9
|
+
|
|
10
|
+
- the prompt is getting long and earlier repo context is being repeated
|
|
11
|
+
- the repo already has `AGENTS.md`, `.hforge/runtime/`, specs, plans, or review artifacts that can answer the next question
|
|
12
|
+
- the task is investigative or iterative enough that careless re-reading will waste tokens
|
|
13
|
+
- the agent is about to scan broad directory trees before checking existing runtime summaries
|
|
14
|
+
|
|
15
|
+
## Inspect First
|
|
16
|
+
|
|
17
|
+
- `.hforge/agent-manifest.json` and `.hforge/generated/agent-command-catalog.json`
|
|
18
|
+
- `.hforge/runtime/index.json`, `.hforge/runtime/repo/repo-map.json`, and `.hforge/runtime/repo/recommendations.json`
|
|
19
|
+
- active guidance bridges such as `AGENTS.md`, `CLAUDE.md`, and `.agents/skills/<skill>/SKILL.md`
|
|
20
|
+
- any existing `spec.md`, `plan.md`, `tasks.md`, review output, or decision record relevant to the current task
|
|
21
|
+
- `skills/token-budget-optimizer/scripts/inspect_token_surfaces.py` when a deterministic token-surface audit would help
|
|
22
|
+
|
|
23
|
+
## Workflow
|
|
24
|
+
|
|
25
|
+
1. identify the concrete question the agent must answer next and avoid reading more than that question requires
|
|
26
|
+
2. rank existing surfaces by authority, freshness, and cost, preferring hidden runtime summaries and durable artifacts before broad source scans
|
|
27
|
+
3. reuse prior findings, repo maps, decision records, and task artifacts instead of re-deriving them from scratch
|
|
28
|
+
4. compact the active context into a short working set: current goal, authoritative surfaces, open questions, and the next small evidence step
|
|
29
|
+
5. escalate to deeper reads only when the compacted working set cannot answer the task safely
|
|
30
|
+
|
|
31
|
+
## Output Contract
|
|
32
|
+
|
|
33
|
+
- a short context budget summary with the current goal and the smallest authoritative surfaces to keep loaded
|
|
34
|
+
- a reuse plan listing which runtime artifacts, docs, or task artifacts should be trusted instead of reread
|
|
35
|
+
- compaction candidates describing what can be summarized once and then dropped from active context
|
|
36
|
+
- unresolved gaps that still require new evidence or deeper file reads
|
|
37
|
+
|
|
38
|
+
## Failure Modes
|
|
39
|
+
|
|
40
|
+
- runtime artifacts are stale, missing, or do not cover the active question
|
|
41
|
+
- the task is genuinely novel and prior summaries are no longer trustworthy
|
|
42
|
+
- the agent mistakes low-cost summaries for high-authority truth and skips required verification
|
|
43
|
+
|
|
44
|
+
## Escalation
|
|
45
|
+
|
|
46
|
+
- escalate when the repo has conflicting guidance across `AGENTS.md`, runtime summaries, and product code
|
|
47
|
+
- escalate when token saving would hide a risky detail such as a release gate, migration step, or support constraint
|
|
48
|
+
- escalate when there is no reliable compact surface and the agent must build a new authoritative summary first
|
|
49
|
+
|
|
50
|
+
## References
|
|
51
|
+
|
|
52
|
+
- `skills/token-budget-optimizer/references/audit-dimensions.md`
|
|
53
|
+
- `skills/token-budget-optimizer/references/promotion-ladder.md`
|
|
54
|
+
- `skills/token-budget-optimizer/references/scoring-model.md`
|
|
55
|
+
- `skills/token-budget-optimizer/references/report-template.md`
|
|
56
|
+
- `skills/token-budget-optimizer/scripts/inspect_token_surfaces.py`
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Token Surface Audit Dimensions
|
|
2
|
+
|
|
3
|
+
Use these dimensions when deciding whether a surface deserves active context.
|
|
4
|
+
|
|
5
|
+
## Authority
|
|
6
|
+
|
|
7
|
+
- highest: generated or maintained runtime truth such as `.hforge/agent-manifest.json`, `.hforge/generated/agent-command-catalog.json`, and current runtime indexes
|
|
8
|
+
- medium: maintained docs and active skill contracts
|
|
9
|
+
- lower: old notes, ad-hoc chat summaries, or broad source scans without task focus
|
|
10
|
+
|
|
11
|
+
## Freshness
|
|
12
|
+
|
|
13
|
+
- prefer artifacts regenerated after the latest repo changes
|
|
14
|
+
- downgrade summaries that predate major install, refresh, or architecture changes
|
|
15
|
+
- if freshness is unclear, verify with `status`, `refresh`, or a targeted file read
|
|
16
|
+
|
|
17
|
+
## Reuse value
|
|
18
|
+
|
|
19
|
+
- high when the surface already answers the current question directly
|
|
20
|
+
- medium when the surface narrows the search space meaningfully
|
|
21
|
+
- low when the surface only restates generic repo facts or marketing prose
|
|
22
|
+
|
|
23
|
+
## Token cost
|
|
24
|
+
|
|
25
|
+
- very low: compact JSON summaries, short skill wrappers, direct command catalogs
|
|
26
|
+
- medium: short markdown guides and specific reference docs
|
|
27
|
+
- high: large source trees, broad recursive scans, or entire repo reviews with no focus
|
|
28
|
+
|
|
29
|
+
## Risk of omission
|
|
30
|
+
|
|
31
|
+
- high risk means the surface guards support claims, release gates, migrations, security rules, or architecture decisions
|
|
32
|
+
- low risk means the surface is descriptive but not safety-critical
|
|
33
|
+
|
|
34
|
+
## Recommended decision rule
|
|
35
|
+
|
|
36
|
+
Keep in active context only the smallest set of high-authority, sufficiently
|
|
37
|
+
fresh surfaces that answer the current question without hiding a known risk.
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
# Context Promotion Ladder
|
|
2
|
+
|
|
3
|
+
Use this ladder to decide what belongs in active prompt context.
|
|
4
|
+
|
|
5
|
+
## Level 1: Discovery only
|
|
6
|
+
|
|
7
|
+
- wrappers in `.agents/skills/`
|
|
8
|
+
- short command docs
|
|
9
|
+
- repo root guidance bridges
|
|
10
|
+
|
|
11
|
+
Use these to choose the next canonical surface quickly.
|
|
12
|
+
|
|
13
|
+
## Level 2: Canonical operating surfaces
|
|
14
|
+
|
|
15
|
+
- `.hforge/agent-manifest.json`
|
|
16
|
+
- `.hforge/generated/agent-command-catalog.json`
|
|
17
|
+
- canonical skill contracts under `.hforge/library/skills/`
|
|
18
|
+
- runtime indexes and repo summaries
|
|
19
|
+
|
|
20
|
+
Prefer these before reading broad product code.
|
|
21
|
+
|
|
22
|
+
## Level 3: Task-bound artifacts
|
|
23
|
+
|
|
24
|
+
- spec, plan, and task documents
|
|
25
|
+
- task-runtime artifacts
|
|
26
|
+
- decision records
|
|
27
|
+
- review summaries and validation outputs
|
|
28
|
+
|
|
29
|
+
Promote these when the work is already scoped and historical context matters.
|
|
30
|
+
|
|
31
|
+
## Level 4: Focused code evidence
|
|
32
|
+
|
|
33
|
+
- only the files needed to resolve an active question
|
|
34
|
+
- only the specific function, module, schema, or config block that matters
|
|
35
|
+
|
|
36
|
+
Do not jump here until the earlier levels stop being enough.
|
|
37
|
+
|
|
38
|
+
## Level 5: Broad exploratory scans
|
|
39
|
+
|
|
40
|
+
- full repo walks
|
|
41
|
+
- many-file comparisons
|
|
42
|
+
- recursive investigation sessions
|
|
43
|
+
|
|
44
|
+
Use these only when lower-cost surfaces cannot answer the question safely.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Token Budget Report Template
|
|
2
|
+
|
|
3
|
+
## Current goal
|
|
4
|
+
|
|
5
|
+
- What question must be answered next?
|
|
6
|
+
|
|
7
|
+
## Keep loaded
|
|
8
|
+
|
|
9
|
+
- Which 3-6 surfaces are authoritative enough to stay in active context?
|
|
10
|
+
|
|
11
|
+
## Reuse instead of reread
|
|
12
|
+
|
|
13
|
+
- Which runtime artifacts, prior summaries, or task docs already cover the needed context?
|
|
14
|
+
|
|
15
|
+
## Compact and drop
|
|
16
|
+
|
|
17
|
+
- Which broad notes, repeated chat summaries, or low-authority reads can be collapsed into one sentence and removed from active context?
|
|
18
|
+
|
|
19
|
+
## New evidence still required
|
|
20
|
+
|
|
21
|
+
- Which focused files or commands still need to be read or run?
|
|
22
|
+
|
|
23
|
+
## Risk notes
|
|
24
|
+
|
|
25
|
+
- What important detail would be dangerous to over-compress?
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
# Token Budget Scoring Model
|
|
2
|
+
|
|
3
|
+
Use a simple score to compare candidate context surfaces.
|
|
4
|
+
|
|
5
|
+
## Formula
|
|
6
|
+
|
|
7
|
+
`score = authority + freshness + reuseValue - tokenCost - ambiguityPenalty`
|
|
8
|
+
|
|
9
|
+
Each dimension can be scored from `0` to `3`.
|
|
10
|
+
|
|
11
|
+
## Guidance
|
|
12
|
+
|
|
13
|
+
- authority:
|
|
14
|
+
- `3` canonical machine-readable runtime truth
|
|
15
|
+
- `2` maintained human-readable canonical docs
|
|
16
|
+
- `1` narrow ad-hoc notes or inferred summaries
|
|
17
|
+
- `0` stale or untrusted context
|
|
18
|
+
- freshness:
|
|
19
|
+
- `3` generated or edited after the relevant change
|
|
20
|
+
- `2` likely current but not recently verified
|
|
21
|
+
- `1` possibly stale
|
|
22
|
+
- `0` known stale
|
|
23
|
+
- reuseValue:
|
|
24
|
+
- `3` directly answers the next question
|
|
25
|
+
- `2` sharply narrows what must be read next
|
|
26
|
+
- `1` weakly helpful
|
|
27
|
+
- `0` mostly decorative
|
|
28
|
+
- tokenCost:
|
|
29
|
+
- `3` large or diffuse
|
|
30
|
+
- `2` moderate
|
|
31
|
+
- `1` small
|
|
32
|
+
- `0` tiny
|
|
33
|
+
- ambiguityPenalty:
|
|
34
|
+
- `3` likely to mislead without verification
|
|
35
|
+
- `2` needs careful cross-checking
|
|
36
|
+
- `1` low ambiguity
|
|
37
|
+
- `0` explicit and stable
|
|
38
|
+
|
|
39
|
+
## Usage rule
|
|
40
|
+
|
|
41
|
+
Prefer the smallest set of surfaces with the highest positive score, then
|
|
42
|
+
validate any high-risk claim with one focused evidence read instead of a broad
|
|
43
|
+
context expansion.
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
#!/usr/bin/env python3
|
|
2
|
+
"""Inspect likely high-value context surfaces for token-efficient agent work."""
|
|
3
|
+
|
|
4
|
+
from __future__ import annotations
|
|
5
|
+
|
|
6
|
+
import json
|
|
7
|
+
import sys
|
|
8
|
+
from pathlib import Path
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
SURFACES = [
|
|
12
|
+
("AGENTS.md", "guidance", 3, 3, 3, 1),
|
|
13
|
+
("CLAUDE.md", "guidance", 3, 3, 2, 1),
|
|
14
|
+
(".hforge/agent-manifest.json", "runtime", 3, 3, 3, 1),
|
|
15
|
+
(".hforge/generated/agent-command-catalog.json", "runtime", 3, 3, 3, 1),
|
|
16
|
+
(".hforge/runtime/index.json", "runtime", 3, 3, 2, 1),
|
|
17
|
+
(".hforge/runtime/repo/repo-map.json", "runtime", 3, 2, 3, 1),
|
|
18
|
+
(".hforge/runtime/repo/recommendations.json", "runtime", 3, 2, 3, 1),
|
|
19
|
+
(".hforge/runtime/repo/instruction-plan.json", "runtime", 3, 2, 2, 1),
|
|
20
|
+
("README.md", "docs", 2, 2, 1, 2),
|
|
21
|
+
(".specify/spec.md", "workflow", 2, 2, 3, 2),
|
|
22
|
+
(".specify/plan.md", "workflow", 2, 2, 3, 2),
|
|
23
|
+
(".specify/tasks.md", "workflow", 2, 2, 3, 2),
|
|
24
|
+
]
|
|
25
|
+
|
|
26
|
+
|
|
27
|
+
def score(authority: int, freshness: int, reuse_value: int, token_cost: int) -> int:
|
|
28
|
+
return authority + freshness + reuse_value - token_cost
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
def main() -> int:
|
|
32
|
+
root = Path(sys.argv[1]).resolve() if len(sys.argv) > 1 else Path.cwd().resolve()
|
|
33
|
+
found = []
|
|
34
|
+
missing = []
|
|
35
|
+
|
|
36
|
+
for relative_path, category, authority, freshness, reuse_value, token_cost in SURFACES:
|
|
37
|
+
absolute_path = root / relative_path
|
|
38
|
+
entry = {
|
|
39
|
+
"path": relative_path,
|
|
40
|
+
"category": category,
|
|
41
|
+
"score": score(authority, freshness, reuse_value, token_cost),
|
|
42
|
+
"authority": authority,
|
|
43
|
+
"freshness": freshness,
|
|
44
|
+
"reuseValue": reuse_value,
|
|
45
|
+
"tokenCost": token_cost,
|
|
46
|
+
}
|
|
47
|
+
if absolute_path.exists():
|
|
48
|
+
entry["sizeBytes"] = absolute_path.stat().st_size
|
|
49
|
+
found.append(entry)
|
|
50
|
+
else:
|
|
51
|
+
missing.append(entry)
|
|
52
|
+
|
|
53
|
+
found.sort(key=lambda item: (-item["score"], item["path"]))
|
|
54
|
+
missing.sort(key=lambda item: (-item["score"], item["path"]))
|
|
55
|
+
|
|
56
|
+
result = {
|
|
57
|
+
"workspaceRoot": str(root),
|
|
58
|
+
"recommendedKeepLoaded": found[:6],
|
|
59
|
+
"recommendedFallbackReads": found[6:10],
|
|
60
|
+
"missingButUseful": missing[:6],
|
|
61
|
+
}
|
|
62
|
+
json.dump(result, sys.stdout, indent=2)
|
|
63
|
+
sys.stdout.write("\n")
|
|
64
|
+
return 0
|
|
65
|
+
|
|
66
|
+
|
|
67
|
+
if __name__ == "__main__":
|
|
68
|
+
raise SystemExit(main())
|