Tytarenko AI Agency

Q: Does Spec Kit integrate with GitHub Issues?

Yes — current versions ship /speckit.taskstoissues, which converts generated task lists into GitHub Issues. My reason for not adopting it wasn't a missing feature; it was that my board conventions and executor daemon already occupy that role, and running both would duplicate state.

I watched a conference talk demoing GitHub Spec Kit: the presenter built a todo app in about 40 minutes through the /specify → /plan → /tasks → /implement pipeline. Instead of installing the framework, I audited spec-driven development (SDD) against the agent stack I already run — a grilling-interview skill, an autonomous-build skill, and GitHub Issues as agent memory. I split SDD into three ideas worth stealing and three I skipped, and shipped the adoption in the same session as the analysis: one commit, 5 files changed, 126 insertions.

What exactly I audited. This article reflects Spec Kit as of July 2026 — v0.12.11 (released July 10, 2026), a ~120k-star repository with 30+ supported coding-agent integrations, extensions, and presets. Where I describe a specific workflow, I distinguish between what the official toolkit does and what the conference presenter demonstrated on top of it. My conclusion is a fit judgment for my own stack, not a verdict on Spec Kit.

What Spec Kit Actually Is Today

Spec Kit makes the specification the center of the engineering process. From a high-level prompt it generates a detailed spec, a technical plan, a task breakdown, and then the implementation — each step producing a markdown artifact in a specs/NNN-slug/ folder that lives in your repository.

The current toolkit is more flexible than its critics (including my first draft of this article) tend to assume. It ships a /speckit.taskstoissues command that converts generated task lists into GitHub Issues for tracking. It supports 30+ coding agents — Copilot, Claude, Gemini, Codex, and others — with a generic integration for the rest. And its default workflow can be customized or replaced through extensions and presets.

A flowchart depicting the Spec Kit pipeline, highlighting the core steps involved in spec-driven development.

The problem SDD attacks is real. The presenter named it precisely: the "curse of knowledge." When you formulate a task, you skip what feels obvious to you, the agent fills the gaps with plausible inventions, and the reasoning behind every decision dies in a chat window nobody can find a month later.

Why I Still Didn't Install It

My reasons are about overlap, not about Spec Kit being bad.

My stack already covers most of what the default Spec Kit pipeline provides:

A grilling-interview skill that stress-tests a plan with structured questions until intent is explicit — this is my cure for the curse of knowledge.

An autonomous-build skill that plans and executes large multi-phase work on its own.

GitHub Issues as agent memory, aggregated on a project board with custom routing fields that my executor daemon reads to claim work.

Adopting Spec Kit would mean either running two sources of task state — its artifacts plus my board — or migrating my board conventions into its workflow. That is a process-migration cost, not vendor lock-in: the toolkit itself is agent-agnostic. But for a stack that already works, the cost buys little.

The honest summary: Spec Kit's default workflow carries more ceremony than my existing stack needs. If you are starting from zero, the calculus is different — the framework hands you a complete discipline on day one.

Three Ideas I Stole

1. Hybrid In-Repo Specs

Large features now get a specs/NNN-slug/spec.md committed next to the code, while the GitHub issue stays the state tracker on the board.

This solves a failure mode I actually have. My executors run headless in containers, and a container dies with its chat context. The PR description records deviations from the task — but never the original intent. A spec committed in the repo survives the container, the chat, and the issue's closure, and the next agent working nearby can read it.

A visual representation of a GitHub repository showcasing the organization of specs within the repository.

The hybrid part matters: small tasks stay issue-only. Specs are read on demand, never inherited into every agent run — and my context-pruning guard now protects specs/ from cleanup, with a regression test.

2. A Task Router

The second steal is the presenter's own addition, not a Spec Kit feature: a single entry point that decides which process a task deserves. My version classifies raw work into four routes:

Trivial fix — just do it, no artifacts.

Plain issue — scope is clear; create the issue as usual.

Interview, then spec — open design questions; run the grilling interview, write specs/NNN-slug/spec.md, link it from the issue.

Autonomous build — a whole multi-phase project; hand off to the autonomous-build skill, which owns its own planning.

A diagram showing the classification process of tasks handled by the /task router skill.

A --fast flag drafts the spec without the interview and hands it to me for approval. The default stays interview-first: the curse of knowledge is cured by being asked questions, not by generating documents.

3. Executor-Authored plan.md

The spec captures intent; the plan captures approach. When an issue links to a spec, my executor's first phase is to write specs/NNN-slug/plan.md — stack choices, data model, key files — and commit it to the PR branch before implementing.

Code review's spec-fidelity axis gets an explicit artifact: the reviewer compares the diff against a stated plan instead of reverse-engineering intent from the code. The spec stays read-only for the executor; a conflict between spec and reality is an escalation, not a silent edit.

Three Things I Skipped

1. The Full Framework

Everything above fit into my existing skills. Installing Spec Kit as well would duplicate the interview, the build loop, and the board integration I already have — two systems tracking one truth. This is the fit judgment, restated: steal the ideas, skip the dependency when the ideas are all you need.

2. The Model-Split Session Pattern

The presenter recommended planning in one session on an expensive model, then implementing in a fresh context on a cheaper one. Worth noting: this is the presenter's workflow advice, not a Spec Kit feature.

I skipped it because my routing ladder already covers it — a cheap fast model does reconnaissance, a mid-tier model does bulk implementation, and the strongest model verifies. Adding a per-session split on top would be complexity without new benefit.

