이제 갓 1년차가 되어갑니다. 1년을 스타트업의 연구원 인턴으로 근무하고 이제 이직을 하게 되었습니다. 기본적인 센서 및 액츄에이터를 올릴 수 있는 stm32 PCB설계, 전장설계, 웹서버 설계 및 연동 정도 가능합니다. 혼자서 드론 pcb 설계, 구조설계, 캘리브레이션, 시험비행까지 가능합니다. 문서화 능력 괜찮고 전전 회사에서부터 지금까지 문서화 능력, 정리 잘한다고 말들을 많이 하십니다. 딱 기본인가요?

샌드박스만 만들면 에이전트가 안전할까요? 실행 공간의 격리와 허용 정책은 따로 확인해야 합니다. GitHub Trending 일간 목록에서 NVIDIA/OpenShell은 조사 당시 978 stars today로 표시됐습니다. 파일 접근, 시스템 호출, 네트워크 연결을 정책으로 검사하는 에이전트 런타임입니다. 첫 시험은 지원 환경과 install.sh를 읽고, 폐기 가능한 환경에서 openshell sandbox create --name demo로 빈 샌드박스 하나만 만드는 것입니다. 실제 에이전트와 자격 증명을 연결하기 전에 기본 정책과 변경 뒤 새로 허용되는 호스트·API 메서드를 비교하세요. Linux와 Apple Silicon macOS를 지원하고 WSL 2는 실험적입니다. Docker·Podman 또는 호스트 가상화가 필요합니다. 최신 공개 릴리스는 v0.1.2, 라이선스는 Apache-2.0입니다. https://github.com/NVIDIA/OpenShell

본인이 필요해서 면접보자고 해놓고, 경력이 짧다고 면전에서 대놓고 갑질을 하네요. 그래놓고 연봉을 천만원이나 깎아놓고 워라벨 가능하다고 얼처구니가 없슴. 학원 수강생,컴퓨터 공학생보다 지식이 전무한 쓰레기들 인프라팀장,보안팀장,PM인 현실 DNS가 뭔지 모르는걸 왜 이렇게 당당하게 이야기 하는거지. 아주 역겨움

24시 넘어서 이력서를 확인하는 회사는 어떤 회사일까요?

AX , MCP, 업무 자동화 앱들이 쏟아져 나오고 있죠. 20여년 넘개 여러 언어를 통해 개발을 해 오며, 개발 언어에 대한 깨닭음을 풀어 봤습니다. 한글 개발언어 철학을 가지고, 모든 REST-API 가 연동 가능한 허브 어플리케이션을 한글 스크립트 언어로 풀어 봤습니다. AI 에이전트들과 한글 언어(domain specific langauage)를 학습 시키고 직접 에이전틀들이 한글 스크립팅을 하기 시작했습니다. 이벤트 -＞ 조건 판단 -＞ 수행 -＞ 전송, 타이머, 맥락 저장 의 단순한 언어의 원리로 복잡한 서비스 로직을 다 구성 할 수 있게 되었습니다. 모든 어플리케이션의 지휘자는 악보를 보지 않습니다. 손짓만 하죠^^ https://github.com/dorafather/NotebookFlow

