goal-flow
Manage explicitly requested Hephaera goals as automated multi-task delivery flows with automatic per-task PR creation and required post-PR QA.
- License 许可
- MIT
- 最近更新
- 2026-11-08
- Stars
- ★ 4
- Forks
- 3
01 前言 Front Matter
- name
- goal-flow
- engines
- [ "AGNOSTIC" ]
- description
- Manage explicitly requested Hephaera goals as automated multi-task delivery flows with automatic per-task PR creation and required post-PR QA.
02 资源文件 35
- 参考文档adapters.md711 B
- 参考文档agents/openai.yaml200 B
- 参考文档api.md699 B
- 参考文档check.md9.7 KB
- 参考文档classify.md724 B
- 参考文档context.md4.8 KB
- 参考文档contract-lint.md2.7 KB
- 参考文档crash-evidence.md1.5 KB
- 参考文档dashboard.md4.2 KB
- 参考文档docs.md1.8 KB
- 参考文档doctor.md5.7 KB
- 参考文档evidence.md1.4 KB
- 参考文档explain.md7.4 KB
- 参考文档flow.md732 B
- 参考文档handoff.md1.7 KB
- 参考文档help.md2.2 KB
- 参考文档impact.md626 B
- 参考文档index.md6.0 KB
- 参考文档init.md9.7 KB
- 参考文档line-endings.md1.7 KB
- 参考文档map.md3.1 KB
- 参考文档next.md1.5 KB
- 参考文档onboard.md1.7 KB
- 参考文档quality.md740 B
- 参考文档run.md5.2 KB
- 参考文档script-pack.md937 B
- 参考文档search.md4.3 KB
- 参考文档status.md1.9 KB
- 参考文档tech.md702 B
- 参考文档update.md6.7 KB
- 参考文档upgrade.md1.0 KB
- 参考文档verify.md6.1 KB
- 参考文档version-sources.md1.3 KB
- 参考文档version.md1.2 KB
- 参考文档workspace.md1.8 KB
03 SKILL.md 正文
When to use
Use when the user explicitly requests a goal, says goal flow, or a task planning artifact marks Goal Flow: enabled or Flow: goal.
Do not activate goal flow from the generic ## Goal section in a normal TASK.md. That section describes task intent; it is not the automated goal feature.
Do not activate or create goal flow while repository-root BRAINSTORM.md is active. Brainstorm must be explicitly closed and converted into a plan first.
Output
- goal file path under
../.hephaera/.cache/goals/<goal_name>/GOAL.md - ordered goal task list
- task flow mode marked as
goal - per-task PR readiness report generated with goal automation enabled
- automatic PR creation after each completed task
- post-PR QA evidence before advancing to the next goal task
- branch-chain records when later work depends on earlier unmerged PR branches
- final goal completion report with PR links in approval order
Notes
- Goal task publication is one scoped exception to the normal human PR readiness prompt. The other is work-unit progress publication under an explicitly approved Gauntlet contract; Gauntlet promotion remains human-gated.
- Goal flow does not skip validation, PR creation evidence, issue linkage, or post-PR QA.
- Goal flow never implies auto-merge, merge approval, or auto-merge enablement.
- If a later goal task depends on an earlier task or would likely create merge conflicts when based on the original base branch, base the later task branch on the previous task branch or PR head and record the dependency.
- When every goal task has completed post-PR QA, generate
GOAL_REPORT.mdwith ordered PR links, branch dependencies, QA evidence, and merge-conflict risk notes for human approval. - Stop automatic advancement if local validation fails, PR creation fails, post-PR QA fails, or a task requires a human decision not covered by the goal plan.
- The project-manager role owns goal decomposition, task ordering, and any parallel sub-agent lane decisions within a goal task.
- Use
./commands/pr-readiness-check.sh --goalto create a durable readiness report that records the goal-flow exception.
Commands
./commands/create-goal-file.sh "<goal_name>" ["Goal Title"] [--dry-run] ./commands/create-goal-completion-report.sh "<goal_name|goal_dir|goal_file>" [--dry-run]
04 同仓库更多 Skills
verify-web3-game-lifecycle
Verify a game's selected Web3 asset, wallet, ownership and trading lifecycle with contract properties, canonical recovery, actual target evidence and separate release readiness.
verify-onchain-game-assets
Verify exact on-chain game collection ownership and quantities at canonical blocks, reconcile inventory events, and design honest match admission. Use for ERC721/ERC1155 inventory, reorg recovery, reservations, or transfer-during-match rules.
plan-web3-game-assets
Define an opt-in Ethereum, Base or Immutable game-asset lifecycle, including token identity, supply, rights, custody, game eligibility and chain-specific dependencies.
integrate-game-wallets
Integrate explicit player-wallet connection, scoped SIWE authentication, authority invalidation and reviewed target-specific handoff without application-held player keys.
integrate-game-asset-trading
Integrate explicitly selected game asset settlement with exact unsigned intents, scoped approvals, idempotent operations and canonical receipt reconciliation. Use for NFT listing, buying, cancellation, retries or marketplace integration.
build-evm-game-contracts
Author and verify host-owned EVM game collections and explicit mint, burn, craft or admin rules with pinned Solidity tooling. Use for contract source and deployment candidates; deployment and player signing require separate authorization.