3. Specs for Everything

The default Spec Kit pipeline assumes a full specification flow even for work my router would classify as trivial. Presets and extensions can tune that, but the tuning is exactly what my router already does: the judgment call about which process a task deserves is the valuable part, and I wanted it in one place I control.

Case Study: Shipping the Adoption

Context: I run a solo AI agency on an autonomous agent fleet — a daemon on a Google Cloud VM that claims issues from a GitHub project board and runs headless coding-agent executors in task containers. The system is brownfield: interview, build, review, and memory conventions already existed.

What changed: one commit, 5 files, 126 insertions —

A new router skill implementing the four-route classification and the --fast flag.

Two paragraphs in the global agent instructions: the hybrid-spec convention, and the executor rule to commit plan.md to the PR branch before implementing.

A context-pruning guard update protecting specs/ from cleanup, with a regression test.

What I can honestly report: the adoption itself was cheap because every idea landed on existing infrastructure — the interview skill, the board, the PR review cycle were already there. What I have not yet measured is before/after lead time or token cost per task; those are initial observations, not benchmarks. The metric I will watch is how often review finds the diff drifting from plan.md.

A real failure mode this design answers: my executors previously recorded why we deviated in the PR but had nowhere durable to record what we originally intended. Every intent question after a container died meant archaeology across chat logs. The in-repo spec closes exactly that gap.

Practical Implementation Layer

Task Router — Simplified Conceptual Pseudo-Code

This is illustrative pseudo-code, not a runnable API:

// Conceptual sketch — the real router is a skill prompt, not JS.
function routeTask(rawWork) {
  if (isTrivialFix(rawWork))  return justDoIt(rawWork);
  if (isScopeClear(rawWork))  return createIssue(rawWork);
  if (isMultiPhaseBuild(rawWork)) return handOffToAutonomousBuild(rawWork);
  const spec = flags.fast
    ? draftSpecForApproval(rawWork)          // --fast: skip interview
    : interviewThenWriteSpec(rawWork);       // default: ask questions first
  return createIssueLinkingSpec(spec);       // board stays the state tracker
}// Executor side, first phase of a spec-linked task:
// write specs/NNN-slug/plan.md → commit to the PR branch → implement.

System Flow

Raw task → router (fix / issue / interview→spec / autonomous build) → spec committed to specs/NNN-slug/ → issue on the board → executor claims it, commits plan.md to the PR branch → implementation, with deviations recorded in the PR → review compares the diff against spec + plan → human merge gate.

Model routing runs underneath, not instead: cheap models read, mid-tier models implement, the strongest model verifies findings.

Rollout Plan

Add the router as the single entry point for new work; wire the --fast flag.

Adopt the specs/NNN-slug/spec.md convention and link specs from issues.

Add the executor rule: plan.md to the PR branch before implementation.

Protect specs/ in whatever context-pruning tooling you run, with a test.

Only then consider whether the full Spec Kit buys you anything on top.

Challenges & Constraints

Context cost: every token an agent inherits is paid on every run. Specs must be read on demand, never folded into always-loaded instructions.

Interview quality: weak answers produce weak specs; the interview needs a human who actually decides, which costs founder time.

Process discipline: the router only helps if it really is the single entry point; side doors recreate the old chaos.

Migration honesty: if you adopt Spec Kit wholesale later, its artifacts and my conventions would need reconciling — process migration cost cuts both ways.

Expectation setting: a spec reduces ambiguity; it does not eliminate review, deviations, or judgment.

Actionable Takeaways

Audit before adopting: list what an SDD framework provides and strike out what your stack already covers. Steal the rest.

Route by task weight: trivial fix, plain issue, interview-then-spec, autonomous build. The judgment call is the feature.

Commit intent to the repo: specs must survive the chat, the container, and the issue's closure.

Separate intent from approach: spec = founder's what and why (read-only for agents); plan = implementer's how (reviewed with the code).

Default to questions: generate specs from an interview, not from silence — --fast is the exception with an approval gate.

FAQ

Does Spec Kit integrate with GitHub Issues?

Yes — current versions ship /speckit.taskstoissues, which converts generated task lists into GitHub Issues. My reason for not adopting it wasn't a missing feature; it was that my board conventions and executor daemon already occupy that role, and running both would duplicate state.

Is adopting Spec Kit a vendor lock-in risk?

Not in the ecosystem sense: it supports 30+ coding agents and its process isn't tied to one vendor's models. The real cost is process migration — its artifacts and workflow become your team's habits, and unwinding habits is expensive. That cost applies to my homegrown conventions too.

What is the difference between spec-driven development and vibe coding?

SDD turns specifications from passive documentation into contracts the agent implements against, with acceptance criteria as the definition of done. Vibe coding relies on loose prompts; it works until the system grows past what one chat context can hold, then the missing intent becomes unpayable debt.

How do I handle the "curse of knowledge" with AI agents?

Get interviewed. The failure isn't that agents lack documents — it's that you never said the things that felt obvious. A structured interview extracts those; generated ceremony doesn't. That's why my router defaults to interview-first and makes --fast the exception.

Do specs slow down small fixes?

They would — which is why the router exists. Trivial fixes ship with no artifacts, clear-scope work gets a plain issue, and only large or ambiguous features pay the interview-plus-spec cost. Applying the full pipeline to everything is the failure mode, not the goal.