agentleFS
felipefontourafelipefontoura/pi-sdd-kit/skills/sdd-init/SKILL.md

sdd-init

Skill36 starsChanged 6 months agoMITView on GitHub

Explicit command-style skill for initializing or adopting SDD in a project by creating or preparing .ai/, .ai/steering/, and .ai/sdd/. Use only when the user explicitly asks to initialize, set up, adopt, or bootstrap SDD. Do not auto-load for general planning, feature specs, status checks, or implementation.

We split this skill into the rules it gives an agent

20 rules. 0 are common, 11 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read ../_shared/references/templates.md when creating starter files.

    line 19
  2. Very specific:

    Use package-level templates/ files as user-facing examples when available.

    line 20
  3. Very specific:

    Check whether .ai/, .ai/steering/, .ai/sdd/, and .ai/sdd/handoff/ already exist.

    line 23
  4. Very specific:

    Read existing .ai/steering/*.md, .ai/sdd/INDEX.md, and .ai/sdd/PLAN.md if present.

    line 24
  5. Very specific:

    If .ai/strategy/handoff/strategy-brief.md exists, note it as optional upstream context for future /skill:sdd-idea, /skill:sdd-plan, or …

    line 25
  6. Distinctive:

    Do not overwrite existing AI artifacts without explicit approval.

    line 27
  7. Distinctive:

    Ask whether the user wants:

    line 30
  8. Distinctive:

    Ask one question at a time.

    line 35
  9. Distinctive:

    Prefer inferred project facts from files, but confirm uncertain durable rules.

    line 36
  10. Very specific:

    Use .ai/steering/ for reusable context:

    line 39
  11. Very specific:

    Use .ai/sdd/ for SDD artifacts:

    line 45
  12. Distinctive:

    Keep generated starter docs concise and mark uncertain items as Open Questions.

    line 50
  13. Distinctive:

    Ask for explicit approval before writing files.

    line 54
  14. Distinctive:

    If files already exist, show what will be preserved or changed.

    line 55
  15. Distinctive:

    Create directories and files only after approval.

    line 58
  16. Distinctive:

    Never mark PLAN or feature artifacts approved during init.

    line 59
  17. Very specific:

    Do not create feature-level requirements.md, design.md, tasks.md, or code in this skill.

    line 148
  18. Distinctive:

    Do not mark any draft as approved.

    line 149
  19. Very specific:

    Do not overwrite existing .ai/ content without explicit approval.

    line 150
  20. Distinctive:

    Do not ask many setup questions at once.

    line 151

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

AI / SDD Init

Initialize a project workspace for AI-assisted Spec-Driven Development.

Purpose

INIT prepares the project for consistent AI work. It creates the shared .ai/ structure, captures minimal reusable steering context, initializes SDD tracking, and recommends the next safe step. Because this changes project structure, use it only after an explicit user request to initialize, set up, adopt, or bootstrap SDD.

Workflow

  1. Load references.
    • Read ../_shared/references/sdd-practical.md.
    • Apply the Language Policy: respond and write artifacts in the user's initial chat language while keeping skill instructions and templates in EN-US.
    • Read ../_shared/references/templates.md when creating starter files.
    • Use package-level templates/ files as user-facing examples when available.
  2. Inspect the project.
    • Check whether .ai/, .ai/steering/, .ai/sdd/, and .ai/sdd/handoff/ already exist.
    • Read existing .ai/steering/*.md, .ai/sdd/INDEX.md, and .ai/sdd/PLAN.md if present.
    • If .ai/strategy/handoff/strategy-brief.md exists, note it as optional upstream context for future /skill:sdd-idea, /skill:sdd-plan, or /skill:sdd-prd work.
    • Briefly inspect README, package files, docs, source tree, and verification scripts when available.
    • Do not overwrite existing AI artifacts without explicit approval.
  3. Clarify initialization scope.
    • Ask whether the user wants:
      • minimal setup: directories + index + workflow guide only
      • steering setup: product, tech stack, conventions, optional principles
      • SDD setup: index + workflow guide + optional first IDEA or PLAN
      • domain setup: extra steering doc such as lp.md
    • Ask one question at a time.
    • Prefer inferred project facts from files, but confirm uncertain durable rules.
  4. Draft starter artifacts.
    • Use .ai/steering/ for reusable context:
      • product.md
      • tech-stack.md
      • conventions.md
      • optional principles.md
      • optional <domain>.md
    • Use .ai/sdd/ for SDD artifacts:
      • INDEX.md
      • optional WORKFLOW.md copied or adapted from templates/sdd-workflow.md
      • handoff/ directory for future .ai/sdd/handoff/sdd-brief.md
      • optional PLAN.md as draft only if the user wants planning now
    • Keep generated starter docs concise and mark uncertain items as Open Questions.
  5. Review with the user.
    • Present the proposed files and short content summary.
    • Ask for explicit approval before writing files.
    • If files already exist, show what will be preserved or changed.
  6. Save approved initialization.
    • Create directories and files only after approval.
    • Never mark PLAN or feature artifacts approved during init.
    • Recommend next command:
      • /skill:sdd-idea for exploration
      • /skill:sdd-plan for roadmap planning
      • /skill:sdd-prd for a known small feature
      • /skill:sdd-steering for more reusable context

Suggested Initial Structure

.ai/
  steering/
    product.md
    tech-stack.md
    conventions.md
    principles.md        # optional
  sdd/
    INDEX.md
    WORKFLOW.md          # optional guide
    handoff/

Starter INDEX.md

# SDD Index

## Upstream Handoffs

- `.ai/strategy/handoff/strategy-brief.md`: missing or available

## Plan

- `.ai/sdd/PLAN.md`: missing

## Ideas

| ID | Name | Status | Path |
|----|------|--------|------|

## Feature Workspace

> Numbering source: actual directories under `.ai/sdd/specs/`, not this index.

| Field | Value | Notes |
|-------|-------|-------|
| Next Feature ID | 001 | Recompute from filesystem before creating a new spec |
| Numbering Issues | none | duplicate prefix / invalid status / non-canonical directory |

## Specs

| ID | Feature | Status | Requirements | Design | Tasks | Review |
|----|---------|--------|--------------|--------|-------|--------|

## Handoff

- `.ai/sdd/handoff/sdd-brief.md`: generated after approved tasks or completed review

## Next Actions

- [ ] Capture first idea with `/skill:sdd-idea`
- [ ] Or create a plan with `/skill:sdd-plan`
- [ ] Or create requirements for a known feature with `/skill:sdd-prd`

Output

Common outputs:

  • .ai/steering/product.md
  • .ai/steering/tech-stack.md
  • .ai/steering/conventions.md
  • Optional .ai/steering/principles.md
  • .ai/sdd/INDEX.md
  • Optional .ai/sdd/WORKFLOW.md
  • .ai/sdd/handoff/ directory
  • Optional .ai/sdd/PLAN.md draft
  • Optional .ai/steering/<domain>.md

Quality Bar

  • Initialization must be safe and idempotent.
  • Existing artifacts must be preserved unless the user approves changes.
  • Generated files must be short enough to be useful as persistent context.
  • Unknown facts must become Open Questions, not invented rules.
  • The final response must list created/updated files and recommended next step.

Critical Rules

  • Do not create feature-level requirements.md, design.md, tasks.md, or code in this skill.
  • Do not mark any draft as approved.
  • Do not overwrite existing .ai/ content without explicit approval.
  • Do not ask many setup questions at once; initialize progressively.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.