procedural-development
Use when executing or resuming a specified issue or bounded development inventory in a GitHub repository. Not for repository-wide Bug discovery, Epic assessment, or merely authoring or reviewing skills.
- License 许可
- MIT
- 最近更新
- 2026-11-08
- Stars
- ★ 4
- Forks
- 2
01 前言 Front Matter
- name
- procedural-development
- description
- Use when executing or resuming a specified issue or bounded development inventory in a GitHub repository. Not for repository-wide Bug discovery, Epic assessment, or merely authoring or reviewing skills.
02 资源文件 4
- 参考文档references/coordination.md8.8 KB
- 参考文档references/delivery.md7.9 KB
- 参考文档references/root-lifecycle.md10.9 KB
- 参考文档references/worker-execution.md7.8 KB
03 SKILL.md 正文
Procedural development
Directives
Execution requires a user-authorized scope; reading, editing or testing skills never authorizes workers, issue mutations or environment replacement. Read repository/local instructions, including the primary worktree's local rules when working elsewhere, and required project memory. Repository delivery policy applies.
Retain one logical run, recovery record and item budgets across callers and resumes. Keep the current runtime root identity separate; only explicit user-authorized replacement uses the root lifecycle handoff. There must be one verified coordinator, not competing roots. The root owns orchestration, user communication, pushes, PRs and merges; it must not implement, edit owner worktrees, adjudicate their findings or replace reviewers. Each owner retains its item's planning, adjudication and resolution; implementers use assigned workspaces; reviewers are read-only. If nested dispatch is unavailable, the root dispatches leaves for their owner. Respect runtime depth and total capacity; do not create autonomous user-owned tasks to bypass limits.
Keep the original inventory and denominator. Record explicit scope revisions with timestamps and prior evidence; discoveries and follow-ups do not silently enter it. Honor draft-only/no-merge limits and caller-specific tracker closure authority.
Configuration
These are invocation parameters, not shell variables or CLI flags. Each role has
<ROLE>_MODEL, <ROLE>_REASONING and <ROLE>_TIER parameters:
| ROLE | Model default | Reasoning default | Tier default |
|---|---|---|---|
OWNER |
Astra | medium | default |
IMPLEMENTER |
Luna | high | priority |
SECURITY_IMPLEMENTER |
Daybreak Blue | high | default |
ESCALATED_IMPLEMENTER |
Astra | high | default |
REVIEWER_A |
GLM-5.3 | maximum supported | default |
REVIEWER_B |
Grok 4.6 | medium | default |
SYNTHESIS_REVIEWER |
Opus 5 | medium | default |
All defaults, including model choices, can be overridden on invocation.
Resolve explicit invocation overrides, then caller/local overrides, then defaults
above; inherited values are not overrides. Pass resolved settings unchanged to
nested calls and apply these rules to caller-defined roles too.
MAX_ACTIVE_OWNERS=7, WATCHDOG_MINUTES=30; the initial P2 budget is three
completed candidate rounds per item. Record user-authorized revisions explicitly.
Route preflight
Before issue mutation or worker launch, resolve exact model IDs and supported reasoning through local mappings and the live dispatch schema/catalog. Explicit routes need not appear in a default listing. Do not invent IDs, infer availability from a working proxy, or infer unavailability from an unfamiliar model. Unresolved bindings or unavailable required model/reasoning routes need a concrete blocker and explicit substitution; never silently lower reasoning or omit a reviewer.
Use self-contained briefs with the assigned role, scope, workspace, evidence and
report contract, including every worker execution brief field.
Supply applicable instructions, resource allocation and command-cleanup obligations
to every role; empty-history forks do not inherit them by assumption.
Follow the live schema's fork rules: where full-history forks
inherit model/reasoning and forbid overrides, use fork_turns="none" for an
overridden route. Dispatch by the actual tool recipient, not an execution wrapper.
A worker missing its brief requests it from its parent through send_message
when supported and performs no guessed assignment.
Tiers are preferences, not gates. default normally omits the tier argument.
Request priority only through a supported control; entitlement/availability
failure falls back to the same model and reasoning at default tier without
approval. Reconcile dispatch acceptance before retrying; hidden tier state never
justifies duplicating a worker. Record requested and confirmed tiers separately,
leaving unobservable effective tiers unconfirmed. Model/transport/tool failure is
not a tier failure or a clean review. Retry only the failed gate on its selected
route, preserving evidence; require success before broad reuse. Reduce optional
tools only when supported and without withholding necessary review evidence.
Procedure
- Read coordination and delivery. Owners/leaves receive the applicable delivery instructions. The root also reads root lifecycle and worker execution in full; all workers receive and read the execution contract.
- Record the run contract below in workflow-local scratch. These are evidence fields, not a new serialized API or executable framework.
- Preflight routes, dispatch mechanisms and declared resources. Verify root heartbeat admission before launching workers or waiting unattended; only then execute scheduling and delivery against the caller's readiness decisions. Unavailable heartbeat control is a coordination blocker, not permission to substitute.
- Reconcile recovery evidence and audit the requested endpoint before completion.
| Contract | Record |
|---|---|
| Identity | Repository, actual target branch/SHA, logical run ID, current root task ID, predecessor/handoff evidence, recovery location |
| Scope | Fixed IDs, sources, acceptance, existing ownership and completed evidence |
| Readiness | Dependencies, acceptance evidence per edge, decisions and dispositions |
| Roles | Exact model IDs, effective reasoning, requested/confirmed tiers, owner limit |
| Coordination | Heartbeat automation binding, confirmed target/status/cadence, observation/result reference, next due and last execution when exposed |
| Execution | Host/run allocation, per-command concurrency/deadline, worker-owned handles, exit and descendant-cleanup evidence |
| Delivery | Checks, commit/PR/merge rules, docs/release metadata, follow-up classification/channel, source-resolution rules |
| Tracker | Identity and allowed checkpoint channel: comment, managed body block, or none |
| Environment | Startup, target-advance, watchdog and final operations, executors and evidence |
| Exclusive resources | Exact resource names, flock skill, protected operations and authorized executors |
| Completion | Final predicates, allowed blocked accounting and tracker closure authority |
For direct invocation derive acceptance and policy from the specified items and repository. Default to no tracker, environment operations or locks unless required; do not require native issue types or create an Epic. Resolve material missing acceptance through the root while independent work progresses. Blocked is not delivered; the requested endpoint and required evidence determine delivery.
Declared locks
Only declared resources use workflow locks. Read the supplied/discovered flock
skill, source its helper and call lock "$RESOURCE" with the exact caller value.
Retain the owning shell/descriptor across all protected calls and verification;
a completed one-shot acquisition protects nothing later. Release on success/abort,
close ownership descriptors in long-lived children, and never hold locks while
waiting for unrelated workers, reviews or CI.
Contention defers only that operation; any acquisition failure prohibits its mutation. Report observed metadata, never steal/delete/replace a lock or kill its holder. Reacquire after shell loss/resume. If the mechanism is unavailable, keep the action pending and continue unrelated work. Do not invent file, worktree, test, database, review, publication or merge reservations. Isolated fixtures and application-internal correctness locks remain unaffected.
04 同仓库更多 Skills
triage-security-issues
Use when asked to coordinate triage and remediation of a repository's Dependabot malware/vulnerability, GitHub Code Scanning, GitHub Secret Scanning, and Codex Security cloud alerts. Not for starting a new scan or merely authoring or reviewing skills.
triage-fix-all-bugs
Use when asked to coordinate triage and remediation of all currently open native GitHub Bug issues in this repository. Not for a single issue or merely authoring or reviewing skills.
lcm-release
Use when explicitly asked to cut or recover a manual LCM release. Not for ordinary version bumps or Changesets release-note/version PR work.
implement-epic
Use when asked to execute or resume an existing planned native GitHub Epic and its required deliverables in this repository. Not for inventing a roadmap, triaging all Bugs, or merely authoring or reviewing skills.
flock
Use when cooperating workers need exclusive ownership of a named resource on the same Linux host through an advisory flock mutex.