kn-go
$
npx mdskill add knowns-dev/knowns/kn-goExecutes all tasks from an approved spec in one continuous run without manual review gates.
- Helps users implement an entire SDD pipeline from an approved spec in a single automated session.
- Integrates with MCP tools like mcp__knowns__get_doc and mcp__knowns__validate for spec validation and retrieval.
- Decides to run based on spec approval status, user commands like 'run all', and absence of unresolved open questions.
- Presents results by announcing execution, validating phases, and optionally providing a dry-run preview before committing.
SKILL.md
.github/skills/kn-goView on GitHub ↗
---
name: kn-go
description: Use when implementing all tasks from an approved spec in one continuous run without manual review gates
---
# Go Mode — Full Pipeline Execution
Run the entire SDD pipeline from an approved spec: generate tasks → plan each → implement each → verify → commit. No manual review gates between steps.
**Announce:** "Using kn-go for spec [name]."
**Core principle:** SPEC APPROVED → GENERATE TASKS → PLAN → IMPLEMENT ALL → VERIFY → COMMIT.
## When to Use
- User has an approved spec and wants to execute everything in one shot
- User says "run all", "go mode", "execute everything", or similar
- The spec is already approved (tag: `spec`, `approved`)
## When NOT to Use
- Spec is still draft — redirect to `/kn-spec` first
- User wants to review each task individually — use `/kn-plan <id>` + `/kn-implement <id>`
- Spec has unresolved open questions — resolve them first
## Inputs
- Spec path: `specs/<name>` (from `$ARGUMENTS` or ask user)
- Optional: `--dry-run` to preview tasks without executing
## Process
Complete these phases in order. Do not skip phases.
---
### Phase 1: Validate Spec
```json
mcp__knowns__get_doc({ "path": "specs/<name>", "smart": true })
```
**Check:**
- Tags include `approved` — if not, STOP: "Spec not approved. Run `/kn-spec <name>` first."
- Has Acceptance Criteria — if empty, STOP: "Spec has no ACs."
- No unresolved open questions marked as blocking
```json
mcp__knowns__validate({ "entity": "specs/<name>" })
```
If validation errors → fix or report before continuing.
---
### Phase 2: Generate Tasks
Parse spec for requirements and generate tasks. Same logic as `kn-plan --from @doc/specs/<name>` but **skip the approval gate**.
```json
mcp__knowns__create_task({
"title": "<requirement title>",
"description": "<from spec>",
"spec": "specs/<name>",
"fulfills": ["AC-1", "AC-2"],
"priority": "medium",
"labels": ["from-spec", "go-mode"]
})
```
Add implementation ACs per task:
```json
mcp__knowns__update_task({
"taskId": "<id>",
"addAc": ["Step 1", "Step 2", "Tests"]
})
```
**Report:** "Created X tasks from spec. Starting implementation..."
---
### Phase 3: Plan + Implement Each Task
Loop through all generated tasks in dependency order (foundational first, dependent last).
For each task:
#### 3a. Take ownership + plan
```json
mcp__knowns__update_task({
"taskId": "<id>",
"status": "in-progress"
})
mcp__knowns__start_time({ "taskId": "<id>" })
```
- Research context: follow refs, search related docs/memories, check templates
- Use `search` for discovery first. If a task/spec needs assembled execution context, use `mcp__knowns__retrieve({ "query": "<keywords>" })` before drafting or executing the plan. Fall back to CLI `knowns retrieve "<keywords>" --json` if MCP is unavailable.
- Draft and save plan directly (no approval gate)
```json
mcp__knowns__search({ "query": "<task keywords>", "type": "memory" })
```
```json
mcp__knowns__update_task({
"taskId": "<id>",
"plan": "1. Step one\n2. Step two\n3. Tests"
})
```
#### 3b. Implement
- Work through plan steps
- Check ACs as completed
- Run tests/lint/build after each task
```json
mcp__knowns__update_task({
"taskId": "<id>",
"checkAc": [1, 2, 3],
"appendNotes": "Implemented: brief summary"
})
```
#### 3c. Complete task
```json
mcp__knowns__stop_time({ "taskId": "<id>" })
mcp__knowns__update_task({
"taskId": "<id>",
"status": "done"
})
```
#### 3d. Quick validate
```json
mcp__knowns__validate({ "entity": "<id>" })
```
If errors → fix before moving to next task.
**Progress report between tasks:**
> "✓ Task X/Y done: [title]. Continuing..."
---
### Phase 4: Full Verification
After all tasks complete:
```json
mcp__knowns__validate({ "scope": "sdd" })
```
**Report SDD coverage:**
```
SDD Coverage Report
═══════════════════
Spec: specs/<name>
Tasks: X/X complete (100%)
ACs: Y/Z verified
```
If coverage < 100% → identify gaps and fix.
Also run project-level checks:
```bash
# Build/test/lint — adapt to project
go build ./...
go test ./...
```
---
### Phase 5: Commit
Stage all changes and commit with a single conventional commit:
```bash
git add -A
git diff --staged --stat
```
Generate commit message:
```
feat(<scope>): implement <spec-name>
- Task 1: <title>
- Task 2: <title>
- ...
- All ACs verified via SDD
```
**This is the ONE gate in go mode — ask user before committing:**
> Pipeline complete. X tasks done, SDD verified.
>
> Ready to commit:
> ```
> feat(<scope>): implement <spec-name>
> ```
> Proceed? (yes/no/edit)
---
## Context Budget
If context exceeds ~60% during implementation:
1. Finish the current task
2. Commit completed work so far
3. Report progress and remaining tasks
4. Suggest: "Run `/kn-go specs/<name>` again to continue remaining tasks."
The skill will detect already-done tasks and skip them on re-run.
---
## Re-run Behavior
When invoked on a spec that already has tasks:
1. List existing tasks linked to the spec
2. Filter to `todo` and `in-progress` only
3. Skip `done` tasks
4. Continue from where it left off
```json
mcp__knowns__list_tasks({ "spec": "specs/<name>" })
```
---
## Error Handling
- **Build/test fails during a task:** Fix the error, re-run tests. If unfixable, mark task as `blocked`, append notes, continue to next task.
- **Spec has conflicting requirements:** STOP and ask user to clarify.
- **Task depends on blocked task:** Skip and report at the end.
---
## Shared Output Contract
Required order for the final user-facing response:
1. Goal/result — state what was completed across the full pipeline run.
2. Key details — tasks completed, tasks blocked, SDD coverage, build/test status.
3. Next action — commit confirmation, or remaining work if interrupted.
For `kn-go`, the key details should cover:
- total tasks created and completed
- any blocked or skipped tasks
- SDD coverage percentage
- build/test/lint status
- commit proposal
---
## Dry Run Mode
With `--dry-run`:
- Phase 1: validate spec ✓
- Phase 2: generate task preview (don't create) ✓
- Phase 3-5: skip
Show what would be created and ask user to confirm before running for real.
---
## Checklist
- [ ] Spec is approved
- [ ] Spec validated (no broken refs)
- [ ] Tasks generated with fulfills mapping
- [ ] Each task: planned → implemented → ACs checked → validated → done
- [ ] SDD verification passed
- [ ] Build/test/lint passed
- [ ] User approved commit
- [ ] Commit created
## Red Flags
- Running on a draft spec
- Skipping task validation between tasks
- Not checking ACs before marking done
- Committing without user approval
- Ignoring build/test failures
- Not reporting progress between tasks
- Continuing past context budget limit without checkpointing