chore: preserve local agent configuration work [skip ci]
This commit is contained in:
Codex committed
1 parent
9c7f669449
commit
256f90a99a
18 files changed
+428
-103
No files matched your search
@@ -5,6 +5,8 @@ platforms:
|
||||
generic:
|
||||
link:
|
||||
- [skills/_shared/artifact-policy.md, ~/.config/opencode/skills/_shared/artifact-policy.md]
|
||||
- [skills/_shared/agent-workflow.md, ~/.config/opencode/skills/_shared/agent-workflow.md]
|
||||
- [skills/all-green, ~/.config/opencode/skills/all-green]
|
||||
- [skills/brainstorming, ~/.config/opencode/skills/brainstorming]
|
||||
- [skills/continuous-driven-development, ~/.config/opencode/skills/continuous-driven-development]
|
||||
- [skills/dispatching-parallel-agents, ~/.config/opencode/skills/dispatching-parallel-agents]
|
||||
@@ -22,10 +24,13 @@ platforms:
|
||||
- [skills/test-driven-development, ~/.config/opencode/skills/test-driven-development]
|
||||
- [skills/to-questionnaire, ~/.config/opencode/skills/to-questionnaire]
|
||||
- [skills/verification-before-completion, ~/.config/opencode/skills/verification-before-completion]
|
||||
- [skills/vibe-review, ~/.config/opencode/skills/vibe-review]
|
||||
- [skills/writing-plans, ~/.config/opencode/skills/writing-plans]
|
||||
- [skills/writing-skills, ~/.config/opencode/skills/writing-skills]
|
||||
|
||||
- [skills/_shared/artifact-policy.md, ~/.agents/skills/_shared/artifact-policy.md]
|
||||
- [skills/_shared/agent-workflow.md, ~/.agents/skills/_shared/agent-workflow.md]
|
||||
- [skills/all-green, ~/.agents/skills/all-green]
|
||||
- [skills/brainstorming, ~/.agents/skills/brainstorming]
|
||||
- [skills/continuous-driven-development, ~/.agents/skills/continuous-driven-development]
|
||||
- [skills/dispatching-parallel-agents, ~/.agents/skills/dispatching-parallel-agents]
|
||||
@@ -43,10 +48,13 @@ platforms:
|
||||
- [skills/test-driven-development, ~/.agents/skills/test-driven-development]
|
||||
- [skills/to-questionnaire, ~/.agents/skills/to-questionnaire]
|
||||
- [skills/verification-before-completion, ~/.agents/skills/verification-before-completion]
|
||||
- [skills/vibe-review, ~/.agents/skills/vibe-review]
|
||||
- [skills/writing-plans, ~/.agents/skills/writing-plans]
|
||||
- [skills/writing-skills, ~/.agents/skills/writing-skills]
|
||||
|
||||
- [skills/_shared/artifact-policy.md, ~/.claude/skills/_shared/artifact-policy.md]
|
||||
- [skills/_shared/agent-workflow.md, ~/.claude/skills/_shared/agent-workflow.md]
|
||||
- [skills/all-green, ~/.claude/skills/all-green]
|
||||
- [skills/brainstorming, ~/.claude/skills/brainstorming]
|
||||
- [skills/continuous-driven-development, ~/.claude/skills/continuous-driven-development]
|
||||
- [skills/dispatching-parallel-agents, ~/.claude/skills/dispatching-parallel-agents]
|
||||
@@ -64,10 +72,13 @@ platforms:
|
||||
- [skills/test-driven-development, ~/.claude/skills/test-driven-development]
|
||||
- [skills/to-questionnaire, ~/.claude/skills/to-questionnaire]
|
||||
- [skills/verification-before-completion, ~/.claude/skills/verification-before-completion]
|
||||
- [skills/vibe-review, ~/.claude/skills/vibe-review]
|
||||
- [skills/writing-plans, ~/.claude/skills/writing-plans]
|
||||
- [skills/writing-skills, ~/.claude/skills/writing-skills]
|
||||
|
||||
- [skills/_shared/artifact-policy.md, ~/.gemini/config/skills/_shared/artifact-policy.md]
|
||||
- [skills/_shared/agent-workflow.md, ~/.gemini/config/skills/_shared/agent-workflow.md]
|
||||
- [skills/all-green, ~/.gemini/config/skills/all-green]
|
||||
- [skills/brainstorming, ~/.gemini/config/skills/brainstorming]
|
||||
- [skills/continuous-driven-development, ~/.gemini/config/skills/continuous-driven-development]
|
||||
- [skills/dispatching-parallel-agents, ~/.gemini/config/skills/dispatching-parallel-agents]
|
||||
@@ -85,6 +96,7 @@ platforms:
|
||||
- [skills/test-driven-development, ~/.gemini/config/skills/test-driven-development]
|
||||
- [skills/to-questionnaire, ~/.gemini/config/skills/to-questionnaire]
|
||||
- [skills/verification-before-completion, ~/.gemini/config/skills/verification-before-completion]
|
||||
- [skills/vibe-review, ~/.gemini/config/skills/vibe-review]
|
||||
- [skills/writing-plans, ~/.gemini/config/skills/writing-plans]
|
||||
- [skills/writing-skills, ~/.gemini/config/skills/writing-skills]
|
||||
|
||||
@@ -27,13 +27,25 @@ The main feature workflow has an optional autonomous entry:
|
||||
|
||||
`solve` is the lifecycle controller for an authorized ticket or text assignment. It preserves pre-existing work before task preparation, routes from recorded ambiguity evidence, and receives artifacts and verification evidence from downstream skills. Missing optional tracker, remote, or review-publication capability permits an explicitly recorded local completion; missing correctness evidence remains a blocker.
|
||||
|
||||
`brainstorming` remains a supported direct, user-invoked design and planning entry. After the design artifact is approved, it may transition to `writing-plans`. When `solve` records high ambiguity, `brainstorming` is the sole stage that may ask the user questions. Planning then selects the recorded execution mode:
|
||||
`brainstorming` remains a supported direct, user-invoked design and planning entry. After the design artifact is approved, it may transition to `writing-plans`. When `solve` records high ambiguity, `brainstorming` is the sole stage that may ask the user questions. Planning preserves the recorded execution mode:
|
||||
|
||||
- `continuous-driven-development` keeps tightly coupled work in the primary agent's context and runs the plan continuously in dependency order.
|
||||
- `subagent-driven-development` lets the controller work directly on a small slice or assign bounded slices to `implementer`; each delegated task receives an independent `checker` review, correction and scoped re-review when needed, and durable progress artifacts.
|
||||
- `continuous-driven-development` gives one worker the dependent plan and runs it continuously; the original inline workflow remains available when requested or delegation is unavailable.
|
||||
- `subagent-driven-development` assigns bounded slices to `implementer`, sequentially by default; each task receives an independent `checker` review, correction and scoped re-review when needed, and durable progress artifacts.
|
||||
|
||||
`finishing-a-development-branch` finalizes branch state in preservation or delivery mode through semantic commits, safe synchronization, and a draft unassigned review request when supported. It never runs project verification or judges correctness; `solve`, the execution skills, `requesting-code-review`, and `verification-before-completion` own those decisions and evidence.
|
||||
|
||||
Across these stages, `_shared/agent-workflow.md` makes the main session the
|
||||
accumulator: it retains accepted decisions, a coordination index, evidence paths
|
||||
and the latest recovery snapshot. Brainstorming keeps its
|
||||
interactive questions, approach comparison and section approvals in the main
|
||||
session. Researchers investigate; document workers record the agreed design
|
||||
after section approvals and draft detailed plans; implementers execute. These
|
||||
are workload boundaries, preserving each skill's original stages and gates. Workers receive bounded
|
||||
inputs and return at most 200 words plus artifact paths. Document workers use an
|
||||
available role that can write the named artifacts; read-only roles return evidence
|
||||
for the controller to persist. New references are deployed by the Shared skills
|
||||
strap; existing skill-directory links expose their local references immediately.
|
||||
|
||||
The controller may use `researcher` for an independent read-only question without granting edit scope. Substantial completed work uses `requesting-code-review` for combined requirements and quality review, and every completion claim passes through `verification-before-completion` with fresh project-declared evidence. A Codex Goal is an optional outer continuation contract: `solve` evaluates and marks an active Goal complete only after the terminal manifest, required verification, and durable intended state are present. Without Goal support, the terminal manifest and final report define the result.
|
||||
|
||||
For bug fixes, `systematic-debugging` establishes the cause before `test-driven-development` drives the repair. `grill-me`, `research`, `handoff`, and `to-questionnaire` provide focused entry points for decisions, durable investigation, context transfer, and missing external knowledge.
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
# Agent Workflow Contract
|
||||
|
||||
Use this contract across design, planning, and execution. The main session is
|
||||
the controller and accumulator: it owns user dialogue, authorization, accepted
|
||||
decisions, task ordering, integration, and the current recovery record. Workers
|
||||
perform the detailed investigation, drafting, implementation, and review assigned
|
||||
by the owning skill. That skill keeps its original sequence, interaction,
|
||||
approvals, reviews, retry limits and completion rules. This contract changes
|
||||
workload placement and context transfer, not those rules.
|
||||
|
||||
Brainstorming remains interactive in the main session. Workers support the
|
||||
current question or section; the user and main session develop the design
|
||||
together. The owning skill determines when recording a complete artifact begins.
|
||||
|
||||
## Dispatch and Context
|
||||
|
||||
1. Discover available delegation and file capabilities. Use fresh worker context
|
||||
with the smallest task brief; disable inherited conversation when supported.
|
||||
Otherwise supply a bounded brief and treat context isolation as unavailable.
|
||||
2. Assign one outcome, applicable instruction paths, exact input paths and
|
||||
relevant sections, constraints, allowed writes, and required evidence. Give
|
||||
workers only the decisions and interfaces their task consumes. Include the
|
||||
applicable worker contract, artifact policy and compact-return format in
|
||||
each brief; fresh workers cannot rely on instructions loaded by the parent.
|
||||
3. Use a read-only researcher for discovery, a document worker with permission
|
||||
to write only named artifacts for drafting, an implementer for approved code
|
||||
changes, and an independent read-only checker for review. Use equivalent
|
||||
available roles; a role name never grants a missing capability. Workers do
|
||||
not delegate. Read-only workers return concise evidence for the controller
|
||||
to persist; do not ask them to write reports.
|
||||
4. Run dependent work sequentially. Parallel work requires independent inputs
|
||||
and disjoint writable ownership. Tell each writer it shares the workspace,
|
||||
must preserve others' edits, and must report conflicting external changes.
|
||||
5. Require the return below. Inspect cited evidence only as needed to resolve a
|
||||
decision, finding, conflict, or verification gap. Perform the reviews required
|
||||
by the owning skill; delegate their detailed inspection where useful. Retain
|
||||
author self-review where that is the original requirement. A worker status
|
||||
alone is not proof of completion.
|
||||
|
||||
If delegation is unavailable, report the context limitation and continue the
|
||||
original workflow inline when its capabilities and authorization allow it; this
|
||||
does not add a new permission or blocker gate. Honor explicit user instructions
|
||||
about delegation. Small coordination work may stay in the main session; a heavy
|
||||
tightly coupled sequence can stay with one worker.
|
||||
|
||||
## Compact Return
|
||||
|
||||
Keep the worker's final message within 200 words, excluding artifact paths:
|
||||
|
||||
- Status: done, needs-context, or blocked; executors may use their existing statuses.
|
||||
- Artifact: absolute path and the exact section needed for coordination, or none.
|
||||
- Summary: at most five decision-relevant findings, with evidence references.
|
||||
- Verification: checks actually run and their results, or not run with reason.
|
||||
- Open issue: the missing fact, decision, or capability and its consequence, or none.
|
||||
|
||||
Put detailed reasoning, source excerpts, code, logs, and full plans in named
|
||||
artifacts under the shared artifact policy. A controller persists a read-only
|
||||
worker's bounded result when needed. Resolve a missing report by requesting a
|
||||
compact corrected return, rather than ingesting a transcript.
|
||||
|
||||
## Accumulator and Recovery
|
||||
|
||||
Maintain compact recovery state using the owning skill's progress artifacts or
|
||||
manifest. Include the objective and authorization, accepted decisions and exact
|
||||
approved artifact versions, task status and ownership, evidence paths, blockers
|
||||
and next action. Write a separate snapshot when needed for reliable recovery;
|
||||
retain the owning skill's existing persistence and completion requirements.
|
||||
For solve runs, the manifest's Controller state field may reference that snapshot.
|
||||
Only the controller advances manifest lineage; workers return their input
|
||||
manifest path alongside results.
|
||||
|
||||
A new run needs no pre-existing recovery record. An existing approved plan stays
|
||||
valid without a coordination index. The assigned worker can extract a compact
|
||||
task summary during its normal preflight without changing the approved plan or
|
||||
adding a separate approval stage. New plans may start with an index of task IDs,
|
||||
dependencies, ownership, expected results and detail anchors so the controller
|
||||
can coordinate without loading implementation detail.
|
||||
|
||||
Keep the ongoing dialogue, accepted decisions and compact coordination state in
|
||||
the main session; detailed research, code and logs stay with workers and their
|
||||
artifacts. After compaction, restore from the latest existing progress or manifest
|
||||
record and inspect only artifacts needed for the next action. Findings remain
|
||||
proposals until accepted; workers cannot approve designs,
|
||||
change scope, authorize publication, or advance approval gates.
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
name: all-green
|
||||
description: Use when the user requests $all-green or asks to fix both review findings and CI failures and update the PR with this workflow.
|
||||
---
|
||||
|
||||
Use the workspace's applicable code review tool to review the current PR and collect existing issues, and its CI diagnostics tool to inspect failing checks. Discover the capabilities from the workspace rather than assuming a provider; report unavailable capabilities instead of inventing results. Follow additional context and scope supplied with the invocation.
|
||||
|
||||
1. Check review findings against the code, fix every substantiated issue in scope, and record why any finding is declined. Diagnose CI failures and fix those caused by the PR, using the workspace's CI-fixing skill (such as `fix-ci-issues`, when available). Respect its check-selection rules and report unrelated failures separately.
|
||||
2. Verify the affected behavior. Use `finishing-a-development-branch` in delivery mode with the evidence to update the existing PR. Commit fixes with the exact title `Fix PR issues`; amend instead if the branch's top commit already has that exact title and belongs to this PR. Preserve unrelated changes and history, use safe synchronization, and create no empty commit. This title and amendment rule overrides the finishing skill's defaults. Keep the existing PR title, description, and publication state.
|
||||
3. After the fixes are verified and synchronized to the PR, delete a fixed issue's draft only when it belongs to the user; resolve a fixed posted issue silently, without a reply. Leave other people's drafts untouched. For a declined review finding, leave a draft explanation starting with `🤖`; keep the issue unresolved and never publish the draft. If drafts are unavailable, show the explanation in chat.
|
||||
4. Recheck the PR's CI for the updated revision. If it reveals new failures caused by these changes, fix and verify them and update the same top fix commit. Limit retries to the applicable project rule, or three attempts per issue if none is declared; then report the blocker. Report pending checks as pending and unrelated failures separately; claim all green only when the current revision's relevant checks have passed and no actionable review findings remain.
|
||||
|
||||
Keep CI progress, failure, and completion reports in chat, without any CI-related PR comments, including drafts. Apply this restriction to delegated skills, permission checks, and error handlers too: skip comment-producing helpers and use a read-only alternative or report the capability gap in chat. The only comment writes in this workflow are the review-draft handling described above.
|
||||
|
||||
A direct request to run this workflow authorizes the PR update and review-issue cleanup above. Creating or editing this skill does not run it. Finish with a concise chat report of fixed, declined, pending, and blocked items.
|
||||
@@ -17,14 +17,29 @@ Do not write code, scaffold files, or take any other implementation action until
|
||||
|
||||
Read the latest manifest supplied by a high-ambiguity solve handoff before design work. Interactive clarification and artifact approvals remain mandatory. After the user approves the exact design artifact, return `status: done | blocked`, `latest_manifest: absolute path`, `artifact: absolute design path`, and concise `evidence_or_blocker` to `solve`; do not independently select an execution route or finalize branch state.
|
||||
|
||||
## Delegation Boundary
|
||||
|
||||
Read and follow [the agent workflow contract](../_shared/agent-workflow.md).
|
||||
The main session leads the interactive exploration: scoping, one question at a
|
||||
time, comparing approaches, developing the design with the user, and approvals.
|
||||
Workers handle bounded source exploration, feasibility analysis, and proposed
|
||||
wording for the section currently being discussed. Their compact findings inform
|
||||
that dialogue; the main session evaluates and discusses them with the user.
|
||||
|
||||
Use [design-worker.md](design-worker.md) for support tasks. Assign recording of
|
||||
the complete durable design only after every section is approved. The recorder
|
||||
captures agreed content and returns unresolved details instead of deciding them.
|
||||
Delegation changes who performs detailed work; the workflow and gates below stay
|
||||
the same.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Discover context.** Read the applicable project instructions and documentation, then inspect the relevant existing structure, files, constraints, and established patterns.
|
||||
1. **Discover context.** Read the applicable project instructions and documentation needed for coordination. Delegate detailed inspection of the relevant structure, files, constraints, and established patterns to a bounded researcher; retain its concise findings and evidence paths.
|
||||
2. **Check scope.** Identify independent subsystems before detailed clarification. If the request is too broad for one coherent design, help the user decompose it, explain relationships and dependency order, and choose one scoped part for this design cycle.
|
||||
3. **Clarify one question at a time.** Understand purpose, constraints, success criteria, and boundaries. Ask only one question per message; prefer a concise set of choices when that makes the decision easier.
|
||||
4. **Compare approaches.** Present two or three viable approaches with tradeoffs. Lead with the recommended approach and explain why it best fits the discovered context.
|
||||
5. **Present the design in sections.** Scale each section to its complexity and ask for approval after each section. Cover the relevant architecture, responsibilities, interfaces, data flow, error handling, and verification strategy. Revise any section that is not approved.
|
||||
6. **Write the approved design.** Only after every section is approved, produce the durable design artifact under the shared artifact policy.
|
||||
6. **Write the approved design.** Only after every section is approved, give a document worker the approved content and a fresh artifact path. Have it record the durable design under the shared artifact policy, then self-review it against the agreed sections. The main session checks that the recorded design matches those decisions.
|
||||
7. **Obtain artifact approval.** Ask the user to review the exact artifact that was written. Apply requested changes, repeat the self-review, and ask again. Do not begin implementation while review is pending.
|
||||
8. **Transition to planning.** After the artifact is approved, use `writing-plans`. Do not transition directly to an implementation workflow or any other implementation skill.
|
||||
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
# Brainstorming Support Worker
|
||||
|
||||
The main session leads brainstorming with the user. The dispatcher supplies one
|
||||
bounded support task, applicable instructions, accepted constraints, evidence
|
||||
paths, allowed writes and a compact-return contract. Preserve others' edits and
|
||||
do not spawn agents. Return questions and decisions to the main session.
|
||||
|
||||
## Research or Section Support
|
||||
|
||||
Investigate the assigned source question, feasibility concern, approach tradeoff,
|
||||
or proposed wording for the current section. Use project evidence and distinguish
|
||||
verified facts, inference, options and unresolved human decisions. Return a
|
||||
concise answer with precise evidence references and any material uncertainty.
|
||||
Use a read-only role for source research; draft support may write only a named
|
||||
support artifact when explicitly allowed. This work supports the current turn of
|
||||
discussion; the main session compares approaches and develops the design with
|
||||
the user.
|
||||
|
||||
## Record the Agreed Design
|
||||
|
||||
Accept this task only when the dispatcher confirms every design section is
|
||||
approved and supplies the agreed content and a fresh design artifact path.
|
||||
|
||||
1. Record those sections faithfully, including the relevant architecture,
|
||||
responsibilities, interfaces, data flow, errors and verification strategy.
|
||||
2. Self-review for omissions, contradictions, ambiguity, scope, placeholders and
|
||||
incomplete requirements against the approved content.
|
||||
3. If a necessary detail is unresolved, return it to the main session for
|
||||
clarification. Approval and new design decisions remain with the user.
|
||||
4. Return the absolute artifact path, concise result and any unresolved issue.
|
||||
The main session obtains approval of the exact saved artifact before planning.
|
||||
|
||||
Write only the supplied artifact. Revisions use fresh paths; preserve the prior
|
||||
artifact and its approval identity. Implementation is outside this assignment.
|
||||
@@ -5,48 +5,59 @@ description: Use when an approved implementation plan exists as an absolute arti
|
||||
|
||||
# Continuous-Driven Development
|
||||
|
||||
Critically review an approved plan, then execute it continuously with dependency-aware progress and current verification evidence.
|
||||
Critically review an approved plan, then execute it continuously with
|
||||
dependency-aware progress and current verification evidence. One bounded executor
|
||||
performs the detailed preflight and dependent sequence; the main session owns
|
||||
interaction, decisions and recovery. Read and follow
|
||||
[the agent workflow contract](../_shared/agent-workflow.md) and
|
||||
[the artifact policy](../_shared/artifact-policy.md).
|
||||
|
||||
## Input Gate
|
||||
|
||||
Accept the plan only when the caller supplies an absolute path whose normalized location is within `~/.agents/docs`. A solve handoff may also supply an optional latest manifest at an absolute path within `~/.agents/docs`. For direct invocation, reject a relative path or a path outside that directory and ask for the correct artifact path.
|
||||
Accept the plan only when the caller supplies an absolute path whose normalized
|
||||
location is within `~/.agents/docs`. A solve handoff may also supply an optional
|
||||
latest manifest at an absolute path within `~/.agents/docs`. For direct
|
||||
invocation, reject a relative path or a path outside that directory and ask for
|
||||
the correct artifact path. Read an approved specification only when the plan
|
||||
references one; a separate specification artifact is not an input requirement.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Read the coordination index and current recovery record when present. Give one
|
||||
bounded executor the approved plan path, any referenced specification paths,
|
||||
applicable instructions and constraints, owned paths and evidence paths,
|
||||
using [execution-worker.md](execution-worker.md). During normal preflight,
|
||||
that executor reads the entire plan and extracts a compact task summary if
|
||||
the plan has no index; no separate index-building phase is required. Preserve
|
||||
the approved plan. Initialize recovery from the authorized objective and
|
||||
available artifact paths for a new direct invocation.
|
||||
2. Have the executor critically review the full plan and relevant project files
|
||||
before edits. For direct invocation, resolve critical concerns with the user
|
||||
before editing. For a solve handoff, return the concern and evidence to
|
||||
`solve`. Do not guess or silently rewrite the plan.
|
||||
3. Execute continuously in dependency order, following every plan step and all
|
||||
specified and relevant project-declared verification. Keep detailed task
|
||||
progress and fresh verification evidence with the executor. The controller
|
||||
handles changed requirements, decisions and blockers; the executor re-reads
|
||||
relevant plan sections as context changes and pauses affected work when a
|
||||
critical assumption or required verification fails.
|
||||
4. Save compact task status, evidence paths, verification results and next action
|
||||
in recovery. Completion requires every task and relevant specified or
|
||||
project-declared verification to have current supporting output. Report tasks
|
||||
and files completed, commands and observed results, explicitly approved
|
||||
deviations, and checks that could not run with their reasons. Never report
|
||||
completion while required work or unresolved blockers remain.
|
||||
|
||||
Inline here remains one continuous dependent execution sequence. Honor an
|
||||
explicit request to execute in the main session; if delegation is unavailable,
|
||||
report the limitation and follow the same execution contract inline.
|
||||
|
||||
## Solve Handoff
|
||||
|
||||
When a solve handoff supplies a manifest, re-read it during preflight and whenever context or external state changes. Return a critical concern or blocker to `solve` rather than asking the user. After execution, return `status: done | blocked`, `latest_manifest: absolute path`, `artifact: absolute execution-evidence path`, and concise `evidence_or_blocker` to `solve`. Do not publish branch state or claim end-to-end completion.
|
||||
|
||||
## Preflight Before Edits
|
||||
|
||||
1. Read the entire plan and any approved specification it references.
|
||||
2. Read the applicable project instructions and the files needed to validate the plan's assumptions.
|
||||
3. Critically review scope, exact paths, responsibilities, interfaces, dependency order, verification commands, and expected results.
|
||||
4. Surface contradictions, unsafe actions, missing prerequisites, stale assumptions, or ambiguity that could change the implementation.
|
||||
5. For direct invocation, resolve critical concerns with the user before editing. For a solve handoff, return the concern and evidence to `solve`. Do not guess or silently rewrite the plan.
|
||||
|
||||
## Continuous Execution
|
||||
|
||||
- Order work by declared dependencies. Among ready tasks, preserve the plan's intended sequence.
|
||||
- Track pending, active, completed, and blocked work through an available progress-tracking capability. If none exists, maintain an explicit concise status in conversation.
|
||||
- Execute ready tasks continuously without arbitrary batches or routine pause points.
|
||||
- Follow every plan step exactly. Do not skip requirements, substitute a different design, or add adjacent work.
|
||||
- Run every verification specified by the plan and any additional relevant check declared by the project for the affected area. Compare actual output with the plan's expected result.
|
||||
- After each task, record the files affected and fresh verification evidence before marking it complete.
|
||||
|
||||
## Re-check as Context Changes
|
||||
|
||||
Re-read the relevant plan sections before each task and whenever the user updates requirements, files change externally, a discovery invalidates an assumption, or verification behaves differently than expected. Re-evaluate dependency order and the remaining steps; report any required plan correction instead of drifting from the approved artifact.
|
||||
|
||||
## Blockers
|
||||
|
||||
Report an honest blocker immediately when a dependency is unavailable, an instruction is unclear, a critical assumption is false, or verification cannot reach its expected result. Include the affected task, observed evidence, safe checks already attempted, and the decision or external change needed. Pause affected work rather than concealing the blocker or claiming progress.
|
||||
|
||||
## Completion
|
||||
|
||||
Completion requires every plan task to be finished and every relevant specified or project-declared verification to have current supporting output. At the end, report:
|
||||
|
||||
- tasks and files completed;
|
||||
- verification commands and observed results;
|
||||
- deviations explicitly approved during execution;
|
||||
- any verification that could not run and why.
|
||||
|
||||
Never report the plan complete while required work or unresolved blockers remain.
|
||||
Re-read a supplied manifest during preflight and whenever context or external
|
||||
state changes. Preserve its latest path in progress and evidence artifacts.
|
||||
Return a critical concern or blocker to `solve` rather than asking the user.
|
||||
After execution, return `status: done | blocked`, `latest_manifest: absolute
|
||||
path`, `artifact: absolute execution-evidence path`, and concise
|
||||
`evidence_or_blocker` to `solve`. Do not publish branch state or claim end-to-end
|
||||
completion.
|
||||
@@ -0,0 +1,47 @@
|
||||
# Sequential Execution Worker
|
||||
|
||||
The controller supplies the full approved plan path, any referenced specification
|
||||
paths, latest manifest when present, inherited constraints, writable ownership, and fresh
|
||||
evidence artifact paths. Use the client's equivalent of an implementation worker
|
||||
for this dependent sequence. Read the detailed plan here, preserve others' edits,
|
||||
and do not spawn agents. Return decisions to the controller.
|
||||
|
||||
## Preflight Before Edits
|
||||
|
||||
1. Read the entire plan and any approved specification it references.
|
||||
2. Read the applicable project instructions and the files needed to validate the plan's assumptions.
|
||||
3. Critically review scope, exact paths, responsibilities, interfaces, dependency order, verification commands, and expected results.
|
||||
4. Surface contradictions, unsafe actions, missing prerequisites, stale assumptions, or ambiguity that could change the implementation.
|
||||
5. Return critical concerns and evidence to the controller before editing. For direct invocation, the controller resolves them with the user; for a solve handoff, it returns them to `solve`. Do not guess or silently rewrite the plan.
|
||||
6. If the plan has no coordination index, extract task IDs, dependencies, ownership and expected results as part of this preflight and return a compact summary. Do not change the approved plan or introduce a separate bootstrap phase. Re-read a supplied solve manifest during preflight and whenever context or external state changes.
|
||||
|
||||
## Continuous Execution
|
||||
|
||||
- Order work by declared dependencies. Among ready tasks, preserve the plan's intended sequence.
|
||||
- Track pending, active, completed, and blocked work through an available progress-tracking capability. If none exists, return an explicit concise status for the controller to maintain in conversation. Keep detailed progress and evidence in the supplied artifact scope; preserve earlier snapshots.
|
||||
- Execute ready tasks continuously without arbitrary batches or routine pause points.
|
||||
- Follow every plan step exactly. Do not skip requirements, substitute a different design, or add adjacent work.
|
||||
- Run every verification specified by the plan and any additional relevant check declared by the project for the affected area. Compare actual output with the plan's expected result.
|
||||
- After each task, record the files affected and fresh verification evidence before marking it complete.
|
||||
|
||||
## Re-check as Context Changes
|
||||
|
||||
Re-read the relevant plan sections before each task and whenever the user updates requirements, files change externally, a discovery invalidates an assumption, or verification behaves differently than expected. Re-evaluate dependency order and the remaining steps; report any required plan correction instead of drifting from the approved artifact.
|
||||
|
||||
## Blockers
|
||||
|
||||
Report an honest blocker immediately when a dependency is unavailable, an instruction is unclear, a critical assumption is false, or verification cannot reach its expected result. Include the affected task, observed evidence, safe checks already attempted, and the decision or external change needed. Pause affected work rather than concealing the blocker or claiming progress.
|
||||
|
||||
## Completion
|
||||
|
||||
Completion requires every plan task to be finished and every relevant specified or project-declared verification to have current supporting output. At the end, report:
|
||||
|
||||
- tasks and files completed;
|
||||
- verification commands and observed results;
|
||||
- deviations explicitly approved during execution;
|
||||
- any verification that could not run and why.
|
||||
|
||||
Never report the plan complete while required work or unresolved blockers remain.
|
||||
|
||||
Keep detailed progress and check output in the named artifacts. Return the
|
||||
compact status, evidence paths, results and unresolved concerns to the controller.
|
||||
@@ -7,6 +7,13 @@ description: Use when a ticket identifier or raw development assignment should b
|
||||
|
||||
Carry one ticket or text assignment from state preparation through verified implementation and final branch storage.
|
||||
|
||||
Read and follow ../_shared/agent-workflow.md. Keep the main session as the
|
||||
lifecycle controller and accumulator. Delegate detailed project discovery,
|
||||
ambiguity evidence and source investigation to bounded researchers; receive
|
||||
compact findings and paths. Keep authority decisions, state preparation and
|
||||
manifest transitions in the controller. Downstream planning and both execution
|
||||
routes use workers, including sequential work on the low-ambiguity route.
|
||||
|
||||
## Authority and Completion
|
||||
|
||||
Explicit invocation authorizes in-scope workspace preparation, semantic commits, safe branch synchronization, and draft unassigned review publication. Only `brainstorming` may ask the user questions. Other stages continue from discovered evidence, use a defined fallback, or return an evidence-backed blocker.
|
||||
|
||||
@@ -41,6 +41,7 @@ Write every snapshot as Markdown with this exact heading and these sections in t
|
||||
- Routing evidence
|
||||
|
||||
## Artifacts
|
||||
- Controller state
|
||||
- Design
|
||||
- Plan
|
||||
- Execution evidence
|
||||
@@ -71,3 +72,7 @@ Treat multiple successors that name one predecessor as a lineage conflict. Recon
|
||||
## Handoff Paths
|
||||
|
||||
Carry the latest manifest snapshot and, when available, the authoritative assignment or approved design and current plan as absolute paths. Every solve-controlled return includes the current manifest path, its artifact path, and concise evidence or blocker.
|
||||
|
||||
The Controller state field links the latest compact recovery snapshot: accepted decisions and approvals, task index and statuses, evidence references, blockers and next action. Keep detailed worker material in its own artifacts. Only the controller advances manifest lineage.
|
||||
|
||||
For a legacy v1 manifest lacking Controller state, read that field as `unavailable: not yet recorded`. Restore from its existing artifact and continuation fields, then add the new reference in the next controller-owned snapshot; preserve the original snapshot.
|
||||
@@ -9,6 +9,10 @@ description: Use when executing a written implementation plan with bounded tasks
|
||||
|
||||
Execute a written plan through bounded implementation tasks and independent combined reviews. Keep tightly coupled work sequential, preserve progress in durable artifacts, and stop repeated correction loops with a concrete blocker.
|
||||
|
||||
Read and follow [the agent workflow contract](../_shared/agent-workflow.md).
|
||||
The main session coordinates from a plan index when present and compact worker
|
||||
returns; workers read detailed task sections and perform bounded investigation.
|
||||
|
||||
## Durable Artifacts
|
||||
|
||||
Before creating a progress document, task brief, implementer report, or review document, read and follow [the shared artifact policy](../_shared/artifact-policy.md). Put every document directly in the resolved scope directory. Use names such as:
|
||||
@@ -32,9 +36,9 @@ When a solve handoff supplies a manifest, return `status: done | blocked`, `late
|
||||
|
||||
## Lifecycle
|
||||
|
||||
1. Read the plan once. Before dispatch, reject internal contradictions and requirements that conflict with applicable constraints.
|
||||
2. Work directly for a small or tightly coupled plan. Otherwise dispatch one `implementer` per bounded task, sequentially unless the plan explicitly proves disjoint file ownership.
|
||||
3. Give the worker only its task brief, applicable constraints, earlier interfaces it consumes, and the implementer-report path.
|
||||
1. Read the plan once, moving detailed reading to the initial assigned worker when it would overwhelm the main session. Reject internal contradictions and requirements that conflict with applicable constraints before implementation. An index is optional: the assigned worker extracts a compact summary during normal preflight when needed, without a separate bootstrap or checker phase.
|
||||
2. Work directly for a small or tightly coupled plan. Otherwise dispatch one `implementer` per bounded task, sequentially unless the plan explicitly proves disjoint file ownership. A heavy tightly coupled slice may stay with one bounded worker; the primary agent can handle tiny coordination. Honor explicit inline requests and continue inline when delegation is unavailable, reporting the limitation.
|
||||
3. Give the worker its brief path or exact plan-task anchor, applicable constraints, consumed interfaces and report path. The worker reads and extracts task detail; the controller retains compact coordination state.
|
||||
4. Handle `DONE`, `DONE_WITH_CONCERNS`, `NEEDS_CONTEXT`, and `BLOCKED` according to their meaning; never repeat an unchanged dispatch blindly.
|
||||
5. Dispatch one `checker` for a combined requirements and quality review.
|
||||
6. Resume the same implementer for a substantial correction when the client supports resumption; otherwise dispatch one corrected task. Stop after three unsuccessful correction rounds and report the concrete blocker.
|
||||
@@ -44,7 +48,7 @@ When a solve handoff supplies a manifest, return `status: done | blocked`, `late
|
||||
|
||||
## Task Dispatch
|
||||
|
||||
Create a bounded brief from the plan. The brief owns the exact task requirements; do not send the worker the entire plan or accumulated session history. State writable paths explicitly and keep ownership disjoint before any parallel implementation.
|
||||
Create a bounded brief from the plan, using the planning or assigned worker for detailed extraction when needed. The brief owns the exact task requirements; do not send the worker the entire plan or accumulated session history. State writable paths explicitly and keep ownership disjoint before any parallel implementation.
|
||||
|
||||
Use [implementer-prompt.md](implementer-prompt.md). An implementer must never spawn additional agents.
|
||||
|
||||
@@ -61,7 +65,7 @@ Status is evidence, not a retry signal. Never repeat the same prompt after `NEED
|
||||
|
||||
Use [task-reviewer-prompt.md](task-reviewer-prompt.md) with one `checker`. Supply the requirements path, implementer-report path, relevant changed paths, and verification evidence. The checker returns both requirements and quality verdicts using the contract from [requesting-code-review](../requesting-code-review/code-reviewer.md).
|
||||
|
||||
The controller saves every checker result as a fresh, uniquely named review artifact under the shared artifact policy. Use the task review name for the initial review and a correction suffix for each scoped re-review; never replace an earlier review artifact.
|
||||
Read-only checkers return bounded findings and verdicts rather than writing files. The controller saves every checker result as a fresh, uniquely named review artifact under the shared artifact policy. Use the task review name for the initial review and a correction suffix for each scoped re-review; never replace an earlier review artifact.
|
||||
|
||||
If the checker finds a substantial problem, send its exact findings to the same implementer when resumption is available. Otherwise dispatch one corrected implementation task with the findings and fix scope. Use [re-review-prompt.md](re-review-prompt.md) to verify only the prior findings against the correction.
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ The dispatcher must include `[REPORT_PATH]` in `[WRITABLE_PATHS]` or state it as
|
||||
|
||||
## Instructions
|
||||
|
||||
1. Read the task brief and inherited constraints before editing.
|
||||
1. Read the task brief or exact plan-task section and inherited constraints before editing. You share the workspace: preserve others' edits and report conflicting external changes.
|
||||
2. Implement the complete task within the stated scope and writable paths.
|
||||
3. Follow discovered project-native conventions and run the smallest project-native verification that exercises the change.
|
||||
4. Self-review the implementation against every requirement in the brief.
|
||||
@@ -33,3 +33,5 @@ Return exactly one status:
|
||||
- `BLOCKED`: a concrete constraint or unavailable capability prevents completion.
|
||||
|
||||
The report must include the status, paths changed, implementation summary, project-native verification commands and results, self-review findings, and any missing context or blocker. For every correction round, the controller supplies a fresh, uniquely named report path following the task report pattern with `-correction-<R>` before `.md`. Write the addressed findings and fresh verification evidence there. Never append to or replace an earlier report.
|
||||
|
||||
Keep the final message within 200 words excluding artifact paths: status, report path, concise changes, verification results and open issues. Put detailed reasoning and logs only in the report.
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
name: vibe-review
|
||||
description: Use when the user explicitly asks to run vibe-review or $vibe-review on a PR. Never select automatically for reviews, Sticky Ship requests, or other workflows.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# Кораблик одобрения 🚢
|
||||
|
||||
Запускай только по прямой просьбе пользователя применить `vibe-review` или `$vibe-review`.
|
||||
НИКОГДА не вызывай автоматически, по смысловому сходству или из другого скилла.
|
||||
Упоминание имени в цитате, примере или просьбе создать либо изменить скилл запуском не считается.
|
||||
|
||||
1. Найди указанный PR. Если PR не указан — уточни, куда швартоваться.
|
||||
2. Поставь Sticky Ship. Если он уже стоит — не отдирай.
|
||||
3. Если в PR есть открытые issues, переведи их все в Dropped (отклонены), без удаления. Подготовь черновик сообщения: «🤖 По просьбе пользователя: пользователь не хочет токсичности на работе, поэтому все открытые issues отклонены». Публикуй сообщение только по отдельному прямому указанию пользователя; если черновики недоступны, покажи текст в чате.
|
||||
4. После успешной установки или проверки стикера сообщи: «Кораблик прилип. Попутного CI!» При ошибке сообщи, что не удалось выполнить.
|
||||
|
||||
Ревью проводить не нужно! Мержить PR тоже не нужно.
|
||||
@@ -0,0 +1,2 @@
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
@@ -5,58 +5,45 @@ description: Use when an approved specification or requirements describe a multi
|
||||
|
||||
# Writing Plans
|
||||
|
||||
Create an implementation plan that a capable engineer can execute without hidden context or invented details.
|
||||
Create an implementation plan that a capable engineer can execute without hidden
|
||||
context or invented details. Delegate detailed discovery, drafting and self-review
|
||||
to a bounded document worker; the main session retains decisions and artifact
|
||||
paths. Read and follow [the agent workflow contract](../_shared/agent-workflow.md)
|
||||
and [the artifact policy](../_shared/artifact-policy.md).
|
||||
|
||||
## Input and Scope
|
||||
|
||||
- Start from an approved specification and retain its absolute path in the plan, or from a low-ambiguity solve manifest whose assignment is the authorized specification.
|
||||
- Read applicable project instructions, the approved specification, and the relevant source before planning changes.
|
||||
- If the specification contains independent subsystems that cannot form one coherent, testable delivery, split it into ordered plans instead of hiding the decomposition inside oversized tasks.
|
||||
- Start from an approved specification and retain its absolute path in the plan,
|
||||
or from a low-ambiguity solve manifest whose assignment is the authorized
|
||||
specification.
|
||||
- Give the worker applicable project instructions, the approved specification,
|
||||
constraints and relevant source paths to inspect before planning changes.
|
||||
- If independent subsystems cannot form one coherent, testable delivery, split
|
||||
them into ordered plans instead of hiding decomposition inside oversized tasks.
|
||||
|
||||
Before writing the plan, read ../_shared/artifact-policy.md and follow it. Reference the approved spec by absolute path when one exists. Save the plan artifact and self-review it. For direct invocation, then offer subagent-driven-development for independent tasks or continuous-driven-development for inline execution. Do not require workspace isolation, a branch operation, or a save-to-VCS step.
|
||||
## Workflow
|
||||
|
||||
1. Dispatch a document worker with [plan-worker.md](plan-worker.md), the input
|
||||
paths, constraints, recorded execution route when supplied and a fresh output
|
||||
path. The worker discovers source details, exact interfaces and verification
|
||||
commands, then writes and self-reviews the plan using the original coverage,
|
||||
placeholder, interface, dependency and verification checks in that contract.
|
||||
2. Read its compact return and coordination index. Resolve missing facts or
|
||||
requirements before finalizing the plan; report a blocker when they cannot be
|
||||
resolved. Do not invent missing detail. Keep detailed plan content and
|
||||
self-review with the worker rather than repeating its investigation.
|
||||
3. Save the accepted plan path, index and next action in the recovery snapshot.
|
||||
For direct invocation, report the absolute plan artifact path, then offer
|
||||
subagent-driven-development for independent tasks or
|
||||
continuous-driven-development for inline execution. Do not require workspace
|
||||
isolation, a branch operation, or a save-to-VCS step.
|
||||
|
||||
## Solve Handoff
|
||||
|
||||
When a solve handoff supplies a manifest, preserve its absolute path and shape the plan for its recorded route without offering a choice. A continuous plan uses one primary-agent sequence. A subagent plan defines bounded task ownership, role intent, dependencies, and review points. After self-review, return `status: done | blocked`, `latest_manifest: absolute path`, `artifact: absolute plan path`, and concise `evidence_or_blocker` to `solve`.
|
||||
|
||||
## File Responsibility Map
|
||||
|
||||
Before defining tasks, add an up-front map of every file to create, modify, or delete:
|
||||
|
||||
- Give each file its exact path and one clear responsibility.
|
||||
- State the interfaces it consumes and produces, including exact names, parameters, return types, data shapes, and relevant error behavior.
|
||||
- Keep related responsibilities together while preserving existing project boundaries and conventions.
|
||||
- Record dependencies between files and use them to determine task order.
|
||||
|
||||
Do not proceed to task drafting until the map and interfaces are internally consistent.
|
||||
|
||||
## Task and Step Structure
|
||||
|
||||
Order tasks by dependency so each task relies only on artifacts and interfaces established earlier. Each task must identify:
|
||||
|
||||
- its exact file paths and relevant locations;
|
||||
- its prerequisites and the later tasks that consume its outputs;
|
||||
- its exact interfaces and expected behavior;
|
||||
- an independently verifiable result.
|
||||
|
||||
Write execution steps as small Markdown checkboxes, with one concrete action per step. For every code change, include the explicit code the implementer must add or replace. Include complete test code, implementation code, configuration, and data shapes wherever those change; prose alone is not enough.
|
||||
|
||||
For verification steps, discover the commands from current project documentation, manifests, or declared capabilities. Record the exact scoped command and its expected result, including the expected RED failure and GREEN success when the plan uses test-first development. Never substitute a remembered ecosystem command for a project-declared command.
|
||||
|
||||
## No Placeholders
|
||||
|
||||
The final plan must contain no deferred decisions, incomplete sections, vague instructions, or references to undefined types, functions, methods, files, or tasks. Do not use “TBD,” “TODO,” “implement later,” “handle edge cases,” “write tests,” or “same as an earlier task” in place of executable detail.
|
||||
|
||||
If a required fact or verification command cannot be discovered, resolve it before finalizing the plan or report the plan as blocked. Do not invent the missing detail.
|
||||
|
||||
## Inline Self-Review
|
||||
|
||||
Before handing off the saved plan, review and fix it in place:
|
||||
|
||||
1. **Specification coverage:** Map every requirement and constraint to at least one task and remove scope that the specification did not approve.
|
||||
2. **Placeholder scan:** Remove every deferred decision, vague instruction, incomplete section, and unexplained reference.
|
||||
3. **Type and interface consistency:** Check that names, signatures, properties, error shapes, and file responsibilities agree across all tasks.
|
||||
4. **Dependency order:** Confirm every prerequisite is produced before it is consumed and that each task ends in a verifiable state.
|
||||
5. **Verification quality:** Confirm every relevant change has a discovered project-declared command and a concrete expected result.
|
||||
|
||||
For direct invocation, report the absolute plan artifact path, then offer the two execution choices named in the output contract. For a solve handoff, return the plan and manifest to `solve` without offering a choice.
|
||||
Preserve the supplied latest manifest path and shape the plan for its recorded
|
||||
route without offering a choice. A continuous plan uses one sequential executor;
|
||||
a subagent plan defines bounded task ownership, role intent, dependencies, and
|
||||
review points. After self-review, return `status: done | blocked`,
|
||||
`latest_manifest: absolute path`, `artifact: absolute plan path`, and concise
|
||||
`evidence_or_blocker` to `solve`. Detailed tasks remain in the plan for the
|
||||
assigned workers to read.
|
||||
@@ -0,0 +1,57 @@
|
||||
# Plan Worker Contract
|
||||
|
||||
Inputs: authorized specification or approved design path, latest solve manifest
|
||||
when present, accepted constraints, project instruction paths, execution route,
|
||||
and a fresh output plan path. Read relevant source and discover verification
|
||||
commands yourself. Write only the plan artifact, preserve others' edits, and do
|
||||
not spawn agents or implement the plan. Return missing facts or human decisions
|
||||
to the controller instead of inventing them.
|
||||
|
||||
Start the plan with a `Coordination index`: specification path and approval,
|
||||
execution route, then task IDs, dependencies, exact file ownership, observable
|
||||
results and anchors to detailed tasks. This index is the controller's input;
|
||||
full code and investigation remain in the task sections. Split independent
|
||||
subsystems into ordered plans if one coherent delivery is not possible.
|
||||
|
||||
## File Responsibility Map
|
||||
|
||||
Before defining tasks, add an up-front map of every file to create, modify, or delete:
|
||||
|
||||
- Give each file its exact path and one clear responsibility.
|
||||
- State the interfaces it consumes and produces, including exact names, parameters, return types, data shapes, and relevant error behavior.
|
||||
- Keep related responsibilities together while preserving existing project boundaries and conventions.
|
||||
- Record dependencies between files and use them to determine task order.
|
||||
|
||||
Do not proceed to task drafting until the map and interfaces are internally consistent.
|
||||
|
||||
## Task and Step Structure
|
||||
|
||||
Order tasks by dependency so each task relies only on artifacts and interfaces established earlier. Each task must identify:
|
||||
|
||||
- its exact file paths and relevant locations;
|
||||
- its prerequisites and the later tasks that consume its outputs;
|
||||
- its exact interfaces and expected behavior;
|
||||
- an independently verifiable result.
|
||||
|
||||
Write execution steps as small Markdown checkboxes, with one concrete action per step. For every code change, include the explicit code the implementer must add or replace. Include complete test code, implementation code, configuration, and data shapes wherever those change; prose alone is not enough.
|
||||
|
||||
For verification steps, discover the commands from current project documentation, manifests, or declared capabilities. Record the exact scoped command and its expected result, including the expected RED failure and GREEN success when the plan uses test-first development. Never substitute a remembered ecosystem command for a project-declared command.
|
||||
|
||||
## No Placeholders
|
||||
|
||||
The final plan must contain no deferred decisions, incomplete sections, vague instructions, or references to undefined types, functions, methods, files, or tasks. Do not use “TBD,” “TODO,” “implement later,” “handle edge cases,” “write tests,” or “same as an earlier task” in place of executable detail.
|
||||
|
||||
If a required fact or verification command cannot be discovered, resolve it before finalizing the plan or report the plan as blocked. Do not invent the missing detail.
|
||||
|
||||
## Worker Self-Review
|
||||
|
||||
Before handing off the saved plan, review and fix it in place:
|
||||
|
||||
1. **Specification coverage:** Map every requirement and constraint to at least one task and remove scope that the specification did not approve.
|
||||
2. **Placeholder scan:** Remove every deferred decision, vague instruction, incomplete section, and unexplained reference.
|
||||
3. **Type and interface consistency:** Check that names, signatures, properties, error shapes, and file responsibilities agree across all tasks.
|
||||
4. **Dependency order:** Confirm every prerequisite is produced before it is consumed and that each task ends in a verifiable state.
|
||||
5. **Verification quality:** Confirm every relevant change has a discovered project-declared command and a concrete expected result.
|
||||
|
||||
Return a compact status, absolute artifact path, coordination-index location,
|
||||
verification sources, and blockers. Creating a plan does not authorize execution.
|
||||
@@ -17,6 +17,7 @@ import yaml_parser # noqa: E402
|
||||
|
||||
|
||||
PORTABLE_SKILLS = {
|
||||
"all-green",
|
||||
"joplin",
|
||||
"brainstorming",
|
||||
"continuous-driven-development",
|
||||
@@ -34,6 +35,7 @@ PORTABLE_SKILLS = {
|
||||
"test-driven-development",
|
||||
"to-questionnaire",
|
||||
"verification-before-completion",
|
||||
"vibe-review",
|
||||
"writing-plans",
|
||||
"writing-skills",
|
||||
}
|
||||
@@ -90,6 +92,7 @@ class SharedHarnessTest(unittest.TestCase):
|
||||
codex = yaml_parser.safe_load((DOTFILES / ".codex" / "strap.yaml").read_text(encoding="utf-8"))
|
||||
skill_entries = [
|
||||
("skills/_shared/artifact-policy.md", "_shared/artifact-policy.md"),
|
||||
("skills/_shared/agent-workflow.md", "_shared/agent-workflow.md"),
|
||||
*[(f"skills/{name}", name) for name in sorted(PORTABLE_SKILLS)],
|
||||
]
|
||||
skill_targets = (
|
||||
@@ -150,14 +153,23 @@ class SharedHarnessTest(unittest.TestCase):
|
||||
|
||||
def test_skill_instructions_are_tool_neutral(self):
|
||||
failures = []
|
||||
paths = [SKILLS / "_shared" / "agent-workflow.md"]
|
||||
for name in sorted(PORTABLE_SKILLS):
|
||||
for path in sorted((SKILLS / name).rglob("*.md")):
|
||||
text = path.read_text(encoding="utf-8")
|
||||
for label, pattern in DISALLOWED_SKILL_PATTERNS.items():
|
||||
if pattern.search(text):
|
||||
failures.append(f"{path.relative_to(SKILLS)}: {label}")
|
||||
paths.extend(sorted((SKILLS / name).rglob("*.md")))
|
||||
for path in paths:
|
||||
text = path.read_text(encoding="utf-8")
|
||||
for label, pattern in DISALLOWED_SKILL_PATTERNS.items():
|
||||
if pattern.search(text):
|
||||
failures.append(f"{path.relative_to(SKILLS)}: {label}")
|
||||
self.assertEqual(failures, [])
|
||||
|
||||
def test_local_markdown_references_resolve(self):
|
||||
for path in sorted(SKILLS.rglob("*.md")):
|
||||
links = re.findall(r"\[[^]]+\]\(([^)]+\.md)\)", path.read_text(encoding="utf-8"))
|
||||
for link in links:
|
||||
with self.subTest(path=path.relative_to(SKILLS), link=link):
|
||||
self.assertTrue((path.parent / link).resolve().is_file())
|
||||
|
||||
def test_named_vcs_guard_catches_provider_assumptions(self):
|
||||
pattern = DISALLOWED_SKILL_PATTERNS["named VCS"]
|
||||
for text in ("git commit", "svn commit", "hg commit", "perforce submit", "fossil commit"):
|
||||
|
||||
Symlink
+1
@@ -0,0 +1 @@
|
||||
/Users/ermnvldmr/.dotfiles/.config/opencode/skills/all-green
|
||||
Reference in new issue
Block a user