$ recombobulate _
home / tips / pipe-a-spec-or-requirements-doc-into-claude-with-stdin-so-it-builds-exactly-what-was-designed
0

Pipe a Spec or Requirements Doc into Claude with stdin So It Builds Exactly What Was Designed

recombobulate @recombobulate · Mar 30, 2026 · Workflows
pipe-a-spec-or-requirements-doc-into-claude-with-stdin-so-it-builds-exactly-what-was-designed

Complex features usually start with a document — a product requirements doc, a technical design, or a detailed ticket. Instead of summarizing it in your prompt, feed the whole thing to Claude and let it work from the source of truth.

# Pipe a spec file as context for a task
cat docs/notification-system-spec.md | claude -p "implement this spec"

# Or reference the file directly in an interactive session
> read docs/notification-system-spec.md and implement everything
> it describes, following the architecture it outlines

Claude reads the entire document — acceptance criteria, edge cases, data models, API contracts — and implements the feature systematically, checking off requirements as it goes.

This is especially powerful for specs that are too detailed to retype:

# Feed a Jira export or project brief
cat requirements/user-permissions-redesign.md | claude -p \
  "implement this redesign — start with the database changes, \
   then the backend logic, then update the UI"

# Use a technical design doc as the blueprint
cat design/event-sourcing-migration.md | claude -p \
  "follow this design document step by step"

Claude treats the document as the authoritative spec, so it catches requirements you might forget to mention verbally — the edge case buried in paragraph four, the constraint noted in the data model section, or the non-functional requirement about response times.

You can also combine a spec with constraints:

> read the spec in docs/search-feature.md and implement it,
> but use Meilisearch instead of Elasticsearch — the spec
> was written before we changed the search engine

For long specs, ask Claude to summarize what it understood first:

> read docs/billing-overhaul.md and tell me your understanding
> of what needs to be built before you start coding

This lets you verify Claude interpreted the spec correctly before it writes any code.

A spec is the most precise prompt you can write — it's already done. Just feed it to Claude and let it build what was designed.

via Claude Code

~/recombobulate $ tip --comments --count=0

Log in to leave a comment.

~/recombobulate $ tip --related --limit=3
0
Run Claude Code in GitHub Actions to Automatically Review Every Pull Request

Set up Claude Code as an automated reviewer in your CI pipeline — on every pull request, it reads the diff, checks for bugs, security issues, missing tests, and convention violations, then posts its findings as a PR comment. Your human reviewers get a head start because the obvious issues are already flagged before they look.

recombobulate @recombobulate · 1 day ago
0
Ask Claude to Build a Deployment Checklist from Your Actual Infrastructure

Before deploying, tell Claude to read your project — migrations, environment variables, queue workers, scheduled tasks, caching, third-party integrations — and generate a deployment checklist that's specific to your app. Not a generic "did you run migrations?" list, but one that knows YOUR infrastructure and catches the things YOUR deploy can break.

recombobulate @recombobulate · 1 day ago
0
Ask Claude to Generate a README from Your Actual Codebase — Not a Template

Instead of writing a README from memory or copying a template, tell Claude to read your project and generate one that's actually accurate — real setup instructions from your config, real architecture from your directory structure, real API examples from your routes, and real prerequisites from your dependency files.

recombobulate @recombobulate · 1 day ago