Harness Start Gate

Harness Start Gate

Purpose

Use this gate before implementation. Decide whether the next action is safe to begin or whether the work first needs clarification, retrieval, alignment, delegation, or durable pre-work memory.

This skill routes. It does not write Feature pages, specs, plans, ADRs, Evidence, or code.

Workflow

1. Classify the task as tiny, routine, non-trivial, or high-risk.
2. Check whether retrieval, Spec Drift, Vision Gate, Delegation Gate, Feature, spec, plan, ADR, Backlog, or handoff anchor is needed.
3. Choose exactly one primary outcome.
4. Report the Start Gate result before implementation starts.

Goal-Driven Feature Flow

When a clear Goal authorizes a multi-Feature effort, creating or updating the Feature page is required memory, not a user approval checkpoint. Return ready when the next Feature slice is inside the approved Goal, Feature Intake can be answered, the Feature page will be created or updated before implementation, and the required Delegation decision is explicit.

Do not require default per-Feature design approval. Ask the user only when the Goal is missing or ambiguous, the proposed Feature exceeds the approved Goal, architecture, data model, security, cost, migration, or external contract decisions need user-level tradeoffs, acceptance criteria conflict, or patch churn suggests the direction may be wrong.

Empty Approval Guard

Do not ask the user to approve a Feature, design, or plan that has not been created or shown. If the artifact is missing, the next action belongs to the agent: create the Feature memory, present the necessary summary only when user judgment is required, or ask a targeted clarification question. Do not invent an Fxxx id or unblock phrase as a substitute for a project artifact.

Task Classes

Use the lightest class that honestly fits:

| Class | Meaning | Default gate pressure | | --- | --- | --- | | tiny | Local, reversible edit where project memory cannot change the outcome. | Usually ready. | | routine | Bounded change with clear intent and known verification path. | Usually retrieval optional. | | non-trivial | Feature work, refactor, behavior change, multi-file change, or unclear acceptance criteria. | Run retrieval or Vision Gate when triggered. | | high-risk | Boundary, architecture, data model, security, cost, migration, cross-feature decision, or process rule change. | Require a durable pre-work anchor before implementation. |

Risk Triggers

Check these before coding:

• Original goal, user pain point, acceptance criteria, non-goals, Vision Anchor, or owner boundary is unclear.
• A new or materially updated Feature would lack Feature Intake answers: original problem, user pain point, capability promise, non-goals, acceptance source, or open questions.
• Work spans multiple sessions, agents, modules, or delivery steps.
• Work changes public behavior, data shape, module boundaries, storage, infrastructure, permissions, external contracts, or Harness process rules.
• Prior decisions, active Feature state, stale-doc status, Lessons, Evidence, or patch history may affect the answer.
• Real cases, validation, or user feedback contradict an existing spec, stale spec, acceptance criteria, or accepted behavior.
• The proposed path looks broader, costlier, or more complex than the user goal requires.
• The task may have separable workstreams, parallel exploration, independent verification, or enough scope that implementation subagents should be proposed.
• The only way to recover context later would be the chat transcript.
• Superpowers spec or plan paths are being used for work that needs official Harness Feature, ADR, Lesson, or Evidence memory.

Core Outcomes

Return exactly one primary outcome:

ready | needs clarification | needs retrieval | needs spec-drift | needs vision gate | needs feature | needs spec | needs plan | needs ADR | blocked

If multiple outcomes apply, choose the earliest blocker:

blocked -> needs clarification -> needs retrieval -> needs spec-drift -> needs vision gate
  -> needs feature -> needs spec -> needs plan -> needs ADR -> ready

Delegation Decision Readiness Rule

Do not return ready for non-trivial or high-risk work until the report includes an explicit Delegation decision.

This rule requires a decision, not automatic subagent use. A valid decision must be single_agent, delegate, or blocked, grounded in the task shape and recorded in the Start Gate report.

If Delegation Gate is skipped, the Start Gate outcome must be blocked, needs clarification, or another pre-work outcome instead of ready.

For single_agent, include the concrete reason. Do not treat a missing Delegation decision as single_agent; absence is a gate failure, not a decision.

Bug Intake

For a non-tiny bug, regression, broken accepted behavior, or validation failure, decide whether existing project memory may affect the fix before code search or edits.

