Skill manifest metadata (6.3.1)#344
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (11)
👮 Files not reviewed due to content moderation or server errors (11)
OverviewThis pull request implements roadmap item 6.3.1 ("Add skill manifest metadata to agent context") by introducing a new agent-context schema extension via an accompanying ExecPlan document ( Code changesSchema additions in
Dependency and re-export updates:
Test coverage:
Documentation updatesThe ExecPlan document specifies the intended wire-contract shape and defers manifest parsing, validation, and CLI integration to later roadmap items (6.3.2 and 6.2.1). Related documentation updates across multiple guides ( Design notesThe implementation incorporates three recommendations from the pre-mortem review: a stable DeferralManifest validation, parsing, prose loading, and WalkthroughIntroduces two new exported schema types — ChangesSkill Manifest Metadata (roadmap 6.3.1)
Possibly Related PRs
Suggested Labels
Suggested Reviewers
Poem
🚥 Pre-merge checks | ✅ 20✅ Passed checks (20 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Reviewer's GuideAdds a detailed ExecPlan document for roadmap item 6.3.1 describing how to model skill manifest metadata in ortho_config::agent_context (including new SkillManifest / SkillCommandRef types and AgentContext.skill_manifests field), links it from the docs contents index, and records constraints, risks, milestones, and design decisions without yet changing any Rust code. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
leynos
changed the title
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
lodyai
Bot
force-pushed
the
6-3-1-skill-manifest-metadata
branch
from
30eb647 to
2fa13f7
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Large Methodortho_config/src/agent_context/tests.rs: agent_context_json_snapshot_covers_wire_contract What lead to degradation?agent_context_json_snapshot_covers_wire_contract has 80 lines, threshold = 70 Why does this problem occur?Overly long functions make the code harder to read. The recommended maximum function length for the Rust language is 70 lines of code. Severity: Brain Method - Complex Method - Long Method. How to fix it?We recommend to be careful here -- just splitting long functions don't necessarily make the code easier to read. Instead, look for natural chunks inside the functions that expresses a specific task or concern. Often, such concerns are indicated by a Code Comment followed by an if-statement. Use the EXTRACT FUNCTION refactoring to encapsulate that concern. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Add `docs/execplans/6-3-1-skill-manifest-metadata.md` covering roadmap
item 6.3.1 as a passive-schema addition to `ortho_config::agent_context`.
The plan introduces two additive types, `SkillManifest` and
`SkillCommandRef`, plus a `skill_manifests: Vec<SkillManifest>` field on
`AgentContext` (with `#[serde(default)]`), and renames the §8.1 defaults
row in `docs/agent-native-cli-design.md` from `skill_manifest_paths` to
`skill_manifests` to match the structured-descriptor shape.
The plan is built on Firecrawl prior-art research (Anthropic Claude
Skills, MCP tool listings, OpenAI `ai-plugin.json`, Microsoft 365
Copilot v2.1, Fig autocomplete) and a Logisphere design review that
recommended adding `id: String` to `SkillManifest`, documenting
`SkillCommandRef.{path,flags}` as exact-match contracts against
`AgentCommand.path` and `AgentInput.long`, and reserving room in
`SkillManifest::path` for future non-filesystem sources. All three
recommendations are folded into the recommended design.
Status: DRAFT, awaiting maintainer approval before Milestone 1 may
begin. Validation, parsing, and any `cargo-orthohelp` flag work are
deferred to roadmap item 6.3.2. Link the plan from `docs/contents.md`.
Record the maintainer's 2026-06-12 confirmation that referencing ADR-003 is sufficient for the `skill_manifest_paths` to `skill_manifests` wire-field rename, so no new ADR is required. Update Milestone 0, the design overview, the Decision Log, and Progress to reflect the closed question.
The decision nodes in the migration-guide flowchart carried raw newlines
inside their `{...}` labels, which the stricter `merman-cli` lexer used
by `make nixie` rejects with "Unterminated node label (missing `}`)".
Put each node label on a single physical line and use `<br/>` for the
intended visual breaks so the diagram renders identically and the gate
passes.
Also record the maintainer's approval of the 6.3.1 ExecPlan: status is
now `APPROVED`, and the approval and ADR-question resolution are noted in
the plan's Progress section.
Roadmap item 6.2.1 merged on main (pull request 342) while this plan was a draft, landing the `cargo orthohelp --format agent-context` generator and adding an additive `AgentCommand.summary` field. Update the plan to reflect the new baseline after rebasing onto `origin/main`: - reframe the "Dependency on roadmap item 6.2.1" section: the prerequisite is now satisfied, and the additive `#[serde(default)]` `skill_manifests` field is tolerated by the existing generator without modification; - correct the `mod.rs` and `tests.rs` line counts (254 and 272) and note that the wire snapshot now carries the 6.2.1 `summary` field, so Milestones 2 and 3 extend the current snapshot rather than the pre-6.2.1 one; - downgrade the roadmap-dependency-confusion risk now that 6.2.1 has landed; - record the rebase and reconciliation in Progress, Surprises, and the revision note. The proposed `skill_manifests` field and the `SkillManifest` and `SkillCommandRef` types are unaffected by 6.2.1. All gates pass after the rebase: check-fmt, typecheck, lint, test, markdownlint, and nixie.
Add `SkillManifest` and `SkillCommandRef` to the agent-context schema module and re-export them from `ortho_config` so downstream crates can construct manifest descriptors without involving `cargo-orthohelp`. Enable `camino`'s serde integration for the typed manifest path field and record the Milestone 1 validation outcome in the ExecPlan.
Add the defaulted `skill_manifests` field to `AgentContext` and initialize it from `AgentContext::new` so legacy payloads continue to deserialize with an empty list. Update the existing inline and generated agent-context snapshots to capture the additive wire shape, and record the Milestone 2 validation outcome in the ExecPlan.
Add focused `rstest` coverage for skill manifest defaulting, typed path serialization, command-reference flag defaults, and required manifest fields. Populate the canonical agent-context unit fixture with one manifest so the inline snapshot captures the structured wire shape expected by downstream consumers.
Align the design, users guide, developer guide, changelog, and roadmap with the new agent-context skill manifest descriptors. Record Milestone 4 validation and close roadmap item 6.3.1 in the ExecPlan after deterministic gates and CodeRabbit review passed.
Mark PR 344 as ready in the ExecPlan after validation, CodeRabbit review, and the GitHub draft-to-ready transition completed.
Move the large inline agent-context JSON snapshot into an insta file snapshot so the test body stays small while preserving the full wire contract assertion.
lodyai
Bot
force-pushed
the
6-3-1-skill-manifest-metadata
branch
from
351245a to
ef21535
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
2 participants
Summary
metadata as additive types in
ortho_config::agent_context(
SkillManifest,SkillCommandRef) plus a defaultedAgentContext.skill_manifestsfield. The full plan is atdocs/execplans/6-3-1-skill-manifest-metadata.md.id: Stringon eachSkillManifest, exact-match contracts betweenSkillCommandRef.{path,flags}andAgentCommand.path/AgentInput.long,and a forward-compatibility note on
SkillManifest::pathso futurenon-filesystem sources stay an open door.
docs/agent-native-cli-design.mdfromskill_manifest_pathstoskill_manifestsso the documented defaultmatches the structured shape (no shipped consumer reads the old name;
the rename is documentation-only).
Validation, parsing, and
cargo-orthohelpintegration are deferred toroadmap items 6.3.2 and 6.2.1 respectively. The plan explains why 6.3.1
can land before its nominal prerequisite 6.2.1.
docs/contents.md.The plan was informed by Firecrawl research into prior art (Anthropic
Claude Skills, MCP tool listings, OpenAI
ai-plugin.json, Microsoft 365Copilot v2.1, Fig autocomplete) and stress-tested via the Logisphere
design-review skill.
Test plan
docs/execplans/6-3-1-skill-manifest-metadata.mdand either approves it or requests revisions.
whether the wire-field rename from
skill_manifest_pathstoskill_manifestswarrants a new ADR-006 or whether referencingADR-003 in
docs/developers-guide.mdis sufficient (plan default:no new ADR).
make markdownlintpasses.make nixiepasses.References
docs/roadmap.md§6.3.1.docs/agent-native-cli-design.md§3.4 and §8.1.docs/adr-003-define-schema-ownership-for-agent-native-contracts.md.Summary by Sourcery
Document an execution plan for adding skill manifest metadata to the agent context and link it into the documentation index.
Documentation: