Hepha

Runs autonomous iterative delivery loops for coding tasks using plan -> execute -> check -> review -> commit. Use when the user asks for hepha mode, autopilo...

Security Scan

The skill's files and runtime instructions are coherent with its stated purpose (autonomous small-step development loops); it requires no additional installs or secrets, but it will read and write project files and may run browser automation and network research as part of its normal operation.

Purpose & Capability

Name/description (autonomous plan->execute->check->review->commit loop) matches the SKILL.md, templates, and references. There are no unexpected required binaries, env vars, or install steps that are unrelated to implementing iterative development workflows.

Instruction Scope

Instructions explicitly direct the agent to read and update project files under a .autopilot directory, run project checks (lint/tests/build), perform browser-based validation (MCP/Playwright), and research live web/GitHub evidence. This behavior is consistent with the purpose, but it means the agent will access network resources and create artifacts (screenshots, logs) in the repository — review access policies and avoid exposing secrets in those artifacts.

Install Mechanism

No install spec or code is provided (instruction-only skill). Nothing will be downloaded or extracted by the skill package itself, minimizing supply-chain risk.

Credentials

The skill declares no required environment variables or credentials. That said, normal operation (commits, running tests, browser automation) will use the agent's existing git/environment/tooling permissions — there are no additional or unexpected credential requests in the skill materials.

Persistence & Privilege

always:false and user-invocable; the skill will create and maintain files only under the project's .autopilot/ directory and update the repo via commits per its protocol. It does not request system-wide changes or to modify other skills.

Assessment

This skill appears to do what it says: automate many small development loops and record progress in .autopilot/. When deciding to enable it, consider: 1) Only activate Hepha when you explicitly request 'hepha/autopilot' — the SKILL.md requires explicit activation. 2) Review and audit the .autopilot files the skill creates (they may include screenshots, logs, and decision notes) so no secrets or PII are accidentally captured. 3) Confirm the agent's git and CI permissions — the skill will commit changes and rely on whatever git credentials or hooks are already present. 4) If you are concerned about browser automation accessing internal systems, restrict the agent's network/tooling permissions or run it in a sandboxed environment. 5) Require human review of final or high-impact changes (especially high-risk tasks) even if the skill is used autonomously. Overall the skill is internally consistent, but operational safeguards (permissions, secret handling, commit review) are recommended.

Purpose

Run each requirement as multiple small, autonomous loops:

plan -> execute -> check -> review -> commit

Keep looping with minimal user intervention until the backlog is done or a stop condition is hit.

Activation

Activate only when the user explicitly asks for:

• hepha / autopilot / autonomous loop / unattended iteration
• continuous plan-execute-check-review-commit flow
• small-step commits until a larger requirement is completed

If the user did not explicitly request hepha, do not force this mode.

Non-Negotiable Operating Rules

1. One loop = one smallest shippable sub-task.
2. No commit before both engineering checks and browser review pass.
3. Every loop must update progress artifacts under .autopilot/.
4. If blocked, re-plan automatically; ask user only when truly necessary.
5. Prefer minimal diff and avoid unrelated files.

Required Working Artifacts

Create and maintain these files in the project's .autopilot/ directory:

• .autopilot/backlog.md - task graph and states (todo, doing, blocked, done)
• .autopilot/progress.md - per-loop execution log and evidence
• .autopilot/decision-log.md - research and technical decisions

Templates: Use the template files from templates/ in this skill directory as starting points:

• templates/backlog.md
• templates/progress.md
• templates/decision-log.md

If working files do not exist, copy from templates or create them before the first loop.

Loop Protocol

Execute the following phases in order for each loop.

1) PLAN (Enhanced)

Goal: pick exactly one ready sub-task from the backlog.

Steps:

Step 0.5 - Schema Validation (execute every PLAN):

Verify each task in backlog.md contains:

• ✅ id (format: TASK-XXX or numeric)
• ✅ title (action statement)
• ✅ state (todo|doing|blocked|done)
• ✅ depends_on (array, can be empty)
• ✅ acceptance (testable pass conditions)
• ✅ risk (low|medium|high)
• ✅ files_hint (expected files, optional)

Missing fields → complete before continuing Circular dependencies → detect and report error

Step 0 - Auto-Decomposition (if backlog.md missing or empty):

1. Analyze original requirement to identify core functional modules
2. Apply decomposition patterns (see references/decomposition-patterns.md):
   • Vertical slicing: split by user value path (UI → API → Data)
   • Risk-first: high-risk dependencies first
   • Independence: each task testable and committable separately
