frame-spine-lookup
Frame spine lookup methodology for mid-turn slice retrieval by spine-aware specialists. Use when a dispatched specialist needs to fetch an addressable plan slice from the durable plan-issue comment. DO NOT USE FOR: authoring plan spines, emitting frame credits, frame-port adapter declarations, or custom transport implementation.
- License 许可
- MIT
- 最近更新
- 2026-08-16
- Stars
- ★ 3
- Forks
- 0
01 前言 Front Matter
- name
- frame-spine-lookup
- description
- Frame spine lookup methodology for mid-turn slice retrieval by spine-aware specialists. Use when a dispatched specialist needs to fetch an addressable plan slice from the durable plan-issue comment. DO NOT USE FOR: authoring plan spines, emitting frame credits, frame-port adapter declarations, or custom transport implementation.
02 资源文件 3
- 参考文档platforms/claude.md4.3 KB
- 参考文档platforms/copilot.md4.9 KB
- 参考文档references/detailed-guide.md14.2 KB
03 SKILL.md 正文
<!-- platform-assumptions: markdown skill guidance for Claude Code specialist shells with Read and Bash access in Agent Orchestra. --> <!-- markdownlint-disable-file MD041 MD003 -->
Frame Spine Lookup
Methodology for retrieving addressable frame-spine slices during a specialist turn without loading the full implementation plan.
When to Use
- When Code-Conductor dispatches a specialist with a frame spine, an active slice, and the durable plan comment id.
- When a specialist needs a depth-1 dependency slice or another explicitly addressable slice during the same turn.
- When the specialist must verify that the dispatched spine is still current before relying on a slice fetched from GitHub.
Purpose
Keep specialist prompts focused while preserving plan traceability. The durable plan-issue comment remains the source of truth; this skill defines how a specialist fetches that comment, asks the production parser helpers for the needed step, and handles stale-spine detection.
Dispatch Inputs
Code-Conductor must provide the specialist with:
- Repository owner and name.
- The GitHub issue comment id for the
<!-- plan-issue-{ID} -->comment. - The GitHub issue comment id for the
<!-- frame-slices-{ID} -->sibling comment, required when the dispatched spine'sslice_comment_idfield is present. Code-Conductor already has the<!-- frame-spine ... -->block in its own dispatch context (seeagents/Code-Conductor.agent.md) and readsslice_comment_idfrom it directly to populate this input — the specialist never readsslice_comment_iditself. Absent when the spine has noslice_comment_id(legacy/unsplit plan); see Operational Contract step 1 for the resulting single-fetch behavior. - The target spine step id, such as
s4. - The spine
generated_atvalue captured at dispatch time.
The specialist must carry the dispatched generated_at into lookup. The lookup
uses generated_at to compare the dispatch-time spine against the current
plan-issue comment body.
Operational Contract
-
Fetch the durable plan payload with the GitHub issue comments API. See
platforms/claude.mdandplatforms/copilot.mdfor tool-specific invocations.Read the response body field as the plan-issue comment body. Do not parse issue timelines or search results when the comment id is already known.
When a sibling comment id was dispatched (the spine's
slice_comment_idwas present at dispatch time), also fetch the<!-- frame-slices-{ID} -->sibling comment body, keyed on the dispatched sibling id, with the same GitHub issue comments API. Before concatenating, verify the fetched sibling body carries a<!-- frame-slices-{ID} -->marker whose{ID}matches the dispatched issue number. If the marker is absent or names a different issue, stop before invoking-Op Lookupand reportsibling-identity-mismatchto Conductor rather than proceeding with a body that may belong to the wrong issue — a copy-pasted or stale sibling id is a zero-adversary path to executing a foreign requirement contract. This check runs at the shim, beforeframe-spine-core.ps1is invoked: the core script has no issue-number parameter to perform it, and adding one would widen the signature the shim concatenation approach was chosen to avoid.When the identity check passes, concatenate the plan-issue comment body and the sibling body with a single blank line (
\n\n) between them — plan body first, sibling body second — and pass the concatenated text to-Op Lookupas a single comment body. When no sibling id was dispatched (legacy plan, noslice_comment_idon the spine), fetch only the plan comment and pass it unchanged; this is the current single-fetch behavior and its shape does not change. -
Invoke the production frame-spine parser helpers through the lookup operation. The command shape must match this contract:
pwsh -File .github/scripts/lib/frame-spine-core.ps1 -Op Lookup -CommentBodyPath {path} -GeneratedAt {generated_at} -StepId {id} -Format JsonThe implementation may pass the fetched body by a supported path or stream (
-CommentBodyPathfor file-based,-CommentBodyStdinfor piped stdin), but the operation remains-Op Lookupagainstframe-spine-core.ps1, with the dispatchedgenerated_atvalue and requested-StepId {id}present in the lookup invocation. When a sibling was fetched, the body passed here is the step-1 concatenation of the plan comment and the sibling comment — the command shape and-Op Lookup/-StepId {id}invocation are unchanged either way; only the content behind-CommentBodyPath/-CommentBodyStdindiffers. Always pass-Format Jsonso the response is machine- parseable JSON regardless of platform; parse the returnedstatusfield to determine the lookup outcome (do not rely on exit code alone — see Exit Codes below). -
Use the returned slice content as the only additional plan context for the current turn. Do not manually parse
<!-- frame-spine -->or<!-- frame-slice -->blocks in specialist prompt logic — this includes the spine'sslice_comment_idfield. The specialist obtains the sibling comment id exclusively from the Dispatch Inputs Conductor supplies, never by reading the spine block itself: the Lookup CLI's JSON payload is closed (frame-spine-core.ps1's-Opparameter is[ValidateSet('Lookup')]) and exposes no "parsed spine field" operation, so there is no lawful shim-side path to deriveslice_comment_id. -
On generated_at mismatch, respect the F2.2 hash-elision filter before declaring staleness. If the lookup result is
stale-spine, stop specialist work and return control to Conductor for re-dispatch with a fresh spine.
Exit Codes and Status Values
Always parse the JSON status field to determine the lookup outcome. Do not
branch on exit code alone — stale-spine exits 0, not 1.
| Status | Exit code | Meaning |
|---|---|---|
ok |
0 | Slice retrieved successfully; slice field contains content. |
stale-spine |
0 | Dispatched spine is no longer current, or the fetched sibling's frame-slices-generated-at stamp diverges from the spine's generated_at; return to Conductor. |
missing-spine |
1 | Comment body contains no <!-- frame-spine --> block. |
invalid-spine |
1 | Spine block is present but malformed (parse error). |
sibling-unstamped |
1 | Spine carries slice_comment_id but the concatenated body has no frame-slices-generated-at marker — a writer defect, not legacy history (863-D3/AC5). |
missing-slice |
1 | Spine is valid but the requested step id was not found. |
duplicate-slice-id |
1 | The concatenated corpus carries two or more <!-- frame-slice --> blocks for the requested step id. |
error |
1 | Unexpected error; message field contains the reason. |
Wrapper-level error codes (when the outer process fails before the script
can run) are surfaced by the platform shim — see platforms/copilot.md and
platforms/claude.md for gh-not-installed, gh-auth-expired,
pwsh-not-found, and sibling-identity-mismatch error handling. The last is
a shim-level check (see Operational Contract step 1) — it never reaches
frame-spine-core.ps1, so it is not one of the core status values above.
Stale-Spine Handling
generated_at can change when the plan is amended or re-emitted. Lookup must
not treat timestamp-only churn as a semantic change until the F2.2
hash-elision filter has ignored transport-only generated_at differences. If
the filtered comparison still shows that the dispatched spine is no longer the
current plan spine, lookup returns stale-spine.
Specialist response on stale-spine is intentionally narrow:
- Do not continue implementation, tests, refactoring, or documentation from the stale slice.
- Report that the lookup returned
stale-spine. - Return control to Conductor so Conductor can re-dispatch the specialist with current spine context.
Tool-Grant Verification
The specialist shells that can perform lookup already have the required tool grants.
Claude Code specialists (Read and Bash):
agents/code-smith.mdagents/test-writer.mdagents/doc-keeper.mdagents/refactor-specialist.md
Copilot specialists (execute/runInTerminal or execute wildcard):
agents/Code-Smith.agent.mdagents/Test-Writer.agent.mdagents/Doc-Keeper.agent.mdagents/Refactor-Specialist.agent.mdagents/Specification.agent.mdagents/UI-Iterator.agent.mdagents/Experience-Owner.agent.md
agents/Research-Agent.agent.md is excluded: it has only read, edit, search, and
web grants — no execute/*. Copilot spine lookup for Research-Agent is deferred to
#544.
Do not edit specialist shells for this contract unless a future test proves the grants drifted.
Non-Goals and Deferred Work
- Copilot parity shims for spine lookup shipped in #514. Research-Agent Copilot spine lookup is deferred to #544.
- A custom MCP server lookup path is deferred and is a non-goal for this skill.
- This skill is supporting methodology only. It declares no
provides:field and does not fill a frame port. - Goal-contract plans (issue #872) are out of scope for this skill's slice
dispatch. A
plan-variant: goal-contractplan (seeskills/plan-authoring/SKILL.md § Goal-contract plan variant) carries no<!-- frame-spine ... -->block and no<!-- frame-slices-{ID} -->sibling comment — the<!-- goal-contract -->block replaces both (872-D8). Such plans are never slice-dispatched through this skill's Operational Contract.Invoke-FSCSpineLookupClireturningmissing-spine(§ Exit Codes and Status Values above) for a goal-contract-only plan body is the intended fail-loud backstop, not a bug (872-D7 item 2): no code change closes this path, because a goal-contract plan is meant to be executed by the future goal-run harness (#874), not walked by Spine-Runner or looked up mid-turn by a specialist. - The credit-ledger degradation note below covers the brief too.
Get-FCLLatestParsedFrameSpinereturning$nullfor a brief is the same expected behavior it is for a goal-contract plan, and for the same reason: no spine exists to parse, so zero spine-sourced credit rows is the correct answer rather than a defect. Recorded here because #942 deletes the only shape that note currently names. - Brief plans (issue #941) are out of scope for the same reason. A
plan-variant: briefplan (seeskills/plan-authoring/SKILL.md § Brief plan variant) carries no<!-- frame-spine ... -->block and no<!-- frame-slices-{ID} -->sibling, because it has no numbered implementation steps to route.missing-spineis the intended fail-loud backstop here too; a brief is read whole by its executor rather than slice-dispatched. - Spine-reader enumeration (872-D7 / AC2). The production readers of the
frame-spine mechanism, in full, are:
frame-validate-core.ps1(the structural-coverage validator,.github/scripts/lib/frame-validate-core.ps1),orchestra-spine.ps1(.github/scripts/orchestra-spine.ps1, the human-readable spine renderer),frame-credit-ledger.ps1(.github/scripts/frame-credit-ledger.ps1, the terminal-credit harvester), andInvoke-FSCSpineLookupCli— the lookup shim implemented inframe-spine-core.ps1that this skill's Operational Contract dispatches to. This is the shipped home for that enumeration; AC2's "spine-reader enumeration documented" requirement is satisfied here rather than living only inside the #872 plan comment. - Credit-ledger degradation note (872-D7 item 3).
frame-credit-ledger.ps1'sGet-FCLLatestParsedFrameSpine(.github/scripts/frame-credit-ledger.ps1:623-637) already degrades to returning$null/$null.Portsgracefully when no spine is found (.github/scripts/frame-credit-ledger.ps1:673-674:if ($null -eq $spine -or $null -eq $spine.Ports) { return @() }) — for a goal-contract (spine-less) plan, this is expected behavior, not a defect: the ledger silently contributes zero spine-sourced credit rows for that plan rather than throwing, which is documented here rather than fixed, since a goal-contract plan legitimately has no spine-sourced credits to harvest.
Platform-specific invocation
See platforms/claude.md for Claude Code tool bindings (Bash and Read) and
platforms/copilot.md for Copilot VS Code tool bindings (execute/runInTerminal).
Platform shims are the only location where tool names appear; the Operational
Contract above is tool-agnostic.
Gotchas
| Trigger | Gotcha | Fix |
|---|---|---|
| Specialist sees a stale slice | Continuing from old context can apply the wrong requirement contract | Return control to Conductor for re-dispatch |
| Comment id is available | Searching issue comments can select an older plan marker | Fetch gh api repos/{owner}/{repo}/issues/comments/{id} directly |
04 同仓库更多 Skills
webapp-testing
Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).
verification-before-completion
Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any "I'm finished" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).
validation-methodology
Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).
upstream-onboarding
Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.
ui-testing
Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).
ui-iteration
Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).