원클릭으로
sspec-align
Structured, efficient agent-user synchronization at decision points. Formalized exchange over prose.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Structured, efficient agent-user synchronization at decision points. Formalized exchange over prose.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Pre-scan Markdown files before reading. Use `sspec tool mdtoc` to get file size + heading structure with line numbers (L<n> format) before reading long docs, SKILLs, or spec-docs. Eliminates blind reads.
Assess scale, create change, fill spec.md + design.md, align with user. Use after clarify when ready to define the solution.
Execute tasks from tasks.md. Implement code changes, update progress. Use after plan approval.
Break design into concrete tasks. Fill tasks.md with file-level execution plan. Use after design alignment.
User acceptance and feedback loop. Handle argue-improve cycles until user is satisfied.
Build shared understanding through dialogue and investigation. Produces Problem Statement + direction sketch. Reusable posture, not rigid phase.
| name | sspec-align |
| description | Structured, efficient agent-user synchronization at decision points. Formalized exchange over prose. |
| metadata | {"author":"frostime","version":"12.0.0"} |
Core principle: Every @align must answer three questions — What happened? What needs deciding? What are the options? — in structured format, not prose. Goal: 5-second scan, instant decision.
| Level | Agent behavior | Typical situations |
|---|---|---|
report | Structured summary, keep going | Plan done, progress update, low-risk confirmation |
gate | Structured summary, stop and wait | Design done, implement complete, blocker, scope change, irreversible action |
Rule: If safe progress depends on a user decision, the agent MUST use gate. Otherwise prefer report.
@align information MUST use structured format. Prose-style @align is an anti-pattern.
❌ Prose @align:
"I've been thinking about the design and I believe we should
split the service into three parts. The first handles auth,
the second manages sessions, and the third provides the API.
What do you think?"
✅ Structured @align:
## Design Gate
| Component | Source → Target | Responsibility |
|-----------|----------------|----------------|
| Auth | `handlers/monolith.py` → `services/auth.py` | Authentication |
| Session | `middleware/chain.py` → `services/session.py` | State mgmt |
| API | (new) `api/surface.py` | Thin wrapper |
**Rationale**: Testability + independent deployment
**Risk**: Migration complexity (feature flag mitigates)
→ Proceed with this split?
question-like tool ONLY for the final concise askquestion-like tool is available → use it for the final asksspec tool ask is available → use it as fallbackFor large context, write analysis to .sspec/tmp/ and link it instead of pasting inline.
Fallback tool usage reference: sspec tool ask --prompt
Alignment without record = information lost on next session.
| What changed | Where to record |
|---|---|
| Design confirmed/revised | spec.md / design.md |
| Plan confirmed/revised | tasks.md |
| Direction changed, key decision made | memory.md Knowledge |
| User feedback received | memory.md Knowledge (new entry) |
| Scope/design change after gate | revisions/NNN-*.md + tasks.md |
No separate ask record is required. Put the decision in its natural home.