Skip to content
Agentmart
Submit a tool

spec-driven-development

Create a concise spec before implementation.

Skill by teknologist

IndexedMIT
Write a review

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/teknologist-spec-driven-development

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Create a concise spec before implementation. Use when starting new features, unclear requirements, or /addy-define.

Reviews

Write a review

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.

Tools
No tools found
Secrets
None asked for
Install scripts
None found

Network hosts it talks to 1

  • codeload.github.com · found in install command

Files it touches

  • ~/.claude/skills/spec-driven-development

What's inside

Skill name
spec-driven-development
Description
Create a concise spec before implementation. Use when starting new features, unclear requirements, or /addy-define.
License
MIT
Instructions
16 lines in SKILL.md · view on GitHub

Files (1)

  • SKILL.md

SKILL.md (first lines)

# Spec-Driven Development

Before code:

1. Clarify objective, users, constraints, acceptance criteria.
2. Identify non-goals and risky assumptions.
3. For ambiguous, risky, domain-heavy, or architecture-sensitive specs, use `grill-with-docs` before finalizing the spec to challenge the idea against existing domain language, `CONTEXT.md`/`CONTEXT-MAP.md`, and documented decisions. Skip it for trivial specs where ordinary clarification is enough.
4. Discover relevant Architecture Decision Records (ADRs): user-mentioned or doc-linked ADRs first, then bounded ADR directories such as `docs/adr/`, `docs/adrs/`, `decisions/`, or `docs/decisions/` when titles, filenames, or summaries match the requested work.
5. Add a concise `Related ADRs / Architecture constraints` section that links relevant ADR paths and says “Before implementation, read ...”. Capture ADR conflicts as open questions or boundaries; do not rewrite or override ADR decisions without a superseding ADR or explicit human architecture decision.
6. Define exact verification commands or checks.
7. Save durable spec only when useful or requested.
8. Get user approval before implementation.

Keep specs concise and agent-verifiable.

From teknologist/pi-addy-workflow, MIT.

More from teknologist/pi-addy-workflow

Signals

Stars
0
Forks
0
Open issues
0
Last commit (this folder)
May 27, 2026 (5 months ago)

From GitHub (fetched Oct 24, 2026).

Details

License
MIT
Repository
github.com/teknologist/pi-addy-workflow
First seen
Oct 24, 2026
Last checked
Oct 24, 2026
Source
GitHubgithub-graphql

More from teknologist

Cite this page

spec-driven-development skill. Agent Mart. https://agentmart.dev/skills/teknologist-spec-driven-development (last updated 2026-10-24)