Menü
Create or update a crate's README documentation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
One tick of a CI watchdog — check main-branch GHA status; spawn an agent to fix if failing and no investigation is in flight.
One tick of the henyey mainnet monitor — checks, metrics scan, deploy, status report
Continuous always-on orchestrator for the henyey project pipeline. Each pass queries the board, central-picks up to N actionable issues by priority, and fans out parallel foreground specialist sub-agents (triage/plan/do/review-pr) with the right Claude model per stage. Owns concurrency, conflict-avoidance, CI pipelining, sibling-nit consolidation, and a self-reflection pass that files pipeline-improvement issues. Replaces scripts/project-tick-loop.sh. Use when the operator asks to "run the loop", "process the board continuously", or "keep the pipeline going".
Single-pick dispatcher primitive for the henyey project pipeline. One tick = pick one actionable issue from the project board and dispatch the right specialist sub-agent for its current state. Used for manual single picks and `--issue=` recovery; the continuous orchestrator is `/project-loop`, which owns concurrency centrally. Use when the user asks to "run a tick", "pick up an issue", or "process one board item".
Run two parallel adversarial PR reviewers and combine their verdicts with external PR reviews (GH Copilot bot, humans, other bots) and CI state into a merge decision. Agent reviewers post structured comment verdicts (since the agent is the PR author and cannot self-approve via GH native review). External CHANGES_REQUESTED reviews block merge identically to agent CHANGES_REQUESTED. Operates on issues in `in-review`. Auto-merges with --admin on all-green (after filing follow-up issues for unaddressed inline review comments, so non-critical feedback is preserved as backlog instead of dropped); bounces to `ready-for-doing` on any request-changes or CI red; blocks after 3 bounce-backs on the same code state. At the lifetime cap (6 bounces since last `## Review: Reset`) the PR enters **force-converge mode**: if CI is green, the PR auto-merges and unresolved reviewer concerns become follow-up issues; only red/pending CI at the cap still blocks. Use when invoked by /project-tick with an issue in in-review, or manuall
Audit a Rust crate's adherence to its Stellar protocol spec (spec-driven, walks every normative claim)
| name | document |
| description | Create or update a crate's README documentation |
| argument-hint | <crate-path> |
Parse $ARGUMENTS:
$TARGET with it.Analyze the Rust crate at $TARGET and create or update its README.md.
If a README already exists, preserve any manually written content that is still accurate and fill in missing sections. If no README exists, create one from scratch.
Follow this section order. Every section is required unless marked optional.
# henyey-<crate>
One-line description of the crate's purpose.
One paragraph explaining what the crate does and where it sits relative to other henyey crates. Mention the key upstream stellar-core component it corresponds to if applicable.
A single diagram showing the crate's internal structure or its relationship to adjacent crates. Pick the ONE type that best fits:
Use Mermaid syntax so diagrams render on GitHub. Keep diagrams focused — max 15 nodes.
A table of the crate's important public types:
| Type | Description |
|------|-------------|
| `Foo` | ... |
Aim for 5-15 rows. Include traits, important enums, and config structs. Omit internal helpers.
2-3 short code examples showing the main API patterns. Cover the most common use cases: construction, the primary operation, and one edge case or secondary pattern (e.g., catchup mode, error handling).
Use rust fenced code blocks. Examples should compile conceptually but
do not need to be runnable standalone.
A table mapping each source file to its purpose:
| Module | Description |
|--------|-------------|
| `lib.rs` | ... |
| `foo.rs` | ... |
Include only if the crate has non-obvious design decisions that a new contributor would find surprising. Examples: savepoint semantics, change coalescing rules, determinism constraints, thread-safety approach.
Skip this section entirely if there is nothing surprising — do not pad with obvious statements.
A table mapping Rust modules to upstream stellar-core C++ files:
| Rust | stellar-core |
|------|--------------|
| `foo.rs` | `src/bar/Foo.cpp` |
This is critical for parity work. If the crate has no upstream equivalent, say so and omit the table.
## Parity Status
See [PARITY_STATUS.md](PARITY_STATUS.md) for detailed stellar-core parity analysis.
Only include if $TARGET/PARITY_STATUS.md exists.
stellar-core/.