요 며칠 제 피드에서 가장 자주 보이는 모델은 단연 제브(Jev)인 것 같습니다. 웹 자동화부터 에이전트까지, 벌써 각자의 방식으로 붙여보는 분들이 많더라고요. 저도 관심 있게 봤는데, 한 가지가 좀 아쉬웠습니다. 뭘 만들었는지는 보이는데, 그래서 넣기 전보다 얼마나 좋아졌는지는 알기 어려웠어요. 원래 쓰던 모델만으로도 되는 일인지, Jev를 넣어서 빨라진 건지, 비용은 오히려 늘지 않았는지요. 그래서 직접 비교해 봤습니다. 같은 일을 Jev 없이도 시켜보고, 넣어서도 시켜보면 차이가 보이지 않을까 싶었어요. 주제는 쇼핑몰 상담으로 잡았습니다. 배송 조회, 주문 취소, 반품처럼 누구나 한 번쯤 해봤을 만한 일이요. “반품할 수 있나요?”라고 물었다고 바로 반품을 접수하면 안 되겠죠. 가능한지만 궁금할 수도 있으니까요. 반대로 설명을 듣고 “그럼 진행해 주세요”라고 했다면, 그때는 실제로 처리해야 하고요. 이런 대화를 얼마나 잘 따라가는지 보고 싶었습니다. 처음에는 DeepSeek 혼자 상담하는 방식과, Jev가 필요한 정책을 고르고 DeepSeek가 답하는 방식을 비교했습니다. 이후에는 의도나 동의를 판단하는 부분을 따로 떼어 Jev에 맡겨봤어요. 주문 조회와 처리 코드는 같게 두고, 안내도 준비한 문구로 보여주면서요. 이 구성에서는 차이가 있었습니다. DeepSeek 대비 Jev의 처리 시간 중앙값은 약 55% 짧았고, 총비용은 약 20% 적었습니다. 그런데 여기까지만 쓰면 제가 처음에 아쉬워했던 소개 글이랑 다를 게 없겠죠. 한국어로 만든 가상 상담 20개를 방식마다 두 번씩 실행했는데, DeepSeek는 40번 모두 처리했고 Jev는 38번 처리했습니다. 같은 반품 대화에서 두 번 모두 멈췄어요. 고객이 처음에는 “반품할 수 있는지만 알고 싶어요”라고 했다가, 다음에는 “반품 신청까지 진행해 주세요”라고 말한 상황이었습니다. Jev는 여전히 동의가 없다고 판단해서 다시 진행할지 물었고요. 고객이라면 “방금 해달라고 했잖아요” 싶을 대화였습니다. 다만 제 실험 구성도 짚고 넘어가야 합니다. 고객이 앞서 한 말은 전달했지만, 상담원의 직전 답변과 현재 업무 상태는 판단 입력에 넣지 않았어요. 이걸 보강하면 결과가 달라질지는 아직 확인하지 못했습니다. 두 모델에 같은 입력을 줬다고 해서, 각각을 가장 잘 쓰는 방법까지 검증한 건 아니니까요. 이번 실험으로 Jev가 무조건 낫다거나 아직 못 쓴다고 결론 내리고 싶지는 않습니다. 대신 어떤 일을 맡겼을 때 이득이 있었고, 어디서는 처리를 놓쳤는지까지 같이 보여드리고 싶었어요. 그래야 자기 서비스에 넣을지 판단하는 데 조금이라도 도움이 될 테니까요. 직접 써보실 수 있게 가상 쇼핑몰도 열어뒀습니다. 로그인 없이 브라우저당 답변 10회까지, 두 상담 방식을 바꿔가며 체험할 수 있어요. 실험 결과는 사이트의 Lab에 정리했습니다. 전체 시간·비용 비교부터 시작해서, 배송 조회나 취소·반품처럼 상황별로 골라 볼 수 있게 해뒀어요. 차트에서 질문을 선택하면 얼마나 빨라졌고 비용이 얼마나 달라졌는지, 두 방식이 실제로 어떤 답변을 했는지까지 이어서 확인할 수 있습니다. 빠르고 저렴했어도 일을 끝내지 못한 경우는 따로 표시했고요. 어떤 설정으로 비교했는지, 제가 입력을 잘못 넣었다가 고친 부분도 남겨뒀습니다. 결과가 궁금하시면 Lab에서 관심 있는 질문 몇 개만 골라 보셔도 차이가 보일 거예요. 참고로 직접 체험하는 채팅은 처음 만든 상담 구성이고, Lab에는 그 이후 진행한 실험까지 담겨 있습니다. 위 수치는 준비한 문구로 안내한 작은 실험의 결과입니다. DeepSeek는 추론을 끈 설정이었고 답변 검토에는 AI를 사용했습니다. 실제 고객 상담의 성과를 측정한 것은 아닙니다. 저처럼 “그래서 기존 방식보다 뭐가 좋아졌는데?”가 궁금하셨던 분들께 참고가 되었으면 좋겠습니다. 읽어주셔서 감사합니다. 쇼핑몰 상담 체험: https://jev.baeksang.dev/ Lab에서 실험 결과 보기: https://jev.baeksang.dev/lab #Jev #AI에이전트

