# Harness Start Gate > MUST use before starting non-trivial AI-assisted engineering work, multi-file bugfixes, behavior changes, refactors, or implementation after task intake to decide whether the agent may implement now or must first clarify scope, retrieve project knowledge, run Vision Gate, run Spec Drift, run Delegation Gate, or create/update a Feature, spec, plan, ADR, Backlog, or handoff anchor; triggers include… - **Type:** Skill - **Install:** `agentstack add skill-solitudetg-harness-coding-skills-harness-start-gate` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [solitudeTG](https://agentstack.voostack.com/s/solitudetg) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [solitudeTG](https://github.com/solitudeTG) - **Source:** https://github.com/solitudeTG/harness-coding-skills/tree/main/skills/harness-start-gate ## Install ```sh agentstack add skill-solitudetg-harness-coding-skills-harness-start-gate ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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: ```text 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: ```text 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 ```text 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](https://github.com/solitudeTG) - **Source:** [solitudeTG/harness-coding-skills](https://github.com/solitudeTG/harness-coding-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-solitudetg-harness-coding-skills-harness-start-gate - Seller: https://agentstack.voostack.com/s/solitudetg - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.