Stack Profile

Stack Profile

Every other skill in this library deliberately names patterns rather than libraries: "circuit breaker", not a specific implementation. That keeps the guidance portable, and it makes the advice vague until someone says what this project actually uses.

This skill closes that gap once. It writes .msskills/stack.md, which every principle reads in step 5 of its Config Resolution, and a starter .msskills/config.yaml pointing at any house standards the team already has.

Workflow

Step 1 — Detect what you can

Read the repository before asking anything. A question whose answer is sitting in a manifest file wastes the user's time and signals you did not look.

Look for, in this order:

1. Build and dependency manifests — pom.xml, build.gradle*, package.json, go.mod, *.csproj, Cargo.toml, pyproject.toml, requirements.txt, Gemfile. These give the language, the framework, and most libraries.
2. Lockfiles — confirm actual versions rather than declared ranges.
3. Container and deployment files — Dockerfile, docker-compose*, *.yaml under k8s/, helm/, .github/workflows/, Terraform. These give the platform, the datastore, and the broker.
4. Configuration — application*.yml, appsettings*.json, .env.example, config packages. These give the config mechanism and often the secret manager.
5. Existing tests — the framework, the assertion style, whether containers or contract tooling are already in use, and the naming convention.
6. Existing architecture — the package or module layout, any architecture tests, any specification files (openapi.*, asyncapi.*, *.proto).
7. Existing standards — a CONTRIBUTING.md, ARCHITECTURE.md, docs/, or an ADR directory. If the team already has written standards, they outrank this library's defaults, and config.yaml should point at them.

An empty or greenfield repository is a valid answer. Say so and move to the interview.

Step 2 — Present what you found, then ask only for the gaps

Show the detected profile as a compact table with a confidence marker, then ask about what is genuinely missing or ambiguous. Batch the questions into one message — see collaborative-judgment on batching.

Detected from the repository:

| Aspect | Value | Source |
|---|---|---|
| Language | Java 21 | pom.xml |
| Framework | Spring Boot 3.4 | pom.xml |
| Datastore | PostgreSQL 16 | docker-compose.yml, Flyway migrations |
| Test framework | JUnit 5 + AssertJ + Testcontainers | pom.xml, src/test |
| Resilience | Resilience4j | pom.xml |

Not found — could you confirm?
1. Message broker: none detected. Is this service synchronous only, or is a broker planned?
2. Contract testing: nothing detected. Is there a broker for contracts, or is this the first?
3. Secret management: where do credentials come from in production?
4. Do you already have written architecture or testing standards I should point the skills at?

Ask no more than six questions. If the user does not know an answer, record it as unknown and move on — an incomplete profile is far better than an interview nobody finishes.

Step 3 — Cover the aspects that matter

The profile is only useful for what other skills actually consult. Aim to fill these; leave the rest blank rather than padding.

Step 4 — Write the files

Write .msskills/stack.md using the template. Keep it factual: what is used, not what is recommended. Mark anything inferred rather than confirmed.

Then write .msskills/config.yaml if it does not exist:

# Points skills at this project's own standards. Delete any key you have no document for —
# a key with no file produces a warning on every run.
paths:
  architecture: docs/standards/architecture.md   # clean-architecture
  testing: docs/standards/testing.md             # test-strategy
  # api:          # api-contracts
  # protocols:    # api-protocols
  # security:     # secure-service
  # boundaries:   # service-boundaries
  # domain:       # domain-modelling
  # persistence:  # data-access
  # consistency:  # cqrs-and-consistency
  # adapters:     # infrastructure-adapters
  # resilience:   # resilience-patterns
  # idempotency:  # idempotency-and-immutability
  # contracts:    # contract-testing
  # config:       # config-and-dependencies
  # judgment:     # collaborative-judgment
  # design:       # design-first

Only include keys for documents that exist. A custom document needs mode: overlay (add to the defaults) or mode: override (replace them) in its own frontmatter.

Step 5 — Confirm and hand off

Show the written profile, say which skills it will change the behaviour of, and name the concrete difference:

Written .msskills/stack.md. resilience-patterns will now say Resilience4j rather than "a circuit breaker library", and test-strategy will assume Testcontainers for component tests. Contract testing is recorded as none — when you adopt a tool, rerun this skill.

Rules

• Detect before asking. Anything discoverable from the repository must not be a question.
• Record, do not recommend. This skill captures what the project uses. If something is missing — no contract testing, no secret manager — note it as absent. Suggesting a tool here would put a recommendation into a file that ten other skills treat as fact.
• Mark confidence. Distinguish confirmed by the user, read from a file, and inferred.
• Never invent. If a library was not found and the user did not name one, write unknown. A guessed library name propagates into generated code.
• Re-running is normal. Read the existing profile, show what changed, and preserve anything the user typed by hand.
• Keep it short. This file is read by every skill. Facts and versions, not prose.