fix(kyberforge): resolve PR #91 review findings in apm docs and orchestrators
Addresses 7 verified findings from the /code-review pass on PR #91's APM-conversion changes: - apm-workflow's description omitted install triggers, misrouting "install my apm dependencies" requests to apm-install instead - `apm marketplace check` was listed under both the marketplace and audit dispatch rows, breaking the "one reference file per action" contract; kept under marketplace.md, its real usage-sequence home - ADR-0015 claimed apm-workflow docs are generic/repo-agnostic while marketplace.md cited this repo's AGENTS.md and git-commits/ git-remotes skills by name; stripped the holocron-specific citations (marketplace.md, compile.md) so the claim now holds - plugin-author/marketplace-author are superseded per ADR-0015 with deletion deferred to #90; added deprecation notices pointing to the replacing apm-workflow dispatch actions - apm-orchestrate/gitea-orchestrate/git-orchestrate all instruct dispatch "via Skill" without granting the Skill tool; added it to all three - apm-orchestrate mandated strictly sequential fan-out across independent packages with no shared state; relaxed to permit parallel dispatch, matching this repo's own subagent-parallelization guidance Refs: #91
This commit is contained in:
@@ -3,7 +3,7 @@ name: apm-orchestrate
|
||||
|
||||
description: Orchestrates apm package/marketplace operations for other agents. Invoke when a caller needs a multi-step apm operation (scaffold a package, register it into a marketplace, compile/pack/publish, audit) coordinated across the apm-workflow skill with safety gates, session context, and structured results — especially fanning the same operation out across multiple packages in a monorepo.
|
||||
|
||||
tools: Bash, Read
|
||||
tools: Bash, Read, Skill
|
||||
|
||||
source_keys:
|
||||
- context7-microsoft-apm
|
||||
@@ -31,7 +31,7 @@ When invoked, you:
|
||||
3. Route to `apm-workflow` with the resolved action (`configure`, `marketplace`, `install`, `compile`, `audit`)
|
||||
4. Manage session context: carry forward each package's root directory and any registry/marketplace config already resolved this session
|
||||
5. Handle error recovery: for recoverable failures (a stale lockfile, a marketplace ref that doesn't resolve yet because a dependency package hasn't been scaffolded), retry after the caller confirms the dependency now exists; for unrecoverable failures, fail gracefully with actionable diagnostics
|
||||
6. When fanning an operation across multiple packages (e.g. `init-package` for every `plugins/<name>/` directory in a monorepo-hybrid conversion), dispatch one package at a time and continue past a single package's failure rather than aborting the whole batch — collect all failures and report them together at the end
|
||||
6. When fanning an operation across multiple packages (e.g. `init-package` for every `plugins/<name>/` directory in a monorepo-hybrid conversion), dispatch independent packages in parallel when no shared state or ordering dependency exists between them; keep dispatch strictly sequential only for packages with a real dependency on another package's completion (e.g. a marketplace registration that needs a dependency package scaffolded first). Either way, continue past a single package's failure rather than aborting the whole batch — collect all failures and report them together at the end
|
||||
7. Aggregate results and return structured JSON output suitable for agent chaining
|
||||
|
||||
## Inputs
|
||||
@@ -54,7 +54,7 @@ When invoked, you:
|
||||
3. If `operation` is `publish`: require `confirm: true`, dispatch `--dry-run -v` first regardless, surface that output, else fail with structured "requires explicit confirmation" error
|
||||
4. Verify `apm --version` succeeds; if not, fail with a diagnostic pointing to `apm-install`
|
||||
5. Invoke `apm-workflow` via `Skill` with the resolved action, `package_root`, and parameters
|
||||
6. If fanning across multiple packages, loop package-by-package, collecting per-package results and failures rather than aborting on the first failure
|
||||
6. If fanning across multiple packages, dispatch independent packages in parallel when no shared state or ordering dependency exists between them; loop package-by-package (strictly sequential) only for packages with a real dependency on another package's completion. Either way, collect per-package results and failures rather than aborting on the first failure
|
||||
7. Catch and handle apm errors: retry once for a dependency-not-yet-scaffolded failure after the caller confirms the dependency exists; otherwise return error structure with diagnostics
|
||||
8. Aggregate all outputs and return as structured JSON
|
||||
|
||||
|
||||
Reference in New Issue
Block a user