Skip to content

Commit c2e75b4

Browse files
ZzackllackZzackllack
committed
chore: Added specify for github copilot
1 parent 02698e2 commit c2e75b4

File tree

5 files changed

+254
-0
lines changed

5 files changed

+254
-0
lines changed

‎.github/prompts/constitution.prompt.md‎

Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
---
2+
description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
3+
---
4+
5+
The user input to you can be provided directly by the agent or in `$ARGUMENTS` - you **MUST** consider it before proceeding with the prompt (if not empty).
6+
7+
User input:
8+
9+
$ARGUMENTS
10+
11+
You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
12+
13+
Follow this execution flow:
14+
15+
1. Load the existing constitution template at `.specify/memory/constitution.md`.
16+
- Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
17+
**IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
18+
19+
2. Collect/derive values for placeholders:
20+
- If user input (conversation) supplies a value, use it.
21+
- Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
22+
- For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
23+
- `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
24+
* MAJOR: Backward incompatible governance/principle removals or redefinitions.
25+
* MINOR: New principle/section added or materially expanded guidance.
26+
* PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
27+
- If version bump type ambiguous, propose reasoning before finalizing.
28+
29+
3. Draft the updated constitution content:
30+
- Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
31+
- Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
32+
- Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
33+
- Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
34+
35+
4. Consistency propagation checklist (convert prior checklist into active validations):
36+
- Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
37+
- Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
38+
- Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
39+
- Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
40+
- Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
41+
42+
5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
43+
- Version change: old → new
44+
- List of modified principles (old title → new title if renamed)
45+
- Added sections
46+
- Removed sections
47+
- Templates requiring updates (✅ updated / ⚠ pending) with file paths
48+
- Follow-up TODOs if any placeholders intentionally deferred.
49+
50+
6. Validation before final output:
51+
- No remaining unexplained bracket tokens.
52+
- Version line matches report.
53+
- Dates ISO format YYYY-MM-DD.
54+
- Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
55+
56+
7. Write the completed constitution back to `.specify/memory/constitution.md` (overwrite).
57+
58+
8. Output a final summary to the user with:
59+
- New version and bump rationale.
60+
- Any files flagged for manual follow-up.
61+
- Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
62+
63+
Formatting & Style Requirements:
64+
- Use Markdown headings exactly as in the template (do not demote/promote levels).
65+
- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
66+
- Keep a single blank line between sections.
67+
- Avoid trailing whitespace.
68+
69+
If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
70+
71+
If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
72+
73+
Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.

‎.github/prompts/implement.prompt.md‎

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
---
2+
description: Execute the implementation plan by processing and executing all tasks defined in tasks.md
3+
---
4+
5+
The user input to you can be provided directly by the agent or in `$ARGUMENTS` - you **MUST** consider it before proceeding with the prompt (if not empty).
6+
7+
User input:
8+
9+
$ARGUMENTS
10+
11+
1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
12+
13+
2. Load and analyze the implementation context:
14+
- **REQUIRED**: Read tasks.md for the complete task list and execution plan
15+
- **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
16+
- **IF EXISTS**: Read data-model.md for entities and relationships
17+
- **IF EXISTS**: Read contracts/ for API specifications and test requirements
18+
- **IF EXISTS**: Read research.md for technical decisions and constraints
19+
- **IF EXISTS**: Read quickstart.md for integration scenarios
20+
21+
3. Parse tasks.md structure and extract:
22+
- **Task phases**: Setup, Tests, Core, Integration, Polish
23+
- **Task dependencies**: Sequential vs parallel execution rules
24+
- **Task details**: ID, description, file paths, parallel markers [P]
25+
- **Execution flow**: Order and dependency requirements
26+
27+
4. Execute implementation following the task plan:
28+
- **Phase-by-phase execution**: Complete each phase before moving to the next
29+
- **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together
30+
- **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
31+
- **File-based coordination**: Tasks affecting the same files must run sequentially
32+
- **Validation checkpoints**: Verify each phase completion before proceeding
33+
34+
5. Implementation execution rules:
35+
- **Setup first**: Initialize project structure, dependencies, configuration
36+
- **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
37+
- **Core development**: Implement models, services, CLI commands, endpoints
38+
- **Integration work**: Database connections, middleware, logging, external services
39+
- **Polish and validation**: Unit tests, performance optimization, documentation
40+
41+
6. Progress tracking and error handling:
42+
- Report progress after each completed task
43+
- Halt execution if any non-parallel task fails
44+
- For parallel tasks [P], continue with successful tasks, report failed ones
45+
- Provide clear error messages with context for debugging
46+
- Suggest next steps if implementation cannot proceed
47+
- **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
48+
49+
7. Completion validation:
50+
- Verify all required tasks are completed
51+
- Check that implemented features match the original specification
52+
- Validate that tests pass and coverage meets requirements
53+
- Confirm the implementation follows the technical plan
54+
- Report final status with summary of completed work
55+
56+
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.

‎.github/prompts/plan.prompt.md‎

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,42 @@
1+
---
2+
description: Execute the implementation planning workflow using the plan template to generate design artifacts.
3+
---
4+
5+
The user input to you can be provided directly by the agent or in `$ARGUMENTS` - you **MUST** consider it before proceeding with the prompt (if not empty).
6+
7+
User input:
8+
9+
$ARGUMENTS
10+
11+
Given the implementation details provided as an argument, do this:
12+
13+
1. Run `.specify/scripts/bash/setup-plan.sh --json` from the repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. All future file paths must be absolute.
14+
2. Read and analyze the feature specification to understand:
15+
- The feature requirements and user stories
16+
- Functional and non-functional requirements
17+
- Success criteria and acceptance criteria
18+
- Any technical constraints or dependencies mentioned
19+
20+
3. Read the constitution at `.specify/memory/constitution.md` to understand constitutional requirements.
21+
22+
4. Execute the implementation plan template:
23+
- Load `.specify/templates/plan-template.md` (already copied to IMPL_PLAN path)
24+
- Set Input path to FEATURE_SPEC
25+
- Run the Execution Flow (main) function steps 1-9
26+
- The template is self-contained and executable
27+
- Follow error handling and gate checks as specified
28+
- Let the template guide artifact generation in $SPECS_DIR:
29+
* Phase 0 generates research.md
30+
* Phase 1 generates data-model.md, contracts/, quickstart.md
31+
* Phase 2 generates tasks.md
32+
- Incorporate user-provided details from arguments into Technical Context: $ARGUMENTS
33+
- Update Progress Tracking as you complete each phase
34+
35+
5. Verify execution completed:
36+
- Check Progress Tracking shows all phases complete
37+
- Ensure all required artifacts were generated
38+
- Confirm no ERROR states in execution
39+
40+
6. Report results with branch name, file paths, and generated artifacts.
41+
42+
Use absolute paths with the repository root for all file operations to avoid path issues.

‎.github/prompts/specify.prompt.md‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
---
2+
description: Create or update the feature specification from a natural language feature description.
3+
---
4+
5+
The user input to you can be provided directly by the agent or in `$ARGUMENTS` - you **MUST** consider it before proceeding with the prompt (if not empty).
6+
7+
User input:
8+
9+
$ARGUMENTS
10+
11+
The text the user typed after `/specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `$ARGUMENTS` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
12+
13+
Given that feature description, do this:
14+
15+
1. Run the script `.specify/scripts/bash/create-new-feature.sh --json "$ARGUMENTS"` from repo root and parse its JSON output for BRANCH_NAME and SPEC_FILE. All file paths must be absolute.
16+
**IMPORTANT** You must only ever run this script once. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for.
17+
2. Load `.specify/templates/spec-template.md` to understand required sections.
18+
3. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
19+
4. Report completion with branch name, spec file path, and readiness for the next phase.
20+
21+
Note: The script creates and checks out the new branch and initializes the spec file before writing.

