Skip to content

Updating some div stuff with specify #200

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 2, 2025
Merged

Updating some div stuff with specify #200

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
57e1cc7
📝[Enhancement]: Improve implementation and planning workflows with Gi…
MariusStorhaug Oct 2, 2025
c521f21
📝[Enhancement]: Add terminal command guidelines and requirement numbe…
MariusStorhaug Oct 2, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions .github/copilot-instructions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -26,4 +26,27 @@ PowerShell 7.4+ (GitHub Actions composite actions): Follow standard conventions
- 001-building-on-this: Added PowerShell 7.4+ (GitHub Actions composite actions) + PSModule/GitHub-Script@v1, PSModule/Install-PSModuleHelpers@v1

<!-- MANUAL ADDITIONS START -->

## Terminal Commands

When executing terminal commands (using `run_in_terminal` or similar tools):
- **ALWAYS** prefix shell commands with `pwsh` unless it's a GitHub MCP call
- This applies to all PowerShell scripts, git commands, and other shell operations
- Exception: GitHub MCP Server calls should use their native format without `pwsh` prefix

Examples:
```bash
# Correct - PowerShell script
pwsh -Command "& './.specify/scripts/powershell/setup-plan.ps1' -Json"

# Correct - Git command
pwsh -Command "git status"

# Correct - Any shell command
pwsh -Command "ls -Recurse"

# Exception - GitHub MCP calls (no pwsh prefix)
gh issue create --title "Feature" --body "Description"
```

<!-- MANUAL ADDITIONS END -->
26 changes: 26 additions & 0 deletions .github/instructions/md.instructions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -163,6 +163,32 @@ Using list when table is better:
- Feature C: Partial - Beta feature
```

## Requirement Number Formatting

When writing or referencing requirement numbers (NFR and FR) in documentation:
- **Always use bold formatting** for requirement numbers
- **Replace hyphens with non-breaking hyphens** (`&#8209;`) between letters and numbers
- This prevents line breaks within requirement numbers and ensures consistent formatting
- This applies to all specification documents, plans, and tables

Examples:
```markdown
# Correct formatting
**NFR&#8209;001**: The system must respond within 200ms
**FR&#8209;042**: User authentication shall support OAuth 2.0

# In tables
| ID | Description |
|----|-------------|
| **NFR&#8209;001** | Performance requirement |
| **FR&#8209;042** | Authentication feature |

# Incorrect formatting (do not use)
NFR-001: Without bold or non-breaking hyphen
**NFR-001**: Bold but with regular hyphen (can break across lines)
NFR&#8209;001: Non-breaking hyphen but not bold
```

## Emphasis

- Use `*` or `_` for emphasis (italic), `**` or `__` for strong emphasis (bold)
Expand Down
180 changes: 125 additions & 55 deletions .github/prompts/implement.prompt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,17 +16,35 @@ $ARGUMENTS

**Iteration Support**: This command supports iterative implementation - you can run it multiple times to complete remaining tasks, fix issues, or add refinements. Task completion state is tracked in tasks.md with [X] markers.

1. Run [`.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks`](../../.specify/scripts/powershell/check-prerequisites.ps1) from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
1. **Set Implementing label immediately**:
- **Determine target repository**:
- Check if `.fork-info.json` exists in the feature directory
- If it exists:
- Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty)
- Use `upstream_owner/upstream_repo` for all GitHub operations
- If it doesn't exist, use the current repository (origin)
- Get the issue number associated with the current feature branch
- **Add 'Implementing' label** to the issue and PR immediately in the target repository
- **Remove 'Planning' label** from the issue and PR

**GitHub Integration**: If GitHub tools are available, update labels automatically in the target repository. If not available, use:
```bash
# If fork: gh issue edit <issue-number> --repo <upstream_owner>/<upstream_repo> --remove-label "Planning" --add-label "Implementing"
# If local: gh issue edit <issue-number> --remove-label "Planning" --add-label "Implementing"
gh issue edit <issue-number> --remove-label "Planning" --add-label "Implementing"
```

2. Run [`.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks`](../../.specify/scripts/powershell/check-prerequisites.ps1) from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.

2. Load and analyze the implementation context:
3. Load and analyze the implementation context:
- **REQUIRED**: Read tasks.md for the complete task list and execution plan
- **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
- **IF EXISTS**: Read data-model.md for entities and relationships
- **IF EXISTS**: Read contracts/ for API specifications and test requirements
- **IF EXISTS**: Read research.md for technical decisions and constraints
- **IF EXISTS**: Read quickstart.md for integration scenarios