A 요청이 사용자 값을 저장한 직후 B 요청이 같은 변수를 덮어쓸 수 있습니다. 서버 모듈은 요청마다 새로 만들어지는 지역 저장소가 아닙니다. 같은 프로세스의 요청은 변경 가능한 모듈 변수를 함께 씁니다. B가 덮어쓴 뒤 A가 다시 읽으면 다른 사용자의 정보가 섞일 수 있습니다. 트래픽이 겹칠 때만 나타나 원인을 찾기도 어렵습니다. 사용자별 값은 요청 함수의 지역 변수에 두고 필요한 하위 컴포넌트에 props로 전달합니다. Server Component에서 같은 함수를 같은 인자로 반복 호출한다면 React의 cache로 중복 작업을 줄일 수 있습니다. 이 캐시는 서버 요청마다 무효화됩니다. 모듈 스코프에는 정적 설정과 정적 자산을 남기세요. 공유 캐시가 필요하다면 사용자별로 캐시 키를 나누고 TTL과 접근 범위를 명확히 해야 합니다. 영상의 A와 B 흐름처럼 현재 서버 코드에서도 요청이 겹칠 수 있는 지점을 확인해 보세요.

새 화면을 만들며 버튼에 팀 색상을 입힐 때가 있습니다. 파일마다 색상값을 고칠지, 전역 CSS 한곳에서 관리할지 먼저 결정하면 이후 수정 범위가 달라집니다. 오늘 GitHub Trending TypeScript 일간에서 133 stars today를 확인한 shadcn-ui/ui는 React UI 컴포넌트의 소스 코드를 프로젝트에 추가해 고쳐 쓰는 도구입니다. 9월 5일에는 기존 파일을 덮어쓰기 전 diff 확인을 다뤘고, 오늘은 새 프로젝트의 색상 관리 방식을 봅니다. 공식 테마 문서에서는 CSS 변수 방식이 기본값입니다. components.json에서 cssVariables가 true이면 전역 CSS의 :root와 .dark에 있는 --primary·--primary-foreground 값이 기본 Button의 배경·글자 색에 연결됩니다. 밝은 화면만 바꾸고 어두운 화면을 놓치면 글자가 잘 안 보일 수 있으므로 두 화면을 함께 확인해야 합니다. 작게 시험하려면 일회용 새 React 프로젝트에서 [email protected]으로 Button 하나를 추가하세요. components.json과 전역 CSS 경로를 확인하고 두 모드의 변수 값을 바꿔 버튼과 글자의 대비를 봅니다. 색상값을 각 컴포넌트의 Tailwind 클래스에 직접 넣는 방식도 있지만, 공식 문서는 초기 설정에서 --no-css-variables를 선택해야 한다고 안내합니다. 기존 프로젝트의 방식 전환은 삭제·재설치가 필요하므로 그대로 적용하지 마세요. 최신 안정 릴리스 [email protected]은 9월 4일에 나왔고 main은 9월 16일에도 변경됐습니다. 시험 버전을 고정하고 MIT 라이선스 고지, Tailwind CSS와 다크 모드 설정까지 확인한 뒤 팀에 맞는 방식을 고르세요. https://github.com/shadcn-ui/ui

보안 감사 결과를 팀에 공유할 때, 코드에서 의심스러운 경로를 봤다는 사실과 실제 취약점을 확인했다는 결론은 다릅니다. 오늘 GitHub Trending 일간에서 1,434 stars today로 눈에 띈 cloudflare/security-audit-skill을 확인했습니다. 조사 시점 별 5,440개, 포크 332개였습니다. Cloudflare가 공개한 코딩 에이전트용 보안 감사 스킬입니다. 공식 문서는 결과를 confirmed, needs_validation, rejected로 구분합니다. 예를 들어 실제 권한 정책이 저장소에 없다면, 확인하지 못한 사실과 소유자가 확인할 방법을 needs_validation에 남깁니다. 이는 설명용 상황이지 특정 서비스의 취약점 발견 사례가 아닙니다. 작게 시작하려면 대상 코드를 실행하기 전에 SKILL.md의 guidance/full audit 구분과 report-schema.json의 blockers·validation_plan 필드를 읽어 보세요. 이번 글에서는 실제 감사나 취약점 검증을 하지 않았습니다. 전체 감사에는 하위 에이전트, Node.js, OS 수준 샌드박스가 필요합니다. 네트워크·환경 변수·쓰기 범위를 통제할 수 없다면 대상 코드를 실행하지 말라는 지침입니다. 팀 승인 범위·민감 정보 처리도 먼저 정해야 합니다. MIT 라이선스, 확인한 main 커밋은 9월 14일이며 공개 릴리스는 확인되지 않았습니다. https://github.com/cloudflare/security-audit-skill