Tiny local edits where project memory cannot change the outcome may skip retrieval, such as a tiny typo in a test fixture or comment, but the Start Gate report must say why.

If ownership or prior history is unknown, return needs retrieval before code search or edits.

If an accepted or completed Feature owns the behavior, record which Feature should receive the Patch History row after the fix.

Feature Intake Gate

Before creating a new Feature or materially changing an existing Feature's Vision Anchor, status, acceptance criteria, or capability boundary, verify that the Feature Intake can answer:

• Original problem.
• User pain point.
• Capability promise.
• Non-goals.
• Acceptance source.
• Open questions.

If any answer is missing or would be guessed from chat ambiguity, return needs clarification. Do not write a polished Feature page that hides unresolved ambiguity.

If the answers exist in a Superpowers spec, OpenSpec proposal, discussion, bug report, or prior chat summary, link the source from the Feature instead of copying the whole source. Feature Intake is the gate result, not a replacement for detailed specs.

Patch Churn Check

Before allowing a bugfix or follow-up patch against an already completed or accepted Feature, retrieve the Feature page and inspect ## Patch History.

Completed post-acceptance bugfixes are patch rows on the original Feature, using ids such as F010.1, F010.2, and F010.3. Do not create a new Feature only because a bug was found in an existing Feature.

If the Feature has 3+ Patch History rows, Fxxx.n patch slices, repeated validation misses, or growing scenario-specific rule branches and no ## Patch Churn Review, do not return ready. Return needs retrieval, needs vision gate, or needs ADR depending on the missing context.

Spec Drift Check

Start Gate only detects Spec Drift risk. It does not perform the full stale spec review.

If real cases, validation, or user feedback contradict an existing spec, acceptance criteria, or accepted behavior, do not return ready. Return needs spec-drift unless the earlier blocker is retrieval, clarification, Vision Gate, or ADR.

Use needs spec-drift for stale spec, outdated spec, acceptance criteria drift, SDD drift, or implementation follows spec but still wrong signals. Required pre-work should say: run harness-spec-drift before changing code.

Reference Map

Use references only when their trigger applies.

• references/start-gate-decision-rules.md: read when task class, outcome ordering, risk triggers, durable anchor requirements, or report details are unclear.
• references/bug-intake-and-patch-churn.md: read for non-tiny bugfixes, completed Feature follow-up fixes, Fxxx.n patches, repeated validation misses, or 3+ Patch History rows.

Report Format

Start Gate: ready | needs clarification | needs retrieval | needs spec-drift | needs vision gate | needs feature | needs spec | needs plan | needs ADR | blocked
Task class:
- tiny | routine | non-trivial | high-risk
Risk triggers:
- ...
Delegation decision:
- single_agent | delegate | blocked
Bug attribution:
- not triggered | existing Feature  | none found after retrieval | needs retrieval | needs feature
Spec drift:
- not triggered | needs spec-drift | spec valid after prior check | spec needs update | needs vision gate | needs ADR
Required pre-work:
- ...
Allowed next action:
- ...

Boundaries

• Do not create documents for every small task.
• Do not let a passing Start Gate replace verification, Evidence, or completion-time knowledge capture.
• Do not use Vision Gate to decide whether a Feature/spec/plan/ADR exists; Start Gate owns that intake decision.
• For non-trivial work, do not proceed with only chat history as the future Vision Gate source. Require a Feature, linked spec, or another durable Vision Anchor first.
• Absence of docs/features/ is not a reason to skip Feature memory. When non-trivial work needs a durable Vision Anchor, create the first canonical Feature page under docs/features/Fxxx-slug.md.
• Treat docs/superpowers/** as legacy spec/plan material only. Do not place Harness Feature, ADR, Lesson, or Evidence artifacts there.
• For non-tiny bugfixes, do not skip Feature attribution silently. If retrieval is not needed, the Start Gate report must say why project memory cannot change the fix.
• Do not skip Delegation Gate for medium or large work just because the user did not explicitly request subagents; the gate may conclude no delegation is needed, but the decision must be explicit.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: solitudeTG
• Source: solitudeTG/harness-coding-skills
• License: MIT

Install and usage instructions live in the source repository linked above.