3. Parse tasks.md structure and extract:
4. Parse tasks.md structure and extract:
- **Detect iteration state**: Check task completion markers
- Tasks marked [X] are complete - skip unless user requests changes
- Tasks marked [ ] are pending - these need implementation
Expand All @@ -36,7 +54,7 @@ $ARGUMENTS
- **Task details**: ID, description, file paths, parallel markers [P]
- **Execution flow**: Order and dependency requirements

4. Execute implementation following the task plan:
5. Execute implementation following the task plan:
- **Skip completed tasks**: Don't re-implement tasks marked [X] unless explicitly requested
- **Resume from last incomplete task**: Start with first [ ] task found
- **Phase-by-phase execution**: Complete each phase before moving to the next
Expand All @@ -45,29 +63,68 @@ $ARGUMENTS
- **File-based coordination**: Tasks affecting the same files must run sequentially
- **Validation checkpoints**: Verify each phase completion before proceeding

5. Implementation execution rules:
6. Implementation execution rules:
- **Setup first**: Initialize project structure, dependencies, and configuration
- **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
- **Core development**: Implement models, services, CLI commands, and endpoints
- **Integration work**: Database connections, middleware, logging, and external services
- **Polish and validation**: Unit tests, performance optimization, and documentation

6. Progress tracking and error handling:
7. Progress tracking and error handling:
- Report progress after each completed task
- Halt execution if any non-parallel task fails
- For parallel tasks [P], continue with successful tasks and report failed ones
- Provide clear error messages with context for debugging
- Suggest next steps if implementation cannot proceed
- **IMPORTANT**: For completed tasks, make sure to mark the task as [X] in the tasks file.

7. Completion validation:
8. Completion validation:
- Verify all required tasks are completed
- Check that implemented features match the original specification
- Validate that tests pass and coverage meets requirements
- Confirm the implementation follows the technical plan
- Report final status with summary of completed work

8. Create or update Pull Request:
9. Update the constitution:
- Read the [Constitution](../../.specify/memory/constitution.md) file.
- Read the [constitution prompt](./constitution.prompt.md) for guidance on how to update the constitution.
- Update the constitution file with details on what has been implemented in this PR
- Document the functionality that was added or changed, remove the sections that are no longer relevant
- Ensure the constitution reflects the current state of the codebase