‎.github/prompts/tasks.prompt.md‎

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
---
2+
description: Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.
3+
---
4+
5+
The user input to you can be provided directly by the agent or in `$ARGUMENTS` - you **MUST** consider it before proceeding with the prompt (if not empty).
6+
7+
User input:
8+
9+
$ARGUMENTS
10+
11+
1. Run `.specify/scripts/bash/check-prerequisites.sh --json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
12+
2. Load and analyze available design documents:
13+
- Always read plan.md for tech stack and libraries
14+
- IF EXISTS: Read data-model.md for entities
15+
- IF EXISTS: Read contracts/ for API endpoints
16+
- IF EXISTS: Read research.md for technical decisions
17+
- IF EXISTS: Read quickstart.md for test scenarios
18+
19+
Note: Not all projects have all documents. For example:
20+
- CLI tools might not have contracts/
21+
- Simple libraries might not need data-model.md
22+
- Generate tasks based on what's available
23+
24+
3. Generate tasks following the template:
25+
- Use `.specify/templates/tasks-template.md` as the base
26+
- Replace example tasks with actual tasks based on:
27+
* **Setup tasks**: Project init, dependencies, linting
28+
* **Test tasks [P]**: One per contract, one per integration scenario
29+
* **Core tasks**: One per entity, service, CLI command, endpoint
30+
* **Integration tasks**: DB connections, middleware, logging
31+
* **Polish tasks [P]**: Unit tests, performance, docs
32+
33+
4. Task generation rules:
34+
- Each contract file → contract test task marked [P]
35+
- Each entity in data-model → model creation task marked [P]
36+
- Each endpoint → implementation task (not parallel if shared files)
37+
- Each user story → integration test marked [P]
38+
- Different files = can be parallel [P]
39+
- Same file = sequential (no [P])
40+
41+
5. Order tasks by dependencies:
42+
- Setup before everything
43+
- Tests before implementation (TDD)
44+
- Models before services
45+
- Services before endpoints
46+
- Core before integration
47+
- Everything before polish
48+
49+
6. Include parallel execution examples:
50+
- Group [P] tasks that can run together
51+
- Show actual Task agent commands
52+
53+
7. Create FEATURE_DIR/tasks.md with:
54+
- Correct feature name from implementation plan
55+
- Numbered tasks (T001, T002, etc.)
56+
- Clear file paths for each task
57+
- Dependency notes
58+
- Parallel execution guidance
59+
60+
Context for task generation: $ARGUMENTS
61+
62+
The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.

0 commit comments

Comments
 (0)