The SDLC Skills Every Modern Principal Must Know

The roles are collapsing. You know this. You feel it. The business analyst who wrote requirements is gone. The architect who drew diagrams is gone. The QA team that wrote test plans is gone. The DevOps engineer who managed pipelines is gone.

Their work is not gone. You are doing all of it now.

This is not a crisis. It is a skill map. Here are the skills, why each one matters, and how to practice them.

1. Requirements Engineering

The old way: A BA interviews stakeholders for weeks, writes a 60-page BRD, hands it to architects, argues about scope for a month.

The new way: You write a specification. Complete. Unambiguous. In your voice. You know the domain because you have been in the meetings. You write what the system must do, not what stakeholders said in a conference room.

SCREENSHOT: Big Bang specification panel showing a loaded spec, formatted, scrollable, with the AI about to decompose it

The skill: Write a specification that an AI can decompose without hallucinating. This means:

State the stack explicitly (“Astro frontend, Node/Express backend”)
Declare the data model (“JSON content files in git, no database for content”)
Define done (“the app boots, the health endpoint responds, the pages render”)
Name what you do not want (“no CMS, no framework lock-in, no paid tiers”)

Practice in StellarView: Big Bang Epic Creator. Paste a spec. See how the AI decomposes it. If the phases are wrong, the spec was ambiguous. Refine and try again. The decomposition is your spec’s grade.

2. Architecture Design

The old way: An architect spends two weeks drawing diagrams in Lucidchart. The team argues about patterns. Nobody looks at the diagrams after sprint one.

The new way: Architecture is expressed as Mermaid diagrams inside the epic. Each phase has one. Each work unit may have one. The diagrams are generated by the AI, reviewed by you, and editable inline. They are not documentation, they are the blueprint that Miracle follows.

SCREENSHOT: Mermaid architecture diagram in Big Bang, rendered, zoomable, with "Edit Diagram" button

The skill: Read a Mermaid diagram and know if the architecture is right. This means:

Spot layer violations (UI importing directly from Infrastructure)
Identify missing components (no auth middleware in the API layer)
Verify data flow direction (does the pipeline actually connect end to end?)
Challenge assumptions (why does this need a message queue?)

Practice in StellarView: Galaxy Explorer. Point it at any repo. See the real architecture as a 3D constellation. Compare the constellation against the epic’s diagrams. Where they diverge, the architecture drifted.

3. AI-Directed Code Generation

The old way: You write code. Line by line. File by file. Eight hours a day.

The new way: You direct code generation. You write the specification. The AI writes the code. You review the output. You fix what the AI got wrong. You push what it got right.

The skill: Know when the AI is right and when it is wrong. This means:

Read generated code critically, not hopefully
Spot anti-patterns (God objects, circular dependencies, missing error handling)
Verify naming conventions match the codebase
Test the happy path AND the error path
Never assume generated code works, verify it boots

SCREENSHOT: Execution log showing Claude Code writing files in real-time, file names, changes, commit messages

Practice in StellarView: Run a Miracle phase. Read the diff. Would you approve this PR from a junior developer? If not, the analysis or the prompt template needs tuning. Open HAL Template Studio and adjust.

4. Quality Assurance

The old way: A QA team writes test plans, executes manual tests, files bugs in JIRA, argues about severity.

The new way: Quality is verified by boot checks, not test plans. Does the app start? Does the health endpoint respond? Do the key pages render? If yes, the code is minimally viable. Unit tests come second.

The skill: Define what “working” means before code is generated. This means:

Write acceptance criteria that are executable (“curl /health returns 200”)
Include smoke tests in every phase (“after this phase, the journal page renders with 3 test posts”)
Know the difference between “tests pass” and “app works”
Run the app locally before declaring the phase done

Practice in StellarView: The Forge. After each Miracle phase, Genesis detects the stack and attempts to boot the app. Three auto-fix attempts. If it boots, the phase is verified. If not, a stuck issue tells you exactly what’s broken.

5. CI/CD and Infrastructure

The old way: A DevOps engineer maintains Jenkins pipelines, writes Terraform, manages AWS accounts, handles deployments.

The new way: Infrastructure is code in the repo. CI/CD is a GitHub Action. Deployment is a Fleet command. You do not manage servers, you declare infrastructure and let the platform provision it.

SCREENSHOT: Fleet dashboard showing Ghost instances, deployment status, AWS resource allocation

The skill: Read a Terraform file and a GitHub Action and know if they are safe. This means:

Spot missing security groups
Verify IAM policies follow least privilege
Ensure CI runs the boot check, not just unit tests
Know when to use Fargate vs. EC2 vs. Lambda

Practice in StellarView: Fleet management. Deploy a Ghost. Watch the Construct provision. Read the Terraform. Break it. Fix it. You learn infrastructure by operating it, not by reading about it.

6. Knowledge Management

The old way: Someone writes Confluence pages. Nobody reads them. Tribal knowledge lives in Slack threads that expire. The architect leaves and takes the architecture with them.

The new way: Knowledge is ingested, classified, and queryable. Space Lake captures documents. The ontology engine classifies them. The RAG Companion answers questions grounded in your actual knowledge base.

The skill: Know what to ingest and when to query. This means:

Ingest at the start of every engagement. SOWs, existing docs, meeting recordings
Query before you design, “what do we already know about this?”
Let the classification reveal patterns you did not see
Review the RAG Companion’s sources, grounded answers with wrong sources are worse than no answer

Practice in StellarView: Foundation Inversion. Pick a client galaxy. Ingest their Confluence dump. Ask the RAG Companion questions. Compare the grounded answers against what you thought you knew.

7. Client Communication

The old way: Status meetings, weekly reports, PowerPoint decks, email threads.

The new way: The cosmic emissions ARE the status report. The epic phases ARE the project plan. The GitHub issues ARE the deliverable tracker. The client can see progress without the practitioner stopping to report it.

The skill: Translate StellarView artifacts into client-facing communication. This means:

Point clients to the GitHub epic, they can see every phase, every PR, every discussion
Use the Mermaid diagrams in presentations, they are already drawn
Show cosmic emissions when asked about AI costs, full transparency
Record a screenshare walkthrough, 5 minutes of showing beats 30 minutes of telling

Practice in StellarView: The demo production lifecycle. Design → Build → Launch → Reveal → Retro → Package. Every engagement is a potential demo. Every demo is a client communication asset.

The Skill Stack

These seven skills are not learned sequentially. They are practiced simultaneously, in every engagement, every day. The Modern Principal does not specialize in one. They practice all seven, with AI as the multiplier that makes it possible.

StellarView is the practice environment. PracticAI is the discipline that ties it together.

The roles collapsed. The skills compounded. The practice is here.

Start practicing: Enter StellarView →