# Pkstack Verified Goal > Work toward a concrete objective in the current Kiro agent session and require deterministic projectctl verification before reporting success. Use for multi-step implementation, repair, migration, or refactoring with an executable acceptance check. - Skill: `njs14/pkstack-verified-goal` (Agent Skill) - Install (CLI): `npx skillmds@latest add njs14/pkstack-verified-goal` - Raw SKILL.md: https://api.skillmd.com/api/skills/njs14/pkstack-verified-goal/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: njs14 (https://skillmd.com/u/njs14) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/njs14/pkstack-verified-goal --- # Run a verified goal Stay in the current Kiro agent session on the selected surface. Do not start another Kiro session or a parallel user session. Kiro Crew may own the session and use ACP internally, but it remains optional and does not change the goal contract. Native sub-agents may help with bounded diagnosis, but the primary agent owns the goal and its evidence. Treat the request text that activated this skill as the objective and acceptance context. This method executes the current task. For a request to build reusable automation, use [`build-iterated-agentic-loop`](../build-iterated-agentic-loop/SKILL.md); this goal may verify that build, but it does not create or enable a recurring workflow by itself. If failure shows verifier drift, use [`maintain-verification-skill`](../maintain-verification-skill/SKILL.md) for a separately bounded verifier repair. Product failures stay in the authorized goal; never turn a failing product expectation into verifier maintenance just to obtain a pass. This is a PROVE + DO workflow. Start from the stored feature/spec verifier and its executable evidence; do not run broad KNOW retrieval by default. Escalate to one bounded, targeted knowledge query only when failure evidence exposes a concrete architecture, decision, concept, or operations question that the feature record and its related links cannot answer. Record that reason. ## Resolve the controller once Use `.pkstack/bin/projectctl` for the entire loop. It is the bootstrap-managed entrypoint and has a locked repo-local runtime. Do not select `./projectctl`: bootstrap deliberately preserves that name when the host project already owns it. Do not use ambient `uv run projectctl` package resolution. If the internal runner is unavailable, stop with the exact missing prerequisite and direct the user to `/pkstack-setup`. Do not emulate goal state in prose or create an ad hoc state file. ## Establish the acceptance contract 1. Run ` goal status --output json` before starting anything. A structured `no goal state exists` error means there is no active state and a new goal may be started. 2. If another objective is active, do not overwrite or clear it. Continue only when it is the same objective and the stored verifier remains valid; otherwise report the conflict. 3. Inspect `.kiro/specs/` as well as ` feature list --output json`. A matching native Spec package is planning provenance, not proof. It is ready to bind only when it has non-empty `requirements.md` or `bugfix.md`, `design.md`, and `tasks.md`. 4. Prefer an existing published feature verifier after inspecting ` feature show --output json`. If the request continues a matching native spec, bind that spec to the feature so the goal retains both proven feature and native planning provenance: ```text goal bind-spec --feature --output json ``` Reusing an identical bridge is idempotent. Never pass `--overwrite` until the existing bridge and replacement have both been reviewed. 5. When no published feature applies, review an executable repository test, build, lint, type-check, or domain command for the requested behavior. A new feature may begin with a failing verifier; it does not need a published feature record before implementation. Bind a matching native spec with ` goal bind-spec --command "" --output json`, or use an explicit goal command. Use `create-verification-skill` if the project lacks a way to drive and observe its public behavior. After the goal passes, publish a reusable feature contract when it will help future work. 6. Do not create a fake spec directory, edit native requirements/design/tasks merely to make the bridge pass, infer Quick Spec provenance from filenames, or treat completed task checkboxes as executable evidence. Do not weaken a verifier to obtain a pass. If no checkable predicate can be established, ask one targeted question rather than claiming success. Start new state with exactly one verifier: ```text goal start "" --feature --max-attempts 4 --output json goal start "" --spec --max-attempts 4 --output json goal start "" --command "" --max-attempts 4 --output json ``` Use `--spec` when a matching native package and bridge exist. Its bridge may point to a published feature or the reviewed command for a feature still being built. It does not replace Kiro's planning artifacts or introduce another task runner. If a native spec exists but has no executable bridge, bind its reviewed verification contract instead of silently dropping its provenance. Before the first verification attempt in every skill invocation, display `goal.contract.display` and its provenance from the latest status or start response to the user. This applies whether the goal was just created or was already active when the invocation began. The shell approval UI is not a substitute for showing the exact stored predicate in the workflow. Never include credentials or other secrets in the objective or stored command. For new behavior, run ` goal verify --output json` before editing and inspect the recorded failure. Keep that acceptance predicate unchanged while repairing the implementation. If it already passes, inspect whether it proves the requested behavior before making unnecessary changes. ## Iterate For every attempt: 1. Read the current status and evidence. 2. Make the smallest evidence-backed change likely to advance the stored predicate. 3. Run ` goal verify --output json`. This command owns the attempt increment and the transition to `active`, `passed`, or `exhausted`; do not duplicate those transitions manually. 4. On `passed`, inspect ` goal status --output json` and report completion with the exact verifier and result. 5. On `active`, diagnose the new evidence. Discard a non-advancing approach instead of repeating the same-shaped change. Use ` goal tripwire --output json` only as a read-only advisory signal. 6. On `exhausted`, stop and report the genuine dead end, attempts, last evidence, and next viable choices. `goal verify` exits non-zero while the verifier is failing. That is expected for `active` and `exhausted`; read the JSON payload and follow its stored status instead of treating the shell exit alone as a tool failure. Do not automatically run `goal resume`, add attempts, or run `goal clear --force`. Use ` goal resume --add-attempts --output json` only when the user explicitly extends an exhausted goal. Clear state only on an explicit request after preserving the final evidence. ## Completion standard At handoff, maintain project understanding materially changed by the authorized work using [`the OKF document lifecycle`](../okf/references/document-lifecycle.md). Link retained findings to the exact verifier evidence, preserve uncertainties, and mark superseded guidance. This does not change the goal contract or turn a documentation update into executable proof. A plausible explanation, a clean diff, a sub-agent opinion, or an external review is not a pass. Completion requires `goal verify` to return `passed` for the stored executable verifier. Report any checks that were not run or any environment limitation separately.