lightspec 0.3.1 → 0.3.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -1,2 +1,2 @@
|
|
|
1
|
-
export declare const agentsRootStubTemplate = "# LightSpec Instructions\n\nThese instructions are for AI assistants working in this project.\n\n
|
|
1
|
+
export declare const agentsRootStubTemplate = "# LightSpec Instructions\n\nThese instructions are for AI assistants working in this project.\n\n**If (and only if) the feature is complex** (new capability, breaking change, architecture/performance/security work), follow these steps:\n\n- [ ] Suggest switching to `/plan` mode before writing the proposal if it's not already the case\n- [ ] Run `lightspec-proposal`.\n- [ ] Do not implement the feature until the proposal is approved by the user. Implementation MUST be operated using `lightspec-apply` to ensure the implementation is properly tracked and documented.\n- [ ] If unsure which skill to run, list installed skills.\n\nKeep this managed block so 'lightspec update' can refresh the instructions.\n";
|
|
2
2
|
//# sourceMappingURL=agents-root-stub.d.ts.map
|
|
@@ -2,8 +2,12 @@ export const agentsRootStubTemplate = `# LightSpec Instructions
|
|
|
2
2
|
|
|
3
3
|
These instructions are for AI assistants working in this project.
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
|
|
5
|
+
**If (and only if) the feature is complex** (new capability, breaking change, architecture/performance/security work), follow these steps:
|
|
6
|
+
|
|
7
|
+
- [ ] Suggest switching to \`/plan\` mode before writing the proposal if it's not already the case
|
|
8
|
+
- [ ] Run \`lightspec-proposal\`.
|
|
9
|
+
- [ ] Do not implement the feature until the proposal is approved by the user. Implementation MUST be operated using \`lightspec-apply\` to ensure the implementation is properly tracked and documented.
|
|
10
|
+
- [ ] If unsure which skill to run, list installed skills.
|
|
7
11
|
|
|
8
12
|
Keep this managed block so 'lightspec update' can refresh the instructions.
|
|
9
13
|
`;
|
|
@@ -11,17 +11,19 @@ metadata:
|
|
|
11
11
|
const proposalGuardrails = `${baseGuardrails}\n- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
|
|
12
12
|
- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.`;
|
|
13
13
|
const proposalSteps = `**Steps**
|
|
14
|
-
1. Run \`lightspec list\` and \`lightspec list --specs\`, and inspect related code or docs (e.g., via \`rg\`/\`ls\`) to ground the proposal in current behaviour
|
|
15
|
-
2.
|
|
16
|
-
3.
|
|
17
|
-
4.
|
|
18
|
-
5.
|
|
19
|
-
6. Draft \`
|
|
20
|
-
7.
|
|
14
|
+
1. Run \`lightspec list\` and \`lightspec list --specs\`, and inspect related code or docs (e.g., via \`rg\`/\`ls\`) to ground the proposal in current behaviour.
|
|
15
|
+
2. Note any gaps in the user plan that require clarification. Ask follow-up questions to resolve ambiguities before proceeding. Avoid making assumptions about unstated requirements or implementation details.
|
|
16
|
+
3. Choose a unique verb-led \`change-id\` and scaffold \`proposal.md\`, \`tasks.md\`, and \`design.md\` (when needed) under \`lightspec/changes/<id>/\`.
|
|
17
|
+
4. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
|
|
18
|
+
5. Capture architectural reasoning in \`design.md\` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
|
|
19
|
+
6. Draft spec deltas in \`changes/<id>/specs/<capability>/spec.md\` (one folder per capability) using \`## ADDED|MODIFIED|REMOVED Requirements\` with at least one \`#### Scenario:\` per requirement and cross-reference related capabilities when relevant.
|
|
20
|
+
7. Draft \`tasks.md\` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
|
|
21
|
+
8. Validate with \`lightspec validate <id> --strict --no-interactive\` and resolve every issue before sharing the proposal.`;
|
|
21
22
|
const proposalReferences = `**Reference**
|
|
22
23
|
- Use \`lightspec show <id> --json --deltas-only\` or \`lightspec show <spec> --type spec\` to inspect details when validation fails.
|
|
23
24
|
- Search existing requirements with \`rg -n "Requirement:|Scenario:" lightspec/specs\` before writing new ones.
|
|
24
|
-
- Explore the codebase with \`rg <keyword>\`, \`ls\`, or direct file reads so proposals align with current implementation realities
|
|
25
|
+
- Explore the codebase with \`rg <keyword>\`, \`ls\`, or direct file reads so proposals align with current implementation realities.
|
|
26
|
+
- If rg is unavailable, use platform-native search tools and suggest installing rg for efficient proposal development.`;
|
|
25
27
|
export const proposalTemplate = [
|
|
26
28
|
proposalGuardrails,
|
|
27
29
|
proposalSteps,
|