@open-agent-toolkit/cli 0.1.63 → 0.1.64
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/assets/agents/oat-phase-implementer.md +9 -1
- package/assets/agents/oat-reviewer.md +8 -1
- package/assets/docs/contributing/skills.md +22 -0
- package/assets/docs/workflows/projects/artifacts.md +30 -0
- package/assets/docs/workflows/projects/dispatch-ceiling.md +13 -0
- package/assets/public-package-versions.json +4 -4
- package/assets/skills/oat-project-autonomous/references/gate-inventory.md +165 -165
- package/assets/skills/oat-project-document/SKILL.md +8 -1
- package/assets/skills/oat-project-document/references/docs/autonomy-contract.md +165 -165
- package/assets/skills/oat-project-implement/references/docs/autonomy-contract.md +165 -165
- package/assets/skills/oat-project-plan-writing/SKILL.md +48 -12
- package/assets/skills/oat-project-pr-final/SKILL.md +9 -1
- package/assets/skills/oat-project-pr-final/references/docs/autonomy-contract.md +165 -165
- package/assets/skills/oat-project-quick-start/SKILL.md +8 -1
- package/assets/skills/oat-project-quick-start/references/docs/autonomy-contract.md +165 -165
- package/assets/skills/oat-project-review-provide/SKILL.md +9 -1
- package/assets/skills/oat-project-review-receive/SKILL.md +9 -1
- package/assets/skills/oat-project-summary/SKILL.md +8 -1
- package/dist/commands/gate/index.d.ts.map +1 -1
- package/dist/commands/gate/index.js +4 -1
- package/package.json +2 -2
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: oat-phase-implementer
|
|
3
|
-
version: 1.0.
|
|
3
|
+
version: 1.0.8
|
|
4
4
|
description: Implements one plan phase end-to-end, commits each task separately, self-checks between tasks, and handles bounded review fixes when resumed by oat-project-implement.
|
|
5
5
|
tools: Read, Write, Edit, Bash, Grep, Glob, Task
|
|
6
6
|
color: cyan
|
|
@@ -90,6 +90,14 @@ Read each required artifact once at phase start:
|
|
|
90
90
|
Extract all phase tasks, dependency order, file boundaries, verification
|
|
91
91
|
commands, commit messages, and phase-wide verification before editing.
|
|
92
92
|
|
|
93
|
+
## Artifact Hygiene
|
|
94
|
+
|
|
95
|
+
Artifact hygiene contract: Before finishing or committing, format every file you created or edited. Use the concrete write/fix formatting command supplied by the governing plan, task, or brief. If none is usable, discover the repository's documented write/fix command from applicable `AGENTS.md`/`CLAUDE.md` instructions and relevant package manifests; do not infer or hardcode a formatter. Prefer a file-scoped invocation when supported, and avoid rewriting unrelated files. If no command is discoverable, warn once with `no format command discovered in repo instructions; skipping`, then continue.
|
|
96
|
+
|
|
97
|
+
After formatting, run the repository's applicable gate set over the produced
|
|
98
|
+
diff, explicitly including artifact writes. This supplements rather than
|
|
99
|
+
replaces every task and phase verification command below.
|
|
100
|
+
|
|
93
101
|
## Mode: Implement
|
|
94
102
|
|
|
95
103
|
### 1. Verify Phase Base
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: oat-reviewer
|
|
3
|
-
version: 1.1.
|
|
3
|
+
version: 1.1.7
|
|
4
4
|
description: Unified reviewer for OAT projects - mode-aware verification of requirements/design alignment and code quality. Writes a review artifact to disk by default, or returns structured findings in-memory when dispatched in structured-output mode.
|
|
5
5
|
tools: Read, Bash, Grep, Glob, Write
|
|
6
6
|
color: yellow
|
|
@@ -84,6 +84,13 @@ Use workflow mode to determine required evidence:
|
|
|
84
84
|
Do not mark missing optional artifacts as findings.
|
|
85
85
|
If required artifacts for the mode are unexpectedly missing, record a workflow contract gap.
|
|
86
86
|
|
|
87
|
+
## Artifact Hygiene
|
|
88
|
+
|
|
89
|
+
Artifact hygiene contract: Before finishing or committing, format every file you created or edited. Use the concrete write/fix formatting command supplied by the governing plan, task, or brief. If none is usable, discover the repository's documented write/fix command from applicable `AGENTS.md`/`CLAUDE.md` instructions and relevant package manifests; do not infer or hardcode a formatter. Prefer a file-scoped invocation when supported, and avoid rewriting unrelated files. If no command is discoverable, warn once with `no format command discovered in repo instructions; skipping`, then continue.
|
|
90
|
+
|
|
91
|
+
After formatting, run only repository checks relevant to the files changed;
|
|
92
|
+
writing a prose artifact does not imply unrelated full test suites.
|
|
93
|
+
|
|
87
94
|
## Process
|
|
88
95
|
|
|
89
96
|
### Step 1: Load Artifacts
|
|
@@ -56,6 +56,28 @@ Skill behavior is defined by frontmatter plus the process contract in each `SKIL
|
|
|
56
56
|
- Keep `AGENTS.md` skills table synchronized with `.agents/skills`.
|
|
57
57
|
- Require explicit user approval for destructive or state-advancing transitions.
|
|
58
58
|
|
|
59
|
+
### Artifact-writing hygiene
|
|
60
|
+
|
|
61
|
+
Every role or skill that creates or edits tracked output must include the
|
|
62
|
+
artifact hygiene contract at its writing boundary. The writer uses a concrete
|
|
63
|
+
write/fix formatting command supplied by its plan, task, or brief. If none is
|
|
64
|
+
usable, it discovers the repository's documented command from applicable
|
|
65
|
+
`AGENTS.md` / `CLAUDE.md` instructions and relevant package manifests.
|
|
66
|
+
|
|
67
|
+
Contracts must distinguish write/fix commands from check-only commands, prefer
|
|
68
|
+
a file-scoped invocation when supported, avoid unrelated whole-tree rewrites,
|
|
69
|
+
and never infer or hardcode a formatter. If no command can be discovered, the
|
|
70
|
+
writer warns once with
|
|
71
|
+
`no format command discovered in repo instructions; skipping` and continues.
|
|
72
|
+
Run only verification relevant to the changed files unless the role's
|
|
73
|
+
definition of done requires broader gates.
|
|
74
|
+
|
|
75
|
+
For planned implementation, plan-producing skills resolve this command once and
|
|
76
|
+
place it in every artifact-writing task. Runtime discovery remains the fallback
|
|
77
|
+
for direct lifecycle writers and incomplete or stale plans. When the same
|
|
78
|
+
contract crosses dispatch boundaries, keep each copy self-contained and protect
|
|
79
|
+
equivalence with contract tests.
|
|
80
|
+
|
|
59
81
|
## Recommended Starting Points
|
|
60
82
|
|
|
61
83
|
- Use `create-oat-skill` when the new skill belongs to an OAT lifecycle or maintenance flow.
|
|
@@ -57,6 +57,36 @@ Manual and auto review artifacts do not require the gate-only fields.
|
|
|
57
57
|
|
|
58
58
|
Artifacts are the project system of record; automation and routing should derive from these files, not memory.
|
|
59
59
|
|
|
60
|
+
### Formatting and verification hygiene
|
|
61
|
+
|
|
62
|
+
Tracked artifacts are part of the repository diff, so artifact writers format
|
|
63
|
+
them before finishing or committing. During plan authoring, OAT resolves the
|
|
64
|
+
repository's documented write/fix command from applicable `AGENTS.md` /
|
|
65
|
+
`CLAUDE.md` instructions and relevant package manifests. Each task that writes
|
|
66
|
+
an artifact receives a concrete invocation, scoped to that task's files when
|
|
67
|
+
the command supports paths.
|
|
68
|
+
|
|
69
|
+
Downstream implementers execute that supplied command without repeating
|
|
70
|
+
discovery. Roles and lifecycle skills that write outside a planned task,
|
|
71
|
+
including reviewers and documentation, summary, PR, and quick-start flows, use
|
|
72
|
+
the same discovery procedure as a fallback. Gate-originated review prompts also
|
|
73
|
+
carry the contract so review artifacts follow the same rule across runtimes.
|
|
74
|
+
|
|
75
|
+
Writers must:
|
|
76
|
+
|
|
77
|
+
- prefer a documented write/fix command over a check-only command;
|
|
78
|
+
- avoid inferring or hardcoding a formatter;
|
|
79
|
+
- scope the write to created or edited files when supported;
|
|
80
|
+
- avoid whole-tree rewrites that could absorb unrelated changes; and
|
|
81
|
+
- warn once with
|
|
82
|
+
`no format command discovered in repo instructions; skipping` when no command
|
|
83
|
+
is discoverable, then continue.
|
|
84
|
+
|
|
85
|
+
Formatting supplements the applicable verification contract. Phase
|
|
86
|
+
implementation runs repository gates over its produced diff, including
|
|
87
|
+
artifact writes. Prose-only lifecycle work runs only checks relevant to the
|
|
88
|
+
files it changed.
|
|
89
|
+
|
|
60
90
|
## Coordination parents
|
|
61
91
|
|
|
62
92
|
Project splitting introduces a coordination-only parent artifact. It records shared context and child relationships, but it is not an executable lifecycle project.
|
|
@@ -64,6 +64,19 @@ existing cells. Planning shows the complete recommendation before asking which
|
|
|
64
64
|
scope should own it. If the resulting ladder is still missing or incomplete,
|
|
65
65
|
planning remains blocked rather than replacing the user's explicit values.
|
|
66
66
|
|
|
67
|
+
Before offering adoption, planning runs `oat config list --json` once and treats
|
|
68
|
+
its output as the effective boundary across shared, repo-local, user, and
|
|
69
|
+
bundled-default precedence. A complete effective ladder skips adoption even
|
|
70
|
+
when the current project has not selected a policy or named ceiling. Adoption
|
|
71
|
+
is offered only when the resolved provider/tier cells are actually missing,
|
|
72
|
+
empty, malformed, or incomplete.
|
|
73
|
+
|
|
74
|
+
Ladder completeness and project-ceiling selection are separate checks. In
|
|
75
|
+
particular, `oat project dispatch-ceiling resolve` returning `matrix: null` can
|
|
76
|
+
mean that the project policy or ceiling is unresolved; it does not prove that
|
|
77
|
+
the effective reusable ladders are absent. When ladders are complete, planning
|
|
78
|
+
proceeds directly to the project-specific policy choice.
|
|
79
|
+
|
|
67
80
|
The ownership boundary is deliberate:
|
|
68
81
|
|
|
69
82
|
| Source | Config location | Codex materialization output |
|