머지않아 AI가 인간을 완전히 대체할 것이고, 지금도 상당 부분 대체됐다는 말을 우리는 자주 듣습니다. 저는 그 말에 전면적으로 동의하지 않습니다. AI한테 “오늘 점심 뭐 먹지?”라고 물어보세요. 추천을 받고, 별로라고 해보세요. 다음 것도 싫다고 해보세요. 메뉴가 계속 나올 때가 있습니다. 참 친절합니다. 이번에는 친구나 애인에게 똑같이 해보세요. 다섯 번쯤 거절하면 이런 말이 나올 겁니다. “아니, 그럼 네가 뭘 먹고 싶은 건데? 한식? 중식? 애초에 배는 고픈 거야?” 슬슬 짜증은 나겠지만, 대화는 그때부터 달라집니다. 사실 아침을 늦게 먹어서 배가 별로 안 고팠을 수도 있고, 밥보다 그냥 밖에 나가고 싶었던 것일 수도 있으니까요. 저는 같이 일할 때도 이런 사람이 좋습니다. 제가 말한 것을 계속 가져오는 사람보다, 몇 번 어긋나면 “잠깐, 원하는 게 그게 맞아요?”라고 물어보는 사람요. 제 니즈를 처음부터 알아맞히라는 뜻은 아닙니다. 계속 안 맞으면 질문이나 접근을 바꿔봤으면 하는 겁니다. AI를 이용해 개발하면서도 이 차이를 느꼈습니다. Spring AI로 프로젝트를 만들 때였습니다. 추론 관련 정보를 응답에서 꺼내 쓰고 싶었는데 안 됐습니다. 사용하는 버전에 맞춰 공식 문서까지 분석하게 했는데도 AI는 계속 된다고 했습니다. 저는 코드를 고치고 또 고쳤습니다. 알고 보니 제공사별 응답 방식의 차이였습니다. 기능을 지원한다는 것과 제가 쓰는 조합에서도 된다는 것은 다른 이야기였고, 결국 응답을 직접 받아 변환해서 해결했습니다. 그 문제를 겪어본 사람이 옆에 있었다면 한마디 했을 것 같습니다. “그거 지금 쓰는 제공사도 지원하는 거 맞아요?” 저는 그 질문을 못 떠올려서 한참 돌아갔습니다. 앱을 출시할 때도 그랬습니다. 심리상담 앱이 구글 플레이 심사에서 조직 계정 요건에 부딪혔는데, AI에게 물어가며 이름을 바꾸다가 백엔드 DTO 이름까지 고쳤습니다. 지금의 제가 그때 옆에 있었다면 바로 말렸을 겁니다. “무슨 뻘짓을 하고 있어. 그 이름을 심사하는 사람이 보는 것도 아닌데.” 그때는 설명이 그럴듯하니 믿었습니다. 뭔가를 열심히 수정하고 있어서 해결에 가까워지는 줄 알았습니다. 사주 앱을 만들면서는 Apple Korea에 공식 문의까지 했습니다. 당시 제 계획에 대해 현실적으로 통과를 기대하기 어렵다는 취지의 답변을 들었습니다. AI의 설명에서 읽은 가능성과, 직접 확인한 현실 사이에는 거리가 있었습니다. 그래서 지금 누군가 사주 앱을 만들겠다고 하면 저는 어디에 출시할 건지부터 물어볼 겁니다. 한번 겪고 나니 먼저 마음에 걸리는 것이 생겼습니다. 저는 그걸 직관이라고 생각합니다. 요즘 이야기되는 FDE처럼 고객과 직접 부딪히며 문제를 풀어내는 역할도 그래서 중요해질 거라고 봅니다. 조금 거칠게 말하면, AI는 아직 이런 데서 멍청할 때가 있습니다. 저는 AI를 코딩으로 이길 자신도, 지식으로 이길 자신도 없습니다. 하지만 제가 겪어본 문제를 누군가 들고 온다면, 그 요청을 그대로 AI에게 전달하는 것보다 제가 함께 이야기하며 풀어가는 편이 더 잘할 자신은 있습니다. 어디서 막힌 건지 물어보고, 이미 시도한 것을 듣고, 애초에 그걸 만들어야 하는지부터 다시 볼 수 있으니까요. 때로는 메뉴를 하나 더 추천하는 대신 “배는 고픈 게 맞아요?”라고 물어야 합니다. 채용 공고나 면접에서 트러블슈팅 경험을 묻는 이유도 여기에 있다고 생각합니다. 한번 헤매본 사람에게는 다음에 먼저 확인할 것이 남습니다. 어떤 말을 믿었다가 틀렸는지, 무엇을 보고 방향을 바꿨는지가 그 사람의 자산이 됩니다. 그러면 우리는 무엇을 공부하고 어디에 집중해야 할까요? 저는 직접 해보고, 그 경험에서 직관을 길러야 한다고 생각합니다. AI가 해결해 줬다고 넘어가지 말고 왜 처음에는 안 됐는지 한번 더 봤으면 합니다. 경험 많은 사람이 다른 질문을 한다면 왜 그걸 먼저 물었는지도 들어보고요. AI 덕분에 해볼 수 있는 일은 많아졌습니다. 그 과정에서 결과물만 늘어나는 건 조금 아깝습니다. 다음에는 같은 곳에서 덜 헤매고, 누군가의 말을 들었을 때 더 필요한 질문을 할 수 있게 됐으면 합니다. 저는 그런 사람과 일하고 싶고, 저도 그런 사람이 되고 싶습니다. 긴 글 읽어주셔서 감사합니다.

