Compare commits

..

7 Commits

Author SHA1 Message Date
Den Delimarsky
54c7f9c19b Merge pull request #4 from lucasmodrich/fix-typo
doco(spec-driven): Fix small typo in spec-driven.md
2025-09-02 21:03:51 -07:00
Lucas Modrich
81fea96e42 doco(spec-driven): Fix small typo in document 2025-09-03 10:58:10 +10:00
Den Delimarsky
b5b02b3961 Merge pull request #3 from github/update-readme-contributors
Update README.md
2025-08-25 14:10:32 -07:00
Den Delimarsky 🌺
c3ff114c5f Update README.md 2025-08-25 14:09:38 -07:00
Den Delimarsky
5ee736b677 Merge pull request #2 from github/update-readme-contributors
Fix release workflow to work with repository rules
2025-08-25 14:09:19 -07:00
Den Delimarsky
704e272a00 Update .github/workflows/release.yml
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-08-25 14:09:09 -07:00
Den Delimarsky 🌺
f755bcfb43 Fix release workflow to work with repository rules
- Remove problematic direct push to main branch
- Keep version updates only for release artifacts
- Add pull-requests permission for future flexibility
- Releases/tags created via API don't require branch pushes
2025-08-25 14:07:30 -07:00
3 changed files with 8 additions and 18 deletions

View File

@@ -11,6 +11,7 @@ jobs:
permissions:
contents: write
pull-requests: write
steps:
- name: Checkout repository
@@ -204,7 +205,7 @@ jobs:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Update version in pyproject.toml
- name: Update version in pyproject.toml (for release artifacts only)
if: steps.check_release.outputs.exists == 'false'
run: |
# Update version in pyproject.toml (remove 'v' prefix for Python versioning)
@@ -213,19 +214,8 @@ jobs:
if [ -f "pyproject.toml" ]; then
sed -i "s/version = \".*\"/version = \"$PYTHON_VERSION\"/" pyproject.toml
echo "Updated pyproject.toml version to $PYTHON_VERSION"
echo "Updated pyproject.toml version to $PYTHON_VERSION (for release artifacts only)"
fi
- name: Commit version update
if: steps.check_release.outputs.exists == 'false'
run: |
git config --local user.email "action@github.com"
git config --local user.name "GitHub Action"
if git diff --quiet; then
echo "No changes to commit"
else
git add pyproject.toml
git commit -m "chore: bump version to ${{ steps.get_tag.outputs.new_version }}"
git push
fi
# Note: No longer committing version changes back to main branch
# The version is only updated in the release artifacts

View File

@@ -2,14 +2,14 @@
<img src="./media/logo_small.webp"/>
<h1>🌱 Spec Kit</h1>
<h3><em>Build high-quality software faster.</em></h3>
[![Release](https://github.com/github/spec-kit/actions/workflows/release.yml/badge.svg)](https://github.com/github/spec-kit/actions/workflows/release.yml)
</div>
<p align="center">
<strong>An effort to allow organizations to focus on product scenarios rather than writing undifferentiated code with the help of Spec-Driven Development.</strong>
</p>
[![Release](https://github.com/github/spec-kit/actions/workflows/release.yml/badge.svg)](https://github.com/github/spec-kit/actions/workflows/release.yml)
---
## Table of Contents

View File

@@ -2,7 +2,7 @@
## The Power Inversion
For decades, code has been king. Specifications served code—they were the scaffolding we built and then discarded once the "real work" of coding began. We wrote PRDs to guide development, created design docs to inform implementation, drew diagrams to visualize architecture. But these were always subordinate to the code itself. Code was truth. Everything else was, at best, good intentions. Code was the source of truth, as it mvoed forward, and spec's rarely kept pace. As the asset (code) and the implementation are one, it's not easy to have a parallel implementation without trying to build from the code.
For decades, code has been king. Specifications served code—they were the scaffolding we built and then discarded once the "real work" of coding began. We wrote PRDs to guide development, created design docs to inform implementation, drew diagrams to visualize architecture. But these were always subordinate to the code itself. Code was truth. Everything else was, at best, good intentions. Code was the source of truth, as it moved forward, and spec's rarely kept pace. As the asset (code) and the implementation are one, it's not easy to have a parallel implementation without trying to build from the code.
Spec-Driven Development (SDD) inverts this power structure. Specifications don't serve code—code serves specifications. The (Product Requirements Document-Specification) PRD isn't a guide for implementation; it's the source that generates implementation. Technical plans aren't documents that inform coding; they're precise definitions that produce code. This isn't an incremental improvement to how we build software. It's a fundamental rethinking of what drives development.