Contact Spec Coding

What this page is for

Use this page when you have a specific issue, question, or collaboration idea related to Spec Coding. The most useful messages include enough context to reproduce the problem or evaluate the request.

• Content corrections: factual errors, unclear examples, outdated guidance, or missing caveats in articles and templates.
• Site issues: broken links, missing downloads, copy buttons that fail, layout problems, or search results that point to the wrong page.
• Tool feedback: generator output that is hard to use, Markdown formatting problems, missing fields, or confusing form labels.
• Partnership inquiries: editorial collaborations, resource exchanges, or practical spec-first development case studies.

Email

You can reach us directly at [email protected]. For faster routing, use the form below and select the appropriate issue type.

How to send a useful correction

If you are reporting a content issue, include the page URL, the exact section or sentence, what appears to be wrong, and a source or short explanation when possible. For templates and tools, include the input you used and the output you expected.

Good reports are concrete: "the API template says retries are safe, but this example lacks an idempotency key" is easier to act on than "the API article is confusing." Screenshots are helpful for layout problems, but the related URL is still the most important detail.

Send a Message

What to Expect

• Content corrections — verified errors are fixed within 5 business days and the article's dateModified is updated.
• Broken links — usually fixed within 2 business days.
• Tool bugs — reproducible issues are triaged by impact; generator bugs that corrupt output are handled before cosmetic requests.
• Partnership inquiries — reviewed within one week; not all inquiries result in a collaboration.
• Suggestions — read and considered; topic suggestions that fit the editorial scope may appear in future articles.

Editorial Scope

Spec Coding focuses on spec-first development, reusable templates, software planning, API and database contracts, acceptance criteria, and practical AI-assisted delivery workflows. We do not provide project-specific legal, security, hiring, or investment advice through this contact form.

Messages may be used to improve public content, but private details, email addresses, and unpublished project information are not published without permission. If a report leads to a meaningful correction, the page will be updated with a new modification date.

What Not to Send

Please do not paste access tokens, private customer records, proprietary source code, unpublished incident details, or documents covered by confidentiality obligations into the form. If a correction requires sensitive context, describe the issue at a high level first and we can agree on a safer way to discuss it.

For urgent production incidents, use your own incident response process. Spec Coding can improve templates and public guidance, but it is not an emergency support channel for live systems.

If you are reporting a generator issue, remove secrets from the sample input and keep only the structure needed to reproduce the formatting or validation problem.

We may ask follow-up questions when a report is unclear, especially for localization, accessibility, or browser-specific layout issues.

The most useful reports include the page URL, expected behavior, observed behavior, browser or device details when relevant, and a short note on whether the issue blocks your workflow or is only confusing.

If the issue affects a public page, include whether it appears on desktop, mobile, or both. If it affects generated output, include the smallest input that reproduces the problem.

Reports that include a reproducible path are usually handled faster than broad requests because they can be verified against the same page, browser, and expected result.

For content suggestions, tell us which reader task the new material would improve.

Contact FAQ

Can I request a new template or guide?

Yes. The best requests name the workflow, the audience, and the failure mode the resource should prevent. For example, "a rollback checklist for database migrations" is easier to evaluate than "more DevOps content."

Do you review private specs?

Not through this public contact form. If you want to discuss a private document, send a short description first and avoid including credentials, customer data, proprietary code, or confidential project details.

What Happens After You Send Feedback

Content corrections are checked against the page context, any linked source, and the practical workflow the page is trying to support. Tool reports are reproduced with the smallest possible input so the fix can be tested without depending on private project data. If a report leads to a material change, the affected page is updated and the visible update date is adjusted.

Feature requests are grouped by reader task. A request is more likely to become a new guide or template when it describes a recurring delivery failure, a missing review artifact, or a practical gap between planning and implementation.

What We Prioritize

Corrections that affect implementation decisions, API compatibility, database safety, privacy handling, or reader trust are reviewed first. A small factual error in a template can matter more than a broad topic suggestion because teams may copy that structure directly into production planning.

When reporting an issue, the most helpful detail is the decision the page caused you to question: unclear scope, missing failure path, outdated tool behavior, broken download, inaccurate translation, or a link that no longer points to the source it claims.