사내에서 self-hosted PDF 도구를 검토할 때 저장소에 적힌 license 한 줄만 보고 도입 가능 여부를 판단하기는 어렵습니다. 같은 저장소 안에서도 코드 경로에 따라 조건이 다를 수 있습니다. 오늘 살펴본 Stirling-Tools/Stirling-PDF는 browser와 self-hosted server에서 PDF 편집·변환 기능을 제공하는 Java 기반 open-core application입니다. GitHub repository API는 license.spdx_id를 NOASSERTION으로 표시했습니다. 고정 commit 77b325cf의 파일 tree를 읽어 보니 이름이 LICENSE인 파일이 12개 있었습니다. root LICENSE는 열거된 디렉터리 밖의 content를 MIT로 두지만 app/proprietary, app/saas, engine과 frontend/editor 아래 7개 디렉터리는 각 LICENSE를 따르게 합니다. app/proprietary/LICENSE의 User License는 production, scale, business-critical use에 active User License가 필요하다고 명시합니다. 먼저 v2.14.3과 commit을 고정한 별도 환경에서 실제로 사용할 코드 경로의 LICENSE 목록을 만드세요. 합성 PDF 한 장으로 localhost:8080의 필요한 기능만 시험하고, production 전에는 접근 제어·파일 보관·백업·업데이트와 라이선스 조건을 함께 검토합니다. 이 확인은 특정 조직에 대한 법률 판단이 아닙니다. 최신 main commit은 2026-09-11입니다. https://github.com/Stirling-Tools/Stirling-PDF

웹 수집기에서 결과가 달라졌을 때 parse 로직 문제인지 대상 서버의 요청 제한인지 한 번에 판단하기는 어렵습니다. 개발 중 재현과 실제 운영 요청을 먼저 나누면 확인 범위가 선명해집니다. 오늘 살펴본 D4Vinci/Scrapling은 Python web scraping framework입니다. Spider의 development_mode를 켜면 첫 응답을 디스크에 저장하고 이후 같은 요청을 네트워크 없이 재생합니다. selector와 추출 코드를 고칠 때 유용하지만 캐시는 자동 만료되지 않고 rate limiting과 blocked-request retry를 거치지 않으므로 production에는 남기면 안 됩니다. 실제 crawl에서는 robots_txt_obey를 명시적으로 켜고 도메인별 동시 요청과 지연을 따로 정해야 합니다. 고정 commit 3115acab에서 cache, robots.txt, throttle 관련 공식 테스트 89개가 통과했습니다. 실제 사이트 접근 성공이나 차단 회피를 확인한 것은 아닙니다. 먼저 v0.4.15를 고정한 별도 환경에서 세 테스트를 실행하고, 운영 전에는 사이트 약관·공식 API·robots.txt·요청 속도·개인정보·저작권을 확인하세요. Python 3.10+, BSD-3-Clause이며 최신 main commit은 2026-09-11입니다. https://github.com/D4Vinci/Scrapling

