devflow

DevFlow — AI Development Workflow Skill

Version 1.0 · Portable · LLM-Agnostic

A structured, command-driven development workflow for AI coding assistants. Works with Claude, GPT-4/o, Gemini, Mistral, and local LLMs.

---

COMMAND REFERENCE

Command	Full Name	One-Line Description
B	Build	Implement the next roadmap item or specified feature
I	Integrate	Reflect on recent changes; sync docs + state
Im	Improve	Refactor, optimise, harden — no new features
E	Evaluate	Audit: quality, security, performance, consistency
C	Consolidate	Deduplicate, remove dead code, reorganise
Bl	Blueprint	Update the project documentation/blueprint file
P	Push	Git commit (smart message) + push to all remotes
D	Deploy	Deploy to live server; confirm live URL
Rb	Robustify	Harden error handling, fault tolerance, graceful degradation
Rl	Reliabilify	Add monitoring, SLOs, health checks, observability
So	Solidify	Comprehensive testing — unit, integration, e2e, load
St	Stabilize	Performance optimization, scaling, rate limiting
CI	Continuous Improve	Full pipeline: I → Im → E → C → Bl → P → D
Kf	KafCa	Activate token-efficiency mode
RRSS	RRSS Pipeline	Full resilience: Rb → Rl → So → St

Combination syntax: B+Bl+P+D runs commands left-to-right. Pipeline alias: full = B+I+Im+E+C+Bl+P+D KafCa prefix: Kf B+P+D — run any pipeline in token-efficient mode.

---

COMMAND SPECIFICATIONS

B — Build

Purpose: Implement the next item on the project roadmap, or a feature the user specifies.

Steps:

1. Read CLAUDE.md (or equivalent project context file) and the blueprint/roadmap.
2. Identify the next 🔲 roadmap item, or accept a feature spec from the user.
3. Plan: list files to create/modify, dependencies, security implications.
4. Implement: write code that is secure, efficient, robust, stable, scalable.
5. Verify: check for syntax errors, broken references, exposed secrets.
6. Report: what was built, what files changed, what is next.

Quality gates (must pass before completing B):

• No API keys or secrets hardcoded in source
• All user-controlled strings HTML-escaped before innerHTML injection
• Graceful fallback / error handling on every async operation
• No eval(), no document.write(), no inline javascript: hrefs

---

I — Integrate

Purpose: Reflect on what was built; synchronise code with docs and state.

Steps:

1. git diff HEAD — summarise what changed since last commit.
2. Check that every new function/module is documented.
3. Check that roadmap items newly completed are marked ✅ in blueprint.
4. Note any technical debt, deferred items, or follow-up needed.
5. Update CLAUDE.md if architectural facts changed.
6. Output: integration summary (what changed, what is in sync, what needs attention).

---

Im — Improve

Purpose: Improve existing code quality without changing external behaviour.

Steps:

1. Run E (Evaluate) first to get a prioritised finding list.
2. Apply improvements in priority order:
   • P0 — Security: XSS vectors, exposed secrets, unsafe patterns → fix immediately
   • P1 — Correctness: off-by-one, null-dereference, race conditions
   • P2 — Performance: unthrottled events, redundant re-renders, large payloads
   • P3 — Quality: dead code, magic numbers, duplicated logic, inconsistent naming
   • P4 — Style: formatting, comment accuracy, unused imports
3. Do not introduce new features during Im.
4. Report: list of improvements made, items deferred, measurable gains (if any).

---

E — Evaluate

Purpose: Produce a structured audit report across four axes.

Output format:

## Evaluation Report — [project] [date]

### Security  (P0)
[finding: file:line — description — severity — recommended fix]

### Correctness  (P1)
[...]

### Performance  (P2)
[...]

### Quality / Consistency  (P3–P4)
[...]

### Score
Security: X/10 · Correctness: X/10 · Performance: X/10 · Quality: X/10

Checks to run:

• Grep for: innerHTML =, eval(, document.write(, localStorage.setItem.*secret, hardcoded tokens
• Count async functions without try/catch
• Check all external API calls have timeout/abort handling
• Verify CSP headers present (if web project)
• Check service worker cache strategy is correct
• Verify no console.log of sensitive data

---

C — Consolidate

Purpose: Clean up; eliminate redundancy; improve organisation.

Steps:

1. git status — list untracked files that should be .gitignored.
2. Find duplicate functions/logic → extract to shared helpers.
3. Remove dead code (functions never called, CSS never used).
4. Verify file organisation matches blueprint file manifest.
5. Check .gitignore covers: node_modules/, .env, *.log, dist/, secrets.
6. Report: what was removed/merged, line-count delta, files reorganised.

---

Bl — Blueprint

Purpose: Update the project's living blueprint/documentation file to reflect current reality.

Steps:

1. Read the blueprint file (e.g., *_Blueprint*.md).
2. Diff blueprint claims vs. actual code state:
   • Version number matches package.json
   • All shipped roadmap items marked [x]
   • Module/function count is accurate
   • File manifest reflects actual files
   • API table reflects actual integrations
3. Add changelog entry for the current version.
4. Update executive summary if scope changed.
5. Update footer: version, date, deploy URL.
6. Preserve all historical changelogs — never delete past entries.

---

P — Push

Purpose: Commit all staged changes with a smart message and push to all remotes.

Steps:

1. git status — list what will be committed (never use git add -A blindly; stage specific files).
2. git diff --stat — confirm the diff is as expected.
3. Compose commit message:
   • Type prefix: feat: / fix: / docs: / refactor: / perf: / security:
   • Subject line: ≤72 chars, imperative mood, no period
   • Body: what + why (not how), bullet list if multiple changes
   • Footer: Co-Authored-By: if AI-assisted
4. git commit -m "..." via HEREDOC to preserve formatting.
5. git push origin main
6. If project has dual-branch deploy (e.g., root = GitHub Pages default): git push origin main:root
7. Confirm: show git log --oneline -3.

---

D — Deploy

Purpose: Push the live version to the deployment target and confirm.

Detection order (first match wins):

1. netlify.toml present → deploy via Netlify
2. vercel.json present → deploy via Vercel
3. .github/workflows/*.yml present → GitHub Actions (auto on push)
4. No config → GitHub Pages (push to gh-pages or configured branch)

Netlify path:

netlify deploy --prod --dir .

Vercel path:

vercel --prod

GitHub Pages path: Served from root of root or main branch.

After deploy — verify:

• Live URL loads (HTTP 200)
• Service Worker registered (DevTools → Application → Service Workers)
• PWA manifest valid
• No mixed-content warnings

---

Kf — KafCa

Purpose: Activate token-efficiency mode for the current session.

Effect (immediate, session-wide):

• Verdict/code first — no preamble
• No openers: no "Certainly", "Great", "I'll now..."
• Plan ≤ 3 bullets; report only what changed
• Surgical edits; never re-print unchanged code
• Functions: 1 job, short names, comments only for non-obvious WHY

Usage:

Kf            ← activate for this session
Kf B+P+D      ← build+push+deploy in KafCa mode

---

Rb — Robustify

Purpose: Harden error handling, fault tolerance, and graceful degradation throughout the system.

Steps:

1. Inventory all external dependencies, API calls, and I/O boundaries.
2. Add circuit breakers, retry logic with exponential backoff, and fallbacks.
3. Implement graceful degradation — every feature works in reduced mode if dependencies fail.
4. Add structured error handling with typed error classes (never swallow exceptions).
5. Verify: inject faults (chaos testing), confirm graceful handling.
6. Report: robustness score before/after, failure modes now covered.

Quality gates:

• Every async call has a timeout and a fallback path
• Circuit breaker configured for all external services
• No unhandled promise rejections or swallowed errors
• Graceful degradation paths tested for each dependency

---

Rl — Reliabilify

Purpose: Add monitoring, alerting, SLOs, and observability to make the system reliable.

Steps:

1. Define SLOs for critical user flows (availability, latency, error rate).
2. Add structured logging with correlation IDs across request lifecycle.
3. Set up metrics: request rate, error rate, duration (RED method).
4. Configure alerts: page on SLO breach, warn on trends.
5. Add health check endpoints (liveness, readiness, deep checks).
6. Report: SLO definitions, alert rules, observability coverage.

Quality gates:

• All critical paths have latency and error-rate metrics
• Logs include correlation IDs for distributed tracing
• Health checks distinguish between live and ready
• Alerts have runbooks linked (who does what when fired)

---

So — Solidify

Purpose: Comprehensive testing — unit, integration, e2e, load. Make the codebase rock-solid.

Steps:

1. Audit current test coverage — identify gaps in critical paths.
2. Add unit tests for all business logic (target: >80% coverage).
3. Add integration tests for all API endpoints and database paths.
4. Add end-to-end tests for critical user flows (login, checkout, etc.).
5. Add load/stress tests to validate performance under expected peak traffic.
6. Report: coverage metrics, test count by type, flaky test count.

Quality gates:

• All new code has corresponding tests (no code without tests)
• Test suite runs in CI under 5 minutes
• No flaky tests (retry-with-pass does not count as fixed)
• Load test validates 2× expected peak traffic

---

St — Stabilize

Purpose: Performance optimization, scaling strategy, and resource management.

Steps:

1. Profile: identify bottlenecks (CPU, memory, I/O, network).
2. Optimize: fix the top 3 bottlenecks with measurable impact.
3. Add rate limiting and backpressure to prevent overload cascades.
4. Configure auto-scaling rules (scale up fast, scale down slow).
5. Add resource quotas and circuit breakers at infrastructure level.
6. Report: latency before/after, throughput gain, cost impact.

Quality gates:

• P95 latency under SLO threshold at 2× traffic
• No memory leaks (validated over 24h soak test)
• Rate limiting prevents cascade failures
• Auto-scaling responds within 60 seconds of threshold breach

---

RRSS — RRSS Pipeline

Purpose: Run the full resilience pipeline. The complete robustness lifecycle.

Pipeline: Rb → Rl → So → St

Execution:

1. Run each command in sequence.
2. After each command, run a smoke test to confirm nothing broke.
3. At end, produce a RRSS Report: robustness, reliability, solidity, stability scores.
4. Flag any architectural changes needed (not just code-level fixes).

---

CI — Continuous Improve

Purpose: Run the full improvement pipeline without building new features.

Pipeline: I → Im → E → C → Bl → P → D

Execution:

1. Run each command in sequence.
2. After each command, check: did anything break? If yes, fix before continuing.
3. At end, report a structured summary of all changes made.
4. Flag any items that require human decision (breaking changes, cost implications, etc.).

---

COMBINATION RULES

Input	Resolves to	Typical use case
B P D	Build → Push → Deploy	Ship a new feature
I Bl P	Integrate → Blueprint → Push	Sync docs after a build session
Im P D	Improve → Push → Deploy	Harden + ship
E Im	Evaluate → Improve	Quality pass without deploy
C Bl P	Consolidate → Blueprint → Push	Cleanup commit
CI	I→Im→E→C→Bl→P→D	Full maintenance cycle
full	B→I→Im→E→C→Bl→P→D	Complete feature lifecycle
RRSS	Rb→Rl→So→St	Full resilience cycle
full+RRSS	full → RRSS	Feature + resilience lifecycle

Parsing rules:

• Commands separated by space, +, ,, or → are all equivalent.
• Commands are case-insensitive: b+p+d = B+P+D.
• If user types only a command letter with no other context, infer project from current working directory / open files.

---

CONTEXT DETECTION

When invoked, the skill auto-detects project context by reading (in order):

1. CLAUDE.md — project facts, conventions, commands
2. *_Blueprint*.md — roadmap, architecture, version
3. package.json — name, version, scripts
4. git log --oneline -5 — recent activity
5. git status — current state

If none found, ask user: "What is this project? Drop a README or describe it."

---

QUALITY PRINCIPLES (R²S²)

Every output from this skill must be:

Principle	Meaning
Robust	Handles errors gracefully; never crashes silently
Reliable	Produces consistent, predictable results
Solid	No half-measures; complete implementations only
Stable	Does not break existing functionality
Resistant	Fault-tolerant; degrades gracefully under failure
Scalable	Code patterns support growth without rewrite
Secure	No exposed secrets; XSS-safe; CSP-compliant
Systematic	Follows established project conventions

---

PORTABILITY NOTES

Using as a Kimi Skill

Register: place in /app/.user/skills/devflow/SKILL.md. Trigger phrases: any of the command letters alone or combined, or "devflow".

Using with other cloud LLMs (GPT-4, Gemini, Mistral, etc.)

Paste this document as the system prompt prefix, then type your command.

Using with local LLMs (Ollama / LMStudio / etc.)

1. Create a Modelfile or system prompt template with this document.
2. Recommended models: codestral, deepseek-coder-v2, qwen2.5-coder.
3. Temperature: 0.1–0.2 for deterministic code output.

---

VERSIONING

Version	Date	Changes
1.0	May 2026	Initial release; 10 commands; R²S² principles; full portability guide
1.1	May 2026	Added RRSS commands: Rb, Rl, So, St; RRSS pipeline; resilience layer

DevFlow Skill v1.0 · Portable: Claude · GPT-4 · Gemini · Mistral · Ollama