3. Generate task graph:
   • Assign unique ID to each sub-task (TASK-001, TASK-002...)
   • Identify dependencies (depends_on)
   • Assess risk level (low/medium/high)
   • Define acceptance criteria (acceptance)
4. Output to .autopilot/backlog.md

Step 1 - Normalize and Build Task Graph:

1. Normalize current requirement into:
   • Goal
   • Definition of done
   • Constraints
   • Out of scope
2. Build/refresh task graph:
   • Decompose Epic -> Tasks
   • For each task, define input/output, acceptance, dependencies, risk
3. Select one task from ready queue (all dependencies done).
4. Write loop plan into .autopilot/progress.md:
   • selected task
   • expected files
   • expected checks
   • expected browser validation path
   • Update progress visualization section

2) RESEARCH (explicit trigger conditions)

Goal: make informed decisions with live evidence.

Decision Matrix - Research Required?

Scenario Category	Specific Situation	Research Required
New Technology	Using library/framework not in project	✅ Yes
Architecture Change	Affects module boundaries or data flow	✅ Yes
Implementation Uncertainty	2+ viable options with >30% difference	✅ Yes
Tool Selection	MCP/Playwright/Puppeteer/etc. choice	✅ Yes
CRUD Operations	Standard CRUD	❌ No
Bug Fixes	Clear error fix	❌ No
Style Adjustments	CSS/style class modifications	❌ No

Research Quality Requirements:

1. Compare at least 2 options
2. Prefer official documentation and source code
3. Record: option summary → evidence links → tradeoffs → decision rationale

Record in .autopilot/decision-log.md:

• option A / B summary
• evidence links or source notes
• tradeoffs
• final decision and rationale

3) EXECUTE

Goal: implement the chosen sub-task with minimal blast radius.

Rules:

• Keep changes focused on required files only.
• Avoid speculative refactors.
• Keep functions small and reusable.
• Add concise comments only where logic is non-obvious.

4) CHECK

Goal: verify engineering quality.

Run all relevant project checks (examples):

• lint
• tests
• build/typecheck

If any check fails:

1. Capture failure details in .autopilot/progress.md.
2. Fix the root cause.
3. Re-run checks.
4. Repeat until pass or retry limit is reached.

5) REVIEW (browser and UX evidence required for UI/flow changes)

Goal: verify behavior from a user perspective, not only compile success.

For UI/interaction changes, use MCP browser tools and/or Playwright to validate:

• page load success
• key interaction path works
• expected text/element state is visible
• major regressions are absent

Attach review evidence to .autopilot/progress.md:

• interaction steps
• observed result
• screenshots/snapshots when relevant

6) COMMIT

Commit only when:

• checks passed
• review passed
• acceptance criteria for selected task are met

Commit policy:

• one loop, one commit
• conventional commit format
• message explains purpose/why, not only what

Update task status in .autopilot/backlog.md to done and append commit hash in progress log.

Re-Planning Policy

Trigger re-plan when:

• dependency changed
• repeated failures suggest wrong approach
• discovered scope mismatch

Re-plan behavior:

1. Split the current task into smaller tasks.
2. Mark blocked tasks explicitly with reason.
3. Continue from next ready task.

Stop Conditions

Stop loop and report clearly if any condition is met:

1. No ready task and unresolved blockers remain.
2. Same task fails checks/review 2 consecutive loops.
3. Required tooling is unavailable (critical checks cannot run).
4. User-defined risk boundary is exceeded.

When stopped, provide:

• current status
• blocker root cause
• proposed next actions

Completion Conditions

Consider a large requirement complete only when:

1. All backlog tasks are done.
2. Requirement-level definition of done is satisfied.
3. Relevant checks pass on final state.
4. Required review evidence is present.

Then generate a final completion summary:

• completed task list
• key decisions
• risk notes
• follow-up suggestions

Communication Style During Hepha

• Keep user updates brief and frequent.
• Do not ask for confirmation every loop.
• Ask user only for true ambiguity, policy conflicts, or missing credentials.

Suggested Starter Prompt For Users

Use this starter format to begin a run:

1. Enable hepha mode.
2. Run loop: plan -> execute -> check -> review -> commit.
3. Perform web/GitHub research before technical choices.
4. For UI flows, perform browser-based validation.
5. Continue until backlog is complete or stop condition is met.
6. Requirement/backlog: <paste requirement here>.

Additional References

• Planning details: references/planning_task-decomposition.md
• Quality gates: references/validation_quality-gates.md
• Decomposition patterns: references/decomposition-patterns.md
• Progress template: references/progress-template.md
• Working file templates: templates/backlog.md, templates/progress.md, templates/decision-log.md