업무 중 coding assistant가 맞는 답을 줬는데도 첫 명령을 찾느라 스크롤하는 일이 있습니다. 설명이 부족해서가 아니라, 첫 행동과 단계가 긴 문장 사이에 묻혀 있기 때문일 수 있습니다. 오늘 GitHub Trending 일간에서 3,882 stars today로 눈에 띈 ayghri/i-have-adhd는 답을 action first 형식으로 바꾸는 agent skill입니다. 조사 시점 값은 별 39,889개, 포크 2,280개였습니다. 공식 SKILL.md는 다음 행동을 첫 줄에 두고, 다단계 작업에는 번호를 붙이며, 마지막에는 2분 안에 할 수 있는 다음 행동 하나를 남기도록 합니다. 바로 전체 환경에 설치하기보다 테스트 세션에서 같은 작은 버그 수정 질문을 활성화 전후로 비교해 보세요. 이 시험은 출력 구조의 변화만 확인합니다. 답의 기술적 정확성이나 개인의 생산성 향상을 보증하지 않습니다. 규칙이 세션에 지속되고 저장소에는 always-on hook도 있으므로 SKILL.md, hook, plugin manifest와 비활성화·제거 절차를 먼저 확인해야 합니다. 최신 commit은 2026-09-10이고 라이선스는 MIT이며 공개 release는 확인되지 않았습니다. https://github.com/ayghri/i-have-adhd

팀에서 정적 웹 도구를 배포했는데 기대한 제출 버튼이 보이지 않으면 설정 누락처럼 느껴질 수 있습니다. 실제로는 파일을 내려받아 사람이 제출할지, 앱에서 GitHub PR까지 만들지 운영 방식을 먼저 정해야 하는 경우가 있습니다. 오늘 살펴본 microsoft/Ontology-Playground는 React 기반의 정적 온톨로지 설계 도구입니다. 별도 OAuth 없이 쓰면 Download RDF로 결과물을 내려받아 사람이 fork와 파일 추가, 빌드, 테스트, PR을 처리합니다. 자동 PR이 필요하면 GitHub OAuth App의 Device Flow와 client ID가 필요하고 public_repo 권한과 브라우저 localStorage의 토큰 정책도 검토해야 합니다. 고정 commit 1f8113ba에서 client ID 없이 npm ci와 npm run build는 완료됐습니다. npm test는 397개 중 389개만 통과했으므로 전체 테스트 통과로 판단하지 않았습니다. 처음에는 수동 제출을 한 번 끝까지 해보고, 반복 비용이 분명할 때 자동 경로를 여는 편이 운영 조건을 설명하기 쉽습니다. 저장소는 MIT이고 최신 main commit은 2026-08-31이며 공개 release는 확인되지 않았습니다. https://github.com/microsoft/Ontology-Playground

업무에 쓸 에이전트 스킬을 찾았더라도 바로 전체 환경에 설치할 필요는 없습니다. 먼저 목록을 보고 필요한 항목과 설치 범위를 정할 수 있습니다. 오늘 GitHub Trending 일간에서 125 stars today로 눈에 띈 vercel-labs/skills는 Codex를 포함해 75개 이상의 agent를 지원하는 TypeScript CLI입니다. 조사 시점 값은 별 30,871개, 포크 2,643개였습니다. 격리된 임시 디렉터리에서 고정 버전 CLI의 --list를 실행하니 9개 skill 이름과 설명이 표시됐습니다. 특정 skill을 선택하거나 프로젝트에 설치하지 않은 상태에서 후보를 확인한 것입니다. 실제로 도입할 때는 SKILL.md와 scripts, references, 라이선스를 읽고 외부 명령·credential·파일 변경 범위를 확인해야 합니다. 기본값은 project scope이고 -g가 global scope이므로, 처음에는 한 프로젝트와 한 agent로 범위를 좁히는 편이 좋습니다. 최신 release는 2026-09-08의 v1.5.25이고 라이선스는 MIT입니다. CLI 저장소와 내려받는 제3자 skill의 조건은 따로 확인하세요. https://github.com/vercel-labs/skills