Compare commits
15 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
23c6bf1b71 | ||
|
|
36fbb85c65 | ||
|
|
f077e90a24 | ||
|
|
f88f6c8c05 | ||
|
|
b4833cb7ea | ||
|
|
2fc7ebeebe | ||
|
|
b4b31f167c | ||
|
|
f3fb55d183 | ||
|
|
54c7f9c19b | ||
|
|
81fea96e42 | ||
|
|
b5b02b3961 | ||
|
|
c3ff114c5f | ||
|
|
5ee736b677 | ||
|
|
704e272a00 | ||
|
|
f755bcfb43 |
20
.github/workflows/release.yml
vendored
20
.github/workflows/release.yml
vendored
@@ -11,6 +11,7 @@ jobs:
|
|||||||
|
|
||||||
permissions:
|
permissions:
|
||||||
contents: write
|
contents: write
|
||||||
|
pull-requests: write
|
||||||
|
|
||||||
steps:
|
steps:
|
||||||
- name: Checkout repository
|
- name: Checkout repository
|
||||||
@@ -204,7 +205,7 @@ jobs:
|
|||||||
env:
|
env:
|
||||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
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'
|
if: steps.check_release.outputs.exists == 'false'
|
||||||
run: |
|
run: |
|
||||||
# Update version in pyproject.toml (remove 'v' prefix for Python versioning)
|
# Update version in pyproject.toml (remove 'v' prefix for Python versioning)
|
||||||
@@ -213,19 +214,8 @@ jobs:
|
|||||||
|
|
||||||
if [ -f "pyproject.toml" ]; then
|
if [ -f "pyproject.toml" ]; then
|
||||||
sed -i "s/version = \".*\"/version = \"$PYTHON_VERSION\"/" pyproject.toml
|
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
|
fi
|
||||||
|
|
||||||
- name: Commit version update
|
# Note: No longer committing version changes back to main branch
|
||||||
if: steps.check_release.outputs.exists == 'false'
|
# The version is only updated in the release artifacts
|
||||||
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
|
|
||||||
|
|||||||
@@ -2,14 +2,14 @@
|
|||||||
<img src="./media/logo_small.webp"/>
|
<img src="./media/logo_small.webp"/>
|
||||||
<h1>🌱 Spec Kit</h1>
|
<h1>🌱 Spec Kit</h1>
|
||||||
<h3><em>Build high-quality software faster.</em></h3>
|
<h3><em>Build high-quality software faster.</em></h3>
|
||||||
|
|
||||||
[](https://github.com/github/spec-kit/actions/workflows/release.yml)
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<p align="center">
|
<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>
|
<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>
|
</p>
|
||||||
|
|
||||||
|
[](https://github.com/github/spec-kit/actions/workflows/release.yml)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Table of Contents
|
## Table of Contents
|
||||||
@@ -207,7 +207,7 @@ At this stage, your project folder contents should resemble the following:
|
|||||||
│ ├── setup-plan.sh
|
│ ├── setup-plan.sh
|
||||||
│ └── update-claude-md.sh
|
│ └── update-claude-md.sh
|
||||||
├── specs
|
├── specs
|
||||||
│ └── 002-create-taskify
|
│ └── 001-create-taskify
|
||||||
│ └── spec.md
|
│ └── spec.md
|
||||||
└── templates
|
└── templates
|
||||||
├── CLAUDE-template.md
|
├── CLAUDE-template.md
|
||||||
@@ -260,7 +260,7 @@ The output of this step will include a number of implementation detail documents
|
|||||||
│ ├── setup-plan.sh
|
│ ├── setup-plan.sh
|
||||||
│ └── update-claude-md.sh
|
│ └── update-claude-md.sh
|
||||||
├── specs
|
├── specs
|
||||||
│ └── 002-create-taskify
|
│ └── 001-create-taskify
|
||||||
│ ├── contracts
|
│ ├── contracts
|
||||||
│ │ ├── api-spec.json
|
│ │ ├── api-spec.json
|
||||||
│ │ └── signalr-spec.md
|
│ │ └── signalr-spec.md
|
||||||
|
|||||||
0
scripts/check-task-prerequisites.sh
Normal file → Executable file
0
scripts/check-task-prerequisites.sh
Normal file → Executable file
0
scripts/common.sh
Normal file → Executable file
0
scripts/common.sh
Normal file → Executable file
0
scripts/create-new-feature.sh
Normal file → Executable file
0
scripts/create-new-feature.sh
Normal file → Executable file
0
scripts/get-feature-paths.sh
Normal file → Executable file
0
scripts/get-feature-paths.sh
Normal file → Executable file
0
scripts/setup-plan.sh
Normal file → Executable file
0
scripts/setup-plan.sh
Normal file → Executable file
0
scripts/update-agent-context.sh
Normal file → Executable file
0
scripts/update-agent-context.sh
Normal file → Executable file
@@ -2,7 +2,7 @@
|
|||||||
|
|
||||||
## The Power Inversion
|
## 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.
|
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.
|
||||||
|
|
||||||
@@ -256,7 +256,7 @@ The constitution defines nine articles that shape every aspect of the developmen
|
|||||||
#### Article I: Library-First Principle
|
#### Article I: Library-First Principle
|
||||||
Every feature must begin as a standalone library—no exceptions. This forces modular design from the start:
|
Every feature must begin as a standalone library—no exceptions. This forces modular design from the start:
|
||||||
```
|
```
|
||||||
Every feature in Specify2 MUST begin its existence as a standalone library.
|
Every feature in Specify MUST begin its existence as a standalone library.
|
||||||
No feature shall be implemented directly within application code without
|
No feature shall be implemented directly within application code without
|
||||||
first being abstracted into a reusable library component.
|
first being abstracted into a reusable library component.
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -813,12 +813,12 @@ def init(
|
|||||||
if selected_ai == "claude":
|
if selected_ai == "claude":
|
||||||
steps_lines.append(f"{step_num}. Open in Visual Studio Code and start using / commands with Claude Code")
|
steps_lines.append(f"{step_num}. Open in Visual Studio Code and start using / commands with Claude Code")
|
||||||
steps_lines.append(" - Type / in any file to see available commands")
|
steps_lines.append(" - Type / in any file to see available commands")
|
||||||
steps_lines.append(" - Use /spec to create specifications")
|
steps_lines.append(" - Use /specify to create specifications")
|
||||||
steps_lines.append(" - Use /plan to create implementation plans")
|
steps_lines.append(" - Use /plan to create implementation plans")
|
||||||
steps_lines.append(" - Use /tasks to generate tasks")
|
steps_lines.append(" - Use /tasks to generate tasks")
|
||||||
elif selected_ai == "gemini":
|
elif selected_ai == "gemini":
|
||||||
steps_lines.append(f"{step_num}. Use / commands with Gemini CLI")
|
steps_lines.append(f"{step_num}. Use / commands with Gemini CLI")
|
||||||
steps_lines.append(" - Run gemini /spec to create specifications")
|
steps_lines.append(" - Run gemini /specify to create specifications")
|
||||||
steps_lines.append(" - Run gemini /plan to create implementation plans")
|
steps_lines.append(" - Run gemini /plan to create implementation plans")
|
||||||
steps_lines.append(" - See GEMINI.md for all available commands")
|
steps_lines.append(" - See GEMINI.md for all available commands")
|
||||||
elif selected_ai == "copilot":
|
elif selected_ai == "copilot":
|
||||||
@@ -868,4 +868,4 @@ def main():
|
|||||||
|
|
||||||
|
|
||||||
if __name__ == "__main__":
|
if __name__ == "__main__":
|
||||||
main()
|
main()
|
||||||
|
|||||||
Reference in New Issue
Block a user