10. Update the CHANGELOG:
- **Locate or create CHANGELOG.md** in the repository root
- **Add a new entry** for this feature/change following the Keep a Changelog format
- **Structure the entry** with:
* Version header (use `[Unreleased]` if version isn't determined yet)
* Date (current date)
* Category sections as applicable:
- `### Added` - for new features
- `### Changed` - for changes in existing functionality
- `### Deprecated` - for soon-to-be removed features
- `### Removed` - for now removed features
- `### Fixed` - for any bug fixes
- `### Security` - for vulnerability fixes
* Write entries from the user's perspective, focusing on what changed and why it matters
* Include brief usage examples where helpful
* Link to the PR or issue: `[#<issue-number>]`
- **Keep it concise**: Focus on user-impacting changes, not internal refactoring details

11. Final commit and push:
- **Stage all implemented changes** including:
* All source code files created or modified
* Updated tasks.md with completed task markers [X]
* Updated CHANGELOG.md
* Updated constitution.md
* Any configuration or documentation files
- **Create a descriptive commit message**:
* Use conventional commit format: `<type>(<scope>): <description>`
* Types: feat, fix, docs, refactor, test, chore
* Include reference to issue: `Fixes #<issue-number>`
- **Push the branch** to remote
- Verify the push completed successfully

12. Update PR description with release notes:
- **Determine workflow mode and target repository**:
- Check if `.fork-info.json` exists in the feature directory (same directory as spec.md)
- **If exists** (fork mode):
Expand Down Expand Up @@ -95,58 +152,71 @@ $ARGUMENTS
| Breaking change | 🌟 | Major |

- Fallback PR title format (if issue title unavailable): `<Icon> [Type of change]: <Short description>`
- **PR description structure** (formatted as a release note):
* Start with a user-focused summary paragraph describing what's new, improved, or fixed
* Write in past tense, focusing on capabilities and user benefits (e.g., "Added support for...", "Improved performance of...", "Fixed issue where...")
* DO NOT add a title or heading before the leading paragraph
* Keep the tone professional and concise - this will be read as a release note
* At the end of the summary paragraph, add "- Fixes #<issue-number>" to link the PR to the issue
* Follow with additional release-note style details:
- **What's Changed**: Brief bullet points of key changes from the user's perspective
- **Technical Details** (optional): Implementation notes if relevant for maintainers
- **Breaking Changes** (if applicable): Clear warning and migration guidance
- **Usage** (if applicable): Brief example or updated command syntax
* Avoid superfluous headers, verbose explanations, or internal implementation details
* Focus on what changes for the end user or developer using this code
- **Write PR description as a release note**:
* **Opening summary** (1-2 paragraphs):
- Start with what was accomplished in user-focused language
- Write in past tense: "Added...", "Improved...", "Fixed..."
- Focus on the "why" - what problem does this solve or what capability does it enable?
- Mention the user impact - who benefits and how?
- At the end, add: "Fixes #<issue-number>"
* **What's Changed** section:
- 3-5 bullet points highlighting key changes from the user's perspective
- Focus on capabilities, not implementation details
- Example: "✨ Added support for custom templates" not "Created new Template class"
* **Usage** section (if applicable):
- Brief example showing how to use the new functionality
- Keep it minimal - just enough to get started
- Use code blocks for commands or code snippets
* **Breaking Changes** section (if applicable):
- Clear warning about what breaks
- Migration guidance for users
- What they need to change in their code
* **Technical Notes** section (optional, for maintainers):
- Brief implementation notes if relevant for reviewers
- Dependencies added or updated
- Architecture decisions
* **Tone and style**:
- Professional and concise
- Avoid jargon and internal terminology
- Write for the end user, not just developers
- This description will be used in release notes
- **Apply appropriate label(s)** based on the type of change
- **Link the PR** to the associated issue
- **After PR updates**: Update `.fork-info.json` (if it exists) with the latest PR number (if not already present)
- **Update `.fork-info.json`** (if it exists) with the latest PR number (if not already present)

**GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to update the PR status and labels automatically in the target repository. If not available, provide these fallback commands with the correct repository:
```bash
# Mark PR as ready for review
# If fork: gh pr ready <PR-number> --repo <upstream_owner>/<upstream_repo>
# If local: gh pr ready <PR-number>
gh pr ready <PR-number>

# Update PR title to match issue (if needed)
gh pr edit <PR-number> --title "<Issue title>"

# Update labels
gh pr edit <PR-number> --add-label "<Type>"
```

9. Update issue labels:
- **Determine target repository** (same logic as step 8):
- Check if `.fork-info.json` exists in the feature directory
- If it exists and validated, use `upstream_owner/upstream_repo`
- If it doesn't exist, use the current repository (origin)
- Remove 'plan' label from the linked issue in the target repository
- Add 'implement' label to the linked issue
- **After updating labels**: Ensure `.fork-info.json` (if it exists) has the issue number stored

**GitHub Integration**: If GitHub tools are available, update labels automatically in the target repository. If not available, use:
**GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to update the PR description in the target repository. If not available, provide this fallback command:
```bash
# If fork: gh issue edit <issue-number> --repo <upstream_owner>/<upstream_repo> ...
# If local: gh issue edit <issue-number> ...
gh issue edit <issue-number> --remove-label "Plan" --add-label "Implementation"
# Update PR description
# If fork: gh pr edit <PR-number> --repo <upstream_owner>/<upstream_repo> --body "<release-note-description>"
# If local: gh pr edit <PR-number> --body "<release-note-description>"
gh pr edit <PR-number> --body "<release-note-description>"
```

10. Update the constitution:
- Read the [Constitution](../../.specify/memory/constitution.md) file.
- Read the [constitution prompt](./constitution.prompt.md) for guidance on how to update the constitution.
- Update the constitution file with details on what has been implemented in this PR
- Document the functionality that was added or changed, remove the sections that are no longer relevant
- Ensure the constitution reflects the current state of the codebase
13. Mark PR as ready for review:
- **Determine target repository** (same logic as step 12):
- Check if `.fork-info.json` exists in the feature directory
- If it exists and validated, use `upstream_owner/upstream_repo`
- If it doesn't exist, use the current repository (origin)
- **Remove 'Implementing' label** from the linked issue and the PR in the target repository
- **Mark PR as ready for review** (no longer draft)
- **After updates**: Ensure `.fork-info.json` (if it exists) has both issue and PR numbers stored

**GitHub Integration**: If GitHub tools are available, update labels and PR status automatically in the target repository. If not available, use:
```bash
# Mark PR as ready for review
# If fork: gh pr ready <PR-number> --repo <upstream_owner>/<upstream_repo>
# If local: gh pr ready <PR-number>
gh pr ready <PR-number>

# Remove Implementing label from issue
# If fork: gh issue edit <issue-number> --repo <upstream_owner>/<upstream_repo> --remove-label "Implementing"
# If local: gh issue edit <issue-number> --remove-label "Implementing"
gh issue edit <issue-number> --remove-label "Implementing"

# Remove Implementing label from PR
# If fork: gh pr edit <PR-number> --repo <upstream_owner>/<upstream_repo> --remove-label "Implementing"
# If local: gh pr edit <PR-number> --remove-label "Implementing"
gh pr edit <PR-number> --remove-label "Implementing"
```

Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/tasks` first to regenerate the task list.
Loading
Loading