|
1 | 1 | --- |
2 | | -name: plan |
| 2 | +name: spec |
3 | 3 | description: > |
4 | | - Plan a feature or change with full knowledge of the opinionated TypeScript architecture and the project's adoption state. |
| 4 | + Spec out a feature or change with full knowledge of the opinionated TypeScript architecture and the project's adoption state. |
5 | 5 | Conducts a thorough discovery interview to understand domain concerns, bounded contexts, and application services, |
6 | 6 | then produces a high-level architectural specification — never concrete implementation details. |
7 | | - Triggers on phrases like "plan a feature", "design this change", "architect this", |
8 | | - "help me plan", "what modules do I need", or "think through this feature". |
9 | | - Also invocable via the /tseng:plan slash command. |
| 7 | + Triggers on phrases like "spec this feature", "design this change", "architect this", |
| 8 | + "help me spec", "what modules do I need", or "think through this feature". |
| 9 | + Also invocable via the /tseng:spec slash command. |
10 | 10 | --- |
11 | 11 |
|
12 | 12 | ```! |
13 | 13 | echo "Architecture docs: ${CLAUDE_SKILL_DIR}/architecture/" |
14 | 14 | echo "Version: $(cat "${CLAUDE_SKILL_DIR}/VERSION")" |
15 | 15 | ``` |
16 | 16 |
|
17 | | -# TSEng Plan |
| 17 | +# TSEng Spec |
18 | 18 |
|
19 | | -Plans features and changes with full knowledge of the opinionated TypeScript architecture and the project's current adoption state. Produces a high-level architectural specification through rigorous discovery — never concrete implementation details. |
| 19 | +Specs out features and changes with full knowledge of the opinionated TypeScript architecture and the project's current adoption state. Produces a high-level architectural specification through rigorous discovery — never concrete implementation details. |
20 | 20 |
|
21 | 21 | The output is a specification that gives the implementer architectural guardrails (which modules, which layers, which events, which services etc.) while leaving room for creative decisions about *how* to implement each piece. |
22 | 22 |
|
@@ -233,7 +233,7 @@ If yes: |
233 | 233 | 3. Create the issue using `gh issue create`. |
234 | 234 | 4. Report the issue URL to the user. |
235 | 235 |
|
236 | | -The issue body should be the specification from Phase 5, formatted for GitHub readability. Include a header noting it was generated by TSEng Plan with the architecture version. |
| 236 | +The issue body should be the specification from Phase 5, formatted for GitHub readability. Include a header noting it was generated by TSEng Spec with the architecture version. |
237 | 237 |
|
238 | 238 | ## Guidelines |
239 | 239 |
|
|
0 commit comments